Facebook iOS 新版开发手记：两倍速度的背后
Facebook上周发布了新版iOS应用，号称速度提升两倍。Facebook工程师Jonathan Dan在Facebook官方页面中撰文，介绍了新版iOS应用、Facebook iOS应用的发展历程以及开发思路。《创事记》特选取此文编译，供移动应用开发者参考。
我们今天(编者注：8月23日)发布了新版iOS应用，速度更快、更可靠、更易用。这款新应用标志着Facebook移动产品开发方式的转型，即深耕不同平台。为了便于你们理解这一转型，让我们回顾移动版Facebook的发展历程。
起步阶段的Three20框架：技术过时首次弃用
早期的iPhone版Facebook诞生于iPhone的起步阶段，当时还没有iPad，而系统也不叫iOS。在早期版本中，我们开发了名为Three20的开源框架，其中包括当时系统尚未提供的组件库。
在随后几年中，Three20成为iOS社区最流行的开源项目之一，帮我们解决了很多问题。然而随着技术的发展，Three20逐渐显得过时。 其功能越来越复杂，对入门者来说上手变难。另一方面，随着iOS核心的迅速发展，Three20的一些功能也显得没有太大用途。因此，最新版iOS应用是 我们这么多年来首次没有使用Three20框架。
HTML5的发展：跨平台快速迭代
随着过去几年移动设备的发展，我们最需要解决的问题是，无论你用什么设备、平台、运营商网络，甚至无论你在哪里，都应当获得不错的移动体验。为了支持数千款手机和多个移动平台，我们利用HTML5技术去开发移动版Facebook，并向包括iOS在内的多个平台发布。
利用HTML5，我们只要进行一次开发，就可以向多个平台发布产品。这样做使我们能覆盖尽可能多的用户，也使Facebook移动业务发展到了 当前的规模。实际上，我们选择HTML5不仅是因为可以跨平台使用一套代码，也是由于这样做有利于快速迭代，在不发布新版本的情况下测试新功能。
基于这一网页技术，我们为5亿Facebook移动用户提供服务，并支持了7000多款设备。然而我们意识到，对iOS这样的平台来说，人们会 希望更快、更可靠的体验，而这正是我们iOS应用的不足之处。我们已经普及了移动服务，现在需要深耕服务。因此，我们从头开始重写了Facebook的 iOS应用，专注于质量，并充分利用iOS系统自身这些年来的发展。
一切为了速度：耗时任务扔后台
开发原生iOS应用带来了一个显而易见的好处，就是应用的速度。在新版iOS应用中，动态汇总的滚动明显更流畅，而具体实现方式则是对处理任务 的系统资源进行更好的调度。例如在iOS中，主线程驱动用户界面，处理触控事件，因此如果在主线程中处理太多任务，那么应用就会变慢。为了解决这一问题， 我们尽量在后台处理对计算资源要求较高的任务，包括所有网络活动、JSON分析、NSManagedObject对象创建以及存盘等。
可以再举另一个例子。我们使用Core Text显示字符串，但排版计算很快成为一个瓶颈。在新版iOS应用中，当我们下载新内容时，我们以异步方式计算字符串大小，缓存在CTFramesetters中，当需要在UITableView中显示时再利用这些计算结果。
在iOS中启动Facebook应用时，你会想看见动态汇总，而不是正在加载的下拉列表。因此，为了提供最好的体验，我们在应用启动时立即显示 此前缓存的内容。不过这带来了新问题：如果你的动态汇总中内容太多，那么UITableView将调用一个委托函数 tableView:heightForRowAtIndexPath:，对每条内容进行处理，以计算滚动条长度。这将导致应用需要从磁盘中加载所有内 容，对整个内容排版进行计算，随后返回所有内容的高度总和。这意味着，当动态汇总中内容过多时，启动速度会变得更慢。
解决这一问题的方法分为两部分。首先，当我们初始化异步排版计算时，我们在Core Data中存储了内容的高度。通过这样做，我们避免了在tableView:heightForRowAtIndexPath:函数中计算排版信息。其 次，我们将“内容”的模式对象进行分解，在应用启动时只会从磁盘读取内容的高度信息，随后才读取其他信息。而其他的排版计算均通过异步方式来完成。
通过以上这些方式，我们在屏幕滚动时实现了更高的帧率，并使应用保持响应。
新的基础：Messenger及其他
开发人员总是避不开一些限制，一些是技术上的，一些是设计上的，一些则是由产品需求引起的。当我们重新开发iOS应用时，一款新的原生应用 Facebook Messenger正越来越流行。为此，我们需要完全集成Messenger的底层架构和用户界面，并充分利用Messenger团队此前已经过充分测试 的代码。当点击iOS应用中“Messages”图标时，运行的代码将与Facebook Messenger应用完全一致。
为了实现这一目标，我们按模块来搭建系统。当你在左侧导航菜单中点击书签时，模块提供的视觉效果将得以显示。动态汇总、Messages、 Friends，这些都是模块。模块也会说明相互之间的依赖关系。例如，我们使用MQTT去更新通知、消息和书签。在应用启动时，应用会遍历依赖关系图， 确保在通知功能启动前先启动MQTT服务。在增加新功能时，模块系统也将确保应用在正确时间、正确位置启动。
尽管模块系统部分解决了问题，但Messenger也不可能简单地以新核心取代当前代码。新版iOS应用中的认证系统以及Messenger应 用的执行方式共享了同一界面的对象。用Objective-C的语言来说，就是“遵循了同样的协议”。通过与Messenger团队的合作，我们开发了依 赖注入系统，向Messenger代码提供了用于实时验证的对象。当作为一款独立应用时，Messenger代码以自己的方式处理这些对象。当作为 Facebook应用的一个模块时，将采取不同的处理方式。在代码中加入这些对象是一个聪明的做法。
未来计划：不必更新应用的升级
目前，动态汇总中的内容都有页面头，其中包括内容预览图、时间戳、消息、照片、视频，以及“赞”和“评论”按钮。这通过HTML5很容易实现， 并且可以快速更新设计，例如用户何时更新了动态汇总，使照片尺寸更大等。不过，动态汇总也在持续发展，当我们增加新功能时，采用Objective-C的 方法将带来新的挑战。
为了解决这一问题，我们采用不同的方式去增加新功能，同时不必升级整个应用，这就是“回退渲染器”(fallback机制)。当动态汇总团队设 计了一种新的内容形式时，iOS应用将下载到一些无法识别的内容。当我们检测到这种内容时，我们将使用回退渲染器，以应用可识别的格式显示新内容中的相关 信息。与此同时，我们开发了新的定制渲染器，在下一次应用升级时发布。对于应用中可能经常更新的部分，我们仍将继续使用HTML5代码，这样我们可以在服 务器端推送升级，而用户不必下载新版本应用。
最后做个广告：你口袋中最好的Facebook体验
开发原生iOS应用使我们有能力保证应用的速度、可靠性和功能。无论使用时间是30秒，还是乘火车旅行，我们都希望你能有快速而满意的体验。我 们认为，移动是Facebook最好的平台，并希望在任何时间任何地点通过这一平台提供最好的Facebook体验。新版iOS应用只是我们其中一步。