2024年安卓最全Github标星5(15)，阿里巴巴一面结果-CSDN博客

本文链接：https://blog.csdn.net/2401_84544752/article/details/138903997

最后

答应大伙的备战金三银四，大厂面试真题来啦！

这份资料我从春招开始，就会将各博客、论坛。网站上等优质的Android开发中高级面试题收集起来，然后全网寻找最优的解答方案。每一道面试题都是百分百的大厂面经真题+最优解答。包知识脉络 + 诸多细节。
节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

《960全网最全Android开发笔记》

《379页Android开发面试宝典》

包含了腾讯、百度、小米、阿里、乐视、美团、58、猎豹、360、新浪、搜狐等一线互联网公司面试被问到的题目。熟悉本文中列出的知识点会大大增加通过前两轮技术面试的几率。

如何使用它？
1.可以通过目录索引直接翻看需要的知识点，查漏补缺。
2.五角星数表示面试问到的频率，代表重要推荐指数

《507页Android开发相关源码解析》

只要是程序员，不管是Java还是Android，如果不去阅读源码，只看API文档，那就只是停留于皮毛，这对我们知识体系的建立和完备以及实战技术的提升都是不利的。

真正最能锻炼能力的便是直接去阅读源码，不仅限于阅读各大系统源码，还包括各种优秀的开源库。

腾讯、字节跳动、阿里、百度等BAT大厂 2020-2021面试真题解析

资料收集不易，如果大家喜欢这篇文章，或者对你有帮助不妨多多点赞转发关注哦。文章会持续更新的。绝对干货！！！

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

五、最佳实践

六、进阶与不足

前言

================================================================

2014年年底偶然得知在Android开发中出现了MVP这种模式，当时觉得这东西挺好，正好赶上公司要做一个新的小项目，于是尝试了一下。仿照网上的Demo分出View、Model、Presenter层，抽取View接口，看起来像那么回事的用MVP完成了整个项目。因为项目简单，期间也没有遇到什么坑，但是总觉得还有那些地方不对。当时网上一些关于Android MVP的介绍都有点浅尝辄止，一个登录或者根据地区查询天气等的小Demo，没有实际在项目中应用的示例，所以在用MVP做完一个小项目之后还是不敢在主项目中轻易尝试。首先，主项目比较混乱，改动起来工作量很大，而工期经常较紧，时间不允许；其次，知道自身对MVP理解还不够，怕掉坑里去；最后，也是最重要的一点，当时的项目不是按功能模块划分的包结构，如果改为MVP那是真的就回不到过去了。好了，废话不多说，今天主要是想分享一下，本人对MVP的浅见，以及如何使用MVP模式搭建一个项目框架。纯属一家之言，不足之处，请见谅。

一、什么是 MVP

=======================================================================

1.1. MVP 的定义

MVP，全称 Model-View-Presenter

要说MVP那就不得不说一说它的前辈——MVC。

MVC（Model-View-Controller，模型-视图-控制器）模式是80年代Smalltalk-80出现的一种软件设计模式，后来得到了广泛的应用，其主要目的在于促进应用中模型，视图，控制器间的关注的清晰分离。MVP（Model-View-Presenter，模型-视图-表示器）模式则是由IBM开发出来的一个针对C++和Java的编程模型，大概出现于2000年，是MVC模式的一个变种，主要用来隔离UI、UI逻辑和业务逻辑、数据。也就是说，MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。

说明：按照View和Presenter之间的交互方式以及View本身的职责范围，Martin Folwer将MVP可分为PV（Passive View）和SoC（Supervising Controller）两种模式。

Passive View

顾名思义，PV（Passive View）是一个被动的View，针对包含其中的UI元素（比如控件）的操作不是由View自身来操作，而交给Presenter来操控。

Supervising Controller

在SoC（Supervising Controller）模式下，为了降低Presenter的复杂度，将诸如数据绑定和格式化这样简单的UI处理逻辑逻辑转移到View中，这些处理逻辑会体现在View实现的接口中。

1.2. 发展历程

任何一种思想的产生都有其特定的背景，在软件开发中也是如此。在软件复杂度增长，需求不断变更的客观条件下，为了更好的解决这些问题，出现了各种软件架构思想、编程思想以及设计模式。（因为人的能力并没有“跟上”机器，所以才会出现各种模式、方法、工具等等来补足人的不足，以最大地透支机器性能。–Indream Luo）

相信做过客户端（PC、Android、iOS等）或者前端开发的童鞋都听过MVC、MVP、MVVM这些名词（就算不了解也大致知道有这个东西吧），这些都是为了解决拥有图像界面的程序开发复杂性而产生的模式。这里说的是模式，当然有各种各样的框架方便开发者在项目中应用这种模式，这不是本文重点。

有前辈（Indream Luo）说过，架构是对客观不足的妥协，规范是对主观不足的妥协。对此我深表赞同，先不管这些，我们来看看GUI是怎么和MVX扯上关系的。

先搞清楚一个顺序，是GUI应用程序的出现导致了MVC的产生。GUI应用程序提供给用户可视化的操作界面，这个界面提供给用户数据和信息。在PC上用户与界面的交互主要依赖（键盘，鼠标等。这些操作会执行一些应用逻辑，应用逻辑（application logic）可能会触发一定的业务逻辑（business logic）使应用程序数据的发生变更，数据的变更自然需要用户界面的同步变更以提供最准确的信息。在开发这类应用程序时，为更好的管理应用程序的复杂性，基于职责分离（Speration of Duties）的思想都会对应用程序进行分层。在开发GUI应用程序的时候，会把管理用户界面的层次称为View，应用程序的数据为Model（注意这里的Model指的是Domain Model，这个应用程序对需要解决的问题的数据抽象，不包含应用的状态，可以简单理解为对象）。Model提供数据操作的接口，执行相应的业务逻辑。有了View和Model的分层，那么问题就来了：View如何同步Model的变更，View和Model之间如何粘合在一起。（所谓的MVX中的X都可以归纳为对这个问题不同的处理方式）（引自：戴嘉华）。

MVC 的产生

早在上个世纪70年代，美国的施乐公司（Xerox）的工程师研发了Smalltalk编程语言，并且开始用它编写图形界面的应用程序。而在Smalltalk-80这个版本的时候，一位叫Trygve Reenskaug的工程师设计了MVC图形应用程序的架构模式，极大地降低了图形应用程序的管理难度。而在四人帮（GoF）的设计模式当中并没有把MVC当做是设计模式，而仅仅是把它看成解决问题的一些类的集合。Smalltalk-80 MVC和GoF描述的MVC是最经典的MVC模式。

看到这服务端的童鞋有话要说：我们也用MVC，你看Structs、SpringMVC这些都是经典的MVC框架。那服务端的MVC和GUI开发中的MVC有何不同之处了，请看下面的分析。

MVC Model 2的出现

在Web服务端开发的时候也会接触到MVC模式，而这种MVC模式不能严格称为MVC模式。经典的MVC模式只是解决客户端图形界面应用程序的问题，而对服务端无效。服务端的MVC模式又自己特定的名字：MVC Model 2，或者叫JSP Model 2，或者直接就是Model 2 。

好吧，说了等于没说，总之一句话，我们今天所说的MVX都有一个前提，那就是得有GUI，得是来解决GUI应用程序开发中遇到的问题的。所以，我们只要关心最经典的MVC就可以了，想了解更多的请自行Google。

MVP 的产生

MVP模式是MVC模式的改良。在上个世纪90年代，IBM旗下的子公司Taligent在用C/C++开发一个叫CommonPoint的图形界面应用系统的时候提出来的。

MVVM 的产生

MVVM模式最早是微软公司提出，并且了大量使用在.NET的WPF和Sliverlight中。2005年微软工程师John Gossman在自己的博客上首次公布了MVVM模式。

1.3. 为什么需要 MVP

（以下内容参考自：MVP在Android平台上的应用，原文作者konmik，译者MiJack）

理由1：尽量简单

如果你还有读过这篇文章，请阅读它：Kiss原则（Keep It Stupid Simple）

大部分的安卓应用只使用View-Model结构

程序员现在更多的是和复杂的View打交道而不是解决业务逻辑。

当你在应用中只使用Model-View时，到最后，你会发现“所有的事物都被连接到一起”。

如果这张图看上去还不是很复杂，那么请你想象一下以下情况：每一个View在任意一个时刻都有可能出现或者消失。不要忘记View的保存和恢复，在临时的view上挂载一个后台任务。

“所有的事物都被连接到一起”的替代品是一个万能对象(god object)。

god object是十分复杂的，他的每一个部分都不能重复利用，无法轻易的测试、或者调试和重构。

With MVP

使用MVP

复杂的任务被分成细小的任务，并且很容易解决。越小的东西，bug越少，越容易debug，更好测试。在MVP模式下的View层将会变得简单，所以即便是他请求数据的时候也不需要回调函数。View逻辑变成十分直接。

理由2：后台任务

当你编写一个Actviity、Fragment、自定义View的时候，你会把所有的和后台任务相关的方法写在一个静态类或者外部类中。这样，你的Task不再和Activity联系在一起，这既不会导致内存泄露，也不依赖于Activity的重建。

这里有若干种方法处理后台任务，但是它们的可靠性都不及MVP。

1.4. 为什么 MVP 是可行的？

（以下内容参考自：MVP在Android平台上的应用，原文作者konmik，译者MiJack）

这里有一张表格，用于展示在configuration改变、Activity 重启、Out-Of-Memory时，不同的应用部分会发生什么？

情景 1: 当用户切换屏幕、更改语言设置或者链接外部的模拟器时，往往意味着设置改变。相关更多请阅读这里。

情景 2:Activity的重启发生在当用户在开发者选项中选中了“Don’t keep activities”（“中文下为不保留活动”）的复选框，然后另一个Activity在最顶上的时候。

情景 3: 进程的重启发生在应用运行在后台，但是这个时候内存不够的情况下。

总结

现在你可以发现，一个调用了setRetainInstance(true)的Fragment也不奏效，我们还是需要保存/恢复fragment的状态，所以为简化问题，我们暂不考虑上述情况的Fragment。Occam’s razor

现在，看上去更舒服了，我们只需要写两段代码为了恢复应用：

· 保存/恢复 for Activity, View, Fragment, DialogFragment;

· 重启后台请求由于进程重启

第一个部分,用Android的API可以实现。第二个部分，就是Presenter的作用了。Presenter将会记住有哪些请求需要执行，当进程在执行过程中重启时，Presenter将会出现执行它们。

1.5. MVP 的优缺点

任何事务都存在两面性，MVP当然也不列外，我们来看看MVP的优缺点。

优点：

1. 降低耦合度，实现了Model和View真正的完全分离，可以修改View而不影响Modle

2. 模块职责划分明显，层次清晰（下面会介绍Bob大叔的Clean Architecture）

3. 隐藏数据

4. Presenter可以复用，一个Presenter可以用于多个View，而不需要更改Presenter的逻辑（当然是在View的改动不影响业务逻辑的前提下）

5. 利于测试驱动开发。以前的Android开发是难以进行单元测试的（虽然很多Android开发者都没有写过测试用例，但是随着项目变得越来越复杂，没有测试是很难保证软件质量的；而且近几年来Android上的测试框架已经有了长足的发展——开始写测试用例吧），在使用MVP的项目中Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter应用逻辑的正确性。

6. View可以进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做到高度可复用的View组件。

7. 代码灵活性

缺点：

1. Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

2. 由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。

3. 如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。

4. 额外的代码复杂度及学习成本。

1.6. 小结

在MVP模式里通常包含4个要素：

(1) View :负责绘制UI元素、与用户进行交互(在Android中体现为Activity);

(2) View interface :需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试;

(3) Model :负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合);

(4) Presenter :作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。

�

二、MVX 剖析

======================================================================

2.1. M（Model）

模型：表示数据模型和业务逻辑(business logic)。模型并不总是DataSet，DataTable之类的东西，它代表着一类组件(components)或类(class)，这些组件或类可以向外部提供数据，同时也能从外部获取数据并将这些数据存储在某个地方。简单的理解，可以把模型想象成“外观类(facade class)”。译注：这里的外观是指“外观模式”中所说的外观。外观的一般作用是为一个复杂的子系统提供高层次的简单易用的访问接口，可以参看下面的图来理解它的原理：

model层主要负责：

· 从网络，数据库，文件，传感器，第三方等数据源读写数据。

· 对外部的数据类型进行解析转换为APP内部数据交由上层处理。

· 对数据的临时存储,管理，协调上层数据请求。

2.2 V（View）

视图：将数据呈现给用户。一般的视图都只是包含用户界面(UI)，而不包含界面逻辑。比如，Asp.net中包含控件的页面(page)就是一个视图。视图可以从模型中读取数据，但是不能修改或更新模型。

view 层主要负责：

· 提供UI交互

· 在presenter的控制下修改UI。

· 将业务事件交由presenter处理。

注意: View层不存储数据，不与Model层交互。

在Android中View层一般是Activity、Fragment、View（控件）、ViewGroup（布局等）等。

2.3. X（C-Controller、P-Presenter、VM-ViewModel）

控制器：View捕获到用户交互操作后会直接转发给Controller，后者完成相应的UI逻辑。如果需要涉及业务功能的调用，Controller会直接调用Model。在完成UI处理之后，Controller会根据需要控制原View或者创建新的View对用户交互操作予以响应。

层现器：作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。Presenter包含了根据用户在视图中的行为去更新模型的逻辑。视图仅仅只是将用户的行为告知Presenter，而Presenter负责从视图中取得数据然后发送给模型。

视图模型：binder 所在之处，是 View 的抽象，对外暴露出公共属性和命令，它是View的抽象，负责View与Model之间信息转换，将View的Command传送到Model。ViewModel的含义就是 “Model of View”，视图的模型。它的含义包含了领域模型（Domain Model）和视图的状态（State）。可以简单把ViewModel理解为页面上所显示内容的数据抽象，和Domain Model不一样，ViewModel更适合用来描述View。

2.4. 小结

MVC模式、MVP模式和MVVM模式都作为用来分离UI层与业务层的一种开发模式。这些模式之间的差异可以归纳为对这个问题处理的方式的不同。

三、MVX 与三层架构

=========================================================================

相信不少童鞋和我有过同样的疑惑：MVX分为了M-V-X三层，那这到底和软件的三层架构有何关系呢？我们带着问题继续往下阅读。

3.1. 什么是三层架构

三层架构是一个分层式的软件体系架构设计，它可适用于任何一个项目。通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。（参考自：百度百科）

常见的架构有：

· 分层架构（如：三层架构）

· 事件驱动架构

· 微内核架构

· 微服务架构

· 基于空间的架构