说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

To Facebook:HTML5不好用?是你不会用!

HTML文档下载 WORD文档下载 PDF文档下载
作者Jamie Avins和Jacky Nguyen是Sencha的工程师,拥有丰富的HTML5框架及工具的开发经验,在听到Mark Zuckerberg表示“HTML5尚未就绪”后不以为然,在空闲时间开发了Fastbook这个纯HTML5应用,有力地回应了Zuckerberg。

虽然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

备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘