项目背景
项目是公司的一个轻量级游戏项目，使用PixiJS建立了一个轻量级互动游戏，在ios和安卓移动端、电脑端全平台进行发布了。
游戏中声音播放使用的是howler.js这个库。本地开发是使用chrome调试的，chrome的性能不容置疑是比较好的，所以在本地开发的时候没有碰到任何问题，游戏运行的很好。
howler.js 可以使用html5的模式和web audioi api 的模式，我们考虑到兼容性的问题，使用了html5 audio模式。
howler.js参数
1 2 3 | <br> html5 Boolean false</br><br> Set to true to force HTML5 Audio. This should be used for large audio files so that you don't have to wait for the full file to be downloaded and decoded before playing.<br> |
一、碰到的问题
项目运行上线之后，碰到的问题就来了。用户那边总是会碰到播放音频卡顿的问题，有的时候是延迟一会，有的时候会完全卡住导致过多久都没有声音。基本上都是IOS系统环境下
二、排查问题方法
分析1:
由于我们的音频播放是在线播放的，一开始我们以为是因为网速的问题，后来接入监控后发现网速完全没有问题，音频很小10kb左右，平均加载40-50毫秒，不应该像用户表现出来的延迟那么久。为了避免掉网络这个问题，我们使用了预加载，页面载入的时候把图片和音频资源全部都下载下来，缓存到浏览器本地。结果用户有的时候还是有卡顿。
分析2:
由于音频已经预先下载了，所以理论上应该离线也可以播放。我们就尝试断网运行游戏，发现音频播放只一开始顺利的播放了几个，等我们的游戏切换场景需要播放新的音频了，会去重新请求线上的音频资源。 而且还发现wifi情况下顺利播放的音频个数多一些，4g情况下顺利播放的个数少一些,大概可以断定这个是html audio自己的浏览器缓存策略导致的。所以我们看了howler.js的缓存策略，有一个参数可以配置。
1 2 3 | <br> pool Number 5</br><br> The size of the inactive sounds pool. Once sounds are stopped or finish playing, they are marked as ended and ready for cleanup. We keep a pool of these to recycle for improved performance. Generally this doesn't need to be changed. It is important to keep in mind that when a sound is paused, it won't be removed from the pool and will still be considered active so that it can be resumed later.<br> |
有点缺心眼的改大了缓存到50，导致整个页面都卡住了。报错HTML5 Audio pool exhausted, returning potentially locked audio object
感觉html5 audio的性能还是有点问题，所以我们改变了howler.js的模式，变更成使用web audio api来播放音频。
分析3:
变更成web audio api模式播放之后，果然不卡顿了，由此可见web audio api的性能真的是很不错。赶紧测试吧，不测不知道，一测吓一跳，兼容性倒是没有什么问题，can i use 网站上面也说明了。 但是，改成web audio api之后测试出来了两个问题：都是在iphone手机和ipad上出现
1.在带上耳机的情况下，播放过视频之后，再播放音频出现了电流声 （感觉上深入的研究一下api应该可以解决）
2.一开始带上耳机播放，然后拔掉耳机之后，直接静音了
我好南～～～
解决问题
综合以上的几个分析，打算还是弃用掉howler.js了，html5 audio在IOS原生浏览器下持续播放的性能不好，会导致一些偶发的卡顿。web audio api会碰到硬件上的问题。
我们游戏是集成在原生APP里面的，索性使用原生播放音频了。可以资源预先下载，然后在原生里面播放就ok . web只渲染pixi交互动画。顺利的解决了音频导致的游戏卡顿。