两年的Android成长之路（一）

前言

又是一年，毕业就成了名副其实的程序员。两年多Android开发，从最初的小白，到现在可以自己设计一些东西；从最初面对需求的茫然，到现在游刃有余，一路的成长和成果，到此做个小结。大牛可以略过，希望能对刚刚踏上Android这条路的同学有一点点帮助。

Android架构的演进（一）

一、架构v0.1（假装有架构）

1. 最初刚工作时，独立开发，并没有想太多(也不懂)，项目紧，任务重，很多东西都是自己看着人家的照葫芦画瓢，可以说并没有什么架构，但是对于当时一开始的业务还是能应对的了的。
   网络连接利用HttpClient自己封装了一套，应对当时的项目体量还是可以，并且也做到了一些常规的功能，例如线程的变换、数据的解析这些常用的功能；图片加载在ImageLoader的基础自己也做了一层封装，应对固定的占位图等。很多这种小的功能组件都是哪里用复制到哪里，虽然麻烦，但是能解决问题。
2. 很快，随着开发进行和业务增长，问题开始出现了。

1）代码太乱
没有合理的封装和抽取，没有对业务功能进行划分，没有清晰的代码约束等等直接导致代码自己都懒得看，一团乱麻；
2）封装的组件难以满足业务需求
最致命的是对于业务开发需要不断的从复制出来的代码上进行更改，以及一些自己写的组件很难满足业务需求，导致开发进度慢，功能实现吃力，到此已经表现出力不从心；
3）代码耦合严重
Activity直接承担了所有业务逻辑实现，组件和业务耦合在一起，没有做区分，可重用的组件很多都是复制过去的，修改起来相当费劲；
4）部分技术实现很业余
对于一些业务的技术实现采取了很多不合理的解决办法，直接导致代码可读性太差，很难理解实现原理；
5）开发新应用需要从头来过
当公司需要开发新的应用时，另一问题就出现了，一切都需要从头搭建，因为很多组件都和业务耦合在一起，没法直接拿过来用；
6）整个项目是拼拼凑凑，哪有漏洞堵哪里，没有任何章法。

二、架构v0.2(好像有架构)

1. 问题和痛点都找到了，开始重构

1）启蒙项目
IOS同事肖伟肖大神推荐了给我Coding
Android端开源项目，看完这个开源项目，虽然懵懵懂，但是也有茅塞顿开的感觉，原来还有那么多的开源框架可以使用，而且在代码的书写上也有很多新的认识，至此，初步懂得如何站在巨人的肩膀上去实现自己的目标。所以，多看他人的项目对自己成长很有帮助，特别是初学者。
2）技术选型
因为之前都是自己封装的组件，所以很多东西做的并不完善，这次选择开源成熟的框架。
整个技术选型基本上分为：网络连接库、图片处理库、数据库操作框架、UI控件、工具库等。
网络框架选用Volley，因为Volley对于初学者，使用简单，功能齐全，入门较容易，并在这之上做了一次中间层的封装，方便对网络框架的替换和统一的功能的实现。
图片加载还是选用的ImageLoader，并没有太大变化，但是对内存进行了优化。 数据库那时候还没有过多使用，所以这块忽略。
3）代码划分
代码主要分为了业务代码还有可以复用的代码。
业务代码主要按业务模块进行划分，这样的好处就是当前业务内的代码都在一起，管理方便，并且查找维护更加容易。
4）业务实现
在实现业务时，考虑的要更加全面，比如有没有更好的实现方式，业务代码能否复用，怎样实现能更好应对一些需求的变化等。

2.重构完成后新的问题

1）仍有大量可以封装抽取的代码
比如：网络请求的进度窗，错误回调的处理等
2）业务实现仍有可以优化的空间
比如：登录模块的登录和退出在整个应用任何一处都有可能调用，这样如果只是实现了登录页面的登录，那么在其他地方需要登录时还需要再次实现，退出登录更是如此，所以如何将业务拆分成可复用的代码块又是一个可优化的。
3）业务代码和组件代码仍有大量耦合
虽然开发前的规划已经想到要避免，但是实际开发中难免还是会出现，开发过程中会发现，有很多业务上的代码如果放到了组件中去处理，那么整个复杂度会降低很多，并且实现起来也容易很多，然后这将是最大的大坑，因为当组件需要多次复用时，这些业务代码将成为绊脚石，所以谨记，不要因为时间紧任务重而降低代码质量；还有其他的耦合也可能是设计上的缺陷，导致一部分业务代码一定要放在组件中。
4）架构不够稳定，问题频发
开发过程中的技术调研和技术方案的确定十分重要。例如：应用中的红点存储方案的不合理，将会给整个应用的开发带来非常多的不稳定，因为类似红点这种东西，可能出现在整个应用的任何地方，并且很可能是嵌套计数的，很多业务功能都有这种特性，所以如果没有制定好技术方案，整个后期维护和扩展会有很多壁垒。
5）问题难以定位和修复
代码的严谨并且逻辑足够的清晰，整个实现有路可寻，那么问题定位就要容易的多，如果实现混乱，可能导致问题出现的地方过多，将给问题定位带来极高的难度，并且修复时很可能不能全面修复和引发新的问题。代码的耦合也会是问题定位和修复的障碍，并且没有任何的设计模式，也会导致个别类的的体量很大，可读性很差。

3.随着学会的东西越来越多，再次重新设计架构势不可挡。
最新的架构将写在下一篇博客，并且是更偏向技术的博客，本篇博客作为成长历程的博客，很多东西记不清，写不全，欢迎提出问题。