Dropbox与C 的“七年之痒”难跨越 跨平台真的是伪命题吗？
“一次编写，处处运行” —— 简单来说就是跨平台。然而这个十分符合程序员思维，且承载着他们美好愿望的方案，在实际操作中往往不能如其所愿，甚至会适得其反。
Dropbox 工程师近日在其官方博客和大家分享了他们“弃暗投明”的经历 —— 放弃在其 iOS 和 Android 客户端之间共用同一套代码的策略，转而使用各自平台的原生语言进行开发。
工程师表示，Dropbox 在 2013 年开发 iOS 和 Android 平台的移动应用时，采用了通过 C 语言在两个平台之间共享同一套代码的策略。当时的想法十分简单，开发团队希望使用 C 编写一次代码即可，无需分别针对 iOS 和 Android 平台各使用 Objective-C 和 Java 编写两次代码。另外，当时负责移动应用开发的团队规模相对较小，为支持快速增长的移动应用，他们需要找到一种方法以通过这个小团队在 iOS 和 Android 平台上快速部署大量代码。
但现在 Dropbox 放弃了这个策略，转而使用各自平台的原生语言（主要是 Swift 和 Kotlin）。之所以做出这个决定，是因为在两个平台共用同一套代码的隐藏开销其实很高。他们从中总结到的经验就是：如果遵循广泛使用的平台默认标准，而不是以非标准方式编写代码，他们可以不用承担本应不必考虑的开销，这种开销最终比编写代码两次更昂贵。
Dropbox 工程师将这些隐藏开销归纳为四类，在介绍这些隐藏开销之前，工程师强调他们实际上从未达到大多数代码库均使用 C 开发的阶段，因为正是采用 C 带来的隐藏开销阻止了他们完全朝这个方向发展。
维护自研框架和库的开销
使用 C 首先面临的开销是需要自己构建框架和库，这大致分为 2 个子类别：
-
支持与主机环境交互以构建完整的移动应用程序的框架。例如：
-
用于在后台运行任务与主线程的框架（使用平台原生语言执行简单任务）
-
用于替代本可以在平台原生语言中使用的默认或者开源标准库。例如：
-
json11：用于 JSON 的 （反）序列化
-
nn：C 的非可空指针
Dropbox 工程师表示，如果采用平台原生语言，这些代码都不是必需的，而且他们对开源项目的贡献可能会使更多的开发者受益于平台原生语言。值得注意的是，上述的这些开销在 C 中尤其高（与其他非原生语言如 Python 和 C# 相比），因为它缺少单一的全功能标准库。话虽如此，C/C 是唯一包含受 Google 和 Apple 支持的编译器的语言，如果使用不同的语言会产生许多其他需要处理的问题。
维护自研开发环境的开销
移动生态系统有许多工具可帮助提升开发效率。其中用于移动开发的 IDE 也非常丰富，Google 和 Apple 为其投入了大量资源，让开发者在相应的平台上拥有最佳的开发体验。由于 Dropbox 没有使用平台的默认方案，他们自然无法享用这些便利。其中最值得注意的是调试体验，在平台的默认 IDE 中调试平台原生语言的体验通常优于调试 C 代码的体验。
Dropbox 工程师举了一个尤其令他们印象深刻的例子，在其后台线程框架中出现了导致应用程序随机崩溃的错误。为此他们使用了简单的标准堆栈，但是也难以定位这些类型的错误。因为这个问题涉及调试在 C 和 Java 之间来回运行的多线程代码，最终他们花费了几周的时间才定位了问题所在。
除了工具的缺失，工程师还需要花费时间构建支持共用同一套 C 代码的工具。最重要的是，他们需要一个自定义构建系统，该系统用于创建包含 C 代码以及封装 Java 和 Objective-C 代码的库，并且可以生成 Xcodebuild 和 Gradle 都能理解的对象。正是这个系统对 Dropbox 的资源造成巨大的拖累，因为它需要不断更新以支持两个构建系统的变更。
可以看到，大量的时间被耗费在造轮子 -
