shifujun

这个功能是支持的。但是一直没演示也没测试用例。我刚补充了一个基本的测试用例。 https://github.com/shifujun/Shadow/commit/005085d5a53fc0fe4cb8ac69275df324b212c11a 麻烦在此基础上修改看看能不能复现问题。

那你看看是不是这个意思：https://github.com/shifujun/Shadow/commit/d8651c3d6ba0b06d15ecc767011926bcc6d36c4f 不是的话，你改一个。

没有代码不方便测试，晚点再看吧。

https://github.com/Hxh188/Shadow/blob/bff43c0f37d5c6aab9bc75940fe99d1ebf7f6684/projects/test/dynamic/host/test-dynamic-host/src/main/java/com/tencent/shadow/test/dynamic/host/UpdateManagerImplTestActivity.java#L69-L82 我不太理解为什么会有复用File对象的需求。这里如果File对象不变，文件路径不变，最终ClassLoader和Resource加载文件时是有可能使用缓存的。 因为完全没必要复用相同路径，所以我也不太想花精力搞清它的缓存逻辑。 建议深究这个问题的话，可以脱离Shadow来研究，单纯研究File、DexClassLoader、Resource这3个类型的创建效果就可以了。 对于Shadow，可能确实可以在`ImplLoader`中加入这一情况的检查，及早提示错误。

> 那是否说我要每次下载保存的文件路径都要不一样吗？ 是的。

Provider的壳子和插件Uri的对应转换关系只存在于Loader内存中，因此插件不能跨进程直接调用。Activity、Service也是如此。 支持这一特性需要对Loader添加跨进程共享插件信息的进一步开发。

Shadow是一个开源技术交流项目，并不提供商业服务。 如果我们业务中有遇到这种场景，我们有这方面的实现的话，我们是很乐意开源分享出来的。不过暂时没有这方面的需求。

https://github.com/Tencent/Shadow/blob/11a71f0ea95decc4de7ad58953f8bc97a4b2d654/projects/sdk/core/loader/src/main/kotlin/com/tencent/shadow/core/loader/managers/PluginContentProviderManager.kt#L34-L49 Provider的映射信息就是这个类的3个Map。所以你需要让不同进程的这个类的对象相互共享其他进程的这些map。 一旦找到映射关系，将插件的Provider映射成系统认可的壳子Provider，那么跨进程调用Provider本身就是正常被系统支持的了。然后壳子Provider因为带有映射关系作为参数，就可以在对应进程里委托Loader再映射回插件Provider。

> 进程间怎么去共享这三个map，有没有参考的例子？ 用任何跨进程通信方案都可以的。

VerifyError一般是两个类有依赖关系，编译时依赖的版本和运行时依赖的版本接口不一致时抛出的异常。如果单看`ShadowActivityDelegate`的话，可能有问题的是它会依赖`HostActivityDelegate`接口。`HostActivityDelegate`接口是打包在宿主中的，其余类包括`MixResources`都是打包在`loader.apk`中的。所以我首先怀疑的是你修改了什么代码，使得宿主和插件的接口不匹配了。 另外你贴出来的堆栈看起来不全，没法判断是否看到了root cause。 关于只在Android 12机型上有复现这一点，目前看到的信息没有值得支撑这一机型特点的证据。sample在android 12的虚拟机上是可以正常运行的。只看贴出来的堆栈部分，也没有涉及到Android 12新增的API。 建议还是先检查一下对SDK都有哪些修改，以及基于SDK的什么版本。