有一个词"手机网站"(mobile web),指供手机浏览的网站,但它是不存在的。
人们提到"移动互联网"的时候,其实专指另外一样东西:手机App。
一、Web App vs. Native App
比起手机App,网站有一些明显的优点。
- 跨平台:所有系统都能运行
- 免安装:打开浏览器,就能使用
- 快速部署:升级只需在服务器更新代码
- 超链接:可以与其他网站互连,可以被搜索引擎检索
但是,现实是怎样呢?
(1)体验差。手机App的操作流畅性,远超网站。
(2)业界不支持。所有公司的移动端开发重点,几乎都是原生app。
(3)用户不在乎。大多数用户都选择使用手机app,而不是网站。
如果将来有一天,Web app会成为主流,一定有一个前提,那就是它的性能可以赶上Native app。
二、为什么Web app有性能瓶颈?
Web app输给Native app的地方,不是界面(UI),而是操作性能。主要是互动(interaction)和动画(animation)这两方面,会出现卡顿(jank),用户会感觉到明显的时滞,有时简直慢得难以忍受。
Web app的性能瓶颈,主要有以下原因。
(1)Web基于DOM,而DOM很慢。浏览器打开网页时,需要解析文档,在内存中生成DOM结构,如果遇到复杂的文档,这个过程是很慢的。可以想象一下,如果网页上有上万个、甚至几十万个形状(不管是图片或CSS),生成DOM需要多久?更不要提与其中某一个形状互动了。
(2)DOM拖慢JavaScript。所有的DOM操作都是同步的,会堵塞浏览器。JavaScript操作DOM时,必须等前一个操作结束,才能执行后一个操作。只要一个操作有卡顿,整个网页就会短暂失去响应。浏览器重绘网页的频率是60FPS(即16毫秒/帧),JavaScript做不到在16毫秒内完成DOM操作,因此产生了跳帧。用户体验上的不流畅、不连贯就源于此。
(3)网页是单线程的。现在的浏览器对于每个网页,只用一个线程处理。所有工作都在这一个线程上完成,包括布局、渲染、JavaScript执行、图像解码等等,怎么可能不慢?
(4)网页没有硬件加速。网页都是由CPU处理的,没用GPU进行图形加速。
上面这些原因,对于PC还不至于造成严重的性能问题,但是手机的硬件资源相对有限,用户互动又相对频繁,结果跟Native app一比,就完全落在了下风。
三、FlipBoard的解决方案
FlipBoard原本是一个手机App,最近开始部署Web版本,结果就遇到了上面的问题:Web版的体验不佳。
上周,他们将解决方案公布在网站上,结果引起了业界轰动,因为这是一个史无前例的解决方案:
---- 他们没有使用DOM,而是将整个网站用canvas输出!
你可以用手机打开flipboard.com,体验一下,看看跟Native app有没有差别。如果你没有帐号,可以直接打开这里或这里。
这个方案的出发点是这样的:如果将网页变成了一个个canvas,用户就等于在跟图片互动,这样就绕开了DOM,降低了操作时滞。而且,canvas可以被硬件加速,这样就提高了性能。具体的技术细节,可以参考原文。canvas的转化基于React框架实现,FlipBoard 开发了一个专门的库React-canvas,已经开源。
这个方案引发了很多争议(这里和这里),主要是canvas只是一个位图,本身没有语义,如果要在它上面实现UI,等于HTML语言已有的东西都要再发明一遍,比如如何实现超链接、如何实现CSS效果等等。一些最简单的东西都变得很麻烦,因为canvas不是自适应的(responsive),文字在哪里断行,都要自己计算,而且用户也无法选中文本。另外,怎么让搜索引擎检索网页,解决起来也不是很容易。
但是不管怎样,这是一个有意义的尝试。
四、未来的路
James Long对FlipBoard的尝试,写了一篇评论《Radical Statements about the Mobile Web》。本文就受到了那篇文章的启发。
在文中,James Long对未来的Web app提出了几点预测,我认为很值得分享。
(1)多线程浏览器。每个网页应该由多个线程进行处理,主线程只负责布局和渲染,而且应该在16毫秒内完成,JavaScript由worker线程执行,这样就不会发生堵塞了。Mozilla正在开发的Servo就是这样一个项目。
(2)DOM的异步操作。JavaScript对DOM的操作不再是同步的,而是触发后,交给Event Loop机制进行监听。
(3)非DOM方案。浏览器不再将网页处理成DOM结构,而是变为其他结构。React的Virtual DOM方案就是这一类的尝试,还有更激进的方案,比如用数据库取代DOM。
(完)
woween 说:
你们不卡吗?提供案例网站我的手机chrome,卡哭了
2015年2月22日 12:35 | # | 引用
xo 说:
再往前一步看,为什么web要长得像app
2015年2月22日 12:56 | # | 引用
yoyon 说:
用手机的Firefox 顺畅无压力~
2015年2月22日 21:30 | # | 引用
Sumhat 说:
这要怪也只能怪 Javascript 引擎太慢吧,DOM 本身没有问题。
2015年2月22日 21:48 | # | 引用
hzf 说:
不是js慢,canvas也是用js绘制出来的。
反正有好有坏就是了,用canvas的话,不利于seo。但是只要浏览器能兼容好canvas的话,其他都不是问题(例如某些ie-_-)。
2015年2月22日 22:11 | # | 引用
WunGCQ 说:
我比较care的是web app如果Canvas UI化的话,就意味着它本身就是在向着native app靠拢。。。native app的语义化本身也更弱一些吧=_=。(抛开这些,DOM的16ms确实是硬伤,想到这还是蛮喜欢canvasUI的。。。)
2015年2月22日 22:11 | # | 引用
autoxbc 说:
网站太卡应该是这两个原因:
1.设计太复杂。形式大于内容,贪婪的使用特效,盲目的拟app化。
2.代码写错了。正确的代码是不用优化的,也没有优化的空间。
不过懂设计的人太少,多的是以为自己懂设计的人;代码写对很难,也很浪费时间。
如果 canvas 是银弹的话,那 flash 早就是了,java applet 也不会死。
2015年2月23日 00:14 | # | 引用
abcdefghijklmnopqrstuvwxyz 说:
2015年2月23日 19:43 | # | 引用
kmokidd 说:
如果使用transform就可以使用GPU来提高性能了
HTML5Rocks上面有说过 http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
QQ空间的手机游戏也有用到 http://isux.tencent.com/html5-game-development-cheats.html
2015年2月24日 12:06 | # | 引用
kiinlam 说:
不认同这样的说法,现在的手机浏览器也很快,在低帧率下跟原生app有得比,甚至比app还快。
用文中提到的例子吧:
如果网页上有上万个、甚至几十万个形状(不管是图片或CSS),生成DOM需要多久?
换成:
如果APP界面上有上万个、甚至几十万个形状,生成界面需要多久?
我可以保证,卡得一样糊涂。
dom拖慢js?我不知道能写出这样代码的程序猿是怎么通过面试的。如果是大量计算,那就应该分解分步骤,或者服务器直接给出结果来。
filpboard为何要用canvas?很简单,因为他们追求的特效,要求不能卡,而那种特效,用dom来渲染,可能会卡。这又得赞(tu)扬(cao)那帮追求完美的产品经理了。为了看起来漂亮而已,与dom慢不慢无关,跟js跟没关系了,毕竟canvas控制也得靠js,甚至整个网页都靠js在维持。
也许这样的网页,对cpu的消耗比dom组成的网页还高,耗电会更快,可能很快就会得出,看网页耗电比看app耗电更大的结论。这点只是个人猜测,纯属娱乐。
canvas绘画还是很出色的,也佩服那帮程序猿居然费这么大劲弄一个canvas版本的页面,不过目前还有些手机在canvas方面有缺陷(红米2就遇到过),不知道他们是否需要对兼容性进行测试。就算用了canvas,在某些手机上也一样卡得死死的,甚至在长时间运行后还失去响应。也许他们做出来之后只给那些左手iPhone6,右手iPhone6Plus的老板们乐乐而已。
在游戏方面,确实原生APP有很大的优势,但在纯粹的网站浏览方面,不一定比原生的差。
2015年2月25日 00:05 | # | 引用
林夕轩 说:
如果说canvas来模拟整个交互会更快的话,那是否应该考虑下页面的加载变慢了?
canvas的绘制依赖js执行,而浏览器中加载js又必须是串行下载,这样有一个问题:
得等react这个比较大的js下载好,再下载flipboard的js,然后页面中才出现内容。
总的来说,canvas对于动态的交互会有更好的体验,但是一些纯静态的内容应该没有多大优势。
2015年2月25日 09:42 | # | 引用
cccc 说:
既然是web app了,考虑SEO有意义吗,有人会考虑native app的SEO么?只是如果开发成本太大的话就失去了做web app的优势了,快速迭代
2015年2月25日 14:34 | # | 引用
英布 说:
加载卡哭了,WIFI网络加载一分多钟还是白屏~~
2015年2月25日 15:43 | # | 引用
henry_wu001 说:
作为移动开发者,我想说如果都用webapp代替native app,移动开发是不是快要失业了?
或者只是针对某些应用可行,比如说杂志新闻类?
2015年2月25日 16:45 | # | 引用
baoqian 说:
Javascript引擎慢,DOM元素多,加载时间长
2015年2月25日 17:08 | # | 引用
未軮 说:
我试了一下,页面虽然没有flipboard原生应用流畅,但比较顺滑,我用的chrome beta
2015年2月26日 03:19 | # | 引用
Fantasy 说:
加载慢的是因为GFW吧 lol
2015年2月26日 10:35 | # | 引用
瑾瑜 说:
这种解决方案还是很大胆很有创意的~
2015年2月26日 10:49 | # | 引用
crocodile 说:
鱼和熊掌焉能兼得?
我只是在担心耗电问题,不知道有没有相关的测试报告
2015年2月26日 16:01 | # | 引用
咸菜一点米 说:
好前沿的东西,看得我一楞楞的。不过我赶脚:在硬件上,划时代的CPU就快临盆了。。
2015年2月26日 20:12 | # | 引用
dm 说:
"用户就等于在跟图片互动,这样就绕开了DOM"
说的好像图片就不是dom一样。。
2015年2月26日 20:25 | # | 引用
Bios Sun 说:
在新版的 IOS 系统中使用 cordova 开发网页应用,其操作的流畅性还是很不错的。但是在 Android 虽非绝不能用,但使用动画时依然还是会有明显的卡顿。
2015年2月27日 08:11 | # | 引用
chf007 说:
几年前刚看到canvas时,就在想,如果网页的布局什么的都用这个,那很多兼容性的问题是不是就都解决了。
2015年2月27日 14:26 | # | 引用
Semmy 说:
如果将来有一天,Web app会成为主流,一定有一个前提,那就是它的性能可以赶上Native app。
---------
这句话不敢苟同,其实在今天,BS应用在某些方面的性能和用户体验仍不能媲美CS应用,但为何如今BS应用却得到广泛应用,所以个人认为市场的需求也是需要技术革命的推动。
(2)DOM拖慢JavaScript
----------
关于这一点,对于一些耗性能的操作,服务端往往是用多线程去处理,而如今客户端H5的技术可以用JS的worker来处理这种耗性能的业务场景。
(4)网页没有硬件加速。网页都是由CPU处理的,没用GPU进行图形加速。
-------------
支持H5的部分浏览器是有支持GPU硬件加速,比如IE9对CSS3动画就有硬件加速,这是浏览器厂商的问题,在一场新的技术革命面前,浏览器厂商不可能不革新自己的产品。
所以移动web技术前景还是蛮乐观的
2015年2月28日 10:54 | # | 引用
feng 说:
为啥没有人实时 famo.us js 的方式呢. 挺快的
2015年2月28日 13:26 | # | 引用
oodzchen 说:
用Chrome的开发工具模拟iPhone6试了一下,确实非常流畅,但是再流畅也无法朝语native app,web app永远只能作为补充角色吧
2015年3月 2日 11:31 | # | 引用
Duzz 说:
对mobile web抱有最大期待的是pc web程序员。
而不是希望给普通用户带来优秀体验的老板。
因此我想你不会失业的。
2015年3月 2日 14:55 | # | 引用
Litson 说:
canvas 坑很多,第一个就是中文无法折行 react-canvas中就是替代dom的一个产品,但是在中国的路还很远
2015年3月 3日 19:48 | # | 引用
hafeyang 说:
想想N年前web UI为什么要做成跟桌面一样?道理是一样的。用户更容易接受,浏览器在用户的映像里面是一个App/Application/Software 用户会认为他应该跟别的软件一样。
2015年3月 4日 12:55 | # | 引用
Rom 说:
呵呵 又在变成web和native两方工作者利益相关的YY了
2015年3月 7日 22:35 | # | 引用
milkman 说:
恰恰跟你的认识相反……
2015年3月 8日 21:18 | # | 引用
milkman 说:
一根筷子你容易折断,给你一大捆你还容易折断吗?
2015年3月 8日 21:24 | # | 引用
doubled 说:
首先,运行web app你需要一个浏览器,然后它是native app……
2015年3月11日 21:31 | # | 引用
drunkevil 说:
有APP的话还是会选择APP;
网站太多的话不可能每个网站都有APP,还是用浏览器比较方便。
2015年3月12日 15:12 | # | 引用
drunkevil 说:
阮老师现在技术性的文章要远多于其他类别,不知道是出于什么样的原因。
2015年3月12日 15:14 | # | 引用
JM_Joy 说:
http2.0
2015年3月12日 20:50 | # | 引用
mrdaydreamer 说:
没做过数据上的研究,但DOM解析真能那么慢?
总觉得web速度的瓶颈在于服务器响应时间和内容下载速度,如果通讯延迟足够小,那么以现有的硬件水平DOM解析应该不是什么大问题吧
2015年3月13日 18:52 | # | 引用
elseJun 说:
自我总结了一下" 特效 网速 手机配置 服务器响应"
2015年3月17日 08:03 | # | 引用
中暑 说:
写得好,非常棒
2015年3月17日 17:35 | # | 引用
谭国谷 说:
我是你大学时代的兄弟,有空给我写封邮件,重拾财大时光!
2015年3月22日 00:35 | # | 引用
hai 说:
想法还是挺好的,但是做起来真是要命。
2015年3月23日 16:41 | # | 引用
wakan 说:
如果web app 盛行,那么像iphone 这样的手机是不是可以轻易饶过App Store来发布
2015年3月28日 22:12 | # | 引用
呵呵 说:
其实web也不算真真扩平台,中国还有大量的用户用着IE6、7、8,噩梦
2015年3月29日 07:31 | # | 引用
yp 说:
我能说我的P6直接卡死机了么
2015年4月 3日 13:58 | # | 引用
SebastianBlade 说:
Web开发 最慢的就是DOM操作。
2015年4月28日 15:44 | # | 引用
mantou 说:
然而 浏览器 就是 系统。
2015年4月29日 12:44 | # | 引用
mantou 说:
对于这种以封闭模式盈利的厂商肯定会伤害它的利益,Web App确实是开放的。
而对于内容发布者,要重拾以前的模式——内容收费模式。
2015年4月29日 12:51 | # | 引用
Arnie97 说:
WP求不黑,我专门用WP上的IE浏览了一下FlipBoard,效果很流畅。
2015年6月 4日 10:41 | # | 引用
Rex 说:
小米手机自带的浏览器打不开这网址,电脑上可以,浏览器的手机模拟器也可以。
2015年6月28日 01:18 | # | 引用
cctvsod 说:
作为手机用户我也很期待mobile web,因为被app的各种要权限,后台自启进程,弹通知等搞的很烦
2015年7月 5日 00:09 | # | 引用
wells 说:
(4)网页没有硬件加速。网页都是由CPU处理的,没用GPU进行图形加速。
这句话有问题吧,不是有GPU加速。
2015年7月21日 15:43 | # | 引用
Coffee 说:
canvas不慢么?以前还想过用svg
2015年7月25日 10:35 | # | 引用
张勇 说:
看看之后的发展
2015年8月 3日 15:57 | # | 引用
Kung 说:
个人认为,跨平台的方案是在性能上是无法与专为某平台而生的方案相比的,如果WebApp性能上能够有巨大的提高,那么NativeApp更可以提高了。
2015年8月 4日 10:46 | # | 引用
木有数据线 说:
老师您好,我想问下,
1 为何不把js各种库集成到浏览器里面,
比如,浏览器都遵循这样一协议:他们的js文件都放在同样的路径下.
这样是否能给解决webapp的速度瓶颈提供一个好的方案
2015年9月 2日 23:00 | # | 引用
蒋鑫 说:
服务端生成就一定会卡的,因为有数据交互的时间,所以要想提升交互效果就一定要把在前端做mvc结构,与服务器只交互数据,不交互生成的界面才行。
你只说生成dom,不提插入和检索操作呢,一个简单的CSS选择 div > a ,就会造成全dom的检索的,这种在前端里处处都是啊。
还有转场效果,即从一个View切换成另一个View,受限于渲染和js数据加载等因素,就是这个的慢。
以iOS上的经典效果来说,短信的消息气泡的弹簧效果、返回手势使用时中间放弃后的操作阀值。这些用dom+js+css实现就是灾难啊!
我反而倾向于不要这么较真,常用的用app,不常用的用web,有通力在web上实现app的效果的公司真不多,现在web开发的氛围太活跃了,几天就出现一个所谓革命的技术,反而浪费了很多时间在学习上。
2015年9月10日 15:19 | # | 引用
林晨 说:
请看https://github.com/drawapp8/cantk
2015年9月26日 23:37 | # | 引用
eddy 说:
js是单线程的,但是浏览器不是单线程的,有渲染线程,ajax线程,事件线程~~
2015年10月 1日 22:47 | # | 引用
獐 说:
请问谁知道”数据库取代DOM“是什么方案?感觉很强大!
2015年10月23日 23:22 | # | 引用
LPegasus 说:
实测手机Chrome游览器的DOM渲染并不会阻塞js脚本。appendChild上去的时候css样式都没有渲染出来,已经进入下一步js语句了。
2015年11月 2日 13:15 | # | 引用
小俊 说:
@蒋鑫:
你可以去看一下framework7,你说的这些效果都可以实现,而且很流畅
2015年11月 7日 21:50 | # | 引用
falls 说:
整个网站用canvas输出 ===> 这个方案我朋友3年前在深圳就用过了, 他后来还自己找了风头做整体解决方案,其实老外未必走在中国人前面。
http://www.tangide.com/
2015年11月23日 15:27 | # | 引用
林法鑫 说:
正在做这样的事,移植Android的一套UI到Web的Canvas,相信比ReactCanvas和React更优秀:
https://github.com/linfaxin/AndroidUI4Web
2015年12月12日 01:37 | # | 引用
York Chen 说:
Javascript说:“网页慢,怪我咯?”
2016年1月12日 21:13 | # | 引用
Jovi 说:
前面那些说时JS本身慢、DOM不慢的,我觉得应该再认真看看文章。现在讨论的内容是,DOM的渲染速度比JS引擎的执行速度慢了一个数量级,所以导致的效率问题,这是一个相对的原因。
好比是飞机汽车同时出发,飞机每隔一段时间要等汽车一下。
说JS慢的,建议换C++;说靠自己代码水平,消除DOM慢影响的,建议去面一下谷歌。
一开始看到那么多人留言说些风马牛不相及的,还以为是几年前的评论,毕竟最近两年,前端从业者对于“DOM太慢”以及“JS引擎的执行速度大大提高”这两件事应该是耳熟能详的。
无法理解硬要挑刺来展现一下自己半吊子水平的评论者。
2016年2月 3日 11:06 | # | 引用
钊王 说:
2016.2.16晚
个人感觉的发展趋势:
1.目前阶段OS下,app+web混战
2.后面OS会整合部分功能(在安卓和IOS、WP上都可以看到一些身影,云计算大势所趋),app会慢慢和web没有很明显的界限,尤其是在网速不断提升的这个时代,web的劣势在减弱,
3.最后可能是一个软硬件结合的时代,不再单单是简单的软件了(理想很丰满)
2016年2月16日 22:45 | # | 引用
attilax 说:
目前我们项目已经全面使用h5做界面了。。最大的优点跨平台呀,java .net php ,cs 桌面程序,bs web程序,android手机程序 全部使用h5,一套界面全兼容。。当然除了游戏可能会慢点,其他方便的没有什么效率问题。
2016年4月 4日 02:05 | # | 引用
书痕 说:
最近在用ionic做一个在线购物的手机APP,目前还挺流畅的,只是虽然说H5跨平台,但在一些表现样式上似乎还有差别
2016年4月29日 17:16 | # | 引用
zhanbox 说:
1,浏览器现在越来越多的把任务分到不同线程,尤其是IE/Edge; 渲染啦,图片解码啦,以及大量的用户输入处理(鼠标,键盘, touch).
2,浏览器现在大量使用硬件加速。
2016年9月23日 13:44 | # | 引用
xgqfrms 说:
React Native vs React
2016年10月28日 12:45 | # | 引用
sparrow 说:
作为初级前端开发者,已经被各项前言技术搞晕了,如何系统的深入的掌握前端技术,而不是蜻蜓点水似的都是略知一二,这对于我真真是一个问题。
2016年12月 8日 16:10 | # | 引用
ww 说:
先膜拜下这帮牛人,然后表达下观点:不看好。
目前最佳实践显然是: Native外壳+Web界面 (当然,游戏类APP除外)
现在很多公司目前都是这种模式了,
只可惜大家都是各自关起门来实现自己的,重复造轮严重,
现在缺的是一个标准,或一个简单的框架,
js框架千千万,为什么偏偏jq火的经久不衰,原因就两个字:简单
2017年2月28日 17:00 | # | 引用
xibaba 说:
首先 浏览器就是一个app.....一个系统有很多app 一个app 有很多app....
2017年10月31日 14:56 | # | 引用
常西甲 说:
要翻墙 老铁
2018年4月11日 12:30 | # | 引用
振华 说:
估计那时候还没有 跨桌面应用
2018年5月 2日 15:09 | # | 引用