目录一、认识插件化1.1 插件化起源1.2 插件化优点1.3 与组件化的区别二、插件化的技术难点 三、ClassLoader Injection3.1 java 中的 ClassLo
插件化技术最初源于免安装运行 Apk的想法,这个免安装的 Apk 就可以理解为插件,而支持插件的 app 我们一般叫 宿主。
想必大家都知道,在 Android
系统中,应用是以 Apk 的形式存在的,应用都需要安装才能使用。但实际上 Android 系统安装应用的方式相当简单,其实就是把应用 Apk 拷贝到系统不同的目录下、然后把 so 解压出来而已。
常见的应用安装目录有:
/system/app
:系统应用/system/priv-app
:系统应用/data/app
:用户应用那可能大家会想问,既然安装这个过程如此简单,Android
是怎么运行应用中的代码的呢,我们先看 Apk
的构成,一个常见的 Apk 会包含如下几个部分:
classes.dex
:Java 代码字节码res
:资源文件lib
:so 文件assets
:静态资产文件AndroidManifest.xml
:清单文件其实 Android
系统在打开应用之后,也只是开辟进程,然后使用 ClassLoader
加载 classes.dex
至进程中,执行对应的组件而已。
那大家可能会想一个问题,既然 Android
本身也是使用类似反射的形式加载代码执行,凭什么我们不能执行一个 Apk 中的代码呢?
插件化让 Apk
中的代码(主要是指 Android 组件)能够免安装运行,这样能够带来很多收益:
65535
的问题想象一下,你的应用拥有 Native 应用一般极高的性能,又能获取诸如 WEB 应用一样的收益。
嗯,理想很美好不是嘛?
App
分成多个模块,每个模块都是一个组件(module
),开发过程中可以让这些组件相互依赖或独立编译、调试部分组件,但是这些组件最终会合并成一个完整的Apk去发布到应用市场。想让插件的Apk真正运行起来,首先要先能找到插件Apk的存放位置,然后我们要能解析加载Apk里面的代码。
但是光能执行Java代码是没有意义的,在Android系统中有四大组件是需要在系统中注册的,具体来说是在 Android 系统的 ActivityManagerService
(AMS) 和 PackageManagerService
(PMS) 中注册的,而四大组件的解析和启动都需要依赖 AMS 和 PMS,如何欺骗系统,让他承认一个未安装的 Apk 中的组件,如何让宿主动态加载执行插件Apk中 Android 组件(即 Activity
、Service
、BroadcastReceiver
、ContentProvider
、Fragment
)等是插件化最大的难点。
另外,应用资源引用(特指 R 中引用的资源,如 layout、values 等)也是一大问题,想象一下你在宿主进程中使用反射加载了一个插件 Apk,代码中的 R 对应的 id 却无法引用到正确的资源,会产生什么后果。
总结一下,其实做到插件化的要点就这几个:
ClassLoader Injection
)Runtime Container
)Resource Injection
)当然还有其他一些小问题,但可能不是所有场景下都会遇到,我们后面再单独说。
ClassLoader
是插件化中必须要掌握的,因为我们知道Android
应用本身是基于魔改的 Java 虚拟机的,而由于插件是未安装的 apk,系统不会处理其中的类,所以需要使用 ClassLoader
加载 Apk,然后反射里面的代码。
BootstrapClassLoader
负责加载 JVM 运行时的核心类,比如 JAVA_HOME/lib/rt.jar 等等ExtensionClassLoader
负责加载 JVM 的扩展类,比如 JAVA_HOME/lib/ext 下面的 jar 包AppClassLoader
负责加载 classpath
里的 jar 包和目录在Android
系统中ClassLoader
是用来加载dex文件的,有包含 dex 的 apk 文件以及 jar 文件,dex 文件是一种对class文件优化的产物,在Android
中应用打包时会把所有class文件进行合并、优化(把不同的class文件重复的东西只保留一份),然后生成一个最终的class.dex
文件
PathClassLoader
用来加载系统类和应用程序类,可以加载已经安装的 apk 目录下的 dex 文件
public class PathClassLoader extends BaseDexClassLoader {
public PathClassLoader(String dexPath, ClassLoader parent) {
super(dexPath, null, null, parent);
}
public PathClassLoader(String dexPath, String libraryPath,
ClassLoader parent) {
super(dexPath, null, libraryPath, parent);
}
}
DexClassLoader
用来加载 dex 文件,可以从存储空间加载 dex 文件。
public class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory,
String libraryPath, ClassLoader parent) {
super(dexPath, new File(optimizedDirectory), libraryPath, parent);
}
}
我们在插件化中一般使用的是 DexClassLoader
。
每一个 ClassLoader
中都有一个 parent 对象,代表的是父类加载器,在加载一个类的时候,会先使用父类加载器去加载,如果在父类加载器中没有找到,自己再进行加载,如果 parent 为空,那么就用系统类加载器来加载。通过这样的机制可以保证系统类都是由系统类加载器加载的。 下面是 ClassLoader
的 loadClass
方法的具体实现。
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
// 先从父类加载器中进行加载
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// 没有找到,再自己加载
c = findClass(name);
}
}
return c;
}
要加载插件中的类,我们首先要创建一个 DexClassLoader
,先看下 DexClassLoader
的构造函数需要哪些参数。
public class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
// ...
}
}
构造函数需要四个参数: dexPath
是需要加载的 dex / apk / jar 文件路径 optimizedDirectory
是 dex 优化后存放的位置,在 ART 上,会执行 oat 对 dex 进行优化,生成机器码,这里就是存放优化后的 odex 文件的位置 librarySearchPath
是 native 依赖的位置 parent
就是父类加载器,默认会先从 parent
加载对应的类
创建出 DexClassLaoder
实例以后,只要调用其 loadClass(className)
方法就可以加载插件中的类了。具体的实现在下面:
// 从 assets 中拿出插件 apk 放到内部存储空间
private fun extractPlugin() {
var inputStream = assets.open("plugin.apk")
File(filesDir.absolutePath, "plugin.apk").writeBytes(inputStream.readBytes())
}
private fun init() {
extractPlugin()
pluginPath = File(filesDir.absolutePath, "plugin.apk").absolutePath
nativeLibDir = File(filesDir, "pluginlib").absolutePath
dexOutPath = File(filesDir, "dexout").absolutePath
// 生成 DexClassLoader 用来加载插件类
pluginClassLoader = DexClassLoader(pluginPath, dexOutPath, nativeLibDir, this::class.java.classLoader)
}
通过反射来执行类的方法
val loadClass = pluginClassLoader.loadClass(activityName)
loadClass.getMethod("test",null).invoke(loadClass)
我们称这个过程叫做 ClassLoader
注入。完成注入后,所有来自宿主的类使用宿主的 ClassLoader
进行加载,所有来自插件 Apk 的类使用插件 ClassLoader
进行加载,而由于 ClassLoader
的双亲委派机制,实际上系统类会不受 ClassLoader 的类隔离机制所影响,这样宿主 Apk 就可以在宿主进程中使用来自于插件的组件类了。
我们之前说到 Activity
插件化最大的难点是如何欺骗系统,让他承认一个未安装的 Apk 中的组件。 因为插件是动态加载的,所以插件的四大组件不可能注册到宿主的 Manifest
文件中,而没有在 Manifest 中注册的四大组件是不能和系统直接进行交互的。 如果直接把插件的 Activity 注册到宿主 Manifest
里就失去了插件化的动态特性,因为每次插件中新增 Activity
都要修改宿主 Manifest
并且重新打包,那就和直接写在宿主中没什么区别了。
这里的不能直接交互的含义有两个
Activity
是否注册 如果我们启动一个没有在 Manifest
中注册的 Activity,会发现报如下 error:
android.content.ActivityNotFoundException: Unable to find explicit activity class {com.zyg.commontec/com.zyg.plugin.PluginActivity}; have you declared this activity in your AndroidManifest.xml?
这个 log 在 Instrumentation
的 checkStartActivityResult
方法中可以看到:
public class Instrumentation {
public static void checkStartActivityResult(int res, Object intent) {
if (!ActivityManager.isStartResultFatalError(res)) {
return;
}
switch (res) {
case ActivityManager.START_INTENT_NOT_RESOLVED:
case ActivityManager.START_CLASS_NOT_FOUND:
if (intent instanceof Intent && ((Intent)intent).getComponent() != null)
throw new ActivityNotFoundException(
"Unable to find explicit activity class "
+ ((Intent)intent).getComponent().toShortString()
+ "; have you declared this activity in your AndroidManifest.xml?");
throw new ActivityNotFoundException(
"No Activity found to handle " + intent);
...
}
}
}
Manifest
注册文件,启动 Activity
被拒绝,那么其生命周期方法也肯定不会被调用了。从而插件 Activity 也就不能正常运行了。由于Android
中的组件(Activity
,Service
,BroadcastReceiver
和ContentProvider
)是由系统创建的,并且由系统管理生命周期。 仅仅构造出这些类的实例是没用的,还需要管理组件的生命周期。其中以Activity最为复杂,不同框架采用的方法也不尽相同。插件化如何支持组件生命周期的管理。 大致分为两种方式:
ProxyActivity
代理)StubActivity
,hook系统启动Activity的过程我们的解决方案很简单,即运行时容器技术,简单来说就是在宿主 Apk 中预埋一些空的 Android 组件,以 Activity 为例,我预置一个 ContainerActivity extends Activity
在宿主中,并且在 AndroidManifest
.xml 中注册它。
它要做的事情很简单,就是帮助我们作为插件 Activity 的容器,它从 Intent 接受几个参数,分别是插件的不同信息,如:
pluginName
pluginApkPath
pluginActivityName
等,其实最重要的就是 pluginApkPath
和 pluginActivityName
,当 ContainerActivity
启动时,我们就加载插件的 ClassLoader
、Resource
,并反射 pluginActivityName
对应的 Activity 类。当完成加载后,ContainerActivity
要做两件事:
Activity
Activity
方法的系统调用,并转发回系统我们可以通过复写 ContainerActivity
的生命周期方法来完成第一步,而第二步我们需要定义一个 PluginActivity
,然后在编写插件 Apk 中的 Activity 组件时,不再让其集成 android.app.Activity
,而是集成自我们的 PluginActivity
。
public class ContainerActivity extends Activity {
private PluginActivity pluginActivity;
@Override
protected void onCreate(Bundle savedInstanceState) {
String pluginActivityName = getIntent().getString("pluginActivityName", "");
pluginActivity = PluginLoader.loadActivity(pluginActivityName, this);
if (pluginActivity == null) {
super.onCreate(savedInstanceState);
return;
}
pluginActivity.onCreate();
}
@Override
protected void onResume() {
if (pluginActivity == null) {
super.onResume();
return;
}
pluginActivity.onResume();
}
@Override
protected void onPause() {
if (pluginActivity == null) {
super.onPause();
return;
}
pluginActivity.onPause();
}
// ...
}
public class PluginActivity {
private ContainerActivity containerActivity;
public PluginActivity(ContainerActivity containerActivity) {
this.containerActivity = containerActivity;
}
@Override
public <T extends View> T findViewById(int id) {
return containerActivity.findViewById(id);
}
// ...
}
// 插件 `Apk` 中真正写的组件
public class TestActivity extends PluginActivity {
// ......
}
是不是感觉有点看懂了,虽然真正搞的时候还有很多小坑,但大概原理就是这么简单,启动插件组件需要依赖容器,容器负责加载插件组件并且完成双向转发,转发来自系统的生命周期回调至插件组件,同时转发来自插件组件的系统调用至系统。
该方式虽然能够很好的实现启动插件Activity
的目的,但是由于开发式侵入性很强,插件中的Activity
必须继承PluginActivity
,如果想把之前的模块改造成插件需要很多额外的工作。
class TestActivity extends Activity {}
->
class TestActivity extends PluginActivity {}
有没有什么办法能让插件组件的编写与原来没有任何差别呢?
Shadow
的做法是字节码替换插件,这是一个非常棒的想法,简单来说,Android
提供了一些 Gradle 插件开发套件,其中有一项功能叫 TransfORM api
,它可以介入项目的构建过程,在字节码生成后、dex 文件生成前,对代码进行某些变换,具体怎么做的不说了,可以自己看文档。
实现的功能嘛,就是用户配置 Gradle 插件后,正常开发,依然编写:
class TestActivity extends Activity {}
然后完成编译后,最后的字节码中,显示的却是:
class TestActivity extends PluginActivity {}
到这里基本的框架就差不多结束了。
最后要说的是资源注入,其实这一点相当重要,Android
应用的开发其实崇尚的是逻辑与资源分离的理念,所有资源(layout
、values
等)都会被打包到 Apk 中,然后生成一个对应的 R 类,其中包含对所有资源的引用 id。
资源的注入并不容易,好在 Android
系统给我们留了一条后路,最重要的是这两个接口:
PackageManager#getPackageArcHiveInfo
:根据 Apk 路径解析一个未安装的 Apk 的 PackageInfo
PackageManager#getResourcesForApplication
:根据 ApplicationInfo
创建一个 Resources
实例
我们要做的就是在上面 ContainerActivity#onCreate
中加载插件 Apk 的时候,用这两个方法创建出来一份插件资源实例。具体来说就是先用 PackageManager#getPackageArchiveInfo
拿到插件 Apk 的 PackageInfo
,有了 PacakgeInfo 之后我们就可以自己组装一份 ApplicationInfo
,然后通过 PackageManager#getResourcesForApplication
来创建资源实例,大概代码像这样:
PackageManager packageManager = getPackageManager();
PackageInfo packageArchiveInfo = packageManager.getPackageArchiveInfo(
pluginApkPath,
PackageManager.GET_ACTIVITIES
| PackageManager.GET_META_DATA
| PackageManager.GET_SERVICES
| PackageManager.GET_PROVIDERS
| PackageManager.GET_SIGNATURES
);
packageArchiveInfo.applicationInfo.sourceDir = pluginApkPath;
packageArchiveInfo.applicationInfo.publicSourceDir = pluginApkPath;
Resources injectResources = null;
try {
injectResources = packageManager.getResourcesForApplication(packageArchiveInfo.applicationInfo);
} catch (PackageManager.NameNotFoundException e) {
// ...
}
拿到资源实例后,我们需要将宿主的资源和插件资源 Merge 一下,编写一个新的 Resources
类,用这样的方式完成自动代理:
public class PluginResources extends Resources {
private Resources hostResources;
private Resources injectResources;
public PluginResources(Resources hostResources, Resources injectResources) {
super(injectResources.getAssets(), injectResources.getDisplayMetrics(), injectResources.getConfiguration());
this.hostResources = hostResources;
this.injectResources = injectResources;
}
@Override
public String getString(int id, Object... formatArgs) throws NotFoundException {
try {
return injectResources.getString(id, formatArgs);
} catch (NotFoundException e) {
return hostResources.getString(id, formatArgs);
}
}
// ...
}
然后我们在 ContainerActivity
完成插件组件加载后,创建一份 Merge
资源,再复写 ContainerActivity#getResources
,将获取到的资源替换掉:
public class ContainerActivity extends Activity {
private Resources pluginResources;
@Override
protected void onCreate(Bundle savedInstanceState) {
// ...
pluginResources = new PluginResources(super.getResources(), PluginLoader.getResources(pluginApkPath));
// ...
}
@Override
public Resources getResources() {
if (pluginActivity == null) {
return super.getResources();
}
return pluginResources;
}
}
这样就完成了资源的注入。
到此这篇关于浅谈Android
插件化的文章就介绍到这了,更多相关Android
插件化内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网!
--结束END--
本文标题: 浅谈Android插件化
本文链接: https://lsjlt.com/news/136560.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-01-21
2023-10-28
2023-10-28
2023-10-27
2023-10-27
2023-10-27
2023-10-27
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0