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