原生应用 vs HTML 5

这几个月都在开发 知乎日报的后端，让我对移动应用的开发有了更多的认识。

简单来说，我以前一直都认为原生应用才是王道，现在则觉得 HTML 5 才是未来。

不可否认的是，原生应用更快，能使用更完整的 API，但它有个致命的缺点——升级太麻烦。

举例来说，我们筛选出下个版本需要实现的功能，很快就能做出其中的一部分让内测人员体验。而等我们全部做完，已经过去一周多了。然后提交苹果审核，又要等一周。再等个良辰吉日发布，就过去 20 天了。
扯淡的是这期间 iOS 7 测试版发布了，然后各种原生控件都有问题。
与此同时，我们又做出了更多功能，调整了多处细节，还修复了几个 bug——但用户只能再等几十天才能体验到了。
而且还有的用户就是不升级。虽说我能强制要求用户升级，但这毕竟影响用户体验。
更让我不爽的是，新版本可能要使用不同的 API，于是服务器端要维护多个 API 版本；甚至还因为 iOS 和 Android 各自有不同的限制，导致 API 要做出各种妥协。而我把数据都放在了 Redis 里的，每个 API 版本都可能要生成不同的数据，于是得占用几倍的内存…
而在开发网站时，一个功能做好了就能上线，一天更新几十次毫无压力。如果客户端只是个浏览器，那一切都会变得很简单。

再来回顾一下原生应用的优势。

• 性能好。
  从最新的 测试来看，C gcc : Java 7 : JavaScript V8 在单核 x86 CPU 上的速度比约为 3 : 2 : 1。JavaScript V8 可是和 Go 一样快哦，我好像还没看到有抱怨 Go 慢的。
  没记错的话，在 1、2 年前，JavaScript V8 可是比 C 慢 20 倍的；甚至在一个月前，还是 4 : 1 的样子。因此你可以期待它更快。
  当然，手机大多用的是 ARM，不一定有 x86 的性能。而除了 V8，还有各种 JavaScript 引擎，例如 iOS 的 Nitro。甚至 V8 自己都在频繁更新，至少最新版本比 2 年前快了 6 倍。而手机上除了升级系统版本，不可能频繁更新 JavaScript 引擎。
  
  此外，JavaScript 是单线程的，但是 JavaScript 引擎在处理 IO 时，还是能通过多线程的方式利用到多核。当然也不排除 JavaScript 未来能直接利用多核，只是目前还有很多依赖 JavaScript 单线程特性的地方，因此设计起来会比较麻烦。
  
• API 更完整。
  HTML 5 为了可移植性，只能定义通用的 API，所以必定会牺牲很多独有的功能。
  不过只要 HTML 5 还是未来的发展方向，那么能支持的 API 肯定会越来越多的。或者自己做个代理层，转发调用原生接口。
  而转向 HTML 5，就意味着得放弃很多开源的原生解决方案，慢慢用 HTML 5 去取代。
  总之，办法是有的，只是时间问题。
  

不过时间问题就是最大的问题，至少我几年内都不想再开发新的移动客户端产品了。

顺便再指出，JavaScript 语言本身还有不少缺点，而 CoffeeScript 也不能解决，我随便列举几个：

1. 弱类型。例如 [] + {} 的结果是 "[object Object]"，{} + [] 的结果是 0。不要问我为什么，我也不知道。
   
2. 不区分整数和浮点数。整数溢出后就变成浮点数了，再加上它是弱类型，还能变成字符串。
   
3. JavaScript 的 object 不如 Python 的 hash 好用。遍历麻烦就不说了，毕竟还能用 CoffeeScript，关键是 key 只能是字符串。如果拿一个对象作为 key，这个 key 就变成了 "[object Object]"。
   
4. 还有些不是 JavaScript 语言本身的问题，而是 DOM API 的设计问题。例如 element.removeEventListener() 必须要传递 listener 函数，不能直接清空一个或所有类型；于是想要注入时，就拿那些匿名函数没辙了。
   

也别梦想 HTML 5 能直接兼容各种平台，只是平台相关的代码写得少些而已。

总之，我很看好 HTML 5，只是目前仍然太早。过渡期的解决办法就是混合使用（即在性能和体验可接受的情况下，用 Web 页面来做展示），然后等时机成熟，再用 HTML 5 替换原生代码。