Android项目架构演进的思考与总结

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年，面临更多的挑战，而我会越走越远。