自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的公众号。
版权声明:本文为博主原创文章,未经博主允许不得转载。
原文地址:http://blog.csdn.net/tencent_bugly/article/details/47616189