所有测试均在一台使用八年的 MacBook Air（英特尔处理器）上运行。我套件中的每个工具都必须在这台机器上证明其价值——如果它无法在此轻量级环境下运行，就不会发布。
在 macOS 上进行 Android 开发本应无缝顺畅，但现实却并非如此。“Android 文件传输”会在复制过程中崩溃。ADB 封装程序即使闲置也要占用 400MB 内存。Xcode 更新会破坏 USB 设备检测。在我那台日益老化的 MacBook Air 上与这些工具斗争多年后，我不再等待他人修复它们，而是开始构建自己的工具。
成果便是 Hiyoko 套件——10 款专为 Android 开发打造的 macOS 实用工具，全部基于 Rust 和 Tauri v2 构建。
简要总结
- 使用 Rust（Tauri v2）+ React 构建了 10 多款适用于 macOS 的 Android 开发工具，以替代臃肿的现有方案。
- 自定义的基于 Rust 的 MTP 引擎取代了 macOS 上故障频发的“Android 文件传输”，支持六通道并行传输。
- 整个套件在一台使用八年的英特尔 MacBook Air 上运行，总内存占用低于 80MB。
- 本地优先架构：除非用户明确选择加入，否则敏感数据绝不会离开设备。
现有工具的问题
标准的 Mac 端 Android 工作流全靠临时拼凑维持。以下是我所面临的问题：
- Android 文件传输：苹果默认的 MTP 处理程序。传输超过 4GB 的文件时会崩溃。无进度指示器。无批量操作功能。已多年未更新。
- 基于 Electron 的 ADB 图形界面：仅为命令行工具包裹一层图形界面就占用 300-500MB 内存。在我的 8GB 内存机器上，这是不可接受的。
- 集成开发环境捆绑工具：Android Studio 内置的日志捕获和设备管理器虽然可用，但需要运行整个集成开发环境。
我需要的是独立、轻量且能出色完成单一任务的工具。
为何选择 Rust + Tauri v2
选择 Rust 并非出于炒作。当处理 MTP（媒体传输协议）或实时 ADB 日志流时，内存安全和并发能力不是可选项——它们决定了用户界面是流畅运行还是导致内核恐慌。
Tauri v2 是自然的搭配选择。Tauri 使用系统自带的 WebView，而非捆绑 Chromium（如 Electron 那样）。在我的机器上，差异显著：
// 在我那台使用八年的 MacBook Air 上的典型内存占用对比
// 基于 Electron 的 ADB 工具： ~350MB 常驻集大小
// Tauri v2 等效应用： ~25MB 常驻集大小
// 每个应用节省： ~325MB
// 对于套件中的 10 个应用而言，这决定了是
// “我的笔记本电脑快烧起来了”还是“我忘了它们还在运行”
Tauri v2 的项目结构保持了整个套件的整洁：
# Cargo.toml — 每个应用都是一个精简、专注的二进制文件
[package]
name = "hiyoko-mtp"
version = "2.4.0"
edition = "2021"
[dependencies]
tauri = { version = "2", features = ["macos-private-api"] }
serde =<
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
