Facebook iOS 应用的架构演变

2012年：从HTML5到原生应用

2012年，Facebook将其iOS应用从基于HTML5的跨平台实现重写为原生应用，以利用原生性能并提高可靠性和可用性。

Core Data 的可靠性问题

两年后，应用开始出现与Core Data相关的可靠性问题。Core Data模型本质上是可变的，这使得在多线程应用中难以使用，导致代码难以调试和重现错误。

2015年：引入ComponentKit

Facebook工程师引入了ComponentKit，这是一个受React启发的声明式框架，用于定义UI。ComponentKit使用不可变数据，简化了代码推理，并提供了50%的性能提升。ComponentKit在Facebook内部非常成功，至今仍是创建iOS UI的默认选择。

动态库（dylibs）的模块化

2015年，Facebook应用经历了“功能爆炸”，导致启动时间显著增加。为了解决这个问题，工程师使用动态库（dylibs）对代码库进行模块化，部分代码可以延迟加载，从而减少启动时需要执行的任务数量。

动态库的可靠性问题及解决方案

虽然动态库解决了启动时间问题，但引入了新的可靠性问题，主要是尝试访问未加载的动态库时可能出现的运行时错误。为了解决这个问题，Facebook工程师利用了Buck构建系统生成的构建图，并创建了一个插件系统，使得可以在构建时而非运行时检测依赖图相关的错误。

2020年：引入Swift

2020年，Facebook开始在移动应用中使用Swift，这是由于iOS SDK中出现了越来越多的Swift-only API。这一改变意味着从之前的通过某种包装访问SDK功能的策略转变为一个更为激进的策略。由于Swift和C++之间缺乏互操作性，解决方案是要求UI相关代码不包含任何C++代码，而C++仅用于基础设施代码。

总结

Facebook iOS应用的演变展示了一系列策略，这些策略有助于克服平台限制，并适应需求变化和底层平台的不断变化。如需了解更多细节，请参阅原文。