小程序开发，那些我们跳过的那些坑

最近，微信小程序扫码签到工具正式上线了。

回首过去一个月的历程，是时候该停下来做个阶段性的总结了，回顾得失，以便持续改进。这篇文章，就总结一下过去跳过的那些坑吧。

这些坑大致可以归为如下几类：

小程序某些技术细节和常用技术存在不一致。文档中虽有提及，如果不仔细看容易跳坑。

小程序的文档太简略，没有注明支持哪些功能，哪些不支持，只有用了才知道。

小程序的bug。

列举一下几个比较典型的坑吧。

于是，我们改方案，把服务器当中转站，让小程序使用wx.downloadFile从服务器下载图片。在收到小程序下载图片的请求之后，服务器直接和微信服务器获取小程序码的图片，然后以附件的形式返回给小程序。

问题解决。

①扫码签到中用到了二维码。

在开始的版本中，我们准备在Canvas上直接绘制二维码，接着使用wx.canvasToTempImage函数保存为image文件，然后通过Image组件加载。

经过调试，一切顺利。运行的时候呢，发现有时候在绘制完图片之后，调用wx.canvasToTempImage函数失败。这种情况在调试无法重现，运行的时候偶尔出现，不稳定。

仔细检查了代码，没问题啊。Google之后，有网友提出了解决方案，在drawImage完成之后，最好等3秒钟再调用wx.canvasToTempImage，以保证保存成功。

② Canvas和Image都不支持Base64图片，Image无法保存。

最初的方案中，我们自己生成二维码，后来为了兼容微信的“扫一扫”功能，我们决定改用小程序码。

开始，我们把Image的src设置为Base64格式，从服务器上通过request获取图片的Base64编码。小程序开发工具和iPhone上面测试都没有问题，唯独Android手机上无法正常显示图片。哦，原来在Android上，Canvas和Image都不支持Base64图片。可是...小程序开发文档中并没有这方面的说明啊。

怎么解决Android手机上的这个问题呢？如果把Image改成URL形式呢，小程序无法保存图片，以致即使是相同的图片，每次都要从服务器获取，这又加重了服务器的负担。这样吧，使用wx.downloadFile把文件下载到本地，然后再处理。

可是，和方形二维码相比，识别小程序码的成功率非常低。小程序码距离远点、稍微有些变形或方向没有对正都可能造成识别失败。一种典型的使用场景是：签到发起者把小程序码投影到大屏幕上，由于投影仪的分辨率和电脑不一致，图片可能产生变形。这种情况下，签到者怎么扫都无法识别。而以上所有这些，对于方形的二维码，全都不是问题。

由于小程序码的实现和识别原理没有开放，我们也没法采取图片纠错、还原等措施改善识别效果。

鱼和熊掌，真的很难兼得。

关于转发，在官方文档里是这么写的。

于是，在实现中，我们定义了此方法，把方法体留空。然后纰漏出现了，当用户签到之后再分享，收到的人一点击分享的链接会进入签到状态。

查了很久，才发现原因是在分享的时候，把当前页面加载时候的参数也给分享过去了，可是，onShareAppMessage函数里面什么都没做啊。

看来，什么都不做的话，它就会默认分享页面加载时的参数。为了修复这个bug，就尝试return一个object，并给这个object赋值path和title两个参数。

终于解决了。

除了上面提到的之外，还有不少微小的bug，不一而足。虽然很快就解决了，相对开发源生代码而言，还是有些影响开发效率的。

过去的这一个月，有些累。

相对之前铺天盖地的小程序宣传，其实它没我们想象中的那么好。当然，不得不承认，微信平台的庞大用户量和小程序无需下载的便利性，这是国内其他任何平台无法做到的。

对于扫码签到工具这种轻量级的应用，开发微信小程序或许是比较好的选择。

至于复杂的应用，是否要开发小程序版本，可能就得慎重了。

-- 写于2018.02. --