DroidDock：把 ADB 包進 macOS 原生視窗，用桌面檔案總管讀寫 Android 裝置

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

DroidDock 是一款給 macOS 用的開源應用，讓你用一般的檔案管理視窗瀏覽和傳輸 Android 手機裡的檔案，不必在終端機打 ADB 指令。這篇文章要講的是它實際怎麼運作、怎麼安裝，以及官方資料能證明與不能證明哪些事；至於接上手機之後的傳輸速度和穩定度，需要你自己驗證，本文不做效果判斷。

Mac 一直缺的那塊：用視窗瀏覽 Android 檔案

Mac 的 Finder 不像 Windows 檔案總管那樣原生支援瀏覽 Android 手機的檔案系統。原因是 Android 手機對外走的是 MTP（Media Transfer Protocol，媒體傳輸協定），而蘋果的系統一直沒有把這個協定整合進 Finder。長期以來 macOS 使用者要嘛靠 Google 那款年代較早、介面也很基本的 Android File Transfer 工具，要嘛自己安裝 ADB（Android Debug Bridge）打指令列。前者更新停滯、遇到大一點的檔案經常卡住是使用者長期反映的問題，後者則需要記指令，對沒碰過開發工具的人門檻偏高。

DroidDock 處理的就是這塊空缺，它鎖定的是「想用圖形介面、又不想把檔案丟上雲端」的那群人。如果你平常也在找本機端的 檔案搜尋工具，會發現 DroidDock 處理的是另一頭：手機端的檔案總管。

ADB 是 DroidDock 的地基，也劃出它的能力上限

既然 DroidDock 的底層是 ADB，先花一段把 ADB 講清楚，你才會知道這工具的極限在哪。ADB 全名 Android Debug Bridge，是 Google 官方維護的命令列工具，用途是讓電腦跟 Android 裝置溝通，能列出檔案、安裝應用程式、看系統紀錄等等。Android Studio、各種刷機工具、第三方手機管理軟體，底下一樣都是呼叫它。

換句話說，ADB 早就解決了「Mac 跟 Android 互傳檔案」這件事，問題只出在它是一行行指令，一般人看不懂也不會用。DroidDock 要補的，就是把這套已經成熟的能力包成你看得懂的視窗。這也意味著它的能力上限大致等於 ADB 的能力上限，不會無中生有。

還有一點值得知道：ADB 看到的是裝置的真實檔案系統，目錄結構會比一般 MTP 工具呈現的「媒體資料夾」檢視更接近你在手機檔案管理員裡看到的樣子。DroidDock 介面上也對應有 Internal Storage（內部儲存）分頁和麵包屑導覽，讓你一層一層進出。不過新版 Android 的儲存權限規範越收越緊，能讀寫哪些目錄最終還是受系統權限控制，DroidDock 沒有辦法繞過這層限制，它只是把 ADB 看得到的東西呈現出來。

原生 macOS 介面，背後跑的還是 ADB

根據官方 README，DroidDock 的底層就是 Google 的 ADB，它只是幫 ADB 套上一層原生 macOS 介面。用 README 自己的話說，DroidDock「不會取代或繞過」ADB，而是 ADB 之上的一個友善介面。這點會直接影響你對它的判斷：資料走的是手機與電腦之間的 USB 本機連線，不經過任何雲端中繼站。

技術棧方面，從倉庫結構看得出來，後端是 Rust 搭配 Tauri 框架，前端是 React 加 TypeScript，這也是它能維持較小體積、跑成原生視窗、避開 Electron 那種肥大套件的原因。最新版本 v0.5.0（2026 年 7 月發布）的安裝檔是 universal 版，Apple Silicon（M1、M2、M3）和 Intel 機器都能用。授權是 MIT，著作權標示為 2025 Rajiv Subramanian M，原始碼完整公開在 GitHub，也就是說前面提到的「不繞過 ADB」「本地處理」這些說法，你都可以自己翻程式碼驗證。

從 GitHub 上的活動軌跡看，這個專案 2025 年 10 月才建立，最新版本在 2026 年 7 月釋出，累積三百多顆星，屬於還在持續更新的新興專案。好處是功能還在往前長、作者也維護著 Homebrew tap 方便更新；代價是它還沒有經過大規模、長時間的使用考驗，遇到邊界情境的機率比成熟老牌工具高一些。這點要跟「開源可自查」一起放進天平。

和透過瀏覽器操作的那類手機管理工具相比，DroidDock 走的是另一條路：它是一個安裝在系統裡的原生應用，不開瀏覽器、不靠 Wi-Fi，執行時直接呼叫本機的 ADB 程式。這代表你不必把手機和電腦連上同一個網路，也不必擔心瀏覽器分頁關掉就斷線，代價是你得先把它裝進應用程式資料夾、並跨過前面提到的那道 ADB 前置門檻。

從官方文件看一條上手的代表流程

README 提供了一條五分鐘上手的代表流程。要特別說明，這條流程來自官方文件，不是作者自己接手機跑出來的紀錄，它能證明的是「這些能力存在」，無法證明你在自家環境一定跑得順：

1. 安裝 DroidDock（Homebrew 或下載 DMG 兩條路）

2. 裝好 ADB

3. 在手機開啟 USB 偵錯

4. 用 USB 接上電腦，手機跳出「允許 USB 偵錯？」時選允許

5. 打開 DroidDock，裝置出現在選單裡就能開始瀏覽

連上之後，DroidDock 會自動偵測已接上的 Android 裝置，並在選單顯示它的型號名稱，你能在裝置下拉選單裡挑要操作的那台。

從官方釋出的截圖可以看到幾個關鍵畫面：清單檢視、圖片格狀預覽，以及資料夾同步執行前的預覽視窗。README 的功能列表提到它支援 Table、Grid、Column（Miller）三種檢視模式，搭配 Cmd 加數字鍵切換，並有縮圖自動產生與延遲載入（lazy loading）。檔案預覽按空白鍵就能快速看圖片或文字檔，不用先下載到電腦。

Pin

其中比較值得多看一眼的是資料夾雙向同步功能。它可以依檔名規則篩選要同步的項目、排除系統檔、保留原始修改時間戳，並且在實際執行前先預覽會變動哪些檔案，確認沒問題再真的跑。README 還提到單次下載遇到檔名衝突時可以逐一處理，不會整批中斷或直接覆蓋。對需要定期把照片備份到 Mac、或反向塞一批檔案過去的人來說，這個功能會比單純的單檔上傳下載更實用，也跟早期那種「傳到一半撞到同名檔案就停下來」的體驗拉開差距。它在介面底部的狀態列會顯示儲存空間用量，README 形容這個樣式是借鏡 VSCode 的狀態列。

Pin

日常操作上，README 列出的鍵盤快捷鍵能讓你大致想像用它工作的節奏：Cmd 加 F 聚焦搜尋列、Cmd 加 A 全選目前可見檔案、Cmd 加數字鍵在幾種檢視模式間切換，選檔案則是用點選加上 Ctrl 或 Cmd 多選、Shift 範圍選取，跟一般在 macOS 上操作檔案的習慣一致。搜尋功能可以 case-insensitive（不分大小寫）並遞迴整個子目錄，結果會帶完整路徑顯示。這些細節雖然要實際用了才知道順不順手，但從設計可以看出它想讓你少拿滑鼠、多用鍵盤把檔案搬完。

關於很多人會擔心的 USB 偵錯，README 有一段誠實的說明：USB 偵錯是 Android 官方的開發者介面，開啟它不會 root 手機、不會讓保固失效，也不會把手機暴露到網路上，它只允許一台你「實體接上、並在手機上明確同意」的電腦與裝置通訊，事後隨時可以在開發者選項裡關掉。這段說明本身是作者（官方）的陳述，但對照 Android 官方文件對 USB 偵錯的定義，方向是一致的。

官方資料能證明什麼、不能證明什麼

把可查證的事和需要自己驗證的事分清楚，才不會對這類工具產生錯誤期待。

官方資料能替它背書的，是這些能力確實存在、授權是 MIT、兩條安裝管道（Homebrew cask 與 GitHub Release 的 DMG）都公開可靠。這幾項都可在倉庫與 release 資產清單中查證。

但有幾件事官方文件無法替它背書。速度與穩定度方面：README 沒有給任何傳輸效能數字，也沒有實際接手機量測的結果，所以無從判斷它比 Android File Transfer 快或慢、或在大量檔案同步時會不會卡。

隱私這環節也得講清楚。README 明確寫著「DroidDock 不收集或傳輸任何個人資料，所有通訊只經 USB 在 Mac 與手機之間進行」，這是作者的宣告。原始碼裡沒有發現遙測或分析類 SDK 的呼叫痕跡（唯一的網路函式庫 reqwest 只出現在依賴鎖定檔 Cargo.lock，對應的是版本更新檢查），源碼層面與作者的說法一致。不過這不等於獨立的資安審計，對隱私特別敏感的人，建議自己再翻一次程式碼，畢竟它是開源的：重點可以放在 src-tauri 那層的 Rust 原始碼，看後端究竟對外發出了哪些網路請求，這比看前端介面更能確認資料流向。

與其他工具的比較也一樣。本文沒有對稱實測競品，所以不會說它「比什麼都好」。如果你要的是跨裝置、跨平台的 免登入檔案傳輸 方案，那屬於另一種工具類型，需求跟 DroidDock 不衝突。

會直接影響你決定的幾個硬限制

應用程式未簽署。第一次打開時 macOS 可能跳出「已損毀，無法打開」的訊息，README 說這是未經 App Store 分發的應用常見狀況，可清除隔離屬性（xattr -cr 指令）或以右鍵選單的「打開」繞過 Gatekeeper。對完全不接受未簽署軟體的人，這點要算進風險。

一定要先裝 ADB 並開啟 USB 偵錯。DroidDock 不會自己生出 ADB，少了這兩步它根本連不上手機。對完全不想碰終端機的人，安裝 ADB 這道門檻還是要跨一次，之後日常使用才不必再打指令。

只能透過 USB 連線。目前沒有無線傳輸的選項，想躺在沙發上用 Wi-Fi 翻手機檔案的人，這工具幫不上忙。

系統需求是 macOS 10.15（Catalina）以上。太舊的 Mac 不在支援範圍。它只處理檔案瀏覽傳輸，不是 Android 自動化 或系統層級控制工具，別期待它做 ADB 能力以外的事。

用最低成本判斷值不值得繼續用

想省點力氣試水，Homebrew 這條路最直接。在終端機依序執行：

brew tap rajivm1991/droiddock
brew install --cask droiddock
brew install android-platform-tools

前兩行裝 DroidDock，第三行裝 ADB。選 Homebrew 的好處是之後只要一行 brew upgrade --cask droiddock 就能更新，解除安裝也有對應指令，適合會一點終端機、想長期跟著新版走的人。完全不願意碰終端機的人，可以改走 README 提供的第二條路：到 GitHub 的 Releases 頁面下載 .dmg，把 DroidDock 拖進「應用程式」資料夾，ADB 則再從 Android 開發者網站抓 Android Platform Tools。兩條路裝出來的應用一樣，差別只在更新和解除安裝方不方便。

都裝好之後，接上已經開啟 USB 偵錯的手機，打開 DroidDock。判斷標準很單純：如果你的手機型號在幾秒內出現在裝置選單，而且點進去能看到內部儲存的目錄結構，代表這條 ADB 路線在你環境下是通的，值得進一步試它的同步與預覽功能；要是怎麼樣都偵測不到裝置，問題通常不出在 DroidDock 本身，而是回頭檢查 ADB 的安裝路徑，或手機那一端有沒有正確授予 USB 偵錯授權。

DroidDock 把一件本來要背指令的事，還原成大家都會用的拖放檔案視窗。它把 macOS 一直欠缺的那塊 Android 檔案總管補上，定位在本機 ADB 與雲端傳輸之間。

什麼情況下它值得你留在 Dock 上：你平常就是用 Mac，手機裡有一堆照片、影片或檔案要在兩邊搬，不想每次都開雲端硬碟繞一圈，也能接受插著 USB、跨過一次 ADB 與 USB 偵錯的前置門檻。相對地，如果你要的是無線、隨手丟個連結就能收檔案的方式，或者你連一次終端機指令都不願意打，那 DroidDock 未必是你的答案，走雲端傳輸或其他免安裝方案會更省事。會不會成為你固定的工具，接上手機跑一次就知道。