To Facebook：HTML5不好用？是你不会用！

　　虽然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原生iOS应用网络性能时发现了一件有趣的事情，API请求会返回大量原始数据到客户端。举个典型的例子：通过API向https://graph.facebook.com/graphql/发送请求来渲染News Feed条目，平均每10条信息会下载15-20KB gzip压缩过的JSON数据，但其中大部分数据都不会被使用到。

　　为了优化网络流量，我们使用了一个代理服务器来过滤Facebook FQL API返回的无用信息。因此Fastbook比Facebook原生应用更节省流量，只占后者的10%。

　　也许你还注意到Fastbook和原生应用滑动减速上的不同：原生应用大概3s后才会停下来，而我们把滚动时间缩减到了1.4s，便于缓冲信息，同时为预渲染提供了时间。

　　结论

　　Fastbook并不是Facebook应用的替代品，它只能算是一个技术demo，为了证明HTML5的能力及价值。如果你对于HTML5是否准备好了还存有疑虑，请使用我们的Fastbook，只需要一台现代智能手机(我们**iOS 5或者Android 4.1以上)。你会发现，只要以正确的方法使用正确的框架，即使是HTML5也能完成非常复杂的应用和特性!

　　原文链接：Sencha

　　(责任编辑：leonlee07)

　　打印 分享 评论 分享到：

　　分享 顶一下 (0)