按音量键连拍至结束，进缩略图查看显示29张

问题是丢图

1、先查app是否每次拍照都保存成功，imageAvailabe 的次数和 mediaInsert 的次数是否一致。

log中查看是ok 的，imageAvaliblae 和 media insert方法成对调用，那么就排除了 bsp 丢图的可能，问题关注点就在 app 以及 多媒体身上了。

2、与测试沟通 是否每次连拍都成功执行完30次，图库中是否存在 单张图片？

测试回复每次都正常拍完30张，不会提前停止操作，图库中情况不清楚

3、再次细查log，确认每次插入的图片信息是否为burst类型？确认多媒体是否又再次进行删图的操作？

1）先查多媒体是否有删图的操作。可惜，log中并没有，还得继续分析。

2）查插入的图片信息类型。

哦豁，在一次连拍30张的操作中，最后一次的 插入图片信息 竟然是 普通图片类型，但是图片名称等一些字段和其余的29张连拍是可以连上的，于是，锅还得背。

4、此问题属于低概率问题，只能通过log进行逆推。

从log中可以看到，图片的burstID改变了，那么我们就按burstID进行逆推，这个ID 是哪里来的？追到最近的传参，可以看到在创建save task的时候主动传入了 一个 id

5、从最后一张图传到app，到创建save task期间有没有改动id的操作？

1）burstNum ==1 时候会初次赋值，不是

2）丢弃连拍？和测试描述不符，不是

3）hideburst？有嫌疑

代码中是通过发消息进行hide操作，那么hide都是在哪里去发的？有一个地方就很奇怪，有一个处理刷新显示text消息的方法，当达到最后一张的时候，send了一个message去hide。有没有可能系统处理图片慢了，导致后面消息先进行了处理，导致burstID重置了？结合是一个低概率的问题，极有可能是这里问题。

6、好在这块有添加锅log

在最后一张图上来，到创建save task之前果然一个hide message触发了，没跑了，就是此处问题。但是怎么处理呢？加个延时？不怎么保险。加个保存flag的state？代码修改太多。

7、问题解决

仿照 其他做法，想着项目跑了一段时间了，应该不会引发大问题，于是采用延时方案走单。