來(lái)自公眾號(hào)：InfoQ

編譯 | Tina、核子可樂(lè)

跨平臺(tái)開(kāi)發(fā)更便宜，原生開(kāi)發(fā)更優(yōu)質(zhì)？

作為世界上最受歡迎的密碼管理器，1Password 放棄了 15 年來(lái)始終堅(jiān)持的原生開(kāi)發(fā)方式，轉(zhuǎn)向了 Electron 框架，并徹底地重寫(xiě)了所有的程序。

1Password 的聯(lián)合創(chuàng)始人 Roustem Karimov 表示，“這是一次徹底的重寫(xiě)，沒(méi)有復(fù)制以前的任何一行代碼。重寫(xiě)我們所有的 Apps，是一個(gè)巨大的挑戰(zhàn)，一般人不該這么做（Nobody should do this）。但是我們需要這樣一個(gè)核心的根本性變革，能推動(dòng)我們面向未來(lái)，為下一個(gè)十年取得成功奠定基礎(chǔ)?！?/p>

大多數(shù)用戶(hù)其實(shí)并不關(guān)心開(kāi)發(fā)人員用什么來(lái)編寫(xiě)我們所使用的應(yīng)用程序，但 1Password 的情況顯然不同。8 月 11 日，沉寂多年的 1Password 發(fā)布了 Early Access 大版本，作為蘋(píng)果平臺(tái)上最流行的密碼管理器應(yīng)用， 這個(gè)版本一經(jīng)釋出，1Password 的用戶(hù)社區(qū)就炸了！

“非原生是一個(gè)巨大的失誤，在各方面都是巨大的倒退！”

“我對(duì)改用 Electron 感到非常失望?！?/p>

輿論幾乎是一邊倒，1Password 的技術(shù) VP Michael Fey 不得不發(fā)了 一篇長(zhǎng)文 解釋他們?yōu)槭裁匆龀鍪褂?Electron 重寫(xiě) Mac 版的決定。在文中，他說(shuō)道：“這可能是我們必須做出的最復(fù)雜的決定?！?/p>

1將 1Password 8 轉(zhuǎn)向 Electron 的理由

1Password 擁有 15 年的歷史，但這些年來(lái)他們構(gòu)建應(yīng)用程序的方式基本相同。

1Password 最初是 Dave 和 Roustem 的業(yè)余項(xiàng)目，他們的日常工作是作為程序員來(lái)構(gòu)建網(wǎng)站，但他們厭倦了測(cè)試中需要不斷地手動(dòng)填寫(xiě)用戶(hù)名、密碼和聯(lián)系信息，于是他們編寫(xiě)了一個(gè)工具來(lái)實(shí)現(xiàn)自動(dòng)化。這個(gè)業(yè)余項(xiàng)目迅速取代了他們的全職工作，并由此催生出了一整個(gè)公司和一個(gè)相關(guān)行業(yè)。

1Password 的首個(gè)版本是一個(gè) Mac 專(zhuān)用程序。當(dāng)蘋(píng)果之后公布 iPhone SDK 時(shí)，這支小團(tuán)隊(duì)繼續(xù)努力、開(kāi)發(fā)出相應(yīng)的 iPhone 版應(yīng)用。在此之后，他們又逐漸推出了 Windows 與 Android 等多個(gè)版本，并為各個(gè)平臺(tái)聘請(qǐng)了獨(dú)立的開(kāi)發(fā)人員。這些開(kāi)發(fā)者能夠獲得文件格式規(guī)范，了解應(yīng)用如何在 Mac 及 iPhone 上運(yùn)行，之后就自由為實(shí)際負(fù)責(zé)的平臺(tái)創(chuàng)建原生版應(yīng)用程序。

發(fā)展多年之后的結(jié)果，就是同一款應(yīng)用程序在不同平臺(tái)之上呈現(xiàn)出完全不同的使用界面。Windows 版本的 1Password 就跟 Mac 版在使用感受以及外觀上存在巨大差異，Android 與 iOS 版之間也是如此。

而且蘋(píng)果 Mac 是出了名的生命力頑強(qiáng)，目前仍有很多用戶(hù)在使用不支持 SwiftUI 的舊版 Mac，1Password 開(kāi)發(fā)商 Agilebits 就還需要做出一個(gè)艱難的選擇——要么為這款應(yīng)用程序創(chuàng)建兩個(gè) MacOS 版本，保證能夠繼續(xù)在較舊的 Mac 上運(yùn)行；要么直接放棄陳舊 Mac 硬件，繼續(xù)推動(dòng)更新之路。當(dāng)然，Agilebtis 也有第三種選擇，就是把應(yīng)用程序直接轉(zhuǎn)向 Electron 平臺(tái)之上。乍看之下，第三種選擇似乎是下下之策，但琢磨之后這好像又是最好的方案。

Electron 是一套跨平臺(tái)應(yīng)用程序構(gòu)建方案，能夠幫助開(kāi)發(fā)者在無(wú)需編寫(xiě)原生代碼的情況下獲得良好的跨平臺(tái)運(yùn)行能力。Electron 允許編碼人員使用 JavaScript、HTML 以及 CSS 構(gòu)建自己的應(yīng)用程序。而且無(wú)論最終用戶(hù)使用的是 MacOS、Windows 還是 Linux，Electron 編寫(xiě)出的應(yīng)用程序都能使用相同的代碼庫(kù)。

目前，Slack、WhatsApp Desktop、Microsoft Teams 以及 Discord 等常用軟件都在使用 Electron。但這套框架的問(wèn)題在于，經(jīng)它之手的應(yīng)用程序往往要比原生版本占用更多系統(tǒng)資源，特別是內(nèi)存。盡管如此，看起來(lái) 1Password 轉(zhuǎn)向 Electron 已經(jīng)成為板上釘釘?shù)氖聦?shí)。

也正因?yàn)槿绱耍簧偃藢?duì)轉(zhuǎn)向 Electron 的決定表示不理解。畢竟既然考慮的是使用較舊 Mac 設(shè)備的用戶(hù)，就應(yīng)該注意到這類(lèi)硬件的內(nèi)存容量本來(lái)就有限。而且在運(yùn)行這種應(yīng)用程序時(shí)，我們還得同時(shí)啟動(dòng)另一位知名內(nèi)存占用大戶(hù)——谷歌 Chrome 瀏覽器。

這也是引發(fā)爭(zhēng)議的根源。沒(méi)錯(cuò)，這款軟件源于 Mac，但其開(kāi)發(fā)商卻放棄了原生開(kāi)發(fā)以擴(kuò)展支持 MacOS 操作系統(tǒng)的更多版本——這著實(shí)令人感到不安。但至少可以明確一點(diǎn)，開(kāi)發(fā)商并不打算放棄 Mac。他們做出的 Electron 框架使用決定雖然會(huì)占用更多內(nèi)存，但核心目標(biāo)確實(shí)是想讓相同的代碼庫(kù)能繼續(xù)順利運(yùn)行在舊版 MacOS 之上。

總之，將 1Password 轉(zhuǎn)向 Electron 的基本思路，是為了減少 Agilebits 所需維護(hù)的應(yīng)用程序數(shù)量。為了與更多 MacOS 版本保持兼容，開(kāi)發(fā)者只能為同一操作系統(tǒng)構(gòu)建兩款不同的應(yīng)用程序。對(duì)于最新版本的 MacOS，Agilebits 使用 SwiftUI 工具包進(jìn)行 1Password 8 開(kāi)發(fā)；但對(duì)于舊版本，開(kāi)發(fā)人員只能提供基于 Web 的應(yīng)用程序。

Electron 本身就基于 Web，因此 1Password 8 的 MacOS 版本有望運(yùn)行在較舊的 Mac 設(shè)備之上。畢竟 SwiftUI 只支持 MacOS 10.15 以及更高版本。雖然調(diào)整之后，新版本的運(yùn)行方式和使用感受可能與之前版本有所區(qū)別，但至少它還是能為簡(jiǎn)化開(kāi)發(fā)流程貢獻(xiàn)力量。我們只能希望它能比其他常規(guī) Electron 應(yīng)用程序少消耗一點(diǎn)內(nèi)存。

2盡管爭(zhēng)議不斷，跨平臺(tái)仍然“真香”！

用跨平臺(tái) Electron 取代之前廣受歡迎的 Mac 原生應(yīng)用程序，這一舉動(dòng)引發(fā)的反響確實(shí)巨大，但關(guān)于跨平臺(tái)應(yīng)用程序技術(shù)的討論始終圍繞著一個(gè)簡(jiǎn)單到有些粗暴的前提：跨平臺(tái)開(kāi)發(fā)更便宜，原生開(kāi)發(fā)更優(yōu)質(zhì)。

此話(huà)倒也不假，畢竟跨平臺(tái)工具的超高人氣確實(shí)主要來(lái)自更低的多平臺(tái)開(kāi)發(fā)成本。但這種心理模型并不一定能確切解釋每一家選擇走跨平臺(tái)路線(xiàn)的軟件開(kāi)發(fā)商的真實(shí)訴求。每當(dāng)有跨平臺(tái)應(yīng)用程序被推上互聯(lián)網(wǎng)輿論的風(fēng)口浪尖時(shí)，我們都會(huì)聽(tīng)到這樣一個(gè)問(wèn)題：“既然開(kāi)發(fā)商有能力為不同平臺(tái)分別開(kāi)發(fā)應(yīng)用程序，他們?yōu)槭裁匆破纫徊糠钟脩?hù)放棄原生版本？”

但在實(shí)踐中，跨不跨平臺(tái)所權(quán)衡的絕不僅僅是“便宜和優(yōu)質(zhì)”。有過(guò)開(kāi)發(fā)經(jīng)驗(yàn)的朋友們應(yīng)該清楚，原生技術(shù)有時(shí)候也能帶來(lái)低成本，而跨平臺(tái)在特定情況下反而有助于提升軟件質(zhì)量。那么，我們?cè)跈?quán)衡跨不跨平臺(tái)時(shí)，到底是在糾結(jié)什么？

核心權(quán)衡

宏觀來(lái)看，跨平臺(tái) UI 技術(shù)優(yōu)先考慮的并不是完善的用戶(hù)體驗(yàn)、而是功能的順暢協(xié)調(diào)。

我們?cè)O(shè)想這樣一個(gè)典型的跨平臺(tái) UI 案例：有一款復(fù)雜的企業(yè)級(jí)應(yīng)用程序，供數(shù)千名員工在各類(lèi)平臺(tái)上日常使用。他們需要用它處理工作內(nèi)容，還需要接受相關(guān)使用培訓(xùn)——但是，這款應(yīng)用程序需要取悅用戶(hù)嗎？并不需要。于是，“用著爽”就成了優(yōu)先事項(xiàng)列表中墊底的一條，基本等同于“音效好聽(tīng)”和“支持游戲手柄”這個(gè)層級(jí)。只有先滿(mǎn)足了跨平臺(tái)一致性和成本效益等核心訴求，之后才可能考慮這些項(xiàng)目。

有鑒于此，企業(yè)當(dāng)然更喜歡跨平臺(tái)工具。企業(yè)軟件最關(guān)注的就是功能支持效果，也向來(lái)是“不講使用體驗(yàn)”的典型代表。對(duì)于跨平臺(tái)工具的常見(jiàn)批評(píng)意見(jiàn)，就是它能快速讓?xiě)?yīng)用的質(zhì)量達(dá)到預(yù)期的 75%，但余下的 25% 則再難寸進(jìn)。不過(guò)只要 75% 已經(jīng)處于可以接受的范圍，那么投標(biāo)合同應(yīng)該就能順利收款了，還費(fèi)別的勁干什么呢？

于是很自然地，內(nèi)部企業(yè)應(yīng)用程序率先開(kāi)始了跨平臺(tái) UI 融合之旅——尤其以 Web 為主。確實(shí)是難看難使，但就是能發(fā)揮正常作用，你說(shuō)氣不氣。

而在面向客戶(hù)的軟件方面，情況就要復(fù)雜得多。體驗(yàn)成了決定產(chǎn)品生死存亡的關(guān)鍵，只有針對(duì)特定平臺(tái)的 UI 代碼能夠觸及“用戶(hù)體驗(yàn)上限”，這類(lèi)軟件才能真正留住付費(fèi)用戶(hù)的心。從概念上說(shuō)，一家愿意花大錢(qián)開(kāi)發(fā)高質(zhì)量原生 Mac 及 Windows 版本軟件的廠(chǎng)商應(yīng)該能夠在競(jìng)爭(zhēng)中壓倒 Electron 版的 Slack、Figma 以及 Spotify 才對(duì)，但為什么實(shí)際情況不是這樣呢？

協(xié)調(diào)成本的指數(shù)級(jí)增長(zhǎng)

在小型產(chǎn)品團(tuán)隊(duì)中，讓幾款原生應(yīng)用程序保持一致并不困難。在這樣的規(guī)模下，原生工具的用戶(hù)體驗(yàn)與便捷性完全碾壓跨平臺(tái)。但是，隨著產(chǎn)品及組織規(guī)模的快速發(fā)展，一致性開(kāi)始成為真正的難題。當(dāng)我們快速招聘新員工、快速添加客戶(hù)功能并逐漸需要為第三、第四乃至第五種平臺(tái)提供支持時(shí)，情況將越來(lái)越危急。1Password 的 Michael Fey 在開(kāi)發(fā)博文中做出了如下解釋?zhuān)?/p>

隨著時(shí)間推移，大大小小的不一致性元素開(kāi)始滲透到我們的應(yīng)用程序當(dāng)中。從平臺(tái)間密碼強(qiáng)度不同等小問(wèn)題到搜索結(jié)果差異、再到不同版本間完全不互通的功能配置，情況變得越來(lái)越糟糕。

這很重要，因?yàn)殡S著平臺(tái)之間功能、設(shè)計(jì)與 bug 的快速增加，對(duì)不同版本做出協(xié)調(diào)正逐漸變得不可能。

• 這項(xiàng)功能要何時(shí)在 Mac 上推出？

• 這份支持文檔符合 Web 用戶(hù)的情況嗎？

• 等等，這里的廣告內(nèi)容是指向哪個(gè)平臺(tái)的？

起初，企業(yè)還可以向銷(xiāo)售及支持團(tuán)隊(duì)提供資金支持來(lái)勉強(qiáng)維持統(tǒng)一，但隨著設(shè)計(jì)沖突的積累，更加危險(xiǎn)的問(wèn)題出現(xiàn)了：產(chǎn)品團(tuán)隊(duì)越來(lái)越難以理解自己打理的產(chǎn)品。最終，各個(gè)平臺(tái)團(tuán)隊(duì)已經(jīng)不在同一個(gè)頻道上，產(chǎn)品交流效率變低、密密麻麻的“路線(xiàn)”彼此交織、重要的細(xì)節(jié)慘遭忽略……

有些企業(yè)會(huì)始終堅(jiān)持客戶(hù)端應(yīng)用程序的精簡(jiǎn)化，也成功避免了這種命運(yùn)。只要能夠保持團(tuán)隊(duì)紀(jì)律、讓產(chǎn)品始終簡(jiǎn)單、不過(guò)度擴(kuò)張平臺(tái)、不快速提升團(tuán)隊(duì)規(guī)模，那么長(zhǎng)期保持同步并不是難事。這里的關(guān)鍵策略，就是盡可能把復(fù)雜性體現(xiàn)在服務(wù)器端，而客戶(hù)端應(yīng)用程序則盡可能“無(wú)腦”，這樣就不需要同時(shí)在多種客戶(hù)端上迭代大量邏輯。

但只要團(tuán)隊(duì)規(guī)模與產(chǎn)品復(fù)雜性持續(xù)提升，并且需要在好幾種平臺(tái)上維護(hù)大量功能，那其中的不一致性終將失控。

• 一位重要客戶(hù)很生氣，因?yàn)殇N(xiāo)售說(shuō)新版本提供一項(xiàng)功能，但在對(duì)方的實(shí)際平臺(tái)上根本找不到。

• 有人在 Twitter 上批評(píng)我們，說(shuō)我們的文檔內(nèi)容有誤；產(chǎn)品經(jīng)理進(jìn)行了深入研究，并發(fā)現(xiàn)這部分內(nèi)容只是不符合 Android 版本的情況。

• 我們無(wú)法測(cè)試有希望的新改進(jìn)，因?yàn)樾鹿δ鼙仨毻瑫r(shí)在所有平臺(tái)上運(yùn)行，而 Windows 團(tuán)隊(duì)的正常更新進(jìn)度已經(jīng)嚴(yán)重落后了。

• iOS 與 Android 產(chǎn)品團(tuán)隊(duì)之間的術(shù)語(yǔ)差異導(dǎo)致某個(gè)討厭的 bug 在 iOS 上存在了 5 個(gè)禮拜，混亂的溝通反而讓 Android 團(tuán)隊(duì)推出了一款沒(méi)啥作用的修復(fù)程序。

總之，事情變得一團(tuán)糟。

所以在具有一定規(guī)模的產(chǎn)品組織架構(gòu)之下，一致性與協(xié)調(diào)性絕不像嘴上說(shuō)說(shuō)那么簡(jiǎn)單。產(chǎn)品體系需要借助更多流程才能讓各平臺(tái)保持代碼庫(kù)同步，開(kāi)發(fā)者被迫將更多時(shí)間花在規(guī)程、說(shuō)明文檔與形式工作上。功能質(zhì)量雖然更高，但開(kāi)發(fā)進(jìn)度變得更慢。而這種強(qiáng)一致性保障，同時(shí)也代表著產(chǎn)品的更新迭代做不出太大的變化。

總而言之，要保持多個(gè)平臺(tái)上的代碼庫(kù)始終一致并非不可能，只是成本極高。我們需要雇用更多工程師來(lái)引入非零改進(jìn)，但協(xié)調(diào)工作的成本會(huì)呈指數(shù)級(jí)增長(zhǎng)（至少是超線(xiàn)性增長(zhǎng)），導(dǎo)致每位新員工帶來(lái)的額外產(chǎn)品開(kāi)發(fā)增速極為低下。

緩慢而低效，最終會(huì)令你輸?shù)舯荣?

對(duì)于產(chǎn)品開(kāi)發(fā)商來(lái)說(shuō)，緩慢是個(gè)致命的弱點(diǎn)。速度慢的產(chǎn)品團(tuán)隊(duì)往往會(huì)被行動(dòng)更快的對(duì)手所擊敗。我們經(jīng)常抱怨 Figma 和 Slack 之類(lèi)的產(chǎn)品給不了原生使用體驗(yàn)，但為什么大多數(shù)人仍在使用 Figma 與 Slack 這些？因?yàn)樗鼈兊膶?shí)際表現(xiàn)確實(shí)壓倒了原生競(jìng)爭(zhēng)對(duì)手。這些產(chǎn)品中當(dāng)然還有很多可以改進(jìn)的地方，但它們確實(shí)在自己設(shè)定的發(fā)展路線(xiàn)上做到了最好。

于是，跨平臺(tái)與原生工具之間的權(quán)衡就成了大規(guī)模協(xié)調(diào)工作中的重要組成部分。沒(méi)錯(cuò)，原生代碼特別擅長(zhǎng)構(gòu)建起出色的用戶(hù)界面，但如果大型產(chǎn)品團(tuán)隊(duì)與多種客戶(hù)端代碼庫(kù)會(huì)極大拖慢更新進(jìn)度，那么原生開(kāi)發(fā)方法本身就是在破壞用戶(hù)體驗(yàn)。

因此，我們得出一種非線(xiàn)性權(quán)衡，而不再是簡(jiǎn)單的“優(yōu)質(zhì)與便宜”之爭(zhēng)。誰(shuí)對(duì)跨平臺(tái)工具最感興趣？當(dāng)然是那些希望能在多個(gè)平臺(tái)上協(xié)調(diào)多種功能的團(tuán)隊(duì)，這意味著功能性的優(yōu)先級(jí)要高于原生使用體驗(yàn)。而在移動(dòng)平臺(tái)上，開(kāi)發(fā)團(tuán)隊(duì)通常不會(huì)貿(mào)然推出新功能、倒是愿意精心設(shè)計(jì)用戶(hù)體驗(yàn)并加以潤(rùn)色，所以移動(dòng)端開(kāi)發(fā)往往比桌面端更傾向原生方法。

當(dāng)然，我們也可以從多種跨平臺(tái)方案中做出選擇，盡可能把協(xié)調(diào)負(fù)擔(dān)降下去。不同于此次 1Password 投向 Electron 所引發(fā)的巨大批評(píng)，之前他們決定將所有應(yīng)用程序版本轉(zhuǎn)向共享 Rust 庫(kù)的決定就廣受歡迎。有趣的是，近年來(lái) Dropbox 及 Slack 等知名團(tuán)隊(duì)都發(fā)表過(guò)如何避免使用跨平臺(tái)核心庫(kù)來(lái)支持移動(dòng)應(yīng)用的文章——目前，雙方都在使用完全原生的 iOS 與 Android 代碼庫(kù)。就目前的情況看，市場(chǎng)似乎分成了兩大派別——一派宣布全面轉(zhuǎn)向 React Native，另一派則決定徹底放棄 React Native。這也是個(gè)有趣的話(huà)題，以后有機(jī)會(huì)再單獨(dú)討論。

總之，我們能做的就是認(rèn)真考慮不同技術(shù)善于解決哪些問(wèn)題，并對(duì)判斷保持足夠的警惕。我們會(huì)觀察技術(shù)的發(fā)展，與實(shí)際使用者交談，并了解團(tuán)隊(duì)分享的哪怕一點(diǎn)點(diǎn)經(jīng)驗(yàn)。只有這樣，我們才有機(jī)會(huì)認(rèn)清事實(shí)的全貌。

https://blog.1password.com/1password-8-the-story-so-far/

https://allenpike.com/2021/gravity-of-cross-platform-apps