Android 对架构和路由的思考

学习自

https://www.jianshu.com/p/9c646002e2f7

这是一种好架构吗？

有人认为，很好了。我第一眼看过去，也是很不错了。因为这就是我的架构。项目会分成若干module。

其实不太好。

原因在于，耦合，你中有我，我中有你。为什么这么说呢？我是这么写的，比如A业务包，我会开放一定的API，然后也会开放一定的接口，我碰到写不下去的功能了，有些东西不属于我模块负责的，我直接扔个接口出来。别人去实现。其实这样存在的弊端是，我A业务包的内部会包含实现者的引用。一个倒还好，可以接受，多了，这耦合还是不低。

所以这张图变一变

看似没什么不同。其实我们是把所有的“接口”扔给了路由，让他去统一管理了。

以前我是

private Action action=..;

public interface Action {

...

}

现在need("pay")，我就能调用支付功能了，相当于从显示，变为了隐式。

但是我还看过美团猫眼，他是这样解耦的：

它主要侧重模块接入。里面的下拉刷新样式、网络等库，都也写成need("功能")的形式，但是他不交给路由去统一配置，他为这个模块专门写一个文本，所以主app想接入，写个文本进来就好了。这样我觉得也很好。

所以功能从接口.方法->need（“功能”），从显示到隐式是我们必须要做的。但是这些所有的功能是否要由路由统一管理或者是一个模块一个文本，还需要见仁见智。我个人认为可以进行一个路由的配置（而且路由最好写成restful的规范，比如功能/ 网络，页面/商城主页这样的），再把路由注解内的东西写成文本，似乎是一个中和、上佳的选择。

我对架构的理解：

没有想象的那么恐怖。其实就是代码不同位置的摆放。我们刚起步的时候，是一个Activity中的业务，UI流水账下来的，后来慢慢地学会了用MVP，解耦了UI和数据；最后发展出代价更小，解耦程度更高的架构。其实只要架构好了，哪怕模块局部乱一点，也是能写下去的。如果没有架构，项目规模又膨胀了，这个时候项目就做不下去了。

还有一个理解就是，不仅要注重全局的架构，模块内部、局部的代码也要注重架构。架构并不是一个宏观的名词，只是换了一个地方放代码，让你更容易找到、分类而已。

最后

以上就是孝顺硬币为你收集整理的Android 对架构和路由的思考的全部内容，希望文章能够帮你解决Android 对架构和路由的思考所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。