校对 | Tina、原子武器果汁
虚拟化合作开发更昂贵，原生植物合作开发更高质量？做为世界上最畅销的公钥命令行，1Password 舍弃了 15 年来仍旧秉持的原生植物合作Attichy，转为了 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
今日好文推荐那个曾领先于谷歌和微软的开源工程项目，为何盛极而衰？年轻人逃离算法围城：老年版App，用着真香光明日报：“996”是互联网行业用工史上的一段弯路；Apache Doris谴责DorisDB违背开源精神 | Q资讯Amazon Elasticsearch Service正式更名，云厂商和开源街道社区间必有一战？ 活动推荐有人说，Serverless 是未来。Serverless 正在改变未来软件合作开发的模式和流程，借助 Serverless 服务，企业和合作开发者可以将更多精力投入在业务逻辑的合作开发整合上，大大缩短合作开发周期。针对一些典型场景，9 月 24 日，华为应用领域市场 AppGallery Connect 合作开发者沙龙·武汉站将为你详细讲解。另外沙龙
