This in the Android
What types of Classloaders are available in Android? What are its functions and differences?
The Dalvik/ART virtual machine on Android needs to load the class file into memory just like the standard Java JVM, but the details of the ClassLoader are slightly different.
- BootClassLoader BootClassLoader is an internal class of ClassLoader that is used to preload common classes. Created in the Zygote process.
- PathClassLoader Is a direct subclass of ClassLoader. When an application starts, the PathClassLoader starts from data/app/… Directory to load APK files, his constructor also obviously follows the parent delegate mode, concrete implementation in the parent BaseDexClassLoader. Generally, only installed APK files are loaded
- DexClassLoader is also a subclass of BaseDexClassLoader. The difference between DexClassLoader and PathClassLoader is that it can load APK files on SD as well as installed APK files. This is also the basis of plug-in and hot repair, complete dex loading without the need to install APK
Describe the parent delegate model of a ClassLoader
When a Class loader receives a request to load a Class or resource, it will first determine whether it has loaded the requested Class or resource. If it has not loaded the request itself, it will entrust the parent Class to load the request. When the parent Class’s base Class has not loaded the request, the Class will find the path of the corresponding Class to load the bytecode, and then return, If not, the subclass is forwarded to find the path of the corresponding class, and so on until the source ClassLoader does not find the path either, and an error is reported
The steps are as follows
- The source ClassLoader first determines whether it has loaded the request Class. If so, it returns the request. Otherwise, it delegates to the parent ClassLoader
- The parent Class loader also determines whether it has loaded the Class. Like the source ClassLoader, if it has loaded the Class, it returns directly, and if it has not loaded the Class, it trusts the parent Class loader to continue this step
- If not, the Class bytecode is searched from the path of the request Class and the file is loaded. Success is returned directly to the ClassLoader, otherwise the subclass is passed on to continue the action.
- The source ClassLoader also searches for the Class bytecode through the path of the request Class for loading. If the loading succeeds, an error message is returned to the ClassLoader of the request Class; if the loading fails, an error message is reported. An exception is thrown
The application of the two-parent delegation model in the field of thermal repair is briefly introduced
Hot repair is implemented through the findClass method of BaseDexClassLoader Let the findClass method of DexPathList handle it. Inside DexPathList, it will traverse the DexFile and load the class through the DexFile’s dex.loadClassBinaryName. Therefore, we just need to put the patch file in the first place to let the class load complete Return, the old class will not be loaded. Because BaseDexClassLoader is the parent class and concrete implementation class of DexClassLoader, when the subclass does not load the request class, it will entrust the parent class to load, so it is closely related to our parent delegate mode.
Reference links Document links