Googoogy

> 不通过service实现你就得自己处理跨进程调用的问题，那就自己写个binder，像shadow的PPS一样。 > > 如果在同一个进程，最简单的手段就是让插件依赖宿主一个接口，然后把实现填充到一个静态域里。像sample中 HostUiLayerProvider 那样。 试了一把把相关的功能改到pps里感觉有点复杂，最后还是决定改到service里执行，就是返回值结果似乎没法返回给调用方这里有点麻烦，需要通过广播通知调用方，是否有更方便的方法可以通知调用方？

碰到了一样的问题，希望这些能帮助你 ``` def codingGroupId = 'com.tencent.shadow.internal' def codingPath = 'projects/sdk/coding' publishing { publications { aarToJarPlugin(MavenPublication) { groupId codingGroupId + ".aar-to-jar-plugin" artifactId codingGroupId + ".aar-to-jar-plugin.gradle.plugin" version publicationVersion artifact("$codingPath/aar-to-jar-plugin/build/libs/aar-to-jar-plugin.jar") artifact sourceJar("aar-to-jar-plugin", "$codingPath/aar-to-jar-plugin")...

> 一个loader本来就可以加载多个plugin的。custompid就是为了防止你这样误用时难以定位问题的。 请问调用过程中是什么地方不正确呢

> sample-app和sample-base就是两个插件，可以参考下。 > > 你说的static域执行了两遍，肯定是有什么更混乱的事发生了。不建议你继续调试multiloader的实现。即便你把代码发上来，我调试明白具体问题，也没什么可复用的意义。 先前FastPluginManager使用PluginManagerThatUseDynamicLoader,单独打开A插件或者B插件都正常,但是我使用A插件后再使用B插件,发现mPluginLoader.convertActivityIntent(pluginIntent);返回不正确 原因是mPluginLoader会从第一次打开的插件中找loader,然后从这个动态加载的loader中查询Activity对应的intent,从错误的插件中找自然不到对应的intent,最后导致intent没有被正确convert,导致activity打开失败 请问我是什么地方漏了关键步骤或者有什么实现不正确吗

> 你可以先debug sample-app和sample-base的运行情况。看看多个插件是怎么加载到loader里的，intent是怎么转换的，转换后的intent又是怎么加载插件的。 > > 加载多个插件就是依次构造出classloader，resource等让loader持有着。再把插件的组件信息放到map里持有着。所以加载完的插件不存在再去原先插件apk里查找信息的情况了。 > > 多debug sample应用再debug你有问题的业务场景。 我这里实现中的多插件和demo里的多插件有点不太一样;demo里即使有多个插件,仍然只有一个runtime和一个loader,多个插件被打包在一个plugin.zip中,我本地集成的时候,会有多个的plugin.zip,所以也会有多个的loader和runtime 刚才恢复了之前的代码,跟踪断点发现加载多插件时会使用旧插件loader的原因是 pluginManager在convertActivityIntent时,使用到com.tencent.shadow.dynamic.loader.impl.DynamicPluginLoader#loadPlugin方法 然而loadPlugin方法在获取installedApk的时候的实现是val installedApk = mUuidManager.getPlugin(mUuid, partKey),这里的mUuid只在构造的时候初始化一次,加载了第一个插件是正常的,加载第二个插件时mUuid就是上一个插件的,因此在调用loadPlugin(partKey: String)的时候肯定返回值不正确 所以我觉得我可能还是得用回PluginManagerThatSupportMultiLoader,请问一下,之前的回答中不建议我使用PluginManagerThatSupportMultiLoader的原因是什么,是这个类放弃维护了吗?

> PluginManagerThatSupportMultiLoader是用来在同一个进程加载多个Loader的，你可以在提交记录里看到。你只是要加载多个插件，所以你用不上的。 > > > 我本地集成的时候,会有多个的plugin.zip,所以也会有多个的loader和runtime > > 即便你打包多个plugin.zip，它也只是个zip包。你没必要发布多个loader和runtime，更不应该分配不同的uuid。 > > 你可能太快上手复杂的场景了，没太理解sample那种简单的场景下整个系统的工作流程。 感谢指导，尝试给多个插件分配了相同的uuid，并且把loader与runtime剥离出来 单独load多个插件都是正常，load一个插件后load第二个插件会提示 java.lang.IllegalStateException: java.lang.RuntimeException: 重复添加 ContentProvider 十分不惑 我的插件中并没有使用到ContentProvider，只有在loader中才有ContentProvider，然而loader现在只有一份了，为什么还是会提示重复添加

经过反复比对，我发现我的多插件不能运行的原因是获取installedPlugin之后loadPlugin的问题 如果在此时load多个plugin，可以正常访问多个插件 如果在此时每次只load单独一个plugin，并且多次load不通的plugin，就会出现重复添加 ContentProvider的异常 我这里先看看有没有办法处理，如果需要一次loadPlugin所有的plugin，可能会和我的使用场景有所不符

参考FastPluginManager#installPlugin 这里的zip路径是外部传进来的，如果用多个apk的话你得动一动manager里的代码了

> arm64不能编译,麻烦看下 replace uint32_t with uint64_t