项目架构定位
终于有时间弄下自己的小项目 SimpleNews.io ，之前 frok 过来项目后，只注重了项目的局部模块的设计，没有从整体上考虑过这些架构上的事，后来在工作中接触 Android 插件和组件化开发，渐渐发现之前的项目结构太单一，一般都是根据不同的页面或者业务分几个文件夹，自己模块的逻辑都写在自己的文件夹下，也不会考虑其他复用情况，后续也有一些和其他模块相耦合的代码，根本无法扩展，当然这种方式也只是适用于个人开发，只是因为项目太小而没有察觉出太大问题，一旦项目变得庞大，那真的就已经晚了.
所以，不管项目大还是小，接下来按照组件化方式来重新设计下项目架构，按照团队开发的的模式开发。
网上有很多针对 Android 组件化开发的实施的具体步骤，我这里没有急于按照编译模式的组件化去直接修改，而是先在代码结构和逻辑上做了拆分，在过程中也逐步的抽出一些基础库、依赖库，也就是后面会常说的一个一个组件，因为之后的组件化也是依赖这些最基本的代码。
为什么要进行拆分？
1、原始方式：
- 存在诸多缺点，虽然开发简单方便，但是后续得不偿失；
2、组件化：
- 正好解决原始方式的缺点，可以将业务实现分离，单个业务可以作为模块进行上下依赖;
- 每一个组件都可以单独运行，各个业务研发同学不互相依赖，也加快了开发的速度，我们知道项目一旦大了，编译都是泪。。
拆分方法
1、新建 Lib moudel 库，将公用的类等逐步移动到依赖库中；
2、Lib moudel 库中也要分层依赖，为以后完全转成组件做准备；
3、主 app 中引用遵循分层思想；
拆分过程
看下之前的结构：
之前
之前的结构是分了很多包，里面基础功能和UI逻辑都是在一起，看着很乱，之后做组建化不方便
之后
这只是在抽离过正常的不完整版，有一些已经改掉了。
目前
局部做了相应调整，可以看到 app 目录下有两个应用，之后是可以单独运行的业务模块
app目录
注意：
前期我这里只是从文件目录进行了整理分割，等整租组件化的时候，只要把这些业务一一移动过去即可，好处是一步一步来改动，避免改动过大，导致项目紊乱，同时也是自己掌握学习的过程。
拆分资源
资源这部分指 Res 目录下的文件，一般最多的就是布局和图片，我这里是按照业务类型功能规范命名，好处是，命名严格，不许出现重复，建议 xml 中的 id 也要严格命名，防止之后出现一些奇怪的问题，最后查起来费劲。
Gradle 全局配置
关于 Gradle 我这里只是说一下我项目中的修改，一些基本介绍暂时没有涉及，之后会做一个基本介绍，一般使用 Android Studio 开发的同学应该不陌生，项目要跑起来都需要使用 Gradle 进行构建，里面有很多很好玩的东东，之后在漫漫细说，今天介绍下如何实现 Gradle 全局配置。
因为由多个 moudle 的原因，gradle 配置文件也就随之增多，所以必须统一管理这些配置，。不然一个一个修改太费劲了。
一般项目结构：
gradle
我这里新建了一个 config.gradle 配置和 build.gradle 同级，内容如下：
config.gradle
然后在项目级别的 build.gradle 文件加上以下配置代码：
apply from: "config.gradle"
使用
在其他 gradle 配置文件中使用：
这样就能统一管理起来一些配置选项，当然如果你的配置修改了，需要手动同步构建一下。
坑坑坑坑：自定义的配置文件配在根目录的字段不生效，改用数组里面，应该是和系统的冲突了，分开放就好了
完整配置
总结
以上内容就是项目架构定位 & Gradle 全局配置两部分的优化整理，重构还谈不上，这是一个长期的过程，每做完一点记录一点，对自己也是一个成长，之后还会继续跟进。
SimpleNews 项目的重构之旅其他文章
SimpleNews 项目的重构之旅(1) －项目架构定位 & Gradle 全局配置
SimpleNews 项目的重构之旅(2) － 整理项目 .gitignore 文件
SimpleNews 项目的重构之旅(3) －EventBus 接入
SimpleNews 项目的重构之旅(4) －Gradle for Android 基础知识汇总
SimpleNews 项目的重构之旅(5) － Android Gradle 打包&混淆应用
SimpleNews 项目的重构之旅(6) － 命名规范 & Android Toolbar
SimpleNews 项目的重构之旅(7) － 改头换面&深度清理
网友评论