s*****n
发帖数: 5488 | 1 尼玛就一个异步下载网页这个教科书的经典也他妈的拿来吹，看见facebook做的多烂。
现在的android客户端不停地crash.去死吧fb.
-------------
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应用只是我们其中一步。 |
k**o
发帖数: 15334 | 2 嗯，facebook确实应该把他们移动部门的傻比都解雇了。明明iOS占移动市场60%
多的份额，这帮傻比为了兼容剩下的30%多，硬是搞HTML5，尼玛你拿一写web app
的语言去写移动app，就为了那点兼容性，值得吗？其实一个iOS，一个android
写这么两个native app，你就已经服务了90%的移动市场了。其他系统你爱写啥
写啥，都对大局无碍。人家很多小破公司都知道这么弄，丫FB移动部门竟然不
知道。 |
b*******e
发帖数: 6389 | 3 facebook和google难道不是竞争对手？
【在 k**o 的大作中提到】
: 嗯，facebook确实应该把他们移动部门的傻比都解雇了。明明iOS占移动市场60%
: 多的份额，这帮傻比为了兼容剩下的30%多，硬是搞HTML5，尼玛你拿一写web app
: 的语言去写移动app，就为了那点兼容性，值得吗？其实一个iOS，一个android
: 写这么两个native app，你就已经服务了90%的移动市场了。其他系统你爱写啥
: 写啥，都对大局无碍。人家很多小破公司都知道这么弄，丫FB移动部门竟然不
: 知道。
|
k**o
发帖数: 15334 | 4 竞争对手也不妨碍写app啊。除非你不想要移动市场了。GOOG和MSFT还是
竞争对手呢，GOOG给微软windows写了不少软件，什么google earth,
desktop search, gtalk etc...何况FB本身没有任何操作系统，不像GOOG还有
自己的操作系统。
【在 b*******e 的大作中提到】
: facebook和google难道不是竞争对手？
|
b*******e
发帖数: 6389 | 5 决策层考虑的可能比外人要多啊。
【在 k**o 的大作中提到】
: 竞争对手也不妨碍写app啊。除非你不想要移动市场了。GOOG和MSFT还是
: 竞争对手呢，GOOG给微软windows写了不少软件，什么google earth,
: desktop search, gtalk etc...何况FB本身没有任何操作系统，不像GOOG还有
: 自己的操作系统。
|
k**o
发帖数: 15334 | 6 这个好像没什么战略性的决策，只是个技术性的决策。FB已经给iOS和android
写了app，但问题是用HTML5写的，号称兼容性好，实际导致app速度慢，难用。
现在承认错误，改成写native app了。绕了个大弯，才回到正确的道路。而
绝大部分其他公司，都不用绕这个弯，直接就写native app。
【在 b*******e 的大作中提到】
: 决策层考虑的可能比外人要多啊。
|
b*******e
发帖数: 6389 | 7 OK，大概他们做web习惯了。
【在 k**o 的大作中提到】
: 这个好像没什么战略性的决策，只是个技术性的决策。FB已经给iOS和android
: 写了app，但问题是用HTML5写的，号称兼容性好，实际导致app速度慢，难用。
: 现在承认错误，改成写native app了。绕了个大弯，才回到正确的道路。而
: 绝大部分其他公司，都不用绕这个弯，直接就写native app。
|
