小程序简略优化
性能：
- 避免首屏加载时间过长.
- 首屏时间是指用户开始看到第一屏的内容的时间，首屏时间太长会导致用户长时间看到的都是白屏，会一直等待有意义的内容展示出来。出现这一情况，应仔细检查这个过程都有哪个操作，一般来说，可能是请求数据的时间太长，或者是一次渲染的数据太大导致渲染时间太长。
- 避免执行脚本的耗时过长的情况
- 执行脚本的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要确认并优化脚本的逻辑
- 避免过大的 DOM 节点数目
- 建议一个页面使用少于 1000 个 DOM 节点，节点树深度少于 30 层，子节点数不大于 60 个。一个太大的 DOM 节点树会增加内存的使用，样式重排时间也会更长。
- 网络图片资源应开启 HTTP 缓存控制
- 开启 HTTP 缓存控制后，下一次加载同样的图片，会直接从缓存读取，提升加载速度
- 对网络请求做必要的缓存以避免多余的请求
- 发起网络请求总会让用户等待，可能造成不好的体验，应尽量避免多余的请求，比如对同样的请求进行缓存
- 所有请求的耗时不应太久
- 请求的耗时太长会让用户一直等待甚至离开，应当优化好服务器处理时间、减小回包大小，让请求快速响应
- 避免短时间内发起太多的请求
- 短时间内发起太多请求会触发小程序并行请求数量的限制，同时太多请求也可能导致加载慢等问题，应合理控制请求数量，甚至做请求的合并等
- 避免渲染界面的耗时过长的情况
- 渲染界面的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要校验下是否同时渲染的区域太大 .
- 避免 setData 的调用过于频繁
- setData接口的调用涉及逻辑层与渲染层间的线程通过，通信过于频繁可能导致处理队列阻塞，界面渲染不及时而导致卡顿，应避免无用的频繁调用
- 避免 setData 的数据过大
- 由于小程序运行逻辑线程与渲染线程之上，setData的调用会把数据从逻辑层传到渲染层，数据太大会增加通信时间
- 避免短时间内发起太多的图片请求
- 短时间内发起太多图片请求会触发浏览器并行加载的限制，可能导致图片加载慢，用户一直处理等待。应该合理控制数量，可考虑使用雪碧图技术、拆分域名或在屏幕外的图片使用懒加载。
- 避免图片太大而有效显示区域较小
- 图片太大会增加下载时间和内存的消耗，应根据显示区域大小合理控制图片大小
体验：
- 避免使用 css ':active' 伪类来实现点击态
- 使用 css ':active' 伪类来实现点击态，很容易触发，并且滚动或滑动时点击态不会消失，体验较差。建议使用小程序内置组件的 'hover-*' 属性来实现
- 应让图片按原图宽高比例显示
- 图片若没有按原图宽高比例显示，可能导致图片歪曲，不美观，甚至导致用户识别困难。可根据情况设置 image 组件的 mode 属性，以保持原图宽高比
- 固定底部的可点击组件都在iPhone X安全区域内
- 底部的可交互组件如果渲染在iPhone X的安全区域外，容易误触Home Indicator
- 滚动区域可开启惯性滚动以增强体验
- 惯性滚动会使滚动比较顺畅，在安卓下默认有惯性滚动，而在 iOS 下需要额外设置
-webkit-overflow-scrolling: touch 的样式
- 合理设置可点击元素的响应区域大小
- 我们应该合理地设置好可点击元素的响应区域大小，如果过小会导致用户很难点中，体验很差
最佳实践：
- 应避免出现任何 JavaScript 异常
- 出现 JavaScript 异常可能导致程序的交互无法进行下去，我们应当追求零异常，保证程序的高鲁棒性和高可用性
- 所有请求应响应正常
- 请求失败可能导致程序的交互无法进行下去，应当保证所有请求都能成功
- 所有资源请求都建议使用 HTTPS
- 使用 HTTPS，可以让你的小程序更加安全，而 HTTP 是明文传输的，存在可能被篡改内容的风险
- 避免将不可能被访问到的页面打包在小程序包里
- 小程序的包大小会影响加载时间，应该尽量控制包体积大小，避免将不会被使用的文件打包进去
- 避免定时器未跟随页面回收
- 定时器是全局的，并不是跟页面绑定的，当小程序从一个页面路由到另一个页面之后，前一个页面定时器应注意手动回收
- 避免使用废弃的接口
- 使用即将废弃或已废弃接口，可能导致小程序运行不正常。一般而言，接口不会立即去掉，但保险起见，建议不要使用，避免后续小程序突然运行异常
- 文字颜色与背景色搭配较好，适宜的颜色对比度更方便用户阅读
- 文字颜色与背景色需要搭配得当，适宜的颜色对比度可以让用户更好地阅读，提升小程序的用户体验
- 避免引入大量未被使用的样式
- 我们应该按需引入 wxss 资源，如果小程序中存在大量未使用的样式，会增加小程序包体积大小，从而在一定程度上影响加载速度
