Android-架构新组件---让天下没有难做的-App，2024年最新腾讯3轮面试都问了Android事件分发

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注Android）

正文

这张图背后隐含了三大设计思想：

• 关注点分离（SOC / Separation Of Concerns）
• 数据驱动 UI（Reactive）
• 唯一真相源（SSOC / Single Source Of Truth）

SOC 具体到工程实践中就是分层合理，单层的职责越明确，对上下游的依赖越清晰就意味着它的结构更稳定，也
更可测（testable）。一个 App 从全局来看，可以划分为三部分：首先是 UI Controller 层，包含 Activity 和 Fragment；其次是 ViewModel 层，既可以做 MVVM 的 VM、MVP 的 P，也可以做 UI 的数据适配，这一层可以实现数据驱动 UI；最后是 Repository 层，它作为 SSOC，是一个 Facade 模式，对上层屏蔽了数据的来源，可以来自 local，也是来自 remote，数据持久化策略向上透明。

一张架构蓝图，三大设计原则，接下来深入细节，看看组件之间如何配合才能实现这个架构

Lifecycle

与 React/Vue 或者 iOS 相比，Android 的生命周期都比较复杂，如果要监听生命周期，一般情况下只能覆写 Activity / Fragment 的回调方法（onCreate、onResume、onPause、onDestroy 等），样板代码少不了，可维护性也变差。

如果要对生命周期进行简化，可以抽象成一个图，点表示状态，线表示事件：

Lifecycle 负责处理这些点（states）和线（events），Activity / Fragment 是 LifecycleOwner，监听者则是 LifecycleObserver，一个非常清晰的观察者模式。

class MyObserver : LifecycleObserver {

@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
fun connectListener() {
}

@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
fun disconnectListener() {
}
}

如果我们的组件需要强绑定声明周期，那么只需要借助 Lifecycle 去监听生命周期的状态和事件即可，再也不用覆写各种回调方法了。下面将要讲到的 LiveData 和 ViewModel 都是 Lifecycle-Aware Components，它们都用到了 Lifecycle。

Android 生命周期管理不当带来的最大问题就是内存泄露，举一个我们经常遇到的场景：一个异步任务（比如网络请求）持有了 UI 元素的引用，只要任务没有执行完，所有与这个 UI 元素有强引用关系的元素都没法被 GC，如果这样的场景多发生几次，很可能会引起 OOM。

为了异步对象引用的问题，最早我们使用 AsyncTask，任务执行在 worker thread，执行结果在主线程上发起回调。AsyncTask 的致命缺点是不支持流式数据（stream），而且回调嵌套太深（callback hell），与软件质量衡量指标之一的 maintainable 背道而驰，不好用自然就会慢慢被淘汰。

后来我们开始使用 RxJava，响应式编程，声明式写法，再借助 retrolambda 这种 backport，即使当年 Android 只支持到 JDK7，我们依然可以利用各种 operator 写出非常简洁的代码，“filter map 我闭~着眼”。RxJava 不但完美解决了线程调度的问题，还为我们提供了 OO 之外的抽象——作用在流上的 lambda，基于函数的抽象。但是，即便完美如斯，生命周期的问题依然无法回避，因为 Java 天生的局限性，一个 lambda 无论伪造地再像高阶函数，它本质上还是一个匿名内部类，这个匿名内部类依然持有对 outer class 实例的引用。于是我们必须通过 CompositeDisposable 来管理订阅关系，发起异步操作时记录订阅，离开页面时取消订阅，仍然需要覆写 onDestory 或者 onPause 。

如果我们以 Repository 层为界把架构蓝图分为上下两部分的话，上面的部分是数据展示，下面的部分是数据获取，数据获取部分因为要请求 Remote 数据，必然会依赖到线程调度，而数据展示必然运行在 UI 线程，与生命周期强相关，这个时候就需要 LiveData 登场了。

LiveData

LiveData 也是一个观察者模型，但是它是一个与 Lifecycle 绑定了的 Subject，也就是说，只有当 UI 组件处于 ACTIVE 状态时，它的 Observer 才能收到消息，否则会自动切断订阅关系，不用再像 RxJava 那样通过 CompositeDisposable 来手动处理。

LiveData 的数据类似 EventBus 的 sticky event，不会被消费掉，只要有数据，它的 observer 就会收到通知。如果我们要把 LiveData 用作事件总线，还需要做一些定制，Github 上搜 SingleLiveEvent 可以找到源码实现。

我们没法直接修改 LiveData 的 value，因为它是不可变的（immutable），可变（mutable）版本是 MutableLiveData，通过调用 setValue（主线程）或 postValue（非主线程）可以修改它的 value。如果我们对外暴露一个 LiveData，但是不希望外部可以改变它的值，可以用如下技巧实现：

private val _waveCode = MutableLiveData()
val waveCode: LiveData = _waveCode

内部用 MutableLiveData ，可以修改值，对外暴露成 LiveData 类型，只能获取值，不能修改值。

LiveData 有一个实现了中介者模式的子类 —— MediatorLiveData，它可以把多个 LiveData 整合成一个，只要任何一个 LiveData 有数据变化，它的观察者就会收到消息：

val liveData1 = …
val liveData2 = …

val liveDataMerger = MediatorLiveData<>();
liveDataMerger.addSource(liveData1) { value -> liveDataMerger.setValue(value))
liveDataMerger.addSource(liveData2) { value -> liveDataMerger.setValue(value))

综上，我们汇总一下 LiveData 的使用场景：

• LiveData - immutable 版本
• MutableLiveData - mutable 版本
• MediatorLiveData - 可汇总多个数据源
• SingleLiveEvent - 事件总线

LiveData 只存储最新的数据，虽然用法类似 RxJava2 的 Flowable，但是它不支持背压（backpressure），所以不是一个流（stream），利用 LiveDataReactiveStreams 我们可以实现 Flowable 和 LiveData 的互换。

如果把异步获取到的数据封装成 Flowable，通过 toLiveData 方法转换成 LiveData，既利用了 RxJava 的线程模型，还消除了 Flowable 与 UI Controller 生命周期的耦合关系，借助 Data Binding 再把 LiveData 绑定到 xml UI 元素上，数据驱动 UI，妥妥的响应式。于是一幅如下模样的数据流向图就被勾勒了出来：

图中右上角的 Local Data 是 AAC 提供的另一个强大武器 —— ORM 框架 Room。

Room

数据库作为数据持久层，其重要性不言而喻，当设备处于离线状态时，数据库可用于缓存数据；当多个 App 需要共享数据时，数据库可以作为数据源，但是基于原生 API 徒手写 CRUD 实在是痛苦，虽然 Github 上出现了不少 ORM 框架，但是它们的易用性也不敢让人恭维，直到 Room 出来之后，Android 程序员终于可以像 mybatis 那样轻松地操纵数据库了。

Room 是 SQLite 之上的应用抽象层，而 SQLite 是一个位于 Android Framework 层的内存型数据库。虽然 Realm 也是一个优秀的数据库，但是它并没有内置于 Android 系统，所会增大 apk 的体积，使用 Room 则没有这方面烦恼。

Room 的结构抽象得非常简单，数据对象（表名 + 字段）用 @Entity 注解来定义，数据访问用 @Dao 来注解，db 本身则用 @Database 来定义，如果要支持复杂类型，可以定义 @TypeConverters，然后在编译阶段，apt 会根据这些注解生成代码。Room 与 App 其他部分的交互如下图所示：

Entity 是一个数据实体，表示一条记录，它的用法如下：

@Entity(tableName = “actors”)
data class Actor(
@PrimaryKey @ColumnInfo(name = “id”)
val actorId: String,
val name: String,
val birthday: Date?,
val pictureUrl: String
)

Actor 是一个用 @Entity 注解的 data class，它会生成一个名字是 actors 的表，注意到有一个字段是 @Date? ，但是 SQLite 本身不支持这种复杂类型（complex type），所以我们还需要写一个可以转换成基础类型的转换器：

class Converters {
@TypeConverter
fun timestampToDate(value: Long?) = value?.let { Date(it) }

@TypeConverter
fun dateToTimestamp(date: Date?) = date?.time
}

转换器通过 @TypeConverters 可作用于 class、field、method、parameter，分别代表不同的作用域。比如作用在 @Database 类的上，那么它的作用域就是 db 中出现的所有 @Dao 和 @Entity。

@Database(entities = [Actor::class], version = 1, exportSchema = false)
@TypeConverters(Converters::class)
abstract class AppDatabase : RoomDatabase() {
abstract fun actorDao(): ActorDao
}

代码出现的 ActorDao 定义了 CRUD 操作。用 @Dao 来注解，它既可以是一个接口，也可以是抽象类，用法如下：

@Dao
interface ActorDao {
@Query(“SELECT * FROM actors WHERE id = :actorId”)
fun getActor(actorId: String): LiveData

@Insert(onConflict = OnConflictStrategy.REPLACE)
fun insertAll(actors: List)
}

@Query 中的 SQL 语句可以直接引用方法参数，而且它的返回值可以是 LiveData 类型，也支持 Flowable 类型，也就是说，Room 原生支持响应式，这是对数据驱动最有利的支持，也是 Room 区别于其他 ORM 框架的显著特征。

至此，我们可以确定，无论数据来自 Remote 还是来自本地 DB，架构蓝图中的 Repository 对 ViewModel 提供的数据可以永远是 LiveData 类型，接下来我们看一下 ViewModel 的妙用。

ViewModel

ViewModel 是一个多面手，因为它的生命周期比较长，可以跨越因为配置变动（configuration changed，比如屏幕翻转）引起的 Activity 重建，因此 ViewModel 不能持有对 Activity / Fragment 的引用。

如果 ViewModel 中要用到 context 怎么办呢？没关系，框架提供了一个 ViewModel 的子类 AndroidViewModel ，它在构造时需要传入 Application 实例。

既然 ViewModel 与 UI Controller 无关，当然可以用作 MVP 的 Presenter 层提供 LiveData 给 View 层，因为 LiveData 绑定了 Lifecycle，所以不存在内存泄露的问题。除此之外，ViewModel 也可以用做 MVVM 模式的 VM 层，利用 Data Binding 直接把 ViewModel 的 LiveData 属性绑定到 xml 元素上，xml 中声明式的写法避免了很多样板代码，数据驱动 UI 的最后一步，我们只需要关注数据的变化即可，UI 的状态会自动发生变化。

ViewModel 配合 Data Binding 的用法与 React 非常相似，ViewModel 实例相当于 state，xml 文件就好比 render 函数，只要 state 数据发生变化，render 就会重新渲染 UI，但是 data binding 还有更强大的一点，它支持双向绑定。举个例子，UI 需要展示一个评论框，允许展示评论，也允许用户修改，那么我们可以直接把 EditText 双向绑定到一个 LiveData 之上，只要用户有输入，我们就可以收到通知，完全不需要通过 Kotlin/Java 来操控 UI：

android:text=“@={viewModel.commentText}” />

注意，如果要在 xml 中使用 LiveData，需要把 lifecycle owner 赋给 binding：

val binding: MainBinding = DataBindingUtil.setContentView(this, R.layout.main)
// Specify the current activity as the lifecycle owner.
binding.setLifecycleOwner(this)

因为 ViewModel 拿到的数据是 Repository 给的，可能不适用于 UI 元素，所以 ViewModel 还承担了数据适配的工作，有时候我们需要汇总 repository 的多个返回值一次性给到 UI，那么就可以使用 LiveData 的“操作符” Transformations.switchMap，用法可以认为等同于 Rx 的 flatMap；如果只想对 LiveData 的 value 做一些映射，可以使用 Transformations.map，目前 Transformations 只有这两个操作符，因为不管 Kotlin 还是 Java8，都提供了很多声明式的操作符，对流的支持都比较友好，而 LiveData 本身不是一个流，所以这两个操作符足矣。

除了数据适配之外，ViewModel 还有一个强大的用法 —— Fragment 之间共享数据，这样 ViewModel 又扮演了 FLUX 模式中的 store 这一角色，是多个页面（fragment）之间唯一的数据出口。

ViewModel 的用法也非常简单，通过 ViewModelProviders.of 可以获取 ViewModel 实例：

.get(ActorViewModel::class.java)

一通操作猛如虎之后，UI controller 层变得薄如蝉翼，它只做了一件事情，把数据从左手（ViewModel）倒给了右手（使用了 Data Binding 的 xml）。

如果把 ViewModel 作为 SSOC（唯一真相源），多个 Fragment 之间共享数据，再利用 SingleLiveEvent 做总线，一个 Activity 配多个 Fragment 的写法就避免了 Activity 之间通过 Intent 传递数据的繁琐。但是 Fragment 的堆栈管理一直是一个让人头疼的问题，AAC 的 Navigation 不但完美解决了这个问题，而且还提供可视化的路由，只需拖拽一下就能生成类型安全的跳转逻辑。

结尾

最后小编想说：不论以后选择什么方向发展，目前重要的是把Android方面的技术学好，毕竟其实对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们！

当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。

想要拿高薪实现技术提升薪水得到质的飞跃。最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

当你有了学习线路，学习哪些内容，也知道以后的路怎么走了，理论看多了总要实践的。

高级UI，自定义View

UI这块知识是现今使用者最多的。当年火爆一时的Android入门培训，学会这小块知识就能随便找到不错的工作了。

不过很显然现在远远不够了，拒绝无休止的CV,亲自去项目实战，读源码，研究原理吧！

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

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）

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

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

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注Android）
[外链图片转存中…(img-Rt5X7x7i-1713697239811)]

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