小姜哥的微信

记一次Sencha Touch项目性能优化

记一次Sencha Touch项目性能优化

公司有一个基于Sencha Touch的项目,左侧有一个侧边栏,侧边栏展示文件夹列表,每个文件夹下还可有包含其他文件夹,最多文件夹层数是30。 每当侧边栏显示的时候都要向Server端发送一个请求,之后更新文件夹列表。

问题在于如果文件夹有嵌套每次打开侧边栏用户都无法操作,要等好长时间才能操作。一个在美国生活的台湾同事抱怨说那个请求加载的文件夹层级太多,请求太慢,所以会使得用户无法操作。之后公司就安排人研究减少加载什么的,最后好像还不了了之了。反正一共提了好几次这个问题,经历了好几个人改,但是问题还是在。

最近可能也是我倒霉,这个问题到了我这里,接下来为期三天的找问题和解决问题就开始了,其中也走过弯路。

代码我并不熟悉,所以只能凭着经验来,首先需要说网络慢导致UI不能响应用户是不对的,异步请求不卡UI。但是最好给出一个量化的数据出来,我找了一个有两个30层文件夹的账号测试请求时间,这个时间为600ms~800ms,考虑到server在美国,这个速度相当快,即便是同步也不至于卡那么久。

找规律,反复点了几次之后我发现如果侧边栏显示后先不做任何操作,等上一段时间,这时再操作就很流畅了。

那就是UI渲染慢咯,由于在移动端所以无法看到量化的渲染信息,所以我就把左侧栏的刷新逻辑做了小小的修改,改成当左侧栏已经有数据显示就不再更新,请求还是照发。依然卡,没有任何好转,进一步计算了一下渲染的时间和检查布局是否有问题,需要更新的部分外部套了postion:absolute,渲染时间500~700ms,慢是慢了点,但是不至于卡嘛。

那根据我的经验就是从请求返回到开始渲染数据花的时间太长,于是做了量化的计算,结果是10s。 好了,问题初步确定。更进一步,问题出在把XML转成Sencha Touch的model。前面提到一个文件夹下可以有多个文件夹,所以写代码的人用了Sencha Touch的hasMany。问题就出在这个hasMany,Sencha Touch在处理这个hasMany的时候出了太多的问题,还有bug,那之前他们怎么用的?研究了半天发现没法改,于是乎我想干脆自己写一个处理hasMany的逻辑得了。既然改不动人家的那就自己实现,回过头来看自己人的代码发现已经有了这样的代码,奇怪了,为啥还有hasMany,经过检查hasMany确实没用,原来是多余,于是乎我删除了这一行。再运行,发现非常流畅,原来需要10s的代码现在20ms。回过头研究代码,发现hasMany确实没用, 哦, 原来是一段多余的代码导致了这个被公司中层领导关注的问题。

推荐文章

回到顶部