Android项目架构演进的思考与总结
从2016年1月，到2017年2月入职满一年，见证了Android团队一路走来的发展历程。这一年，跟着项目组一块儿成长、进步，将这些记录下来，算是对本身这一年工做的总结。
Eclipse 到 Android Studio 的切换
16年入职时，Android Studio 刚刚发布新的1.0 stable版本，项目组的Project和全部的Library都切换到AS环境进行开发，可使用最新的AS进行开发，可是构建工具依然选择的是Eclipse使用的Ant进行编译。
在实际项目使用中，Ant对比Gradle，其实有如下几个优势：
1． 编译速度快
2． 资源占用少
3． 对系统硬件要求低
4． 不须要改变在Eclipse中的代码目录结构
可是，随着Google宣布再也不支持Eclipse SDK开发模式，愈来愈多的开源项目使用AS进行开发，使用Ant构建工具没法兼容Github上的优秀开源项目，并且维护以前的项目结构，对于新入职员工在AS搭建环境有必定的学习成本。考虑到将来AS是主流开发工具，Gradle也是AS主流的构建工具，咱们选择原生的AS开发之路。
制定项目代码规范/Code Review
对于大多数Coders来讲，最痛苦的莫过于修改别人写的代码，填别人挖的坑。
随着项目组同伴愈来愈多，咱们参考了网上不少资料，结合现有的项目风格，制定了一份比较完整的代码规范说明书1.0 bata版本，这里要特别推荐阿里发布的《阿里巴巴Java开发手册》(v1.0.2版)。
下载网址在这里：https://yq.aliyun.com/attachment/download/?id=1186
固然，仅仅有代码规范是不够的，怎么去执行，怎么去保证代码质量才是关键。好比：使用统一的代码编写风格，统一的缩进，相同Code Format 设置，方法名排序等。高度统一代码风格，能在进行代码修改的时候把代码不一样的部分降到最低，提供代码审查和后期维护效率。
提到Code Review 不必定是项目组的组长或者老大来作这件事情，每一个成员都应该有意识的去作，从Review本身的代码，到Review同时的代码，最主要的是要有写好规范代码的意识——代码不只仅是用来执行的，更是用来给你们读的。这里有一份清单能够供你们参考 [ 参考网址: http://blog.jobbole.com/83595/ ]：
代码审查清单常规项
• 代码可以工做么？它有没有实现预期的功能，逻辑是否正确等。
• 全部的代码是否简单易懂？
• 代码符合你所遵循的编程规范么？这一般包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
• 是否存在多余的或是重复的代码？
• 代码是否尽量的模块化了？
• 是否有能够被替换的全局变量？
• 是否有被注释掉的代码？
• 循环是否设置了长度和正确的终止条件？
• 是否有能够被库函数替代的代码？
• 是否有能够删除的日志或调试代码？
• 全部的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）而且进行了编码？
• 在哪里使用了第三方工具，返回的错误是否被捕获？
• 输出的值是否进行了检查而且编码？
• 无效的参数值是否可以处理？
项目核心模块重构
在4月份左右，产品业务的调整，项目核心模块须要进行调整，这时候咱们发现，因为在项目初期，为了快速实现，复用已有功能，把大部分功能相近的模块进行了继承。BaseActivity进行继承是一个不错的选择，可是对已经有完善的业务功能的Activity进行继承。在后期调整的时候，因为代码的高度耦合，任何一个在被继承的页面进行修改，都是牵一发而动全身，必须厘清全部方法和实现，每一步修改都是慎重又慎重。
既然有坑，就不能一直跳进去不出来。
咱们开始从基础的模块进行抽离，把能够进行复用的页面采用fragment进行重写。BaseActivity用来定义一些公共的方法和接口，例如网络状态检测、帐号有效期检测、数据状态显示、加载Loading动画等。
对应业务上能够进行复用的方法，咱们对类似业务进行抽象，定义了Manager进行处理，尽量的封装比较基础的业务。在系统架构上，咱们引进了MVP的思想，尽量的不在View（Fragment和Activity）进行数据操做和业务操做。
因为对数据操做的业务比较多，对于数据库操做保持操做模式下的单例，防止多个页面操做相同数据表致使数据混乱，而且完善离线数据保存功能，基础信息缓存机制。现有的架构依然存在不少缺点，可配置化程度低，代码冗余依然存在，受限于业务，整个系统架构还不是纯粹的MVP思想。将来，咱们想作的事情是，组件化与模块化。
组件化不是个新概念，通俗的讲组件化就是基于可重用的目的，将一个大的软件系统拆分红一个个独立组件。组件化的带来的好处不言而喻：
• 避免重复造轮子，节省开发维护成本；
• 下降项目复杂性，提高开发效率；
• 多个团队公用同一个组件，在必定层度上确保了技术方案的统一性。
项目模块化和组件化，也是我将来对Android开发进一步的思考和学习的方向。
项目核心数据操做接口化
项目中对数据库进行数据操做的场景比较多，并且咱们的数据同步机制，也基本上能知足在app端获取到服务器端大部分数据。
并且，咱们还有个比较贴心的功能——离线操做模式——容许用户在无网络状态下进行业务操做，固然这必然会产生业务数据，而后在联网状态进行数据上传和更新。
可是，这样的操做面临很大的风险，若是数据未上传成功，会致使app端和服务器端的数据不一致。可是，咱们的实际业务数据是以服务器端为准，这样对用户来讲，会产生很大的误解，甚至在涉及到核心数据的业务上，会形成系统级漏洞。
咱们从新梳理业务，对于大多数核心数据咱们会进行实时同步，数据展现也是根据接口返回数据为准。而且，采用和新的网络请求框架Retrofit+OkHttp，规范了接口定义以及数据加密等。
固然，咱们还作了不少的新的尝试，RecycleView替换了ListView，状态栏Immersive Mode设计，组件化开发的尝试，App功能动态化配置，通用自定义控件设计以及国际化设配等。
2017年，面临更多的挑战，而我会越走越远。数据库