微信小程序里的美工 第1篇
在小程序里用 canvas，我遇到了两个大坑：
第 坑，也是最莫名其妙的坑，就是自定义组件盖不住 canvas 的问题，无论自定义组件的 z-index 多高都盖不住 canvas。微信的官方解释就是“原生组件层级最高”，一句话，bug 就变 feature 了？解决方案也只能是：当需要盖住 canvas 的时候，隐藏这个 canvas，然后临时用 canvasToTempFilePath 生成一张假图顶替一下。真挺蠢的。
第 坑，是锯齿的问题。使用 canvasToTempFilePath 导出图片，会产生锯齿。因为在我的程序逻辑中涉及到至少 3 次将 canvas 导出图片然后重绘到 canvas 上，所以图片质量经过三次下降之后就变像素风了。最终找到的解决方案，竟然是要在绘制的时候给 canvas 的宽高设大一些（大家建议是 2 倍），导出的时候再导出成需要的尺寸。比如需要 1200px 宽的图片，要给 canvas 设置成 2400px 宽，然后导出的时候再导成 1200px。然后微信又有 canvas 尺寸不能超过 4096 的限制，所以当图片高度大于 2048px 的时候，我只能再把放大倍数调低一丢丢…
微信小程序里的美工 第2篇
云托管，一键完成配置，我不用再另外自己搭个后台环境了。而且资源也是弹性的，对新手比较友好。
但作为一个挺业余挺业余挺业余的开发者，我这个“新手”可能过于新了：
总之，我觉得程序员的世界太不容易了，天天要面对这么多对用户（程序员）不友好的产品（框架、文档、服务…… ）。
最后，先跑起来再说
不过世界就是这么个草台班子，到处都是不完美，到处都是对用户不友好，可是又不得不用的产品。所以当自己是设计的时候，就尽量帮着用户对产品吹毛求疵，力求完美。但哪有完美的东西，有几个 1px 的坑不碍事，先跑起来再说。
微信小程序里的美工 第3篇
微信的 rpx 初看起来挺聪明的，把所有的屏幕都映射到 750rpx 的宽度上，帮开发者省去了适应不同屏幕尺寸的麻烦。
但是！rpx 的坑就来了：
不用 rpx 那做适配不就麻烦了吗？其实还好，从我自己这个小程序的需求出发，我的方案是：根据页面需要的最小高度和当前屏幕比例来定一个最大宽度（类似游戏地图的适配逻辑）。对于一般的功能型产品来说，这样相对于用rpx，不仅阅读体验提升了，屏幕展示内容的效率也能有所提升，甚至如果要专门为宽屏（pad）适配新的布局也比较灵活。