我动了公司祖传的老代码…

在开发世界里，永远是技术至上，一门新技术的盛行总是有原因的，要么比老框架性能提升不少，要不更加易用等等。作为一个追求上进的开发者，就是要不断学习，尝试各种新技术。

APP自身在飞速发展，发展有两个方向：

1）死亡，我们的团队被优化；

2）版本不断迭代，新功能不断增加，业务模块数量不断增加，业务上的处理逻辑越变越复杂，同时每个模块代码也变得越来越多。对于app的不断壮大，这将引发一个问题，所维护的代码成本越来越高，稍微一改动可能就牵一发而动全身，改个小的功能点就需要回归整个APP测试，这就对开发和维护带来很大的挑战，更有甚者：一个app里面同质的SDK大量集成，最典型的就是网络SDK，一个App里面同时包含了Volley，Okhttp，Retrofit，其实，我们不想这样啊，我们是没办法才这样做的，因为，我们的app架构太混乱了，不敢动哦，有木有？

明明只改了一行代码啊…

事实上以下才是根本问题：

1. 代码量膨胀，不利于维护，不利于新功能的开发。项目工程构建速度慢，在一些电脑上写两句代码，重新编译整个项目，测试的话编译速度起码5~10分钟，有的甚至更长，Gradle老是和我们过不去。

2. 不同模块之间代码耦合严重，有时候修改一处代码而牵动许多模块，更不用说切换SDK了。每个模块之间都有引用第三方库，但有些第三方库版本不一致，导致打包APP时候代码冗余，容易引起版本冲突。

3. 现有项目基于他人项目基础上开发，经手的人次过多，存在着不同的代码风格，项目中代码规范乱，类似的功能写法却不一样，导致不统一，然后我却不敢动手推翻重来。

app重构后，系统更稳健了

如果之前app的架构无法满足现有的业务需求，我们该如何优雅地重构App呢？

从工作到现在，经历过了MVC、MVP、MVVM等，每个App由于项目特点和需求的不同，都会出现一套基于开发者所设计的架构模式，分层、组件化、模块化，每一种设计都是基于项目所在场景的，很难适合所有项目场景。

App 业务规模扩大，随之而来的是团队规模扩大，那就涉及到多人协作问题，每个移动端软件开发人员势必要熟悉如此之多代码，如果不按照一定的模块组件机制去划分，将很难进行多人协作开发；随着单一项目变大，而且Andorid项目在编译代码方面就会变得非常缓慢，在单一工程代码耦合严重，每修改一处代码后都需要重新编译打包测试，非常耗时。

模块化、层次化、控件化、组件化怎么应用到实践当中？Artifactory对模块化和组件化大有帮助；Jetpack可以有效减少OOM和No Pointer Exception；Mvvm则可以满足需求的变化。也许单个的技术点你了解过，我们又该怎样将Artifactory、最新的Jetpack和Mvvm结合呢？另外，如何在搭建app架构的同时，进行App启动速度的性能优化呢？

为了让大家掌握这些技能，我邀请了国防科技大学研究生、全球首批Android开发者Allen老师为大家带来《架构实战》系列直播课程，让大家从Mvvm高级实战开始，快速成长为移动端大神！