未来很快将支持的

以下是各App接入方提出的一些，我们认为有必要在未来几个版本支持的特性。因为现在还不支持，为了“不坑大家”，故在此列出来，但将来版本支持后将“去掉”这些限制。

暂不支持“宿主和插件之间直接调用类和方法”（宿主和主程序形成父子类ClassLoader）方案
- 建议：采用经过验证的“反射”、Binder等方式，可做到“天然的”版本控制。同时，近期会推出“稳定共享代码”方案（和业界做法不是很一样），敬请期待。
- 原因：这是RePlugin的性质所决定的。也即——尽可能的稳定，不要有直接调用带来的问题。因篇幅所限，请了解这块儿的更多内容。

近期明确不支持的

注意：这里列出的限制中，有些是出于系统原因，不仅RePlugin，而是各插件化方案都不能很好的支持。而非“仅RePlugin不支持”，特此说明。谢谢您的理解！

插件声明Target SDK无效，只认主程序的
- 建议：根据需要来调整主程序的Target SDK，同时插件和主程序最好同时调整。这样即便插件变成单品，也能做到“天然的适配”。
- 原因同上，不赘述
不支持“双开应用”功能。也即：“不经修改，直接将任意APK放入RePlugin进行‘免安装运行’”
- 建议：RePlugin的核心诉求是在“稳定（1 Hook，0 Binder Hook）的前提下”，尽可能保持灵活，且以最小的成本，产生更多的插件，而非“免修改APK直接运行”。
- 如确实需要开发双开、免安装应用，或公司接入的插件均“只提供APK（不含混淆后的AAR）”的，可使用我们360的另一套成熟的框架：，或 @Lody 罗迪的 VirtualApp。
- 原理：要想实现这种效果，必须先Hook AMS、PackageManager，甚至还要做很多Native Hook的工作。Hook点会很多，也会有不少的适配工作。但只要Hook齐了，就能让一个应用“直接运行起来”，但代价是“适配量太大”，对未来新增的机型充满了“未知性”。

overridePendingTransition，仅支持使用宿主和系统的
- 建议：将动画资源“预埋在主程序里”，且确保其ID为固定（利用public.xml），这样可以通过拿主程序的动画ID来传递给系统，实现相应效果。目前手机卫士等产品都是这样做的，效果不错。
- 原因：此方法仅会传给AMS两个int值，且由AMS层进行资源解析并实现动画效果，根本到不了客户端。目前市面上所有插件化、热更新方案均无法实现此功能。

不支持“宿主和主程序无缝使用资源”（共享资源）方案
- 建议：采用更稳定的一些API来“迂回的”获取资源。顺便说一句，RePlugin支持“共享View”方案（例如公共UI库的使用等），这样“无缝获取资源”的场景，在其它方面也能得到满足。
- 原因：这是RePlugin的性质所决定的。也即——尽可能的稳定，不要有适配代码。因篇幅所限，请了解这块儿的更多内容。
不支持“主程序退出后”的静态广播
- 建议：请尽量避免过分依赖“主程序停止后”的“静态广播”（Android 8.0以上更是如此，因为原生就禁用了）。此外，只要常驻进程存在，则静态广播将一直生效。
- 原因：毕竟是“模拟的”静态广播，本质上仍是“动态注册广播”。这和系统直接唤起应广播所在进程，然后发送的“静态广播”是不一样的。