Prototype Z

暂时不支持，主要时出于编译时扫描的性能考虑，后续会考虑支持

感谢建议，事实上我已经在着手重构，新的版本会在API兼容的基础上，使用性能更好的实现方案 :) 对于目前的版本，编译耗时主要在全量编译的过程中，个人实践 20+ 模块的编译过程中，耗时可接受，对于模块单独开发的流程则不会有任何影响。本人开发项目流程开发中，已经很少使用全量编译，大多数时候都是在模块单独开发，所以当前版本对日常开发的影响并不大。

很高兴对这个小工具对您有用　：），谢谢分享你的宝贵经验，证明了 AppJoint 是个低入侵性、轻量级的组件化方案，我主张项目不应该和某个具体的组件化方案强耦合，您做到了这一点，说明你已经把项目结构改造到十分松散耦合的状态了，如果是其它的组件化方案不一定能做到这一点。

这个问题确实存在，目前我也在想有什么方法可以避免这种情况

@razerdp 首先非常感谢提出如此详细的建议，非常抱歉回复较晚，一方面工作较忙，另一方面由于您的建议很具体，有一些我确实之前不是特别懂，花了一些时间调研。 1. gradle 里的subprojects 我才发现原来这么有用，感谢你的建议，我之前有计划把现在纯 plugin 的模式，改为 apt + plugin 的模式，但是又担心配置过于麻烦，我感觉这个可以帮我节省不少配置，很赞 2. 这两个注解确实是为了做初始化工作，而且现在已经可以支持按照 priotiy 进行初始化了。 3. 很好的建议！我在调研期间已经支持这个功能，并已经发了新的一版 4. 拦截器的功能我觉得交给 ARouter 这样的库去做更好，我这个小工具功能很纯粹，就是只做跨模块接口调用。良好的接口设计可以避免“拦截器”这样的需求出现。 5. 很赞！我也是这么建议的 6. 这个功能已经实现，但是我现在觉得可以用更好的方式实现。 7. 使用provider进行初始化我之前考虑过，但是觉得无法控制先后顺序，但是现在经过调研，我确定可以在编译期间修改 manifest 增加任意...

@razerdp 嘿嘿，我就是看到了 initOrder 这个属性，我的思路时对用户暴露 prioiry 这个接口，实际的实现是，在编译期增加 provider 并且添加 initOrder ，用户不需要直接去操作 manifest 。我估计这个时可行的 :)

[捂脸]其实我一直在硬改开发者的代码 逃

你研究的时PackageManagerService的代码吗？ 我的意思是，AppJoint 的现有的api完全不变，创建新的provider ，以及把provider 写入manifest 都由工具来做。另外，如果我自己维护一个 provider 来管理用户的注解类就和现在的实现差不多了，能交给系统来做的就交给系统去做吧，嘿嘿

Oh, sorry for that, I commit it by mistake, I will remove it from repository, thank you :)

You are right, I'm working on it to remove this large file from git history. Thanks : )