Jetpack Compose也能搞插件化了

/   前言   /
在传统的 Android 开发模式中,由于界面过分依赖于 Activity、Fragment这样的组件,一个业务模块中往往会存在着大量的 Activity 类,因此诞生了很多的插件化框架,这些插件化框架基本都是想方设法的使用各种Hook/反射手段来解决使用未注册的组件问题。在进入 Jetpack Compose 的世界以后,Activity 的角色被淡化了,由于一个 Composable 组件就可以承担一个屏幕级的显示,因此我们的应用中不再需要那么多的 Activity 类,只要你喜欢,你甚至可以打造一个单 Activity 的纯 Compose 应用。
 
本文主要尝试探索几种可以在 Jetpack Compose 中实施插件化/动态加载的可行性方案。
/   Activity占坑方式访问插件中的Composable组件   /
这种方式其实传统 View 开发也可以做,但是由于 Compose 中我们可以只使用一个Activity,而其余页面均使用 Composable 组件来实现,感觉更加适合它。因此主要的思路就是在宿主应用的 AndroidManifest.xml 中注册一个占坑的 Activity类,该 Activity实际存在于插件中,然后在宿主中加载插件中该 Activity的Class,启动插件中的该Activity并传递不同的参数,以显示不同的 Composable 组件。说白了就是借助一个空壳 Activity 来做跳板去展示不同的 Composable 。
 
首先在工程中新建一个 module 模块,将 build.gradle 中的 ‘com.android.library’ plugins配置改为 ‘com.android.application’,因为这个模块是当成一个 application 模块开发的,最终以 apk 的形式提供插件。然后在其中新建一个 PluginActivity 作为跳板 Activity,并新建两个测试的 Composable 页面。
 
PluginActivity 的内容如下:
 
class PluginActivityComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val type = intent.getStringExtra(“type”) ?: “NewsList”
setContent {
MaterialTheme {
if (type == “NewsList”) {
NewsList()
else if (type == “NewsDetail”) {
NewsDetail()
}
}
}
}
}
这里就是简单的根据 intent 读取的 type 类型来判断,如果是 NewsList 就显示一个新闻列表的 Composable 页面, 如果是 NewsDetail 就显示一个新闻详情的 Composable 页面。
 
NewsList 内容如下:
@Composable
fun NewsList() {
LazyColumn(
Modifier.fillMaxSize().background(Color.Gray),
contentPadding = PaddingValues(15.dp),
verticalArrangement = Arrangement.spacedBy(10.dp)
) {
items(50) { index ->
NewsItem(“我是第 $index 条新闻”)
}
}
}

@Composable
private fun NewsItem(
text : String,
modifier: Modifier = Modifier,
bgColor: Color = Color.White,
fontColor: Color = Color.Black,
)
 {
Card(
elevation = 8.dp,
modifier = modifier.fillMaxWidth(),
backgroundColor = bgColor
) {
Box(
Modifier.fillMaxWidth().padding(15.dp),
contentAlignment = Alignment.Center
) {
Text(text = text, fontSize = 20.sp, color = fontColor)
}
}
}

NewsDetail 内容如下:
 
@Composable
fun NewsDetail() {
Column {
Text(text = “我是插件中的新闻详情页面”.repeat(100))
}
}
执行 assembleDebug,将生成的 apk 文件拷贝到宿主 app 模块的 assets 目录下,以便在应用启动后从其中拷贝到存储卡(实际项目中应当从服务器下载)。
 
然后在宿主app模块的 AndroidManifest.xml 中注册插件中定义的 PluginActivity 进行占坑,这里爆红也没有关系,不会影响打包。
 
然后在app模块中定义一个 PluginManager 类,主要负责加载插件中的 Class:
 
import android.annotation.SuppressLint
import android.content.Context
import dalvik.system.DexClassLoader
import java.io.File
import java.lang.reflect.Array.newInstance
import java.lang.reflect.Field

class PluginManager private constructor() {

companion object {

var pluginClassLoader : DexClassLoader? = null

fun loadPlugin(context: Context) {
val inputStream = context.assets.open(“news_lib.apk”)
val filesDir = context.externalCacheDir
val apkFile = File(filesDir?.absolutePath, “news_lib.apk”)
apkFile.writeBytes(inputStream.readBytes())

val dexFile = File(filesDir, “dex”)
if (!dexFile.exists()) dexFile.mkdirs()
println(“输出dex路径: $dexFile)
pluginClassLoader = DexClassLoader(apkFile.absolutePath, dexFile.absolutePath, nullthis.javaClass.classLoader)
}

fun loadClass(className: String): Class<*>? {
try {
if (pluginClassLoader == null) {
println(“pluginClassLoader is null”)
}
return pluginClassLoader?.loadClass(className)
catch (e: ClassNotFoundException) {
println(“loadClass ClassNotFoundException: $className)
}
return null
}

/**
* 合并DexElement数组: 宿主新dexElements = 宿主原始dexElements + 插件dexElements
* 1、创建插件的 DexClassLoader 类加载器,然后通过反射获取插件的 dexElements 值。
* 2、获取宿主的 PathClassLoader 类加载器,然后通过反射获取宿主的 dexElements 值。
* 3、合并宿主的 dexElements 与 插件的 dexElements,生成新的 Element[]。
* 4、最后通过反射将新的 Element[] 赋值给宿主的 dexElements。
*/

@SuppressLint(“DiscouragedPrivateApi”)
fun mergeDexElement(context: Context) : Boolean{
try {
val clazz = Class.forName(“dalvik.system.BaseDexClassLoader”)
val pathListField: Field = clazz.getDeclaredField(“pathList”)
pathListField.isAccessible = true

val dexPathListClass = Class.forName(“dalvik.system.DexPathList”)
val dexElementsField = dexPathListClass.getDeclaredField(“dexElements”)
dexElementsField.isAccessible = true

// 宿主的 类加载器
val pathClassLoader: ClassLoader = context.classLoader
// DexPathList类的对象
val hostPathListObj = pathListField[pathClassLoader]
// 宿主的 dexElements
val hostDexElements = dexElementsField[hostPathListObj] as Array<*>

// 插件的 类加载器
val dexClassLoader = pluginClassLoader ?: return false
// DexPathList类的对象
val pluginPathListObj = pathListField[dexClassLoader]
// 插件的 dexElements
val pluginDexElements = dexElementsField[pluginPathListObj] as Array<*>

val hostDexSize = hostDexElements.size
val pluginDexSize = pluginDexElements.size
// 宿主dexElements = 宿主dexElements + 插件dexElements
// 创建一个新数组
val newDexElements = hostDexElements.javaClass.componentType?.let {
newInstance(it, hostDexSize + pluginDexSize)
as Array<*>
System.arraycopy(hostDexElements, 0, newDexElements, 0, hostDexSize)
System.arraycopy(pluginDexElements, 0, newDexElements, hostDexSize, pluginDexSize)

// 赋值 hostDexElements = newDexElements
dexElementsField[hostPathListObj] = newDexElements

return true
catch (e: Exception) {
println(“mergeDexElement: $e)
}
return false
}
}
}

这里的原理就不多介绍了,网上相关的文章已经有很多了,如有不了解的可以自行搜索。这里我使用的代码基本上也是从其他地方搬过来参考的。上面 PluginManager 类中定义了三个方法:loadPlugin() 方法负责将 assets 中的 apk 拷贝到外置存储卡中应用的缓存目录,并定义一个用于加载插件中的 Class 的 DexClassLoader ;loadClass() 方法就是使用该ClassLoader根据指定的className进行加载并返回 Class的;mergeDexElement() 方法则是将插件中的dexElements数组合并到宿主的dexElements数组中,以便加载的插件Class能被宿主应用识别。
 
接下来定义一个 PluginViewModel ,分别针对上面 PluginManager 中的三个方法进行调用处理,并向 Composable 公开相应的状态:
 
class PluginViewModelViewModel() {

private val _isPluginLoadSuccess = MutableStateFlow(false)
val isPluginLoadSuccess = _isPluginLoadSuccess.asStateFlow()

private val _isMergeDexSuccess = MutableStateFlow(false)
val isMergeDexSuccess = _isMergeDexSuccess.asStateFlow()

var pluginActivityClass by mutableStateOf?>(null)
private set

fun loadPlugin(context: Context) {
viewModelScope.launch {
withContext(Dispatchers.IO) {
PluginManager.loadPlugin(context)
if (PluginManager.pluginClassLoader != null) {
_isPluginLoadSuccess.value = true
}
}
}
}

fun mergeDex(context: Context) {
viewModelScope.launch {
withContext(Dispatchers.IO) {
if (PluginManager.mergeDexElement(context)) {
_isMergeDexSuccess.value = true
}
}
}
}

fun loadClass(name: String) {
viewModelScope.launch {
withContext(Dispatchers.IO) {
pluginActivityClass = PluginManager.loadClass(name)
}
}
}
}

最后就是一个用于的测试页面,定义一个 HostScreen 作为宿主中的页面进行展示:
 
const val PluginActivityClassName = “com.fly.compose.plugin.news.PluginActivity”

@OptIn(ExperimentalLifecycleComposeApi::class)
@Composable
fun HostScreen(viewModel: PluginViewModel = viewModel()) {
val context = LocalContext.current
Column(
horizontalAlignment = Alignment.CenterHorizontally,
verticalArrangement = Arrangement.spacedBy(20.dp)
) {
Text(text = “当前是宿主中的Composable页面”)
Button(onClick = { viewModel.loadPlugin(context) }) {
Text(text = “点击加载插件Classloader”)
}
val isLoadSuccess = viewModel.isPluginLoadSuccess.collectAsStateWithLifecycle()
Text(text = “插件Classloader是否加载成功:${isLoadSuccess.value})

if (isLoadSuccess.value) {
Button(onClick = { viewModel.mergeDex(context) }) {
Text(text = “点击合并插件Dex到宿主中”)
}
val isMergeDexSuccess = viewModel.isMergeDexSuccess.collectAsStateWithLifecycle()
Text(text = “合并插件Dex到宿主是否成功:${isMergeDexSuccess.value})

if (isMergeDexSuccess.value) {
Button(onClick = { viewModel.loadClass(PluginActivityClassName) }) {
Text(text = “点击加载插件中的 PluginActivity.Class”)
}
if (viewModel.pluginActivityClass != null) {
Text(text = “加载插件中的 PluginActivity.Class 的结果:n${viewModel.pluginActivityClass?.canonicalName})
val intent = Intent(context, viewModel.pluginActivityClass)
Button(onClick = {
context.startActivity(intent.apply { putExtra(“type”“NewsList”) })
}) {
Text(text = “点击显示插件中的 NewsList 页面”)
}
Button(onClick = {
context.startActivity(intent.apply { putExtra(“type”“NewsDetail”) })
}) {
Text(text = “点击显示插件中的 NewsDetail 页面”)
}
}
}
}
}
}

运行效果:
 
可以看到,这种方式是完全可行的,几乎毫无压力。
 
对于这种占坑的方式,它的好处是每个插件只需要提供一个用于在宿主中占位的 PluginActivity 即可,这是相对于以前传统的View开发而言的,因为以前 View 并不能承担屏幕级内容展示的角色而且也没有独立的导航功能,所以需要借助大量的 Activity 类,如果在以前传统的开发中只允许你用一个Activity 类,然后页面在不同的View之间切来切去,恐怕要疯掉了。但是现在不同了,Composable 组件可独立负责屏幕级内容的展示而且也具备独立于Activity的导航功能,它可以独挑大梁,所以说基本不需要太多的 Activity 类,需要在宿主中占位的 Activity 数量自然也就很少。
 
但是这种方式并不一定能满足所有的场景,它的优点也是它的缺点,试想每一个插件都需要提供一个占位的Activity,插件多的情况下还是有可能出现大量的Activity类,还有一个严重的问题是,这种方式只能以 “跳转” 的形式打开新的页面来展示,因为借助的是一个Activity来当做 Composable的容器,也就是说,假如我想在当前页面的某个区域显示来自插件中的某个Composable组件,这种方式就无法实现。
/   直接加载插件中的Composable组件   /
为了能在宿主中当前页面的某个局部区域显示来自插件中的Composable组件,就不能采取占坑Activity做跳板的这种方式了,我们可以考虑去掉插件中的这个Activity,也就是说每个插件中只保留纯 Composable 的组件代码(纯kotlin代码),然后打成apk插件给宿主加载,既然宿主中都可以加载插件中的类了,那应该可以很轻松地通过反射直接调用插件中的Composable函数。
 
因为 kotlin 代码在最终被编译成DEX文件之前,要先翻译成对应的Java代码,而我们知道在Java当中是没有顶层函数这种概念的,每一个Class文件都必须对应一个独立的Java类且Class文件的名称必须和Java类的名称保持一致。因此不管我们的 Composable 组件是写在哪个 xx.kt 文件当中,它最终都会被翻译成一个 Java 类,然后我们在宿主中加载该 Java 类并调用该类中的 Composable 方法不就可以了。
 
这个想法似乎很完美,但是事情并没有想象中的那样简单,很快我就发现了一个残酷的现实,我们知道,Compose 编译器会在编译过程中对 Composable 函数施加一些 “黑魔法”,它会篡改编译期的 IR,因此最终的 Composable 函数会被添加一些额外的参数。例如,前面代码中的 NewsList.kt 和 NewsDetail.kt,使用反编译工具查看它们最终的形态是长下面这样:
 
这里可以看到 Compose 编译器为每个 Composable 函数注入了一个 $composer 参数(用于重组)和一个 $changed 参数(用于参数比较和跳过重组),也就是说即便一个无参的 Composable 函数也会被注入这两个参数,那么这就有问题了,即便我们能在宿主中加载该类并通过反射获取了 Composable 函数的句柄引用,但是我们却无法调用它们,因为我们无法提供 $composer 和 $changed 参数,只有 Compose runtime 才知道如何提供这些参数。
 
这就很尴尬了,这相当于我们想调用一个只有上帝才知道该如何去调用的方法。
那么这样难道就没有办法了吗?其实我们想要的就是在宿主中调用 Composable 函数而已,可以换一种思路,既然直接调用不行,那就间接地调用。
 
首先,我们可以通过在一个类中定义 Composable lambda 类型的属性来存储 Composable 函数,也就是提供一个 Composable 函数类型的属性成员。例如可以这样写:
 
class ComposeProxy {

val content1 : (@Composable () -> Unit) = {
MyBox(Color.Red, “我是插件中的Composable组件1”)
}

val content2 : (@Composable () -> Unit) = {
MyBox(Color.Magenta, “我是插件中的Composable组件2”)
}

@Composable
fun MyBox(color: Color, text: String) {
Box(
modifier = Modifier.requiredSize(150.dp).background(color).padding(10.dp),
contentAlignment = Alignment.Center
) {
Text(text = text, color = Color.White, fontSize = 15.sp)
}
}
}

这里 ComposeProxy 类中的成员属性 content1 和 content2 的类型都是 Composable 函数类型,即 @Composable () -> Unit,实际上就是定义了两个 Composable lambda。在其 lambda block 块中可以调用真正的 Composable 业务组件,因为这本质上还是在Composable中调用另一个Composable。至于为什么要这样写,可看下面编译后的结果:
 
可以看到,翻译成 Java 代码之后,ComposeProxy 中的 content1 和 content2 变成了两个 public 方法 getContent1() 和 getContent2(),而这两个方法是没有参数的,因此我们就可以通过加载类后反射调用它们。注意到它们返回的类型是 Function2,它其实对应的就是 Kotlin 中的 @Composable () -> Unit函数类型,因为在 Java 的世界中没有所谓的函数类型,取而代之的是使用类似函数的接口类型来对应Kotlin 中的函数类型(Function0…Function22,最多有22个)。
 
因此我们可以认为在编译期, Function2 和 @Composable () -> Unit 二者是等价的,因为后者会被翻译成前者。
 
其实我们不必关心返回的到底是 Function 几,因为我们最终会通过 Java 的反射API来调用 getContent1() 和 getContent2()方法,也就是执行 Method.invoke(),它返回的是一个 Object 对象(如果是用 kotlin 代码来写那就是返回一个 Any 类型的对象),因此我们可以在编写加载插件代码的时候将这个 Object (Any) 对象强转成 @Composable () -> Unit 函数类型。然后我们就在宿主中得到了一个 @Composable () -> Unit 函数类型的对象,那么我们就可以调用该函数对象的 invoke 方法了(即调用了 Composable 函数)。
 
下面修改一下 PluginViewModel ,在其中添加如下代码:
 
class PluginViewModelViewModel() {
// …省略其它无关代码
val composeProxyClassName = “com.fly.compose.plugin.news.ComposeProxy”
var pluginComposable1 by mutableStateOf<@Composable () -> Unit>({})
var pluginComposable2 by mutableStateOf<@Composable () -> Unit>({})
var isLoadPluginComposablesSuccess by mutableStateOf(false)

fun loadPluginComposables() {
viewModelScope.launch {
withContext(Dispatchers.IO) {
val composeProxyClass = PluginManager.loadClass(composeProxyClassName)
composeProxyClass?.let { proxyClass ->
val getContent1Method: Method = proxyClass.getDeclaredMethod(“getContent1”)
val getContent2Method: Method = proxyClass.getDeclaredMethod(“getContent2”)
val obj = proxyClass.newInstance()
pluginComposable1 = getContent1Method.invoke(obj) as (@Composable () -> Unit)
pluginComposable2 = getContent2Method.invoke(obj) as (@Composable () -> Unit)
isLoadPluginComposablesSuccess = true
}
}
}
}
}

修改 HostScreen 测试代码如下:
 
@Composable
fun HostScreen(viewModel: PluginViewModel = viewModel()) {
CommonLayout(viewModel) {
Button(onClick = { viewModel.loadPluginComposables() }) {
Text(text = “点击加载插件中的 Composables”)
}
// 加载成功后调用插件中的Composable函数
if (viewModel.isLoadPluginComposablesSuccess) {
viewModel.pluginComposable1()
viewModel.pluginComposable2()
}
}
}
@OptIn(ExperimentalLifecycleComposeApi::class)
@Composable
private fun CommonLayout(
viewModel: PluginViewModel = viewModel()
,
content: @Composable () -> Unit
) {
val context = LocalContext.current
Column(
horizontalAlignment = Alignment.CenterHorizontally,
verticalArrangement = Arrangement.spacedBy(20.dp)
) {
Text(text = “当前是宿主中的Composable页面”)
Button(onClick = { viewModel.loadPlugin(context) }) {
Text(text = “点击加载插件Classloader”)
}
val isLoadSuccess = viewModel.isPluginLoadSuccess.collectAsStateWithLifecycle()
Text(text = “插件Classloader是否加载成功:${isLoadSuccess.value})

if (isLoadSuccess.value) {
Button(onClick = { viewModel.mergeDex(context) }) {
Text(text = “点击合并插件Dex到宿主中”)
}
val isMergeDexSuccess = viewModel.isMergeDexSuccess.collectAsStateWithLifecycle()
Text(text = “合并插件Dex到宿主是否成功:${isMergeDexSuccess.value})

if (isMergeDexSuccess.value) {
content()
}
}
}
}

重新打包 news_lib 模块生成 apk,并拷贝到 app 模块中的 assets 目录,然后运行 app,查看效果:
 
可以看到,我们成功的在宿主的 Composable 界面中直接加载了来自插件中的 Composable 组件,非常完美。这也意味着我们可以在宿主中任意的 Activity/Fragment、Composable 中调用来自插件中的 Composable。也就是说我们的插件中可以不保留任何 Activity 类,只保留 Composable 组件及与其相关的业务逻辑代码即可。
 
相比传统的插件化方式,这种方式再也不用考虑如何去绕开 AMS 对 Activity 的校验,无需在 Manifest 中占位 Activity,也无需在系统源码中寻找各种Hook点通过动态代理的方式偷换 Activity ,因为插件中压根就不需要 Activity 了。从此以后,插件化可以走上非常纯净的道路。
 
关于 Compose 的插件化技术探索到这里还没完,最后还有一种方式来尝试一下。
 
/   套娃模式加载Composable组件   /
这种方式的灵感来自于 Composable 和 Android View 的互操作性。例如,要在 Composable 中显示一个 Android 的 View 可以通过如下方式:
 
@Composable
fun SomeComposable() {
AndroidView(factory = { context ->
// android.webkit.WebView
WebView(context).apply {
settings.javaScriptEnabled = true
webViewClient = WebViewClient()
loadUrl(“https://xxxx.com”)
}
}, modifier = Modifier.fillMaxSize())
}
其中 AndroidView 是一个 Composable 函数,可在其内部嵌套 Android 原生 View 组件。
 
另一方面,可以通过调用 ComposeView 的 setContent{} 来设置其 Composable 内容,这是因为 Activity 的 setContent{ } 方法内部其实就是创建了一个 ComposeView 来执行 setContent 的:
ComposeView 是一个公开的类,也就是说我们也可以这样调用:
 
ComposeView(context).apply {
setContent {
ComposableExample()
}
}
由于 ComposeView 是一个标准的 Android View,因此我们可以这样调用:
 
@Composable
fun SomeComposable() {
AndroidView(factory = { context ->
ComposeView(context).apply {
setContent {
ComposableExample()
}
}
}, modifier = Modifier.fillMaxSize())
}
于是我们的俄罗斯套娃版本的插件化方案就诞生了:
插件只需向宿主提供 ComposeView 的获取方式即可,宿主获取到来自插件的 ComposeView 后可以借助 AndroidView 这个 Composable 来嵌入到宿主的界面中。而插件内部的 Composable 无需向宿主暴露,包裹在 ComposeView 的内部即可。
 
跟前面类似的,在插件中定义一个 ComposeViewProxy 类,然后在其中定义一个类型为 Context.(String) -> ComposeView 函数类型的成员属性:
 
class ComposeViewProxy {

val pluginView: (Context.(String) -> ComposeView) = { name ->
ComposeView(this).apply {
setContent {
if (name == “content1”) {
MyBox(Color.Red, “我是插件中的Composable组件1”)
else if (name == “content2”) {
MyBox(Color.Magenta, “我是插件中的Composable组件2”)
}
}
}
}

@Composable
fun MyBox(color: Color, text: String) {
Box(
modifier = Modifier.requiredSize(150.dp).background(color).padding(10.dp),
contentAlignment = Alignment.Center
) {
Text(text = text, color = Color.White, fontSize = 15.sp)
}
}
}

将生成的插件 apk 使用反编译工具查看:
 
接下来只需要在宿主中加载 ComposeViewProxy 类,然后反射调用 getPluginView() 方法,拿到返回结果即可在宿主的 AndroidView 中使用了。
 
修改 PluginViewModel ,在其中添加如下代码:
 
class PluginViewModelViewModel() {
// …省略其它无关代码
val composeViewProxyClassName = “com.fly.compose.plugin.news.ComposeViewProxy”
var pluginView by mutableStateOf ComposeView>({ComposeView(this)})
var isLoadPluginViewSuccess by mutableStateOf(false)

fun loadPluginView() {
viewModelScope.launch {
withContext(Dispatchers.IO) {
val composeViewProxyClass = PluginManager.loadClass(composeViewProxyClassName)
composeViewProxyClass?.let { proxyClass ->
val getPluginViewMethod: Method = proxyClass.getDeclaredMethod(“getPluginView”)
val obj = proxyClass.newInstance()
pluginView = getPluginViewMethod.invoke(obj) as (Context.(String) -> ComposeView)
isLoadPluginViewSuccess = true
}
}
}
}
}

修改 HostScreen 测试代码如下:
 
@Composable
fun HostScreen(viewModel: PluginViewModel = viewModel()) {
CommonLayout(viewModel) {
Button(onClick = { viewModel.loadPluginView() }) {
Text(text = “点击加载插件中的 ComposeView”)
}
// 加载成功后调用插件中的ComposeView
if (viewModel.isLoadPluginViewSuccess) {
SimpleAndroidView { context ->
viewModel.pluginView(context, “content1”)
}
SimpleAndroidView { context ->
viewModel.pluginView(context, “content2”)
}
}
}
}

@Composable
private fun  SimpleAndroidView(factory: (Context) -> T) {
AndroidView(
factory = { context -> factory(context) },
modifier = Modifier.wrapContentSize()
)
}

@OptIn(ExperimentalLifecycleComposeApi::class)
@Composable
private fun CommonLayout(
viewModel: PluginViewModel = viewModel()
,
content: @Composable () -> Unit
) {
val context = LocalContext.current
Column(
horizontalAlignment = Alignment.CenterHorizontally,
verticalArrangement = Arrangement.spacedBy(20.dp)
) {
Text(text = “当前是宿主中的Composable页面”)
Button(onClick = { viewModel.loadPlugin(context) }) {
Text(text = “点击加载插件Classloader”)
}
val isLoadSuccess = viewModel.isPluginLoadSuccess.collectAsStateWithLifecycle()
Text(text = “插件Classloader是否加载成功:${isLoadSuccess.value})

if (isLoadSuccess.value) {
Button(onClick = { viewModel.mergeDex(context) }) {
Text(text = “点击合并插件Dex到宿主中”)
}
val isMergeDexSuccess = viewModel.isMergeDexSuccess.collectAsStateWithLifecycle()
Text(text = “合并插件Dex到宿主是否成功:${isMergeDexSuccess.value})

if (isMergeDexSuccess.value) {
content()
}
}
}
}

运行效果:
 
运行效果跟前一种方案相同,这种方式的代码逻辑也跟前一种几乎一样,但相比前一种,这种方案插件无需向宿主直接暴露 Composable 组件,而只提供 ComposeView。
 
实际上这种方式开发的插件可以同时混合使用原生 View 和 Composable,例如在项目改造的过程中,有可能界面中的一部分还没来得及改造完毕就需要发布应用版本,此时这部分可仍然使用原来的 View 实现,而另一部分使用 Composable 全新实现的部分可通过 ComposeView 嵌入到整个页面中,然后将整个页面再作为一个单独的 View 提供给宿主使用。

下载说明:
1、本站所有资源均从互联网上收集整理而来,仅供学习交流之用,因此不包含技术服务请大家谅解!
2、本站不提供任何实质性的付费和支付资源,所有需要积分下载的资源均为网站运营赞助费用或者线下劳务费用!
3、本站所有资源仅用于学习及研究使用,您必须在下载后的24小时内删除所下载资源,切勿用于商业用途,否则由此引发的法律纠纷及连带责任本站和发布者概不承担!
4、本站站内提供的所有可下载资源,本站保证未做任何负面改动(不包含修复bug和完善功能等正面优化或二次开发),但本站不保证资源的准确性、安全性和完整性,用户下载后自行斟酌,我们以交流学习为目的,并不是所有的源码都100%无错或无bug!如有链接无法下载、失效或广告,请联系客服处理!
5、本站资源除标明原创外均来自网络整理,版权归原作者或本站特约原创作者所有,如侵犯到您的合法权益,请立即告知本站,本站将及时予与删除并致以最深的歉意!
6、如果您也有好的资源或教程,您可以投稿发布,成功分享后有站币奖励和额外收入!
7、如果您喜欢该资源,请支持官方正版资源,以得到更好的正版服务!
8、请您认真阅读上述内容,注册本站用户或下载本站资源即您同意上述内容!
原文链接:https://www.dandroid.cn/15280,转载请注明出处。
0

评论0

显示验证码
没有账号?注册  忘记密码?