Facebook iOS 新版开发手记:两倍速度的背后

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应用只是我们其中一步。

本文编译自Facebook官方博客