渐渐的，简书好像逐渐变成我记录滴血问题的一个好地方了。这次是什么呢？这次更加严重。
9月2号周六，加班加点，终于成功发包。
两个星期之后，9月15周五，收到客户的反馈，app更新完之后一点就崩一点就崩。跟客户简单了解之后，并没有得出什么结论，用自己手机测试了下，也没有任何异常，这时候才想起来可以上Fabric看崩溃日志（滴血一），研究之后发现是数据库保存引发的异常，没有想太多，跟客户交代之后回家去了。周末也没放在心上。
到了9月18周一，打开了Fabric看，崩溃记录暴增，这时候才有点重视起来。开始调试为什么出现异常，通过搜索资料，比较倾向的结论是数据库更新了某些字段，但没有做数据迁移导致的崩溃。认真回想了很久才记起来，之前更新了某个字段属性，从Int16 换成Int32，当时确实没有做迁移，用自己手机测试了，没有异常，所以认为是更改属性不需要做迁移（滴血二）。但是即便是没做迁移，为什么我的手机没事呢？在看了下崩溃日志，发现99%的都是出现在iOS8的手机上，带着疑问搜索资料，发现Xcode8对于数据库有一个升级，自动完成数据迁移，这时候基本定位到问题，低版本的手机没有享用到自动数据迁移的特性，导致崩溃。然后跟与客户对接的人沟通，如果有客户反应出现崩溃问题的话，让他重新安装（滴血三）。
9月20今天，看着Fabric，每天都有20条左右的崩溃记录出现，感到有点心虚了，开始想补救措施。首先研究能不能通过JSPatch修复，貌似对数据库并不支持不能直接修复，然后尝试在第一次进行数据库操作的地方来拦截，转而弹出更新提示，实践之后发现虽然拦截成功但是并不能区分崩溃用户和正常用户来针对会出现崩溃的用户才弹出更新提示。最后得出的方案是通过发新包解决（滴血四）；
滴血一：没有与Fabric后台绑定邮箱，导致不能及时处理出现的崩溃；
滴血二：没有全面调试来确定是否不需要做数据迁移；
滴血三：没有重视客户的体验；
滴血四：最后时刻才想起要发新包，其实应该第一时间就发新包。
