非死book引发的HTML5危机

   <p>        近期几个新闻堆叠在一起，颇有韵味。先是 WHATWG 和 W3C 在 HTML5 标准上分道扬镳，继而“非死book 移动应用宣布放弃 HTML5 的部分，改为纯 Native 方式开发”，接着又传闻苹果 AppStore 肃杀基于 Web 技术的 App。这几个事件对移动互联网行业来说个个都是重磅炸弹，押注 HTML5 的受到不小的打击，唱衰 HTML5 发展的借此幸灾乐祸。HTML5真的只是一场政治斗争吗？到底 非死book 为什么放弃 HTML5？现阶段 HTML5 到底出了什么问题？</p>    <p>        <strong>非死book 放弃 HTML5 主因：慢</strong></p>    <p>        “对于 非死book 的 iOS 原生应用来说，它在主要在三个方面有很大的速度提升：应用启动、共享新闻滚动还有图片点击查看。其总体速度大约提升了一倍。这个版本部分采用了 非死book Camera 和 非死book Messenger 两款应用的代码库：其中图片点击查看功能的代码是从 非死book Camera 移植过来，而屏幕消息是从 非死book Messenger 那克隆过来的。这个原生版本是由一个独立的团队开发，产品经理 Johnson 表示未来会充分利用公司的代码共享，也会适当向其他团队寻求帮助。”</p>    <p>        上述摘自 非死book 的官方博客。博客中介绍到 非死book 的 iOS 原生应用放弃 HTML5 后速度得到大幅度提升。大家不禁好奇，为什么 HTML5 会比原生 NativeApp 要“慢”很多？</p>    <p>        在当前的移动终端设备硬件配置和操作系统优化水平的前提下，大部分基于 HTML5 开发的 Web 页面会出现延时加载展示的现象，也就是俗称的卡、慢。特别是在不同的视图界面(view)切换之间，这种卡和不流畅的现象会尤为严重。而 Native 应用不会出现这种情况。究其根源，在于浏览器解析的运作机制和原生 Native 的界面展示机制差异上。如下图所示：</p>    <p style="text-align:center;"><a rel="attachment wp-att-149407"><img title="1" alt="非死book引发的HTML5危机" src="https://simg.open-open.com/show/9833ebb9f1ebf09c73a25492604c537b.jpg" width="545" height="258" /></a></p>    <p>        红色框起来的部分是原生 NativeApp 的界面展示机制，简单的看起来就是 1 个步骤——展示，因为所有的绘图和渲染工作都由系统直接完成。而红框以外的部分包括红框内的部分是 webkit 核心的浏览器解析页面的流程。相比 Native 的 1 个步骤，webkit 的解析过程可谓漫长而艰辛。历经解析、建立 Dom 树、获取对应资源、布局、建立渲染树、绘图到展示。所以不管移动终端设备硬件如何发展，这个差异是始终存在的，最多只是随着硬件的提升和软件的优化将这个 差异收缩到最小甚至忽略。</p>    <p>        更糟糕的是。非死book 之前的 iOS 混合了 HTML5 的移动应用，使用 HTML5 绘图的页面在 HTML5 开发上也毫无技巧可言，基本沿用了主流前端开发框架 jQuery mobile 等的单 View 多 div 的机制。也就是在一个网页内绘制多个视图，页面之间的切换其实只是一个页面内不同区块的切换。这种方式加大了浏览器的渲染和绘制工作强度。并且在数据加载 和流量上产生很大的负面影响。如果切换到新页面，之前的页面不进行销毁，则会加大运算量和增加内存占有，而如果销毁又会导致已经下载的数据失效，要重新载 入，浪费流量。类似情况在中国的网络和设备情况下会尤为突出。所以 非死book 不当的在 Native App 内混搭 HTML5 也难免引来用户怨言。</p>    <p>        还有，一如报道中提到的，非死book 这次的改进提升主要是“新闻滚动和图片点击”。如果了解 HTML5 的人，就会发现，这两点当然是“不应该在现阶段使用 HTML5 实现的”。为什么？笔者作为一个基于 HTML5 技术的 Hybrid App 系统的设计者，设计秉承的一个原则就是“凡是需要’动’的部分和需要大量运算的部分，就最好使用原生弥补，而不是一定要使用 HTML5 来实现”。新闻滚动，这种不停通过改变 Dom 树近而改变渲染再绘图展示的使用场景相比原生 Native 弱势是非常明显的。至于图片的部分就更不用多说了，这并不是 HTML5 眼下擅长的部分。HTML5现在擅长的部分是数据量不大的页面、动画少的页面，特别是跨平台的开发。充分利用好 HTML5 的优势，尽量降低 HTML5 的弱势，学会用好 HTML5，才是现在这个时期使用 HTML5 开发的重点。可以说开发技巧很重要。</p>    <p>        <strong>现阶段 HTML5 的问题：政治斗争</strong></p>    <p style="text-align:center;"><a rel="attachment wp-att-149408"><img title="未命名-1" alt="非死book引发的HTML5危机" src="https://simg.open-open.com/show/b00dfdb4e5a2df2537e2a45cd2e88995.jpg" width="581" height="677" /></a></p>    <p>        “原生版本是一个独立团队开发的。”非死book 公开的这一点也耐人寻味。原来客户端是 Native 与 HTML5 混合的方式，原来的团队也肯定有原生的开发能力，为什么非要一个独立团队重新耗费 6 个月进行重新开发？或许这里不能排除公司内政治因素，而 HTML5 成为一个牺牲品。HTML5的政治不仅是一个公司内的，更是整个行业的。7月份，同为 HTML5 制定者的 WHATWG 和 W3C 表示无法继续合作，前者希望制定一个能够跟随市场或技术动态的标准；后者则要确立一个“死”的标准，一旦正式颁布再也无法修改。</p>    <p>        WHATWG 和 W3C 的分道扬镳或许会成为 HTML5 发展的一个分水岭。WHATWG 背后有 Google、苹果，W3C 拉到了特立独行的巨无霸微软。标准是为利益服务的，曾经力推 HTML5 的苹果，现在也传闻在 AppStore 内打压基于 HTML5 开发的 App。那苹果到底是喜欢还是不喜欢 HTML5？喜欢也是真，讨厌也是真。过去乔布斯为了灭掉 Adobe 的 Flash，将 HTML5 当成冲锋枪，<a href="/misc/goto?guid=4958523242586496121">在移动端干掉了 Flash 之后</a>，面对自己封闭生态系统的巨大利益和 HTML5 世界大同的愿景做出选择的时候，苹果当然毫无悬念的选择自己的利益。</p>    <p>        《<a href="/misc/goto?guid=4958523242704200785">web app 的挑战(三)：入口之争</a>》 一文中，我有阐述自己的观点：入口之争”在现有移动操作系统设计架构下，浏览器很难和用户桌面争夺核心入口地位。苹果打造的 iOS 系统就是一个应用优先的系统，无论 HTML5 怎么发展，Web App 如何挣扎，浏览器如何砸钱，都抢不过用户桌面的入口地位。基于 HTML5 的 Web App 的命运被苹果牢牢把控。Android 系统这个跟随 iOS 桌面入口理念的半山寨货也没有押注 Web App 而是将这个任务交给了 ChromeOS。所以，不用炒概念，也不用谈未来，用 HTML5 开发原生应用，而不是仅仅套个外壳那么简单才是现阶段 HTML5 使用的重点和发展的重点。并且苹果封杀的也只是纯 HTML5 套壳的 App，对于使用混搭模式(包括 非死book 之前的版本)的移动应用还是保持开放姿态，毕竟这种 HTML5 还是在苹果的生态系统内可控的运行着。</p>    <p>        <strong>最后</strong></p>    <p>        非死book 的 iOS 放弃 HTML5。幸灾乐祸也好，沮丧也罢。变的只是一个应用，HTML5的势头和趋势不是一个企业可以逆转的。现阶段，真正的了解 HTML5，掌握 HTML5 的开发技巧和在恰当的地方用好 HTML5，才是把握机遇的重点。</p>    <p>        作者：@<a href="/misc/goto?guid=4958523242797017103" rel="external nofollow" target="_blank">AppCan 刘鑫</a></p>    <div id="come_from">    来自:     <a id="link_source2" href="/misc/goto?guid=4958523242900693606" target="_blank">36氪</a>    </div>