组件化之AppJoint和ARouter

组件化之AppJoint和ARouter

1、分类

application：apk,安装包，会依赖library，而不会被别的library依赖。
library：aar，依赖，可以依赖别的依赖，也可以被别的library依赖。

一个依赖（上级）依赖于另一个依赖（下级）
包名不一样，类名自然也就不一样了，这样自然就不会产生类冲突。
但如果是在res里面，比如drawable里有photo.jpg文件，这种情况，大概率会产生冲突。如果冲突了，上级的资源会覆盖下级的资源（只是显示的时候改变，并不会更改下级资源）。

2、模型

----Router会做组件对外开放的功能，APPlication被抽空为一个APP壳，主要功能模块都在下面的libA，libB，libC中，而Router会暴露出三个lib的接口，让他们可以在Router中相互调用。

理解组件化，CS/BS模型

----这个模型是BS/CS模型，能很方便的理解组件化的思想，思想差不多。B和C把内容交个DNS，然后DNS来解析，生成baidu，和10.10.10.10, 把所有组件放到一个项目中，这样的话，B,S和C互相不接触，就像三个黑盒，这样就可以极大程度的解耦，降低耦合性。
-----上述两个模型其实想表达的意思差不多，所有组件在一个项目中，libB，libC就相当于B端，和C端；Router就相当于DNS；libA就相当于一个登录功能模块，如果libA开放了能力，那其他的模块就可以利用其开放的用户信息，用户登录状态信息等。
-----每个lib都可以服务，都可以使用别人的能力，也可以暴露自己的能力供别人使用。
-----其实这就是组件化的思想，把一个完整的项目，拆分成不同的功能模块，减少其中耦合的部分，使功能互相不干预，想访问的时候，通过对方暴露出来的接口，来调用方法，从而调用其中的数据。

3、具体应用

----比如做一个应用，有三个业务，登录业务，呼叫业务，设置业务，他们分别对应三个组件，即登录组件（Login Module），呼叫组件(Dispatch)，设置组件(Setting Module)。
----在开发的时候，无论是开发功能模块还是解bug，都要先找到自己负责的模块在哪里，也不用担心自己负责的模块和别人的模块有交集，自己无法解决。
----内部的功能模块：例：清理缓存，即删文件，不需要和别的组件进行交互，自己正常开发即可。
----对外开放的：有可能使用到ARouter，或者AppJoint。ARouter比较经典，但AppJoint更适合自己。

ARouter：

自动的
标记，告诉别人我是可开放的
形成路由表，ARouter是自动的，遍历所有，并做标记，被标记的 即为可开放的，形成路由表，然后跳转，这样更安全可靠。

AppJoint：

半自动的
需要自己手动打开每一个类来遍历，然后标记，然后写到路由表中，
但他会自动找到接口的实现类，虽然需要手动打开每一个类来遍历，容易造成缺失，但如果缺失，编译时就会报错，这也就让程序员能够谨慎核对，这个缺点就不用过于在意了。

如何写AppJoint：

当自己的模块对外开放时：

1. 定义接口（如果没有的话）
2. 接口内声明对外开放的方法
3. 真正实现接口（用@Service注释），会在组件内implement接口（对应组件内）
4. 真正实现，可以具体业务：DB数据通讯录，提供用户信息，查询信息等

当我们要用别人的信息时：

 AppJoint.getService(接口.class)   //这样就可以调用方法了
  真正实现（所有方法）调用		//然后就可以获得具体的联系人信息等

 List<DIS> getAddress(where)
 return DB.get(where)