我带的第一个安卓项目，现在想起来简直是一团浆糊。
那时我们搞移动端，刚开始大家一股脑就往那个主模块里塞东西，什么UI组件，业务逻辑，甚至各种第三方库的版本号，全都在一个文件里写死。项目稍微大点，编译一次能让你去冲杯咖啡，回来还没
小编温馨提醒：本站只提供游戏介绍，下载游戏推荐89游戏，89游戏提供真人恋爱/绅士游戏/3A单机游戏大全，点我立即前往》》》绅士游戏下载专区
为什么我下定决心要整理这摊烂泥？
真正让我痛下决心必须把安卓项目结构好好梳理一遍的，是前年接手了一个紧急的电商项目。那个项目要求我们同时维护三个环境：开发环境、测试环境和生产环境。我们当时就是靠手动改代码里的配置来切换环境，每次发布前都得像做手术一样小心翼翼，生怕哪里漏改了。结果，有一次测试环境发布时，我大意了，把生产环境的某个SDK密钥给打包进去了。
虽然没造成直接损失，但那个周末我是在公司通宵过的，把所有东西回滚、检查、重新编译、重新部署。那一晚上，我对着那个慢得要死的构建过程，心里只有一个念头：再这样搞下去，迟早要猝死在键盘前。
痛定思痛，我决定必须把项目“模块化”这个事情彻底落地，而且要搞一套傻瓜式的管理流程。
我具体是怎么拆分和管理的？
我做的是拆家。把所有功能模块从主应用里狠狠地剥离出来。我们不是要高效吗？高效就是让改动的影响范围最小化，让构建速度提升上来。
我把项目结构重新规划了，主要分成了几个部分：
- :core-common：专门放那些所有模块都需要的底层工具类和基础配置。这里面基本不改动，稳定得很。
- :feature-xxx：每一个业务功能（比如“购物车”或者“个人中心”）都独立成一个模块。要改购物车，就只编译购物车，不影响
- :data-repository：专门负责数据获取和缓存的，把网络请求和本地存储全部扔进去，让业务模块只管展示和逻辑。
光拆还不够，版本管理是另一个大坑。以前各种第三方库的版本号散落在几十个模块的配置文件里，升级一个库简直是灾难。我立刻引入了统一版本管理。
我专门创建了一个单独的文件，把所有用到的库和版本号都集中管理起来。这样，以后要升级，只需要改一个文件，一目了然。这个操作看着简单，但效果立竿见影，团队成员再也不会因为版本不一致导致各种奇葩的冲突了。
至于环境切换那个老大难问题，我用了更偷懒的方法：构建变体（Build Variant）配合配置文件。我把开发、测试、生产环境的配置（比如API地址、密钥）全部写到了不同的资源文件里，通过Gradle的配置来自动切换，每次构建，打包机自己就知道该用哪一套配置。彻底告别了手动修改和粗心大意。
结果如何？
这套东西跑起来之后，效果那是相当明显。原来十分钟的构建时间，现在只需要三四分钟，局部模块编译更快。最关键的是，开发人员终于可以专注于写业务代码，不用整天跟那个破构建系统和版本冲突较劲了。
以前发版，我心惊胆战。现在流程清晰了，只需要在打包机上选好环境，点一下，剩下的就交给机器了。这才叫真正的效率管理。说到底，项目管理不是为了显得高大上，而是为了让自己少加班，少背锅。这套实践，真是用头发换来的经验！
