小程序以免安装用完即走的特性自发布初就很火，即使是现在也是热度不减。小程序虽然是一个 HTML5，但是通过限制开发者的写法，提供一套自定义的组件以及写法，并且将一部分耗费性能的组件使用客户端渲染来极大的提高网页的性能。
前段时间我们也进行了小程序的开发。由于是接手的项目，这个项目之前是没有使用框架，直接使用原生小程序开发的，开发过程中就发现有很多不方便的地方。例如 NPM, Promise 组件化等。最后我对 wepy , tinajs , labrador , mpvue 等多个框架进行了调研，最后决定使用 tinajs 对项目进行重构。选择 tinajs 的原因是它是基于小程序的语法，并没有多大的改造，学习成本非常低。同时它的渐进式概念让我能够循序渐进的接入框架，而不是一下子就要把它的所有概念都要学习下来，这对当时工期比较紧张的我来说是比较重要的。当然还有一个更重要的原因是，它的源码非常的简单，即使是出了问题我也能快速定位出来。
不过即使是选择了一套正确的框架，碰到坑的情况也是在所难免的，小程序更甚。下面我就我这段时间碰到的一些比较经典的问题来说一下我碰到的一些问题。
数据传输长度超过最大长度
我们是一个新闻流的项目，用户可以无限下拉加载数据，内部会使用一个数组将列表的数据存储起来。当我美滋滋的使用 tinajs 重构完项目后准备试试的时候，我就发现，当我加载数据超过一定数量限制（大概200条数据）之后，控制台就会报“输出传输长度超过最大长度”的错误。
最后查了一下发现是小程序为了性能限制了一次渲染传输的数据量大小。最开始我以为是我的数据超过限制了，所以采取了精简不必要字段的办法将数据体积减小。不过在我缩减到不能再缩减的时候，发现依旧没什么卵用。后来就想到我的数据真的有这么大么，于是乎拿之前原生的测试了一下，发现刷到七百多条数据的时候也会提示这个错误。那么就可以证明我之前两百条数据的时候没有超过限制，同时我将数据 JSON 化并保存到本地文件里查看了一下，发现才150KB左右，远远没有达到上限。
最后经过我和 tinajs 作者的逐一分析，发现可能是自定义组件的锅。因为我的列表元素有不同的样式，所以我使用了自定义组件去定义了不同的样式类型组件，部分组件又有公共的部分所以又要抽离出来变成组件，也就是说实际上我的列表是由一个多层嵌套的自定义组件循环渲染而成的。我们猜测最后小程序渲染的时候，每一个自定义组件传入的数据都会做一次拷贝，这样就导致了我本来 150K 的数据，瞬间就超过了它们的限制。
最后解决的办法也非常简单，由于我其实大多数都是纯渲染的组件，所以组件内部的自定义组件我都是用 <template> 模板去渲染，这种情况下不会触发数据的拷贝试了下就没有问题了。当然除了我说的减少数据体积以及是用自定义模板代替自定义组件减少数据拷贝层级之外，我们还可以对 数据进行分页操作 来达到减少一次数据渲染的体积。
滚动
我们的小程序有一个下拉刷新的功能，小程序自己官方是有封装 onPullDownRefresh 接口来帮助我们完成这个事。不过因为我们的下拉刷新是有自定义样式的，所以就没办法使用官方的接口了。最后做出来的效果大概如下所示：
最开始我是使用了 <scroll-view> 组件来做滚动，同时使用 scrolltoupper 来触发下拉的事件。内部则是使用了 translate 操作来展开下拉卡片。一顿操作之后觉得甚是完美，但是之后突然发现官方提示：
请勿在 scroll-view 中使用 textarea 、 map 、 canvas 、 video 组件
因为这几个组件都是使用 Native 实现的，只能是固定在屏幕上的存在，所以没办法在 scroll-view 中使用。因为之后可能会在里面加入视频的数据，所以对这个组件就有点望而却步。同时使用了这个组件之后，外部的其它组件想要修改 scrllTop 的话会变得很麻烦，都需要自维护一套事件，增加了业务的复杂度。
最终我退回成普通的 view 监听 touchstart , touchmove 和 touchend 事件，根据移动的距离来判断下拉百分比来实现这个功能。最终的实现可以说是异常艰辛的。不过这个实现完了之后，又出现了一个问题。在 iOS 中会存在阻尼效果，也就是下拉的时候滚动条会有一个回弹的特效，导致你虽然下拉了但是 touch 事件并没办法有效的执行。目前这个问题还没有比较好的解决办法，这里也有用户提出了需要 提供禁止页面阻尼效果的参数 ，不过目前还没有官方回应。
除了阻尼问题之外，还有一个问题是 wx.pageScrollTo() 方法提供了 duration 参数，让滚动能够有动画效果。你可以在开发者工具中看到，实际上小程序的这个动画是使用 transform 属性来做的。正常情况来说这个是没有问题的，但是对于页面内存在 position: fixed 的元素来说，这个是有问题的。为什么这么说呢，大家可以看看 MDN 上 fixed 的描述：
It is positioned relative to the initial containing block established by the viewport, except when one of its ancestors has a transform , perspective , or filter property set to something other than none (see the CSS Transforms Spec), in which case that ancestor behaves as the containing block.
via: https://developer.mozilla.org/en-US/docs/Web/CSS/position
文档上说 fixed 默认是相对于视口的，除非说父级元素设置了 transform , perspective 或者 filter 数值的值为非 none ，那么就会相对于这个祖先元素。这样就造成了如果我最开始相对于窗口设置了一个元素 fixed 在右下角，当我 wx.pageScrollTo() 操作的时候本来相对于窗口的元素就会突然相对于 <page> 定位，当滚动结束之后因为 transform 属性已经消失，所以元素又会闪现回来。有做一个代码片段，大家感兴趣的也可以试试：wechatide://minicode/Q7zHi6m96eYV 。滚到底部之后点击下方的蓝色色块，会发现蓝色色块出现闪动，原因就是刚才描述的。解决办法就是去掉 wx.pageScrollTo() 的 duration 参数，或者是将滚动内容使用 <scroll-view> 包裹与 fixed 元素分离。
Canvas
除了以上两个问题之外，还有一个就是 Canvas 画布的问题。这个 Canvas 画布最大的问题在于小程序内部是使用客户端组件实现的，但是在开发者工具中由于是网页预览所以这里的是 HTML 中的 <canvas> 。虽然微信将 HTML 原生的 canvas 大部分接口都实现了，但是我要说...还是有！很多！不！一！样！敲黑板，划重点！所以这就导致了开发者工具上看到的效果和客户端实际看到的效果有可能会完全不一样，给我们开发过程带来了无尽的阻挠！而且我这边不知道为什么，即使是同样身为客户端版本的调试版，预览版，线上版，这三者有时候表现出来的行为也可能造成不一样，我当时的内心真的是万马奔腾！
由于是客户端渲染的画布，所以小程序的画布有以下几个比较明显的特点：
- 小程序的画布是无限大的，使用 CSS 的宽高设置只是影响它的显示区域，并不会影像绘制。也就是说你发现元素绘制超出画布返回之后，只要设置画布的 CSS 宽高即可让超出区域显示出来。如果是 HTML 中的画布的话应该是没有这个效果的。这样就导致了我们没办法同时设置绘制区域和画布大小这两个概念。
- 小程序的画布因为是客户端渲染的，所以它永远是置顶的， z-index 属性是无效的。这个理解起来也非常简单，因为网页是使用客户端 WebView 组件加载的，画布又是另外一个客户端组件，两个客户端组件叠加只能是以层级的关系叠加，没办法做成嵌入式的。
- 小程序的 ctx.draw() 方法是异步的，而且默认是清屏重绘的。这个和原生的画布是有区别的，之前我没有注意清屏重绘的问题导致调试了很久。
- 小程序的 ctx.drawImage() 方法只能获取本地资源的图片。当你想要使用远程资源的时候必须先使用 wx.getImageInfo() 方法下载下来获取到路径之后才能使用 ctx.drawImage() 进行绘制。
另外还有一个问题在于，小程序的画布必须可视才能绘制成功，也就是说如果你给这个画布设置 display:none 然后等它绘制成功之后再显示出来是不可以的。目前我的解决办法是在页面用户不可视区域内先绘制然后再获取图片内容。
后记
目前接触到的小程序的一些问题大概是这么多，有些可能在之后的版本中会解决（例如阻尼效果），而有些真的就是特性必须去适应（例如画布）。希望我总结的一些经验能帮助到大家。
