参考文章：
https://juejin.cn/post/6854573206700130317

一、移动端架构设计到底做什么？
常规来看，基本就是MVC、MVP、MVVM以及组件化的东西，这些东西说是架构，但本质上就是模块化的变种，这类东西主要是做业务架构，将一个很大的业务划分为很多小业务，每个小业务就是一个模块。
另一部分架构内容则是技术架构，一般是分层的，最底层是基础框架，包括网络、存储、日志、图片加载等第三方库；中间层则是上层业务经过抽象后所形成的公共业务层，也可以叫做中台，这一块往往包含账号、支付、客服、地图等相对独立的业务；最上层就是核心业务了。从变动性来说，基础框架变动最低，公共业务层次之，上层业务变动最高。
总结来看：移动端架构 = 业务架构（模块化） + 技术架构（分层）

二、为什么要做架构设计？
主要总结为如下几点：
“为了让项目看起来更有技术含量”
“大家都做架构设计，我也得做”
“提高程序性能和可扩展性，降低后续的维护成本”
其实这些目标都比较抽象，不好衡量，做完架构设计后未必能达到预期。
举个例子，MVP特别流行，MVP的好处就是降低耦合，降低后续维护成本，但事实上，用了MVP后，代码极度膨胀，新增了很多类，代码可读性也差，很多新人上手困难，在一大堆presenter中迷失了，大家想想，这样做维护成本是否真的降低了？

三、架构设计的目标
为了寻找架构设计的目标，我们要寻找当前项目中的复杂度来源，也就是说看看当前项目中哪个方面最痛最急需改进，举个例子吧，像滴滴出行这种APP，复杂度来自于大量相似的业务线，而且这些业务线又是在不同的团队开发，那团队协作问题就极为迫切，那我们的架构就要围绕这个来。
换言之，架构设计的目标是解决当前项目的痛点，如果当前项目没有痛点，那就先别进行架构设计了。

四、如何做架构设计
架构设计要以实用为目的，不要光想着造一个世上最牛逼的架构，这样往往是不靠谱的，我们不是救世主。总结下，架构设计有三个基本原则：
1、合适优于先进
适合自己当前业务的就好，不要总想搞世界领先的架构，比如一个用户量100万的系统，光想着对标微信的架构，那微信日活上亿，适合微信的架构未必适合自己。
2、简单优于复杂
如同写代码一样，代码量越少越简单越好，架构设计也是一样，越简单的架构越牛逼。
3、演进优于一步到位
可扩展性我们当然要考虑，但是人不是神，无论你怎么去预测未来的系统演进，总是很大可能会失算。所以架构设计优先解决当下的问题，至于后来的问题，到时候再对架构方案进行改进。
架构设计还要考虑成本，你设计了一个很好的架构，但是需要投入20个人，还要项目停止2个月专门做架构开发，那这种成本就太高，很难推进。拿后端来举例，你设计了一个巨牛逼有效的架构，但需要1000台服务器，然后公司买不起这么多服务器，那也是白搭。
这三个原则也是有优先级的，具体是：
合适优于先进 > 演化优于一步到位 > 简单优于复杂
合适也就是适应当前需要是首位的，连当前需求都满足不了谈不到其他。架构整体发展是要不断演进的，在这个大前提下，尽量追求简单，但也有该复杂的时候，就要复杂，比如生物从单细胞一直演化到如今，复杂是避免不了的。

现在大家都对架构设计的目的以及是否需要有了进一步的认识，下面我们讲讲移动端的架构设计的实现方案有哪些。
上面讲了架构设计分为技术架构和业务架构，技术架构是基础，业务架构是基于技术架构之上的。
对技术架构进行分层：
最底层是基础框架，包括网络请求、数据存储、布局约束、bug检测、图片加载等第三方库；中间层则是针对当前项目的业务编写的工具类库，也可以叫做中台，这一块往往包含账号、支付、客服、地图等相对独立的业务，以及一些工具类：比如字符串、数组、字典的数据转换、系统UI层的一些类的扩展、加解密等等。

业务层：
就是MVC、MVP、MVVM以及组件化的东西，这些东西说是架构，但本质上就是模块化的变种，这类东西主要是做业务架构，将一个很大的业务划分为很多小业务，每个小业务就是一个模块。
最上层就是核心业务了。从变动性来说，基础框架变动最低，工具类库层次之，业务层变动最高。

关于业务层的架构设计可以采用MVC、MVP、MVVM或者是组件化，下面具体讲下几者的区别及用途：
https://www.jianshu.com/p/640352715b01