将近一个月没有更新博文，是因为最近一个月在不停的更新折腾小程序，看看这个玩意到底能搞什么飞机。
某天boss看到一个文章说小程序启动超过1.6秒会有流失，彻夜未眠。早上截图给我们催促我们踏上了优化之路。
我们的小程序打开逻辑
正常打开
- 直接打开 -> index页面 -> home首页
分享tab页打开
- 不同的分享地址(比如设置) -> index页面 -> switch tab 到设置页面
分享其他tab页的内容页打开
- 不同的分享地址(比如设置) -> index页面 -> switch tab 到设置页面 -> 跳转进内容页
这样做的目的就是分享进去哪个页面，使用之后返回也可以按原来的逻辑和操作去继续处理。
启动页index页面的效果优化
小程序的第一个页面index/index页面，基本上就拿来当启动页。但是如果在跳转到其他页面之前，网络还没有回调完，那么这个页面就会出现卡在白屏的问题，所以做一张漂亮的启动页会好很多。
最早之前为了拿取到登录信息，所以是在index页面做登录login操作，到网络成功回调之后再跳转到了其他页面。
为什么不先跳转，然后在首页去登录？
这个是因为小程序可以有很多分享页面，而分享出去跳转进来的并不只是像app一样跳转进来，而是会跳转到对应的页面，比如直接跳转到个人详情，所以是多入口的，严格意义上来说index页面既是启动页，也是首页和分发页。
这样就会产生如果请求信息太慢，网速太慢，那么就会一直卡顿在首页的问题。所以比较好的解决方案就是请求登录的同时去跳转。
如果跳转的页面请求信息需要登录信息怎么办？那就是后面说的网络优化
网络请求优化
断线重连和重试次数
网络请求的优化，首先就是失败重试和限制重试次数，这个也是APP开发中很常见的。小程序最多并发10个http连接和2个websocket连接，并且如果一直重试的话会出现手机发烫的问题。
所以我现在设置的500毫秒重试一次，重试60次，相当于30s，如果依旧不行，那就弹网络错误的报错信息就可以了。
身份登录信息重试
前面说到的跳转和登录请求同时发送，那如果登录请求过慢，先跳转到页面，而这个页面的请求需要使用登录请求怎么办？那就是网络处理的问题了，现在我采用的是服务端约定登录信息报错的code，出现这个code的话就去重新登录并且记录当前的请求，登录成功之后再继续请求即可。
图片优化
图片除了使用必要的cdn存储外，最好不要返回大大的原图，可以返回较小清晰度可以接受的小图即可，同时小程序已经对图片做了缓存，目前网页图片的缓存用的是webview的缓存策略，所以cdn如果每次返回的图片都有时间戳的话，这个自带的缓存就用不上了，所以最好去掉时间戳，直接缓存即可。
合并接口
如果接口的请求是串行的，可以考虑合并接口，当然不是合并所有的串行接口，因为数据量太大也会出现问题，所以根据情况考虑某些页面的接口，这样大概又可以省下一秒多。
当然还有官方说的不要频繁的setData，合并setData等代码级别的操作，这些可以考虑下，但是感觉提升不大，最大的时间消耗其实还是网络请求。
先写这么多，最近也在完善懒猪计划和懒猪清单的iCloud同步部分，等后续稳定再分享一下。
版权属于：东哥笔记
本文链接：https://ddceo.com/blog/854.html
自2017年12月26日起，『转载以及大段采集进行后续编辑』须注明本文标题和链接！否则禁止所有转载和采集行为！
