來自公眾號：InfoQ
編譯 | Tina、核子可樂
跨平臺開發更便宜，原生開發更優質？
作為世界上最受歡迎的密碼管理器，1Password 放棄了 15 年來始終堅持的原生開發方式，轉向了 Electron 框架，並徹底地重寫了所有的程式。
1Password 的聯合創始人 Roustem Karimov 表示，“這是一次徹底的重寫，沒有複製以前的任何一行程式碼。重寫我們所有的 Apps，是一個巨大的挑戰，一般人不該這麼做（Nobody should do this）。但是我們需要這樣一個核心的根本性變革，能推動我們面向未來，為下一個十年取得成功奠定基礎。”
大多數使用者其實並不關心開發人員用什麼來編寫我們所使用的應用程式，但 1Password 的情況顯然不同。8 月 11 日，沉寂多年的 1Password 釋出了 Early Access 大版本，作為蘋果平臺上最流行的密碼管理器應用， 這個版本一經釋出，1Password 的使用者社群就炸了！
“非原生是一個巨大的失誤，在各方面都是巨大的倒退！”
“我對改用 Electron 感到非常失望。”
輿論幾乎是一邊倒，1Password 的技術 VP Michael Fey 不得不發了 一篇長文 解釋他們為什麼要做出使用 Electron 重寫 Mac 版的決定。在文中，他說道：“這可能是我們必須做出的最複雜的決定。”
1將 1Password 8 轉向 Electron 的理由
1Password 擁有 15 年的歷史，但這些年來他們構建應用程式的方式基本相同。
1Password 最初是 Dave 和 Roustem 的業餘專案，他們的日常工作是作為程式設計師來構建網站，但他們厭倦了測試中需要不斷地手動填寫使用者名稱、密碼和聯絡資訊，於是他們編寫了一個工具來實現自動化。這個業餘專案迅速取代了他們的全職工作，並由此催生出了一整個公司和一個相關行業。
1Password 的首個版本是一個 Mac 專用程式。當蘋果之後公佈 iPhone SDK 時，這支小團隊繼續努力、開發出相應的 iPhone 版應用。在此之後，他們又逐漸推出了 Windows 與 Android 等多個版本，併為各個平臺聘請了獨立的開發人員。這些開發者能夠獲得檔案格式規範，瞭解應用如何在 Mac 及 iPhone 上執行，之後就自由為實際負責的平臺建立原生版應用程式。
發展多年之後的結果，就是同一款應用程式在不同平臺之上呈現出完全不同的使用介面。Windows 版本的 1Password 就跟 Mac 版在使用感受以及外觀上存在巨大差異，Android 與 iOS 版之間也是如此。
而且蘋果 Mac 是出了名的生命力頑強，目前仍有很多使用者在使用不支援 SwiftUI 的舊版 Mac，1Password 開發商 Agilebits 就還需要做出一個艱難的選擇——要麼為這款應用程式建立兩個 MacOS 版本，保證能夠繼續在較舊的 Mac 上執行；要麼直接放棄陳舊 Mac 硬體，繼續推動更新之路。當然，Agilebtis 也有第三種選擇，就是把應用程式直接轉向 Electron 平臺之上。乍看之下，第三種選擇似乎是下下之策，但琢磨之後這好像又是最好的方案。
Electron 是一套跨平臺應用程式構建方案，能夠幫助開發者在無需編寫原生程式碼的情況下獲得良好的跨平臺執行能力。Electron 允許編碼人員使用 JavaScript、HTML 以及 CSS 構建自己的應用程式。而且無論終端使用者使用的是 MacOS、Windows 還是 Linux，Electron 編寫出的應用程式都能使用相同的程式碼庫。
目前，Slack、WhatsApp Desktop、Microsoft Teams 以及 Discord 等常用軟體都在使用 Electron。但這套框架的問題在於，經它之手的應用程式往往要比原生版本佔用更多系統資源，特別是記憶體。儘管如此，看起來 1Password 轉向 Electron 已經成為板上釘釘的事實。
也正因為如此，不少人對轉向 Electron 的決定表示不理解。畢竟既然考慮的是使用較舊 Mac 裝置的使用者，就應該注意到這類硬體的記憶體容量本來就有限。而且在執行這種應用程式時，我們還得同時啟動另一位知名記憶體佔用大戶——谷歌 Chrome 瀏覽器。
這也是引發爭議的根源。沒錯，這款軟體源於 Mac，但其開發商卻放棄了原生開發以擴充套件支援 MacOS 作業系統的更多版本——這著實令人感到不安。但至少可以明確一點，開發商並不打算放棄 Mac。他們做出的 Electron 框架使用決定雖然會佔用更多記憶體，但核心目標確實是想讓相同的程式碼庫能繼續順利執行在舊版 MacOS 之上。
總之，將 1Password 轉向 Electron 的基本思路，是為了減少 Agilebits 所需維護的應用程式數量。為了與更多 MacOS 版本保持相容，開發者只能為同一作業系統構建兩款不同的應用程式。對於最新版本的 MacOS，Agilebits 使用 SwiftUI 工具包進行 1Password 8 開發；但對於舊版本，開發人員只能提供基於 Web 的應用程式。
Electron 本身就基於 Web，因此 1Password 8 的 MacOS 版本有望執行在較舊的 Mac 裝置之上。畢竟 SwiftUI 只支援 MacOS 10.15 以及更高版本。雖然調整之後，新版本的執行方式和使用感受可能與之前版本有所區別，但至少它還是能為簡化開發流程貢獻力量。我們只能希望它能比其他常規 Electron 應用程式少消耗一點記憶體。
2儘管爭議不斷，跨平臺仍然“真香”！
用跨平臺 Electron 取代之前廣受歡迎的 Mac 原生應用程式，這一舉動引發的反響確實巨大，但關於跨平臺應用程式技術的討論始終圍繞著一個簡單到有些粗暴的前提：跨平臺開發更便宜，原生開發更優質。
此話倒也不假，畢竟跨平臺工具的超高人氣確實主要來自更低的多平臺開發成本。但這種心理模型並不一定能確切解釋每一家選擇走跨平臺路線的軟體開發商的真實訴求。每當有跨平臺應用程式被推上網際網路輿論的風口浪尖時，我們都會聽到這樣一個問題：“既然開發商有能力為不同平臺分別開發應用程式，他們為什麼要逼迫一部分使用者放棄原生版本？”
但在實踐中，跨不跨平臺所權衡的絕不僅僅是“便宜和優質”。有過開發經驗的朋友們應該清楚，原生技術有時候也能帶來低成本，而跨平臺在特定情況下反而有助於提升軟體質量。那麼，我們在權衡跨不跨平臺時，到底是在糾結什麼？
核心權衡
宏觀來看，跨平臺 UI 技術優先考慮的並不是完善的使用者體驗、而是功能的順暢協調。
我們設想這樣一個典型的跨平臺 UI 案例：有一款複雜的企業級應用程式，供數千名員工在各類平臺上日常使用。他們需要用它處理工作內容，還需要接受相關使用培訓——但是，這款應用程式需要取悅使用者嗎？並不需要。於是，“用著爽”就成了優先事項列表中墊底的一條，基本等同於“音效好聽”和“支援遊戲手柄”這個層級。只有先滿足了跨平臺一致性和成本效益等核心訴求，之後才可能考慮這些專案。
有鑑於此，企業當然更喜歡跨平臺工具。企業軟體最關注的就是功能支援效果，也向來是“不講使用體驗”的典型代表。對於跨平臺工具的常見批評意見，就是它能快速讓應用的質量達到預期的 75%，但餘下的 25% 則再難寸進。不過只要 75% 已經處於可以接受的範圍，那麼投標合同應該就能順利收款了，還費別的勁幹什麼呢？
於是很自然地，內部企業應用程式率先開始了跨平臺 UI 融合之旅——尤其以 Web 為主。確實是難看難使，但就是能發揮正常作用，你說氣不氣。
而在面向客戶的軟體方面，情況就要複雜得多。體驗成了決定產品生死存亡的關鍵，只有針對特定平臺的 UI 程式碼能夠觸及“使用者體驗上限”，這類軟體才能真正留住付費使用者的心。從概念上說，一家願意花大錢開發高質量原生 Mac 及 Windows 版本軟體的廠商應該能夠在競爭中壓倒 Electron 版的 Slack、Figma 以及 Spotify 才對，但為什麼實際情況不是這樣呢？
協調成本的指數級增長
在小型產品團隊中，讓幾款原生應用程式保持一致並不困難。在這樣的規模下，原生工具的使用者體驗與便捷性完全碾壓跨平臺。但是，隨著產品及組織規模的快速發展，一致性開始成為真正的難題。當我們快速招聘新員工、快速新增客戶功能並逐漸需要為第三、第四乃至第五種平臺提供支援時，情況將越來越危急。1Password 的 Michael Fey 在開發博文中做出瞭如下解釋：
隨著時間推移，大大小小的不一致性元素開始滲透到我們的應用程式當中。從平臺間密碼強度不同等小問題到搜尋結果差異、再到不同版本間完全不互通的功能配置，情況變得越來越糟糕。
這很重要，因為隨著平臺之間功能、設計與 bug 的快速增加，對不同版本做出協調正逐漸變得不可能。
- 這項功能要何時在 Mac 上推出？
- 這份支援文件符合 Web 使用者的情況嗎？
- 等等，這裡的廣告內容是指向哪個平臺的？
起初，企業還可以向銷售及支援團隊提供資金支援來勉強維持統一，但隨著設計衝突的積累，更加危險的問題出現了：產品團隊越來越難以理解自己打理的產品。最終，各個平臺團隊已經不在同一個頻道上，產品交流效率變低、密密麻麻的“路線”彼此交織、重要的細節慘遭忽略……
有些企業會始終堅持客戶端應用程式的精簡化，也成功避免了這種命運。只要能夠保持團隊紀律、讓產品始終簡單、不過度擴張平臺、不快速提升團隊規模，那麼長期保持同步並不是難事。這裡的關鍵策略，就是儘可能把複雜性體現在伺服器端，而客戶端應用程式則儘可能“無腦”，這樣就不需要同時在多種客戶端上迭代大量邏輯。
但只要團隊規模與產品複雜性持續提升，並且需要在好幾種平臺上維護大量功能，那其中的不一致性終將失控。
- 一位重要客戶很生氣，因為銷售說新版本提供一項功能，但在對方的實際平臺上根本找不到。
- 有人在 Twitter 上批評我們，說我們的文件內容有誤；產品經理進行了深入研究，並發現這部分內容只是不符合 Android 版本的情況。
- 我們無法測試有希望的新改進，因為新功能必須同時在所有平臺上執行，而 Windows 團隊的正常更新進度已經嚴重落後了。
- iOS 與 Android 產品團隊之間的術語差異導致某個討厭的 bug 在 iOS 上存在了 5 個禮拜，混亂的溝通反而讓 Android 團隊推出了一款沒啥作用的修復程式。
總之，事情變得一團糟。
所以在具有一定規模的產品組織架構之下，一致性與協調性絕不像嘴上說說那麼簡單。產品體系需要藉助更多流程才能讓各平臺保持程式碼庫同步，開發者被迫將更多時間花在規程、說明文件與形式工作上。功能質量雖然更高，但開發進度變得更慢。而這種強一致性保障，同時也代表著產品的更新迭代做不出太大的變化。
總而言之，要保持多個平臺上的程式碼庫始終一致並非不可能，只是成本極高。我們需要僱用更多工程師來引入非零改進，但協調工作的成本會呈指數級增長（至少是超線性增長），導致每位新員工帶來的額外產品開發增速極為低下。
緩慢而低效，最終會令你輸掉比賽
對於產品開發商來說，緩慢是個致命的弱點。速度慢的產品團隊往往會被行動更快的對手所擊敗。我們經常抱怨 Figma 和 Slack 之類的產品給不了原生使用體驗，但為什麼大多數人仍在使用 Figma 與 Slack 這些？因為它們的實際表現確實壓倒了原生競爭對手。這些產品中當然還有很多可以改進的地方，但它們確實在自己設定的發展路線上做到了最好。
於是，跨平臺與原生工具之間的權衡就成了大規模協調工作中的重要組成部分。沒錯，原生程式碼特別擅長構建起出色的使用者介面，但如果大型產品團隊與多種客戶端程式碼庫會極大拖慢更新進度，那麼原生開發方法本身就是在破壞使用者體驗。
因此，我們得出一種非線性權衡，而不再是簡單的“優質與便宜”之爭。誰對跨平臺工具最感興趣？當然是那些希望能在多個平臺上協調多種功能的團隊，這意味著功能性的優先順序要高於原生使用體驗。而在移動平臺上，開發團隊通常不會貿然推出新功能、倒是願意精心設計使用者體驗並加以潤色，所以移動端開發往往比桌面端更傾向原生方法。
當然，我們也可以從多種跨平臺方案中做出選擇，儘可能把協調負擔降下去。不同於此次 1Password 投向 Electron 所引發的巨大批評，之前他們決定將所有應用程式版本轉向共享 Rust 庫的決定就廣受歡迎。有趣的是，近年來 Dropbox 及 Slack 等知名團隊都發表過如何避免使用跨平臺核心庫來支援移動應用的文章——目前，雙方都在使用完全原生的 iOS 與 Android 程式碼庫。就目前的情況看，市場似乎分成了兩大派別——一派宣佈全面轉向 React Native，另一派則決定徹底放棄 React Native。這也是個有趣的話題，以後有機會再單獨討論。
總之，我們能做的就是認真考慮不同技術善於解決哪些問題，並對判斷保持足夠的警惕。我們會觀察技術的發展，與實際使用者交談，並瞭解團隊分享的哪怕一點點經驗。只有這樣，我們才有機會認清事實的全貌。
https://blog.1password.com/1password-8-the-story-so-far/
https://allenpike.com/2021/gravity-of-cross-platform-apps
