作者 | Sergio De Simone

译者 | 刘雅梦

策划 | 丁晓昀

脸书（Facebook）在 2012 年重写了其 iOS 应用程序，以利用原生性能，并提供了比以前基于 HTML5 跨平台实现更高的可靠性和可用性。脸书工程师 Dustin Shahidehpour 解释说，在重写后的十年里，应用程序代码库一直在不断发展，以适应新功能的引入，规避 SDK 限制，并跟上 iOS 平台的变化。

在原生重写的两年后，脸书的 iOS 应用程序开始出现与核心数据使用相关的可靠性问题。Shahidehpour 表示，核心数据模型本质上是可变的，这使得在多线程应用程序中使用它们变得很困难。

最终，这种设计加剧了不确定性代码的产生，这些代码很难调试或重现缺陷。很明显，这种架构是不可持续的，是时候重新思考它了。

脸书工程师随后实现了 ComponentKit，这是一个受 React 启发的声明性框架，用于定义 UI。ComponentKit 使用了不可变数据，这简化了代码的推理，并提供了比以前实现高 50% 的性能。ComponentKit 在脸书上取得了巨大的成功，它仍然是创建 iOS UI 的默认选择。

2015 年，脸书应用程序出现了 Shahidehpour 所描述的“特性爆炸”，其净效果是缩短了应用的发布时间，甚至可能导致应用程序被 iOS 杀死。这导致了使用动态库（dylib）对代码库进行模块化的努力，这样部分代码可以延迟加载，从而减少了在 main 之前执行的任务数量。

虽然动态库的采用解决了启动时间问题，但它引入了另一类可靠性问题，主要与尝试访问尚未加载的动态库中的某些代码时可能会出现运行时错误有关。为了解决这个问题，脸书工程师决定利用他们自己的构建系统 Buck 来生成的构建图。

每个“目标”都列出了构建它所需的所有信息（依赖项、编译器标志、源代码等），当调用“buck build”时，它会将所有这些信息构建成一个可以查询的图。

使用这些信息，该应用程序能够创建一个从类和函数到动态库的映射，然后自动生成代码，以确保在某些函数试图访问动态库时将其加载到内存中。

这进一步导致了一个插件系统的创建，它可以在构建时而不是在运行时检测依赖关系图相关的错误。

直到 2020 年，由于越来越多的 Swift 专用 API 出现在 iOS SDK 中，脸书才开始在他们的移动应用中使用 Swift。这与以前只通过某种包装器访问 SDK 功能的立场截然不同。虽然是出于提高开发人员效率的目标，但由于 Swift 和 C++ 之间缺乏互操作性，这种方法变得更加复杂了。解决方案是要求与 UI 相关的代码不包含任何 C++，这样工程师就可以使用苹果当前和未来的 Swift API，而为基础设施代码保留 C++。

总体而言，脸书 iOS 应用程序的发展表明，有许多策略可以帮助克服平台限制，并适应需求和基础平台不断变化的本质。如果你对完整的细节感兴趣，请不要错过原文。

原文链接：

/

科大讯飞回应用“绩效回溯”变相降薪；OpenAI逆天开放API，价格打骨折；推特裁员超70%，马斯克给剩下员工“画饼”？｜Q资讯

直接到云上做开发？先等等，这个方案还“半生不熟”

“干净”的代码，贼差的性能

一场向应用交付标准的“冲锋”