小程序卡卡卡？用这个方法后，渲染速度提升三倍！
19-03-22
要做性能优化，必须先理清以下三个关键点：
产生性能问题的关键点
度量性能指标
寻找解决方案
在阅读案例分析前，我们先了解下小程序的工作原理和性能关键点。
小程序的视图层目前使用WebView作为渲染载体，而逻辑层是由独立的 JavascriptCore作为运行环境。在架构上，WebView和JavascriptCore都是独立的模块，并不具备数据直接共享的通道。
当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript所实现。
即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份JS脚本，再通过执行JS脚本的形式传递到两边独立环境。
而evaluateJavascript的执行会受很多方面的影响，数据到达视图层并不是实时的。
1. 频繁 setData
在我们分析过的一些案例里，部分小程序会非常频繁（毫秒级）的setData，其导致了两个后果：
Android下用户在滑动时会感觉到卡顿，操作反馈延迟严重，因为JS线程一直在编译执行渲染，未能及时将用户操作事件传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层。
渲染有出现延时，由于WebView的JS线程一直处于忙碌状态，逻辑层到页面层的通信耗时上升，视图层收到的数据消息时距离发出时间已经过去了几百毫秒，渲染的结果并不实时。
2. 每次setData传递大量新数据
由setData的底层实现可知，我们的数据传输实际是一次 evaluateJavascript脚本过程，当数据量过大时会增加脚本的编译执行时间，占用WebView JS线程。
3. 后台态页面进行setData
当页面进入后台态（用户不可见），不应该继续去进行setData，后台态页面的渲染用户是无法感受的，另外后台态页面去setData也会抢占前台页面的执行。
我们在优化性能时，指标是非常重要的。没有指标，就没法知道优化的点是否有效。不能单凭感觉去优化，要根据指标反馈，明确优化的成果。同时，优化就像个无底洞，要注意投入产出比。
用户反馈的卡顿，要么就是JS执行消耗资源过多导致处理器没响应，要么是UI渲染消耗资源过多，导致UI没法响应用户操作。
通过查看代码，我们并没有消耗大量计算资源的业务逻辑，但是出现了UI反复操作和抢占资源的现象。
如何度量呢？
可以利用setData的第二个参数，传入Callback函数，统计渲染时长。代码如下：
