手机上也就无需安装大量的,分析了HTML5的优劣势

作者:新美高梅

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

去年此时,W3C定稿了HTML5。我曾发表一篇文章《HTML

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

5终于定稿,为什么原生App世界将被颠覆》,这文章转载量很大,它阐述了HTML5的来龙去脉,分析了HTML5的优劣势并对未来发展做了一些预测。

Web的优势是

时隔一年,我们看看HTML5产业都发生了什么,那些基于理论的预测,哪些被实践了,结果又如何?

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

2015年初,Facebook宣布推出React Native开源框架。

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

2015年初,腾讯微信推出了JS SDK。

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

2015年中,阿里巴巴公司的Judy Zhu入选W3C Advisory Board,这是中国人在W3C组织中话语权最高的位置。

Web 没有真正提高开发效率

2015年中,HTML5中国产业联盟举行扩大会议,引入十几家会员单位

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

2015年中,Firefox副总宫力离职创业H5OS并获得巨额融资。

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

腾讯QQ玩吧成为重要的HTML5手机游戏平台。

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

360手机助手与DCloud合作推出流应用,开启HTML5替代原生的序幕。

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

从整体来看,2015年是各个巨头进军HTML5领域的探索年,不同的公司通过不同的方式在探索HTML5如何为其所用,在推进、验证、纠错、继续推进中不停迭代,并出现了一些非常亮眼的突破。

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

Facebook回归并发布React Native,并非拥抱HTML5

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

扎克伯格在2013年放弃HTML5的声明是HTML5历史上黑暗的一幕。2015年,Facebook终于回来了。不过这种回归略微尴尬的是:React

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

Native并非拥抱H 然是JS,但并不兼容HTML5。通过Facebook的自定义语法,React

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

Native实现了更高效率的渲染引擎,提升了性能表现。

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

React Native从年初召开发布会,然后发布iOS版,直到9月份Android版推出,中间也是在不停试水。

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

Facebook基于动态语言构建生态链的动力是十足的,作为全球最大的社交基础平台,Facebook的Web版本上活跃着广泛的三方应用,但手机上这套体系搬过不来。

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

Facebook自己的App是原生开发的,但三方应用如果也使用原生开发,是无法成为Facebook移动生态的一部分的。而基于HTML5的三方应用,在手机上的表现实在不佳,严重打击用户在手机上使用、购买这些三方应用的热情。而Facebook极大的盈利来源恰恰是从三方应用的收入中获取分成。

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

虽然基于动态语言构建生态系统的动力十足,但Facebook为何要另起炉灶呢?

Web 的归 Web,App 的归 App

当初Facebook放弃HTML5,就是因为HTML5的渲染效率在手机上达不到流畅标准,Facebook认为罪魁祸首是DOM和CSS3。而React

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

Native的原则就是No DOM,使用了完全不同的绘制引擎。

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

当初CSS3被设计的超级复杂,很大程度上是为了替

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

代Flash在HTML4年代酷炫的交互效果。在PC上硬件资源没问题,CSS3虽然复杂也能跑得流畅。但手机不同于PC,DOM和CSS重绘在低端机上并不流畅。

功能缺陷可以通过 Native API 调用实现;

但无论如何,自建标准是比较难的事情,如果仅在Facebook生态里自然没别人管,但如果做大了就又会像Flash一样遭遇巨头联合绞杀。但是React

杜绝与业务本身无关的操作元素,不产生操作混淆;

Native确实在倒逼浏览器引擎开发商反思渲染引擎应该如何优化。

美狮美高梅官方网站,资源可以预先下载到本地,不需要运行时下载大量资源。

腾讯在微信和QQ两大生态中,运用不同思路探索HTML5

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

腾讯也是社交巨头,和Facebook有类似的需求,围绕着腾讯巨大的用户群,有众多三方应用在这里掘金。不过腾讯有微信和QQ两套生态,这两个生态做HTML5的思路还并不相同。对微信而言,公众号就是它的生态,为了增强公众号的能力,微信推出了JS

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

SDK,它本质上是一种轻应用,强化了JS的能力,补充了十几类常用的API。公众号是以服务内容和应用为主的,JS

不仅要优化,还要开放

SDK的强化基本没有考虑HTML5游戏的需求。

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

虽然微信强化了JS

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

SDK,但公众号的性能和体验还是让用户不太爽的,切换页面的长时间等待、Back错乱等很多问题让人烦躁。从这个角度看,还是落后Facebook一筹。

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

另一方面,如何推进开发商使用JS SDK也是一件挠头的事情。本来滴滴出行内嵌在微信里的版本是可以通过微信JS

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

SDK来展现地图和语音输入的,但滴滴并没有强化微信内嵌版的体验。这里就暴露了微信的另一个问题:当一个App厂商自己也是巨头或者想成为巨头时,它必然不会依赖和强化微信里的入口,它会希望主推自己的独立入口。

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

回想张小龙做微信公众号的理念“再小的个体也有自己的品牌”和“消除中介”,这一切也是顺理成章。

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

与微信不同,QQ是另一套思路,QQ用户低龄化,爱玩游戏,通过HTML5游戏变现是QQ空间这个产品更关注的事情,于是腾讯在QQ空间App里推出了玩吧栏目,专门汇聚HTML5游戏,给这些游戏导流量,然后获取分成收益。目前玩吧汇聚了各种主流HTML5游戏,包括普通HTML5游戏和使用Cocos2d-HTML5、Egret等引擎的游戏。

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

2015年有不少渠道在探索HTML5游戏,包括浏览器和一些超级App,甚至包括滴滴出行也开设了游戏中心。但就目前的情况,大多数渠道都没有亮眼成绩。玩吧在众多渠道的胜出反映一个现状:HTML5游戏目前比较适合基于社交属性的轻度游戏。

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

业内还有一些开发商尝试把HTML5游戏引入到互动营销、客户服务以及多屏互动领域,这些有意义的探索或许在未来能给消费者和商家带来新的体验。

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

将HTML5应用于应用市场,360等企业寻求新突破点

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

应用市场对待HTML5与社交平台不同。应用市场不存在通过社交用户建立开放平台并变现的需求,应用市场是比较自由和单纯的发行渠道。

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

但原生应用的发行是一个很简单的工作,无法差异化的,各家就是拼自己的资源和流量占入口。于是应用市场也在寻找自己的突破点。360手机助手在2015年初上线了生活助手栏目,汇总了各种O2O厂商的服务,但不是让用户下载这些O2O厂商的原生App,而是直接打开HTML5网页。年中360还宣布对HTML5服务免流量,目前360生活助手里访问这些O2O厂商的HTML5

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

App可以不花通信流量费,费用由360买单。

O2O服务的集成发行其他巨头也很重视,百度在宣布200亿砸向O2O后,手机百度及各条产品都很注重O2O厂商的HTML5服务引入;小米也推出了小米生活,华为也在做华为生活,也都是类似思路。于是今年O2O厂商们有一个忙碌的工作就是把HTML5页面集成到各家渠道。由App分发升级为服务分发,这是应用市场自己的动力,但用户使用习惯的养成还需要时间。

OS国产化,从HTML5入手

2015年中,HTML5中国产业联盟举行扩大会议。这个联盟其实2013年就成立了,无奈当时整个产业太冷。随着基础环境的变化,越来越多的公司开始重视HTML5,并加入HTML5中国产业联盟一起推动产业发展。目前联盟的会员们已经形成从开发、测试、发行、培训、外包、融资、媒介宣传的一条龙HTML5产业服务能力。这也让中国的HTML5开发者有更强的信心和更方便的服务。

2015年中,Firefox副总裁、Firefox

OS的核心人物宫力博士,宣布辞职创业做H5OS,并获得紫光国际1亿美金的巨额投资。这笔巨款着实令人吃惊,且不说上半年疯狂股市是否引发泡沫,但H5OS指向的是紫光国际看好的中国政府国产化OS市场。自从斯诺登事件后,中国政府就反复强调国产化。在政府信息化领域围绕着很多IT公司,都试图从中寻找到新机会。

关于OS的国产化,有些人从Linux入手,另有一些人 ,从HTML5入手。鉴于Google和中国政府的关系, Chrome

OS是没人敢碰的,于是不少人在接触Firefo x OS,宫力博士的创业也在情理之中。

此外,华为也推出了国产安全手机,从芯片到系统都是国产的。

但手机上的OS比PC上的OS难做。做一个操作系统本就很难,操作系统出来后要建生态更难。PC上大多数业务本就是基于Web的,但手机上目前大多数优质App都是Native的,缺少优质的应用是目前所有做手机HTML5

OS的尴尬。如果希望在HTML5的OS上有足够好的体验,必然涉及扩展HTML5,但如果各家定义自己的扩展规范,让开发者为每家单独开发,这个事基本就无法推动了。产业各方合力,把扩展标准统一,才可能有机会。

流应用,HTML5产业又一大亮点

2015年在HTML5产业里最大的亮点是360和DCloud公司推出的流应用,它对于HTML5缺陷的弥补和优势的发挥,可以说做得淋漓尽致。

在360手机助手里搜索“大众点评外卖”,看到的按钮不是“下载”,而是“秒开”。

流应用?这是轻应用换个概念炒冷饭吗?

当然不是,点击秒开后并不是在线打开一个网页,仍然是安装一个客户端App,仍然如原生App般强大和流畅。只不过这个客户端App是JS代码,并像流媒体一样流式发行、边用边下,实现了5秒内完成客户端App的下载、安装、启动。App二次使用仍然在桌面点图标启动,应用使用体验也与传统原生App没有区别。

一定要注意,对于用户而言,使用App的功能体验与之前的原生方式并没有区别,但是获取App却秒开了。

读者肯定会问,怎么实现的?

这个新概念包括的新技术有点多,本文不负责科普所有实现过程。大概讲讲HTML5为何能达到原生的功能和体验。

流应用使用了一种强化的JS引擎(HTML5+),这种引擎能让JS调用操作系统的40万API,并将之前HTML5体验不佳的交互都改进为原生体验。

不同于React Native的反HTML5方案,HTML5+采取的方案是强化HTML5。

HTML5+兼容HTML5,并扩充40万原生API。对于DOM和CSS3动画效果不佳的部分场景,使用原生动画补足,比如窗体切换、下拉刷新的动态交互效果,不采用CSS3动画,而是通过JS调用了原生view动画。

相比React Native,强化HTML5的方案对开发商更友好,开发商只需把现有的HTML5版本做简单强化改造即可,而不是重新写一套No

本文由美狮美高梅官方网站发布,转载请注明来源

关键词: