Transform is a concept introduced in Android Gradle Plugin 1.5.

Let’s start with how to introduce the Transform dependency. First we need to write a custom plug-in, and then register a custom Transform in the plug-in. The Transform library is independent from gradle. Since version 2.0.0, the Transform library has been incorporated into the Gradle-API that the Android build system relies on. Let’s take a look at a current version of Transform on JCenter.

So, a long, long time ago I introduced transform dependencies like this

The compile 'com. Android. Tools. Build: transform - API: 1.5.0'Copy the code

Right now

/ / since 2.0.0 version is in the gradle - API implementation 'com. Android. View the build: gradle - API: 3.1.4'Copy the code

Next, let’s register a custom Transform in our custom plugin. The Gradle plugin can be written in Java, Groovy, or Kotlin. I chose Java here.

public class CustomPlugin implements Plugin<Project> { @SuppressWarnings("NullableProblems") @Override public void apply(Project project) { AppExtension appExtension = (AppExtension)project.getProperties().get("android"); appExtension.registerTransform(new CustomTransform(), Collections.EMPTY_LIST); }}Copy the code

So how do you write a custom Transform?

Each Transform is actually a Gradle Task. The TaskManager in the Android compiler concatenates each Transform. The first Transform receives the result from the Javac compilation. As well as third-party dependencies that have been pulled locally (jar.aar), and resource resources, note that the resource is not the RES resource in the Android project, but the asset directory. These compiled intermediates flow along a chain of transforms, and each Transform node can process the class and pass it on to the next Transform. Our common confusions, such as Desugar logic, are now implemented in a single Transform, and our custom Transform is inserted at the top of the Transform chain.

However, the above image is just one example of a Transform. A Transform can have two types of input: consumption, which the current Transform needs to output to the next Transform, and reference, which the current Transform can read without output to the next Transform. Instant Run, for example, checks diff between compilations in this way. Examples of how to declare both inputs in a Transform and how to handle both inputs follow.

In order to confirm the working principle and application of the Transform way, we can also from Android gradle plugin source of finding evidence, in TaskManager createPostCompilationTasks have a method. To avoid Posting too long source code, here is the link

TaskManager#createPostCompilationTasks

The context of this method is very clear, we can see Jacoco, Desugar, MergeJavaRes, AdvancedProfiling, Shrinker, Proguard, JarMergeTransform, MultiDex, and Dex are all connected in series in the form of Transform. It also inserts our custom Transform.

After talking about the principle of data flow of Transform, we will introduce the filtering mechanism of input data of Transform. The data input of Transform can be filtered through Scope and ContentType.

ContentType, as the name implies, is a data type. In plug-in development, we can only use CLASSES and RESOURCES. Note that CLASSES already contain class files and JAR files

As you can see from the figure, in addition to CLASSES and RESOURCES, there are other types that we can’t use during development, such as DEX files. These hidden types are in a separate enumerated class, ExtendedContentType, which is only available to the Android compiler. In addition, we generally use several common sets of contentTypes and scopes provided in TransformManager. If we want to process all the bytecodes of classes and jars, ContentType We normally use transformManager.content_class.

Scope is another dimension filter compared to ContentType,

As you can see, there are several types available on the left, and we use them in combination. TransformManager has several common Scope sets for developers to use. To handle all class bytecodes, Scope is normally transformmanager.scope_full_project.

So far, we have introduced the principle of the data flow of the Transform, the types of input, and the filtering mechanism. Let’s write a simple custom Transform to give us a more concrete understanding of the Transform

public class CustomTransform extends Transform { public static final String TAG = "CustomTransform"; public CustomTransform() { super(); } @Override public String getName() { return "CustomTransform"; } @Override public void transform(TransformInvocation transformInvocation) throws TransformException, InterruptedException, IOException { super.transform(transformInvocation); / / if the current is incremental compilation Boolean isIncremental = transformInvocation. IsIncremental (); // Consumer input, from which you can get the JAR package and the class folder path. Need to output to the next task Collection < TransformInput > inputs. = transformInvocation getInputs (); // Reference input, no output required. Collection<TransformInput> referencedInputs = transformInvocation.getReferencedInputs(); //OutputProvider manages the output path. If the consumption input is empty, You will find OutputProvider = = null TransformOutputProvider OutputProvider = transformInvocation. GetOutputProvider (); for(TransformInput input : inputs) { for(JarInput jarInput : input.getJarInputs()) { File dest = outputProvider.getContentLocation( jarInput.getFile().getAbsolutePath(), jarInput.getContentTypes(), jarInput.getScopes(), Format.JAR); Fileutils.copyfile (jarinput.getFile (), dest); fileutils.copyfile (jarinput.getfile ()); } for(DirectoryInput directoryInput : input.getDirectoryInputs()) { File dest = outputProvider.getContentLocation(directoryInput.getName(), directoryInput.getContentTypes(), directoryInput.getScopes(), Format.DIRECTORY); Fileutils.copydirectory (directoryInput.getFile(), dest); fileutils.copydirectory (directoryInput.getFile); } } } @Override public Set<QualifiedContent.ContentType> getInputTypes() { return TransformManager.CONTENT_CLASS; } @Override public Set<? super QualifiedContent.Scope> getScopes() { return TransformManager.SCOPE_FULL_PROJECT; } @Override public Set<QualifiedContent.ContentType> getOutputTypes() { return super.getOutputTypes(); } @Override public Set<? super QualifiedContent.Scope> getReferencedScopes() { return TransformManager.EMPTY_SCOPES; } @Override public Map<String, Object> getParameterInputs() { return super.getParameterInputs(); } @Override public boolean isCacheable() { return true; } @Override public boolean isIncremental() { return true; // Enable incremental compilation}}Copy the code

As you can see, in the transform method, we copy each jar package and class file to the dest path, which is the input data for the next transform. The bytecodes of jar packages and class files can be modified before copying. As for how to modify bytecodes, we will use ASM later. And if the development process depends on your current transform processing after class/jar package, can go to/build/intermediates/transforms/CustomTransform/view, you will find all the jar package name is 123456, This is normal, the naming rules can be OutputProvider. GetContentLocation found in specific implementation

public synchronized File getContentLocation( @NonNull String name, @NonNull Set<ContentType> types, @NonNull Set<? super Scope> scopes, @NonNull Format format) { // runtime check these since it's (indirectly) called by 3rd party transforms. checkNotNull(name); checkNotNull(types); checkNotNull(scopes); checkNotNull(format); checkState(! name.isEmpty()); checkState(! types.isEmpty()); checkState(! scopes.isEmpty()); // search for an existing matching substream. for (SubStream subStream : subStreams) { // look for an existing match. This means same name, types, scopes, and format. if (name.equals(subStream.getName()) && types.equals(subStream.getTypes()) && scopes.equals(subStream.getScopes()) && format == subStream.getFormat()) { return new File(rootFolder, subStream.getFilename()); }} // increment by position!! // didn't find a matching output. create the new output SubStream newSubStream = new SubStream(name, nextIndex++, scopes, types, format, true); subStreams.add(newSubStream); return new File(rootFolder, newSubStream.getFilename()); }Copy the code

• NOTCHANGED: The current file does not need to be processed, or even copied;
• ADDED, CHANGED: Normally processed, output to the next task.
• REMOVED: Removes the file obtained by the outputProvider.

Perhaps the implementation can take a look at the code below

@Override public void transform(TransformInvocation transformInvocation){ Collection<TransformInput> inputs = transformInvocation.getInputs(); TransformOutputProvider outputProvider = transformInvocation.getOutputProvider(); boolean isIncremental = transformInvocation.isIncremental(); // If it is not incremental, empty the old output if(! isIncremental) { outputProvider.deleteAll(); } for(TransformInput input : inputs) { for(JarInput jarInput : input.getJarInputs()) { Status status = jarInput.getStatus(); File dest = outputProvider.getContentLocation( jarInput.getName(), jarInput.getContentTypes(), jarInput.getScopes(), Format.JAR); if(isIncremental && ! emptyRun) { switch(status) { case NOTCHANGED: continue; case ADDED: case CHANGED: transformJar(jarInput.getFile(), dest, status); break; case REMOVED: if (dest.exists()) { FileUtils.forceDelete(dest); } break; } } else { transformJar(jarInput.getFile(), dest, status); } } for(DirectoryInput directoryInput : input.getDirectoryInputs()) { File dest = outputProvider.getContentLocation(directoryInput.getName(), directoryInput.getContentTypes(), directoryInput.getScopes(), Format.DIRECTORY); FileUtils.forceMkdir(dest); if(isIncremental && ! emptyRun) { String srcDirPath = directoryInput.getFile().getAbsolutePath(); String destDirPath = dest.getAbsolutePath(); Map<File, Status> fileStatusMap = directoryInput.getChangedFiles(); for (Map.Entry<File, Status> changedFile : fileStatusMap.entrySet()) { Status status = changedFile.getValue(); File inputFile = changedFile.getKey(); String destFilePath = inputFile.getAbsolutePath().replace(srcDirPath, destDirPath); File destFile = new File(destFilePath); switch (status) { case NOTCHANGED: break; case REMOVED: if(destFile.exists()) { FileUtils.forceDelete(destFile); } break; case ADDED: case CHANGED: FileUtils.touch(destFile); transformSingleFile(inputFile, destFile, srcDirPath); break; } } } else { transformDir(directoryInput.getFile(), dest); }}}}Copy the code

This provides incremental features for our compiled plug-in.

Once incremental compilation is implemented, it is best to support concurrent compilation as well. The implementation of concurrent compilation is not complicated, just need to process the logic for a single JAR /class, process it concurrently, and finally block until all tasks are finished.

private WaitableExecutor waitableExecutor = WaitableExecutor.useGlobalSharedThreadPool(); Class waitableExecutor.execute(() -> {bytecodeWeaver. WeaveJar (srcJar, destJar); return null; }); waitableExecutor.execute(() -> { bytecodeWeaver.weaveSingleClassToFile(file, outputFile, inputDirPath); return null; }); / / wait for all task end waitableExecutor. WaitForTasksWithQuickFail (true);Copy the code

Next, we make a comparison on compilation speed. Each experiment is compiled 10 times under the same conditions for 5 times, and the average time is taken after removing the maximum size value

First of all, in the QQ Mailbox Android client project, we will do a cleanbuild first

./gradlew clean assembleDebug --profileCopy the code

To add UI time statistics to the project, globally insert the first and last lines of each method (including ordinary class files and all classes in third-party JAR packages), using Transform+ASM. The time of Tranform step

As you can see, concurrent compilation is basically 80% faster than non-concurrent compilation. The effect is remarkable.

Then, in another experiment, we simulate a routine modification of a class file in a project that is compatible with incremental compilation. Then do the same piling logic on the basis of the previous, and compare the difference between the incremental Transform and the full Transform.

./gradlew assembleDebug --profileCopy the code

It can be seen that the incremental speed is more than 3 times faster than the full speed, and this speed optimization becomes more significant as the project gets larger.

The data shows that increments and concurrency have a significant impact on compilation speed. Some of them are written in Kotlin, some are written in Java, some support delta, some don’t. And the code comments write a large FIXME To support incremental build. So, to be fair, there is still room for improvement in Android compilation speed.

We’ve talked about Transform and how to efficiently process all the bytecodes at compile time, but what about bytecodes? Let’s take a look at the JVM platform bytecode processing magic tool, ASM!

On the JVM platform, the most common frameworks for processing bytecode are ASM, Javasist and AspectJ. I tried Javasist, and AspectJ knew a little bit about it, and chose ASM because it could process each command of bytecode at a lower level, with speed, memory footprint, and better than the other two frameworks.

We can make a comparison. Based on the above experiment of calculating compilation time, we do the following experiment. In the case that ASM and Javasist are respectively used to fully process all the classes of the project and concurrent processing is not enabled, the time comparison of transform in a clean build is as follows

ASM has significant advantages over Javasist, and the efficiency and performance advantages of ASM over other bytecode operation libraries should be beyond doubt. After all, it is a bytecode generation library authorized by many JVM languages.

We will introduce ASM in this part in the future, but due to space problems, not from the basis of bytecode introduction, will introduce some bytecode knowledge through the implementation of several examples, in addition, will introduce the use of ASM, as well as ASM parsing class file structure principle, as well as the application of Android plug-in development, encountered problems. And its solutions.

ASM designs two API types, one is Tree API, one is based on Visitor API(Visitor Pattern),

The Tree API reads the class structure into memory and builds a Tree structure. Then, when processing elements such as Method and Field, the Tree locates an element in the Tree structure, performs operations, and writes the operations to a new class file.

The Visitor API separates the logic that reads and writes classes by interface, typically through a ClassReader that reads the class bytecode, and then through a ClassVisitor interface that reads the class bytecode. Each detail of the bytecode is passed in order through the interface to the ClassVisitor (you’ll find multiple visitXXXX interfaces in the ClassVisitor), just as the ClassReader takes the ClassVisitor through each instruction of the class bytecode.

The above two kinds of parsing the file structure of the way in many dealing with structured data are common, general background to choose the appropriate scheme depends on demand, and our demand is such, for a certain purpose, looking for a hook point in the class files, to bytecode modification, this background, the way we choose the Visitor API is more appropriate.

Let’s write a simple demo that reads the contents of a class through the Visitor API and saves them to another file

private void copy(String inputPath, String outputPath) { try { FileInputStream is = new FileInputStream(inputPath); ClassReader cr = new ClassReader(is); ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES); cr.accept(cw, 0); FileOutputStream fos = new FileOutputStream(outputPath); fos.write(cw.toByteArray()); fos.close(); } catch (IOException e) { e.printStackTrace(); }}Copy the code

First, we read a class file with a ClassReader, and then we define a ClassWriter, which we can look at the source code for, which is basically a ClassVisitor implementation, Write ClassReader data to a byte stream, which is triggered by ClassWriter accept.

public void accept(ClassVisitor classVisitor, Attribute[] attributePrototypes, Int parsingOptions) {// Read bytecode information of the current class int accessFlags = this.readUnsignedShort(currentOffset); String thisClass = this.readClass(currentOffset + 2, charBuffer); String superClass = this.readClass(currentOffset + 4, charBuffer); String[] interfaces = new String[this.readUnsignedShort(currentOffset + 6)]; //classVisitor is the ClassWriter that was passed by the accept method. Visit (this.readint (this.cpInfooffsets [1] -7), accessFlags, thisClass, Signature, thisClass, thisClass, thisClass, thisClass superClass, interfaces); // /visit Attribute while(attributes! = null) { Attribute nextAttribute = attributes.nextAttribute; attributes.nextAttribute = null; classVisitor.visitAttribute(attributes); attributes = nextAttribute; } /** omit a lot of visit logic */ classvisit.visitend (); }Copy the code

Finally, we export the bytecode passed from ClassReader to ClassWriter via toByteArray() of ClassWriter and write it to a new file. This completes the copy of the class file. This demo, while very simple, covers ASM using the Visitor API to modify the lowest level of bytecode

If we want to modify bytecode, we should start from ClassWriter. As mentioned above, each visitXXX in ClassWriter (these interfaces are implemented from ClassVisitor) will save bytecode information and can be exported eventually. So if we can proxy the ClassWriter interface, we can interfere with the final bytecode generation.

So the diagram above should look something like this

We just have to look a little bit at the ClassVisitor code and see that its constructor can accept another ClassVisitor and delegate all the methods through that ClassVisitor. Let’s look at an example of inserting a line of code at the beginning and end of each method call statement in a class

The method before modification looks like this

private static void printTwo() {
    printOne();
    printOne();
}Copy the code

The modified method looks like this

private static void printTwo() {
    System.out.println("CALL printOne");
    printOne();
    System.out.println("RETURN printOne");
    System.out.println("CALL printOne");
    printOne();
    System.out.println("RETURN printOne");
}Copy the code

So let’s see how do we do that with ASM

private static void weave(String inputPath, String outputPath) { try { FileInputStream is = new FileInputStream(inputPath); ClassReader cr = new ClassReader(is); ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES); CallClassAdapter adapter = new CallClassAdapter(cw); cr.accept(adapter, 0); FileOutputStream fos = new FileOutputStream(outputPath); fos.write(cw.toByteArray()); fos.close(); } catch (IOException e) { e.printStackTrace(); }}Copy the code

The only difference between this code and the code that implements the copy class above is the use of a CallClassAdapter, which is a custom ClassVisitor that passes the ClassWriter to the constructor of the CallClassAdapter. Let’s look at the implementation

//CallClassAdapter.java public class CallClassAdapter extends ClassVisitor implements Opcodes { public CallClassAdapter(final ClassVisitor cv) { super(ASM5, cv); } @Override public void visit(int version, int access, String name, String signature, String superName, String[] interfaces) { super.visit(version, access, name, signature, superName, interfaces); } @Override public MethodVisitor visitMethod(final int access, final String name, final String desc, final String signature, final String[] exceptions) { MethodVisitor mv = cv.visitMethod(access, name, desc, signature, exceptions); return mv == null ? null : new CallMethodAdapter(name, mv); } } //CallMethodAdapter.java class CallMethodAdapter extends MethodVisitor implements Opcodes { public CallMethodAdapter(final MethodVisitor mv) { super(ASM5, mv); } @Override public void visitMethodInsn(int opcode, String owner, String name, String desc, boolean itf) { mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;" ); mv.visitLdcInsn("CALL " + name); mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;) V", false); mv.visitMethodInsn(opcode, owner, name, desc, itf); mv.visitFieldInsn(Opcodes.GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;" ); mv.visitLdcInsn("RETURN " + name); mv.visitMethodInsn(Opcodes.INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;) V", false); }}Copy the code

The visitMethod in the CallClassAdapter uses a custom MethodVisitor — the CallMethodAdapter, which also proxies for the original MethodVisitor, in the same way as the proxy for the ClassVisitor.

See here, using the modified ASM bytecode appeared to be about routines are covered, so how to write the above visitMethodInsn method to insert the logic of printing the method name, which requires some basic knowledge of the bytecode, we said that this will not introduce bytecode, but we can introduce some learn quickly bytecode way, It is also a useful tool for developing bytecode related projects.

Before we do that, let’s talk about line numbers

We can see that lines 17 and 18 each contain three lines of code.

This is before you turn on the option

So how do you turn this on? Mac CMD + Shift + A enter Registry and check both options

All code in class, whether it’s bytecode code or ASM code, is going to declare line number X, and then start several bytecode instructions, and those bytecode instructions are going to be in line number X until the next line number is declared.

If we apply ASM directly to the Android compiler, we will run into a pit from ClassWriter, because one of the logic in ClassWriter is to find the common parent of both classes. Look at the method getCommonSuperClass in ClassWriter,

/** * Returns the common super type of the two given types. The default * implementation of this method <i>loads</i> the  two given classes and uses * the java.lang.Class methods to find the common super class. It can be * overridden to compute this common super type in other ways, in particular * without actually loading any class, or to take into account the class * that is currently being generated by this ClassWriter, which can of * course not be loaded since it is under construction. * * @param type1 * the internal name of a class. * @param type2 * the internal name of another class. * @return the internal name of the common super class of the two given * classes. */ protected String getCommonSuperClass(final String type1, final String type2) { Class<? > c, d; ClassLoader classLoader = getClass().getClassLoader(); try { c = Class.forName(type1.replace('/', '.'), false, classLoader); d = Class.forName(type2.replace('/', '.'), false, classLoader); } catch (Exception e) { throw new RuntimeException(e.toString()); } if (c.isAssignableFrom(d)) { return type1; } if (d.isAssignableFrom(c)) { return type2; } if (c.isInterface() || d.isInterface()) { return "java/lang/Object"; } else { do { c = c.getSuperclass(); } while (! c.isAssignableFrom(d)); return c.getName().replace('.', '/'); }}Copy the code

This method is used to find the common parent of the two classes. We can see that it is the type that gets the current class and loads the two inputs. The classLoader used during compilation does not load the code in the Android project, so we need a custom classLoader. Add all the jars received in the Transform mentioned above, along with the class and android.jar, to the custom ClassLoader. (Some of the problems with this method are hinted at in the above method comments.)

The following

public static URLClassLoader getClassLoader(Collection<TransformInput> inputs,
                                            Collection<TransformInput> referencedInputs,
                                            Project project) throws MalformedURLException {
    ImmutableList.Builder<URL> urls = new ImmutableList.Builder<>();
    String androidJarPath  = getAndroidJarPath(project);
    File file = new File(androidJarPath);
    URL androidJarURL = file.toURI().toURL();
    urls.add(androidJarURL);
    for (TransformInput totalInputs : Iterables.concat(inputs, referencedInputs)) {
        for (DirectoryInput directoryInput : totalInputs.getDirectoryInputs()) {
            if (directoryInput.getFile().isDirectory()) {
                urls.add(directoryInput.getFile().toURI().toURL());
            }
        }
        for (JarInput jarInput : totalInputs.getJarInputs()) {
            if (jarInput.getFile().isFile()) {
                urls.add(jarInput.getFile().toURI().toURL());
            }
        }
    }
    ImmutableList<URL> allUrls = urls.build();
    URL[] classLoaderUrls = allUrls.toArray(new URL[allUrls.size()]);
    return new URLClassLoader(classLoaderUrls);
}Copy the code

However, if we just replace the Classloader in getCommonSuperClass, there is still a further hole. We can look at the implementation of getCommonSuperClass. It loads a Class via class.forname and then looks for its parent Class. However, classes in Android.jar cannot be loaded casually. Android.jar is a compile-time dependency for android projects. The runtime uses the Android machine’s own Android.jar. And all of the android.jar methods, including constructors, are empty implementations with only one line of code

throw new RuntimeException("Stub!" );Copy the code

When a class is loaded, its static field is fired, and if a static variable is initialized at declaration time and only a RuntimeException is initialized, an exception is thrown.

So, we can’t get the parent class this way, but can we get the parent class without loading the class? The parent class is also an item in the bytecode of a class, so we can query the parent class from the bytecode. The final implementation looks like this.

public class ExtendClassWriter extends ClassWriter { public static final String TAG = "ExtendClassWriter"; private static final String OBJECT = "java/lang/Object"; private ClassLoader urlClassLoader; public ExtendClassWriter(ClassLoader urlClassLoader, int flags) { super(flags); this.urlClassLoader = urlClassLoader; } @Override protected String getCommonSuperClass(final String type1, final String type2) { if (type1 == null || type1.equals(OBJECT) || type2 == null || type2.equals(OBJECT)) { return OBJECT; } if (type1.equals(type2)) { return type1; } ClassReader type1ClassReader = getClassReader(type1); ClassReader type2ClassReader = getClassReader(type2); if (type1ClassReader == null || type2ClassReader == null) { return OBJECT; } if (isInterface(type1ClassReader)) { String interfaceName = type1; if (isImplements(interfaceName, type2ClassReader)) { return interfaceName; } if (isInterface(type2ClassReader)) { interfaceName = type2; if (isImplements(interfaceName, type1ClassReader)) { return interfaceName; } } return OBJECT; } if (isInterface(type2ClassReader)) { String interfaceName = type2; if (isImplements(interfaceName, type1ClassReader)) { return interfaceName; } return OBJECT; } final Set<String> superClassNames = new HashSet<String>(); superClassNames.add(type1); superClassNames.add(type2); String type1SuperClassName = type1ClassReader.getSuperName(); if (! superClassNames.add(type1SuperClassName)) { return type1SuperClassName; } String type2SuperClassName = type2ClassReader.getSuperName(); if (! superClassNames.add(type2SuperClassName)) { return type2SuperClassName; } while (type1SuperClassName ! = null || type2SuperClassName ! = null) { if (type1SuperClassName ! = null) { type1SuperClassName = getSuperClassName(type1SuperClassName); if (type1SuperClassName ! = null) { if (! superClassNames.add(type1SuperClassName)) { return type1SuperClassName; } } } if (type2SuperClassName ! = null) { type2SuperClassName = getSuperClassName(type2SuperClassName); if (type2SuperClassName ! = null) { if (! superClassNames.add(type2SuperClassName)) { return type2SuperClassName; } } } } return OBJECT; } private boolean isImplements(final String interfaceName, final ClassReader classReader) { ClassReader classInfo = classReader; while (classInfo ! = null) { final String[] interfaceNames = classInfo.getInterfaces(); for (String name : interfaceNames) { if (name ! = null && name.equals(interfaceName)) { return true; } } for (String name : interfaceNames) { if(name ! = null) { final ClassReader interfaceInfo = getClassReader(name); if (interfaceInfo ! = null) { if (isImplements(interfaceName, interfaceInfo)) { return true; } } } } final String superClassName = classInfo.getSuperName(); if (superClassName == null || superClassName.equals(OBJECT)) { break; } classInfo = getClassReader(superClassName); } return false; } private boolean isInterface(final ClassReader classReader) { return (classReader.getAccess() & Opcodes.ACC_INTERFACE) ! = 0; } private String getSuperClassName(final String className) { final ClassReader classReader = getClassReader(className); if (classReader == null) { return null; } return classReader.getSuperName(); } private ClassReader getClassReader(final String className) { InputStream inputStream = urlClassLoader.getResourceAsStream(className + ".class"); try { if (inputStream ! = null) { return new ClassReader(inputStream); } } catch (IOException ignored) { } finally { if (inputStream ! = null) { try { inputStream.close(); } catch (IOException ignored) { } } } return null; }}Copy the code

So far, we introduce Transform+ASM, the two basic technologies of implementing bytecode modification on Android, introduce its principle and application, and analyze performance optimization and adaptation on Android platform. From there, I abstracted a wheel that would allow developers to write a section code plug-in with a small amount of ASM code and not care much about the details behind Transform and ASM. As shown in the

Github.com/Leaking/Hun…

All we need to do is write a plugin to play around with, so let’s take a look at some examples.

This article explains how to direct URLConnection requests to your own OkhttpClient.

At this point, I’ve covered the entire process of using the Hunter framework to develop a bytecode compilation plug-in that can do whatever it wants with third-party dependencies. If you are confused about the code, go to the project home page for the complete code, as well as the implementation of several other plug-ins. I’ll write another article about the implementation of the other plug-ins when I have time.

In-depth understanding of the Java virtual machine

ASM GUIDE

A good bytecode technology PPT