Matrix 首頁推薦

文章代表作者個人觀點，少數派僅對標題和排版略作修改。

如果要我選最愛的 Apple 功能，那必定是 AirDrop。在接觸 AirDrop 前，我一直用著笨笨的檔案傳輸方法——以 QQ 作為中轉，需要經歷「新增好友-上傳檔案-下載檔案」的複雜流程，既耗時、又費力。

那 AirDrop 有什麼好？

簡單的 AirDrop 操作

在《設計心理學》一書說過，「好的設計有兩個重要特徵：

可視性

（discoverability）及

易通性

（understanding）。」AirDrop 符合這兩個特徵：

可視性：在入口位於點選分享後最顯眼的地方。

易通性：選擇 AirDrop 後，立刻出現目標裝置選項，設計用意明顯；設計用途就是分享、傳送，沒有其他功能。

此外，同類競品堆滿各式各樣的功能，Apple 卻始終保持克制，一直在做減法；相較而言，AirDrop 操作邏輯更符合使用直覺，使用只需兩步：分享檔案、然後選擇物件。

AirDrop 什麼都好，易用、速度頗快（33Mbps+）；但談起它，卻始終繞不開

僅限 Apple 裝置使用

的硬傷。所以作者群的@陳川端有天提出疑惑，有沒有支援跨平臺的 AirDrop 呢？

鴿子群截圖

有個工具不但和 AirDrop 一樣好用，還開源、全平臺支援並且免費。它就是我們今天的主角——Snapdrop。

開箱即用

受 AirDrop 啟發誕生，Snapdrop 功能和介面與 AirDrop 十分相像。Snapdrop 只保留了最核心特性：

檔案傳輸

開箱即用

跨平臺，只要有瀏覽器便能用（Android、iOS、Windows、macOS、Linux）

離線使用

只要兩個裝置在同一個區域網，並且同時開啟snapdrop。net便能使用。無需任何設定，也不用下載客戶端、搗弄埠。這是我看過最

簡單

的檔案傳輸方式之一。

你會獲得一個暫時名稱作為當前裝置的識別碼。在截圖中，本機的識別碼是 ，在區域網發現了臺 iOS iPad 叫 。巧合的是，名字組合規律是【顏色 + 動物】。前者是薰衣草貂，後者是灰色鬣狗，或許這就是程式設計師的情趣吧。

AirDrop 既視感

類似 AirDrop，點選裝置圖示選取傳送物件。左鍵在 macOS 上會彈出 Finder 檔案視窗，選中檔案即可傳送。

如果右鍵點選裝置圖示，則會喚出文字輸入框，能傳送文字到目標裝置。還不快傳送情話給你的心儀物件，展開轟轟烈烈的愛情？

土味情話大師

理論上，需要瀏覽器支援 WebRTC API 才能使用。Chrome、Firefox 在 2012 年的版本已經支援 WebRTC，市面主流瀏覽器都支援。現在應該沒人還用 IE 了吧？

以 PWA 為載體

在第一次用 Snapdrop 時，Chromium 核心瀏覽器（e。g。 Chrome、Edge）會詢問你是否要

安裝

Snapdrop。PWA 有著輕量化的優勢，佔用空間小到可以忽略。

PWA 安裝彈窗

在測試過程中，我還發現 Snapdrop 支援 PWA 一個重要的特性——離線使用。Snapdrop 網頁會自動進行

快取

。之後就算沒有連線到網際網路，就像一個安裝好的 App 一般，你仍然能開啟 Snapdrop，進行區域網檔案傳輸。

另外它也支援

系統通知

，當授予通知許可權後，每當有新的檔案傳輸完成，便會以原生通知形式出現。

macOS 通知 Banner速度尚可

這個速度和 AirDrop 相比，實在拉胯。AirDrop 能跑滿 802。11n 的寬頻（33 Mbps），Snapdrop 顯然還差得遠。不過，又不是不能用對吧？傳送一些小檔案非常好用。

奇怪的是，從 iPhone 傳送 照片到 macOS 電腦時，會自動轉換成 。 好像是 Safari 為了保證相容性做的自動轉換。

要避免格式轉換，把照片存到 iOS 的文件 App，在選擇檔案的時候，別選照片，而是選檔案。

其他細節

Snapdrop 在隱私方面讓我頗為放心：

第一，它是

開源

的。

第二，Snapdrop承諾他們不會儲存

任何

使用者資料。

第三，技術上使用者隱私得以保護。WebRTC 在檔案傳輸時自行加密，防止其他人（包括 Snapdrop 團隊）窺探使用者文件。如果以上無法打動你，你甚至可以託管你的 Docker映像，建立私人的 Snapdrop 網頁。

雖然我覺得 PWA 已經足夠好用，你仍然能使用開源社群為 Snapdrop 開發的

第三方

客戶端。

至於傳輸原理，Snapshare 使用了 WebRTC 協議提供的 P2P1功能。WebRTC 受 Apple、Google、Microsoft、Mozilla、Opera 支援，是 W3C 下的開源、免費標準。開發者利用簡單的 API 介面，就能在瀏覽器開發端對端實時通訊的網路應用。

WebRTC 定義了三個常用的 Javascript API：

獲取使用者機器上的多媒體文件。

建立 P2P 連線。負責訊號處理、編碼、端對端通訊、安全、寬頻管理。

雙向傳輸資料。

兩個 peers 之間，不會「嘛哩嘛哩哄」神奇地便連線起來了。能看到原理圖中，兩個客戶端之外，還有一個節點稱作 Signaling 伺服器。

說好的 P2P 去中心化，怎麼冒出來一個伺服器呢？這個 Signaling 伺服器還不歸 WebRTC 標準管。

Signaling 伺服器的作用類似相親裡的

媒人

。一開始，兩個客戶端互不認識。他們需要一箇中介人去介紹，才知道另一方的存在，而後使用 WebRTC 定義的 API 進行 P2P 連線及資料傳輸。就像相親中，透過媒人相識，而後才能約出來吃飯。沒相親過，應該是這樣吧。（逃

兩個客戶端發現對方後，文件傳輸的過程確實是 P2P，不像使用公有云（e。g。 百度網盤、iCloud）一般依賴中央伺服器上傳下載。

結語

Snapdrop 是我目前找到最簡單的跨平臺檔案傳輸方式，過去的檔案傳輸類應用要不需要下載客戶端，要不就得要用到命令列，學習成本不低。Snapdrop 可能傳輸速度比較容易受路由器等網路環境因素影響，卻有著最容易上手的特性，非常適合一些日常場景中小型檔案的傳輸。