某某宝原始整个团队被挖走，而我们又是被挖去进去填坑的。一批人走，另一批进来的总要搞点新花样。对于Android客户端App，如果服务器架构变化、数据格式变化，那一般情况非重构不可，要不然在原先的基础上进行修修补补，终究会把坑填的越来越大。幸运的是，服务端方面并没有架构或者请求数据格式等的改动。因此Android客户端App是否重构变成工程本身是否到有必要重构的地步。重构的工作，会看重更高性能、高可用，高扩展。基于这三个方面，首先先审判以前团队做的App是否满足这三方面，不满足的话，是烂成什么样，7分以上可以暂时接受，7分以下，还是有必要去做。在旧版本中，存在以下几个方面的问题：
性能问题上：启动性能问题、Activity错综的堆栈管理问题容易导致泄漏、内存泄漏问题，Activity的context的全局静态化问题、session丢失，session串联频率高发；
可用性上：没有可控的恢复兜底、没有做降级处理、没有对异常产生做补偿、交互体验上存在不足，登录页面跳出轨迹异乎寻常等，这是在APP使用上的可用性。在APP开发使用的可用性上，统计信息不全、业务出现问题不易跟踪，没有全局的log，只能等待服务器的日志接口调用，查找问题受干扰较大；
扩展性上：没有充足的中间件基础、公共组件工具碎片化、业务逻辑碎片化、重复业务逻辑出现频率高，各个业务逻辑串联不易维护等等。
如此种种的不足，于是一个基于渐进式组件化的重构化就此展开。重构不是一窝蜂的重启一个工程，然后从0开始，在移动互联网快速迭代的要求下，这是不符合实际的。而在一边开发新需求，一边渐进式的开发新组建，并在迭代期内做组建和需求的同时验证，这是符合我们的开发流程的，因此也称为渐进式组件化重构。
基于此，提出一种一切都是组件（服务），采用分层的框架思想。主要思想如下：
1.如关于日志服务，成立日志组件，提供日志服务，组装日志所需的服务管理，既链路有：存储---->Log Service ---> Log Manager ---> 调用。
2.同理，如网络服务，成立网络组件，提供网路请求服务，组装请求所需的网络代理管理，既链路有：缓存（本地存储）----> 网络服务（自己定义或第三方框架，如retrofit+okhttp）----> Proxy Manager -----> 调用。
3.再看具体业务功能，这里实际属于框架上层。业务功能会使用到其他基础业务组件，因此最普遍的基础工具组件需要先组件化成型，如log，网络，路由，配置。接下来渐进组件化业务功能，如从登陆功能开始，形成登陆组件，web组件等等进行渐进组件化。
整个重构方案到完全组件化，大概花了4个半月的时间。在这其期间，包括热修复、异常恢复、下发配置、导航跳转路由、组件路由等组件的开发。接下来会大概给出一些中间件的思路，其中有用到开源的第三方库也会大概分析下思路或者原理。
