一句话结论

没上架的 App 一样能查崩溃，但光拿到日志没用，原始日志里全是内存地址。要经过一步叫符号化（Symbolicate，把地址翻译成函数名和行号）的处理，它才会变成你能看懂、能拿去改的内容。

为什么原始日志看不懂

App 编译发布的时候，为了方便排查，编译器会同时生成一份对照表：dSYM（debug symbols，调试符号文件）。这份文件里记着「哪个地址对应哪个函数、哪一行代码」。

但真正装到用户手机上的包，为了体积和安全的考虑，会把这些名字信息剥掉。所以用户手机崩溃时，系统只能记录「程序停在了某个地址」，它不知道那个地址叫什么名字。于是日志看起来就是这样一串东西：一堆十六进制数字，谁也读不出所以然。

符号化做的，就是把这份对照表拿回来，按地址一个一个查回去。

签名分发下，这一步为什么更容易断

上架的 App 有现成的渠道能帮你做还原，签名分发的 App 没有，得自己留好东西。要断通常是断在这三处。

• 对照表没留。打包的机器清过一次，或者换人接手，那份 dSYM 就找不回来了。没有它，日志永远是地址。
• 版本对不上。符号化要求日志和对照表严格属于同一次构建。哪怕代码一行没改，只要重新编译过一次，一般就对不上了，还原出来的行号会指到奇怪的地方。
• 包被重新签过。这一点在签名分发里很常见。重签会改动包里的签名信息，如果最后用来定位的构建标识变了，对照表就匹配不上。

该养成什么习惯

• 每次出包，把这一版对应的 dSYM 按版本号和构建号归档存好，别放在会被清理的临时目录里。
• 版本号和构建号严格递增，不要两个不同的包用同一个构建号，不然事后根本分不清用户崩在哪一版。
• 如果包要拿去签名，先在本地把成品包留一份原始副本，再送签。这一份是用来做对照的基准。
• 收集崩溃时，顺手把设备型号、系统版本、App 版本号一起带上，这三个信息能帮你判断是个例还是通病。

没有对照表还有救吗

有，但能拿到的信息会少很多。日志里有一部分内容是明文的系统框架名称，能大致判断崩在系统的哪一块；再加上崩溃时的异常类型（比如数组越界、找不到某个方法），配合版本号去翻这一版改了什么，有时也能定位到范围。但这属于退而求其次的办法，最省事的还是一开始就把对照表留好。

小结

崩溃排查这件事，八成功夫花在出包之前。把 dSYM 归档、把版本号管住、把原始包留一份，这三件事做到位，事后定位会轻松很多；反过来，前面的东西没留，再着急也只能对着地址发呆。

---

我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920　微信：A-mk5888）