如何解读Google Play Store崩溃报告？ProGuard混淆问题排查

嘿，我来帮你拆解这类被ProGuard混淆过的崩溃日志！首先得明白为什么会出现这些看起来奇怪的方法名，比如access$1000、access$1502这类，还有被缩短的方法名——这都是ProGuard搞的鬼：它会把类、方法、变量的原名替换成无意义的短名称来减小包体积，同时生成access$xxx这类方法，用来让内部类能访问外部类的私有成员。

下面是具体的解读和排查步骤：

• 核心前提：找到对应的mapping文件
  每次用ProGuard构建发布版本时，都会在app/build/outputs/mapping/release/路径下生成一个mapping.txt文件，它是混淆后的名称和原代码名称的对应表。这个文件一定要按版本备份好，每个发布版本的mapping都不能丢——不同版本的混淆规则和结果是不一样的。

• 用retrace工具还原真实日志
  Android SDK自带了retrace工具，路径在SDK目录/tools/proguard/bin/下，Windows用retrace.bat，Mac/Linux用retrace.sh。你只需要把mapping文件和崩溃日志作为参数传入，就能还原出真实的方法名和代码位置：

  # Mac/Linux示例
  retrace.sh path/to/mapping.txt path/to/crash-report.txt
  
  # Windows示例
  retrace.bat path/to/mapping.txt path/to/crash-report.txt
  

  执行后，你就能看到崩溃发生在原代码的哪个具体方法、哪一行，空指针的根源一下子就清晰了。

• 如果没有mapping文件怎么办？
  这就比较棘手了，但也不是完全没办法：

  • 先看那些没被完全混淆的方法名，比如你日志里的doStamping、handleIntent、wrongFilePopup，这些可能因为被注解标记（比如@Keep）、或者是对外暴露的方法，没被ProGuard重命名，你可以先聚焦这些方法，排查里面的空指针场景——比如是否有对象在调用前没做判空处理（比如Intent、按钮控件、文件对象等）。
  • 至于access$xxx这类方法，它们是内部类访问外部类私有成员的桥接方法，说明问题可能出在MainActivity的内部类和外部类交互的地方，比如内部类尝试访问外部类的某个已被销毁的变量。

• 预防下次踩坑

  • 每次发布版本时，务必备份mapping.txt，最好和对应版本的APK一起归档，或者上传到Google Play的App Signing服务里（如果你用了官方签名），这样Google Play后台会自动帮你还原崩溃日志。
  • 可以在ProGuard规则里添加-keepattributes SourceFile,LineNumberTable，这样即使方法名被混淆，崩溃日志里也能显示具体的代码行号，方便排查。
  • 对核心业务类或方法，用@Keep注解或者ProGuard规则保留原名，比如：

    -keep class com.xxx.MainActivity {
        void doStamping();
        void handleIntent(android.content.Intent);
    }
    

内容的提问来源于stack exchange，提问作者j3App