代码重构之路

来到了新的公司已经半年之久了，准确来说应该是163天，整个应用无论是层级还是架构，都已经被我全部翻新了，这一路走过来，有艰辛，有郁闷，当然还有快乐和成就感。

在此总结一下这半年的工作。也算是有所收获。

我们做的第一步就是拆:

首先来看一下我们应用之前的样子,和现在的样子的对比区别。

从这张图可以看出来以下几点区别

1.之前采用的是ant方式编译          <==>         现在采用的是gradle方式编译

这里倒不是说必须要将ant改为gradle，只是我觉得，gradle技术在android这里，已经成熟，而且功能扩展更加方便，

举个简单的例子，对multidex的支持，gradle两三行代码就能解决的，实用ant需要几百行(这里包括jar包，自己写xml等工作)

2.业务层级的拆分，之前的所有内容都是在一个层级，所有的业务都绑在一下，单存的靠文件夹来区分业务是不现实的，随着业务量的加大，与人员的引入，各个文件夹的业务差异会组建模糊，导致后期很难维护。所以我们讲业务逻辑拆分：

从整个架构可以看出来，sdk和thirdparty是整个架构的最底层，也是完全与业务逻辑没有任何耦合的部分，其中包括网络，json，DB，task，等公共业务逻辑

而base则是sdk的封装，这里面嵌入了一些业务逻辑，例如网络中一些统一的业务逻辑处理，exception，统计，基础base类等等。

再向上则是业务逻辑，这些业务之前没有任何耦合，可以以两种类型存在,一种是插件，一种则是module，这一层之间是完全独立的，他们只会依赖base层，这样模块之间耦合就会归为0，以后业务扩展将会非常方便，最上面是app，其实就相当有一个空壳，这一会存在的是进入各个业务的入口。

在从一层结构变成多层结构的过程是痛苦的，但效果也是最明显的，这里做的就是拆分业务逻辑，提取公共业务，如果将一个苹果，变成一盘漂亮的果盘是需要一定功力的，我总结的就是：胆大，细心，敢担当。

胆大:就是要大胆的改，不要因为这块逻辑影响比较重就不敢下手，万一引入side怎么办,不要想那么多，否则痛苦只会更长久

细心：这个的工作量很大，大量的copy，重名名，该文件，解藕，改动之大大到恐怖，一定要慢慢的，否则一旦一个copy错了，隐患是沉重的。

敢担当：不管再怎么细心，肯定会有遗漏的错误，一旦发生，勇于承认自己的错误，修复了就可以啦

这个时期过去，未来是很美好的

第二步:整

这里的整是业务整合的意思

由于我们第一步一景结束，第二步就简单多了，这里我们需要弄清楚我们的整个应用的主体是什么结构，MVC,MVVM,还是MVP，由于我们之前的采用的是MVC结构，但是命名方式是MVVM的，所以我刚来的时候，看着很郁闷，

最终我决定整个架构都改为MVP的

原因如下：1.MVC的业务逻辑，在android中，activity扮演了VC的双重功能，看到这里，你应该想一想你自己的应用是否也是如此，activity中即使view的承载者，有一一些控制的作用，这样导致activity很大，维护那是相当困难，

   2.MVVM和MVP都是很适合我们应用的解藕的，但是各人更喜欢MVP，因为看着更加清晰，而且V和M的捆绑需要加入一些额外的库，所以我选择了后者。

这里的结构弄清了，那么我们就要做一个框架和模版，让大家都按照这个规则来进行更改，那么我只需要在base层，写好我的BasePresenter，和IView接口，然后让所有场景都按照这个规则来做就可以了，但这是一个漫长的过程，

到现在还都没有全部替换。

注意：有些人觉得MVC，MVP这些都是框架层的东西，整个应用的框架是MVP，MVC,..但是实际上这都是很细小的东西，我们的每个业务，甚至每个页面都是一个MVP结构，当然你牛X的话，可以每一小块都是一个模式，但是为了应用的整体一致性，还是消停的统一吧

还有一点就是传统的MVP都是一对一的，根据业务的不同我们做架构的可以调整的，我们最终采用的就是一对多的，这样可以解藕更加彻底，增加代码复用率

第三步：删

其实在前两步完成之后，我们的应用已经从胖子，变成了一个瘦子，但是我们希望他更加完美，那就接来下做的就是取消没用的东西。

如今会联网快速发展，很多时候，从0到1可能只给你一个月的时间，这个过程中，就会引入各种因为时间限制而没有太大功能的代码。

怎么删呢，首先检查jar包，将一些没有用的jar包删除掉。这个简单，能够删除的也就是一些刚开始引入的，但后来功能删掉，但是jar包没有删掉的功能，

第二步，查找一些用的很少的jar包，(apache的包或java的包)，这些包一般我们使用了很少的功能，但是呢，这些功能都可以用android的库解决掉，这是我们就需要修改掉这些，然后删除掉jar包

第三步，资源，随着版本的叠加，很多资源都已经不用了，但是还在应用中，这时我们就需要清理掉这些包袱，（android-unused-resources这是一个开源的遍历库，可以使用它帮助你事半功倍）

第四步:性能

这个是所有同行都会提到的问题，关于性能方面的文章很多，以下是我有一点建议，希望以下几项都检查一下。

1.静态代码分析 会帮我们派出掉一些比较明显的问题

2.应用启动线程的多少与主线城中的工作会直接影响我们应用的启动速度

3.MTC工具的使用

第五步：引

这里的引指的是当前的最先进的技术，我们引入的是一热补丁，插件，等技术的引入，主要是帮助我们实现快速的版本迭代。

这里是我这几个月做的事情。

下面再分享一下这其中的总结：

不要重复造轮子：这个是软件开发界内公认的准则，这里我只同意在应用内部不要重复造轮子，但是是否我们应该完全引用第三方库来实现我们的功能，这一点我是不太赞同的，

确实很多开源的软件:volley,imageLoader,AsynHttp,fastjson,fesco,andfix,dexposed等等，这些相信都是大家在使用的一些开源的库，有的人建议直接使用，不要更改，

我觉得这个需要区别对待，我们在业务需求的时候，经常发现这些库有时无法满足我们的需求，怎么办？打补丁？确实是一个治标不治本的策略，但是我希望大家能够在使用的时候，能够吸收里面优秀的东西，而去掉一些冗余的东西，

就像volley网络请求方便，但是文件下载，和加载缓存drawable://，file://这些功能不支持，但这些功能我都想要，难道3个都引入？太浪费了，我们可以整合功能，保留一个，删除另外两个，

再比如andfix，不支持字段，不支持multidex，怎么办，认了？看看他是怎么实现的，抄一个，然后讲过他不支持的功能，想办法加上。

当然如果你看不懂人家代码怎么办？我只能告诉你 "学习吧"