12）不要使用已弃用的接口：
因为使用即将废弃或者已经废弃的接口，可能会导致小程序运行异常。一般来说，该接口不会立刻被移除，但为了安全起见，建议不要使用，避免后续小程序突然运行异常；
13）避免 WXML 节点数量过多：
建议页面使用的 WXML 节点数量不超过 1000 个，节点树深度不超过 30 层，子节点数不超过 60 个。过大的 WXML 节点树会增加内存占用，并且样式回流时间较长；
14）避免将那些不太可能被访问的页面打包到小程序包中：
因为小程序的包大小会影响加载时间，所以要尽量控制包大小，避免打包那些不会用到的文件；
15）定时器的及时恢复：
由于定时器是全局的，不和页面绑定，当页面因退出而销毁时，需要手动回收定时器；
16）避免使用 CSS ':' 伪类来实现点击状态：
使用CSS ':'伪类实现点击状态容易触发，滚动或者滑动时点击状态不会消失，体验较差，建议使用小程序内置组件的'-*'属性实现；
17）滚动区域可开启惯性滚动，增强体验：
由于惯性滚动使得滚动更加平滑，因此在 上默认启用惯性滚动，但在 iOS 上需要进行额外设置：
常见的优化方向
总结一些常见的问题并介绍可能的解决方案；
1.启动加载性能优化：
11.控制代码包大小：
在开发者工具中勾选“上传代码时自动压缩”；
及时清理无用的代码和资源文件；
减少代码包内图片等资源文件的大小和数量；
12.分包加载：
将小程序中不常用的页面放入多个子包，主包用于存放最常用的核心页面，启动时只加载主包，使用时按需下载子包。
使用子包加载时，用户首次进入子包页面时需要下载并注入子包，造成页面切换延迟。开发者可以使用子包预下载，预先配置页面可能跳转到的子包，进入页面后框架会根据配置进行预下载。
13.独立分包：
从子包页面启动时，需要先依赖主包的下载和注入，启动速度受主包限制；使用独立子包，从独立子包页面启动，只要下载并注入子包就可以打开页面；
2.优化首屏加载体验建议：
21、提前请求：异步数据请求，不需要等待页面渲染完成（无需等待，在此阶段即可发起请求）；
22、使用缓存：使用API缓存异步请求数据，第二次启动页面时，先使用缓存数据渲染页面，下拉刷新或者缓存过期时再更新数据。
23.避免白屏：先显示页面骨架和基本内容；
24、及时反馈：对需要用户等待的交互操作提供即时反馈，让用户不会觉得小程序没有响应；
3.避免不当使用：
31.现有数据过多（通讯时间和数据量有关，页面更新延迟；使用特殊按键实现部分更新）；
// 1: 初始一个list，存储列表数据 this.data = startList // 2: 监听滚动事件，滚动到底部获取新数据，并追加到list尾部,最后重新setData onReachBottom:()=>{ const {list} = this.data fetchNewData().then((res)=>{ list.push(res.list); this.setData({list}) } }
面对滚动长列表时，大多数人最初都会这样处理：如果数据不多，只有几页，问题可能不会太暴露；但当页面太多，几十页甚至几百页时，列表数据会越来越大，数据每次都会增加，因此每次需要重新渲染的节点数就会增多，导致滚动到后面时加载速度越来越慢。另外，由于小程序的视图渲染层和数据逻辑处理层是分开的，不在同一个线程上，从用户触发页面交互到处理数据逻辑最后呈现页面，都需要将数据传输到视图，因此小程序本身对数据大小也有限制，不能超过 1M。
我们可以通过写入数据路径的方式，将数据批量传输到视图层，减少一次性数据的大小，具体写入方法如下：
// 1.通过一个二维数组来存储数据 let feedList = [[array]]; // 2.维护一个页面变量值，加载完一次数据page++ let page = 1 // 3.页面每次滚动到底部，通过数据路径更新数据 onReachBottom:()=>{ fetchNewData().then((newVal)=>{ this.setData({ ['feedList[' + (page - 1) + ']']: newVal, }) } } // 4.最终我们的数据是[[array1],[array2]]这样的格式，然后通过wx:for遍历渲染数据
32. 名单部分更新：
比如传递like的id，找到该id对应数据的（不会变），用来做局部刷新
this.setData({ list[index] = newList[index] })
33.短时间内频繁通话：
因为会存在操作卡顿，交互延迟，页面渲染延迟等问题。优化：避免不必要的连续调用合并；
34. 避免使用后台状态页面，因为后台状态页面也会抢占前台页面的执行。
4. 短时间内图片请求过多：
就是在渲染页面的时候，一次性发送了过多的图片请求，导致同时发起过多的http请求。http连接是非常耗时的，尤其是一次性发起这么多的时候，而一次性发起的http链接数量是有限制的，比如浏览器就限制了一次性最多发起6个http链接。
因此，在渲染页面时，我们不会加载不在视图范围内的图片，只有当元素出现在视图范围内时，我们才会渲染它们。
常规的做法是通过 t() 获取元素的位置，然后与页面滚动位置进行比较，如果出现在视图中，则显示 img。这种方式有两个问题：
1）t()方法调用本身很容易引起页面回流；
2）事件监控本身触发比较频繁，虽然可以通过节流来减少，但是还是容易添加不必要的代码处理；
微信提供了一个对象，用来推断某些节点是否能被用户看到，以及被用户看到的比例是多少。
有了这个API，我们不再需要主动去监控元素位置，在页面渲染开始的时候，我们就可以通过这个API指定需要监控的元素，系统就会自动去监控元素位置。
let data = list; data.forEach((item,index)=>{ this.createIntersectionObserver().relativeToViewport.observe(`.img-${index}`,res=>{ if (res.intersectionRatio > 0){ this.setData({ item.imgShow:true }) } }) })
如果值大于0，则表示元素出现在视图中，并刷新数据以显示图像组件。
5.图像太大，显示区域太小：
这个问题的意思是图片尺寸过大，但是我们在页面上显示的尺寸却太小，图片尺寸越大，图片请求就越慢，导致页面渲染速度下降。
对于页面内的图片，最好是存放在CDN服务器上，一个原因是可以充分利用CDN的缓存，加快请求速度，另一个原因是CDN可以对图片进行一定方式的处理，比如裁剪等。我司通过CDN来响应图片处理，然后在请求图片的时候告诉CDN服务器需要什么尺寸的图片，CDN服务器就响应相应尺寸的图片。
6.列表渲染中key值的作用：
在渲染列表的时候，key值可以提升列表渲染性能。为什么呢？首先我们要思考小程序页面是怎么渲染的，主要分为以下几步：
1.将wxml结构化文档构建成vdom虚拟数据
2、当页面有新的交互时，会生成新的vdom编号，然后和旧的编号进行对比，看哪里有变化，并做相应的修改（删除、移动、更新值）。
3.最后将vdom渲染成真实的页面结构
key值的作用在第二步，当数据发生改变，触发渲染层重新渲染时，带有该key的组件会被修正，框架会保证它们被重新排序而不是重新创建，以保证组件保持自身状态，提高列表渲染的效率。
若不指定键值，则默认按数组索引来处理，这可能会造成输入框等某些组件的值混乱。
因此在渲染列表的时候，如果列表的顺序发生变化，最好添加一个键，而不要简单的使用数组索引作为键。
7.避免不当使用：
仅在必要时监听事件；
避免在中实现复杂的逻辑；
避免频繁来电；
避免频繁查询节点信息()；
8.渲染：
分不同的层进行绘制，将不变的部分单独绘制成一个，将动态生成的部分绘制成一个，最后合并成一个。
总结
以上总结的只是一些常见问题，并不是全部，随着微信小程序基础库的升级，部分问题可能会得到优化解决，但也有可能出现其他新的问题。