我现在对2条线的同步也感觉不太放心 所以 最好是 能根据音频本身的时间来设置事件
象动画时间帧一样 就算卡顿 也是操作和音频一起卡顿 不会有不同步的情况发生
有没有人知道可否这样处理
update(dt)里，dt等于1/60秒，如果因为对象多了drawcall高导致卡住了，比如降到40帧，每一秒时间就和真实时间差1/3，不是开玩笑的，音乐类型的游戏，节奏块随着时间生成，一开始10个不影响，50个就不一定了啊。所以前面几个是准的，后面就不准了。对于掉帧这种事情先想办法优化，再考虑让时间对齐
上面有说了，直接在update也就是每帧去判断音频播放时间。
比如第10、15秒触发事件，那么第一阶段就是每帧去判断音频进度是否等于或大于10秒，是的话触发事件，然后进入下一阶段，继续每帧判断是否等于或大于15秒。帧速率就算低到10帧每秒，也最多有0.1秒的延迟。
或者说如果音频本身播放时候会发送一个时间事件，当然我不清楚有没有，也需要对其进行侦听然后判断，其实实际效果和在update中判断差不多。
update(dt)中，dt的时间并不固定等于1/60秒，而是两帧之间执行的间隔时间
要保证同步的话，首先音频就必须要能保证自身能按正确时间执行。假如音频有掉帧情况，比如应该播放第5秒，结果卡了0.1秒，卡顿后音频从5.1秒开始而不是第5秒开始的话，音频的播放时间就是可信的。
在update进行时间对比是可以的。如果我没理解错的话，不管你用什么方式，你用事件的话，逻辑也是要等到下一帧逻辑处理的时候执行。不可能在两帧之间单独给你cpu时间来执行逻辑吧。
正常情况如果帧率降得很低，也只是在帧率低的那些帧可能时间误差较大，但是这个误差是不会累积的。
帧率低的情况考虑节奏同步也没什么意义，这个时候整个游戏都没法玩，可能UI直接就穿过“打击点”了，玩家的输入事件也会卡到下一帧执行。
嗯嗯 明白了 实际上 动画帧事件 也是基于帧的触发的 和update 一样
我又反复测试了很多遍 到音乐结束的事后 画面上元素少的事后 节奏又对上了 所以 还是要从优化性能消耗着手来处理这个问题
在微信开发工具上测 节奏完全对上了 都没有优化过 。。。 之前是浏览器的问题？ 后面再微信真机测试下