承接上一篇《组件间通信：接口下沉与事件取舍》，那一篇讲的是「模块间如何在编译期保持独立」，这一篇讲一个更激进的思路：能不能让模块在运行时才加载，甚至不重新编译就更新功能？这就是插件化与热修复的底层技术。结论先行：所有 Android 动态化方案都建立在两个能力之上——「ClassLoader 能被替换」和「关键对象的引用能被改写」。前者决定「代码能不能被换掉」，后者决定「换掉后系统还认不认」。理解了这两点，插件化的所有变体和它们的兼容性边界就都能推出来了。一、两个基础能力1.1 能力一：ClassLoader 加载顺序可干预Android 的类加载是双亲委派的应用：启动时PathClassLoader按顺序在dexList里找类。可干预的点是「把哪个 PathClassLoader 设成当前线程的上下文 ClassLoader」：// 系统视角：类加载发生在 zygote fork 出的应用进程里 // 应用启动时，ActivityThread 的 LoadedApk 会创建 PathClassLoader // 这个 ClassLoader 被存到 mBoundApplication.info.classLoader // 之后所有的类加载请求都走它 // 干预点 1：替换 LoadedApk 里的 classLoader val loadedApk = activityThread.mBound
承接上一篇《组件间通信：接口下沉与事件取舍》，那一篇讲的是「模块间如何在编译期保持独立」，这一篇讲一个更激进的思路：能不能让模块在运行时才加载，甚至不重新编译就更新功能？这就是插件化与热修复的底层技术。结论先行：所有 Android 动态化方案都建立在两个能力之上——「ClassLoader 能被替换」和「关键对象的引用能被改写」。前者决定「代码能不能被换掉」，后者决定「换掉后系统还认不认」。理解了这两点，插件化的所有变体和它们的兼容性边界就都能推出来了。一、两个基础能力1.1 能力一：ClassLoader 加载顺序可干预Android 的类加载是双亲委派的应用：启动时PathClassLoader按顺序在dexList里找类。可干预的点是「把哪个 PathClassLoader 设成当前线程的上下文 ClassLoader」：// 系统视角：类加载发生在 zygote fork 出的应用进程里 // 应用启动时，ActivityThread 的 LoadedApk 会创建 PathClassLoader // 这个 ClassLoader 被存到 mBoundApplication.info.classLoader // 之后所有的类加载请求都走它 // 干预点 1：替换 LoadedApk 里的 classLoader val loadedApk = activityThread.mBound
