shifujun
shifujun
> > > > > > Sample的Demo是经过transform修改吗？ > > > > 因为我看到有接入文章中提到需要在AndroidManifest.xml中提前写好插件的ID，似乎不满足应用市场宿主App不更新自身情况下就可以打开任意插件应用的需求 > > > > 目前对Shadow的了解还很浅，希望大大解惑！ 建议主要阅读和调试源码，wiki也可以看看。
插件不能直接引用宿主资源ID，就像插件不能直接引用宿主类一样。Shadow做了宿主和插件的隔离，就是为了让宿主和插件版本关系可以多对多。在此之上Shadow提供了插件访问宿主类的白名单机制，可以把稳定的接口放在其中。通过这个接口宿主和插件才可以相互调用。因此最好通过Java接口从宿主提供资源给插件。
我想插件技术最重要的特性就是满足宿主和插件的多对多版本关系。因此把插件的可复用资源放在宿主中不是个好主意。
`dependsOn`只影响ClassLoader的parent逻辑，不会影响Resources的逻辑的。 但是做资源的依赖关系也是可行的，Android系统本身就支持。可以在构建aar模块时用`public.txt`固定一些资源ID，然后在其他Apk中引用固定的资源ID。还需要用`aapt2`的参数在构建时修改资源ID的分区。 构造插件的Resources对象时也需要将被依赖的apk添加到`android.content.pm.ApplicationInfo#sharedLibraryFiles`字段中。可以通过修改Shadow的这个方法修改构造Resources对象的逻辑`com.tencent.shadow.core.loader.blocs.CreateResourceBloc#create`，将dependsOn引入到这里来。 这里可能有些坑，Android大概是8.0或者9.0，`android.content.pm.PackageManager#getResourcesForApplication(android.content.pm.ApplicationInfo)`这个API构造的Resources对象才能正确识别`sharedLibraryFiles`中的资源ID的分区号。旧版本的Android系统还是需要反射AssetsManager才能正确构造。
没有代码，复现不了，谁也帮不上你什么吧？
如果你的代码是闭源的，我只能建议你对比Shadow前后版本的代码差异，然后debug那些改动的代码。找出问题后在shadow的sample上复现出来。
在Shadow框架下插件是依赖宿主的，所以宿主对插件的依赖都要通过控制反转设计。 可以参考`sample-host-lib`中类的使用。
sample-host-lib就是具体的例子了。你可以全文搜索其中的类名包名。
你可以自行搜索一下“依赖注入和控制反转”，这是一种基本的设计模式。
看你干什么用。按我的理解，苹果、Google等应用商店都是禁止应用动态更新软件功能的。插件或热更新等能动态更新软件代码的技术都有能力动态更新软件功能，同时也有能力动态修复bug。应用这些技术如果只用于修复bug，一般是能够通过审查的。 从技术对抗的角度看这个问题，shadow也只依赖dexclassloader，这个动态加载class的技术技术广泛存在于各种app中。所以shadow比较容易对抗技术审查。