虽然Mark Zuckerberg说HTML5尚未就绪，但我们对此不以为然。HTML5并不是Facebook移动应用反应缓慢的原因，我们很清楚最新的移动系统——iOS 5或Android 4.1——有多强大，不论是性能还是对HTML5的支持。
我们怀疑Facebook开发团队遇到了问题，不过这很正常。他们可能直接把网站开发思路直接套入HTML5移动应用开发上了，导致应用反应迟钝、加载缓慢、用户体验差。但是我们在HTML5框架、工具以及应用开发上有足够经验，所以决定在空闲时间挑战Facebook，最终成果就是这个
Fastbook，你可以试试看HTML5究竟可以有多快。
我们的结论是：HTML5已经足够面对很多复杂应用的挑战，不是“HTML5 IS NOT READY”，而应该是“HTML5 IS NOT JUST READY”！或者你也可以观看这个
视频（墙外），比较我们的HTML5应用跟Facebook原生iOS（v5.2）、Android（v1.9.12）版本应用的速度。本视频录制时间是12月10日。
iOS 5 - Native vs. HTML5
Android 4.1 - Native vs. HTML5
以下是开发过程：
细看Facebook原生应用
我们试着理解Zuckerberg关于“HTML5尚未就绪”的发言，最好的方式莫过于深入研究Faceboook最新的iOS原生应用。我们把一台iPhone联入网络调试代理（web debugging proxy）中，观察它推送的HTTP信息流。当时我们就震惊了，它传输的大部分仍然是HTML网页数据！News Feed页面和个人信息页面“原生化”了，但很多其它UI依然是向m.facebook.com发送HTTP GET请求。其所谓的“原生”应用也不过是Web/Native混合应用：从m.facebook.com上获取内容，再使用UIWebView以及原生Objective-C组件混合显示。
重新实现News Feed
分析完Facebook原生原生应用的结构，结果就很明显了：News Feed是整个应用中最难实现的部分。News Feed需要处理10亿级别用户发布的无数信息，即使是最有经验的程序员也很难处理这样这种不确定的难题。
那么首要目标就确定了，我们需要使用HTML5实现一个足够流畅的News Feed界面，为此还需要往Sencha Touch框架的核心添加一些新功能和改进。
首先，需要实现一个无限长度的链表，来处理未知数目的信息条目。填充屏幕可见区域只需要几组DOM节点，然后它们将根据需要不断地被回收，以呈现下/上一条信息。这就保证无论存储的数据有多少，内存占用率总是最低的。实现起来也很简单，真正的难点在于如何快速处理各式各样的信息条目，瓶颈在于浏览器无法避免的核心过程：布局与UI绘制。
经验表明，一个小demo在演示中表现良好并能够不代表它一定能在大型应用中正常运行。DOM树往往会随着应用的扩展慢慢变得臃肿，于是浏览器需要花费更多时间来设计布局，最终导致应用性能下降。此外，随着可见层数目的增加，各层合成视图的性能也会下降。我们需要一个能够在DOM节点数目庞大情况下的解决方案。
为此我们重新设计了一个“Sandbox Container”，它可以分解复杂的视图，并在独立的iframe中渲染，这样就分割了DOM树。这种特殊的容器不需要在应用程序级别做任何额外的处理，因此可以无缝地提供给开发者（例如：任何添加到该容器的组件都会自动地被沙盒化。）。但它也需要付出相应的代价：事件、定位、样式处理和JavaScript代码在父窗口和子沙箱间都必须使用用代理。
这很复杂，因此必须有一个健壮并且合适的框架辅助实现。我们采用的是Sanfboxing，能够独立地计算布局，因此尽可能地保证了主DOM树的轻量。为了保证性能平衡，必须慎重地使用沙箱。
在Fastbook中，News Feed、Timeline以及Story视图都存在于独立的沙盒。因为所有DOM原生都被频繁地重用，来渲染请求得到的数据，回流（reflow）是不可避免的。关键在于如何尽可能降低该过程的性能开销。虽然News Feed是更大DOM树的一部分，但Sandboxing能让News Feed像是在独立运行一样。
接下来，将其深度集成到我们的TaskQueue（我们最近引入Sencha Touch的新功能）中，TaskQueue能够预防DOM交叉读写请求，避免不必要的布局绘制。结合新的沙盒技术，能够显著减少复杂视图，如Timeline和News Feed这样非常消耗性能的布局。
之后添加的是AnimationQueue，响应式地实现动画和事件，此外还负责复杂任务调度到CPU空闲时间执行。它的作用类似于交警：为不同的任务设置不同的优先级，以保证程序一直保持响应状态。应用在绘制动画时将会暂停低优先级的功能，直到应用空闲时才重新执行被暂停的任务。此外，繁重的任务将会借助一个高频率计时器以非阻塞方式执行。这些都是为了保证触摸事件总有机会尽快处理。
当然，你可能不希望暂停部分功能中的类，比如“读取更多信息功能”。为了保证该功能不会导致流畅度的降低，我们使用了Web Workers，可以从UI线程中移除XHR/RPC通信。此外Web Workers还降低了网络请求以及JSON加/解密的消耗，同时更好地利用了当今多核设备的性能。
以上是Fastbook的设计要点。纯粹开放标准的Web技术给我们带来了如此优秀的性能，更让人兴奋的是，我们用HTML5实现了Facebook原生应用所有的功能。
加分点
为了优化网络流量，我们使用了一个代理服务器来过滤Facebook FQL API返回的无用信息。因此Fastbook比Facebook原生应用更节省流量，只占后者的10%。
也许你还注意到Fastbook和原生应用滑动减速上的不同：原生应用大概3s后才会停下来，而我们把滚动时间缩减到了1.4s，便于缓冲信息，同时为预渲染提供了时间。
结论
Fastbook并不是Facebook应用的替代品，它只能算是一个技术demo，为了证明HTML5的能力及价值。如果你对于HTML5是否准备好了还存有疑虑，请使用我们的
Fastbook，只需要一台现代智能手机（我们推荐iOS 5或者Android 4.1以上）。你会发现，只要以正确的方法使用正确的框架，即使是HTML5也能完成非常复杂的应用和特性！
发表于 2012-12-19 16:20:53
收藏
楼主