Facebook 引发的 HTML5 危机

Facebook 引发的 HTML5 危机

2012/09/01 · HTML5 · 来源:
@AppCan 刘鑫     ·
HTML5

作者:AppCan 刘鑫

近期几个新闻堆叠在一起,颇有韵味。先是 WHATWG 和 W3C 在 HTML5
标准上分道扬镳
,继而“Facebook
移动应用宣布放弃 HTML5 的部分,改为纯 Native
方式开发
”,接着又传闻苹果 AppStore
肃杀基于 Web 技术的
App。这几个事件对移动互联网行业来说个个都是重磅炸弹,押注 HTML5
的受到不小的打击,唱衰 HTML5
发展的借此幸灾乐祸。HTML5真的只是一场政治斗争吗?到底 Facebook
为什么放弃 HTML5?现阶段 HTML5 到底出了什么问题?

Facebook 放弃 HTML5 主因:慢

“对于 Facebook 的 iOS
原生应用来说,它主要在三个方面有很大的速度提升:应用启动、共享新闻滚动还有图片点击查看。其总体速度大约提升了一倍。这个版本部分采用了
Facebook Camera 和 Facebook Messenger
两款应用的代码库:其中图片点击查看功能的代码是从 Facebook Camera
移植过来,而屏幕消息是从 Facebook Messenger
那克隆过来的。这个原生版本是由一个独立的团队开发,产品经理 Johnson
表示未来会充分利用公司的代码共享,也会适当向其他团队寻求帮助。”

上述摘自 Facebook 的官方博客。博客中介绍到 Facebook 的 iOS 原生应用放弃
HTML5
后速度得到大幅度提升
。大家不禁好奇,为什么
HTML5 会比原生 NativeApp 要“慢”很多?

在当前的移动终端设备硬件配置和操作系统优化水平的前提下,大部分基于 HTML5
开发的 Web
页面会出现延时加载展示的现象,也就是俗称的卡、慢。特别是在不同的视图界面(view)切换之间,这种卡和不流畅的现象会尤为严重。而
Native 应用不会出现这种情况。究其根源,在于浏览器解析的运作机制和原生
Native 的界面展示机制差异上。如下图所示:

 图片 1

红色框起来的部分是原生 NativeApp 的界面展示机制,简单的看起来就是 1
个步骤 ——
展示,因为所有的绘图和渲染工作都由系统直接完成。而红框以外的部分包括红框内的部分是
webkit 核心的浏览器解析页面的流程。相比 Native 的 1 个步骤,webkit
的解析过程可谓漫长而艰辛。历经解析、建立 Dom
树、获取对应资源、布局、建立渲染树、绘图到展示。所以不管移动终端设备硬件如何发展,这个差异是始终存在的,最多只是随着硬件的提升和软件的优化将这个差异收缩到最小甚至忽略。

更糟糕的是。Facebook 之前的 iOS 混合了 HTML5 的移动应用,使用 HTML5
绘图的页面在 HTML5 开发上也毫无技巧可言,基本沿用了主流前端开发框架
jQuery mobile 等的单 View 多 div
的机制。也就是在一个网页内绘制多个视图,页面之间的切换其实只是一个页面内不同区块的切换。这种方式加大了浏览器的渲染和绘制工作强度。并且在数据加载和流量上产生很大的负面影响。如果切换到新页面,之前的页面不进行销毁,则会加大运算量和增加内存占有,而如果销毁又会导致已经下载的数据失效,要重新载入,浪费流量。类似情况在中国的网络和设备情况下会尤为突出。所以
Facebook 不当的在 Native App 内混搭 HTML5 也难免引来用户怨言。

还有,一如报道中提到的,Facebook
这次的改进提升主要是“新闻滚动和图片点击”。如果了解 HTML5
的人,就会发现,这两点当然是“不应该在现阶段使用 HTML5
实现的”。为什么?笔者作为一个基于 HTML5 技术的 Hybrid App
系统的设计者,设计秉承的一个原则就是“凡是需要’动’的部分和需要大量运算的部分,就最好使用原生弥补,而不是一定要使用
HTML5 来实现”。新闻滚动,这种不停通过改变 Dom
树近而改变渲染再绘图展示的使用场景相比原生 Native
弱势是非常明显的。至于图片的部分就更不用多说了,这并不是 HTML5
眼下擅长的部分。HTML5
现在擅长的部分是数据量不大的页面、动画少的页面,特别是跨平台的开发。充分利用好
HTML5 的优势,尽量降低 HTML5 的弱势,学会用好
HTML5,才是现在这个时期使用 HTML5 开发的重点。可以说开发技巧很重要。

现阶段 HTML5 的问题:政治斗争

图片 2

“原生版本是一个独立团队开发的。”Facebook
公开的这一点也耐人寻味。原来客户端是 Native 与 HTML5
混合的方式,原来的团队也肯定有原生的开发能力,为什么非要一个独立团队重新耗费
6 个月进行重新开发?或许这里不能排除公司内政治因素,而 HTML5
成为一个牺牲品。HTML5
的政治不仅是一个公司内的,更是整个行业的。7月份,同为 HTML5 制定者的
WHATWG 和 W3C
表示无法继续合作,前者希望制定一个能够跟随市场或技术动态的标准;后者则要确立一个“死”的标准,一旦正式颁布再也无法修改。

WHATWG 和 W3C 的分道扬镳或许会成为 HTML5 发展的一个分水岭。WHATWG 背后有
Google、苹果,W3C
拉到了特立独行的巨无霸微软。标准是为利益服务的,曾经力推 HTML5
的苹果,现在也传闻在 AppStore 内打压基于 HTML5 开发的
App。那苹果到底是喜欢还是不喜欢
HTML5?喜欢也是真,讨厌也是真。过去乔布斯为了灭掉 Adobe 的 Flash,将
HTML5 当成冲锋枪,在移动端干掉了 Flash
之后,面对自己封闭生态系统的巨大利益和 HTML5
世界大同的愿景做出选择的时候,苹果当然毫无悬念的选择自己的利益。

《Web App
的挑战(三):入口之争》一文中,我有阐述自己的观点:入口之争”在现有移动操作系统设计架构下,浏览器很难和用户桌面争夺核心入口地位。苹果打造的
iOS 系统就是一个应用优先的系统,无论 HTML5 怎么发展,Web App
如何挣扎,浏览器如何砸钱,都抢不过用户桌面的入口地位。基于 HTML5 的 Web
App 的命运被苹果牢牢把控。Android 系统这个跟随 iOS
桌面入口理念的半山寨货也没有押注 Web App 而是将这个任务交给了 Chrome
OS。所以,不用炒概念,也不用谈未来,用 HTML5
开发原生应用,而不是仅仅套个外壳那么简单才是现阶段 HTML5
使用的重点和发展的重点。并且苹果封杀的也只是纯 HTML5 套壳的
App,对于使用混搭模式(包括 Facebook
之前的版本)的移动应用还是保持开放姿态,毕竟这种 HTML5
还是在苹果的生态系统内可控的运行着。

最后

Facebook 的 iOS 放弃
HTML5。幸灾乐祸也好,沮丧也罢。变的只是一个应用,HTML5
的势头和趋势不是一个企业可以逆转的。现阶段,真正的了解 HTML5,掌握 HTML5
的开发技巧和在恰当的地方用好 HTML5,才是把握机遇的重点。

 

 

 

赞 收藏
评论

图片 3

混合开发的直白解释是 Native 和 Web
技术都要用。但形式上,应用仍然和浏览器无关,用户还是需要在 App Store 和
Android Market 下载应用。只是在开发时,开发者以 Native
代码为主体,在合适的地方部分使用 Web 技术。比如在 iOS 中的
UIViewController 内放置一个 UIWebview(一个浏览器引擎,只拥有渲染
HTML,CSS 和执行 JavaScript 的核心功能)。这样,部分用户界面就可以在
UIWebView 中使用 Web 技术实现。

促使我们在移动开发中使用 Web 技术主要动力在于,相比于 Native 技术,Web
技术具有诸多优势:

高效率的界面开发:HTML,CSS,JavaScript
的组合被证明在用户界面开发方面具有很高的效率。

跨平台:统一的浏览器内核标准,使得 Web 技术具有跨平台特性。iOS 和
Android 可以使用一套代码。

热更新:可越过发布渠道自主更新应用。

这些优势都和开发效率有关。Web 技术具有这些优势的原因是,Web
技术是一个开放标准。基于开放的标准已经发展出来庞大生态,而且这个生态从
PC
时代发展至今已积累多年,开发者可以利用生态中产出的各种成果,从而省去很多重复工作。

在大型移动应用的开发中,项目代码庞杂,通常还需要 iOS,Android,移动 Web
和 桌面 Web
全平台支持。这种情况下,更高的开发效率就成了开发者不得不考虑的议题。这也是为何虽然移动端的
Web
技术在使用范围和性能上有诸多劣势,仍然有很多开发者付出努力,探索如何在移动开发中使用
Web 技术。

我们也是基于以上各种考虑,决定在豆瓣的移动开发中实践一些混合开发技术。

Rexxar 的背景

豆瓣在 2014 年推出一个主应用:豆瓣
App。这个主应用慢慢成长,逐渐覆盖了豆瓣在 Web
上的大部分功能。随着项目的扩大,产品线的扩展,豆瓣App
成为了一个需要同时提供 iOS,Android 和移动 Web
页面的多平台支持的服务。工程技术团队为了更从容地应对这种状况,开始投入较大的精力提高团队的开发效率。混合开发是其中主要的措施之一。

由于项目已经发展到一定程度,我们并不希望推倒以往的开发方式,也没有一切从头来的野心和勇气。只是希望在不影响
App 的性能前提下,在合适的地方使用 Web 技术部分地提高开发效率。而豆瓣App
中又确实存在部分页面是重度展示,并轻度交互的。这些页面恰恰适合使用 Web
技术来实现。

经过团队的一些努力,项目中部分页面已经使用 Web
技术实现,并取得了不错的效果。工程师使用 Web
技术可以以更快的速度完成产品需求,并且将一份代码部署到两个平台。开发效率得到了实质性提高。即使不提热更新,减少
Android
项目方法数这种附带好处,我们也已喜欢上这项技术,决定在豆瓣移动开发中推动混合开发技术的使用。

现在,我们将这个过程的主要产出:Rexxar
这个项目开源。一方面,是为了给大家提供一些借鉴的方向;另一方面,是为了提高项目本身的质量。我们知道还存在不少问题。所以,会悉心接受大家的意见和建议。

Rexxar 的介绍

Rexxar 是一个针对移动端的混合开发框架。现在支持 Android 和 iOS
平台。并有一个 Web 基础库。

团队中喜欢玩魔兽的同学将该项目命名为
Rexxar(《魔兽世界》中人物,出生于卡利姆多大陆的菲拉斯,同时具有雷骨兽人和南部菲拉斯野生食人魔两种血统)。

各平台代码仓库地址如下:

Rexxar
Web:https://github.com/douban/rexxar-web

Rexxar
iOS:https://github.com/douban/rexxar-ios

Rexxar
Android:https://github.com/douban/rexxar-android

Rexxar 主要由以下三部分组成:

Rexxar Route,我们使用 URL 来标识每一个页面。在 App 中通过指明 URL
跳转到此页面。所以,需要一个路由表。通过路由表可以根据 URL 找到一个
Rexxar Web 的对应资源来正确展示相应页面;

Rexxar Web,前端代码库,由 HTML、CSS、JavaScript、Image
等组成,用来提供在移动客户端使用的用户页面;

Rexxar
Container,一个前端代码的运行容器。它其实是一个内嵌的浏览器(WebView),我们为内嵌浏览器提供了一些必要的原生端支持,包括
API 的 OAuth 授权、图片缓存、Native UI 组件的调用等;现在有 Android 和
iOS 两个版本的实现。

在项目实践中,Rexxar Web 和 Rexxar Route 由一个项目实现,并部署于同一个
Web 项目中。

Rexxar Route

Rexxar Route 比较简单,只需要表达一个路由表即可。我们使用了一个 json
文件来表达路由表。给出一个路由表的例子:

{
    count: 4,
    items: [{
        remote_file: "https://img1.doubanio.com/dae/rexxar/files/orders/orders-70dbdbcb1c.html",
        uri: "douban://douban.com/orders[/]?.*"
    }, {
        remote_file: "https://img1.doubanio.com/dae/rexxar/files/related_doulists/related_doulists-1d7d99e1fb.html",
        uri: "douban://douban.com/(tag|tv|movie|book|music)/(\w+)/related_doulists[/]?.*"
    }   ],
    deploy_time: "Fri, 04 Mar 2016 11:12:29 GMT"
}

我们发布的每个版本的 App 安装包都会包含最新版本的 routes.json 文件。在
App 启动时,都会尝试下载最新版本的 routes.json。在遇到无法解析的 URL
时,也会去下载新版 routes.json。

Rexxar Web

Rexxar Web 是 Rexxar 前端实现。Rexxar Container 的实现和 Rexxar Web
的实现是分离的。Rexxar Container 对 Rexxar Web
使用何种技术实现并不关心。所以,你可以选择自己的前端技术和 Rexxar
Container 进行组合。比如,我们在业务层选择了 React 作为前端开发框架。

Rexxar Web 包括了三部分内容:

工具

一套开发 Rexxar Web 所需的打包,调试,发布工具。

公共的前端组件

通用的错误处理、Loading等效果

页面点击反馈效果

List 的支持

对 Rexxar Container 实现的 Widget 的调用

ActionBar 的 title 定制

ActionBar 的 button 定制

Dialog

下拉刷新

Toast

有了这些组件,我们日常产品开发的难度就降低了。普通移动开发工程师经过一段时间的学习,也可以像前端工程师一样,以
Rexxar 为工具为 App 做一些产品开发了。这部分可以视为一个纯粹的前端项目。

Rexxar Container