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

Djinni ，一种用于生成跨语言类型声明和接口绑定的工具。

负责在后台运行任务与主线程（用平台原生语言执行的简单任务）的框架。

2. 库：替换我们本可以在平台原生语言中使用的语言默认开源标准的库。例如：

json11 ，实现JSON（de）序列化。

nn ， C++的非可空指针。

如果我们坚持使用平台原生语言，那么这些代码都没有必要，而且我们为开源项目贡献的代码也可以让更多使用平台原生语言的开发人员受益。虽然我们可以利用开源的C++代码库，但C++开发社区的开源文化并不如移动开发社区那般强大（特别是移动开发社区中没有C++移动社区）。请注意，这些成本在C++中特别高（与Python或C#等其他非原生语言相比），因为它缺少单一全面的标准库。尽管如此， C / C++是谷歌和苹果唯一支持的带编译器的语言，因此使用其他语言会面临更多其他需要处理的问题。自定义开发环境的开销移动生态系统有许多可以提高开发效率的工具。移动的IDE非常丰富，谷歌和苹果为提高各自平台上的开发体验投入了大量资源。由于我们没有采用默认的平台原生语言，所以无法享受这些好处。最值得注意的是，平台原生语言的调试体验通常都远胜于在平台默认的IDE中调试C++代码的体验。有一个令我特别难忘的例子，有一次引发后台线程框架死锁的某个bug导致我们的应用频频崩溃。即使在简单的标准技术栈中，你也很难确定这类的bug 。因为这个问题需要调试在C ++和Java之间反复切换的多线程代码，所以我们花费了数周时间才修复！除了丧失了一大批工具之外，我们还需要花时间构建支持C++代码共享的工具。最重要的是，我们需要一个自定义的构建系统，其中包含打包C ++代码以及Java和Objective-C的库，还需要生成Xcodebuild和Gradle都能理解的构建目标。这个系统占用了我们的大量资源，因为它需要不断的更新，才能支持两个构建系统的变动。解决平台之间差异的开销虽说iOS和Android应用都是“移动应用” ，而且二者通常都具备相同的特性和功能，但平台本身确实存在一些影响实现的差异。例如，应用在每个平台上执行后台任务的方式是不同的。即便我们采用了这种跨平台式策略，虽然刚开始还有点相似，可随着时间的推移差异也逐步拉大（例如，与相机相册的交互等）。因此，实际上“只需编写一次代码就可以在不同平台上开箱即用”的说法只是一个传说。最终为了将代码集成到不同的平台上，你依然需要花费大量时间编写特定于平台的代码（而且有时你需要改动C++层的代码！）。因此，只需编写一次代码只是一个永远无法兑现的美梦，这种做法并没有太大益处。培训、招聘和留住开发人员的开销最后，虽然这不是最重要的因素，但培训和/或雇用开发人员在我们自定义的技术栈上工作也有一定的成本。当初采用这种移动策略时，我们拥有一批经验丰富的C++开发人员。该小组负责启用了这个C++项目，并为Dropbox培训其他移动开发人员。过了一段时间后，这些开发人员逐步跳转到了其他团队和其他公司。留下的工程师没有足够的经验挑起技术领导的大梁，而且招聘具备C++经验且对移动开发感兴趣的高级工程师也越来越难。最终，我们深陷缺乏维护C++代码库的关键专业知识的困境。重获这种专业知识的唯一方法是投资如下其中一个方向：招聘具备这种特定技术力的工程师（我们尝试了一年多，却无果而终）。培训内部的移动（或C++）工程师，然而如果你没有具备这些技术力的人员来做培训，这种方法也行不通。此外，早在核心小组的人员发生变动之前，大多数移动工程师就对学习C++失去了感兴趣，因此找不到培训对象也是一个大问题。在招聘问题之上，维持我们的技术栈面临人员去留的问题，因为移动开发人员根本不想掺和C++的项目。这导致许多有才华的移动工程师都离开了这个项目，最后自定义技术栈的维护工作陷入了举步维艰。总的来说，移动开发社区的发展日新月异，新技术和模式频频出现，且被迅速采用。优秀的开发人员都希望尝试最新的技术。在拥有标准技术栈的成熟产品环境中，跟上最新技术和产品的步伐是一项很大的挑战。有时，为了保持稳定，你不得不牺牲采用新技术的速度。如果你将自己封闭到某个自定义技术栈中，远离移动生态系统的花花世界，那么这种挑战的难度会急剧上升。总结虽然“只需编写一次代码”的说法听起来性价比很高，但实际的额外开销会导致这种做法得不偿失（并让你大失所望）。最终，我们放弃利用C++（或任何非标准的方式）共享移动代码，转而使用平台原生的语言编写代码。另外，我们也希望我们的工程师享受快乐的工作时光，并为回馈社区做贡献。这也是我们决定向行业标准看齐的原因。网友说对于这样一套代码两端运行的成本的计算与使用，网友也纷纷发表了自己的看法：评论1：我不明白像Dropbox这种规模的公司明明完全可以采用平台原生语言，为什么还要利用C++开发移动应用。话说回来，我们公司有一个非常老的ERP系统，我们需要开发一些移动应用。当时我们的团队中只有7个人，却有很多项目需要维护，再加上考虑到共享代码的成本以及我们对C#的熟悉程度后，我们选择了Xamarin 。这绝对是一个折衷方案，但也不失为一种务实的选择。如果你有能力雇佣Java或Obj-C的开发人员，而且要求他们承担起移动开发的工作，那么就应该考虑使用平台的原生语言。但是，如果你是一家小公司，且拥有Java和C#的开发，同时Obj-C和C#开发人员的招聘有难度，那么就可以考虑Xamarin或其他跨平台共享代码。总结起来就是，根据自身的实际情况而定。评论2：经过多年的反复验证后，我也得出了相同的结论。在两个移动平台之间共享任何定制的业务逻辑（模型、控制器等）并不明智。如果你有一些非常棘手的低级算法或库，或者你需要考虑到速度、数据库、加密，丰富的图形等，那么可以尝试利用C ++或其他语言共享模块。除此之外，即便是谷歌和苹果尝试利用CRUD应用来实现高效的代码共享，最后也无果而终。对此，你怎么看？本文为CSDN翻译，转载请注明来源出处。