一、飞行模式概述
大家好，我是你们的讲师。今天咱们聊聊飞行模式——这个手机里天天见、但你可能从没认真想过它的功能。
说实话，我做了这么多年嵌入式开发，飞行模式是我见过最「被低估」的系统功能之一。大多数人觉得它就是个「坐飞机时打开的小开关」，但在我眼里，它其实是系统级通信管理的典范设计。
1.1 什么是飞行模式
飞行模式，也叫航空模式。它的核心动作很简单：一刀切地关闭所有无线通信模块。
具体来说，当你开启飞行模式，系统会依次做这几件事：
- 关闭蜂窝基带（2G/3G/4G/5G 射频）
- 关闭 Wi-Fi 和蓝牙（部分厂商允许单独再打开）
- 关闭 NFC 近场通信
- 关闭 GPS 定位（有些系统保留）
说白了，就是把手机变成一个「单机设备」——不能打电话、不能上网、不能连蓝牙耳机。但本地功能照常运行：看视频、玩单机游戏、写备忘录，都没问题。
核心本质：飞行模式是系统级的射频电源管理策略。它通过统一关闭多个硬件模块的电源或时钟，实现最低功耗的通信静默状态。
1.2 传统飞行模式的局限性
嗯，这里我要说点实话了。传统飞行模式虽然好用，但它的设计思路是「一刀切」——要么全开，要么全关。这在今天看来，已经有点跟不上时代了。
我遇到过不少实际场景，让我觉得这个设计太死板：
- 场景一：你在飞机上看下载好的电影，想连蓝牙耳机。传统飞行模式一开，蓝牙也关了。你还得手动再打开蓝牙——多此一举。
- 场景二：你在医院陪床，想关掉蜂窝网络避免干扰医疗设备，但想用 Wi-Fi 刷视频。传统飞行模式做不到这种「选择性关闭」。
- 场景三：你在国外出差，只想用 Wi-Fi 收发微信，不想开漫游数据。传统飞行模式关了蜂窝，但 Wi-Fi 也得重新手动开。
为什么会这样？因为传统飞行模式的实现方式太粗暴了。我拆解过几个厂商的源码，发现它们大多是在 Settings.Global 里写一个标志位，然后遍历所有无线模块的 setEnabled() 方法。代码大概长这样：
// 传统飞行模式的典型实现（简化版）
public void setAirplaneMode(boolean enable) {
// 一刀切：所有无线模块统一开关
mTelephonyManager.setRadioEnabled(!enable);
mWifiManager.setWifiEnabled(!enable);
mBluetoothAdapter.enable(!enable);
mNfcAdapter.enable(!enable);
// 保存状态
Settings.Global.putInt(mContext.getContentResolver(),
Settings.Global.AIRPLANE_MODE_ON, enable ? 1 : 0);
}你看，它没有区分「用户到底想关什么」。所有模块一视同仁。这在功能机时代没问题，但在今天这个多无线协议并存的时代，就显得不够灵活了。
我曾经踩过的坑：有一次做定制 ROM，客户要求在飞行模式下保留蓝牙。我直接改了上面的代码，把蓝牙那行注释掉了。结果测试发现，飞行模式关闭后再打开，蓝牙状态恢复异常——因为系统框架里有多处地方在同步这个状态，我只改了一处。嗯，从那以后我学乖了：改系统功能，一定要把所有的状态同步路径都理清楚。
1.3 自定义飞行模式的价值与场景
那么，自定义飞行模式到底能做什么？说白了，就是把「一刀切」变成「精准控制」。
我个人习惯把自定义飞行模式理解为：用户可配置的无线模块组合开关策略。它允许你定义「飞行模式开启时，哪些模块关、哪些模块保持原状」。
来看几个我实际做过的项目场景：
| 场景 | 需求 | 自定义策略 |
|---|---|---|
| 航空出行 | 关蜂窝，但保留蓝牙连耳机 | 飞行模式 = 关基带 + 关Wi-Fi + 保留蓝牙 |
| 医院陪护 | 关蜂窝，用Wi-Fi刷视频 | 飞行模式 = 关基带 + 保留Wi-Fi + 关蓝牙 |
| 省电模式 | 保留通话，关数据流量 | 飞行模式 = 保留基带语音 + 关数据 + 关Wi-Fi + 关蓝牙 |
| 儿童模式 | 完全断网，仅限本地应用 | 飞行模式 = 关所有无线模块 |
你想想看，这种灵活性带来的体验提升是巨大的。用户不再被系统的「全有或全无」逻辑绑架，而是可以根据自己的实际需求，定义最适合自己的飞行模式行为。
我的建议：在做自定义飞行模式设计时，不要只想着「开关组合」。还要考虑状态持久化、异常恢复、以及用户界面的交互反馈。我曾经在一个项目里，因为忽略了「飞行模式切换过程中用户突然插拔USB」的边界情况，导致基带驱动状态机卡死——那次debug花了我整整两天。
从技术实现角度看，自定义飞行模式的核心挑战在于：
- 状态管理：如何优雅地保存和恢复每个无线模块的独立状态
- 依赖关系：有些模块之间有依赖（比如 Wi-Fi 和 Wi-Fi Direct），关一个可能影响另一个
- 用户意图推断：当用户手动打开某个被飞行模式关闭的模块时，系统该怎么处理？
- 性能与功耗：频繁切换模块电源状态，会不会引入额外的功耗开销？
这些，都是我们在后续章节中要一一攻克的问题。
好了，这一章我们理清了飞行模式的基本概念、传统方案的局限，以及自定义飞行模式的价值。下面这张图可以帮你快速回顾本章的知识脉络：
下一章，我们会深入 Android 系统的无线通信框架，看看这些模块在底层是怎么管理的。到时候我会带你看实际的 AOSP 源码，咱们一步步把自定义飞行模式的架构搭起来。
公众号:蓝海资料掘金营，微信deep3321