直到最近，Dropbox才制定了一项技术策略，以便为iOS和Android移动应用程序使用通用的C ++代码。 这个想法很明确：用C ++编写一次代码，而不是用Java和Objective C分别复制代码。我们在2013年采用了这一策略，当时移动开发工程师团队规模相对较小，必须快速开发产品。 这种解决方案允许一小队的力量在Android和iOS上生成大量代码。
现在，我们已经完全放弃了该策略，转而使用每个平台的本地语言（主要是Swift和Kotlin，这在我们开始时并不存在）。 该解决方案涉及（并非如此）隐藏的代码共享成本。
所有问题都源于最主要的
问题 ：
开销不仅仅是将代码编写两次而已 。
在分析各种类型的开销之前，我想澄清一下，我们从来没有达到大多数代码库都是C ++的地步。 成本实际上阻止了我们朝这个方向发展。
还值得注意的是，像Google和Facebook这样的大型公司已经开发了可扩展的代码共享解决方案已有几年了。 这种解决方案不是很常见。 尽管像React Native或Flutter这样的第三方系统避免了一些开销，但仍然存在一些成本（至少直到其中一项技术变得流行和足够成熟为止）。 例如，
Airbnb出于与本文概述的许多相同原因而
拒绝使用React Native 。
所有成本可以分为四个主要类别。
自定义框架和库的开销
预测创建框架和库的成本的最简单方法。 它们大致分为两个子类别：
- 允许您与主机环境进行交互以创建功能完善的移动应用程序的框架。 例如：
- Djinni ，用于创建连接类型和接口的中间语言声明的工具
- 一个在后台针对主线程执行任务的框架（主要使用平台的本地语言）
- 图书馆，以取代可能用于本国语言的语言标准或开源解决方案，例如：
如果您使用该平台的本地语言，则无需这样做。 而且我们以母语参与开源项目可能对开发人员更有利。 在C ++社区中，开源文化是（并且是吗？）不如在移动开发者社区中那样发达，更是如此，因为C ++
移动社区实际上不存在。
请注意，对于C ++，这些开销特别高（与其他可能的非本机语言，例如Python或C＃）不同，因为没有一个功能齐全的标准库。 但是，只有C / C ++具有Google和Apple支持的编译器，因此切换到另一种语言会引起许多其他问题。
大型定制开发环境
移动生态系统中有许多工具可以提高开发效率。 移动IDE的功能非常强大，Google和Apple已投入大量资源，使其在平台上非常理想。 摆脱默认设置，我们放弃了一些优势。 首先，默认情况下，本机语言调试通常胜过IDE中的C ++调试。
我特别记得一个错误，该错误导致后台流结构的阻塞，从而导致应用程序意外崩溃。 即使使用简单的标准堆栈，也很难跟踪此类错误。 由于问题涉及调试在C ++和Java之间运行的多线程代码，因此跟踪花费了数周！
除了失去标准工具外，我还不得不花时间创建自己的工具来支持常见的C ++代码。 最重要的是，需要自定义构建系统来创建包含C ++代码以及Java和Objective-C Shell的库。 它应该生成Xcodebuild和Gradle都可以理解的目标。 创建这样的系统需要花费大量资源，因为必须不断对其进行更新以支持两个构建系统中的更改。
针对平台差异的平台替代
尽管iOS和Android是通常提供相同功能的“移动应用程序”，但平台本身仍有一些差异会影响实施。 例如，应用程序如何执行后台任务。 甚至相似的事物也会随着时间的流逝而开始大相径庭（例如，与相机进行交互）。
结果，您不能只编写一次代码并在另一个平台上运行它。 您需要花费大量时间为特定平台进行集成和编码，有时此代码恰好在C ++级别结束！
仅编写一次代码所节省的理论成本并不符合实际情况，这立即大大降低了这种方法的有效性。招聘，培训和留住开发人员的开销
最后但并非最不重要的是，培训和/或雇用开发人员使用我们非常特殊的堆栈的成本。 当Dropbox开始使用这种移动策略时，我们拥有一批经验丰富的C ++开发人员。 该小组启动了C ++项目，并培训了其他移动开发人员。
随着时间的流逝，这些开发人员去了其他团队和其他公司。 剩下的人没有足够的经验来填补技术领导者的空白，找到具有相关C ++经验并对移动设备开发感兴趣的经验丰富的工程师变得越来越困难。
结果，我们真正缺乏维护C ++代码库的关键知识。 仅剩下两个选择，每个选择都需要大量的努力：
- 查找和聘用具有非常特定技能的候选人（我们尝试了一年未成功）。
- 对您自己的移动（或C ++）开发人员进行培训，如果没有具有正确技能的老年人来完成培训，这几乎是不可能的。 即使主要人群尚未分散，移动开发人员通常也不会对C ++感兴趣，因此寻找人来学习也是一个大问题。
除了雇用外，其自己的技术堆栈的发布还造成了保留问题-移动开发人员根本不想在C ++项目上工作。 这导致许多有才华的工程师离开项目，而不是继续遭受维护不善的自定义堆栈的困扰。 通常，移动开发人员社区是非常动态的-新技术和模型经常出现并且正在快速实施。 顶级工程师喜欢保持最新技能。
具有标准堆栈的成熟产品很难保持最新状态。 您为了稳定而牺牲了新颖性。 如果您将自己锁定在更广泛的移动生态系统之外的自定义堆栈中，则此问题会大大增加。
结论
有一次，为不同的平台编写一次代码似乎是一件大事，但与此相关的成本却超过了它的优势（无论如何都比预期的要少）。 最后，我们不再通过C ++（或任何其他非标准方式）使用通用代码库，而是为每种平台使用本机语言编写代码。
另外，我们希望我们的工程师感觉良好并能够为社区做出贡献。 这就是为什么我们决定使我们的做法与行业标准保持一致的原因。