Facebook iOS新版应用：两倍速度的背后

资讯频道 → 移动开发

1顶
0踩

2012-08-30 17:34 by 副主编 MnouW 评论(0) 有3688人浏览

facebook ios html5 app

Facebook上周发布了新版iOS应用，号称速度提升两倍。Facebook工程师Jonathan Dan在Facebook官方页面中撰文，介绍了新版iOS应用、Facebook iOS应用的发展历程以及开发思路。

以下为文章全文：

我们今天发布了新版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代码，这样我们可以在服务器端推送升级，而用户不必下载新版本应用。

Via Facebook官方博客

来自: 新浪科技

分享到：

1
顶

0
踩

评论共 0 条请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

1顶0踩