您可以捐助,支持我们的公益事业。

金额: 1元 10元 50元

姓名:

邮件:

电话:

公司:

说明:

认证码: 验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   专家招募  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
要做移动前端优化的朋友进来看看吧
 
作者:叶小钗 来源:博客园 发布于: 2015-04-15
来自于要资料   823 次浏览     评价:      
 

单页or多页

本文仅代表个人观点,不足请见谅,欢迎赐教。

webapp

小钗从事单页相关的开发一年有余,期间无比的推崇webapp的网站模式,也整理了很多移动开发的知识点,但是现在回过头来看,webapp究竟是好还是不好真是一言难尽哟!

webapp使用JavaScript修改页面;紧接着再从服务器传递更多数据然后再修改页面,如此循环。

从性能的角度看,在现代浏览器中单页面Web App已经能够和普通native应用程序相媲美,而且几乎所有的操作系统都支持现代的浏览器。

所以,很多人认为webapp是HTML5流行过程中最大的赢家,那么他有哪些特定呢?

SPA(single page application),即单页webapp,它具有以下优点:

用户体验,对于内容的改动不需要加载整个页面。这样不会出现白页情况,页面与页面无缝切换,甚至带有一定动画效果。

请求量少,请求内容无需服务器解析,对服务器压力较小,消耗更少的带宽,比如每次不需要接收完整的html结构,而只需要json数据。

当然,单页应用也不是完美无瑕的,他也具有以下问题:

由于历史原因,单页应用对SEO支持不是太好,需要对SEO做特殊处理。

首次加载量过大,首屏加载慢,所以首屏需要做特殊处理。

本身入门门槛就高,加之view编码需要释放资源,以免heap值过高,对编码人员的要求较高。

现状

传说中的webapp足以媲美native app,事实上这个足以还有很大的距离,小钗预计这个“足以”需要用2-3年时间填平,所以事实是什么呢?

事实上移动端的webapp模式的网站很少很少,一淘半年前还是,这两天一看又变回来了,小钗虽然对webapp抱有信心,但是信心从何而来呢?

携程webapp独树一帜,去哪儿ipad介入webapp,但是国内主流网站依旧是传统网站,主要原因不过有二:

① SEO

② 不想吃螃蟹

所以,携程的webapp在国内,何其可贵,说到这里,我都要哭出来了......

优劣之分

孰优孰劣非是小钗可以论断,求稳,webapp不比传统网站;求SEO,webapp需要其它解决方案;说垃圾收集,webapp需要自己释放资源。

说体验,webapp需要考虑首屏加载;说动画,webapp要考虑低端手机,所以webapp还有很长一段路需要走!

小钗相信,现在的webapp效果不可媲美native app,总有一天,当webapp不再制约于网络、设备,那么webapp的春天不会远。

虽说如此,现阶段webapp也会有许多优化心得、奇技淫巧可以拿出来说说的,这里小钗做一次分享,希望可以对webapp的同学有所帮助。

网络传输优化

综述

前端优化分为两个切入点:网络传输与DOM操作,而网络传输是制约一个网站速度的主要因素。

网络传输的优化要点是,零请求,无流量,其意是最大程度的减少请求数,降低请求量。

对webapp模式的应用来说,首屏加载慢是一个不可避免的问题,所以提升webapp首屏加载速度是提升整体网站速度的关键。

fake页-首屏加速

以上是一个网站首页的加载时间,我们分别取其150kb与30kb网速的加载速度,可以看出会慢!若他是webapp,我们可以做一些优化

我们应该避免页面长时间白页,这个时候便提出了fake页的概念。页面渲染只需要完整的HTML以及CSS,这个便是第一个优化点。

从数据请求数以及请求量来说,webapp首页的响应应该比较慢,若是任由js加载完成再渲染页面,用户很有可能失去耐心。

但是从DOMContentLoaded来看,首页事实上页面响应比较迅速,所以这个加载结束后页面第一屏便渲染结束,然后再异步加载js,当js改变后再动态改变dom结构中的一些关键点

这个时候一个静态HTML页面,装载首屏的基本内容,让首页快速显示

然后js加载结束后会马上重新渲染整个页面,这个样子,用户就可以很快的看到页面响应,给用户一个快的错觉,给人感觉快得多。

降低请求数

由webapp首页来说,不可避免的使用的js文件较多,这些文件分为两类:

① 框架js-css

② 各个业务团队js-css

所以可以限定每个业务团队只会加载这四个文件,以最小降低请求数,这里又涉及到并行加载,数量与容量有一个临界值,如何取这个临界值需要各位自己去实验

降低请求量

虽说图片压缩是不必说的事情,但是总会有些时候你会发现一些网站的图片尺寸很大,这个需要处理,而且必须处理。

以框架库为例,除了核心包以外,不需要的UI或者功能库可以剔除,用到了再动态加载,减少首次加载量,这个一开始就得做好,做不好后期就不好改

以业务团队为例,首次加载的js与html模板会将常用的几个页面压缩合并,其它页面访问时再请求,若是想提升首屏加载便可以只下载需要的页面文件。

另外,以下两点尤其需要注意:

① 若是你们是要的还是jQuery库的话,可以考虑换成zepto了

② 勿胡乱引用第三方库,若是要引用一定是读懂源码的情况下重写使用之,这样的好处是,吃得透,万一有问题,能改,而不是没办法又换库

缓存Ajax/localstorage

该方案的原理与前面类似,我们发送Ajax请求时候,应该缓存一些非实时数据,比如城市信息和常用联系人,但是我们只能缓存非敏感信息,

产品搜索页至列表页的请求数据会缓存30s-60s,若是过期时间内用户回到列表页的话不会重新请求数据

这对服务器压力,页面响应皆是有利的,这个在30s内事实上意义不大,可以减少一次请求。

另外,对于get和post的效率,曾经有人做过一次测试:

get100次平均耗时323ms;post100次平均耗时589ms,所以post方式是比get慢的,但post请求的优点是安全,并且参数没有长度限制。

是选择post还是选择get,皆需要处理,避免截断url,或者处处post。-

lazyload

只显示首屏页面,其它内容需要时再加载,比如列表页、图片lazyload,皆需要做

DOM操作优化

综述

DOM操作主要分为页面渲染与资源清理(heap控制),两者之间又相辅相成,若是DOM操作一块处理不好,其产生的感觉就不再是慢,而是卡

所以DOM操作优化的主要目的就是消灭页面卡的问题,这个在移动端尤为重要。

关于页面渲染

浏览器会解析三个东西:HTML、Javascript、CSS

浏览器首先会根据HTML生成DOM Tree,其次会根据CSS生成CSS Rule Tree,javascript可以通过DOM API与CSS API操作DOM Tree与CSS Rule Tree,从而引起页面变化。

浏览器解析结束会通过DOM Tree与CSS Rule Tree形成render tree,只有display不为none的元素才会形成render Tree,render Tree形成后浏览器会调用GUI绘制页面,在此之前做的一件事情便是layout或者说reflow。上面的描述简单而言可以分为以下流程:

生成DOM树

计算CSS样式

构建render tree

reflow,定位元素位置大小

绘制页面

在这个过程中,若是javascript动态改变DOM Tree便会引起reflow

页面中的元素改变,只要不影响尺寸,比如只是颜色改变只会引起repaint不会引起回流

否则,reflow不可避免,这个时候便需要重新计算形成render Tree

reflow分为局部回流与全局回流,会影响下面的,不会影响上面的元素

reflow耗用的系统资源较大,DOM Tree中受到影响的节点皆会reflow,然后影响其子节点最坏的情况是所有节点reflow,该问题引发的现象便是低性能的电脑风扇不停的转,手机变得很热,并且非常耗电,以下操作可能引起reflow

操作dom结构

动画

DOM样式修改

获取元素尺寸的API

减少使用定位属性(fixed/absolute)

static元素处于文档流中,其渲染速度是最快的,我们做过一个测试:

100个absolute元素与100个static元素渲染时差在0.01-0.007ms

100000个元素渲染差距便增至30ms左右,这个微小的时差在移动端变得尤为明显,比如:

小米/三星手机(1000左右),便存在明显的渲染问题,具体表现为:

定位元素在手机上不能显示。

定位元素动画效果失效。

以上问题便是UI渲染失效多导致,最好的解决方案是减少使用定位元素,否则只能引起强烈reflow才能解决。

另外,产品经常会有fixed的相关需求,比如支付按钮一直出现在低端,这个需求会造成两个问题:

fixed元素遭遇文本框时失效,可能会飘到页面中间阻挡输入

影响效率

问题一原因与移动端的实现有关,暂时没有完美的解决方案,问题二便与渲染直接关联

滚屏时,页面上所有的像素会跟着滚动,显卡对全屏幕上下移动的处理很快,但是若是出现一个fixed元素或者有元素不跟着一起滚动,那么滚动对手机浏览器来说就是一个负担,这种滚动的性能甚至体现在了iphone 4s,因为滚动可能会造成reflow,这个现象体现在:

使用absolute配合javascript模拟fixed效果时,会有断片的效果,该问题在iphone5s便不会出现这个问题。

奇技淫巧

当然,我们不能忽略产品的需求,fixed类需求应该在技术上得到解决,还用户一个良好的体验。

虚拟键盘导致fixed元素错位

fixed元素一定会伴随虚拟键盘的出现,但是虚拟键盘只是“贴”在了viewport上,表面上不会对dom产生“任何”影响,但是这个时候fixed元素表现却变得怪异起来,会错位。

应用层面解决问题方案是,虚拟键盘弹出时将fixed元素设置为static,虚拟键盘消失时候设置回来。

由于虚拟键盘出现并未抛出事件,而检测scroll或者resize事件,皆会有一定延迟,会出现闪烁现象,所以现有最好的方案是setinterval定时器监控当前获取焦点元素是否为文本元素,若是是的话便需要处理,如此便可解决fixed元素错误问题。

fixed元素滑动惯性平滑度

我们常常遇到这种产品需求,tab标签栏开始固定,当滚动向下超过该标签栏后便会变成fixed元素,一直出现在头部,这样的需求在电脑上没有问题,但是在iPhone5s以下的手机常常会出现小范围错位或者快速移动大范围错位的问题。

这个时候我们可以引起reflow迫使浏览器重绘以解决这个问题,这里推荐一个奇怪的hack写法:同时设置三个image元素的src属性,便可以全范围解决该难题, 该方案被团队证实并得到应用。

//三图片src,引发reflow,处理fixed方案惯性问题

var el = this.els.ctlc.find('img');

$(el[0]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');

$(el[1]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');

$(el[2]).attr("src", 'http://res.m.ctrip.com/html5/Content/images/144.png');

另外,上图中的tab标签下面的蓝线具有动画,但是在小米或者三星手机上可能不会移动,这个时候也可以动态引起reflow解决这个BUG。

其它

CSS选择器尽量使用id与class,避免过度层叠

避免使用数值,比如:border: none不会引起渲染,而boder: 0会

动画时候让元素脱离文档流,以免导致大量reflow

避免逐条修改DOM样式,改以className实现同样功能

操作DOM时将display设置为none,因为这种元素不会影响渲染,或者操作fragment对象取代操作显示在页面上的DOM

避免将获取DOM样式属性的操作写在循环中,可能引起重复reflow

内存资源优化

移动端的javascript

首先,移动端的性能与PC端的性能完全不在一个数量级上,比如,我哥做过一个测试,使用innerHTML绘制大段,之后想获取HTML的ID节点,事实上是获取不到的,这种问题在单页模拟多页,动态创建DOM会经常发生。

var element   = $('
...大量结构...
'); $(root).html(element) $('#test) //为空

这类问题匪夷所思,因为页面UI渲染与DOM操作是互斥的,但是就算出现了这个问题,一个解决方案是使用settimeout,更好的方案是使用DOMNodeRemoved事件监控页面DOM改变,将我们的DOM操作回调放入以确保渲染结束。

以上问题只是为了说明移动端的性能问题,这类性能问题会导致很多莫名其妙的问题,而且很多与渲染有关。但是这也从侧面说明了移动端资源的紧缺,若是heap值过大,会导致操作出现卡的现象,更有甚者,会引起页面假死直接退出。

webapp的模式,完全依赖于浏览器的垃圾回收,基本就是作死,因为传统页面一旦刷新页面整个资源完全释放,而webapp没有刷新这类操作,只有一个状态到两一个状态,不相关的内存会保留,资源必须手动释放,或者说,框架必须提供垃圾释放的机制。

这个由图表heap值变化可以清晰看出。

而view切换过程中,不用的资源若是不手动设置为null会导致变量得不到回收便脱离框架控制而失控了。所以我们在webapp的过程中需要注意:

释放没有使用的闭包

观察者需要得到清理

释放定时器

view切换过程中,在destroy中释放view相关资源

——感谢艾伦友情支援

闭包陷阱

在我们工作过程中,滥用局部变量极有可能引起闭包陷阱,这个问题不止是性能问题,在逻辑上会引起错误,而且不易发现,比如,在AMD闭包中使用一个局部变量

var _attributes = {};

callback ($.extend(_attributes, opts));

如此操作,会改变_ attributes对象,若是一个实例还无问题,但是两个实例的话便会发生变量污染。

这只是一个例子,但是在代码中滥用局部变量可能会引起不必要的隐忧,戒之慎之。

webapp资源释放

根据前面的描述,我们可以得出一个结论:

无论是view还是UI组件我们得提供统一的destroy接口,以便让用户继承释放资源。

若是view的资源得不到释放导致heap值过高,webapp模式的网站其价值大减。这里有几点可以考虑:

webapp中view实例保存不超过5个,多了便释放dom结构以及内存引用(临界值自己判断最优)

view隐藏时释放内部资源,解除DOM事件句柄

UI组件与view相同,需要统一释放机制

但是单页应用由于页面不会刷新,总有一些资源得不到释放,此问题任重道远,平时编写过程可以做以下优化:

使用函数替换逻辑

让我们的函数产生一个返回值替换函数中的大段逻辑,这样的第一个好处便是逻辑清晰,第二个好处是这些函数在不同的函数中,这个函数被使用后便会自动得到释放。

清理闭包引用

当一个闭包函数或者什么使用结束后,若不会再使用,便需要手动清理该变量,以便解除闭包之间的引用关系,从而释放资源。

使用对象属性或者方法

一个对象可以引用其他对象的属性或者方法,比如obj.foo = thatObj;这种情况下,我们可以随时删除对象解除引用关系,然后便可以清理资源。

动画与假死

动画而言建议采用CSS3实现动画,CSS3中又推荐采用最新的接口,比如使用transform取代top/lelf操作,这样操作效率搞得多。

若是采用动画可以将对应元素设置为absolute以减少回流,另外最关键一点还是

避免移动DOM树过多的节点,这个时候需要驳回产品无理需求,比如:

产品要求日期滚屏组件,显示半年的数据,这半年的数据便是180个DOM树

这个级别的DOM一旦移动整个手机会直接卡死,甚至构建DOM树,渲染页面也会出现假死现象,该问题需要规避。

Application Cache

Application Cache是HTML5为webapp离线使用而增加的API,与localstorage、cookie等不同,Application Cache存储的是一系列请求资源允许浏览器在请求资源时不必通过网络,设计得当的话可以实现离线应用。

使用Application Cache主要是在网络性能上提升,有效降低了网络延迟,提升请求加速

但是也会有一些问题,比如新版本缓存不立刻生效;manifest中的请求路径相对于manifest文件,而非加载页面;更新/回滚等问题,所以使用与否还得论证。

体验优化

区域滚动

移动端经常需要实现区域滚动的需求,成熟的也有IScroll解决方案,但是方案却不理想。

就官方的例子便会出现以下问题:

头部消失

偶尔不能显示文本框焦点,或者焦点错位

若是以上问题可忽略,但是文本框不见了这种事情,我是不会接受的

导致的原因与组织浏览器默认事件有关,所以,我这里不太推荐各位大范围的使用区域滚动,而改在区域使用,

就去哪儿的ipad版本在一个具有文本框的地方使用了IScroll,其提高的用户体验与导致的问题一样引人入胜。

事实上,小钗及其推崇IScroll库,虽说他有这样那样问题,但是,IScroll是最有可能带来移动端革命的库,因为他可以:

① 解决webapp区域滚动

② 变相解决fixed问题

③ 解决动画过程带来的长短页问题

总而言之,IScroll方案的提出,是让webapp媲美native app靠近了一大步,真正的平起平坐还需要浏览器的支援

点击响应

click本身在移动端响应是没有问题的,但是我们点击下来300ms 的延迟却是事实,这种事实造成的原因就是

手机需要知道你是不是想双击放大网页内容

所以click点击响应慢,而touch却不会有这样的限制,于是移动端的touch相当受欢迎,至于鼠标慢,他究竟有多慢,我会告诉你每次会慢300ms

所以该问题需要处理,具体见:http://www.cnblogs.com/yexiaochai/p/3462657.html#_h2_7

结语

webapp不是一天两天的事情,总有一天,webapp会绽放其应有的风采!

   
 订阅
  捐助
 
相关文章

手机软件测试用例设计实践
手机客户端UI测试分析
iPhone消息推送机制实现与探讨
Android手机开发(一)
 
相关文档

Android_UI官方设计教程
手机开发平台介绍
android拍照及上传功能
Android讲义智能手机开发
相关课程

Android高级移动应用程序
Android系统开发
Android应用开发
手机软件测试
 

android人机界面指南
Android手机开发(一)
Android手机开发(二)
Android手机开发(三)
Android手机开发(四)
iPhone消息推送机制实现探讨
手机软件测试用例设计实践
手机客户端UI测试分析
手机软件自动化测试研究报告
更多...   


Android高级移动应用程序
Android应用开发
Android系统开发
手机软件测试
嵌入式软件测试
Android软、硬、云整合


领先IT公司 android开发平台最佳实践
北京 Android开发技术进阶
某新能源领域企业 Android开发技术
某航天公司 Android、IOS应用软件开发
阿尔卡特 Linux内核驱动
艾默生 嵌入式软件架构设计
西门子 嵌入式架构设计
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号