[关闭]
@avenwu 2017-09-07T06:04:00.000000Z 字数 5723 阅读 140

对异常收集的一些思考与优化

1. 背景

在分析崩溃bug的时候,我们非常倚重调用栈日志,他在大多数情况下可以帮助开发者定位崩溃的逻辑链路,比如是哪个页面的控件出现了什么空指针之类的。

但是总有那么些个崩溃是没有这种有效日志的,没有办法定位崩溃源的样子真让人感到无助。

  1. # main(1)
  2. java.lang.NullPointerException
  3. Attempt to invoke virtual method 'int android.view.View.getVisibility()' on a null object reference
  4. 1 android.widget.FrameLayout.layoutChildren(FrameLayout.java:531)
  5. 2 android.widget.FrameLayout.onLayout(FrameLayout.java:514)
  6. 3 android.view.View.layout(View.java:15695)
  7. 4 android.view.ViewGroup.layout(ViewGroup.java:5048)
  8. //...
  9. 23 android.os.Handler.dispatchMessage(Handler.java:95)
  10. 24 android.os.Looper.loop(Looper.java:147)
  11. 25 android.app.ActivityThread.main(ActivityThread.java:5513)
  12. 26 java.lang.reflect.Method.invoke(Native Method)
  13. 27 java.lang.reflect.Method.invoke(Method.java:372)
  14. 28 com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:969)
  15. 29 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:764)

诸如此类信息不足以定位的bug还是很常见的。

2. 数据收集

为了方便定位问题,我们在早些时候时候写了一个Tango小模块,专门用来收集崩溃信息。
彼时我们根据需要定义了一套收集的内容和传输协议。

  1. {
  2. "process": "process name"
  3. "taskInfo": {
  4. "topActivity": "component name",
  5. "baseActivity": "component name",
  6. "origActivity": "optional component name"
  7. },
  8. "dump": {
  9. "activity": "activity name",
  10. "pluginName": "optional package name",
  11. "pluginClassName": "optional real activity name",
  12. "fragment#0": "fragment data",
  13. "deep": "optional hierarchy dump deep",
  14. "hierarchy": "optional view stack"
  15. }
  16. }

Tango设计图

经过一段时间的使用,这个模块有效的帮助我们定位解决了大量bug,现在几乎成了分析bug的一个必经流程,比如通过他定位bug的模块关系,从而分配负责修复的RD。

3. 协议扩展

由于业务的特殊性,在我们58App当中,存在大量的业务线,也存在很多载体相同但是动态承载分类业务的情况,比如我们的黄页大类下面有成百个自己分类,每个分类都可以进入对应的分类列表页面。
这个时候如果这种共性在载体页面发生了崩溃,我们如何定位他的业务类别呢?

基于此,我们想到扩展协议,让Tango手机必要的参数用于是被页面信息。通过梳理业务逻辑和思考,我们知道在Andorid中页面载体主要是Activity和Fragment,他们之间的跳转和承载必然会涉及到页面间的参数,而我们的业务线,实际上也是通过常规的intent和bundle进行数据传递的。因此我们的扩展非常明确,支持收集Activity的bundle[1]信息和Fragment的Bundle[2]信息。

tango协议

  1. {
  2. "process": "process name"
  3. "taskInfo": {
  4. "topActivity": "component name",
  5. "baseActivity": "component name",
  6. "origActivity": "optional component name"
  7. },
  8. "dump": {
  9. "activity": "activity name",
  10. "extras": "Bundle[]",
  11. "fragments": [
  12. {
  13. "bundle": "Bundle[]",
  14. "fragment": "fragment name"
  15. }
  16. ],
  17. "pluginName": "optional package name",
  18. "pluginClassName": "optional real activity name",
  19. "deep": "optional hierarchy dump deep",
  20. "hierarchy": "optional view stack"
  21. }
  22. }

在收集的时候,需要注意兼容一下android.support.v4.app.Fragmentandroid.app.Fragment

4. 数据分析

过去我们分析上传的数据主要是人工,原因也很简单,为了让数据和bug能够一一吻合上,我们是直接把数据和崩溃信息一起上传到bugly[3]这边的。但是目前bugly并没有提供相关API供我们做数据分析和二次开发。所以我们的分析就是在bugly查询页面直接查看对应的日志,如果数据较多就复制出来通过json工具进行格式化后再阅读。

手工分析日志流程

这个流程基本上是可行的,但是也有他的缺点:

  1. 阅读日志的RD必须理解我们的的协议格式,起码要知道关键字段的含义。

现在我们的协议字段内容已经比较多了,如果继续按以前的老版本手工提取日志然后格式化查看的话就显得比较费劲了。因此我们设计并开发了专门用于提取Tango协议日志的工具 Tango助手[4]

Tango助手基于Chrome Extension[5] 技术开发, 可以在我们查阅bug详情时,自动提取并解析上传到bugly上的定制信息。

tango分析日志流程
他的好处在于:

可视化面板

我们的数据面板有两块,通过设置项可以设置插件自动识别完日志后谭树提示框,这个信息只做了简单提取Activity,和格式化;
如果觉得自动弹窗比较烦人那么可以设置插件不弹窗(默认是不弹窗),这个时候日志提取完了,上哪去看呢?可以点击右上角的插件按钮,会弹出相对详细的内容。

如果说由于web页面大改版了或者bug什么的,导致插件没有自动提取到数据时怎么办呢,还可以手动提取,选中日志右键菜单选择提取日志就可以了,这个时候会再次识别选中内容并弹出提示面板。

5. 自动提取实现

好了,是时候讲一下我们的插件是如何工作的。

tango插件工作流程

基本上这就是我们的整个工作流程。如果懂js的话,基本可以照着整个思路直接实现了。

5.1 注意事项

这里提几个extension开发需要注意的一些点:

所以我们的整体流程的工作其实是分散在不同js当中的,不同的面板触发也是不同逻辑。

讲了这么多,还不放点代码么?

5.2 代码示例

控制插件按钮的可用性,如果没有命中日志,我们希望按钮点击不生效,只有有数据的时候才启用。这个实现实际上是通过api动态设置按钮的状态实现的。

  1. function updateBrowserAction(enable) {
  2. if (enable) {
  3. chrome.browserAction.enable();
  4. chrome.browserAction.setTitle({title: i18n('browser_action_enable_tips')});
  5. chrome.browserAction.setBadgeText({text: "new"});
  6. chrome.browserAction.setBadgeBackgroundColor({color: '#f44336'});
  7. } else {
  8. chrome.browserAction.disable();
  9. chrome.browserAction.setTitle({title: i18n('browser_action_disable_tips')});
  10. }
  11. }

你是怎么过滤的DOM数据? 这个使功能使我们的插件真正做到了自动解析,那么简单看下代码吧;

  1. function selectTangoLogElements() {
  2. console.log("select log elements...");
  3. // this elements sequence base on web page layout
  4. $('td span:nth-of-type(2)').each(function (index, element) {
  5. if (element.innerText.indexOf('Tango: ') !== -1) {
  6. var innerText = element.innerText;
  7. var logString = innerText.split('Tango: ')[1];
  8. console.log(logString);
  9. try {
  10. var tangoLog = JSON.parse(logString);
  11. tangoLog.timestamp = new Date().toUTCString();
  12. chrome.runtime.sendMessage({
  13. parseTangoLog: true,
  14. tangoLog: tangoLog
  15. }, function (r) {
  16. console.log('send message', r);
  17. });
  18. } catch (e) {
  19. console.log('skip invalid log', e);
  20. }
  21. }
  22. })
  23. }

实际上就是拦截了dom元素,然后根据我们提前观察,得出日志所在的dom树中的位置,然后就提取啦。

为什么你的弹框这么大,alert应该是很小很丑的以一个样子啊。这个确实比较麻烦, 笔者毕竟不是很懂前端的一套,想要我自定义一个alert是困难的。因此我的做法是往当前的dom里面插入一个div,这个div动态控制显示状态模拟出alert弹窗的效果就好了。

  1. $('#modal1').modal({
  2. dismissible: true, // Modal can be dismissed by clicking outside of the modal
  3. opacity: .5, // Opacity of modal background
  4. inDuration: 300, // Transition in duration
  5. outDuration: 200, // Transition out duration
  6. startingTop: '4%', // Starting top style attribute
  7. endingTop: '10%', // Ending top style attribute
  8. ready: function (modal, trigger) { // Callback for Modal open. Modal and trigger parameters available.
  9. console.log(modal, trigger);
  10. },
  11. complete: function () {
  12. console.log('Closed');
  13. unloadCSS('materialize-fonts-icon');
  14. unloadCSS('materialize-min');
  15. } // Callback for Modal close
  16. }
  17. );
  18. $('#modal1').modal('open');

示例就讲到这,最后我们在简单总结下。

7. 小结

一:PHP是最好的语言?
二:插件里面主要使用的js,如果有些语法写的不正确,请原谅,我只懂这么多啦。
三:对我们的异常收集有什么其他建设性的建议,欢迎指正。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注