未来不是Web与App的生死之争，而是两者共生存

2013 年是 HTML5 在中国最惨淡的一年，但是直到现在仍旧很少有人反思这种惨淡的根源。“体验经济”的盛行，让“用户体验至上”成了互联网公司铁的纪律。各行各业也把用户体验挂在嘴边上，可是偏偏在 HMTL5 从业者的思维中，用户体验被刻意忽略甚至成了“某种借口”。

很快中国力挺 Web App 和 HTML5 的排头兵们纷纷偃旗息鼓，为数不多的当时获得 VC 青睐的 HTML5 创业公司也在 2013 年被迫转型甚至解散。直到 500 天后的 2014 年，一只再次挑动了 HTML5“神经的猫”出现才打破这一悲观的趋势。

Web的优势是

• 对用户而言：通过 Web 访问业务，无需下载安装，快速安装使用，手机上也就无需安装大量的 App，影响注意力；

• 对开发者而言：手机浏览器跨操作系统，App 开发商一次开发，就可以部署在 Android，iOS，WP 等不同平台的手机浏览器上，开发效率远超 App；

• 对互联网公司而言：基于 Web 访问业务，可以方便地跨应用访问和调用数据，这一点 App 目前还很难做到。

　　Web 没有真正提高开发效率

　　但是即使理论上 Web 有诸多优势，但是无法改变目前 App 开发占据主流的现状，其原因不外乎以下：

• 执行效率：在手机端，无论就 JavaScript 的执行效率，还是渲染性能，Web 技术都无法与更直接调用 OS 功能的 Native App 技术匹配，这是天然的；

• 内容呈现能力：在手机端，传统 Web 的 UI 控件与 Native App 的 UI 控件的的形态和表现能力有较大差距；

• 功能覆盖：一些I/O功能调用如：拍照、音效、视频...基于 HTML5 的调用效果仍然不及 Native API。

　　从用户体验的角度来讲，用户对于 Web 并没有强烈的需求。而且传统 Web 模式在产品模式上是有问题的，它在操作系统与应用之间插入一个自有的操作体系和业务体系。这在 PC 上可行，在手机端则会引发以下问题：

• 
  

  操作极其不流畅 相对于 PC 上可以通过鼠标、键盘、菜单等丰富的操作方式，手机上的操作方式非常有限。用户在手机浏览器等 Web 平台中针对 Web App 的操作，一部分将会被平台本身截获，产生不符合用户预期的执行结果。典型的被截获操作是系统回退和左右滑屏——这使得 Web App 在传统应用模式下无法实现应用内回退或侧边栏等设计。

• 没有减少操作 传统手机浏览器试图在其自身操作范畴内建设一个大而全的生态。用户进入所谓的轻应用，和桌面一样 需要寻找，指示操作的对象从 App Store 换成了搜索引擎。Android 和 iOS 的 App 虽然数以百万计，但用户常用的业务类型只有 10 种左右，除游戏外，用户只需要针对每种业务类型选择安装 1~2 种垂直领域的“超级 App”就可以满足日常绝大部分移动互联网需求。

• UI 元素落后 所有的手机浏览器，基本操作元素都来自 PC 浏览器，包括：菜单栏、网址框、搜索框、窗口标签等。不过，在寸土寸金的手机屏幕，这些元素都是必须的吗？在功能机时代，系统桌面不是多任务的，手机浏览 器的多任务会给用户带来极大的便利；但智能手机系统本身就是多任务、多窗口的。用户没有感受到 Web 的便利。

　　除了一般意义上的 Web，还有一个要单独拿出来讲的是手机上的网页游戏。

　　高品质的手机游戏，如果完全基于传统 Web App 即时下载的运行模式，根本无法启动运行。而针对一些轻小的休闲游戏，微信、QQ 空间、微博等平台基于其社交属性，很容易引起用户的交流和分享，给“打飞机”“神经猫”“2048”等看似简陋却极易传播的 HTML5 游戏带来了巨大的访问量，但这样的游戏又很难找到持久粘性。

　　HTML5 标准的设计者认为 Canvas 就是 2D HTML5 游戏的技术基础；但在实际的开发中，绝大部分 HTML5 手游开发商却选择 DOM 作为运行基础。根本不是为游戏定义的。但是基于 canvas 开发高品质游戏，对研发人员有很高的要求。DOM 是 HTML 的基本组成部分，所有的前端开发人员都会；而拥有 Canvas 商用开发经验的前端人员则凤毛菱角。Canvas 的 API 非常底层，如果基 Canvas 开发游戏，必须从最基础的元素开始构建帧画面，其开发成本并不亚于基于 Native。

　　综上所述，传统意义上的 Web App 应用模式，面临诸多挑战。但是传统 Web App 应用模式的问题并不意味着移动 Web 缺乏应用价值。恰恰相反，移动 Web 具备其他平台技术很难有的独特优势。基于开放的应用模式，移动 Web 可以在更大的应用场景下，充分实现其平台化价值。在移动端，Web App 与 Native App 最终将不是孰优孰劣的问题，而是 Web App 自身将融入操作系统的大平台中。

　　Web 的归 Web，App 的归 App

　　在移动端，社交平台内传播的内容形态，当前移动搜索可以访问的内容形态，当然还有手机浏览器，都是基于 Web 的。所以，在几乎所有的 App 应用领域，几乎所有的 App 开发商都必须提供基于移动 Web 的内容呈现形态，否则，将失去社交平台、手机浏览器、移动搜索等重要的流量入口——这就是移动 Web 技术的平台化价值。

　　所以，对于移动 App 开发商而言，存在一个普遍的需求：只开发一套基于 Web 的应用，就可以同时部署在应用商店、社交平台、手机浏览器，可以被移动搜索访问，甚至还可以被其他应用直接调用。以下是某电商的新版移动端解决方案，融合和 Web 和 App。

　　同时，如果想将 Web 与浏览器内核打包为 App，Web App 在手机浏览器中运行可能存在的问题将得到自然解决，例如：

• 功能缺陷可以通过 Native API 调用实现（Hybrid App 技术）；

• 杜绝与业务本身无关的操作元素，不产生操作混淆；

• 资源可以预先下载到本地，不需要运行时下载大量资源。

　　这个思路简单总结起来就是 Web 的归 Web，App 的归 App。但是这种思路也面临着一个问题，因为当前智能手机操作系统并不能很好地满足这个需求，当前应用 App 开发可用的内核平台运行效果很差。正如之前 36 氪讨论 HTML5 的文章中说的那样:

HTML5 标准本身涉及的技术并无任何障碍，截止 2013 年 90% 以上的 HTML5 的标准早已完成，但是迟迟无法定稿的原因则是各种利益集团的政治博弈。

　　不仅要优化，还要开放

　　再这样的局面下，其实是需要有一方出现强力推广自家的标准打破这种僵局。不管是苹果的 Safari 和 Google 的 Chrome，还是国内的大多数手机浏览器，都在基于 WebKit 不断优化浏览器引擎，也取得了很好的效果。但是这些引擎并不对第三方开放，开发者无法用他们来完成自己想要的 Hybird 开发。

　　在今年 9 月底，腾讯首先开放了 QQ 浏览器使用的 X5 内核，我认为这只是行业的第一步。顺便八个卦，这个内核很快也被微信采用了，这让我很意外。因为微信和 QQ 两家向来是不喜欢用对方的东西。

　　未来腾讯应当充分利用作为微信内核的优势，争取给 App 开发商提供真正一站式的应用开发服务支撑。 对其他手机浏览器内核厂商而言，如果面向移动 App 开放内核，同样可以获得广泛的需求空间；其他三方浏览器完全可以找到独特的差异化优势，也可以与 AppCan、PhoneGap 这些移动 Web 框架引擎巨头合作获得广泛的用户（应用开发商）资源。

　　一旦这样的整合完成后，对移动 App 开发商而言，只需要开发一次，就可以顺利适配微信、QQ、QQ 空间并打包为 Native App。对腾讯而言，借助这个内核，甚至可以直接打通包括应用宝、微信、QQ、QQ 空间、QQ 手机浏览器的完整的应用开发服务和应用分发产业链。

　　现在很多通过微信出现在我们面前的 HTML5 页面都是使用了腾讯的 X5 内核，比如各种 HTML5 招聘微门户，HTML5 邀请函还有最近的微信连 WiFi 弹出的商家营销页面。还有新浪新闻、凤凰客户端、知乎等平台也采用了腾讯 X5 的内核和云平台。

　　未来微信利用自己在用户技术方面的优势，“挟用户以定标准”，必然能推动国内 HTML5 开发向前推进。微信的心态也应该更开放。比如微信目前已经开始开放 API，支持从第三方 App 直接跳转微信公众号，但是必须经过微信的严格审核。如果未来采用腾讯 X5 内核的 Web 页面也可以直接跳转微信的各种服务，那想必也是极好的。

　　对其他手机浏览器内核厂商而言，如果面向移动 App 开放内核，同样可以获得广泛的需求空间；其他三方浏览器完全可以找到独特的差异化优势，也可以与 AppCan、PhoneGap 这些移动 Web 框架引擎巨头合作获得广泛的用户（应用开发商）资源。

　　除了手机浏览器之外，硬件和平台级厂商也应当对移动 Web 的运行性能和运行效果提供持续的平台支撑和优化，若干厂商早已在为之投入，例如 Intel 支持基于 CPU SIMD 指令来加速 JS 代码的执行，xDK，crossWalk 框架；ARM 一直在持续优化 WebKit 关键库、cocos2d-js，推出 NEON；iOS8 正式开放 webGL；Chrome Mobile 支持 WebGL，并且从 Android4.4 开始，系统自带 WebView 基于 Chromium（但还没有支持 webGL）。

　　不过这只是一个开始，未来开放的 Web 和 App 的融合还要解决很多问题：

• 提供针对移动 App 应用（而不仅仅是手机网页）的功能支持：传统上，Web 规范的使用对象是 Web 网页；但在今日，移动 Web 技术的用户已经远远不止是手机网页，而是大量的 Native App。移动 Web UI 控件的形态，应当与 Native App 的控件形态看齐，而不是与 PC 浏览器的 Web 形态保持规范上的一致。移动 Web 技术平台，应当更多地考虑如何基于 Web 技术实现 Native App 的内容体现和运行效果。

• 提升 JS 运行性能：JS 非常灵活的高级语言，其开发灵活的代价就是运行效率明显低于 Native 程序，因为 JS 在设计之初根本没有料想到将来会在手机这样的微型设备上运行。通过系统硬件和软件的改进不断提升 JS 运行性能，是需要芯片厂商、操作系统厂商、浏览器内核厂商持续解决的。

• 提升基于移动 Web 的渲染性能：笔者认为，操作系统、手机浏览器内核应用尽早实现和开放 webGL。webGL 的开放价值远不止于提供 3D 渲染，而是在于直接向 Web 应用开放硬件渲染能力。未来的渲染框架引擎，可以直接基于 JS+webGL 完成，而不需要依赖 Native 的渲染框架，这将帮助大量具备 HTML5 商用开发经验的团队灵活地实现和提供更有针对性的开发框架。甚至，DOM 体系的解析、布局和渲染，未来也可能基于 JS + webGL 直接实现。