最近很多文章都在谈移动端的架构，在早些年的时候，移动端是没有所谓的架构可言的，很大的原因是因为移动端开发刚刚兴起，刚刚兴起意味着“代码存量少”，意味着软件复杂度相对于传统的服务端开发更低。但是最近越来越多的人谈到软件架构很大一部分原因是移动端经过十年的积累，诞生了越来越多的大型App，业务发展越来越快，例如微信、支付宝、天猫之类的App。 正因有越来越多的大型App，业务越来越复杂。快速发版，快速运营需求越来越强烈，对移动端要求更加偏向于前端化，因此各种快速开发框架层出不穷，RN、Weex、Flutter。同时为何更好的组织移动端的代码，将传统的软件架构移到了移动端开发上面，从最开始的mvc到mvp、mvvm,以及综合各种概念的clean架构。

更多内容: CO-有面试上CO (baidu搜索)

业务即架构

很多人在开发伊始就开始想着后期要怎么扩展，设计无比复杂的架构，最终导致开发起来非常痛苦，为了实现一个功能，写各种各样冗余的类，做各种各样重复的事情，导致效率低下，“过度设计”是架构设计可能犯下的第一个错误。

如何做恰当的架构设计？自己实践经验来看，第一步先不用去考虑你需要什么架构，而是应该思考你这个项目的核心业务是什么，再考虑为了实现这个核心业务，最大最重要的技术点是什么？ 德鲁克管理一书中有一句话：围绕着价值最大的点去设计流程。

同样道理，围绕着最核心的业务、最核心的技术点去设计架构才是最重要的。

对于一个以H5为主的App，你最重要的架构设计是设计好H5和原生的交互方式，如何快速的加载出H5页面。 对于一个以主要以图片加载为主的App, 最重要的核心技术点就是大量图片的加载，好的图片加载框架，项目已经成功了一半。

对于一个本地数据库为主的App，如何设计好本地数据库的读取和存储，如何选择一个适合的轮子去处理好数据库存在的问题，才是最根本的架构设计。

我见过一些项目，最表层项目结构设计的很好MVP+RxJava，但是最重要，最核心的数据库模块还是古老、低效的设计，导致的结果就是，涉及到核心的数据库操作就麻烦、复杂、低效。甚至出现整个项目组只有一两个人能看明白最核心的代码，这样下来无论是最外层的架构设计多么NB，整个项目是低效的。没有从最开始的时候设计好核心东西的架构设计，没有在开发过程花力气去优化最核心的模块。

最简单的就是最好的

我一直认为，最简单的东西往往最有力量。

比如 首付5成，贷款加息50% 越多的解释，就显得心虚，解释就是掩饰。架构设计也是如此，越是简单的架构设计，越容易学会，合作的同事越容易接受，就像代码设计，自解释的代码比写满了注释的代码设计的要更好。

clean架构为什么不容易流行，因为太复杂了，它把Java Web开发那一套搬到了移动端，如果应用到项目中，可能除了架构设计者，没人能够完全明白整个架构设计。

相反，为什么MVC 和MVP容易推广，因为简单,可复制性强，无需思考，学习容易。谷歌官方开源了一套MVP架构设计思路，非常值得借鉴，除了写重复性代码多一些以外（重复性代码可以通过模板自动生成），代码易用性、维护性都是设计的典范。

代码逻辑守恒

架构设计中有很多的设计模式、固定范式大部分都是围绕着分层进行设计的 软件开发中没有什么问题不能通过加一层来解决的

分层思想其实契合人类对事物的认知模式，各司其职，分工不同，从传统农业社会的架构-士、农、工、商，每个层级负责对应层级的事情，每个层级有既有隔离又有沟通。 移动端开发也是一样，从大层级划分，可以划分为业务层、持久层、UI层，从细分角度来看，又可以分层各种组件类，比如网络、图片、缓存、日志等等模块，而通过对这些组件的的组合形成更大的模块。各个模块之间既有数据的传递和流动，又会对各个层级之间数据的传递做限制。最明显的例子MVP框架，P层作为沟通的桥梁，负责M和V层数据的交互，但是又限制V和M层直接进行数据的交互，这样很大程度减少了数据流向复杂的问题。 总之，我认为架构设计是对代码逻辑二次划分，代码逻辑永远是守恒的，差别在于你是如何管理这些逻辑的。

MVP管理逻辑的办法很简单，就是将所有逻辑放到了P层中，保持M层和V层的纯粹性，但是毋庸置疑P层是会随着业务逻辑的增加，复杂度会产生巨大的增长，因此这个时候就需要对P层在做逻辑的转移。因此在对P层逻辑转移过程中，就产生了各种各样的helper类，结合各种各样的网络处理框架、RxJava响应式编程框架等等，这些东西都是为了逻辑转移而做的工作。

这篇文章不谈具体的移动端架构设计，更多的是从架构本身聊一下关于架构设计的一些思想，以及在实践过程中的一些想法，一家之言，欢迎探讨。