原生应用 vs HTML 5

标签:HTML, JavaScript, iOS开发

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

简单来说,我以前一直都认为原生应用才是王道,现在则觉得 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 替换原生代码。

6条评论 你不来一发么↓ 顺序排列 倒序排列

    向下滚动可载入更多评论,或者点这里禁止自动加载

    想说点什么呢?