跨平台应用即将死亡！
共 6024字，需浏览 13分钟
·
2020-12-17 00:38
点击“开发者技术前线”，选择“星标?”
让一部分开发者看到未来
2015 年时，我是一名自由职业的原生 iOS 开发者。我知道 Objective C——这是唯一我睡着都能写的语言。Swift 还在努力解决 ABI 兼容性问题，而我还在观望。
当我决定重新进入就业市场时，每个人都想要 React Native。
我是这个领域的新手。每个工程博客，主要 包括 Airbnb，都在鼓吹“一次编写，随处发布”的优势。我的朋友们建议我转向跨平台，或者立即退休。
如果有人给我提供机会，相信我在 Windows + iOS 领域的工程技能，我可以在工作中学习原生安卓。
但是我犹豫要不要学习 RN。LinkedIn 在 2013 年放弃了其基于 HTML5 的 跨平台 app，这在我的脑海中记忆犹新。尽管 React Native 在执行时是完全原生的，但是它没有像 Objective C 或 Java 那样暴露出原生的感觉。
我的犹豫很快得到了验证：
我读到了相关新闻，RN 的创造者 Facebook——宣布将其 iOS 主页（新闻流）切换到 Kit 组件——一个基于 Objective C++ 创建的框架。他们大量借用了 React 的声明式方案，但是 用 Objective C++ 实现了所有东西 来利用 iOS 架构的真正力量——甚至 Swift 现在还无法提供。
图片来源:Reddit
现在大部分经常使用的应用程序依赖 C++ 或它的一些变种（对于安卓是 JNI，对于 iOS 是 Objective C++）。
快进到 2020 年。
Airbnb 早在 2019 年就 放弃了继续使用 RN。这在工程界引起了足够的轰动，迫使人们重新思考。在 2019 年的同一年，苹果发布了 SwiftUI，一个声明式的 UI 框架，旨在再次吸引新手开发者度过其 Swift 灾难（尽管现在已经稳定了）。
跨平台的应用程序有其固有缺陷。随着市场的不断变化，现在市场已经成熟，它们要么改进要么消亡。
这是 公开的秘密，从未变过。尽管安卓的市场份额很大，但在应用程序收入方面，它远远落后于苹果。这不仅仅是因为安卓在世界的低收入地区处于领先地位，还因为安卓的核心业务是授权，而不是硬件制造。
因此，iOS + iDevice 的更新更符合其高付费用户的需求。
尽管非苹果制造商引领了许多智能手机创新。
由于苹果对操作系统和硬件的控制更严格，苹果在提供卓越 + 个性化的体验方面做得更好，而这也是高价值用户在移动设备上的追求。
由于苹果最新致力于成为一个以隐私为中心的软件生态系统，显而易见，苹果将继续在企业移动解决方案领域占据主导地位。
对于开发者来说，苹果和安卓之间的收入分成非常简单：
苹果开发 =>高价值付费用户 =>应用程序销售收入
安卓开发 =>低价值用户 =>广告收入
苹果最近强制应用程序请求用户权限来分享广告数据。这对于那些以广告数据为唯一资产的公司来说是一个直接的打击——特别是 Facebook 和谷歌。
而 Facebook 和谷歌碰巧是 React Native 和 Flutter 的创造者，这应该不是个巧合。
你很容易看到这对于 App 开发者来说意味着什么：进一步搞明白你的理想的用户基础。尽早做出选择，并选择你相应的工具集。
例如，如果你不想做广告，你最好先开发苹果应用。经过验证后，再开发安卓应用。这种比较零碎的方案几乎没有动力来进行跨平台开发。只要团队保持不变，通用代码库需求很容易得到满足。
除非某家颠覆性的硬件公司从黑暗中走出来。
谷歌是一个规模相当大的挑战者，但并不可怕。它在移动领域的主要目的不是销售软件，而是掌握用户数据。如果不在硬件上取胜，正如 它所公开承认的那样，谷歌很难打破这种平衡。安卓的采用直接取决于它许可的硬件制造商。
有了 Apple Silicon，苹果就整合了它的开发者社区。它已经向开发者支付了更多。现在有了 Apple Silicon，iOS 开发者可以轻松迁移到新的苹果 Mac 上。
这一举措使得 开发苹果应用更有利可图，使用它自己的工具：XCode、Playground 等等，使用 Apple Silicon 驱动的 Mac 电脑，因为它可以完全控制它的硬件。有更明确的动机让所有人都投入到一个平台上，至少在最初是这样，而且没有开发者或创业公司会错过这个优势。
这是一种渐进性改进，告诉垄断者：
现在，我挑战你进行创新。我不能做一个更好的 IDE 或硬件，但是我可以剥夺你从中获取的一些收益或开发者。
一次又一次，跨平台工具将自己作为解决每个与平台相关的问题的灵丹妙药。
如果没有底层硬件，它们会成为垄断者的挑战者，因为垄断企业有很高的进入成本壁垒。Mac 机器 vs windows 机器的成本是被引用最多的标准。
它们迅速被采用的另一个原因，不是它们有能力创造更好的体验，而是开发者对专有平台的不满。
每个超过千万美元的初创公司都会雇佣一名移动开发人员来维护一个最终依赖于远程 GitHub 贡献者支持的代码库
它们可以是开源的。快速入门项目、Youtube 教程和价值 100 美元的模板充斥在开发人员的信息流中，但几乎很难找到依据：
跨平台 App 可以实现的东西用原生并不容易实现！（5 行代码 vs 3 个类！）。不要看原生提供的定制可能性 vs 5 行代码的底层机制。
它提供了 通用业务逻辑 的独特优势——这是任何初创公司都无法抗拒的。最后，每个 千万美元 的初创公司都会雇佣一名移动开发人员来维护一个最终依赖于 GitHub 贡献者支持的通用代码库。这些公司没有意识到的是，通用业务逻辑必须通过清晰的文档（嗯？那是什么）和简洁的规范（但我们是敏捷开发！）维护。
幸运的是，如果这些初创公司能够超过一个收入点，如果出现开发人员流失，增长策略就会介入，在 app store/play store 上排名退步 + 投资人的压力会促使创始人重新考虑他们最初追求快速但杂乱的解决方案的决定。这也解释了 LinkedIn、Facebook iOS 版、Airbnb 以及其它无数应用后期采用原生方案的原因。
然而，初露头角的创业公司数量从未减少，跨平台开发人员的市场也从未枯竭。反抗精神万岁！但现实是这样的：如果你知道 C++（或 Objective C 及其变种）或者 Java，你的技能将在几十年后还不落伍。如果你用一个奇特的跨平台开源工具集来修饰你的简历，那就要准备好每 3-5 年做一次彻底的调整。
它们被开发是为了发布，而不是维护。
在跨平台应用中，困惑不断。
如今的跨平台产品能够提供几乎 100% 的原生代码——这一点毫无疑问。Xamarin、React Native 和 Flutter——都承诺 100% 原生执行。
它们不同于以往运行在浏览器上和基于 HTML5 的 PWA 应用。
但在设计上，它与每一个代码组织原则都相反。它们由 500 多个从完全不同的不受监控的源代码（而不是本地库）下载的包组成，模仿了 Web 开发方法。在移动开发中采用这种方法——其源代码被视为公开的，而不是在由开发人员控制的服务器的边界内，人们可以想象其风险。
跨平台工具很容易被采用，因为它们提供了初学者更容易理解的更高级别的抽象。它们融合了不同底层原生 API 之间的差异。它们采用了最常用的功能，其余的定制工作留给了开发人员。
设想一个假设的 函数 F 在原生 iOS 和安卓中有如下实现：
iOS: function f (int a, int b, int c)
Android: function f (int a, int b, int p, int q, int r)
一个典型的跨平台包会提供如下函数：
function f (int a, int b)
如果你想要充分利用这两个功能，你必须在原生代码（即 Objective C 和 Java）中找出 c、p、q 和 r 的调整。
在我的上一个组织中，由于现有的 Flutter 通知包的缺点，开发人员必须在以下方面进行开发：
Dart
iOS 插件
安卓插件
因为 Flutter 开发人员只熟悉 XCode 或 Android Studio，并不精通 Objective C 或 Kotlin API，所以这被认为是一个缺陷。
大部分跨平台爱好者都是大学生，他们在图书馆中创建了他们的第一个软件，不能忘记他们的“初恋”。他们构建跨平台 App 是用来发布，而不是维护。
但当你被迫下载一个包来实现一个简单的功能，例如 设备信息，真正的痛苦就开始了。
大部分跨平台爱好者都是大学生，他们在图书馆中创建了他们的第一个软件，不能忘记他们的“初恋”。
平均而言，虽然一个移动应用开发人员开发一个单一代码库只节省了 20% 时间（而不是 50%，因为需求转化 + 定制化），包管理占用了维护者 70% 多的时间。
一个 React Native 应用程序被一些 非常严重的功能 + 性能相关问题 困扰，这些问题会在开发周期的后期被发现。
相比于原生开发者的 IPA 和 APK，一个典型的 flutter app 的尺寸要大得多。
在我的上一个组织中，我修改了 70 多个文件，来处理 Flutter 的 Equatable 实现的兼容性中断。
这并不痛苦，直到我了解了其背后的原因：早期的哈希算法对于一个对象内属性值的交换产生相同的哈希值！
换句话说，以下对象将在旧的有缺陷的实现中产生相同的哈希值，除非你显式地重写 Equatable 哈希函数，在 1.0 之前，这从不是一个强制要求！
对象 A:
x = 3, y = 4
对象 B:
x = 4, y = 3
想象一下，检查所有 500 多个包是否存在 equality 检查漏洞...?
我问我的架构师，为什么像我们这样的数据密集型应用程序首先采用了 Flutter。
他的回答非常经典：
“管理人员常说：敏捷的目标之一，就是避免无价值的操作，例如文档。通用代码库就是我们的文档和唯一信源。”
这个问题不是跨平台固有的。但这个问题通过开源共享与跨平台紧紧绑定在了一起。
库所有人具有不可思议的权力
这个问题的存在有两个原因。
首先，GitHub（和它的竞品）是未评级的，但要对国家法律负责。它可以在任何时候通过合法的改组来 摧毁任何东西。
其次，库所有人对于贡献者的工作具有不可思议的权力，无论这个库有多大。
库所有者的暴政 已经在区块链领域臭名昭著，创始贡献者在制定链币发行规则方面占据上风。
所有头部公司（包括 FAAMG）都已经在利用开源，来使他们的 SDK 可以被获取 + 对 bug 修复开放。公司雇佣开发者来维护社区意识，关注开发者的兴趣，并根据大众需求来发布特性。
如果他们不这么做，他们的核心产品就会受损。
对于跨平台供应商则不是这样。事实上，他们对严重的 bugs 或关键的增强请求没有任何反映。因此，错误处理 GitHub 问题不会对他们造成任何后果。
如果 Flutter 有严重的 bugs，谷歌在已经微不足道的 Pixel 销量或庞大的搜索流量方面不会有任何减少。
如果 React Native 缺少一个功能，Facebook 的广告收入不会缩减。
但是，如果 Android/Kotlin 或 iOS/Swift 有严重的漏洞，谷歌和苹果肯定会遭受损失——谷歌在授权收入方面受损，苹果在 iPhone 销量方面受损。开发者会削减 30% 收入。
因此，与那些在午夜发布修补程序的原生平台所有者不同，跨平台开发者对开发人员的请求置若罔闻。
稍好点的回应者会对问题写一个正式的回应，并单方面关闭它们，而不进行后续处理。在没有适当文档的情况下，开发人员的唯一办法就是深入研究包 / 库代码，修复问题，然后发布他们的应用程序。
有时，他们被库开发者诱导回馈，而这也没有任何激励措施，这一切都是基于开源精神。
对于一个被承诺了高效跨平台实现的开发者来说，这是 2 个缺点：花在 bug 上的时间更多 + 特性请求是开源的。
但还有更糟糕的。
雪上加霜的是，他们的 PR 有时候会被库所有者拒绝或忽视，理由是为了保证他们的记录簿干净。
除非高薪的跨平台库所有者平等对待他们的低薪同行创新者，否则情况只会恶化。
随着有经验的开发人员转向更好的平台原生的解决方案，跨平台项目注定会是一个伪装成创新的巨大渐进改动。
跨平台开发将很快意味着对于多种设备的单平台开发
在所有的移动开发厂商中，苹果是唯一一家真正的业务线是硬件的公司。随着他们平台的统一，它向开发者发出了一个明确的信息：你对我们的服务业务至关重要，我们关心你们的增长。
现在预测其长期市场主导地位还为时过早。谷歌有足够的财力来为其原生安卓平台提供燃料，使其对开发者更有吸引力。
虽然单靠苹果无法撼动整个跨平台社区，但它肯定能够迫使其竞争对手采用一种更结构化更易于维护且更不易出现故障的移动开发方案。
跨平台开发领域将很快意味着对多种设备的单平台开发，就像.NET 早期那样。
创业公司最好不要跨平台。公共代码库的诱惑必须被良好的老文档取代，这样才能在开发人员心中培养真正的通用商业逻辑。
你的客户值得原生平台提供的最佳统一体验。
你的开发者？休息（不是双关语） + 尊敬。
Pen Magnet 创业作家、程序员、科技职业博主、教育爱好者。
https://medium.com/swlh/the-end-of-cross-platform-as-we-know-it-dad658d96b8
END 前线推出学习交流群，加群一定要备注： 研究/工作方向+地点+学校/公司+昵称（如前端+上海+上交+可可） 根据格式备注，可更快被通过且邀请进群，领取一份专属学习礼包
扫码加我微信进群，内推和技术交流，大佬们零距离
历史推荐
网易云音乐的消息队列改造，到底做了啥？ 5个常用的大数据可视化分析工具 VS Code竟然能约会谈恋爱，找对象不看脸，主要看编程水平 为什么 Google 的技术这么牛？ 好文点个在看吧！
