一套代码两端运行不靠谱？是时候放弃 C++ 跨 Android、iOS 端开发！( 三 )_「Writeonce

以下为译文： Dropbox一直有一个共享移动设备上的iOS和Android代码的策略：使用C++语言编写。这种策略背后的想法很简单：利用C++编写一次代码就够了，否则就需要用Java和Objective C写两次。我们于2013年开始采用这种C++的策略，当时我们的移动工程团队规模相对较小，而且需要支持快速增长的移动发展蓝图。我们需要找到一种方法，让这个小团队快速发布大量iOS和Android代码。直到最近，我们才决定完全摒弃这种策略，转而使用每个平台的原生语言（主要是Swift和Kotlin ，我们刚开始做移动开发的时候这些语言还没有出现）。做这个决定的原因关系到代码共享相关的隐形成本。我将在本文中分享我们公司在有效共享代码方面得到的经验教训。其实，所有这些都源自同一个基本问题：如果以非标准的方式编写代码，我们就需要承担额外的开销（如果采用广泛使用的平台就没有这种担心）。结果却发现，这种额外的开销超过了写两次代码的代价。在深入介绍我们遭遇的所有不同的额外开销之前，我想先澄清一下，实际上我们之前的目标（即大多数代码都用C++开发）从未实现。采用C++引发的额外开销导致我们无法完全朝着这个方向迈进。请注意，多年以来谷歌和Facebook等大公司一直在开发可扩展的代码共享解决方案。然而，迄今为止这些解决方案的采用范围依然很有限。虽然你可以利用React Native或Flutter等第三方代码共享解决方案，来避免本文描述的部分额外开销，但仍有一些开销避无可避，至少在其中一项技术发展成熟之前我们依然需要承担这些额外的开销。例如， Airbnb也因为本文中描述的许多原因，而不再使用React Native 。我们可以将我们遭遇的额外开销大致分为如下四类：自定义框架和库的开销采用C++时最显而易见的开销就是构建框架和库。而这又包含两个方面： 1. 框架：通过与主机环境的交互构建完整的移动应用的框架。例如：