從一個線上問題 重新認(rèn)識R8編譯器
背景
在過去的一段時間內(nèi)，京東Android APP通過圖片壓縮、圖片轉(zhuǎn)下載、資源混淆編譯、插件化、插件后裝、混合開發(fā)等一系列手段對安裝包大小進(jìn)行了優(yōu)化，取得了不錯的瘦身收益。在完成這些常規(guī)瘦身手段優(yōu)化后，為了進(jìn)一步優(yōu)化安裝包的大小，調(diào)研了谷歌官方新推出的 R8 編譯器，了解到R8編譯器在提升構(gòu)建效率的同時，又能優(yōu)化包體積大小，所以我們開始嘗試升級AGP版本來啟用R8編譯，升級的過程不是很順利，遇到了下面這些問題。
混淆工具介紹
對于Android應(yīng)用，為了提高應(yīng)用的安全性，常將代碼混淆作為手段之一。代碼混淆就是將源代碼轉(zhuǎn)換成功能上等價，但是難于閱讀和理解的形式，降低代碼的可讀性，即使被反編譯成功也很難得出代碼的真正含義，通過代碼混淆可以提升應(yīng)用被反編譯破解的難度。另一方面代碼混淆后，由于類、方法或者字段的名稱被映射成簡短無意義的名稱，也能減少應(yīng)用的包體積。
01ProGuard
在AGP3.4.0之前，Android打包流程中默認(rèn)使用ProGuard作為優(yōu)化工具，ProGuard對源代碼采用如下4個步驟進(jìn)行優(yōu)化，分別為壓縮（shrink）、優(yōu)化（optimize）、混淆（obfuscate）和預(yù)校驗（preveirfy）。
- 壓縮（shrink）：移除未被使用的類、方法、字段等；
- 優(yōu)化（optimize）：字節(jié)碼優(yōu)化、方法內(nèi)聯(lián)等操作；
- 混淆（obfuscate）：使用簡短無意義的名稱重命名類名、方法名、字段名等，增加反編譯難度；
- 預(yù)校驗（preverify）：對class進(jìn)行預(yù)校驗。
上面四個階段是可以獨立運行的，默認(rèn)都是開啟的，可以通過在混淆配置文件中設(shè)置-dontshrink、-dontoptimize、-dontobfuscate、-dontpreverify規(guī)則來關(guān)閉對應(yīng)的階段。ProGuard對.class文件進(jìn)行代碼壓縮優(yōu)化與混淆后會交給D8編譯器進(jìn)行脫糖，并將.class 文件轉(zhuǎn)換成.dex文件，執(zhí)行流程如下：
圖1 ProGuard與D8的優(yōu)化流程
02R8
AGP 3.3.0之后谷歌官方開始引入R8，是ProGuard的替代品，但是兼容ProGuard的keep規(guī)則。R8將代碼脫糖、壓縮、混淆、優(yōu)化和dex處理(D8)等優(yōu)化流程整合在一個步驟中完成，啟用R8編譯后，在實際的開發(fā)過程中工程的構(gòu)建效率要優(yōu)于ProGuard，其編譯流程如下。
圖2 R8 的優(yōu)化流程
- 搖樹優(yōu)化：從應(yīng)用及其庫依賴項中檢測并安全地移除未使用的類、字段、方法和屬性；
- 資源壓縮：從應(yīng)用中移除未使用的資源，包括應(yīng)用的庫依賴項中未使用的資源；
- 混淆：縮短類和成員的名稱；
- 優(yōu)化：優(yōu)化字節(jié)碼、簡化代碼等操作，以進(jìn)一步減小應(yīng)用 DEX 文件的大小。例如，如果 R8檢測到從未采用過給定 if/else 語句的 else {} 分支，R8 便會移除 else {} 分支的代碼。
在Android正式發(fā)布Release包時，我們通常如下設(shè)置來開啟優(yōu)化功能：
release {
// 開啟代碼收斂
minifyEnabled true
// 開啟資源壓縮
shrinkResources true
// 定義ProGuard混淆規(guī)則
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}踩坑經(jīng)驗
01R8 混淆規(guī)則
1.1 問題現(xiàn)象
首先我們來看下在AGP 3.3.3構(gòu)建工具打包混淆后生成的mapping.txt文件，觀察數(shù)據(jù)類混淆后的映射關(guān)系，其中OtherBean數(shù)據(jù)類在混淆配置文件中添加了排除混淆規(guī)則-keep class com.jd.obfuscate.bean.OtherBean{ *; }，而WatermelonBean數(shù)據(jù)類沒有添加keep規(guī)則，而且這兩個數(shù)據(jù)類擁有3個相同名稱的字段name、color、shape：
com.jd.obfuscate.bean.OtherBean -> com.jd.obfuscate.bean.OtherBean:
java.lang.String name -> name
java.lang.String color -> color
java.lang.String shape -> shape
java.lang.String otherPrice -> otherPrice
java.lang.String otherComment -> otherComment
java.lang.String otherProducer -> otherProducer
java.lang.String otherCategory -> otherCategory
int otherWeight -> otherWeight
int otherQuality -> otherQuality
int otherScore -> otherScore
com.jd.obfuscate.bean.WatermelonBean -> com.jd.obfuscate.bean.a:
java.lang.String name -> name
java.lang.String color -> color
java.lang.String shape -> shape
java.lang.String price -> aMR
java.lang.String comment -> aMS
java.lang.String producer -> aMT
java.lang.String cate -> aMU
int weightAttr -> aMV
int qualityAttr -> aMW
int scoreAttr -> aMX
仔細(xì)觀察這兩個數(shù)據(jù)類混淆后的類名和字段名，由于WatermelonBean數(shù)據(jù)類沒有添加keep規(guī)則，發(fā)現(xiàn)WatermelonBean數(shù)據(jù)類的類名和其余字段名都被混淆成無意義的名稱，而字段name、color、shape卻沒有被混淆。
接下來我們再來看下升級AGP 3.6.4后啟用R8編譯后，WatermelonBean數(shù)據(jù)類會被混淆成什么樣：
com.jd.obfuscate.bean.WatermelonBean -> b.b.a.a.a:
java.lang.String name -> a
java.lang.String color -> b
java.lang.String shape -> c
java.lang.String price -> d
java.lang.String comment -> e
java.lang.String producer -> f
java.lang.String cate -> g
int scoreAttr -> j
int weightAttr -> h
int qualityAttr -> i
在啟用R8編譯后，發(fā)現(xiàn)未添加keep規(guī)則的WatermelonBean數(shù)據(jù)類里的name、color、shape3個字段也都被混淆了。
在開發(fā)過程中與服務(wù)端交互時，使用Gson、FastJson等框架解析服務(wù)端數(shù)據(jù)時，會涉及到反序列化或反射相關(guān)，對應(yīng)的對象數(shù)據(jù)類不能被混淆，應(yīng)該添加相應(yīng)的keep規(guī)則，否則無法將json數(shù)據(jù)解析成正確的對象。所以如果你的項目工程在升級AGP后，在應(yīng)用上線前沒有檢查到所有的網(wǎng)絡(luò)解析數(shù)據(jù)類都添加了相應(yīng)的keep規(guī)則，那么業(yè)務(wù)功能就會出現(xiàn)問題。
1.2 原因分析
是什么原因?qū)е铝松厦娴默F(xiàn)象？
①當(dāng)你升級AGP啟用R8編譯時，如果仔細(xì)查看打包日志，你會發(fā)現(xiàn)關(guān)于"-useuniqueclassmembernames"混淆規(guī)則的警告提醒：
AGPBI: {"kind":"warning","text":"Ignoring option: -useuniqueclassmembernames",
"sources":[{"file":"xxx/proguard-project.txt","tool":"R8"}②熟悉ProGuard混淆規(guī)則的同學(xué)，針對上面的混淆現(xiàn)象應(yīng)該一眼就能看出是"-useuniqueclassmembernames"的混淆規(guī)則引起的，對該規(guī)則解釋是：為不同類中相同名稱的成員變量在混淆后生成全局唯一的混淆名。在沒有設(shè)置該規(guī)則時，不同類的方法或者字段都有可能被映射為a、b、c等無意義的名稱。
③將"-useuniqueclassmembernames"混淆規(guī)則移除后進(jìn)行驗證，我們看下WatermelonBean數(shù)據(jù)類混淆后mapping文件：
com.jd.obfuscate.bean.WatermelonBean -> com.jd.obfuscate.bean.a:
java.lang.String name -> a
java.lang.String color -> b
java.lang.String shape -> c
java.lang.String price -> d
java.lang.String comment -> e
java.lang.String producer -> f
java.lang.String cate -> g
int weightAttr -> h
int qualityAttr -> i
int scoreAttr -> j
發(fā)現(xiàn)WatermelonBean數(shù)據(jù)類中的字段name、color、shape都被混淆成了字母，證實是該混淆規(guī)則會導(dǎo)致類名被混淆而它的部分字段名未被混淆的現(xiàn)象。
Proguard 對字段名是如何進(jìn)行混淆的？
開發(fā)過自定義 Android Gradle 插件的開發(fā)者應(yīng)該對 Gradle Transform 抽象類比較熟悉，Gradle Transform是Android 官方提供給開發(fā)者在項目構(gòu)建階段class文件轉(zhuǎn)換為dex文件期間用來修改.class文件的一套標(biāo)準(zhǔn)API，通過這些API可以操作字節(jié)碼，實現(xiàn)通用的功能。
AGP源碼查看方式，在項目工程中添加依賴：
implementation 'com.android.tools.build:gradle:3.3.3'
定位源碼到com.android.build.gradle.internal.transforms.ProGuardTransform：
public void transform(final TransformInvocation invocation) {
final SettableFuture<TransformOutputProvider> resultFuture = SettableFuture.create();
Job job = new Job(this.getName(), new Task<Void>() {
public void run(Job<Void> job, JobContext<Void> context) throws IOException {
ProGuardTransform.this.doMinification(invocation.getInputs(),
invocation.getReferencedInputs(), invocation.getOutputProvider());
}
}, resultFuture);
SimpleWorkQueue.push(job);
job.awaitRethrowExceptions();
}創(chuàng)建ProGuard處理的異步任務(wù)添加到WorkQueue隊列中，執(zhí)行doMinification() -> runProguard() -> (new ProGuard(this.configuration)).execute();
// 核心方法，根據(jù)混淆規(guī)則配置執(zhí)行相應(yīng)的操作
public void execute() throws IOException {
System.out.println(VERSION);
// 檢查GPL許可協(xié)議
GPL.check();
if (configuration.printConfiguration != null) {
// 打印配置文件
printConfiguration();
}
// 檢查混淆規(guī)則配置是否正確
new ConfigurationChecker(configuration).check();
if (configuration.programJars != null &&
configuration.programJars.hasOutput() &&
new UpToDateChecker(configuration).check()) {
return;
}
if (configuration.targetClassVersion != 0) {
configuration.backport = true;
}
// 讀取所有class文件到類池中，programClassPool和libraryClassPool
readInput();
if (configuration.shrink || configuration.optimize ||
configuration.obfuscate || configuration.preverify) {
// 清除類中所有的JSE預(yù)驗證信息
clearPreverification();
}
if (configuration.printSeeds != null || configuration.shrink ||
configuration.optimize || configuration.obfuscate ||
configuration.preverify || configuration.backport) {
// 檢索類的依賴關(guān)系
initialize();
}
if (configuration.printSeeds != null)
// 將keep住的類輸出到seeds.txt文件中
printSeeds();
}
if (configuration.shrink) {
// 執(zhí)行壓縮優(yōu)化
shrink();
}
// 根據(jù)設(shè)置的優(yōu)化級別進(jìn)行代碼指令優(yōu)化：-optimizationpasses 5
if (configuration.optimize) {
for (int optimizationPass = 0;
optimizationPass < configuration.optimizationPasses;
optimizationPass++) {
if (!optimize(optimizationPass+1, configuration.optimizationPasses)) {
break;
}
// Shrink again, if we may.
if (configuration.shrink) {
// Don't print any usage this time around.
configuration.printUsage = null;
configuration.whyAreYouKeeping = null;
// 再次壓縮優(yōu)化
shrink();
}
}
// 在方法內(nèi)聯(lián)和類合并等優(yōu)化之后，消除所有程序類的行號
linearizeLineNumbers();
}
if (configuration.obfuscate) {
// 執(zhí)行混淆處理步驟
obfuscate();
}
if (configuration.preverify) {
// 預(yù)校驗
preverify();
}
......
}
上面就是ProGuard執(zhí)行的基本流程，我們著重看下obfuscate()混淆方法:
execute()方法執(zhí)行真正的混淆操作:
new Obfuscator(configuration).execute(programClassPool, libraryClassPool);
Obfuscator類是真正做混淆處理的類，包含類混淆ClassObfuscator，成員混淆MemberObfuscator。
在執(zhí)行的方法中，發(fā)現(xiàn)2處關(guān)于"-useuniqueclassmembernames"規(guī)則的處理邏輯：
// If the class member names have to correspond globally,
// link all class members in all classes, otherwise
// link all non-private methods in all class hierarchies.
ClassVisitor memberInfoLinker =
configuration.useUniqueClassMemberNames ?
(ClassVisitor)new AllMemberVisitor(new MethodLinker()) :
(ClassVisitor)new BottomClassFilter(new MethodLinker());
programClassPool.classesAccept(memberInfoLinker);
// Create a visitor for marking the seeds.
NameMarker nameMarker = new NameMarker();
ClassPoolVisitor classPoolvisitor =
new KeepClassSpecificationVisitorFactory(false, false, true)
.createClassPoolVisitor(configuration.keep,
nameMarker,
nameMarker,
nameMarker,
null);
// Mark the seeds.
programClassPool.accept(classPoolvisitor);
// Come up with new names for all class members.
NameFactory nameFactory = new SimpleNameFactory();
// Maintain a map of names to avoid [descriptor - new name - old name].
Map descriptorMap = new HashMap();
// Do the class member names have to be globally unique?
if (configuration.useUniqueClassMemberNames) {
// Collect all member names in all classes.
programClassPool.classesAccept(
new AllMemberVisitor(
new MemberNameCollector(configuration.overloadAggressively, descriptorMap)));
// Assign new names to all members in all classes.
programClassPool.classesAccept(new AllMemberVisitor(
new MemberObfuscator(configuration.overloadAggressively, nameFactory, descriptorMap)));
} else { ...... }
混淆分為六個步驟：
第一步：如果設(shè)置了"-useuniqueclassmembernames"混淆規(guī)則，首選通過ClassVisitor)new AllMemberVisitor(new MethodLinker())創(chuàng)建MethodLinker訪問者對象，將所有類中的字段信息轉(zhuǎn)為鏈表連接起來，以字段名稱和字段類型作為key，查詢memberMap中是否已經(jīng)存在該字段的visitorInfo信息，如果沒有查詢到就調(diào)用lastMember()方法嘗試獲取該字段在鏈表中的visitorInfo，并存入memberMap中；如果能查詢到，則將該字段信息作為visitorInfo加入到字段信息的鏈表中：
public void visitAnyMember(Clazz clazz, Member member) {
// 取得字段的名稱和描述符
String name = member.getName(clazz);
String descriptor = member.getDescriptor(clazz);
String key = name + ' ' + descriptor;
Member otherMember = (Member)memberMap.get(key);
if (otherMember == null) {
// Get the last method in the chain.
Member thisLastMember = lastMember(member);
// Store the new class method in the map.
memberMap.put(key, thisLastMember);
} else {
// Link both members.
link(member, otherMember);
}
}
public static Member lastMember(Member member) {
Member lastMember = member;
while (lastMember.getVisitorInfo() != null &&
lastMember.getVisitorInfo() instanceof Member) {
lastMember = (Member)lastMember.getVisitorInfo();
}
return lastMember;
}
private static void link(Member member1, Member member2) {
// Get the last methods in the both chains.
Member lastMember1 = lastMember(member1);
Member lastMember2 = lastMember(member2);
// Check if both link chains aren't already ending in the same element.
if (!lastMember1.equals(lastMember2)) {
// Merge the two chains, with the library members last.
if (lastMember2 instanceof LibraryMember) {
lastMember1.setVisitorInfo(lastMember2);
} else {
lastMember2.setVisitorInfo(lastMember1);
}
}
}第二步：將添加keep規(guī)則的類名、方法或字段名進(jìn)行標(biāo)記（NameMarker）而不被混淆。ProGuard源碼大量使用了訪問者模式，通過創(chuàng)建ClassVisitor的實現(xiàn)類nameMarker對象來訪問對象池，最終會執(zhí)行NameMarker類中的方法：
public void visitProgramClass(ProgramClass programClass) {
// 標(biāo)記keep規(guī)則中的類名
keepClassName(programClass);
// Make sure any outer class names are kept as well.
programClass.attributesAccept(this);
}
public void keepClassName(Clazz clazz) {
ClassObfuscator.setNewClassName(clazz, clazz.getName());
}
public void visitProgramField(ProgramClass programClass,
ProgramField programField) {
// 標(biāo)記keep規(guī)則中的字段名
keepFieldName(programClass, programField);
}
private void keepFieldName(Clazz clazz, Field field) {
MemberObfuscator.setFixedNewMemberName(field, field.getName(clazz));
}
// 給字段標(biāo)記固定的名稱
static void setFixedNewMemberName(Member member, String name) {
VisitorAccepter lastVisitorAccepter = MethodLinker.lastVisitorAccepter(member);
if (!(lastVisitorAccepter instanceof LibraryMember) &&
!(lastVisitorAccepter instanceof MyFixedName)) {
lastVisitorAccepter.setVisitorInfo(new MyFixedName(name));
} else {
lastVisitorAccepter.setVisitorInfo(name);
}
}
public void visitProgramMethod(ProgramClass programClass,
ProgramMethod programMethod) {
// 標(biāo)記keep規(guī)則中的方法名
keepMethodName(programClass, programMethod);
}
private void keepMethodName(Clazz clazz, Method method) {
String name = method.getName(clazz);
if (!ClassUtil.isInitializer(name)) {
MemberObfuscator.setFixedNewMemberName(method, name);
}標(biāo)記字段keep名稱做法比較簡單，只要通lastVisitorAccepter.setVisitorInfo(name)來設(shè)置。
第三步：收集所有類中的所有成員的映射關(guān)系（MemberNameCollector），先從字段鏈表中獲取上一步中標(biāo)記的keep名稱(visitorInfo)，并將相同類型的方法或字段放入同一個Map<混淆后名稱,原始名稱>中：
public void visitAnyMember(Clazz clazz, Member member) {
String name = member.getName(clazz);
// Get the member's new name.
// 在鏈表中獲取該成員的visitorInfo
String newName = MemberObfuscator.newMemberName(member);
// keep的名稱
if (newName != null) {
// Get the member's descriptor.
String descriptor = member.getDescriptor(clazz);
if (!allowAggressiveOverloading) {
descriptor = descriptor.substring(0, descriptor.indexOf(')')+1);
}
// Put the [descriptor - new name] in the map,
// creating a new [new name - old name] map if necessary.
Map nameMap = MemberObfuscator.retrieveNameMap(descriptorMap, descriptor);
String otherName = (String)nameMap.get(newName);
if (otherName == null ||
MemberObfuscator.hasFixedNewMemberName(member) ||
name.compareTo(otherName) < 0) {
// 把相同描述符的方法或字段放入同一個
// Map<混淆后名稱,原始名稱>中
nameMap.put(newName, name);
}
}第四步：創(chuàng)建混淆名稱混淆，如果在keep名稱鏈表中找不到映射關(guān)系，就創(chuàng)建新的混淆名稱（MemberObfuscator）：
public void visitAnyMember(Clazz clazz, Member member) {
String name = member.getName(clazz);
// Get the member's descriptor.
String descriptor = member.getDescriptor(clazz);
// Get the name map, creating a new one if necessary.
Map nameMap = retrieveNameMap(descriptorMap, descriptor);
// Get the member's new name.
// 1.如果前面已經(jīng)有keep的名稱，就不進(jìn)行混淆，
// 如果沒有就分配新的混淆名稱
String newName = newMemberName(member);
// Assign a new one, if necessary.
if (newName == null) {
// Find an acceptable new name.
nameFactory.reset();
do {
// 2.生成新的名稱
newName = nameFactory.nextName();
}
while (nameMap.containsKey(newName));
// Remember not to use the new name again
// in this name space.
nameMap.put(newName, name);
// Assign the new name.
// 3. 為這個成員設(shè)置新的名稱
setNewMemberName(member, newName);
}
}
static void setNewMemberName(Member member, String name) {
MethodLinker.lastVisitorAccepter(member).setVisitorInfo(name);
}NameFactory接口類主要負(fù)責(zé)生成新的混淆名稱，如果沒有設(shè)置自定義 obfuscationDictionary 字典的話，NameFactory接口的實現(xiàn)類SimpleNameFactory類，主要通過newName方法生成新的混淆名稱：
private static final int CHARACTER_COUNT = 26;
private String newName(int index) {
// If we're allowed to generate mixed-case names,
// we can use twice as
// many characters.
int totalCharacterCount = generateMixedCaseNames ?
2 * CHARACTER_COUNT : CHARACTER_COUNT;
int baseIndex = index / totalCharacterCount;
int offset = index % totalCharacterCount;
char newChar = charAt(offset);
String newName = baseIndex == 0 ?
new String(new char[] { newChar }) :
(name(baseIndex-1) + newChar);
return newName;
}
private char charAt(int index) {
return (char)((index < CHARACTER_COUNT ? 'a' -0 :
'A' - CHARACTER_COUNT) + index);
CHARACTER_COUNT被定義為26，正好是26個字母的意思，nextName()方法里通過index計數(shù)器，每次產(chǎn)生新名稱都往上自加，所以ProGuard的混淆名字是從a開始到z。
第五步：應(yīng)用混淆名稱，創(chuàng)建ClassRenamer訪問者對象，通過ConstantPoolEditor對象向常量池添加新的混淆名稱，并更新字段名稱的索引u2nameIndex指向新的混淆名稱。
// Actually apply the new names.
programClassPool.classesAccept(new ClassRenamer());
public void visitProgramMember(ProgramClass programClass,
ProgramMember programMember) {
// Has the class member name changed?
String name = programMember.getName(programClass);
String newName = MemberObfuscator.newMemberName(programMember);
if (newName != null && !newName.equals(name)) {
programMember.u2nameIndex = new ConstantPoolEditor(programClass).addUtf8Constant(newName);
}
第六步：常量池壓縮，新的混淆名稱是通過在常量池中新增數(shù)據(jù)，原先的數(shù)據(jù)并沒有被刪除，需要進(jìn)行修復(fù)，由于篇幅優(yōu)先不做詳細(xì)分析。
R8 編譯器為什么不支持該混淆規(guī)則？
從上面的現(xiàn)象上看，R8編譯器是忽略了"-useuniqueclassmembernames"的混淆規(guī)則，但是在谷歌Android開發(fā)文檔“縮減應(yīng)用大小”用戶指南里也沒有提到該規(guī)則的相關(guān)信息，接下來嘗試通過源碼層面查找該規(guī)則被忽略的原因。通過查找資料，在?提交記錄?。"-useuniqueclassmembernames"混淆的規(guī)則在ProGuard中主要用于增量?混淆?，但是引入R8編譯器的主要目標(biāo)是進(jìn)一步縮減應(yīng)用的大小，如果在R8中支持該規(guī)則只會增加代碼混淆的復(fù)雜性，并沒有帶來真正的好處。
R8 還有哪些混淆規(guī)則不支持？
查看ProguardConfigurationParser.java源碼(https://r8.googlesource.com/r8/+/3a100449ba5b490cd13d466b8c7e17dcd500722a/src/main/java/com/android/tools/r8/shaking/ProguardConfigurationParser.java)，以下混淆規(guī)則會被R8編譯器忽略：
-forceprocessing
-dontusemixedcaseclassnames
-dontpreverify
-experimentalshrinkunusedprotofields
-filterlibraryjarswithorginalprogramjars
-dontskipnonpubliclibraryclasses
-dontskipnonpubliclibraryclassmembers
-invokebasemethod
-mergeinterfacesaggressively
-android
-shrinkunusedprotofields
-allowruntypeandignoreoptimizationpasse
-addconfigurationdebugging
-assumenoescapingparameters
-assumenoexternalreturnvalues
-dump
-keepparameternames
-outjars
-target
-useuniqueclassmembernames
1.3 混淆小結(jié)
如果你的項目工程中同時滿足以下情況，就有可能在升級AGP的過程中，出現(xiàn)字段解析獲取不到對應(yīng)值的問題，導(dǎo)致業(yè)務(wù)功能異常：
- 添加了"-useuniqueclassmembernames"混淆規(guī)則；
- 有多個業(yè)務(wù)線不同的數(shù)據(jù)類又包含一些相同的字段；
- 不能保證所有的數(shù)據(jù)類在進(jìn)行網(wǎng)絡(luò)json數(shù)據(jù)解析時添加了keep規(guī)則；
- 打算升級AGP啟用R8編譯。
針對Android開發(fā)的混淆建議：
- 開發(fā)檢查數(shù)據(jù)類是否添加了keep規(guī)則的Gradle自定義插件，在工程打包調(diào)式階段通過錯誤日志提前提醒開發(fā)者是否有混淆風(fēng)險；
- 針對混淆形成最佳實踐來指導(dǎo)開發(fā)者正確使用混淆規(guī)則，例如將所有的數(shù)據(jù)類放在統(tǒng)一的包中，添加該包名的keep規(guī)則，或者涉及到反序列化或反射相關(guān)的，也可以添加@Keep注解。
02v1簽名邏輯
2.1 v1簽名丟失問題
京東APP調(diào)試包會讀取v1簽名的信息，在升級AGP 3.6.4 后運行調(diào)試包崩潰，排除原因發(fā)現(xiàn)是通過Android Studio run按鈕生成的調(diào)試包中的v1簽名丟失導(dǎo)致的。
我們通常會在工程app目錄的build.gradle文件進(jìn)行簽名相關(guān)設(shè)置：
signingConfigs {
release {
storeFile file('xxx')
storePassword 'xxx'
keyAlias 'xxx'
keyPassword 'xxx'
v1SigningEnabled true
v2SigningEnabled true
}
}
buildTypes {
debug {
minifyEnabled false
shrinkResources false
zipAlignEnabled true
signingConfig signingConfigs.release
}
release {
minifyEnabled true
shrinkResources true
zipAlignEnabled true
signingConfig signingConfigs.release
}
}2.2 原因分析
通過查閱AGP 3.6.4源碼發(fā)現(xiàn)在PackageAndroidArtifact類執(zhí)行doTask()靜態(tài)方法中會創(chuàng)建IncrementalPackagerBuilder會涉及到簽名相關(guān)，代碼如下：
public IncrementalPackagerBuilder withSigning(
@Nullable SigningConfigData signingConfig, int minSdk,
@Nullable Integer targetApi) {
boolean enableV1Signing =
enableV1Signing(
signingConfig.getV1SigningEnabled(),
signingConfig.getV2SigningEnabled(),
minSdk,
targetApi);
boolean enableV2Signing = (targetApi == null || targetApi >= NO_V1_SDK)
&& signingConfig.getV2SigningEnabled();
creationDataBuilder.setSigningOptions(
SigningOptions.builder()
.setKey(certificateInfo.getKey())
.setCertificates(certificateInfo.getCertificate())
.setV1SigningEnabled(enableV1Signing)
.setV2SigningEnabled(enableV2Signing)
.build());
} catch (KeytoolException|FileNotFoundException e) {
throw new RuntimeException(e);
}
return this;
}
private static int NO_V1_SDK = 24;
static boolean enableV1Signing(boolean v1Enabled, boolean v2Enabled,
int minSdk, @Nullable Integer targetApi) {
if (!v1Enabled) {
return false;
}
// If there is no v2 signature specified we have to sign with v1 even if the versions are
// high enough otherwise we would not have signed at all
if (!v2Enabled) {
return true;
}
// Case where both v1Enabled==true and v2Enabled==true
return (targetApi == null || targetApi < NO_V1_SDK) && minSdk < NO_V1_SDK;
從上面enableV1Signing()方法中可以看到，targetApi是指連接電腦的手機(jī)的系統(tǒng)版本，會根據(jù)當(dāng)前連接的測試機(jī)的系統(tǒng)版本是否小于Android7.0來判斷是否啟用v1簽名，如果手機(jī)系統(tǒng)大于Android7.0的話，v1簽名將會失效。
解決方案，將targetApi通過反射置為null，在build.gralde文件添加如下設(shè)置：
project.afterEvaluate {
project.android.getApplicationVariants().all { appVariant ->
String variantName = appVariant.name.capitalize()
Task packageTask = project.tasks.findByName("package${variantName}")
try {
if (packageTask.getTargetApi() != null) {
Field field = packageTask.getClass().getSuperclass().getSuperclass().getDeclaredField("targetApi")
field.setAccessible(true)
field.set(packageTask, null)
}
} catch (Exception e) {
e.printStackTrace()
}
}
}從源碼IncrementalPackagerBuilder.java提交的變更記錄來看，啟用v1/v2簽名的邏輯變化了多次。
03打包流程
3.1 現(xiàn)象
京東APP在打包過程中通過APT技術(shù)識別代碼中的注解，然后將注解信息生成json文件存放到工程assets目錄，隨后該json文件會被一起打包進(jìn)apk中，但是在升級 AGP 后，在進(jìn)行打包時該json文件丟失導(dǎo)致功能異常。排查原因發(fā)現(xiàn)是打包過程中的某些任務(wù)執(zhí)行順序發(fā)生了變化：
升級 AGP 前：
> Task :AndroidPhone:compileXXXJavaWithJavac
> Task :AndroidPhone:mergeXXXAssets
升級 AGP 后：
> Task :AndroidPhone:mergeXXXAssets
> Task :AndroidPhone:compileXXXJavaWithJavac
由于注解處理邏輯在 compileXXXJavaWithJavac 任務(wù)中，上述兩個任務(wù)在執(zhí)行順序發(fā)生變化后，會導(dǎo)致合并assets資源文件任務(wù)優(yōu)先于拷貝json文件到項目工程assets目錄，最終導(dǎo)致json文件在apk包中丟失。
3.2 解決方案
將兩任務(wù)設(shè)置先后依賴的關(guān)系，build.gradle中添加如下腳本：
project.afterEvaluate {
project.android.applicationVariants.all {
def variantName = it.name.capitalize()
Task compileJavaWithJavacTask = project.tasks.findByName("compile${variantName}JavaWithJavac")
Task mergeAssetsTask = project.tasks.findByName("merge${variantName}Assets")
mergeAssetsTask.dependsOn(compileJavaWithJavacTask)
}
}AGP升級建議
- 首先將升級AGP前后的apk產(chǎn)物進(jìn)行對比，檢查資源文件等是否有缺失；
- 制作腳本工具來對比升級前后生成的mapping.txt文件，檢查本該添加keep規(guī)則的類或字段是否有遺漏；
- 針對R8編譯器不支持的，影響全局的ProGuard混淆規(guī)則做好潛在風(fēng)險評估：例如混淆規(guī)則"-useuniqueclassmembernames"；
- 全面評估升級AGP的風(fēng)險，做好降級預(yù)案。
總結(jié)
本文主要介紹的是京東APP在升級Android構(gòu)建工具AGP 3.6.4過程中的踩坑記錄，升級完成后包體積減少了約1.5MB，希望上面的踩坑經(jīng)驗?zāi)軌驇椭酱蛩闵堿GP的讀者。
