安卓代码混淆后的定位代码混淆是什么？ 如何打开Android Studio的代码混淆如何将流程定位到程序崩溃后崩溃的代码行mapping.txt
什么是代码混淆
在用java编写的. java文件之后，使用javac编译为. class文件。 在编译过程中，不是像C/C和C#那样在编译时加密或混淆，而是将其直接编码、标记化的编译处理。 因此，还出现了逆向工程问题，即可以从. class文件反向分析为原始java文件。
大多数安卓APP应用程序都是用Java语言编写的，在发布自己的程序时，有非常重要的功能和组件。 因为我们不希望别人反编译后直接使用，所以代码可能会混淆。 当然，一些非常重要的东西是用抄送写的，在动态库中调用。
如图所示，如果开放代码是混淆的，则反编译的代码和左边的源代码几乎是对应的，很容易找到代码的逻辑。
混淆代码后，反编译的源代码如下所示。
打开反编译后，可以看出程序的代码大致得到了一定程度的保护。
目前有多种混淆代码的方法，其中安卓studio附带一种。 他用相似的名称“重命名”包名、类名和方法名，这也使得读反编译的代码非常困难：
当然，目前更安全的方法是将字节码文件转换为动态库，这大大增加了反编译的难度，包括增强了腾讯APP应用。
打开android Studio代码混淆的方法目前也有多种。 最简单的方法是Android Studio提供的代码混淆功能。 通过在APP应用程序模块的build.gradle中将minifyEnabled更改为true，可以打开代码混淆功能。
此外，还可以自定义和设置混淆规则。 Android Studio系统的默认混淆规则文件只需要在对等目录下的名为proguard-rules.pro的文件中修改proguard-rules.pro。 以下是一些常见的混淆规则。 具体请参阅缩小、混淆处理、优化APP应用
#指定压缩级别(0到7之间，默认值为5，通常不需要更改(-optimizationpasses 7# ) )在混淆时不使用大小写混合。 混淆的类名是小写字母(如果混淆大小写，则class文件容易相互复盖(-dontusemixedcaseclassnames# )保护代码中的注释不混淆)这在Json实体映射中非常重要，如FastJson )-keepattributes*annotes这是fast JSON-keepattributessision }#设置为在抛出异常时保留代码行号- keepattributessourcefile.line number table #忽略警告(谨慎使用)-ignorewarnings#未混淆的类和成员)保留apk中的所有本地native方法，以免混淆- keepclasseswithmembernamesclass * { native methods； 保存从android.view.View类继承的子类的-在keep public class * extends Android.view # activity中保存的方法参数是view的方法。 因此，我们只要在layout上写onClick就不受影响- keepclassmembersclass * extends Android.app.activity { public void * (Android.view }#枚举类不要混淆- keepclassmembersenum * { public static * * [ ] values (； public static * * value of (Java.lang.string )； 保留Parcelable序列化的类不应混淆- keepclass * implements Android.OS.parcelable { publicstaticfinalandroid.OS.parcelable $ }程序崩溃后，如何定位于崩溃的代码行mapping.txt代码具有优势，但对于开发人员来说，在不添加日志的情况下，程序崩溃后，很难确定在特定的代码位置
如照片所示，在Crash日志中找不到任何异常的位置。 如果知道Crash的位置，并且该类的代码量很少，则可以通过添加日志来缓慢分析其定位，但如果是其他情况呢？
幸运的是，Android Studio在混淆代码的同时会生成名为mapping.txt的索引文件并通过
这份文件还是可以比较轻松的定位出问题来源的，该文件位置为 build/outputs/mapping/debug/mapping.txt ，当然这个文件的位置会根据你的配置也许会有所不同的。分析流程
在日志中的输出为：
java.lang.NullPointerException at java.io.File.<init>(File.java:283) at com.imorning.demo.MainActivity.F(:26) at com.imorning.demo.MainActivity.E(Unknown Source:0) at k1.a.onClick(Unknown Source:2) at android.view.View.performClick(View.java:7448) at com.google.android.material.button.MaterialButton.performClick(:1119) at android.view.View.performClickInternal(View.java:7425) at android.view.View.access$3600(View.java:810) at android.view.View$PerformClick.run(View.java:28305) at android.os.Handler.handleCallback(Handler.java:938) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:223) at android.app.ActivityThread.main(ActivityThread.java:7656) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)在这其中，比较重要的几句就是
at java.io.File.<init>(File.java:283)at com.imorning.demo.MainActivity.F(:26)at com.imorning.demo.MainActivity.E(Unknown Source:0)首先通过 java.io.File.<init> 这一句可以确定该异常发生的位置是在构造 File 对象的时候，类似于 new File(filePath) 这种情况，然后根据
at com.imorning.demo.MainActivity.F(:26)at com.imorning.demo.MainActivity.E(Unknown Source:0)这两句可以判断是在 MainActivity 这个类里面，具体的方法是F和E，但是很显然我们的源代码里面是不存在这两个方法的，所以这两个方法是由于代码混淆后产生的，那如何确定他们在源代码中的名字是啥呢？
打开 mapping.txt 文件，搜索 com.imorning.demo.MainActivity 这个类，然后可以找到如下内容：
可以在第一部分很明显找到E和F两个函数的定义，分别是：
$r8$lambda$jbVq07liQWCDW9wfWoMM5fMjaN0(com.imorning.demo.MainActivity,android.view.View) -> E26:28:void lambda$onCreate$0(android.view.View) -> F这里由于使用了lambda表达式，因此对于函数E的确认有点问题，不过问题不大，可以通过其两个参数确定出来大致范围，并且由于使用了lambda表达式也是比较好确认的。
对于函数F则可以直接看出来它的函数名是onCreate()，因此定位比较简单，同时也就确认了函数E是在onCreate()中的某个方法，并且使用了File的构造函数，这样一来便可以确定出来位置了：