leobert

抱歉这么晚回复，目前JIMU跨组件调用的主要思路：约定暴露服务的API，提供者注册实现到下层的IOC容器（Router），使用者通过IOC容器获得实例访问控制。所以需要对牵涉到的API接口（ComponentService）以及相关的数据bean、回调接口等都需要做下沉处理。 ps：APPShareBean是不完善的代码，当时我在JIMU中添加了事件机制支持，打算重新整理下sample，出于很多原因搁置了。 回到刚才的问题，对于class，只要是跨组件调用所需要的，下沉处理；存在通用性的（例如UserInfo）下沉处理；对于res，color、style等全局规范类的推荐下沉、公用的基础性文案（Strings资源）推荐下沉；其他的组件单独维护即可。

下个版本会开放一个decorator提供对intent的装饰

sorry，会在JIMU项目中提供，DDAndroidComponent这边不再提交PR

上次有个issue还准备写一下gradle plugin3.0.0 迁移的，发现有分支之后就一直没动手 233🤣

JIMU实现组件化加载的核心是定制了gradle编译的task，请检查是否有使用了其他gradle插件，带来了可能的兼容性问题。之前测试主要在gradle-plugin 2.x版本，3.x测得比较少

@KingMing2017 检查一下没有被自动注册的组件，其中IApplicationLike的实现类，是否被RegisterCompManual注解，如果是，该组件只能被手动注册。

DDComp这边代码很久没有维护过了，记忆中，在使用Autowired的时候，当时提供的功能并不是很多。 在JIMU那边最新的代码里，我也仅提供了这些支持： ``` // Primitive if (typeMirror.getKind().isPrimitive()) { return element.asType().getKind().ordinal(); } switch (typeMirror.toString()) { case Constants.BYTE: return Type.BYTE.ordinal(); case Constants.SHORT: return Type.SHORT.ordinal(); case Constants.INTEGER: return Type.INT.ordinal(); case Constants.LONG: return Type.LONG.ordinal();...

@xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题 :octocat: [From gitme Android](http://flutterchina.club/app/gm.html)

> > > @xiaojinzi123 dd这边很久没维护了，包括jimu也有不少时间没维护了，jimu那边的路由我升级过几个版本，可以对生成的intent进行额外的操作。确实，路由框架在绝大多数场景下都是花里胡哨，有兴趣可以看一下jimu那边。 包括像arouter也是用的json应对一些传值问题 > > > :octocat: [From gitme Android](http://flutterchina.club/app/gm.html) > > > > > > 从 DDComponentForAndroid到jimu，到升级维护的 component。小弟收益匪浅。 > > 但是我一直的想法是 “路由的方案真的是最好的吗？” > > 通过路由意味着需要维护路由表且需要硬编码，同时除了强大的arouter用于页面跳转场景/api提供场景外，基本项目router用于页面跳转。个人觉得很没有必要。 >...

TODO：迭代中文法发生了改变，细化文法，将颜色、尺寸等终结符剥离出来