一位Android资深工程师对移动端架构的思考 _Android

架构就像是一场进化史，根据不同时期的需求，演变出不同的架构，车轮滚滚，到今天，移动端框架百花齐放，让人目不暇接。但是其中的本质是磨灭不了的，换言之根本没有磨灭而是隐藏到了人们所看不到的地方，但是依旧发挥着不可或缺的作用。
为什么需要架构？1、一个Activity走天下，包含各种模块和功能
2、臃肿类太多
3、不同功能，不同层次拎不清楚，混合在一起
4、重复代码太多，复用性为差。
5、无法协作开发，
6、耦合严重，bug太多
等等
当我们新进一个公司，接受别人的项目的时候，基本都会说句MMP，SHI一样的代码啊，啥玩意啊，搞得什么啊。
我擦，我就改了一个参数，怎么全乱套了，一个功能怎么天上地下都需要改啊。
没有经受过痛苦的人，是不会想了解架构的，只有痛苦过的人，才会急切的了解架构，好好做人，不作孽。
进化1.0 MVC人们刚接触编程，相信第一个遇到的框架就是MVC，不管你经意还是不经意写出来的Android程序他就是MVC框架，只不过是MVC框架的某一个变种（最混乱的那种）。Android系统本身就根据MVC建造的。

XML的View层
Activity/Fragment的Controller层
数据Model层。

我们编写程序刚开始应该是这种结构

文章插图

View层和Controller交织在一起。在Activity里面处理各种事件和逻辑，界面的显示和更新都在这里，除了按功能分出去的模块外，能在Activity里面写的都会堆在这里面，代码常常达到上千行，别说别人，自己再回到头看的时候也是头皮发发麻。
所以我们开始试着学Android系统的MVC来梳理代码。当然每个人从众理解的也不大一样。
不管是单向依赖还是双向依赖都是为了把处理的职责交给Controller，这一点是不变的，所以不管你用的是哪一种形式都是不打紧的，没有对与错。根据自己的需求选择最适合的一种依赖关系。

文章插图

优点：
由于MVC很好的分离了视图层和业务层，所以它具有以下优点

耦合性低
开发速度快
可维护性高
易于理解

缺点：

由于MVC的设计思想是从Model出发，而没有考虑到View端的复杂性，这样导致的问题是Model难以符合复杂多变的View端变化。导致Model的作用很小，而很多View层的职责也转移到了Controller层。Controller变得臃肿不堪。耦合性也变高了。
测试困难

MVC使用的误区其实我在刚开始编程的时候，
误区一：一度认为Model就是实体类（Entity）
正解：是MVC的Model应该有两个功能：

处理业务逻辑
提供View显示的数据

误区二：把业务逻辑全部放在Controller端
正解：Model也会处理业务逻辑
这两个误区其实也和MVC的构成有关系，很容易让人误解，但是本质上还是不理解MVC，特别是对Model的作用不明白。
其实Model在MVC框架里面的作用不仅仅是Entry，Model在MVC中起着很重要的作用，它更应该是业务逻辑的真正实现层，而Controller层更应该作为一个桥接的作用，把View的求情转发给Model，再把Model处理结束的消息告诉View 。这样做也就是界面和代码（逻辑）分离。
进化2.0 MVP但是踏入误区的人太多了，大家都在Activity里面处理逻辑因为太方便了（写的很爽）。
但是这样之后，我们Activity的职责太多了，耦合也严重，所以我们就想着怎么能给Activity减负，同时把耦合也降下来，所以就想找个哥们来替Activity分担的责任，大家最后都只有一个责任，各层关系也相对好理解，大家照着这个方式写，那多好，不用加班，天天都很快乐。
既然Activty这么愿意和View搞到一起（解耦太高了），那么就让他们俩在一起（在一起，在一起，在一起），共同负责View，我们在招聘一个职业经理人（Presenter）来处理事务，有啥事都找Presenter，你看着多方便啊，MVP是一个真正意义上的隔离View的细节和复杂性的模式

文章插图

至于虚线的部分，这个和楼上的MVC的虚线一样，每个人的理解不同，情况不同，选择合适的就好，不用纠结谁对对错，本质不变就可以的。
这样就简单多了，Activity和View两人各种腻歪秀恩爱，各层的关系也一目了然，大家各干各的事情，想要什么和Presenter说一声，有啥事情Presenter也会汇报，简直爽的不要不要的。Presenter也会处理和View层的交互，Presenter在手天下我有。