HTML5资讯

当前位置: HTML5技术网 > HTML5资讯 > To Facebook:HTML5不好用?是你不会用!

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”!


  或者你也可以观看这个视频[地址:http://player.vimeo.com/video/55486684?title=0&byline=0&badge=0](墙外),比较我们的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


       译文链接:CSDN


【To Facebook:HTML5不好用?是你不会用!】相关文章

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

2. 宣称要打败Facebook,反Facebook社交网络Unthink上线

3. 制作Fastbook:一段HTML5爱情故事

4. bookblock:可帮助你生成翻页效果的jQuery插件

5. bookblock:可帮助你生成翻页效果的jQuery插件

6. Facebook收购基于HTML5开发平台Spaceport

7. HTML5能否颠覆传统Web应用?

8. 微软CEO鲍尔默:Facebook“是反社交的”

9. Facebook活跃用户正转向Twitter和Google+等服务

10. Google+是工具 Facebook是玩具

本文来源:https://www.51html5.com/a3040.html

点击展开全部

﹝To Facebook:HTML5不好用?是你不会用!﹞相关内容

「To Facebook:HTML5不好用?是你不会用!」相关专题

其它栏目

也许您还喜欢