Hybrid App性能优化之路

 

主要从两个方面讲一下首屏数据展现耗时优化和局部滚动长行列表优化

首屏数据展现耗时优化

1.首屏渲染的通常时序能够用以下的几个步骤：

首先点击打开页面，建立webview，进行页面的加载，页面加载完后，发送cdn请求去拉一些js和css的数据。

首先看一下首屏数据渲染，时候不用cgi?

首先想到的一点就是利用缓存。让cgi第一次拉取的数据是直接从缓存里读取出来的，等到加载完后再用实际的数据进行二次渲染；

可是这样会有两个问题：问题1–资源加载与cgi请求串行，就是咱们必须等待资源加载完成后，才能发起这个cgi请求；问题2–数据存在二次渲染，由于当新的cgi数据拉取回来了，要从新刷一遍；

因此咱们存在这样的一个思考?

1.可否让cgi请求与资源请求并行？

2.可否在第一次渲染时就渲染最新的数据？

咱们能够思考进一步的优化方案：cgi预拉取方案

在head里面写一个jsonp发送cgi请求，这样就达到了与资源并行的目的；将拉取的数据存在一个对象中，判断数据是否返回，若是返回的话，就用新的数据进行渲染，若是没有返回那么仍是用上面的缓存数据；

然而，在不少状况下，不少数据并不适合利用缓存的，好比一些页面打开的很频繁（一些热门的帖子，常常打开），或者只看一次就不看了；并且localstorage自己也有大小限制；

那么咱们还有别的优化方法吗？

数据共享（工厂数据），提早渲染

好比下面的，两边不少数据都是同样的，好比标题以及其余的一些详细信息

把一些公用的数据单独提出出来，放在缓存中能够共享，提早渲染；

上面是数据的共享，有时候一些图片数据也是能够共享的

如何在右边大图尚未请求以前，利用左边已经缓存的小图片；右边能够先使用小图的拉伸大图，先看到模糊的大图，在看到清晰的大图；

进行下一步，资源加载

如今都是组件化的开发页面，可是组件开发在首屏加载中也会有一些问题

组件之间的逻辑耦合，是的加载一些非首屏的组件资源，这样却是首屏的js体积过大；

给出的方案是 分离组件，区分环境后加载

最后是打开页面到穿件webview的优化

在点击页面到打开webview之间通常存在必定的延时，尤为是android的机型，通常有1-2秒的打开时间，这是时候，能够利用这段时间来尽可能作一些事情。

经过观察者模式，去订阅和触发事件，从而在这段时间内，去拉取首屏的一些数据；

总结上面的几点

局部滚动长列表优化

通常的滚动长列表能够分为两种：一种是数目条数限定的，就几十条数据的滚动，另外一种是无限滚动；

最初的实现方案是IScroll来解决；首先是数据有限状况下时，IScroll仍是能够的，在松手的时候稍微有点卡顿，可是在几千条数据是，IScroll就卡的不行了。基本滚不动。也能够经过测试工具来测试两个页面的FPS，用IScroll来作，数目有限是上下波动比较大，可是能用；数目上千后，FPS上下波动特别大，随着列表数目的增长，卡顿现象愈来愈明显；

IScorll卡顿的缘由是什么呢？

优化方案一：不用IScroll,替换成div的局部滚动；

可是，在条目比较多时，若是滚动过快，也会出现一些闪白的问题，因此对于列表项较多的列表，不推荐直接使用div局部滚动的方式；

思考？？可否在利用div滚动特性的同时，规避滚动内容的闪白问题

优化方案二：利用div原生滚动内容层

因此采用一个折中的方案，内容层和滚动层分离，只需设置内容层的overflow：auto；

这样基本能解决问题，可是在小米2等低版本的android手机上，会发现滚动不是平滑的滚动，而是跳跃式的滚动，也就是说，很快滚动到后面，中间的条目很快就滚过去了，这是由于scroll不是实时触发的，而是结束后在进行样式变动。

那咱们应该怎么办呢？ 

优化方案三：动态的增删dom

思考？？咱们是否能够不去滚动如此巨大的dom节点；在可视范围内的dom，增长，在可视区域外的dom，进行删除；

这种方式在PC上是没什么问题，可是在移动端，就会有layout，重绘重排；

优化方案四：使用canvas绘制列表

将列表绘制到canvas上，这样整个列表就是一个dom元素；只绘制可视区域的列表项；

可是测试发现，小米手机问题是解决了，可是在三星手机上又有问题

经过canvas绘制列表能够减小绘制的条目，FPS会有很大的提高，可是由此也证实一些机型，单纯的canvas绘制操做上已经达到了性能瓶颈；渲染区域越大，性能越受限，并且canvas绘制的元素不支持无障碍化，不支持被读屏软件识别；

优化方案五：滚动依然使用模拟的滚动，滚动过程当中，复用dom

这样，dom的个数只有可视区域内dom个数，与条目总的数目没有关系；

测试结果：

总结一些上面的五种优化方案；