Dropbox 最近宣布将放弃用 C++ 编写跨 iOS、Android 平台代码,转而使用各平台的原生框架(Swift/Kotlin),理由是代码共享相关的隐藏成本太高。有趣的是,2014 年,Dropbox 在给 Facebook 的开发人员做分享时,却曾直言写两套代码会带来种种弊端,推荐使用 C++ 进行跨平台开发。为什么几年前的经验之谈却成了几年后的技术债?C++ 因何躺枪?跨平台开发前景如何?本文试图一一为你讲解。
事件综述
编写一次,随处运行。这句话不知道被多少工具和框架写在开篇介绍中,用以吸引更多公司和开发者。然而,作为这一策略忠实的实践者,Dropbox 近日宣布放弃这一想法,宁愿为不同的平台写两遍代码,也不用C++ 跨iOS、Android 两大平台共享代码的方式进行开发。
早在 2013 年,Dropbox 就采用上述策略进行移动开发,这背后的想法很简单:用C++ 编写一次代码,而不是用Java 和Objective-C 编写两次。那时,整个移动工程团队相对还比较小,但需要支持快速增长的移动路线图。因此,公司希望找到一种方法,使这个小团队可以快速交付大量 Android 和iOS 代码。
如今,Dropbox 完全放弃了这个策略,转而使用各个平台的原生语言(主要是Swift 和Kotlin,这两种语言在刚开始制定移动策略时还不存在)。这个决定的主要原因是代码共享相关的隐藏成本太高,这源于同一个基本问题:
以非标准的方式编写代码,使Dropbox 承担了一些开销,而如果采用广泛使用的平台默认选项,就不必担心这些开销,这种开销最终比只编写两次代码要昂贵得多。
C++ 的问题?
随后,Dropbox 总结了成本太过高昂的主要原因,比如自定义框架和库的开销、自定义开发环境的开销、处理不同平台差异的开销以及培训、招聘和留住开发人员的开销,这与 C++ 本身存在的问题密切相关。但是,C/C++ 是唯一一种编译器同时受到谷歌和苹果支持的语言,如果使用其他语言将会产生一系列更麻烦的问题。
1、自定义框架和库的开销
关于使用 C++,最容易出现的开销就是构建框架和库,这大致可以分为两类:
框架,让开发者与主机环境交互,构建一个功能齐全的移动应用程序。例如 Djinni 、用于在后台和主线程中运行任务的框架