开发小程序需要注意的几点：

1、对于非空白页面，小程序需要进行适当的处​​理，避免出现异常导致页面空白。

2、合理控制图片大小：图片过大会增加下载时间和内存消耗，要根据显示区域大小合理控制图片大小。

3、每次联调的时候可以检查一下请求后端接口的时间，所有请求的时间不宜过长，如果请求时间过长，用户会一直等待甚至离开，应该优化服务器处理时间，减少响应包的大小，以快速响应请求。

（目前可能存在的缺陷：wx.在开发者工具中请求时间没问题，但是进入真机之后，时间很短，但是很长，特别是在慢速4G的安卓机上）

4、避免短时间内进行过多的图片请求：短时间内进行过多的图片请求会触发浏览器的并行加载限制，可能导致图片加载缓慢，用户等待时间过长。数量应合理控制。离屏图片可以考虑使用雪碧图技术或者懒加载。

5、避免短时间内发出过多请求：短时间内发出过多请求会触发小程序的并行请求数限制，同时请求过多也可能导致加载缓慢等问题，应合理控制请求数，甚至进行请求合并。目前小程序请求并发阈值为10，但是wx.的最大并发限制为5[不过我们从来没有用过这个...]。

6.避免数据过大而频繁调用（！！！）由于小程序运行在逻辑线程和渲染线程上，调用时会把数据从逻辑层转移到渲染层，数据过多会增加通信时间，非常耗性能。因此如果短时间内不得不频繁调用，可以考虑防抖和节流。

7. 图片应按原始宽高比显示：若图片不按原始宽高比显示，可能会导致图片扭曲、不美观，甚至用户难以识别。你可以根据情况设置组件的 mode 属性，保持原始宽高比。

8. 避免 WXML 节点数量过多：建议一个页面使用的 WXML 节点数量不超过 1000 个，节点树深度不超过 30 层，子节点数量不超过 60 个。过大的 WXML 节点树会增加内存占用，并且样式重排时间也会变长。

9. 避免将不太可能被访问的页面打包到小程序包中：小程序的包大小会影响加载时间，尽量控制包大小，避免打包那些不会用到的文件。

10.避免使用CSS':'伪类实现点击状态：使用CSS':'伪类实现点击状态容易触发，而且在滚动或者滑动的时候点击状态不会消失，体验很差。

11.如果有滚动区域，建议开启惯性滚动：惯性滚动会让滚动更加流畅， 默认开启惯性滚动，iOS 需要额外设置---：

12、建议所有资源请求都使用HTTP（使用起来比较安全，HTTP是明文传输，存在内容被篡改的风险）

13、小程序中未使用的wxss样式尽量去除：我们应该根据需要引入wxss资源，如果小程序中存在大量未使用的样式，会导致小程序包大小增大，从而一定程度上影响加载速度。

14、如果请求的是同一张图片，可以开启HTTP缓存控制，下次加载同一张图片时，会直接从缓存中读取，提升加载速度。

15. 如果页面包含定时器，则必须随页面一起回收。定时器是全局的，不与页面绑定。当页面因退出而销毁时，应手动回收定时器。

1. 小程序应避免任何异常

异常可能会导致小程序交互无法进行，追求零异常，保证小程序的高健壮性和高可用性。

2.小​​程序所有请求均应正常响应

请求失败可能导致小程序交互无法进行，应保证所有请求成功。

3. 所有请求都不应耗时太长

如果请求耗时过长，用户会不断等待甚至离开，应优化服务器处理时间，减少响应包大小，保证请求响应速度快。

4. 避免在短时间内发出过多的图片请求

短时间内发起过多的图片请求会触发浏览器的并行加载限制，可能导致图片加载缓慢，用户等待时间过长。数量要合理控制。离屏图片可以考虑使用雪碧图技术或者懒加载。

5. 避免在短时间内提出过多请求

短时间内发起过多请求会触发小程序并行请求数限制，同时请求过多也可能导致加载慢等问题，应合理控制请求数，甚至可以进行请求合并。

6. 避免数据过大

工作准则

小程序的视图层目前作为渲染载体，而逻辑层则是独立的运行环境。从架构上来说，和都是独立的模块，并不具备直接数据共享的通道。目前视图层与逻辑层之间的数据传输其实是通过双方提供的服务来实现的。即需要将用户传输的数据转换成字符串形式再进行传输。同时需要将转换后的数据内容拼接成JS脚本，然后通过执行JS脚本传输到双方独立的环境中。

但执行会受到很多因素的影响，到达视图层的数据并不是实时的。

由于小程序运行在逻辑线程和渲染线程上，调用时会把数据从逻辑层传输到渲染层，如果数据过大，会增加通信时间。

常见操作错误

经常去

用户在滑动的时候会感觉到卡顿，操作反馈延迟严重，因为JS线程一直在编译和渲染，没能及时将用户操作事件传递给逻辑层，而逻辑层又不能及时将操作处理结果传递给视图层。

存在延迟，由于JS线程一直处于繁忙状态，导致逻辑层到页面层的通讯时间增加，当视图层收到数据消息时，距离发送已经过去了几百毫秒，渲染结果不够实时。

每次都会传递大量新数据

从底层实现可以看出，数据传输其实就是一个脚本过程，当数据量过大时，会增加脚本的编译和执行时间，占用JS线程。

后台页面

当一个页面进入后台状态（用户不可见）时，它不应该继续运行。用户无法感受到后台状态页面的渲染。另外，后台状态页面还会抢占前台页面的执行。

避免过于频繁地拨打电话

界面的调用涉及到逻辑层与渲染层之间的线程传递，过于频繁的通信可能导致处理队列堵塞，界面渲染不及时，造成卡顿，应避免无用的频繁调用。

避免传递未绑定到 WXML 的变量

该操作会导致框架处理一些与界面渲染相关的工作，未绑定的变量意味着与界面渲染无关，传入会造成不必要的性能消耗。

7.合理设置可点击元素的响应区域大小

我们应该合理设置可点击元素的响应区域大小，如果太小，用户点击起来会比较困难，体验感会很差。

8. 避免花费太长时间渲染界面

如果渲染时间过长，用户可能会感觉界面卡顿，体验不佳，出现这种情况时需要检查是否同时渲染的区域过多。

9. 避免脚本执行时间过长

如果脚本执行时间过长，用户会感觉卡顿，体验不佳，需要确认并优化脚本的逻辑。

10.对网络请求做必要的缓存，避免不必要的请求

发起网络请求总会令用户等待，可能会带来不好的体验，应尽量避免重复请求，例如缓存同一个请求。

11.wxss覆盖率高，引入不用的样式较少甚至没有

根据需要引入wxss资源，如果小程序中存在大量未使用的样式，会导致小程序包大小增大，从而一定程度上影响加载速度。

文字颜色与背景颜色搭配良好，适当的颜色对比度让用户更容易阅读。

文字颜色与背景颜色需要合理搭配，适当的颜色对比，可以让用户更好的阅读，提升小程序的用户体验。

建议所有资源请求使用