从 Facebook 原生应用想到的

Facebook 所犯的最大错误，就是将赌注押在了 HTML 5、而不是原生应用上。

在上月的 Techcrunch Disrupt 上，Facebook CEO Mark Zukerberg 针对其移动 App 的这番发言引发了一场针对 Web App 的声讨。HTML 5 驱动的 Web App 从在此之前的明日之星，似乎变成了所有相关移动应用体验不佳的最大症结所在。从用户评价上，Facebook 新的原生 iOS App 从过去的 1.5 星评价迅速提升到了 4 星；从使用数据上，在新的应用推出后，用户的使用率上升了一倍之多。对于 Facebook 这样一个用户量庞大的应用来说，能够获得如此的提升实属难得，特别是考虑到新的应用在视觉上与旧的应用几乎没有什么区别。用户的一致反应是，新的应用在速度和使用体验上有了大幅度的改进。

那么，我们是否可以得到结论说：在移动设备上，HTML 5 应用很糟糕，原生应用是王道呢？也许我们应该先看看 Facebook 手机应用的发展历程是怎么样的。

Joe Hewitt，这位 Web 开发工程师都相当熟知的 Firefox、Firebug 开发者，同样也是 Facebook iPhone 应用的最初开发人员。他开发的 Facebook 第一版原生 App 在当时获得了广泛的好评，从其中衍生出来的 Three20 也是 iPhone 早期时，开发者熟知的一个开发框架。但在 Joe 2009 年因为苹果应用商店的审核问题退出这个项目后，后续的开发人员没有能够很好的在其基础上进行进一步的改进。之后 Facebook 表示，出于跨平台开发的考虑，他们开始转向 HTML 5 的版本开发，但据 Facebook 内部开发人员表示，Facebook 服务器端团队与移动团队之间在如何传输数据方面一直相持不下，移动团队原本计划的混合开发模式是希望服务器端能为其提供 JSON 数据，以能够实现本地内容缓存、以及快速的内容渲染，但服务器团队却告知他们说只能提供 HTML 数据。最后结果是，后来的 Facebook App 仅仅只是其移动版网页的简单封装而没有什么优化，其性能严重落后于同时间的其他原生应用，也落后于其他 Web 应用。

对于 Facebook 来说，其手机应用之前难用的主要原因并不在于 HTML 5，而更多的在于其执行中的问题，这也是目前很多 Web 封装型应用的共同问题。由于目前各大手机平台上 WebView 本身的性能限制和特性缺失，使得这些简单网页封装型应用不仅无法赶上原生应用的水平，甚至还比不上自己的移动版网页（出于安全性的考虑，苹果对于 Safari 以外的 Web App 采用的 UIWebView 进行了限制，使其 在 JS 脚本执行速度等方面无法发挥真正的性能，而 Android 的 WebView 性能则更是不尽如人意。）

但这并不意味着 HTML 5 在移动开发中彻底失去了意义，Facebook 虽然比较激进的转向了原生开发，但事实上，新的 Facebook App 同样也采用了混合的做法，在应用的大多数地方采用了原生代码来实现优化的性能，但在会频繁变动的地方采用了 HTML 5 代码来实现快速的功能更新分发，而相对应的原生代码更新则会累积到下一次应用升级时进行更新（所谓的“fallback" renderer）。

如果说新的 Facebook App 对于 HTML 5 的使用仅仅是实验性质的话，那么我们从 LinkedIn、Quora 等业界一致好评的优秀应用中，可以看到 HTML 5 与原生应用结合使用的优秀案例：LinkedIn iPad 应用 95% 都采用了 Web 代码，在性能敏感的地方使用 Node.js 来进行优化；Quora 的交互功能部分采用了原生代码，但在内容呈现上则采用了 HTML 5 来实现。

对于应用开发者来说，不应仅仅因为 Facebook 的这一政策转向就激进的改变自己应用的开发方向。也许单纯的 Web App 打包型应用的确还无法满足用户的标准，但 HTML 5 即使在目前的情况下也可以在原生应用中发挥重要的作用（甚至像 LinkedIn 那样，实现非常优秀的体验），当然其未来会如何进展还有待继续的关注。在这方面，Mozilla Firefox OS、Google Chrome 等是 HTML 5 未来在移动端如何进化的值得关注的参与者。

此外，也不要忽略了 Mark Zuckerberg 讲话的另一部分：Facebook 的移动版网页的使用量依然比 iOS、Android 应用加起来还要多。移动网页将依然是 Facebook 重要的战略阵地，我们希望 Facebook 能够在其 HTML 5 移动端进一步进行优化和改进，而不是仅仅抱怨其多么的不好用。