本文出自门心叼龙的博客，属于原创类容，转载请注明出处。https://blog.csdn.net/geduo_83/article/details/88606548
昨天晚上一年一度的315晚会又来了，今年虽然没有哪家大公司上榜，但是曝光了一些黑心小企业，我们平时用的塑料盆、塑料袋、孩子的塑料玩具有可能都是用医疗废弃物，如输液袋、输液管、一次性注射器、血袋等加工而成的，还有平日孩子们抢着买的辣条这种混合了十几中添加剂的垃圾食品的生产环境着实让人辣眼睛，我们无比惊叹这些企业为了金钱、利益没有一点道德底线，等待他们的将是法律的制裁。
好了，我们言归正传，项目功能移植可以说在日常开发中很多时候都会遇到，把A项目中的几个功能移植到B项目当中，最近工作中就有这样一个需求，需要将公司的一个老项目的几个功能模块移植到新项目当中，一开始以为工作量不是很大，但是随着改造工作的深入，不得不改变原有的移植改造方案。
对，就是将一个老项目进行移植改造，说他老是因为这个项目从2014年就开始做了，直到2018年这个项目算是基本结束，整整做了4年多时间，现在隔三差五有些零星的小升级，这个项目可以说是我参加工作有史以来工期最长的一个项目，有人可能会问，多大的项目啊，尽然能做这么长时间？它是我公司一款核心主打移动app产品，随着用户需求的不断变化，功能的不断增多，做这么长时间，也就不足为奇了，我们天天使用的微信、支付宝哪个不是这样？
编码架构演变史:
原有项目工程架构为单一结构体项目，在这四年时间里，随着业务需求的不但变化，技术的更新迭代，导致了不同模块出现不同技术实现方案。从最开始的非标准的MVC架构，这种结构是最早些从事Android开发的人员通用的技术架构，有些人可能很奇怪，什么是非标准的MVC结构？因为这种结构Activity和Fragment即承担了View的角色又承担了Controller的角色，在项目开始的时候，我们不得不说，这种结构开发效率非常高，但随着业务功能的增多，导致整个Activity的代码量越来越多，使其变得极其臃肿。
为了解决Android开发中普遍出现的这种通病，2016年谷歌Android团队推出新一代Android应用编码架构MVP，一经推出就火变了大江南北，它将原来的Controller层进行了拆分，将一层拆分为两层：Presenter层和View层，这样一来我们整个Activity和Fragment工作量就减轻了不少，它只做View的工作，一些业务逻辑的工作就交给Presenter了。既然是google出品，必然是精品，为了顺应历史潮流，该项目在原有架构基础上也就引入了MVP架构，在研究了google MVP的demo后，我们发现能解决我们的大部分问题。
- Model: 数据层，负责与网络层和数据库层的逻辑交互
- View: UI显示层, 并向Presenter报告用户行为
- Presenter: 从Model拿数据，应用到UI层，管理UI的状态，响应用户的行为
但是随着时间的推移，产品中出现一些新的业务需求，现有架构的一些缺陷也逐渐暴露出来，比如常常有这样的应用场景：在上传图片的时候，首先要去请求Token令牌，客户端拿到了令牌时候再去上传图片，其问题的本质就行一个网络请求回来之后才能进行另外一个网络请求，直接导致的一个问题就是回调嵌套太多，代码逻辑不清晰，这样的代码难以理解而且不利于以后的维护，有时候进入一个界面的时候，同时要进行两个后者两个以上的网络请求，那么这时候就出现问题了，Activity数据显示不同步，多个网络请求同时进行，他们必然是异步的，既然是异步的，毫无疑问有的请求回来早，有的请求回来迟，界面上的数据必然会出现不同步。这时候RxJava出现了，刚刚接触RxJava的时候，的确被它强大所惊叹，能将原来复杂的业务逻辑变得如此简单，在配合上Retorfit那就是绝配，直接就解决了我们上面提到的问题，简易的接口配置，优雅的代码结构，强大的扩展支持深受广大开发者的追捧。
从MVC架构到MVP架构，再从MVP在到MVP+RxJava+Retorfit，也就是现在我们的项目里存在着三种编码架构体系。虽然编码架构移在变，但唯一不变的是项目一直都是单一结构体项目，它的弊端在我这里我就不讲了，如果感兴趣的可以阅读我的另外一篇文章：Android组件化方案最佳实践，https://blog.csdn.net/geduo_83/article/details/86604852
网络请求演变史:
网络请求作为一个APP项目最基本的功能需求，在我们项目里http也经历了四次更新迭代。从最开始行业通用的AsyncHttpClient框架，再到google官方推出的Volley，在到国内技术大神严振杰在OkHttp基础上封装的NoHttp，再到square公司开源的网络请求框架的终结者Retrofit。
基本组件Activity演变史：
关于Activity基类结构也有着两种不同的架构体系，一种是基于ActionBar的架构体系，随着ActionBar的弃用，诞生了另一种是基于ToolBar的架构体系。
这就是目前这个项目的基本架构，给我们最直接的认识就是，各个模块技术解决方案不统一，正是由于功能模块多，项目周期长，新技术的更新迭代快，有没有足够的时间进行重构改造，必然会造成现在的单一结构体项目的多架构问题。 现在要抽取几个功能模块，的确不是一件很容易的事。原本打算按照现有新项目的架构：组件化+MVP+RxJava+Retorfit重新开发一遍，最后我放弃了，因为有些模块有着大量的业务逻辑，这工期可不是一星半点，最后经过商议，采取了一种折中的方案，编码架构保持不变，维持原状，功能模块原来以包来划分，现在以组件的方式从新进行拆分，这样一来工作量就大大降低了。
方案定了之后，开始实施了，抽取了一个公共的Common库，其中包含了有网络请求组件和项目基础组件，要移植的模块的资源文件散落在整个项目的各个角落，然后就是施展我们的VC大法了，这可不是好差事，这一周频繁的使用VC大法，一致出现了眼花，手腕酸疼的感觉。
通过这次的移植改造，再次给我们警醒，一个好的项目架构多么的重要，架构不统一，技术解决方案不统一，多个模块各自为政，给后期的维护和改造、扩展将是灾难性的。我们不得不感叹，在软件开发行业不像医生、律师这些知识相对稳定的行业，软件行业的技术没隔一段时间就会更新换代，让你清零，所谓“活到老，学到老”，用到程序员身上在适合不过了。