最近写了一个音频播放相关的小程序，用innerAudioContext进行音频的播放。

发现小程序中的onStop回调与调用stop方法可能是异步。

现象是：

我们在一个触摸事件回调函数A中调用了stop方法停止当前音频播放，然后设置一些属性（不是在data里，是page中定义的customData区域）。

结果发现，有一定的概率，onStop回调的时候，前面那个函数的设置属性的代码还未执行。

在浏览器中，js是单线程事件模型的，即使有回调，也会等到函数A执行完毕，才执行onStop回调，而不会A执行一半，插入onStop进行执行。

如果onStop是与stop方法同步执行的，那应该在stop执行完毕之前，onStop就回调了。但我们实际监测到的情况却是，大概率情况下是在A函数执行完毕后才回调，也就是说是异步回调的。

请问一下微信小程序框架的工程师，音频回调的线程模型到底是什么样的？

为什么有的时候回调先执行，有的时候后执行？（难道是多线程？那什么时候会提供加锁机制？）