属性名已经改变了, 变成了没有意思的名称, 对我们后续的某些处理是很麻烦的.
反序列化的代码
Gson gson = new Gson();
Item item = gson.fromJson(“{“id”:1, “name”:“Orange”}”, Item.class);
Log.i(LOGTAG, “testGson item.id=” + item.id + “;item.name=” + item.name);
对应的日志结果是
I/MainActivity: testGson item.id=0;item.name=null
可见, 混淆之后, 反序列化的属性值设置都失败了.
为什么呢?
- 因为反序列化创建对象本质还是利用反射, 会根据 json 字符串的 key 作为属性名称, value 则对应属性值.
如何解决
-
将序列化和反序列化的类排除混淆
-
使用 @SerializedName 注解字段
@SerializedName(parameter) 通过注解属性实现了
-
序列化的结果中, 指定该属性 key 为 parameter 的值.
-
反序列化生成的对象中, 用来匹配 key 与 parameter 并赋予属性值.
一个简单的用法为
public class Item {
@SerializedName(“name”)
public String name;
@SerializedName(“id”)
public int id;
}
当然也可以直接这么写
public class Item implements Serializable{
public String name;
public int id;
}
上面是通过添加 @SerializedName 注解实现混淆之后反序列化出现的问题,下面我们说下将将序列化和反序列化的类排除混淆该怎么做。
package com.baidu.bean;
public class Item {
public String name;
public int id;
public static class PageConfig {
public String type;
}
}
Item 中增加了一个内部类 PageConfig。
这里敲黑板了:
1.Item 里面的字段、Item 里面引用到的类和 Item 里面的内部类 PageConfig 都需要实现序列化 (implements Serializable);
- 如果不是 implements Serializable 实现序列化,而是给每个字段加上 @SerializedName 注解,那么务必注意:Item 里面的字段、Item 里面引用到的类的和 Item 里面的内部类的字段都需要加上 @SerializedName 注解,否则会出现莫名其妙的问题:不会崩溃,就是各种奇怪现象,而在 debug 下又不出现这个问题。
最常见的做法是:
-keep class com.baidu.bean.** { *; }
含义是:将 bean 目录下包括子目录下的类排除不被混淆
单独排除某个类可以这么写:
-keep class com.baidu.bean {*;}
单独排除某个类的内部类需要这么写:
-keep class class com.baidu.bean.Item$PageConfig {*;}
如果很多实体类里面有内部类,建议组合起来写:
-keep class com.baidu.bean.**{ *;}
-keep class com.baidu.bean.**$*{ *;}
另外,下面的写法也是可以的,主要以上面的写法为主。具体要使用哪种,读者可以自己根据需要使用。
-keep class com.baidu.bean.$** {;}
-keep class com.baidu.bean.$ {*;}
-keep class com.baidu.bean.**$* {*;}
上面出现了 * 和 ** 通配符的配置,为了便于加深印象,这里延伸阅读下:
============================================================================
1. 混淆配置
android{
buildTypes {
release {
buildConfigField “boolean”, “LOG_DEBUG”, “false” //不显示log
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’
signingConfig signingConfigs.config
}
}
}
因为开启混淆会使编译时间变长,所以 debug 模式下不开启。我们需要做的是:
-
将
release下minifyEnabled
的值改为true
,打开混淆; -
加上
shrinkResources true
,打开资源压缩。
3.buildConfigField
不显示 log 日志
4.signingConfig signingConfigs.config
配置签名文件文件
=====================================================================
自定义混淆方案适用于大部分的项目
#指定压缩级别
-optimizationpasses 5
#不跳过非公共的库的类成员
-dontskipnonpubliclibraryclassmembers
#混淆时采用的算法
-optimizations !code/simplification/arithmetic,!field/,!class/merging/
#把混淆类中的方法名也混淆了
-useuniqueclassmembernames
#优化时允许访问并修改有修饰符的类和类的成员
-allowaccessmodification
#将文件来源重命名为“SourceFile”字符串
-renamesourcefileattribute SourceFile
#保留行号
-keepattributes SourceFile,LineNumberTable
#保持泛型
-keepattributes Signature
#保持所有实现 Serializable 接口的类成员
-keepclassmembers class * implements java.io.Serializable {
static final long serialVersionUID;
private static final java.io.ObjectStreamField[] serialPersistentFields;
private void writeObject(java.io.ObjectOutputStream);
private void readObject(java.io.ObjectInputStream);
java.lang.Object writeReplace();
java.lang.Object readResolve();
}
#Fragment不需要在AndroidManifest.xml中注册,需要额外保护下
-keep public class * extends android.support.v4.app.Fragment
-keep public class * extends android.app.Fragment
保持测试相关的代码
-dontnote junit.framework.**
-dontnote junit.runner.**
-dontwarn android.test.**
-dontwarn android.support.test.**
-dontwarn org.junit.**
真正通用的、需要添加的就是上面这些,除此之外,需要每个项目根据自身的需求添加一些混淆规则:
第三方库所需的混淆规则。正规的第三方库一般都会在接入文档中写好所需混淆规则,使用时注意添加。
在运行时动态改变的代码,例如反射。比较典型的例子就是会与 json 相互转换的实体类。假如项目命名规范要求实体类都要放在 model 包下的话,可以添加类似这样的代码把所有实体类都保持住:-keep public class **.*Model*.** {*;}
JNI 中调用的类。
WebView 中JavaScript
调用的方法
Layout 布局使用的 View 构造函数、android:onClick
等。
====================================================================
混淆过的包必须进行检查,避免因混淆引入的 bug。
一方面,需要从代码层面检查。使用上文的配置进行混淆打包后在<module-name>/build/outputs/mapping/release/
目录下会输出以下文件:
dump.txt
描述 APK 文件中所有类的内部结构
mapping.txt
提供混淆前后类、方法、类成员等的对照表
seeds.txt
列出没有被混淆的类和成员
usage.txt
列出被移除的代码
我们可以根据 seeds.txt
文件检查未被混淆的类和成员中是否已包含所有期望保留的,再根据 usage.txt
文件查看是否有被误移除的代码。
另一方面,需要从测试方面检查。将混淆过的包进行全方面测试,检查是否有 bug 产生。
===================================================================
混淆后的类、方法名等等难以阅读,这固然会增加逆向工程的难度,但对追踪线上 crash 也造成了阻碍。我们拿到 crash 的堆栈信息后会发现很难定位,这时需要将混淆反解。
在 <sdk-root>/tools/proguard/
路径下有附带的的反解工具(Window 系统为proguardgui.bat
,Mac 或 Linux 系统为proguardgui.sh
)。
这里以 Window 平台为例。双击运行 proguardgui.bat 后,可以看到左侧的一行菜单。点击 ReTrace,选择该混淆包对应的 mapping 文件(混淆后在 /build/outputs/mapping/release/ 路径下会生成 mapping.txt 文件,它的作用是提供混淆前后类、方法、类成员等的对照表),再将 crash 的 stack trace 黏贴进输入框中,点击右下角的 ReTrace ,混淆后的堆栈信息就显示出来了。
以上使用 GUI 程序进行操作,另一种方式是利用该路径下的 retrace 工具通过命令行进行反解,命令是
retrace.bat|retrace.sh [-verbose] mapping.txt [<stacktrace_file>]
例如:
retrace.bat -verbose mapping.txt obfuscated_trace.txt
注意事项:
所有在 AndroidManifest.xml
涉及到的类已经自动被保持,因此不用特意去添加这块混淆规则。(很多老的混淆文件里会加,现在已经没必要)
proguard-android.txt
已经存在一些默认混淆规则,没必要在 proguard-rules.pro 重复添加
==================================================================
Android 中的 “混淆” 可以分为两部分,一部分是Java
代码的优化与混淆,依靠 proguard
混淆器来实现;另一部分是资源压缩,将移除项目及依赖的库中未被使用的资源 (资源压缩严格意义上跟混淆没啥关系,但一般我们都会放一起用)。
代码压缩流程
代码混淆是包含了代码压缩、优化、混淆等一系列行为的过程。如上图所示,混淆过程会有如下几个功能:
压缩。移除无效的类、类成员、方法、属性等;
优化。分析和优化方法的二进制代码;根据proguard-android-optimize.txt
中的描述,优化可能会造成一些潜在风险,不能保证在所有版本的 Dalvik 上都正常运行。
混淆。把类名、属性名、方法名替换为简短且无意义的名称;
预校验。添加预校验信息。这个预校验是作用在 Java 平台上的,Android 平台上不需要这项功能,去掉之后还可以加快混淆速度。
这四个流程默认开启。
在Android
项目中我们可以选择将 “优化” 和“预校验”关闭,对应命令是-dontoptimize、-dontpreverify
(当然,默认的 proguard-android.txt
文件已包含这两条混淆命令,不需要开发者额外配置)。
==================================================================
资源压缩将移除项目及依赖的库中未被使用的资源,这在减少apk
包体积上会有不错的效果,一般建议开启。具体做法是在 build.grade
文件中,将shrinkResources
属性设置为true
。需要注意的是,只有在用minifyEnabled true
开启了代码压缩后,资源压缩才会生效。
资源压缩包含了 “合并资源” 和“移除资源”两个流程。
“合并资源” 流程中,名称相同的资源被视为重复资源会被合并。需要注意的是,这一流程不受shrinkResources
属性控制,也无法被禁止,gradle
必然会做这项工作,因为假如不同项目中存在相同名称的资源将导致错误。gradle
在四处地方寻找重复资源:
src/main/res/
路径
不同的构建类型(debug
、release
等等)
不同的构建渠道
项目依赖的第三方库
合并资源时按照如下优先级顺序
依赖 -> main -> 渠道 -> 构建类型
假如重复资源同时存在于 main 文件夹和不同渠道中,gradle 会选择保留渠道中的资源。
同时,如果重复资源在同一层次出现,比如src/main/res/ 和 src/main/res2/
,则 gradle
无法完成资源合并,这时会报资源合并错误。
“移除资源” 流程则见名知意,需要注意的是,类似代码,混淆资源移除也可以定义哪些资源需要被保留,这点在下文给出。
=====================================================================
在上文 “混淆配置” 中有这样一行代码
proguardFiles getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’
这行代码定义了混淆规则由两部分构成:位于 SDK 的 tools/proguard/ 文件夹中的 proguard-android.txt 的内容以及默认放置于模块根目录的 proguard-rules.pro 的内容。前者是 SDK 提供的默认混淆文件,后者是开发者自定义混淆规则的地方。
=====================================================================
-
optimizationpasses
-
dontoptimize
-
dontusemixedcaseclassnames
-
dontskipnonpubliclibraryclasses
-
dontpreverify
-
dontwarn
-
verbose
-
optimizations
-
keep
-
keepnames
-
keepclassmembers
-
keepclassmembernames
-
keepclasseswithmembers
-
keepclasseswithmembernames
更多详细的请到官网
需要特别介绍的是与保持相关元素不参与混淆的规则相关的几种命令:
| 命令 | 作用 |
| — | — |
| -keep | 防止类和成员被移除或者被重命名 |
| -keepnames | 防止类和成员被重命名 |
| -keepclassmembers | 防止成员被移除或者被重命名 |
| -keepnames | 防止成员被重命名 |
| -keepclasseswithmembers | 防止拥有该成员的类和成员被移除或者被重命名 |
| -keepclasseswithmembernames | 防止拥有该成员的类和成员被重命名 |
[保持命令] [类] {
[成员]
}
“类” 代表类相关的限定条件,它将最终定位到某些符合该限定条件的类。它的内容可以使用:
-
具体的类
-
访问修饰符(public、protected、private)
-
通配符 *,匹配任意长度字符,但不含包名分隔符 (.)
-
通配符 **,匹配任意长度字符,并且包含包名分隔符 (.)
-
extends,即可以指定类的基类
-
implement,匹配实现了某接口的类
-
$,内部类
“成员” 代表类成员相关的限定条件,它将最终定位到某些符合该限定条件的类成员。它的内容可以使用:
-
匹配所有构造器
-
匹配所有域
-
匹配所有方法
-
通配符 *,匹配任意长度字符,但不含包名分隔符 (.)
-
通配符 **,匹配任意长度字符,并且包含包名分隔符 (.)
-
通配符 ***,匹配任意参数类型
-
…,匹配任意长度的任意类型参数。比如 void test(…) 就能匹配任意 void test(String a) 或者是 void test(int a, String b) 这些方法。
-
访问修饰符(public、protected、private)
举个例子,假如需要将 com.biaobiao.test 包下所有继承 Activity 的 public 类及其构造函数都保持住,可以这样写:
-keep public class com.biaobiao.test.** extends Android.app.Activity {
}
- 不混淆某个类
-keep public class com.biaobiao.example.Test { *; }
不混淆某个包所有的类
-keep class com.biaobiao.test.** { *; }
}
不混淆某个类的子类
-keep public class * extends com.biaobiao.example.Test { *; }
不混淆所有类名中包含了 “model” 的类及其成员
-keep public class * extends com.biaobiao.example.Test { *; }
不混淆某个接口的实现
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip204888 (备注Android)
最后说一下我的学习路线
其实很简单就下面这张图,含概了Android所有需要学的知识点,一共8大板块:
- 架构师筑基必备技能
- Android框架体系架构(高级UI+FrameWork源码)
- 360°Androidapp全方位性能调优
- 设计思想解读开源框架
- NDK模块开发
- 移动架构师专题项目实战环节
- 移动架构师不可不学习微信小程序
- 混合开发的flutter
Android学习的资料
我呢,把上面八大板块的分支都系统的做了一份学习系统的资料和视频,大概就下面这些,我就不全部写出来了,不然太长了影响大家的阅读。
330页PDF Android学习核心笔记(内含上面8大板块)
Android学习的系统对应视频
总结
我希望通过我自己的学习方法来帮助大家去提升技术:
-
1、多看书、看源码和做项目,平时多种总结
-
2、不能停留在一些基本api的使用上,应该往更深层次的方向去研究,比如activity、view的内部运行机制,比如Android内存优化,比如aidl,比如JNI等,并不仅仅停留在会用,而要通过阅读源码,理解其实现原理
-
3、同时对架构是有一定要求的,架构是抽象的,但是设计模式是具体的,所以一定要加强下设计模式的学习
-
4、android的方向也很多,高级UI,移动架构师,数据结构与算法和音视频FFMpeg解码,如果你对其中一项比较感兴趣,就大胆的进阶吧!
希望大家多多点赞,转发,评论加关注,你们的支持就是我继续下去的动力!加油!
ndroid)**
[外链图片转存中…(img-6DRcnGTR-1712073908601)]
最后说一下我的学习路线
其实很简单就下面这张图,含概了Android所有需要学的知识点,一共8大板块:
- 架构师筑基必备技能
- Android框架体系架构(高级UI+FrameWork源码)
- 360°Androidapp全方位性能调优
- 设计思想解读开源框架
- NDK模块开发
- 移动架构师专题项目实战环节
- 移动架构师不可不学习微信小程序
- 混合开发的flutter
[外链图片转存中…(img-k7MmQpt1-1712073908601)]
Android学习的资料
我呢,把上面八大板块的分支都系统的做了一份学习系统的资料和视频,大概就下面这些,我就不全部写出来了,不然太长了影响大家的阅读。
330页PDF Android学习核心笔记(内含上面8大板块)
[外链图片转存中…(img-lt4w08Ds-1712073908602)]
Android学习的系统对应视频
总结
我希望通过我自己的学习方法来帮助大家去提升技术:
-
1、多看书、看源码和做项目,平时多种总结
-
2、不能停留在一些基本api的使用上,应该往更深层次的方向去研究,比如activity、view的内部运行机制,比如Android内存优化,比如aidl,比如JNI等,并不仅仅停留在会用,而要通过阅读源码,理解其实现原理
-
3、同时对架构是有一定要求的,架构是抽象的,但是设计模式是具体的,所以一定要加强下设计模式的学习
-
4、android的方向也很多,高级UI,移动架构师,数据结构与算法和音视频FFMpeg解码,如果你对其中一项比较感兴趣,就大胆的进阶吧!
希望大家多多点赞,转发,评论加关注,你们的支持就是我继续下去的动力!加油!