面试中常常会有一些问题，信任我们也都遇到过

例如：

看你重构过代码，问你怎样重构的，为什么要重构

你知道什么是mvc、mvp等事务架构，你的项目中运用的是哪一个

你觉得技能重要仍是事务重要

不仅只在面试中，在实际工作中，信任大多数的Android程序员也都在迷失在众多的事务中，在一次次和产品的battle以及需求的deadline中丧失了对一个好的事务架构的考虑，什么扩展性、通用性、解耦都不重要了，重要的是明日提测.

做技能方向的和做事务方向的，哪个愈加“巨大上”呢

咱们也常常听到类似的话，一直写事务代码技能水平是不或许进步的，也常常对根底架构组的同学充满了仰望，觉得他们都是大神。

是的，曾经我的主意也是这样，常常看许多技能视频，想着进步技能，逃离无聊的事务。

进步技能当然没有错，其实事务也没有低人一等，在大多数公司或许说一切的情况下，事务才是底子，事务才是一个公司是否能够长期发展的筹码。关于个人来说，纯技能大神许多，可是具有杰出的事务思维，能写出优异的事务架构代码的人，很少。

这种事务能力强的人，才是公司真正大量需求的，也应该是一个程序员的应该具备的基本。

再说一个“题外话”，“年少无知”的咱们只单纯的羡慕根底架构组的技能,却不知道他们压力。做事务的同学，大都是产品经理喂饭吃，不怕“饿死”，只怕工作量太大。而纯做技能的同学呢，大多数都是自己找饭吃，尤其是在今天Android运用在各个方向的优化都已尽头，想再找一个优化点去打破，很难，所以现在呈现了许多黑科技，乃至是对虚拟机的hook，种种的黑科技看似是一种巨大上的技能追求，实际上是一种压力、无法，要不没饭吃，没绩效

那怎样写好事务代码，培育事务思维呢

抛砖引玉，希望看到此文章的同学，能给出更多有价值的考虑或自身的领会

大致能够从以下几个方面去考虑

  • mvc、mvp、mvvm、mvi等事务架构的挑选

这些事务构架其实都是在想要处理日渐添加的杂乱的事务需求与怎样更好的更新界面（view）之间的矛盾

  • View的组织形式

何为view的组织形式呢，简单点解说也便是用一种什么样的办法将各个view组合成一个完好的页面，当然把一切的view都堆积在一个 xml里边，也是一种办法，只不过这样的话你的xml会超越几千行哦

  • 怎样高雅的进行数据通信

数据通信首要包含两个方面，怎样给view传递数据，更新view，这块其实和（mvc、mvp等架构的想处理的问题是一样的）; 另一方面便是模块间或许类与类之间的数据传输了

  • 承继与组合

原本想从规划形式的角度去写，又感觉规划形式太大了。事务的添加离不开承继，可是一味的用承继真的好吗，能够测验下组合，会有很好的作用

  • 事务思维

这个事务思维怎样说呢，一些招聘简章上有这个词【事务 sense】，我是以为这个很重要，不论是在处理问题和分析问题上面，仍是在需求评定、测验用例评定，仍是在实实在在编写代码的逻辑性上面都会发挥很大的作用。用一句话总结便是有事务 sense的人，会让人感觉沟通很顺利，思路很清楚，考虑很全面

下面将会从以下方面逐一打开来说说什么样的代码是好代码

（本文不会纠缠于技能细节，仅从一个比较大的一个角度去表达些什么）

事务架构 mvc、mvp、mvvm、mvi 究竟怎样挑选

我习惯上先说定论，再根据定论去打开

当然这个定论仅仅是我个人的一个考虑，由于好的程序，好的架构有千千万

一个综合大型的app，例如抖音、小红书等这些事务架构（mvc、mvp、mvvm 乃至mvi），肯定都在用，不会单单选其中一个，比方A模块的B事务用的是mvc，相同模块的C事务就用的mvvm，这些架构思维的合理混合运用才是一个更好的挑选。

那关于某一个事务或模块怎样进行挑选呢

那就需求先大致说说每个架构的运用场景（本文不纠结太细的完成，只根据其思维去打开）

android事务代码一般分为4个部分 : View的更新、纯事务代码逻辑、View的点击滑动等事情的分发（用户操作）、网络请求逻辑

这些事务架构基本围绕着怎样更好的解耦、扩展而去去编排这些模块的编写以及之间的通信。就像咱们在写需求时，常常会喃喃自语，我的这个逻辑应该怎样写，写到哪里比较好呢…..

mvc

定论 ： 在我看来mvc在Android上的运用，都不应该算作一个架构思维。

在Android的事务中，一般Activity或许Fragment充任多个人物，View的更新逻辑，事务代码的处理逻辑以及View的点击等用户操作的逻辑，有的乃至网络请求也都会在里边。

这其实便是mvc的基本思维，就像东北乱炖、大锅菜。

长处：

代码编写很便利，几乎一切的逻辑代码都写在一个类中（Activity或Fragment），不必关怀类之间、模块之间的数据通信，能够直接更新view，很便利

缺陷：

Activity或Fragment代码量会暴增，后续有bug很难排查、想优化无法下手、想添加需求只能继续堆积

那什么场合适宜用它呢 ，我以为

  • 有些专门在debug包下用来测验的页面，能够用这种。

测验页面一般事务比较简单，和事务耦合几乎没有，后续的代码扩张也应该比较清楚。

  • 假如某个事务模块区分的很独立，为加速代码编写、削减无用的数据通信，其实也能够直接用mvc

当然事务模块的独立，或许不单单指的是产品或需求逻辑上的独立，更多的是整体的代码架构，一个好的整体的代码架构能够使每个事务代码都在不经意间保持必定的间隔，间隔发生美嘛～

至于怎样规划这个“好架构”，会在下节的【View的组织形式】中论述。当view组织的很好时，mvc也能够常常用

可是实际情况是什么呢，我想我们都知道，看看自己的某个类，某个Fragment 的代码量，有的都超越了5000行！

mvp

mvp的运用仍是比mvc愈加广泛的，假如要在mvc和mvp中必定要选其一运用，必定是mvp

在Android事务中，mvp思维相对mvc来说，多了一层P层，也便是接口以及其完成层，正是由于这个接口层，将View的更新逻辑与冗杂的事务代码的处理逻辑分开了

这便是mvp的基本思维（接口思维），为了处理mvc大乱炖的乱象，mvp将事务处理代码放到了完成层，减轻了view的主类（Activity或fragment）的负担。

长处：

经过添加接口，完成了职责别离，易于模块化，可有效运用对需求的快速添加，可维护性，扩展性都很好。

缺陷：

  • 正是由于多了接口层，代码量和开发时刻或许会添加，需求处理view与事务的数据的通信。
  • 当然等需求大迸发时，接口数量、接口的完成以及接口的“递归”调用深度也会越多，在排查问题时，想要找个某个具体完成和调用顺序就会变的适当困难了

不过相对古代Android开发，现代Android开发关于view的更新处理很少用mvp思维了，由于有了更先进的更新 mvvm（mvi）。不过关于sdk，aar等独立模块的开发，仍是需求经过接口的方法，由于接口愈加通用。

实际情况是什么呢，有同学已经有意识到mvc不适用于杂乱的大型页面，开端用mvp重构，单纯的将冗杂的事务剥离出去，目的不是为了模块化，而仅仅是为了削减主类（Activity或fragment 的负担，当作了对主类的一个代理 ，这种其实不能算作一个适宜的mvp改造。

mvvm

在Android事务中，一直在探索怎样愈加高雅的更新view，跟着呼应式编程思维的逐步在Android事务中生根，许多优异的框架被引进到Android，比方Rxjava。这种思维能够使得view的更新和呼应能够脱节接口的捆绑，view能够自动通知事务层，也能够很便利的收到其数据的改变

LiveData诞生了！

  • 有面试题会问：LiveData为什么只能运行在主线程中，由于LiveData的呈现便是单纯的为了更新ui，而更新ui只有在有在主线程中进行才是合法的。
  • 当然现在也呈现了许多LiveDataBus进行数据通信，如同像是针对 EventBus。
  • 有的直接用LiveData来进行数据通信，而非用于ui更新。可是有一个问题需求注意，原生的LiveData是具有粘性的，在某些非ui更新的场合，或许会收到历史脏数据，导致事务bug的问题，所以有同学以为这是LiveData的bug。

而我以为（也不能说是我以为，应该说是谷歌的目的），LiveData的目的便是单纯的来保障ui界面的正确、实时性，包括Activity销毁重建时，也要保证UI 不会呈现异常。LiveData和ViewModel的合作就能够完美的做到这个。

这便是MVVM,经过呼应式编程思维 来使得View的更新逻辑和事务逻辑处理解耦

长处：

呼应式的架构长处很明显，就不说了

缺陷：

缺陷也是有的，我这儿说两点（我也只会这些了）

  • 假如运用LiveData和ViewModel的架构，假如view的状况比较杂乱，ViewModel中的LiveData数量能够会许多
  • 每关于一个View状况，或许需求两个LiveData，一个用来写，一个用来读。这样能够保证view状况的改变源单一，可控。

当然，实际情况下，我们都会觉得麻烦，直接用一个public 的可读可写的 LiveData，其实我觉得勉强也能够吧

虽然呼应式思维不算是一个新鲜事，可是我信任，许多同学对此还不是很清楚，不论怎样样，先用起来，用上它，不必太操心就能写出比mvc、mvp愈加优异的代码。

MVI

MVI与MVVM相对比就比较暧昧了,它是在MVVM的根底上改造的。只不过多了一个状况机器的概念。

将View的点击滑动等事情的分发（用户操作）转化成一个目的（其实也是把动作封装到一个类中），把View的更新逻辑规划一个状况。

标准的demo型的MVI代码我还没写过，这个东西相对mvvm仍是比较新的。不过类MVI仍是常常写的，我信任许多同学也写过。便是当一个View的状况比较多时，假如单纯用mvvm，livadata确实会比较多，假如把view状况的枚举全都归于一个State，然后机会这个State，去更新view，那么需求一两个livadata就能够了。

同样的

这些事务架构，咱们也不有必要拘于其教科书式的写法去写代码， 只需求去抓住其中心思维，灵敏运用，再加上对事务未来的一个预判以及后续的调用方法，信任写出来的代码不会很差。

除去这些事务架构，咱们还应该重视View的组织形式。假如说mvc、 mvp 、mvvm等架构的重点都在于繁琐的事务代码应该写在哪里，那么View的组织形式更多在于怎样再view层次去再次解偶事务逻辑，或许说的比较抽象。下一节将具体对其解说。

View的组织形式

待定

数据通信怎样挑选 LiveData，LiveData 合作ViewModel、EventBus、接口、单例（静态）办法传递、Rxjava、flow

待定

承继 VS 组合

待定

事务思维

待定