当前位置：首页 > KM&CC-知识管理与协同商务 > 移动商务 > 正文

走向开放的移动 Web——写在腾讯 X5 内核开放之时

来源：科极网

2014/9/28 14:41:22

大中小

第三方浏览器开始开放内核，是移动 Web 的平台化价值被行业充分认知的标志性事件，几乎所有 App 应用领域都可能从中受益，Web App 将融入 Native App 体系，而移动 Web 和手机浏览器内核技术本身也将迎来新的发展机遇。

分享到：新浪微博腾讯微博

本文关键字： Web 腾讯 X5 内核浏览器

行业内各种统计都显示，绝大部分用户日常使用的 App，只有 10~20 个左右，并不存在用户为了日常需求而被迫频繁安装大量 App 的情况。

在访问路径上，用户使用 Native App，只需要找到 App 图标在桌面上的位置；而若要通过手机浏览器或者其他移动 Web 平台，则需要首先找到浏览器图标，再在手机浏览器内部的找到相应的图标或链接。

Native App 会把大量的资源信息预先下载安装到本地；而基于传统移动 Web 的访问模式，则非常可能需要在访问内容时才同时下载所有资源信息，其访问效率和内容展示效果与 Native App 相比都存在劣势。

传统 Web App 的应用模式是在操作系统与应用之间插入一个自有的操作体系和业务体系；这在 PC 上可行，在手机端则面临挑战。

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

传统手机浏览器、移动搜索等 Web 平台一直试图在其自身操作范畴内建设一个大而全的 Web App Store 体系，甚至，部分手机浏览器和移动搜索 App 将其 Home 页面设计为非常接近系统桌面的形态。这本身就可能混淆用户的认知，既然用户在系统桌面上就可以满足绝大部分日常需求，为什么还要进入某个 App 去访问一个跟系统桌面非常类似的 Web App 体系呢？

“轻应用”一度成为 Web App 切入系统桌面的探索，但各个巨头推出的“轻应用”仍然试图将 Web App 限定在其手机浏览器的操作范畴内。当用户从系统桌面打开“轻应用”快捷图标后，应用界面中往往会出现与该应用自身毫无关系的手机浏览器操作菜单。这样的设计，反而会给用户增加理解和操作的负担。

那么 PC 浏览器的操作元素在智能手机上是否必要？所有的手机浏览器，基本操作元素都来自 PC 浏览器，包括：菜单栏、网址&搜索框、多窗口（Lable）等。不过，在寸土寸金的手机屏幕，这些元素都是必须的吗？

事实上，当下主流的 App，包括与手机浏览器类似同样支持 Web 访问的 App 例如：微信、QQ 空间、资讯类 App（今日头条、Zaker…）、移动搜索客户端（百度，搜狗，360…），都不提供（或刻意回避）单个 App 内多窗口、多任务的设计，而采用更为简单的单一内容访问模式。手机浏览器基于其历史原因，多窗口似乎不得不成为标配，但用户真的需要吗？

在功能机时代，系统桌面不是多任务的，手机浏览器的多任务会给用户带来极大的便利；但智能手机系统本身就是多任务、多窗口的，单一 App 内的多窗口，给手机应用带来了多级多任务体系，是否仍然会让用户感到便利？

当下，PC 端游、PC 页游、手游（“手机端游”）三大领域各领风骚，而手游的市场空间更是年年翻番。但是，基于 Web App 的“手机页游”的发展却远不能与之匹配，为什么？

首要的还是带宽的影响：高品质的手机游戏，需要大量的资源（动辄几十甚至数百 M 图片和音效）。如果完全基于传统 Web App 即时下载的运行模式，根本无法启动运行。如果手机页游基于预下载等技术手段，则用户访问的体验其实就等同于 Native App。

而针对一些轻小的休闲游戏，微信、QQ 空间、微博等平台基于其社交属性，很容易引起用户的交流和分享，给“打飞机”“神经猫”“2048”等看似简陋却极易传播的 HTML5 游戏带来了巨大的访问量，但这样的游戏又很难找到持久粘性。

更深的原因则是行业对移动 HTML5 游戏技术的认知存在信息不对称：HTML5 标准的一个重要组成部分是 canvas 元素，标准的设计者认为 canvas 就是 2D HTML5 游戏的技术基础；但在实际的开发中，绝大部分 HTML5 手游开发商却选择 DOM 作为运行基础。要知道，DOM 是为网页的布局而不是根本不是为游戏定义的，这是为什么？

事实上，canvas 的 API 非常底层，如果基于 canvas 开发游戏，必须从最基础的元素开始构建帧画面，游戏程序必须自行构建和对象体系，其开发成本并不亚于基于 Native；同时，canvas 的 API 体系与智能手机的硬件渲染机制 OpenGL 并不匹配，很难有一种通用的模式能够提升基于 canvas 的手游游戏运行效率。所以，基于 canvas 开发高品质游戏，对研发人员有很高的要求。当然，行业中有大量的基于 canvas 的框架引擎，但其学习成本本身就是一种负担。

而基于 DOM 开发游戏，虽然执行性能远远无法与 Native 游戏匹配，但由于 DOM 体系本身就基于对象化机制，实现页面元素的布局、操作事件的获取都极其方便，其开发成本大大低于基于 canvas 或 Native App；对于实时性能要求不高的手游（典型如棋牌类游戏），DOM 是极好的技术选择。

要知道：DOM 是 HTML 的基本组成部分，所有的前端开发人员都会；而拥有 canvas 商用开发经验的前端人员则凤毛菱角。

所以，HTML5 手游领域发生了一个并没有被行业普遍意识到的问题：若干技术平台开发商聚焦在提升 canvas 游戏的执行和渲染效率；而大量真正基于 HTML5 的手游开发商却不使用 canvas。同时，大量的 HTML5 手游并不是基于传统意义上的 Web App 形态运行，而是打包为 Native App 形态，甚至从不宣传其基于 HTML5。

综上，传统意义上的 Web App 应用模式，面临诸多挑战。

但是，传统 Web App 应用模式的问题并不意味着移动 Web 缺乏应用价值。恰恰相反，移动 Web 具备其他平台技术很难有的独特优势。基于开放的应用模式，移动 Web 可以在更大的应用场景下，充分实现其平台化价值。

在移动端，Web App 与 Native App 最终将不是孰优孰劣的问题，而是 Web App 自身将融入操作系统的大平台中。

开放手机浏览器内核：Web App 融入 Native App 体系的契机

让我们看两页 2014 年 iWeb 大会某 App 开发商的 PPT，它清楚地描述了 App 开发商面临的典型问题和解决方案：

在移动端，社交平台（微信、微博、QQ 空间、QQ）内传播的内容形态，当前移动搜索可以访问的内容形态，当然还有手机浏览器，都是基于 Web 的。所以，在几乎所有的 App 应用领域（除手机游戏，系统类应用，以及有特殊技术需求的应用外），几乎所有的 App 开发商都必须提供基于移动 Web 的内容呈现形态，否则，将失去社交平台、手机浏览器、移动搜索等重要的流量入口——这就是移动 Web 技术的平台化价值。

责编：李玉琴