最近公司安排了个使用uniapp开发打包成Android apk安装在pda手持设备上的任务，下面就记录下让我生不如死的uniapp开发之旅吧。。。
pda实现扫码有三种方式
- 键盘方式输出：输入框聚焦扫码自动赋值
- pda开启广播模式输出
- 使用插件：公司pda设备型号是iData品牌，正好此设备uniapp有专门的云端插件，
并且免费
不得不说这是我第一次搞pda（开始连pda是什么都不知道一直以为是扫码枪），更是第一次用uniapp开发，最不幸的是上面三种扫码方式我都写了。真的要命啊！！！
-
第一种：扫码后的值会连同上一次扫码的值一起拼接在输入框，我想大家遇到这种问题都会想到扫码完成清空输入框。恭喜你入坑开始，pda扫码应该是异步的（待确认），当你扫的频率比较快时（在接口未响应完成之前）依然会拼接到一起然后触发新的请求。而且这种方式处理起来输入框失焦、聚焦也很痛苦，那怎么解决呢——当然是舍弃它了
-
第二种：需要pda做些设置，然后拿到对应的广播动作和广播数据标签，代码中会用到。这种方式是完全可行的，但是我公司也有其他项目用到扫码，也就是说一个pda会服务多个项目，而其他项目都是国外开发国内代理的一些高大上的桌面应用。这些应用的扫码模式都是键盘方式输出，会导致使用pda需要针对项目来做出设置调整，最终——当然是舍弃它了
-
第三种：HbuilderX直接导入云端插件，通过
globalEvent全局监听iDataBarcodeEvent，亲测可行。
以上扫码问题解决了，又不幸的是uniapp音频播放又进坑了，当用户拿着pda做个无情的扫码机器时，扫到一定次数（大概20次以上后面再扫就不播报了）。原因是uniapp内置音频组件uni.createInnerAudioContext()在Android上不能多次创建实例（大概20次以上就会报-99错误），并且destroy方法不能销毁实例。所以实例只能创建一次，多次调用。亲测一直扫一直响。
本以为事情到这里就结束了，当扫码频率过快时，会出现中间不播报问题，男人真的不能太快啊。比如我扫了1、2、3，只会播报1和3，而且页面渲染会卡顿（因为innerAudioContext虽然实例化一次，但是每次播报监听事件都会叠加）。。。
这个问题搞了我两天，每天加班到9点啊有木有，疲劳导致眼睛疼鼻炎复发（鼻涕一直往桌上滴啊有木有）。试了N多种方式，通过audio标签播报（这样不会多次创建实例，可惜uniapp无法获取到audio的play播放方法），通过webview嵌入H5页面形式（遇到token问题，还得考虑与H5之间的通讯问题）。
就当真的觉得uniapp不合适是不是该用原生开发之际，突然领导妥协说控制扫码频率，语音播放完成之后再扫（一开始有中间不播报问题我就问要不要控制下频率啊喂）
最终通过控制扫码频率完美解决，虽然扫码体验上不能连续扫，但总归扫码次数渲染与语音播报是一致的。特在此记录一下
掉头发的uniapp开发经历。。。。
