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