一些总结

内存/性能方面

黑块和闪退

注意有无内存泄漏；定时器要记得关；有高消耗、或需要反复渲染的地方，不在展示区时可以停止操作。

打开慢、操作卡顿

首页打开慢要区分是下载包慢还是首屏慢，前者需要分包，后者则需要打点留意慢在哪。以下几点问题一定要杜绝发生：图片未压缩、一次性加载太多图片、重复发送请求。另外，对于初始化数据的时机也要把握好，比如我曾发现ios的onReady在首次渲染之前执行，而安卓的onReady却在之后，给换成onLoad后有明显好转。

操作卡顿则意味着当页有执行的其他高消耗的任务阻塞了渲染行为，比如我们的商品列表有个轮播头像组件会持续轮播，下拉加载商品列表越多，所造成的消耗越大、交互越卡顿，后来改成仅在视窗口的商品才开启轮播后要好很多。

小程序api问题/兼容

初次打开小程序网络请求很易失败

所以…前端错误展示一定要做好/区分好哦。如果是网络问题造成请求失败的情况，务必给出明确讯息和重试按钮。

曾经安卓下没有console.time，直接宕机

这个情况本来就不应该发生阿，应设置debug级别，线上不应调用console。

获取地理位置api直接没回调

遇到也没办法啦。后来前端给加了一个超时控制，尽量不影响对于地理位置强依赖的后续流程。

会重复推入相同页面

恩…这个也不能说是问题。只是使用者需注意，在页面跳转前一定要做点击控制。

nav页跳转无法携带参数

要么存全局变量；要么用reLaunch到nav页，可以带参数。

版本适配

小程序api迭代还挺快的，并且微信各版本对小程序的支持能力差异很大。这种情况下，太老的版本（比如一年前）给与强制版本更新弹窗。比较新的、又存在api适配问题的情况下，就得手动做好兼容啦（可以对有影响的api进行先行包装）。

数据处理

setData数据过多时可能不成功

普通情况下不会出现。但是由于我们的setData做了包装，会在一个事件循环之后异步合并执行，所以遇到活动页渲染超多图墙的情况下…要小心了。还是那句老话~尽量减小更新数据的量。

全局数据

我们一开始并没有对数据做特殊处理，全局数据就拿个全局变量存着，每次进页面时都需要手动同步。最后非常混乱。

有一个场景是可加购的商品列表，其已加购商品数量需要在各个页面保持同步。我最后的做法仿照flux，建了一个基于Event的商品个数store，在页面onShow时订阅store变更，onHide时停止订阅。

后来有看到westore库，它的第一目标其实是setData前对data的diff，以此来保证setData的最小颗粒度。同时也保证了不同页面对全局data的本地映射数据的统一。westore有个小问题是，全局数据只要发生改变，所有订阅了该份数据的页面本地数据都会进行更新（不显示的页面不应抢用资源进行setData的），所以它对全局数据量的要求会更加严格。

测试

大致分IDE、安卓（老oppo、老魅族、新款华为）、ios（以X和系统10作为分界线）这几类。安卓下极易出现性能问题、ios10下则兼容问题较多。