此文背景：
微信体验版和pc调试版本都没有问题，但是上了Android手机就有问题，百思不得其解。并且有的同事遇到，有的同事没遇到。后面定位之后才发现，不是其没遇到，而是还没到触发时机。
引擎版本：
龙骨编辑器版本：
动画导出版本：5.0，
通用法则：收集日志，试图恢复现场。
1、找一台Android手机，连接调试环境，开启开发者模式，尝试捞取闪退日志。比如pc上装有android开发环境，或者带有adb调试也可。
2、按照他人反馈闪退的步骤操作，直到出现闪退。
3、android闪退通常会有crash日志。比如下图：
--------- beginning of crash：明确指明了闪退日志开始了
pid: 7307, tid: 7421, name: GLThread1358 >>> com.qm.dwslh<<<：指明了包名，以此确认这段日志就是来自于当前游戏。
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR),fault addr 0x8381103d2c：这是闪退常见的标记，signal ... 还有fault addr 0x... 错误的地址
【通常上述问题都是由于原生c++层出了问题，地址首先想到的是指针，比如野指针、空指针等；还有数组越界。这个数组越界非常典型。因为微信或pc上调试运行环境是js环境，容错能力比较强，比如数组 var a = [1, 2]; 取值a[-1] 也不会导致闪退，最多就是undefined。而c++这些原生层就不一样了，容不得半点沙子，数组越界这些问题必然导致崩溃。】
放大仔细看这个调用栈，似乎与龙骨动画解析有关。
4、A》根据以上日志关键字_parse...，回顾这个游戏开发过程中，似乎在pc上也遇到过关于龙骨动画解析的问题。比如错误的内存释放，导致下一个即将产生的相同龙骨动画解析失败。凭着这点经验，因此先尝试排除内存错误释放所引发。因为这个内存释放是很容易出错的，风险较大，所以要首先排除。找到相应释放代码，临时注释掉，可以重新出包再测试。
B》顺便打上日志。根据游戏实际运行情况，在可疑地方打上日志。比如闪退都在花园中出现，并且花园中只有顾客事件和鸽子，还有飞翔宝箱才是龙骨动画，而后两者在铺子中已经正常出现过，因此在花园顾客产生时打上顾客id，以便知道是哪一个顾客出场引发的。如图：
由他人重新出包时，已经上晚上十一点多，我已经睡了。第二天打开微信一看，测试反馈还是有闪退，并且和之前没什么差异，还是花园中闪退。很奇怪，但是排除了内存释放导致的问题。
4、随后其他人提供闪退日志，如下图：
这个日志更加详细，具体调用栈函数名都列的清清楚楚：
并且该日志显示和上述自己调试所得日志基本上一致。
由此比较肯定地得出一个结：龙骨动画解析出错了。
6、接着自己再测试同一个包，看看补打的日志是否有用，结果比较符合预期，如图：
ok，不错，是期望值。16号顾客出厂时，接着就闪退了，因此自然而然想到是不是这个顾客动画文件有问题？因为已经排除了内存释放了，还有错那就应该是动画本身有错。于是再想法测试。
7、好在动态调整配置即可达到测试，不用再出包。基本思路如下：
A、花园顾客只配置少量，比如一两个。且只能配置店铺1中出现过的骨骼动画；若是出错，那就不是骨骼动画的问题，因为店铺1中都出现过，很正常，那就应该花园相关代码有问题；若是没出错，ok，这和预期很接近，可以再做下一波配置测试。
B、 花园顾客只配置16号顾客，重新测试。若是出错，并且百分百出错，那就定位了，就是这个动画本身有问题。若是没出错，ok，冤枉了16号，只能再做下一波配置测试。
C、花园顾客配置其他店铺会出现但是目前还没出现过的顾客。若是出错，麻烦了，问题到底在哪？若是不出错，嗯，这是理想的情况。
根据以上思路让策划调整配置，测试在B步骤就停止了，因为只配置16号顾客是百分百出错，并且多人都能复现，日志和上述日志一模一样，还是继续输出了id为16。
8、好吧，到这基本上看似要结束了，因为直接让美术重新出个16号顾客就可以了，也不用花费太多时间纠结。但是并没有这么做，作为一个程序员，有必要刨根问底，防止下一次再出现，这到底是怎么出现的。骨骼动画好几十个，这个有问题，那其他的能没有问题吗？不可能一个一个去打开检查吧。应该要精确定位到这个骨骼动画到底哪里出了错。
9、要来16号骨骼动画源文件，打开检查，顺便也让美术自查和其他没错的骨骼动画的差异性。结果查看编辑属性和导出属性，没什么诡异之处。
10、问百度问论坛。带着dragonBones、JSONDataParser、_parseZOrderFrame等这些关键字搜索：
搜搜结果还有点启发：
第一帖：https://forum.cocos.org/t/creator2-0-9/77284
第二贴：https://forum.cocos.org/t/ios/75811
根据第二贴哥们的描述，有了启发：若是真是越界，那么和上面的报错很相似。既然同一个动画有错，那么微信或pc上调试时动画数据是不会发生变化的，那么调试一下看是不是真的会越界。因为js上容错比较ok，所以可能没有因此闪退，但是在原生环境上肯定会闪退，那么这就是想要的答案。
带着这样思路，找到引擎js和c++源代码，就是上述调用栈所示源文件：
c++：
js：
11、并在pc上调试：
zOrders最后的结果：
这样在js上不会导致闪退的。
ok，根据上述调试，在反推到c++代码中，必然触发断言：
引擎这么做，可能希望开发者在开发调试时就能触发，及时发现动画数据有问题。但是实际是我们在微信和pc调试没问题就直接输出app版本，没有经过模拟器验证，因此没有在开发中就触发。锅是谁的，就不纠结了。继续排查，为什么会出现这个情况，则继续调试：
rawZOrder为[0, -1],这个是来自动画输出文件：
12、打开动画原始文件，查看：
绘制顺序被k了两帧，意图是想要在动画中调整渲染层级。
这个很奇怪，为什么这有，那其他动画中是不是也有这个操作。于是随便打开几个没有出现问题的动画，惊讶的发现，没错的都没有这个k帧。
13、于是写了个脚本(见tools下check_role_dragbones.js)搜索查找所有骨骼动画，结果很惊喜，还好只有这一个动画：
14、再看修改前后参数对比，左前右后：
vs
根据上述对照，已经引擎源码解析算法所示，有-1肯定会触发断言而闪退。
此时，你肯定会问，这个动画师是怎么调整的呢？问得好！我也正想问他，他的名字叫cj！
15、标题虽然是android上触发的，但是实际上不改的话，ios上必然出现。正好符合上述第二贴那哥们所述。
16、完
这个过程虽然比较长，但是非常有价值，踩坑经验值++！
——DF 流闻名 scott 2020.4.15、4.16
_____________更正______________查阅龙骨官方数据说明，如图所示：
zorder的说明：
也就是说，上面提到的zOder=[0, -1] 中的-1是被允许的，标识偏移量。由此再根据cocos引擎的解析算法得出：当zOrder这个数组长度为2，且最后一个元素为-1时，那么是必然触发断言，如图：
因此可以认定cocos这么解析是不妥的，没有考虑到上述情况，实属bug：
更正完毕！
——DF 流闻名 scott 2020.4.1621:58
