fastbook制作过程邂逅html5.docVIP

[核心提示]?HTML5 不是 Facebok 移动客户端速度慢的原因，相反，HTML5 的出现，为程序员提供了更多的开发工具，使得他们可以将浏览器看作应用的开发平台而不仅是页面渲染引擎。 在开始 Sencha 的开发之前，我们对 web 开发抱有一个希望：希望现代应用程序的开发只需要一个浏览器，而不需要其他的任何环境，另外加上一组足够强大的开发框架和强大的编码工具。以上三件武器在手，我们相信开发者一定可以开发出用户喜欢的应用程序。HTML5 的出现，为程序员提供了更多的开发工具，使得他们可以将浏览器看作应用的开发平台而不是页面渲染引擎。开发者们迅速抓住这个机会，并发布了大量基于桌面端和移动端的程序-充分利用了 HTML5 的特性，使用 web 标准建立强大的应用程序。 因此，当马克 扎克伯格谈到?HTML5 还没准备好时，我们对此不以为然。 HTML5 不是 Facebok 移动客户端速度慢的原因。我们非常清楚现代智能手机的浏览器能够做什么， HTML5 又提供了如何丰富的特性。我们同时看到了运行最新版 iOS 5 和 Android 4.1 移动设备上性能的逐步提升以及 HTML5 应用跑分(测试浏览器对 HTML5 兼容性)的不断增加。但最重要的还是，我们看到了我们的客户(这里指使用 Sencha 的开发者)正在做什么和他们使用 HTML5 所创造出的神奇事物。 Facebook 的移动客户端开发团队遇到问题是因为他们碰到了一个常见的错误模式。在 Sencha 中，我们为程序员提供了开发框架和工具，因此我们对于建立 HTML5 项目的开发团队有相当成熟的经验。当一个团队在使用 HTML5 时遇到问题，通常是因为他们使用传统的网页开发方式去开发应用程序，而且在实际开发过程中没有使用正确的工具和架构。这正是我们质疑 Facebook HTML5 应用的地方。导致程序经常出现加载缓慢，读取用户新动态卡屏的症状。 在任何场合下，我们都想去证明 HTML5 实际上已经准备好了。因此我们决定利用空余时间重新设计 Facebook HTML5 移动客户端中最具挑战性的部分。今天，我们推出了 SenchaFastbook?。从技术的角度验证了 HTML5 到底可以多块，并演示 HTML5 是如何去化解这些程序开发中的最大挑战。 下面四分钟的简短视频将会展示 HTML5 客户端在面对原生 iOS 和 Android Facebook 客户端时的精彩表现（分别对应 iOS 5.2 版本和 1.9.12 版本，也是到 12 月 10 日为止的最新版本）。文章的剩余部分将会介绍 Fastbook 制作的技术细节。 细看“原生” Facebook 客户端 扎克伯格抱怨 HTML5 “还没准备好”，理解这句话最好的方式莫过于深入挖掘最新版本的 Facebook iOS 原生客户端。我们将 iPhone 连接到一个 web 调式代理中( web debugging proxy )，观察客户端发送数据时的 HTTP 流量变化。令我们吃惊的是，客户端的很多地方依然是原始的 HTML 页面编写。最新动态部分，也就是我们所看到的用户资料页面，全部被移到了本地。但是程序的很多其他界面仍然是发送简单的 HTTP GET 请求连接到 。现在我们看到的“原生” Facebook 应用实际上是 web/原生混合应用：既有基于 渲染显示在 UIWebView 里的内容，也有原生的 Objective C 组件混合在一起。 重新编写“最新动态”( News Feed )页面 在了解了原生 Facebook 客户端是如何工作之后，我们很快就清楚了，体验中最难建立的就是“最新动态”部分。同时处理由上亿的用户，使用完全无法预料的方式所创造的无限数量的内容，即便对于那些最有经验的开发者来说也是一个很难解决的问题，不管他们所使用的是什么技术。 我们迫切的想要确定，在使用 HTML5 重构应用时，“最新动态”部分能够拥有很流畅的体验。为了使它变得可能，我们添加了一些新的特性，并把它们添加到了现有的 Sencha 触控框架中。 我们从实现一个能够处理未知大小的无限列表组件开始。在实际的可视屏幕区域内，建立了很少的几组 DOM 节点。这些节点将会被持续的用于循环渲染下一条或者上一条所需数据。这样一来，不管储存的数据有多大，内存的开销始终被控制的很小。实现这个部分非常简单，但是要使它在复杂多变的情况下，例如加载最新动态时，仍然能够保证速度才是最大的挑战。瓶颈来源于浏览器执行的核心进程：布局以及渲染。 建立( Sencha )框架的经验告诉我们，一些小的演示组件单独执行时能够正常工作，但是把它放入一个比较大型的应用中时表现通常比较糟糕。随着应用的逐渐变大，DOM 树也随之增加；浏