透过微信应用号看HTML5与Native进入融合时代

如果说以前的微信公众号还是一个媒体化的平台，那么2016年的公众号会有一种新的形态，叫应用号。应用号预示着比公众号更强大的功能、更优质的体验以及更丰富的服务。应用号的出现是微信产品的一次重大升级，无论是为了体现用户价值观？还是追求产品商业化？作为一名技术人员，我不想过多讨论，而是更愿意从技术的角度来分析一些其中Web技术的发展。

微信做为一款超级App，有着巨大的入口流量，需要不断的产生动态的内容，Web技术在微信中一直发挥中重要的作用。如果说公众号还是标准Web技术＋简单桥接扩展，那么在应用号中，Web技术将依靠更强大的Web执行容器在微信中发挥更大的作用。我们可以来看看在微信中Web与Native技术的结合过程，从嵌入系统Webview, 到X5增强浏览器引擎，到功能扩展的JS-SDK，再到刚刚发布的weUI，再到应用号。微信团队一直推进着Web技术在Native App中融合与发展。

随着移动设备的快速更新换代，以HTML5为代表的Web技术在NativeApp中有了越来越多的应用场景。一方面是Native App开发团队在保证功能和性能的同时，需要提高开发效率，降低运营成本；另一方面是App用户在满足需求和体验的同时，需要更快的获取动态的内容；这些都需要Web技术在App开发中发挥越来越多的作用和价值。但这种价值绝对不能称为脱离或颠覆。在今天，更多的是“融合”！

我从06年开始做了10年浏览器引擎和跨平台App引擎。见证了这10年来，Web技术在Native App中不断的应用和发展。从功能机到智能机，从k-java到移动App，从WebBrowser到Webkit，我们可以将Web技术在Native App中的发展分为5个阶段，内置、嵌入、桥接、混合、融合。

一 内置自定义Web容器时代

2010年之前，那时还是feature phone为主流的时代，硬件配置低，系统功能弱，手机应用以内置为主。但SP业务已得到长足的发展，用户需要动态获取内容来满足资讯和娱乐的需求。这个时期Web技术在Native应用中的使用方式是Native应用开发商与浏览器厂商合作，在应用中内置某个厂商的浏览器引擎，作为Web的执行容器。应用从服务器端动态下载web文件，解压后交给Web容器离线运行。内容和功能都很简单，通常就是图片＋文字的排版，以及按键交互。形式如图书、杂志、小游戏以及小工具等。这类需求也驱动了当时一些主流浏览器厂商去思考浏览器的在传统价值以外的作用，并积极参与到W3C Widget规范的制订。这一时期也是移动浏览器厂商的黄金时代。

二嵌入系统Webview时代

2010年，Android系统在国内兴起，iPhone也逐渐普及，以Android和iOS为主的原生应用生态系统开始不断的培养用户到AppStore下载应用，以及以独立App作为入口的使用习惯。这一时期App开发需求也逐渐增长，但是竞争还不算激烈。客户可以接受原生的开发成本和周期。应用开发商利润丰厚，开发者纷纷开始学习Android和iOS App开发。系统自带浏览器的功能和性能已经超过当时的第三方浏览器。在App中通过嵌入系统Webview来展示本地或服务器端的界面已经比较常见。这一时期Web技术的应用以内容展示为主，所能完成的功能被限制在标准浏览器支持的范围内。而传统浏览器厂商依靠Lisence收费的商业模式终结，并且逐渐淡出市场。

三 Webview的桥接扩展时代

2011年， Android和iOS在手机系统中逐渐已经占据了统治地位。App开发需求迅速增长，竞争加剧，原生开发人员供不应求，客户开始考虑成本和周期，开发商开始考虑效率和利润。开发者开始思考Webview在展示内容之外是否还可以完成部分App功能。由于系统内置的都是Webkit引擎，支持标准的Web技术，并且支持开放扩展。国内外以Phone Gap为代表的厂商开始了对Webview的桥接扩展，并且形成一套完整的调用机制，在JS中可以任意调用原生接口。