使用 APT 开发组件化框架的若干细节问题
作者：互联网
好文推荐：
作者：shouheng
1、APT 开发组件化框架的细节问题
1.1 如何避免生成的类冲突
首先，当我们为使用了注解的 ISchedulerJob 生成 JobHunter 实现类的时候是将所有的实现类统一放到 me.shouheng.startup.hunter 这个包名下面（JobHunter 的实现类中使用反射的方式装载所有的 ISchedulerJob 实例）。那么问题来了，多个组件都往这个包下面生成类的时候如何避免类冲突。因为，虽然每个 module 打包成 aar 的时候，在当前的 aar 里，我们无需考虑类冲突问题，但是多个 aar 中如果在同一包下面存在同一个类名的类，那么其他的 aar 中的类会被覆盖掉（只有一个生效）。
解决上述问题的一个办法是在 gradle 文件里使用注解标明当前的 module name，然后生成类的时候使用 module name 作为后缀，依此来避免出现类冲突现象，
javaCompileOptions {
annotationProcessorOptions {
arguments = [STARTUP_MODULE_NAME: project.getName()]
}
}
1.2 如何动态加载 APK 同一包下面所有的类
按照上述配置方式，不同的 module 会向同一个包 me.shouheng.startup.hunter 下面生成不同的类。那么在启动应用的时候我们如何找到该包名下面的所有的生成类呢？这里我参考了 ARouter 的方案，即在启动的时候获取到当前启动的 APK，解析 APK 信息，遍历 dex，搜索指定包名下的类，核心代码如下，
抽取 APK，获取 dex 路径，
public static List<String> getSourcePaths(Context context) throws PackageManager.NameNotFoundException, IOException {
ApplicationInfo applicationInfo = context.getPackageManager().getApplicationInfo(context.getPackageName(), 0);
File sourceApk = new File(applicationInfo.sourceDir);
List<String> sourcePaths = new ArrayList<>();
sourcePaths.add(applicationInfo.sourceDir); //add the default apk path
//the prefix of extracted file, ie: test.classes
String extractedFilePrefix = sourceApk.getName() + EXTRACTED_NAME_EXT;
// 如果VM已经支持了MultiDex，就不要去Secondary Folder加载 Classesx.zip了，那里已经么有了
// 通过是否存在sp中的multidex.version是不准确的，因为从低版本升级上来的用户，是包含这个sp配置的
if (!isVMMultidexCapable()) {
//the total dex numbers
int totalDexNumber = getMultiDexPreferences(context).getInt(KEY_DEX_NUMBER, 1);
File dexDir = new File(applicationInfo.dataDir, SECONDARY_FOLDER_NAME);
for (int secondaryNumber = 2; secondaryNumber <= totalDexNumber; secondaryNumber++) {
//for each dex file, ie: test.classes2.zip, test.classes3.zip...
String fileName = extractedFilePrefix + secondaryNumber + EXTRACTED_SUFFIX;
File extractedFile = new File(dexDir, fileName);
if (extractedFile.isFile()) {
sourcePaths.add(extractedFile.getAbsolutePath());
//we ignore the verify zip part
} else {
throw new IOException("Missing extracted secondary dex file '" + extractedFile.getPath() + "'");
}
}
}
return sourcePaths;
}
读取 dex，获取报名下面所有的类，
public static Set<String> getFileNameByPackageName(
Context context, final String packageName, Executor executor
) throws PackageManager.NameNotFoundException, IOException, InterruptedException {
final Set<String> classNames = new HashSet<>();
List<String> paths = getSourcePaths(context);
final CountDownLatch parserCtl = new CountDownLatch(paths.size());
for (final String path : paths) {
executor.execute(new Runnable() {
@Override
public void run() {
DexFile dexfile = null;
try {
if (path.endsWith(EXTRACTED_SUFFIX)) {
//NOT use new DexFile(path), because it will throw "permission error in /data/dalvik-cache"
dexfile = DexFile.loadDex(path, path + ".tmp", 0);
} else {
dexfile = new DexFile(path);
}
// 遍历 dex 中所有的 class
Enumeration<String> dexEntries = dexfile.entries();
while (dexEntries.hasMoreElements()) {
String className = dexEntries.nextElement();
if (className.startsWith(packageName)) {
classNames.add(className);
}
}
} catch (Throwable ignore) {
Log.e("AndroidStartup", "Scan map file in dex files made error.", ignore);
} finally {
if (null != dexfile) {
try {
dexfile.close();
} catch (Throwable ignore) {
}
}
parserCtl.countDown();
}
}
});
}
parserCtl.await();
return classNames;
}
2、上述方案的问题和解决方案
2.1 解析 APK 加载类的一个问题
按照上述方案可以解决获取同一个包名下面的类的问题，但是这会导致其他问题。采用了上面的方案之后，当我启动 APP 的时候会有明显的停顿效果。虽然很短暂，但是可以肉眼感受到使用之前和之后的差距。
导致这个问题的原因是，上述动态解析和加载的过程是需要消耗一定的时间的，很显然包越大，解析的时间越长，停顿的时间也就越长。这显然是我们无法接受的。那么有没有其他的方案可以解决这个问题呢？我能想到的也就两种解决方案，
解决方案一：使用缓存，第一次解析之后后面再从缓存中加载；
解决方案二：插桩，根本解决问题，问题是插桩实现比较繁琐，影响编译；
2.2 解决方案一：使用 SharedPreferences 缓存
这里的思路是，通过解析 APK 读取到所有的类之后将其存储到 SharedPreferences. 不过这里根据是否处于 debug 模式以及 App 的版本信息进行存储。也就是说，对于 Release 版本，每次存储的类是跟 App 版本对应的，只有当 App 版本更新的时候才需要再次解析。那么，也就是说，按照 SharedPreferences 缓存的方案，第一次启动某一个版本的应用的时候需要解析，会有卡顿效果，后面会走缓存。
private fun gatherByPackageScan(context: Context): List<JobHunter> {
val hunters = mutableListOf<JobHunter>()
val hunterImplClasses: Set<String>
if (debuggable || PackageUtils.isNewVersion(context, logger)) {
// 读取包名下所有的类
hunterImplClasses = ClassUtils.getFileNameByPackageName(
context, "me.shouheng.startup.hunter", executor?:DefaultExecutor.INSTANCE)
if (hunterImplClasses.isNotEmpty()) {
// 存储类名到 SharedPreferences
context.getSharedPreferences(STARTUP_SP_CACHE_KEY, Context.MODE_PRIVATE)
.edit().putStringSet(STARTUP_SP_KEY_HUNTERS, hunterImplClasses).apply();
}
PackageUtils.updateVersion(context)
} else {
hunterImplClasses = HashSet(
context.getSharedPreferences(STARTUP_SP_CACHE_KEY, Context.MODE_PRIVATE)
.getStringSet(STARTUP_SP_KEY_HUNTERS, setOf())
)
}
hunterImplClasses.forEach {
val hunterImplClass = Class.forName(it)
hunters.add(hunterImplClass.newInstance() as JobHunter)
}
return hunters
}
2.3 解决方案二：通过 ASM 插桩，动态扫描
插桩的思路应该还是比较清晰的，因为在 Gradle 编译的 tarnsform 阶段可以动态地对 class 进行扫描，所以，我们可以很容易地实现发现指定包名之下所有的类的目标。找到这些类之后，只需要再通过插桩的方式将其写入到指定的 class 里，然后再根据标志位走插桩对应的方法而不是上述解析 APK 的方式即可。
1. 插桩思路
这里的实现思路是，调用 scanAnnotations()方法的时候首先会走 gatherHunters() 的逻辑，这里有一个标志位 registerByPlugin. 我们插桩的逻辑是在 gatherHunters() 方法中插入 addHunter() 的代码。addHunter() 方法中会根据传入的类名进行反射，获取 JobHunter 所有实现类的实例。
/** Scan annotations for job by [ISchedulerJob]. */
fun scanAnnotations(context: Context) {
try {
if (jobHunters == null) {
gatherHunters()
if (registerByPlugin) {
logger?.i("Gathered hunters by startup-register plugin.");
} else {
jobHunters = gatherByPackageScan(context)
}
}
jobHunters?.forEach { jobHunter ->
val jobs = jobHunter.hunt()
jobs?.let {
this.jobs.addAll(it)
}
}
} catch (e: Exception) {
e.printStackTrace()
}
}
private fun gatherHunters() {
registerByPlugin = false
jobHunters = mutableListOf()
// addHunter()
}
private fun addHunter(className: String) {
registerByPlugin = true
if (!TextUtils.isEmpty(className)) {
try {
val clazz = Class.forName(className)
val obj = clazz.getConstructor().newInstance()
if (obj is JobHunter) {
(jobHunters as? MutableList)?.add(obj)
} else {
logger?.i("Register failed, class name: $className should implements one " +
"of me/shouheng/startup/JobHunter.")
}
} catch (e: java.lang.Exception) {
logger?.e("Register class error: $className", e)
}
}
}
2. 插桩实现
首先，定义一个插件并注册 transform，
class RegisterPlugin : Plugin<Project> {
override fun apply(project: Project) {
val hasApp = project.plugins.hasPlugin(AppPlugin::class.java)
if (hasApp) {
Logger.make(project)
Logger.i("Project enable startup-register plugin")
val android = project.extensions.getByType(AppExtension::class.java)
val transform = RegisterTransform(project)
android.registerTransform(transform)
}
}
}
然后，在自定义的 transform 中扫描本地目录和 aar，
class RegisterTransform(private val project: Project): Transform() {
// ...
override fun transform(
context: Context?,
inputs: MutableCollection<TransformInput>?,
referencedInputs: MutableCollection<TransformInput>?,
outputProvider: TransformOutputProvider?,
isIncremental: Boolean
) {
Logger.i("Start scan register info in jar file.")
val startTime = System.currentTimeMillis()
if (!isIncremental) outputProvider?.deleteAll()
inputs?.forEach { input ->
scanJarInputs(input.jarInputs, outputProvider)
scanDirectoryInputs(input.directoryInputs, outputProvider)
}
Logger.i("Scan finish, current cost time " + (System.currentTimeMillis() - startTime) + "ms")
insertImplClasses()
Logger.i("Generate code finish, current cost time: " + (System.currentTimeMillis() - startTime) + "ms")
}
}
并使用自定义的 ClassVisitor 获取所有 JobHunter 实现，
class ScanClassVisitor(api: Int, cv: ClassVisitor): ClassVisitor(api, cv) {
override fun visit(version: Int, access: Int, name: String?,
signature: String?, superName: String?, interfaces: Array<String>?) {
super.visit(version, access, name, signature, superName, interfaces)
interfaces?.any { it == JON_HUNTER_FULL_PATH }?.let {
if (it && name != null && !hunterImplClasses.contains(name)) {
hunterImplClasses.add(name)
}
}
}
}
读取到所有的类之后再使用自定义的 MethodVisitor 实现上述方法插入和调用，
class GeneratorMethodVisitor(
api: Int,
mv: MethodVisitor,
private val classes: List<String>
): MethodVisitor(api, mv) {
override fun visitInsn(opcode: Int) {
if ((opcode >= Opcodes.IRETURN && opcode <= Opcodes.RETURN)) {
classes.forEach {
val name = it.replace("/", ".")
mv.visitVarInsn(Opcodes.ALOAD, 0)
mv.visitLdcInsn(name) // Class name
// generate invoke register method into AndroidStartupBuilder.gatherHunters()
mv.visitMethodInsn(Opcodes.INVOKESPECIAL, GENERATE_TO_CLASS_NAME,
ADD_HUNTER_METHOD_NAME, "(Ljava/lang/String;)V", false)
}
}
super.visitInsn(opcode)
}
override fun visitMaxs(maxStack: Int, maxLocals: Int) {
super.visitMaxs(maxStack+4, maxLocals)
}
}
上面就完成了插桩的代码。在使用的时候只需要添加上我们的自定义插件即可实现组建中自定义扫描。
3. ASM 插桩问题排查方法
插桩之后的代码 R8 编译报错的问题：因编译期间问题，插桩完毕之后，R8 再执行插桩后代码的时候报错，这里只给出报错的 class，但是无法确定真正错误的代码的位置。
Caused by: com.android.tools.r8.CompilationFailedException: Compilation failed to complete, position: Lme/shouheng/startup/AndroidStartupBuilder;gatherHunters()V, origin: /Users/wangshouheng/Desktop/repo/github/AndroidStartup/sample/app/build/intermediates/transforms/StartupRegister/debug/83.jar:me/shouheng/startup/AndroidStartupBuilder.class
... 36 more
Suppressed: java.lang.RuntimeException: java.util.concurrent.ExecutionException: com.android.tools.r8.utils.Z: java.lang.ArrayIndexOutOfBoundsException: -1
at com.android.tools.r8.D8.d(D8.java:143)
... 38 more
Caused by: java.util.concurrent.ExecutionException: com.android.tools.r8.utils.Z: java.lang.ArrayIndexOutOfBoundsException: -1
at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:552)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:513)
at com.google.common.util.concurrent.FluentFuture$TrustedFuture.get(FluentFuture.java:86)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at com.android.tools.r8.utils.a1.a(SourceFile:11)
at com.android.tools.r8.utils.a1.a(SourceFile:40)
at com.android.tools.r8.utils.a1.a(SourceFile:38)
at com.android.tools.r8.utils.a1.a(SourceFile:37)
at com.android.tools.r8.ir.conversion.O.a(SourceFile:339)
at com.android.tools.r8.D8.d(D8.java:36)
... 38 more
此时，可以采用下面两种解决方案，
方案一：使用 JD-GUI 打开报错的 jar，因为 class 解析错误，所以无法获得完整的堆栈。方案不行！
方案二：解压 jar，反编译 class 文件，指令 javap -c -p AndroidStartupBuilder.class 这里的 -c 要求输出反编译结果的参数，-p 是反编译内容包含 private 的字段和方法的参数。按照上述指令可以输出反编译结果。我们可以通过阅读反编译结果来发现错误的真实的位置。方案可行！
ASM 插件无法阅读 Kotlin 字节码或者 Kotlin 字节码编译失败问题：Kotlin 代码可以使用 AS 自带工具 Tools->Kotlin->Show kotlin Byte Code 查看 Kotlin 文件的字节码。对于简单的 ASM 插桩代码，还可以直接使用查看 Kotlin 字节码的形式，然后手动翻译成 ASM 的代码。
3、总结
使用 APT 实现注解扫描，如果不是组件化的应用场景，并不需要实现上述缓存和插桩的逻辑，比如 ButterKnife，只需要调用一下对应的方法，完成 APT 相关代码的自动装载即可。但是如果是组件化场景，为了实现指定包名下面的类的扫描，走插桩和缓存似乎是必经之路。不过准确来说，我们是不需要插桩的，只需要 transform 阶段能够扫描到类，存储下来，然后应用启动的时候动态加载即可。所以，除了插桩之外，我们还有没有其他的可选的办法呢？当然有，比如读取到类之后写入到 json 文件里面，然后启动的时候读取 json 文件并解析出生成的类。不过，这种方式性能上会比插桩稍逊一筹。
标签：java,val,框架,APT,class,context,组件,com,插桩 来源： https://blog.csdn.net/u012165769/article/details/121163090