Jetpack 概述：从混乱到有序的 Android 开发之路
说实话，我刚入行那会儿，Android 开发还处于「野蛮生长」阶段。那时候写一个 App，光处理屏幕旋转就要写一堆 onSaveInstanceState，稍不留神就内存泄漏。直到 Google 推出了 Jetpack，我才觉得 Android 开发终于有了「正规军」的样子。
这一章，咱们就来聊聊 Jetpack 到底是什么，它解决了哪些痛点，以及为什么我建议每个 Android 开发者都应该拥抱它。
Jetpack 是什么？
Jetpack 是一套组件库、工具和架构指南的集合。说白了，它就是 Google 官方给 Android 开发者准备的一套「乐高积木」。你不需要重复造轮子，直接拿来用就行。
我记得 2018 年 Google I/O 大会上，Jetpack 刚发布时，台下开发者们其实挺懵的——这不就是 Support Library 换了个马甲吗？但用了一段时间后，大家发现事情没那么简单。
核心观点：Jetpack 不是某个单一框架，而是一整套解决方案。它覆盖了从 UI 到数据层、从生命周期管理到后台任务的方方面面。
Jetpack 组件家族
Jetpack 的组件可以分为四大类，我习惯把它们比作一个房子的四个部分：
| 分类 | 核心组件 | 我的理解 |
|---|---|---|
| 基础 | AppCompat、Android KTX、Multidex | 地基，保证 App 在不同版本上跑得稳 |
| 架构 | LiveData、ViewModel、Room、WorkManager | 承重墙，决定 App 的结构是否牢固 |
| 行为 | Permissions、Notifications、Sharing | 门窗，处理系统交互 |
| UI | Compose、Fragment、Navigation | 装修，用户直接看到的部分 |
你可能会问：「这么多组件，我该从哪个开始学？」我的建议是：先从架构组件入手。因为这部分解决的是最核心的问题——代码该怎么组织。
为什么选择 Jetpack？
这个问题我经常被问到。其实答案很简单：省心。
举个例子，以前做网络请求，我要自己管理线程池、处理 Activity 销毁时的回调、还要防止内存泄漏。用了 Jetpack 的 ViewModel + LiveData 之后，这些破事儿全交给框架了。我只需要关注业务逻辑。
我的经验：曾经有个项目，因为生命周期处理不当，线上崩溃率高达 3%。改用 Jetpack 架构组件后，这个数字降到了 0.1% 以下。嗯，数据不会骗人。
另外，Jetpack 还有一个隐形的好处：统一团队规范。以前团队里每个人写代码的风格都不一样，有人用 MVP，有人用 MVC，代码 review 时经常吵架。用了 Jetpack 推荐的 MVVM 架构后，大家的代码结构基本一致了，沟通成本直线下降。
项目架构演进
Android 项目的架构，说白了就是一部「打怪升级史」。我把它分成三个阶段：
第一阶段：一切都在 Activity 里
早期的 Android 开发，Activity 就是「万能容器」。网络请求、数据解析、UI 更新全塞在一起。一个 Activity 上千行代码是常态。
// 2015 年的典型写法
public class MainActivity extends AppCompatActivity {
private TextView textView;
private Handler handler = new Handler();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
textView = findViewById(R.id.text_view);
// 网络请求直接写在 Activity 里
new Thread(() -> {
String result = fetchDataFromNetwork();
handler.post(() -> textView.setText(result));
}).start();
}
}这种写法的问题很明显：Activity 销毁时，网络请求还在跑。结果就是内存泄漏、空指针异常满天飞。
避坑指南：我曾经在一个老项目里看到过 2000 行的 Activity。改一个 bug 要翻半天代码，而且经常修了一个问题又引出三个新问题。所以，千万别这么写。
第二阶段：MVP 模式
后来大家发现 Activity 太臃肿了，于是 MVP 模式开始流行。Presenter 负责业务逻辑，View 只负责 UI 更新。代码确实清晰了不少。
但 MVP 也有它的痛点：接口太多。每个页面都要定义 View 和 Presenter 的接口，写起来很繁琐。而且 Presenter 的生命周期管理依然是个问题。
第三阶段：MVVM + Jetpack
Jetpack 推出后，MVVM 成了官方推荐模式。ViewModel 天然解决了生命周期问题，LiveData 让数据观察变得简单，Room 把数据库操作封装得明明白白。
// 现在的写法
public class MyViewModel extends ViewModel {
private MutableLiveData<String> data = new MutableLiveData<>();
public LiveData<String> getData() {
return data;
}
public void loadData() {
// ViewModel 自动感知生命周期
new Thread(() -> {
String result = fetchDataFromNetwork();
data.postValue(result);
}).start();
}
}你看，代码量少了，逻辑清晰了，而且不用担心内存泄漏。这就是 Jetpack 带来的改变。
Jetpack 知识体系总览
为了让你对 Jetpack 有个整体认识，我画了一张图。这张图涵盖了 Jetpack 的核心组件和它们之间的关系：
我的建议
如果你刚开始接触 Jetpack，别想着一下子把所有组件都学会。我个人的学习路径是这样的：
- 先学 ViewModel + LiveData——这是最核心的架构组件，解决了生命周期问题
- 再学 Room——数据库操作，比 SQLite 好用一百倍
- 然后学 Navigation——页面跳转终于不用写 Intent 了
- 最后学 WorkManager——后台任务管理，省心省力
至于 Compose，那是未来的趋势，但如果你项目还在用 XML 布局，也不急着迁移。慢慢来，比较快。
一个小技巧：在 Android Studio 里新建项目时，直接选择「Empty Activity with Jetpack Compose」模板。这样你就能直接体验 Jetpack 全家桶了。我刚开始就是这么干的。
好了，这一章的内容就到这里。Jetpack 的世界很大，但别怕，咱们一章一章来啃。下一章，我会带你深入 ViewModel 的内部机制，看看它到底是怎么做到「自动感知生命周期」的。