【功能发布】Crash不好找？Bugly来支招！

自Bugly上线以来，通过各位开发者的试用和口口相传，目前Bugly已经迎来了大批量的用户，在业内的反响只能用下图来形容：

当然也有很多程序员哥哥在使用的过程中遇到了一些问题，比如按照文档的引导流程正确接入了，但是上报的Crash文档却不可读，很难准确定位到Crash的所在。对于这个问题，小编跪抱技术哥哥们大腿，进行仔细查看，认真琢磨，发现原来都是符号表惹的祸。

说到这里，不禁有人要发问：

在产品开发的过程中，为了进行代码及产品保护，几乎所有的非开源App都会进行代码混淆。但是，当收集到崩溃信息后，就需要进行符号化来还原代码信息，以便开发者可以定位Bug。这就像是谍战戏里的暗号密码的加密与解密一样。为了方便理解，小编在这里给大家举个栗子

先用IOS来举例，当我们没有对代码进行符号化还原的时候，我们通常看到的Crash文档是这样的：

这些都是地址，可读，但是Crash非常难定位，不知道要看瞎多少双程序员哥哥闪亮的大眼~~但是如果经过了符号化解码，我们看到的文件则是这样的：

在Android平台中，这种问题的显示通常是这样的：

为了让文档内容更清晰，更方便地定位到Crash的所在，各位开发者在每次接入的时候，都要手动配置符号表。体验过手动配置的开发哥哥肯定知道这是个多么麻烦的工作，为了解救大家于水火之中，Bugly新增了脚本自动配置符号表功能，抛弃复杂的配置符号表流程，自动化完成配置工作。本次符号表自动配置，IOS 与 Android 开发均可使用，只需按照平台提供的接入指南进行接入，手动配置符号表的苦日子就从此一去不复返了！

（说到这里，请允许小编擦一擦激动的泪水……）

但是配置符号表进行还原之后，很多开发哥哥还是需要颇费眼力地进行逐行扫描，寻找Crash的所在。为此Bugly作为业内的一个颇具良心和情怀的工具类平台，特地新增了如下新功能：

1、优化崩溃堆栈中高亮关键堆栈行，助力高效定位

以前的一堆堆栈，没头没尾，找个关键信息要半天？小萝莉终于受不了，例会上一双大眼睛，泪眼汪汪瞪着大伙，改不改？能敢说不改么？ 这不改了么～

2、优化崩溃列表信息展示关键堆栈，一目了然

卡顿功能推出时，卡顿列表中问题第三行信息直接改成“首行应用堆栈”信息，获得大家的一致好评。现在崩溃列表也支持了，愿大家定位崩溃更轻松～

------------更多功能介绍-------------

1、更新 Android NDK动态库 2.0.5

Android Native异常堆栈获取方式重构，获取更全更完善的堆栈

解决空堆栈“empty stack”问题

新增架构支持： arm64-v8a 、x86 、x86_64

2、更新 Unity Plugin SDK 1.2.5

修改接口类为BuglyAgent.cs

修改初始化方法为BuglyAgent.InitWithAppId(string)

添加系统日志回调方法BuglyAgent.LogCallbackDelegate 以替换Application.LogCallback

添加方法BuglyAgent.ReportException(Exception, string)主动上报自定义C#异常

添加方法BuglyAgent.ReportException (string, string, string)主动上报自定义错误

【小编有话说】

听说七夕将至，Bugly的技术同学加班加点，为各位开发哥哥献上这些新功能，希望各位用的放心，用的舒心。人生苦短，把那些配置符号表，辛苦找Crash的时间都拿去挥洒吧，约会自己心中的女神与男神，而们会默默祝福，暂时只能帮您到这儿了。

想了解更多新功能？请密切关注Bulgy的公众号。

腾讯Bugly 最专业的质量跟踪平台

精神哥、小萝莉，为您定期分享应用崩溃解决方案