2024大厂Android面试集合，秒懂是如何做到的(1)，三面腾讯已拿offer

• Jetpack LiveData

• LiveData 存在前的混沌世界

• LiveData 为什么能解决上述这些问题？

• LiveData 有个坑需要注意

• Jetpack ViewModel

• ViewModel 存在前的混沌世界

• ViewModel 为什么能做到这几点？

• Jetpack DataBinding

• DataBinding 存在前的混沌世界

• DataBinding 就是来解决这些问题

• 综上

Jetpack Lifecycle

Lifecycle 的存在，主要是为了解决 生命周期管理 的一致性问题

Lifecycle 存在前的混沌世界

在 Lifecycle 面市前，生命周期管理 纯靠手工维持，这样就容易滋生大量的一致性问题。

例如跨页面共享的 GpsManager 组件，在每个依赖它的 Activity 的 onResume 和 onPause 中都需要 手工 激活、解绑 和 叫停。

那么 随着 Activity 的增多，这种手工操作 埋下的一致性隐患 就会指数级增长：

一方面，凡是手工维持的，开发者容易疏忽，特别是工作交接给其他同事时，同事并不能及时注意到这些细节。

另一方面，分散的代码不利于修改，日后除了激活、叫停，若有其他操作需要补充（例如状态监听），那么每个 Activity 都需要额外书写一遍。

Lifecycle 为什么能解决上述这些问题？

Lifecycle 通过 模板方法模式 和 观察者模式，将生命周期管理的复杂操作，全部在作为 LifecycleOwner 的基类中（例如视图控制器的基类）封装好，默默地在背后为开发者运筹帷幄，

开发者因而得以在视图控制器（子类）中只需一句：

getLifecycle().addObserver(GpsManager.getInstance) ，优雅地完成 第三方组件在自己内部 对 LifecycleOwner 生命周期的感知。

除了解决一致性问题，这样做还 顺带地提供了其他 2 个好处：

1. 规避 为监听状态 而 注入视图控制器 的做法

当需要监听状态时，以往我们的做法是 通过方法手工注入 Activity 等参数，这埋下了内存泄漏的隐患 —— 因为团队中的新手容易因这是个 Activity，而在日后误将其依赖给组件中的其他成员。

现如今，我们可以直接在组件内部 点到为止 地监听 LifecycleOwner 的状态，从而规避这种不恰当的使用。

2. 规避 为追溯事故来源 而 注入视图控制器 的做法

当发生事故时，以往我们若想在组件中 追溯事故来源，同样不得不从方法中直接注入 Activity 等，这同样埋下了内存泄漏的隐患。现如今组件因实现了 DefaultLifecycleObserver，而得以通过生命周期回调方法中的 LifecycleOwner 参数，在方法作用域中 即可得知事故来源，无需更多带有隐患的操作。

如果这么说还不理解的话，可具体参考我在 《为你还原一个真实的 Jetpack Lifecycle》 中提供的 GpsManager 案例，本文不再累述。

Jetpack LiveData

LiveData 的存在，主要是为了帮助 新手老手 都能不假思索地遵循 通过唯一可信源分发状态 的标准化开发理念，从而使在快速开发过程中 难以追溯、难以排查、不可预期 的问题所发生的概率降低到最小。

LiveData 存在前的混沌世界

在 LiveData 面市前，我们分发状态，多是通过 EventBus 或 Java Interface 来完成的。不管你是用于网络请求回调的情况，还是跨页面通信的情况。

那这造成了什么问题呢？首先，EventBus 只是纯粹的 Bus，它 缺乏上述提到的 标准化开发理念 的约束，那么人们在使用这个框架时，容易因 去中心化 地滥用，而造成 诸如 毫无防备地收到 预期外的 不明来源的推送、拿到过时的数据 及 事件源追溯复杂度 为 n² 的局面。

并且，EventBus 本身缺乏 Lifecycle 的加持，存在生命周期管理的一致性问题。这是 EventBus 的硬伤，也是我拒绝使用 EventBus 的最主要因素。

对上述状况不理解的，可具体参考我在 《LiveData 鲜为人知的 身世背景 和 独特使命》 中提供的 播放器状态全局通知 的案例

LiveData 为什么能解决上述这些问题？

首先，LiveData 是在 Google 希望确立 标准化、规范化 的开发模式 —— 这样一种背景下诞生的，因而为了达成这个艰巨的 使命，Google 十分克制地将其设计为，仅支持状态的输入和监听，从而，它不得不 在单例的配合下，承上启下地完成 状态 从 唯一可信源 到 视图控制器 的输送。

（ViewModel 姑且也算是一种单例，一种工厂模式实现的伪单例。唯一可信源是指 生命周期独立于 视图控制器的 数据组件，通常是 单例 或共享 ViewModel）

这使得任何一次状态推送，都可预期、都能方便地追溯来源，而不至于在 事件追溯复杂度为 n² 的迷宫中白费时间。（即，无论是从哪个视图控制器发起的 对某个共享状态改变的请求，状态最终的改变 都由 作为唯一可信源的 单例或 SharedViewModel 来一对多地通知改变）

并且，这种承上启下的方式，使得单向依赖成为可能：单例无需通过 Java Interface 回调通知视图控制器，从而规避了视图控制器 被生命周期更长的单例 依赖 所埋下的内存泄漏的隐患。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

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

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

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

如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）

最后

说一千道一万，不如自己去行动。要想在移动互联网的下半场是自己占有一席之地，那就得从现在开始，从今天开始，马上严格要求自己，既重视业务实现能力，也重视基础和原理。基础夯实好了，高楼才能够平地而起，稳如泰山。

最后为了帮助大家深刻理解Android相关知识点的原理以及面试相关知识，这里放上相关的我搜集整理的24套腾讯、字节跳动、阿里、百度2020-2021面试真题解析，我把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包知识脉络 + 诸多细节。

还有 高级架构技术进阶脑图、Android开发面试专题资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算

L、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算**