HTML5会砸掉iOS和Android的饭碗么?

 我们第一次谈论HTML5要改变世界大概是因为乔布斯,他坚持在iOS上不兼容Flash,在Adobe统治多媒体开发的那个年代,这需要付出极大的勇气。这么多年过去了,虽然所有人都在谈论HTML5,但是大部分人甚至都忘了它还是一个仍在完善中的体系。

  

   2007年W3C(万维网联盟)立项HTML5,直至2014年10月底,这个长达八年的规范终于正式定稿。接下来,HTML5将真正开始颠覆原生 (Native) App 世界。虽然这种危言耸听已经让人有点厌烦。但是如果回顾HTML这些年走过的路,你就不会再怀疑它的能量。

  

  一、HTML5 的诞生

  

  自W3C于1999年发布HTML4后,Web世界快速发展,一片繁荣。人们一度认为HTML标准不需要升级。一些致力于发展Web App 的公司另行成立了WHATWG组织,直到2007年,W3C从WHATWG接手相关工作,重新开始发展HTML5。

  

  HTML5的发展史,有用户的需求在推动,有技术开发者的需求在推动,更有巨大的商业利益在推动。在互联网的早期,对用户而言,能打开浏览器接入到互联网世界就是一个神奇的事情,但互联网发展到2005年前后,开始出现下一个变化,就是宽带互联。

  

   随着宽带的普及和电脑性能的增强,人们不再满足于单纯的通过互联网看新闻、收发邮件,消耗更高带宽的娱乐产品开始出现,就是流视频和网页游戏。其实视频 和游戏是古老的需求,在互联网不普及的时候,需求的满足方式是离线传输的VCD和游戏光盘;后来互联网逐渐普及,人们更改了使用方式,通过下载软件+本地 媒体播放器来看视频,下载体积较大的端游玩游戏。

  

  但是对消费者体验更好的新方式还是出现并颠覆了以前的一切,那就是流媒体和网页游戏。Youtube等公司把握住潮流飞速崛起,各种页游公司也如雨后春笋

  

   HTML标准没有把握住产业的变化及时演进,浏览器产品也未升级,这块新需求被浏览器插件满足了,那就是Flash。这个部署在亿万浏览器里的商业插件 俨然成为事实标准。2005年Adobe巨资收购Macromedia,把Flash收归旗下,紧接着大幅推广FLV流媒体和 action script语言,很明显这桩收购可以列为IT 并购的经典案例,FLV流媒体和Flash游戏风靡互联网,Adobe在新的产业升级中攫取了大量的利润。

  

   除了Flash这个商业产品成为了事实标准,W3C还面临一个尴尬,就是另一个私有扩展协议的制造者—IE。IE 当时在桌面浏览器占有垄断地位,并且扩展了大量的IE Only语法,开发者完全不知道这些语言是谁定义的。整个web世界,就被两家公司微软+Adobe 绑架了。

  

   很多IT巨头都坐不住了,尤其是苹果Google。PC 操作系统的世界难有突破,Web浏览器被苹果寄予厚望;新贵Google虽然大量赞助Mozilla,但并未对IE的地位产生实质影响,收购了 YouTube后发现命脉在Adobe手里,也是非常难过,而且Google每年给IE的搜索框和Adoble FLV缴纳的费用真不是小数目。

  

  既然大家都是W3C的主要单位,好吧,我们重新开始做HTML5吧。是的,HTML5其实就是这么诞生的。

  

  二、HTML5第一阶段:Web增强与破垄断

  

  自HTML5诞生以来,一共经历了两个阶段,分别是Web增强和移动互联网。我们先从Web增强说起。Web体验的丰富增强主要表现在:

  

  WebApp HTML5新增了离线存储、更丰富的表单(比如 Input type=date)、js 线程、socket、标准扩展 embed、css3

  

  流媒体HTML5新增了audio、video

  

  游戏HTML5新增了canvaswebgl

  

  当然HTML5还为搜索引擎语义分析做了优化,比如新增Header和Section等标签,也在无障碍等领域做了不少工作,这些不再多述。HTML5 在流媒体和游戏方面的努力,成功的遏制了Flash的发展,然后就该遏制IE私有语法了。

  

   在 HTML5 标准的升级过程中,苹果和Google同时也看到了浏览器市场重新洗牌的机会,他们一方面参与HTML5的规范,一边在浏览器产品上发力。Apple首先 开始大力发展Safari,建立WebKit开源项目,迁移Safari到Windows平台;Google起初是赞助Mozilla开发 Firefox,后来自己开发了v8引擎,合并WebKit,于2008年正式推出Chrome。“IE 的私有规范+Flash不是标准,我们才是标准” 这样的口号在新一代浏览器大战中打响,IE 瞬间成为千夫所指的垄断代表,甚至成了阻碍Web发展的**(当时IE6已数年未更新,并且丝毫不惧Firefox的发展)。

  

  偏偏微软此时也出了晕招,推出了一系列即不完整支持规范又互相不兼容的IE7、8、9、10,彻底失去了开发者的支持。

  

  Adobe的Flash被遏制,与Web霸主的位子擦肩而过;IE的私有标准被遏制,并且造成IE市场份额不停下滑,直到IE最新的移动版本反过来开始支持WebKit语法,真是令人唏嘘。不知道HTML6是不是该打倒WebKit垄断。

三、HTML5 第二阶段: 移动互联网

  

   随着Chrome和Safari的高歌猛进,以及IE+Flash的衰落,HTML5告一段落,进入了下一个时代——移动互联网。HTML5的跨平台优 势在移动互联网时代被进一步凸显。HTML5是唯一一个通吃PC、Mac、iPhone、iPad、Android、Windows Phone等主流平台的跨平台语言。Java 和Flash都曾梦想这个位置,但梦断于iOS。此时人们纷纷开始研究基于HTML5开发跨平台手机应用。很多人当时认为,原生应用只是过渡,就像当年从 C/S 结构转变为B/S结构一样。而且学习Objective-C和Java很费劲,我既然会网页开发,为何不试试HTML5。

  

   W3C此时成立了Device API 工作组,为HTML5扩展了Camera、GPS等手机特有的API,然而麻烦的是,移动互联网初期的迭代太快了,手机OS在不停的扩展硬件API,陀螺 仪、距离感应器、气压计。每年手机OS都有大版本更新。而W3C作为一个数百家会员单位共同决策的组织,从标准草案的提出到达成一致是非常复杂的过程,跟 不上移动互联网初期的快速迭代。

  

  PhoneGap的出现,给开发者打开了一扇窗。很多人期待 PhoneGap不停扩展API,来补充浏览器的不足。Adobe看到PhoneGap仿佛看到了重振江湖地位的希望,但在Adobe收购 PhoneGap后,又发现这个东西问题很多,而且开源使得Adobe无法像Flash那样获取商业利益,于是就把PhoneGap捐给了Apache, 改名为Cordova。

  

  因为各种原因,Cordova 的定位最终没有成为浏览器的强化,而走向了混合式开发。基于当时的背景,他们认为原生是不可替代的,“原生+HTML5” 的混合模式更有意义。所以现在Cordova的使用往往是“原生工程师+HTML5 工程师”一起协作完成App。

  

   这时Facebook加入了W3C,牵头成立了Mobile Web工作组。Facebook是混Web圈的,并且在手机OS上并无自己的领地,他不喜欢被苹果和Google掌控的原生应用生态系统。Mobile Web这个工作组的重要目标就是让HTML5开发的网页应用达到原生应用的体验。然而,事与愿违,它不努力也就算了,结果是努力了却失败了。2012 年,Facebook 放弃HTML5的新闻充斥了全世界的IT媒体,HTML5 瞬间被打入冷宫。

  

   Facebook为何放弃HTML5?核心是当时基于HTML5真的做不出好的移动App。对比Twritter等竞争对手的原生 App,Facebook的 HTML5版本实在无法让用户满意。比如Push功能,到现在HTML5的推送和原生的推送体验差距依然巨大,更不用说HTML5应用的页面切换白屏、下 拉刷新 / 侧滑菜单不流畅等众多问题。看着原生工程师轻松实现摇一摇、二维码、语音输入、分享到朋友圈等功能,更是让HTML5工程师感觉自己站错了队。

  

  即使Facebook不喜欢被控制,也不能拿被用户抛弃来冒险。而且Facebook并没有掌握关键点—手机浏览器内核。如果浏览器不跟上,其他都是白搭。

  

   而浏览器在手机上的表现是什么呢?先看Google,Chrome性能虽高,但Android上的浏览器却并非Chrome,而是WebKit改出来的 一个蹩脚的Android浏览器;再看苹果,iOS 上不允许其他浏览器引擎上架App Store,而且其他使用Safari引擎的应用也无法调用苹果自己的JavaScript加速引擎Nitro。结果是苹果和Google不但不在浏览器 上积极实现HTML5关于移动App所需的规范,反而对HTML5做出种种限制。

  

  不管是当时硬件能力不足,还是手机OS厂商的故意限制,总之结果很明显:在移动互联网的初期,一定是原生应用生态系统的天下,iOS 和Android首先把自己变成老大后,其他小弟才能寻觅到成长的机会。

  

  Facebook也好,PhoneGap也好,想在移动互联网初期就分一杯羹是分不到的,但坚持下来,机会往往会出现。

  

  四、HTML5 这回真的来了

  

   HTML5在这个时间定稿,不晚不早,硬件性能更强、手机OS迭代速度下降。随着HTML5标准定稿,一切纷争将告一段落,现在,属于HTML5的时代 到来了。这个曾让人满怀希望,又被Facebook等众多满怀希望的开发者放弃的技术,现在会告诉大家,曾经让各位失望的原因,现在已经不存在了!这听起 来有些惊人,大家不禁要问:是真的吗?让我们细细分析。

  

  业内俗称HTML5有“性功能”障碍。即HTML5性能不如原生、开发工具不如原生、能力调用不如原生。

  

  这几个问题导致开发者无法使用HTML5做出与原生一样的App。然而,不管是硬件升级还是OS 厂商策略变化,以及相关软件技术的成熟,已解决了HTML5的“性工能”障碍。

  

  移动端硬件军备竞赛2011年,iPhone 4s的CPU是A5,现在iPhone 6是A8,按苹果的历次发布会的说法,速度共提升了7.5 倍。这3年间7.5 倍的速度提升,抹平了太多HTML5的性能问题。

  

   苹果、Google的策略变化,Google在2013年底发布的Android 4.4,内置的Webview不再是蹩脚的Android WebKit浏览器,而是 Chromium。2012年iPhone 5发布后,HTML5在iOS 上的表现已令人满意,Safari 独家的JavaScript 加速引擎Nitro不再那么重要,不过在iOS 8发布后,苹果还是很识趣地取消了三方程序调用Nitro的限制,现在任意浏览器或应用调用iOS的UIWebview都可以利用Nitro加速。两大手 机操作系统霸主和浏览器巨头的态度发生了变化,使得HTML5在手机上的发展不再受限,而且这个变化不可逆只能继续向前,这种变化势必会产生深远的影响。

  

  软件技术的成熟PhoneGap的发展虽然放缓,但其他产品技术却成熟了。2014年的iWeb大会上,众多厂商的产品提供了面向开发者免费或开源的HTML5性工能障碍的解决方案。

  

   我们都知道浏览器的默认控件样式和原生控件样式差别很大,一个高性能的、样式体验与原生控件一样的UI框架是非常重要的,之前jQuery Mobile等产品的因性能不足,所以难当此任。我们公司在iWeb大会上发布了系统的HTML5 “性工能缺失”的解决方案,包括解决HTML5性能问题的手机端引擎、超快的HTML5 开发IDE产品HBuilder、还有把40 万原生API 封装成JavaScript对象,以解决 HTML5 能力不足问题的Native.js 技术。

  

   英特尔公司发布了Crosswalk引擎,可以让Android 4.0-4.3的手机上的应用打包Chromium引擎而不是Android WebKit。虽说未来 Android 4.4 会占据更多市场份额,但目前主流的Android手机的系统版本毕竟还是 4.1、4.2。

  

  在专业方向上很多公司也做出了不错的成绩。触控的Cocos2d-html5、Egret runtime和Ludei CocoonJS强化了Canvas的表现,让 HTML5游戏体验更好;UC、猎豹等手机浏览器也强化了音视频播放的表现。

  

  不管是硬件升级、软件成熟,还是操作系统厂商策略变化,都在强力推动HTML5的爆发。

  

   不过要注意,我说的HTML5爆发,不是指手机浏览器爆发。有人说HTML5不好,因为用户讨厌打开浏览器输入URL 的过程。我想说这种想法是对HTML5的片面理解。HTML5!=传统浏览器,虽然编程语言还是HTML、Javascript、CSS,但发行方式绝不 是传统网站那么简单。HTML5 应用的入口,反而很少是启动浏览器输入URL,它可以是存在于手机桌面的图标、也可以来自超级App(如微信朋友圈)、以及搜索引擎、应用市场、广告联 盟。到处都是它的入口。它的入口,比原生App更多。  

五、原生App的颠覆

  

  HTML5的“性工能”障碍得到解决,可以接近原生App的效果,所以它就可以替代原生App吗?很多人认为,即使HTML5会发展的比现在好,也将是与原生App各占一部分市场的格局,要求不高的长尾应用会使用HTML5,而主流应用仍是原生App的天下。

  

  但我认为这样的想法很危险,就像HP的高层告诉沃兹:谁会在家里摆一台电脑呢?未来HTML5肯定会颠覆原生App。“性工能” 障碍的消除,只是HTML5的劣势被削弱,但劣势被消除后,它的优势就会大放异彩,HTML5的优势是什么?对开发者来说:

  

   跨平台 在多屏年代,开发者的痛苦指数非常高,人人都期盼HTML5 能扮演救星。多套代码、不同技术工种、业务逻辑同步,这是折磨人的过程。有点类似个人电脑早期世界,那个时候的每家电脑都有自己的操作系统和编程语言,开 发者疲于做不同版本,其实 DOS 的盛行也很大程度是因为开发者实在没精力给其他电脑写程序。跨平台技术在早期大多因为性能问题夭折,但中后期硬件能力增强后又会占据主流,因为跨平台确实 是刚需。

  

  快速迭代 移动互联网是一个快鱼吃慢鱼的时代,谁对用户的需求满足的更快,谁的试错成本更低,谁就拥有巨大的优势。互联网产品大多免费、且有网络效应,后入者抢夺用 户的难度非常大。使用原生开发,从招聘、开发、上线各个环节的效率都慢一倍以上,而且参与的人越多,沟通效率往往拖慢不止一倍。

  

  减低成本 创业者融资并不容易,如何花钱更高效非常重要。如果你使用原生开发的App和竞争对手使用HTML5开发的App没什么区别,但你的开发成本高出一倍,我相信没有投资人会喜欢给你投钱。

  

  导流入口多 HTML5应用导流非常容易,超级App(如微信朋友圈)、搜索引擎、应用市场、浏览器,到处都是HTML5的流量入口。而原生App的流量入口只有应用市场。聪明的HTML5开发者当然会玩转各种流量入口从而取得更强的优势。

  

   分发效率高 前段时间微信朋友圈风靡一时《神经猫》,这个游戏如果放到Appstore,绝对没有那么多流量,超级App带来的流量,远大于原生应用市场。假如微信允 许游戏在桌面创建快捷方式、假如游戏后续升级解决持续娱乐问题,未来不可想象。除了入口多、流量大,导流效率高也不可忽视,谁都知道:页游和端游打同样的 广告,广告变用户的转化率,页游远远高于端游。

  

  HTML5 对用户的好处是:和流量入口多、分发效率高相对应的。大幅降低使用门槛。用户眼睛看到一个兴趣点,点击后,就应该立即开始满足用户需求。比如流媒体可以立 即看,页游可以立即玩。而目前的原生应用市场,用户需要这样操作:选一个应用、等待下载、确认权限、等待安装,然后点击打开。这样糟糕的体验迟早要被颠 覆。不管是App、游戏还是音视频,未来都将即点即用。谁先满足用户这个需求,谁就制胜。

  

  这就是所谓“天下武功,唯快不败”。分析至此,我们可以明显的看出,不管是站在最终用户角度、还是站在开发者角度,HTML5必将取代原生应用当前的位置。并由此引发一系列颠覆。

  

  六、还有什么会被改变?

  

  HTML5的爆发,原生App生态系统的颠覆,是一场产业革命,很多角色都会受到影响,我们来预测一番。

  

  标准的HTML5引擎并不能解决HTML5的所有问题,拥有大流量入口的互联网巨头,莫不在思考内嵌更优秀的增强引擎。腾讯推出了X5浏览器引擎,就是看中这个机会。

  

   目前各路浏览器厂商、应用市场厂商、甚至rom厂商,都在努力整合更优质的浏览器引擎。假使微信内嵌的webview可以运行更优秀的canvas游 戏、假使360手机助手可以发行即点即用的HTML5应用并且能力体验与原生一致、假使小米rom内置更强大的 webview使得所有HTML5应用在小米手机上运行的更流畅。所有巨头都会闻风而动,没错,这场战役会是移动互联网世界的二次世界大战。

  

   应用分发市场将面临洗牌,由于超级App的巨大流量能轻易成为HTML5应用的入口,并且会形成大者更大的效应,传统的应用商店、甚至线下预装,这些流 量不足和效率偏低的发行模式将被挤出市场主流。本身也是超级App的大流量应用商店,如果转型得当,也将以发行HTML5应用为主。

  

  原生的广告和统计SDK提供商会面临尬尴,Google、百度等基于网页的广告和统计服务会取得更大的优势。开发者不再需要打包 SDK,引入一个Script即可。

  

   开源技术将在移动互联网领域更加流行。HTML的开放性造就了大量的开源产品,也反向促进了HTML的繁荣。在Github上有大量的JS 框架,而原生的开源代码数量相比甚少。而未来移动互联网世界将因为开源而发展的更迅速,这里也同样存在类Github厂商的机遇。

  

   早期HTML只需要记事本写几个Tag,中期的HTML、JS、CSS比较复杂,需要更高级的文本编辑器,但HTML5到来后,它的代码量、复杂度、开 发模型将与原生开发看齐,需要类似XCode、Eclipse等专业的IDE工具来解决开发、调试的问题。一些以会使用记事本写代码为荣的开发者,将面临 思路转换甚至被更高效的开发者淘汰。

  

  HTML5的强大会引发很多安全问题,并且解决思路与原生不一样,业内有可能会出现新的安全厂商领导者。

  

  七、结语

  

  写到结尾,感觉话题有点大了。其实未来如何发展是没人能准确预测的,变量非常多。但我想让用户和开发者都更方便的趋势是不会错的。欢迎大家一起讨论HTML5的问题,在争议中提炼真知。

时间: 2024-10-13 05:18:40

HTML5会砸掉iOS和Android的饭碗么?的相关文章

html5写链接打开ios和android本地应用

1.在html中设置链接 <a id="open-app" href="[scheme]://[host]/[path]?[query]">打开应用</a> href="[scheme]://[host]/[path]?[query]" scheme可以自己在app内部设置成任意的,把android和ios的设置成一样的 2.若本地应用存在,直接打开app:若不存在,计时一段时间跳到appstore 需要判断ios还是an

html5图片上传时IOS和Android均显示摄像头拍照和图片选择

最近在做信开发时,发现<input type="file" />在IOS中可以拍照或从照片图库选择,而Android系统则显示资源管理器,无拍照选项,网上查找资料,改为<input type="file" capture="camera">后,Android可显示相机和文档,但IOS则只有拍照选项了,最后通过判断设备类型使在IOS和Android下均可以显示拍照和图库选择,代码如下: var u = navigator.u

ios和android适配

一些情况下对非可点击元素如(label,span)监听click事件,ios下不会触发 解决方案:css增加cursor:pointer; 三星手机遮罩层下的input.select.a等元素可以被点击和focus(点击穿透) 问题发现于三星手机,这个在特定需求下才会有,因此如果没有类似问题的可以不看.首先需求是浮层操作,在三星上被遮罩的元素依然可以获取focus.click.change),有两种解决方案: 1.是通过层显示以后加入对应的class名控制,截断显示层下方可获取焦点元素的事件获取

《React-Native系列》19、 ListView组件之上拉刷新(iOS和Android通用)

ReactNative提供了RefreshControl下拉刷新组件,但是没有提供上拉刷新组件,上拉刷新在App中是很常用的. 今天我们来实现一个iOS和Android通用的上拉刷新功能. 下面简要介绍下我实现的思路. 如果你对ListView的基础知识不是很清楚,建议先移步:<React-Native系列>16. RN组件之ListView 思路: 1.常量定义: const moreText = "加载完毕"; //foot显示的文案 //页码 var pageNum

HTML 5 会让iOS和Android开发者转行吗?

我们第一次谈论 HTML5 要改变世界大概是因为乔布斯,他坚持在 iOS 上不兼容 Flash,在 Adobe 统治多媒体开发的那个年代,这需要付出极大的勇气.这么多年过去了,虽然所有人都在谈论 HTML5,但是大部分人甚至都忘了它还是一个仍在完善中的体系. 2007年W3C(万维网联盟)立项 HTML5,直至 2014年10月 底,这个长达八年的规范终于正式定稿.接下来,HTML5 将真正开始颠覆原生(Native) App 世界.虽然这种危言耸听已经让人有点厌烦.但是如果回顾 HTML 这些

基于IOS和Android设备MDM技术方案服务价格

导读:前段时间 www.mbaike.net 博客被恶意攻击,导致程序崩溃,目前已经替换了以前的Wordpress程序,现提供IOS和Android版本MDM的代码和相关文档咨询服务. 一.IOS版MDM服务内容及价格: 套餐一:IOS端MDM Server代码(提供MDM Server端的代码和部署文档,不含后期技术支持) 3000元套餐二:IOS端MDM开发技术顾问(提供MDM开发的顾问服务,协助理解MDM原理流程及搭建MDM Server工作的咨询) 1500元套餐三:IOS端MDM全部服

「Unity」与iOS、Android平台的整合:3、导出的Android-Studio工程

本文属于「Unity与iOS.Android平台的整合」系列文章之一,转载请注明出处. Unity默认导出的是Android-Eclipse工程,毕竟Eclipse for Android开发在近一两年才开始没落,用户量还是非常巨大的. 个人认为AndroidStudio非常好用,能轻易解决很多Eclipse解决不了或者很难解决的问题. 所以我将Unity导出的Andoid工程分为Eclipse和AndroidStudio两部分. 不过我之后的相关内容都会使用AndroidStudio,希望依然

Unity3D 语音接入适用于pc、ios、android

语音接入 考虑到pc与ios.android三端的混服情况,所有录音的格式均存储为mp3格式,也是unity推荐的音频文件方式 前提:目前比较成熟的语音模块由科大讯飞平台提供的,目前我们需要的功能是把语音转化成文字,因此我们只需要下载相应的语音识别模块就可以了. 1)进入科大讯飞官网下载相应平台的sdk,目前我们只需要免费的语音识别就可以了,要创建相应的应用才能下载,里面的demo提供边录音边翻译的功能. 2)pc端的没有提供边录边能,要想在pc版进行录音可引入第三方库进行录音或者使用unity

基于iOS,Android的服务器证书失效检测

1.前言 在目前的iOS,Android手机上,当手机应用进行SSL通信时,手机端默认是不会进行服务器证书是否失效的监测. 在iOS上,系统是会定期获取所访问服务器的证书信息然后出存在本地. 在Android端,系统是不会进行任何服务器证书的监测. 2.影响 如果应用在与服务器进行SSL通信时不进行任何的证书有效性检测会造成用户信息泄漏等安全问题. 3.解决方法 服务器证书有效性检测有两种方法,CRL检测和OCSP检测. OCSP检测主要的好处是时效性更有效率.本文主要从OCSP角度介绍实现方法