性能优化建议

代码包的优化

优化大小

对于开发者来说，为了实现更加丰富的功能，所以有时会忽略对代码包大小的优化，但对于用户设备来说，需要把智能小程序所使用的代码包下载到本地空间。所以代码包的大小会影响着用户所需的下载流量以及空间占用。另外，代码包的下载速度也会直接影响着用户的首次打开智能小程序的体验。

智能小程序的打包过程会把用户工程下所有的文件都进行打包，生成最终的用户包，所以，应该在实际开发用户包的过程中，实现业务逻辑的同时尽量去除冗余，提高复用性，及时清理不再使用的库文件和资源，来减少代码包的大小。

使用分包

可以合理的使用智能小程序的分包策略。按功能聚合、业务代码的使用频度等指标来进行代码包的拆分，当用户访问到不同包内的页面时，客户端再分别加载对应的分包。这样既能够减少智能小程序首次加载时的使用流量，也能够提升智能小程序首次加载时的速度。

图片资源优化

当使用大图片或者是长列表图片时，可能会导致客户端的内存占用上升，当占用量达到一定指标时，会触发客户端销毁智能小程序的机制。另外，大图片也可能会造成客户端的卡顿，所以建议开发者尽量减少使用大图片的资源。

合理的使用 setData

setData 是用户开发中经常使用的接口，对于手机百度智能小程序而言，使用不当也是极易引起性能问题的接口。为了使大家更好的理解 setData 的错误用法，首先先介绍一下其背后的工作原理。

setData 的工作原理

智能小程序的逻辑层与视图层分属于不同的运行环境，相互之间不具备直接数据共享通道，他们之间的数据传递是通过客户端的消息事件派发来实现，所以到达视图层的 object 对象并非原指针，而是数据的复制版本。两者数据也并非完全同步，而是在数据未到达视图层之前，逻辑层的数据会领先于视图层。

智能小程序的视图层使用了 san 框架，相对于其他类似 react 等 mvvm 框架来通过 virtual dom diff 来实现组件的渲染来说，san 框架是基于 data 的 diff 来进行的组件重新渲染，减少了内存的使用率与计算量，保证视图更新的高效性。所以智能小程序的视图层对于数据的变更更加敏感，感受到数据变更时则会直接触发组件的重渲染。

常见不合理的使用 case

下面列举在开发者开发的过程中会常见的使用 setData 不当的场景。

1. setData 数据粒度划分不够

常见场景：开发者仅改变对象中某个属性的值，setData 的数据却是整个对象例如：假设 person 的模型为

{
    name:'swan',
    age:'20',
    sex:'man',
    getName:fn,
    ……
}

错误写法：

let person = this.getData('person');
person.age = 30;
this.setData('person',person);

正确写法：

this.setData('person.age',30);

此时，若逻辑层直接向视图层传递更新整个 person ，那么首先传输的数据量会成倍增长，其次，视图层中所有使用了 person 中任何属性的组件均重新渲染。好在逻辑层对于此处进行了优化，在逻辑层先进行数据对比，自动将 setData(‘person’,person) 补全为 setData(‘person.age’,30)。但上述写法也依旧使逻辑层增加处理过程，并且对于特殊的数据类型，如 array ，逻辑层的 diff 比较无法精准到具体 key 。例如：假设 numbers 模型为 [1,2,3,4,5]错误写法：

let numbers = this.getData('numbers');
numbers.unshift();
this.setData('numbers',numbers);

正确写法：

this.unshiftData(array);

所以在开发过程中，开发者应正确划分 setData 的数据粒度，以优化程序性能。

2. 频繁的 setData

原因同上，频繁的 setData，常见场景如 setInterval ，或其他循环执行。上述操作逻辑层每次均会通过客户端传递数据到视图层，消耗用户的网络流量与增加传输次数。并且，视图层也会频繁的重渲染组件，造成用户视觉卡顿等不好的体验。

3. 智能小程序页面不可见后进行 setData

在页面进入到后台状态时，程序后台的 setData 会占用前台页面的执行资源，且后台页面的渲染对用户并不可见，导致资源浪费。所以在页面隐藏时，不应该继续进行 setData 。

性能分析工具存储