对架构的一点思考

仅作个人记录，读者看之几乎无益

本文灵感来自

1.某大型项目的源码的长达1-2天的阅读

2.微信架构演变一文

一开始我想到了纯模块化，比如说一个项目，把每个模块都拆分的清清楚楚，模块之间不产生任何依赖，仅仅暴露接口。这也是微信一文的一个思想。

在项目扩大的时候，模块会衍生许多小模块，这些小模块就变成了新的独立的模块了。

最后我们需要画一张图，把整个系统，画成一颗模块树。

利

我们开发一个模块的时候是很简单的，跟做一个小项目一样，甚至可以写在一个独立的apk里。我们只需要划分模块很清晰，就能在架构上迈出坚实的一步了。

弊

每个模块里都有不同的基类依赖，比如模块A请求网络用的是OkHttp，但是B请求网络如果用的也是OkHttp，那么包不就重复引入了，apk体积不就大大增加了？当然我们可以统一管理lib与so，但是这些大型的库，和小型的工具类又有何区别？所以我们最好是把所有的基类都放在同一个库里统一管理。

这个时候有2个方式可以选择：

1.所有的都放在基类里管理

2.先写在模块里，列一个清单，发现某个基类（也可以称之为服务、功能，是lib、so+服务的结合体）被重复依赖2次的，就直接下沉到基类，如果只有这个模块会用到这个基类，就保留在这个模块里

显然是第一种方法好，第二种方法固然可以简化基类，但是模块内的基类仍有留存，这样管理起来就显得复杂。所以最好是所有的基类都放到底层，这样模块只需要关心业务即可，剥离了业务与基类，让我们写模块更加高效。

最后一点是基类的依赖

这里重点讲工具类之间的依赖。我所阅读的那个大型项目以及我之前阅读的某个大型项目，发现工具类之间的依赖特别严重。当我需要抽离出一个功能到我自己的项目里的时候，往往需要抽离出他整个工具类文件夹的半壁江山。这样一来，工具类的复用就变得特别困难了。

解决：

暂时没想到非常好的方案。

方案1：在写工具类的时候，不依赖其他工具类，碰到需要借助其他工具类功能的时候，把其他的工具类拷到该工具类下，争取一个类就可以解决需求。（此外就是一个工具类最好负责单一的功能，不要大杂烩）

方案2：在写工具类的时候，采用隐式依赖的方法，扔接口，拿接口（类似阿里路由）。这样我们在拷贝这个工具类的时候，不会发生编译级的错误，然后我们可以很快地定位到隐式依赖的地方，然后拿一些功能过来。借鉴方案1的思路，尽量少地去索要其他工具类的功能。实在没办法，我可以自己实现这个隐式依赖，然后注释掉代码，我拷贝这个工具类的时候，发现我的工具类库实现不了、还未实现这些功能，就把之前的注释拿掉，自己实现隐式依赖。如果工具类库中有这样的功能，那就可以直接进行匹配了（当然协议要约定好，像阿里路由一样）

最后的心得

架构如人生，如何清晰地规划自己的人生，并且不局限于清晰的简单，这才是有意思的

架构内外之分

内如MVP解耦UI、数据

外如模块间解耦这样分比较粗浅，其实从高层到低层依赖无处不在，一定要多开发，有意识地去考虑每一寸代码该去如何架构