New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

移动Web产品前端开发口诀——“快” #1

Closed
maxzhang opened this Issue Aug 1, 2013 · 17 comments

Comments

Projects
None yet
@maxzhang
Owner

maxzhang commented Aug 1, 2013

重定向:http://www.maxzhang.com/2013/05/%E7%A7%BB%E5%8A%A8Web%E4%BA%A7%E5%93%81%E5%89%8D%E7%AB%AF%E5%BC%80%E5%8F%91%E5%8F%A3%E8%AF%80%E2%80%94%E2%80%94%E2%80%9C%E5%BF%AB%E2%80%9D/


前言

“天下武功无坚不摧,唯快不破”,这句话最早是出自古龙小说《小李飞刀》,其实不论是武功还是产品,口诀都是一个字——快。一个好的产品,无论是页面加载速度,还是响应用户点击动作,都应当非常快,能快速的把响应内容反馈给用户,对于用户而言,快就是使用流畅——不卡。

移动端浏览器现状

现在的移动端浏览器十分混乱,在iOS下由于Apple的限制,所有浏览器都是webkit内核,并且iPhone机器性能以及iOS系统优化得十分优秀,BUG的一致性表现得非常统一,无论是哪个浏览器都会相对容易做兼容。但在Android设备下,由于操作系统、硬件配置和浏览器差异等问题,导致Web产品在Android下表现参差不齐。

  • 低版本的Android对一些高级的HTML5、CSS3特性支持不佳,无法做到很好的功能适配;
  • 由于设备硬件差异,导致低端机型无法承载较大的运算量及页面渲染;
  • 再有就是浏览器的差异,浏览器家族关系的复杂程度,会远远超出大家的理解范畴,与PC端相比有过之而无不及,在

移动端三大浏览器的角色换成了Safari、Android Browser、IE,还有国内各种浏览器UC、QQ等等,版本更是错综复杂,有时甚至会遇到,相同版本浏览器,相同操作系统,在不同设备上BUG表现不一致;

Note: 三星的设备就是奇葩,做过适配的都有体验。

分版本适配

基于以上对移动端浏览器混乱程度的理解,移动web产品要做到全平台适配,工作量无遗是巨大的,并且,由于HTML5的支持程度,也会导致大部分低端用户无法使用到一些高级特性,或表现效果不佳。而且,没必要为了适应低端Android用户让高端iOS用户也忍受着简陋无比的交互及界面。那么,将iOS、Android、Windows Phone分为不同的版本,做相应的功能适配还是很有必要的。

  • 在iOS下,自由度比较高,能随意发挥,很多有创意的交互及设计,都能在Safari下表现得比较好;
  • Android下由于设备硬件配置及浏览器版本差异比较大,就会选择相应保守的方式,舍弃部分影响用户使用流畅的交互,以及影响页面渲染的界面设计;
  • 对于Windows Phone我们是从WP8起步,这样会更好做浏览器兼容。
    做分版本适配的目的,是为了在保证功能交互的前提下让每个用户都能得到最流畅的操作体验。

Note: 其实现在大多数高端的Android机器,性能已经非常不错了,但是,永远不要抛弃399元山寨机的用户。

iScroll的问题

iScroll的诞生,主要是因为早期的webkit内核浏览器没有一种原生支持固定高度的容器。到目前为止,iScroll最大的问题就是慢,在千元以下Android设备上表现尤为突出。使用局部滚动来替代iScroll滚动是最好的一种方式,但很可惜,现在只有iOS5、6支持局部滚动,并且支持程度并不好,而Android压根就不打算支持。这样,我们就不得不抛弃iScroll,除非UE在设计交互原型时,将固定高度容器和局部区域滚动的需求完全砍掉。

分析结束,问题来了,现在到底使用iScroll呢?还是不使用?使用的话,大部分Android设备在滚动时会很卡,如不使用,部分功能又实现不了。其实,这个问题也不必太纠结。

  • 首先, 对于header、footer需要固定位置的页面,可以直接使用position:fixed实现。部分不支持fixed定位的浏览器问题也不大,这部分设备一般都是Android2.x的系统,配置也较低,相对交互而言,速度显然更加重要;
  • 对于需要依赖固定高度实现切换动画效果的交互,应尽量保证滚动条在页面顶部时处理。必要时做出一些牺牲,舍弃部分影响用户使用流畅的交互;
  • 尽量使用浏览器原生支持代替iScroll;
  • 如果必须使用iScroll才能实现的功能,一定要控制在最小范围,不要在常用场景应用iScroll;

虽然iScroll在iOS下表现得非常出色,但是都应当尽量使用浏览器原生支持特性来实现功能,这样才能最大化保证交互操作的流畅性。

关于页面跳转

很长一段时间都有一个争论,有页面跳转是不是WebApp?我认为单独讨论single page webapp还是页面跳转是没有意义的,所有产品都是建立在用户需求之上。对于现有的single page webapp产品,浏览器没有准备好,硬件配置也没有准备好,函数运算效率、页面渲染都跟不上,尤其是Android设备。基于用户需求出发,一些意识形态的东西该抛弃就抛弃,放开的使用页面跳转,只要能让程序运行流畅的东西,就应该毫不犹豫的使用。

但凡事也没有绝对,在一定的功能范围之内,也可以使用炫一些的切换动画,在一个页面实现多个子功能。

Note: iOS是值得称赞的一个系统,single page webapp在iOS6下运行非常完美。

总结

尽管大家都看到了HTML5的优点,但就现阶段而言,外部环境还没准备好。我们必须认清现实,做一个能让用户使用的产品才是最重要的,我们开发能做到的就是尽可能优化产品,让用户在最流畅的操作环境下得到最好的用户体验。速度是系统优化一个永恒不变的话题,没有任何一个用户愿意忍受卡卡的页面,点击一个按钮等待半天。切记,当你把用户的耐心消费完之后,产品的死期也不远了。

@cssmagic

This comment has been minimized.

cssmagic commented Sep 7, 2013

使用局部滚动来替代iScroll滚动是最好的一种方式,但很可惜,现在只有iOS5、6支持局部滚动,并且支持程度并不好,而Android压根就不打算支持。

我在模拟器上测试发现 Android 4 是支持 {overflow: scroll} 的,虽然效果很一般。

@Yaphats

This comment has been minimized.

Yaphats commented Dec 16, 2013

single page web app + 各种页面切换效果是比较酷 但是会不会很影响搜索引擎收录?

@maxzhang

This comment has been minimized.

Owner

maxzhang commented Dec 16, 2013

@Yaphats 一定会的,目前我还没有研究过这块

@Yaphats

This comment has been minimized.

Yaphats commented Dec 18, 2013

同样没具体研究过... 不过正在尝试理解ing...
最初考虑到 我们的webapp有点依赖搜索引擎,所以放弃使用single page
现在市场上很多产品,甚至移动框架jquery mobile之流的都是使用single page
内部又有些人员想要这种比较"酷"的page change animate

@maxzhang

This comment has been minimized.

Owner

maxzhang commented Dec 18, 2013

@Yaphats 无论是纯粹的单页应用还是非单页应用,都会有很多坑,一起来体验采坑的乐趣吧

@vven

This comment has been minimized.

vven commented Jan 24, 2014

想请教个问题,在应用页面很多的情况下
采用单页应用,是否会造成页面臃肿?(特别是某些页面用到很多控件)
采用非单页应用,在移动设备上反复加载html也挺浪费资源的,效果也不好
请问你们是采用什么解决方案的呢?

@maxzhang

This comment has been minimized.

Owner

maxzhang commented Jan 24, 2014

@vven
1、在早期时候,我们还是很传统的web链接web的多页形式,页面效率很高,但是用户体验比较差;
2、后来接触了单页应用开发相关的一些技术,为了追求潮流和炫酷,所以大量采用单页技术,导致页面臃肿,功能复杂,而且兼容性特别不好;
3、经过前面的技术积累与坎坷,现在我这采用的是单页与多页复合技术,在有一定的业务场景下,采用单页技术。并且保守的使用一些新技术。

@vven

This comment has been minimized.

vven commented Jan 24, 2014

非常感谢你的回复,我现在也在根据项目需求做一些single page的调整

@leinov

This comment has been minimized.

leinov commented Apr 29, 2014

额 移动端做的我蛋疼死了

@gongguanfu

This comment has been minimized.

gongguanfu commented Jun 24, 2014

@cssoul

This comment has been minimized.

cssoul commented Aug 20, 2014

小米手机更是奇葩,各种不兼容。。┭┮﹏┭┮

@logoove

This comment has been minimized.

logoove commented Sep 5, 2014

小米就是个垃圾 兼容性特差

@woaixiangbao

This comment has been minimized.

woaixiangbao commented Oct 16, 2014

对于小米的兼容性我已经吐槽无力了,实在是奇葩

@andysjt

This comment has been minimized.

andysjt commented Oct 20, 2014

请教个问题啊,为什么不用push state这样的技术, 这样至少能保证页面基本的css文件跟共用的js文件不会被请求,很多手机网站都没有这么做,不知道为什么

@tianxietaoyan

This comment has been minimized.

tianxietaoyan commented Apr 7, 2015

对于这个:
“Note:iOS是值得称赞的一个系统”

虽然你这个是个老坟,但不得不吐槽一句,你开发时首先围绕着iOS,再去做其它适配,自然会觉得痛苦无比。这次iOS 8的file input的bug已经持续两个更新没fix了。说实话这个bug比你成天琢磨的这些CSS实现问题大不知道多少倍。iOS上的各种坑看看原生应用开发者论坛讨论的那些问题就知道,当然这些人中大多数和所有的果粉一样,家丑不外扬。

再比如你们讨论来讨论去弄了两年的这个scroll的事情,说实话明明首先是苹果的错。苹果把boucing、橡皮筋之类都申请成专利,弄得别的厂商都没法用,在这种情况下,iOS下的Safari带有回弹效果其实才是破坏一致性和违背标准的,按理说以前端的作风,应该大骂才是,怎么你们又双重标准了?

当然,这也不赖你,你一看就是个小孩(听这话别不高兴,我肯定比你大得多),干这活儿时Apple已经如日中天了,被洗脑(这词中性,我也经常被洗脑)也是正常的。

就好比当年前端一窝蜂骂微软,要知道JSON、AJAX、SVG、CSS特效这些东西,其实无一不来自于微软的贡献,甚至一些如今还没有完全引入的东西,早在IE5时代微软就开始尝试了。正是因为Google、Apple、IBM等这伙阴谋家捣乱,很多微软提出的东西不能进入标准(从而包括微软在内的所有公司可以展开真正严格的标准化流程),而是非要另搞一套,才导致了新技术不能在当初得到快速应用,以及后来的混乱。

当然你可以说微软态度不正,被废了就被废了,赶紧推进真正的标准算了。但想当年微软每弄一个东西,就被上述流氓搅黄,凡是微软做得好的,可以说就是必然要被废的,在IE就是事实标准的情况下,微软唯一的选择就只有什么也不做,希望让市场说话。如果没有后来的反垄断和移动端的崛起导致的浏览器多样化,现在你们前端可以跟那些Windows应用开发人员一样,统一在真正的事实标准下了。

需知一个标准多种实现千奇百怪,你们不能简单的把这理解为BUG,很大程度上这是标准本身的错。你可以看到,C社区就没有这种问题,为什么?因为那个标准足够简单,背后的模型清晰。一个说不准上百万页文档才能说的完全清楚的东西,让不同的团队和公司去实现,目前的局面是一种必然。而这种局面背后是什么,是Google、Apple们无耻的争夺网络和端入口的主导权:即不甘人后的推陈出新、又对Web取代原生应用心存疑虑,从而三心二意。

微软总是再问,用户需要什么、开发者需要什么;而G、A和IBM们却再问:我怎么才能成为主流。在这种情况下,用户和开发人员居然全都在骂微软、而以为其它那些公司才是真正为用户、为开发者考虑的,这也是当今世界一个怪相了。当然,微软也不是做慈善的,只是当年垄断惯了,已经是绝对主流,所以想问题的方式总是在目前的基础上怎么能提供更多(除了在web这块被折腾的实在是什么也不能干);后来风向变了新市场来了,微软却没及时改变思路而是变得无所适从不知从何着手,才有今日的结果。

成天说谁谁创新、谁谁工程师文化、谁谁精雕细琢,其实从技术层面看,吹这些的公司们往往还不如微软那条落水狗。当然目前这个场合说微软这种昨日黄花其实不怎么合适;就Android和iOS来说,旗鼓相当的两破烂外加捣蛋鬼,只是糟糕的地方不一样而已,谁也别说谁了。

就web来说,这个完全不能履行职能的机构,和在这些标准台前幕后上下其手的大公司们,没有一个值得称赞。垃圾的标准、垃圾的实现、垃圾的专利流氓。我们站在垃圾堆里,居然还要各自战队,去”称赞“谁吗?

@tianxietaoyan

This comment has been minimized.

tianxietaoyan commented Apr 7, 2015

一不小心说多了。针对你的note,主要是两点:

  1. iOS的一些设计和实现质量之差、坑的大小和持久程度,远超包括LZ你的想象,只是干LZ这活儿的没法under the hood而已。
  2. 就目前最新的状况而言,皮筋效果这事,完全是苹果破坏了一致性,LZ和其它前端人士执行了双重标准。

另外,标准没定死前任何实现都不能说是错的。当然,Android阵营内部尤其是一家公司内部的不统一也是够扯淡的。

考虑到这是一个坟,确实Android 4.x以前的Android质量偏低;现在虽然改善了很多,但仍然很低。只是综合看也未必低过苹果,就看我们不同的人关注哪个侧面了。

@maxzhang

This comment has been minimized.

Owner

maxzhang commented Apr 8, 2015

@tianxietaoyan 有幸成为关注你的第一个人,首先感谢你的吐槽。
这是一篇老文了,内容只能代表我当时想表达的,时间在走,人在变,思想也会发酵,现在已过了那种评价谁是谁非的年龄,剩下的只是发现问题解决问题,优化每个技术实现,并且将这些问题上报,两年过去依然在追求“极速”的目标。
我很同意你说的最后一句话“旗鼓相当的两破烂外加捣蛋鬼,只是糟糕的地方不一样而已,谁也别说谁了”。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment