Zuckerberg says no to HTML5
把用户要做一件事情, 浏览器/客户端所需的步骤拆开看.
网页版 (ajax):
1 加载网页 - 加载网页中的 js, css, images, ... - 页面初始化 (js)
2 (触发) 发送具体请求 (主要是 ajax, 也有少量 websocket 用于实时应用)
3 得到内容并展示在页面上
网页版 (传统):
1 加载网页 - (说明同上)
2 (内容已经随着网页到了, 没有这一步)
应用:
0 从某市场下载应用 (注: 一次性操作)
1 打开应用
2 (触发) 发送具体请求 (主要以 http/https 上的 api 为主, 少量使用其它协议的)
3 在应用的某个控件中展示内容.
---
都是 overhead 惹的祸啊.
应用的问题(对使用者来说)只有一个 (混用网页组件的忽略), 就是需要先下载.
当然因此也带来版本更新所引发的问题. 不提了.
网页版的问题:
1 受请求响应时间的影响大
实际上意思是, app 的只有实际内容请求才会受到这个影响. 静态内容已经嵌到里面去了.
网页版需要全部下载, 缓存命中率可以说比较低(指跨使用时间的情形, 连续的使用当然会命中的).
2 文件臃肿
延迟和带宽是网络传输中两个最重要的参数. 但这只适用于一个请求的情况.
由于依赖性的存在, 下完这个发现还要再去搞下一个这种事情是经常存在的.
有些依赖不可避免, 但加载项目的增加可以迅速将其它优化带来的那一点提升全部吃掉.
一个库 gzip 之后还要接近 20k (甚至更大) 挺常见的.
3 Javascript VM
还是把应用整个搞简单比较好对吧, 不谈这个.
总之网页版应用一定不能做的太复杂, 也就是说:
HTML5 宣称的大部分效果在带宽和延迟的约束下是很难做到的.
再换一句话说:
想让 HTML5 表现的像原生 app 那么好, 在一开始就打错了算盘.
如果你愿意遵守这个约束, 大概还可以相安无事. 简单也可以很美.
否则, 还是锻炼锻炼你的营销团队 (当然, 其它的事情也不简单) 把 app 推向市场吧.
ps:
有些团队人特别多, 闲的无事, 就什么版本都做. 但每一个版本评价又高不到哪里去.
App Store 上也因为乱加功能 (冲 KPI?) 被人打成全 1 星.
偶就不评论这属于什么行为了吧...
网页版 (ajax):
1 加载网页 - 加载网页中的 js, css, images, ... - 页面初始化 (js)
2 (触发) 发送具体请求 (主要是 ajax, 也有少量 websocket 用于实时应用)
3 得到内容并展示在页面上
网页版 (传统):
1 加载网页 - (说明同上)
2 (内容已经随着网页到了, 没有这一步)
应用:
0 从某市场下载应用 (注: 一次性操作)
1 打开应用
2 (触发) 发送具体请求 (主要以 http/https 上的 api 为主, 少量使用其它协议的)
3 在应用的某个控件中展示内容.
---
都是 overhead 惹的祸啊.
应用的问题(对使用者来说)只有一个 (混用网页组件的忽略), 就是需要先下载.
当然因此也带来版本更新所引发的问题. 不提了.
网页版的问题:
1 受请求响应时间的影响大
实际上意思是, app 的只有实际内容请求才会受到这个影响. 静态内容已经嵌到里面去了.
网页版需要全部下载, 缓存命中率可以说比较低(指跨使用时间的情形, 连续的使用当然会命中的).
2 文件臃肿
延迟和带宽是网络传输中两个最重要的参数. 但这只适用于一个请求的情况.
由于依赖性的存在, 下完这个发现还要再去搞下一个这种事情是经常存在的.
有些依赖不可避免, 但加载项目的增加可以迅速将其它优化带来的那一点提升全部吃掉.
一个库 gzip 之后还要接近 20k (甚至更大) 挺常见的.
3 Javascript VM
还是把应用整个搞简单比较好对吧, 不谈这个.
总之网页版应用一定不能做的太复杂, 也就是说:
HTML5 宣称的大部分效果在带宽和延迟的约束下是很难做到的.
再换一句话说:
想让 HTML5 表现的像原生 app 那么好, 在一开始就打错了算盘.
如果你愿意遵守这个约束, 大概还可以相安无事. 简单也可以很美.
否则, 还是锻炼锻炼你的营销团队 (当然, 其它的事情也不简单) 把 app 推向市场吧.
ps:
有些团队人特别多, 闲的无事, 就什么版本都做. 但每一个版本评价又高不到哪里去.
App Store 上也因为乱加功能 (冲 KPI?) 被人打成全 1 星.
偶就不评论这属于什么行为了吧...
