Android bug的监听与定位

出现总结下来有2个原因。
1.在Android开发中，平时开发测试很正常。但是到用户手机上，就可能出现各种bug,因为Android 系统的版本的碎片化，以及各个手机品牌对Android 系统的深度定制，导致有时bug很难复现。
2.由于Android 主要是用java语言开发，在我们开发的平时，我们一般是在debug下，对于闪退等问题可以快速定位到具体的类、方法、代码行数。当我们发布的App，为了保护我们的应用版本，我们都会对代码进行混淆，让我们的类名、方法名、变量名用 “abcd”等各种字符代替，可读性差，不易定位问题。这虽然保护了我们的应用不易被别有用心之人破解，但是也增加了我们自己在拿到闪退日志时定位bug的难度，这也只是增加了一点难度，并不是无法破解，作为程序员，这些问题肯定不是问题的。

下面我来解决，平时我是怎么监听并解决线上App出现的bug。

第一步，获取日志

监听闪退的日志，首先我们要了解一个类
Thread.UncaughtExceptionHandler
这个是系统处理那些我们没有try{}catch的代码，但是出现异常的。这个类我们只需要处理一个方法，uncaughtException(Thread thread, Throwable ex)，这个ex包含了闪退时的信息。
我们主要是在关注这个Throwable里的信息。下面是我处理的ex的代码块。

     try {
            Writer writer = new StringWriter();
            PrintWriter printWriter = new PrintWriter(writer);
            ex.printStackTrace(printWriter);
            Throwable cause = ex.getCause();
            while (cause != null) {
                cause.printStackTrace(printWriter);
                cause = cause.getCause();
            }
            printWriter.close();
            String result = writer.toString();

            
        } catch (Exception ex2) {

        }

result 就是我们闪退日志的信息。我们可以处理将这个信息写入到本地，在后期上传到服务器。也可以通过其它的日志异常系统，如bugly、umeng上传。同时我们可以在追回一些信息，如设备的型号、发生时间等。完整的crach 处理类

public class CrashHandler implements Thread.UncaughtExceptionHandler {

    public static final String TAG = "CrashHandler";
    //CrashHandler实例
    private static CrashHandler INSTANCE = new CrashHandler();
    //系统默认的UncaughtException处理类
    private Thread.UncaughtExceptionHandler mDefaultHandler;
    //程序的Context对象
    private Context mContext;

    private static int DELAY_TIME = 3000;
    /**
     * 保证只有一个CrashHandler实例
     */
    public CrashHandler() {
    }

    /**
     * 获取CrashHandler实例 ,单例模式
     */
    public static CrashHandler getInstance() {
        return INSTANCE;
    }
    /**
     * 初始化
     *
     * @param context
     */
    public void init(Context context) {
        mContext = context;
        //获取系统默认的UncaughtException处理器
        mDefaultHandler = Thread.getDefaultUncaughtExceptionHandler();
        //设置该CrashHandler为程序的默认处理器
        Thread.setDefaultUncaughtExceptionHandler(this);
    }

    /**
     * 当UncaughtException发生时会转入该函数来处理
     */
    @Override
    public void uncaughtException(Thread thread, Throwable ex) {
        try {
            Writer writer = new StringWriter();
            PrintWriter printWriter = new PrintWriter(writer);
            ex.printStackTrace(printWriter);
            Throwable cause = ex.getCause();
            while (cause != null) {
                cause.printStackTrace(printWriter);
                cause = cause.getCause();
            }
            printWriter.close();
            String result = writer.toString();

            Exception throwable = new Exception(result);

            CrashReport.postCatchedException(throwable);
        } catch (Exception ex2) {

        }
        if ( mDefaultHandler != null) {
            //如果用户没有处理则让系统默认的异常处理器来处理
            try {
                Thread.sleep(DELAY_TIME);
            } catch (InterruptedException e1) {
            }
            try {
                mDefaultHandler.uncaughtException(thread, ex);
            } catch (Exception ex1) {
                //ignored
            }
            //mDefaultHandler.uncaughtException(thread, ex);
        } else {
            //退出程序
            killProcessAndExit();
        }
    }


    private void killProcessAndExit() {
        try {
            Thread.sleep(DELAY_TIME);
            android.os.Process.killProcess(android.os.Process.myPid());
            System.exit(8);
        } catch (Exception e) {
            //ignored
        }
    }

}

接下来，我们只需要在我们的Application 调用就可以：CrashHandler.getInstance().init(this);

第二步，还原日志，定位问题

上面我们可以拿到闪退时的日志，但是经过混淆后，我们要如何定位。
我在页面中点击事件加入如下代码。

    String a = "12gd";
    int b = Iunteger.parseInt("a");

这个平时我们肯定在数据转换时try{}catch。如果不处理，这肯定会出现java.lang.NumberFormatException。在线上时，然后我们知道出现了问题，但是APP对应的页面可能有上百个，大量的代码中如何找到异常的位置。我们还是要从混淆入手。

java.lang.NumberFormatException: For input string: "a"
at java.lang.Integer.parseInt(Integer.java:608)
at java.lang.Integer.parseInt(Integer.java:643)
at c.e.a.q.j.b.fa.clickView(:538)
at c.e.a.c.b.onClick(:354)
at android.view.View.performClick(View.java:6266)
at android.view.View$PerformClick.run(View.java:24730)
at android.os.Handler.handleCallback(Handler.java:793)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:173)
at android.app.ActivityThread.main(ActivityThread.java:6698)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:782)

正常情况，我们混淆发布版本时，都会生成一个mapping.txt文件，这个是混淆前后的映射表。路径一般是在app 下的build文件夹
build/outputs/mapping/release/mapping.txt

这时我们在借助proguard提供的工具proguardgui，路径在我们的Android SDK目录下，/tools/proguard/bin/proguardgui.sh 。windows系统是proguardgui.bat。
如何运行.sh文件，我们打开命令终端，./proguardgui.sh

image.png

找到侧边 “Retrace”，打开如下

image.png

Mapping 就是上面提供的mapping.txt文件，
obfuscated stack trace就是混淆后的闪退日志。
点击下面的Retrace按钮，得到混淆前的日志。

image.png

得到混淆前的报错代码

java.lang.NumberFormatException: For input string: "a"
at java.lang.Integer.parseInt(Integer.java:608)
at java.lang.Integer.parseInt(Integer.java:643)
at com.xxx.xxxx.xxxxx.xxxxxx.xxxxx.xxFragment.clickView(:538)
at com.xxx.xxxx.xxxxx.BaseFragment.onClick(:354)
at android.view.View.performClick(View.java:6266)
at android.view.View$PerformClick.run(View.java:24730)
at android.os.Handler.handleCallback(Handler.java:793)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:173)
at android.app.ActivityThread.main(ActivityThread.java:6698)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:782)

这些我们就找到了具体代码出现位置，这样就可以把我们致命的可恨的闪退bug修复了。
通过上述方法，让bug在我人照妖镜下立马现出原型。
bug永远改不完，且行且珍惜。