请教下：运行test-none-dynamic-host模块，启动的插件还是在宿主进程的问题。

[SunShineMy66]

我们决定使用非动态化加载插件，但是有5个业务插件，期望运行在5个不同进程中，现在test-none-dynamic-host模块演示的demo启动的插件还是在宿主进程中，请问如何基于非动态化让5个业务插件运行在5个不同进程中呢？

[shifujun]

动态化是shadow不可或缺的关键设计。那个none-dynamic的demo更多的作用是保持动态化的代码始终分层实现。就是core层应该能单独运行。

因为业务中是不可能单独用core层的。所以在core层先实现一个PPS就没有那么重要了。尽管确实应该这样写代码才更优雅。

none-dynamic的demo显然就是在没有PPS的情况下接入的loader。如果你把接入代码移到另外的进程不就达到你的目的了吗？插件是宿主代码的一部分，所有你在宿主的单独进程中启动插件，插件就看起来运行在插件进程了。PPS就是宿主代码。没有PPS就还缺少跨进程支持插件service的能力，因为我们需要它跨进程传递插件的binder。

[SunShineMy66]

1、清单文件中PluginDefaultProxyActivity配置了android:multiprocess="true"属性，表示Activity跑在调用进程里面。 调用进程是在清单文件中通过配置PluginProcessPPS来区分的，所以得创建5个PPS类并在清单文件中配置5个不同进程，并且需要把none-dynamic 模块的loadPlugin代码放到PPS中，对吗？

2、因为Manager、runtime、loader维护起来真心复杂，和版本还可以存在多对多关系，复杂度再次升级，所以我们考虑使用非动态化来实现插件化，，不知道去掉runtime、loader、manager后，是否会 影响后面插件的升级呢？很担心插件里遇到bug，如果使用非动态化方案不能解决这个bug会出问题？

Shadow研究了2个月，还是有很多不懂的，请大佬帮忙分析下上面2个问题，谢谢。

[shifujun]

我不太能理解你说的。比如android:multiprocess是Android系统的定义，不是shadow定义出来的。你的表述好像它是shadow设计的用来控制什么的。

我也不能理解你说的复杂性，因为在我看来不存在所谓的多对多版本。维护代码和发布也很简单。就是这些动态化的部分在升级时没有太大心智负担。如果你能把这部分动态化去掉，那你是插件也可以不动态化了。它们和插件是个整体。分成多个apk只是因为要加载到不同的classloader里。

通过issue空谈效率是很低的，对其他人也不会有什么帮助。建议你可以参与到开源项目中，通过改进项目的sample、demo甚至注释、文档，来加深对项目的理解。比如你想做none-dynamic的模式，你可以改进shadow的none-dynamic demo。对shadow的代码修改也可以在PR中得到落实。合入也可以保证后续的兼容性。

[SunShineMy66]

感谢，我先采用none-dynamic模式接进来。后续有改进的地方我听你的，参与到开源项目中。