这次的性能优化，我们找寻了小程序运行中可能影响性能的点，再针对这些影响点我们提出可行的优化建议，落地方案，最终一个个小的优化汇合成一个大的结果，使小程序的性能得到大幅的改善。在探究的过程中我们并没有细述所有的流程，我们只是着重分析小程序打开页面至用户交互的流程，有兴趣读者可以继续深挖源码，例如在各个阶段小程序初始化了什么构造器，基础库提供了什么能力等等，这有帮助我们更好的理解小程序设计的思路。
 
从资源下载载入到代码接口请求次数，数据通信再到多媒体资源和手机性能的考虑，我们抽丝剥茧，深挖流程，从表象中找寻埋藏在深层的本质。因为小程序相对较低的开发门槛，使得很多开发者对小程序的使用程度仅仅停留在“能用”、“能实现功能”的阶段上，并没有去深入了解小程序。本文也是想抛砖引玉，带读者粗浅了解小程序执行流程下的步骤，如果读者通过这次阅读能有所收获并激起了阅读小程序源码，深究细节的心，那便是本文最大的成功。
相比于上面的优化策略，最重要的是找出小程序中的性能瓶颈。在自己的优化实践中，遇到了下面的问题：

下拉加载更多，特别特别卡，通过列表局部更新的技巧，发现性能改善不大。后来发现，是因为首页需要监听scroll事件，导致scroll事件被频繁的触发，回调函数中有耗时操作，导致onreachBottom事件被阻塞了，也就是说，要等大概1~2秒才会去发起下一页的请求。取消掉scroll事件的监听，原本>4s的加载时间，控制在1s之内。
 
一些坑在微信开发者工具没有办法复现某些性能问题，是因为从逻辑层到webview的通讯，开发者工具底层是通过onpostMessage, 微信ios好像是微信自己实现的桥接。所以强烈建议使用真机进行调试
 
微信开发者工具，没有办法在【network】里面看到图片资源的加载，通过【trace】面板连接安卓真机也没有办法看到。如果想测试懒加载的效果，就比较麻烦，需要通过设置微信开发者工具的代理到127.0.0.1，通过charles可以抓包看到
搞微信小程序遇到的这些坑，虽然可以收获满满的填坑经验，但是这些填坑经验并不算是真正的计算机知识，因为这些知识的并不是基于对本质底层的理解，而是依靠经验，而经验是很快就会过时，可能下一次小程序api来一次大的升级，小程序优化手段马上就会换成另外一种。