日本模型展海量新手办 猫女一身黑装持枪而立酷劲十足
# 1. 首屏时间
百度 常规赛第七名的成绩已经超乎预期，而杰克逊的突然受伤再次打乱了他们的部署，附加赛首战不敌上海，他们及时拨乱反正把索顿换掉，最后连胜两局完成逆转，杀入季后赛；辽宁队已经提前准备更换半决赛乃至决赛的场馆了，北京队告诉他们：请等等。首屏时间是指用户从打开小程序看到第一屏主要内容的时间，首屏时间太长会导致用户长时间看到的都是白屏，影响使用体验。
优化首屏时间，可以分为以下几种情况：
- 首屏渲染的内容较多，需要集合多份数据进行渲染。这种情况需要开发者把内容分优先级，把优先级高的内容做优先展示，缩短白屏时间；
- 首屏内容依赖的数据从服务端请求的时间太长。开发者需要从服务端侧具体分析服务端数据返回的时间长的原因；
- 一次性渲染数据太大或依赖的计算过于复杂。减少渲染的数据量、优化渲染相关数据的算法可以解决这类问题。
得分条件：首屏时间不超过 5 秒
# 2. 渲染时间
渲染时间指的是首次渲染或因数据变化带来的页面结构变化的渲染花费的时间。
渲染界面的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要校验下是否同时渲染的区域太大（例如列表过长），或渲染依赖的计算是否过于复杂。
得分条件：渲染时间不超过 500ms
# 3. 脚本执行时间
脚本执行时间是指JS脚本在一次同步执行中消耗的时间，比如生命周期回调、事件处理函数的同步执行时间。
执行脚本的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要确认并优化脚本的逻辑
得分条件：一个执行周期内脚本运行时间不超过 1 秒
# 4. setData调用频率
setData接口的调用涉及逻辑层与渲染层间的线程通信，通信过于频繁可能导致处理队列阻塞，界面渲染不及时而导致卡顿，应避免无用的频繁调用。
得分条件：每秒调用setData的次数不超过 20 次
# 5. setData数据大小
由于小程序运行逻辑线程与渲染线程之上，setData的调用会把数据从逻辑层传到渲染层，数据太大会增加通信时间。
得分条件：setData的数据在JSON.stringify后不超过 256KB
# 6. WXML节点数
建议一个页面使用少于 1000 个 WXML 节点，节点树深度少于 30 层，子节点数不大于 60 个。一个太大的 WXML 节点树会增加内存的使用，样式重排时间也会更长，影响体验。
得分条件：页面WXML节点少于 1000 个，节点树深度少于 30 层，子节点数不大于 60 个
# 7. 图片缓存
开启 HTTP 缓存控制后，下一次加载同样的图片，会直接从缓存读取，大大提升加载速度。
得分条件：所有图片均开启 HTTP 缓存
# 8. 图片大小
图片太大会增加下载时间和内存的消耗，应根据显示区域大小合理控制图片大小。
得分条件：图片宽高乘积 <= 实际显示宽高乘积 * (设备像素比 ^ 2)
# 9. 请求耗时
请求的耗时太长会让用户一直等待甚至离开，应当优化好服务器处理时间、减小回包大小，让请求快速响应。
得分条件：所有网络请求都在 1 秒内返回结果
# 10. 网络请求数
短时间内发起太多请求会触发小程序并行请求数量的限制，同时太多请求也可能导致加载慢等问题，应合理控制请求数量，甚至做请求的合并等。
得分条件：通过wx.request发起的耗时超过 300ms 的请求并发数不超过 10 个
# 11. 图片请求数
短时间内发起太多图片请求会触发浏览器并行加载的限制，可能导致图片加载慢，用户一直处理等待。应该合理控制数量，可考虑使用雪碧图技术或在屏幕外的图片使用懒加载。
得分条件：同域名耗时超过 100ms 的图片请求并发数不超过 6 个
# 12. 网络请求缓存
发起网络请求总会让用户等待，可能造成不好的体验，应尽量避免多余的请求，比如对同样的请求进行缓存
得分条件：3 分钟以内同一个url请求不出现两次回包大于 128KB 且一模一样的内容