Skip to main content

Chapter 4: Mobile Platform Constraint Model

移动平台约束模型要解决的问题是：当 App 请求一个持续、昂贵、涉及隐私的系统能力时，系统怎样决定立即执行、延后执行、降级执行、拒绝执行或终止执行。读完本章后，读者应能把一次 App 可见现象放回电量、温控、传感器、隐私、连接、后台调度和用户设置共同构成的策略链中，定位是哪一层改变了结果。

本章使用一个贯穿材料：一个骑行记录 App 在前台显示地图，持续读取位置和运动传感器，途中调用相机拍照，随后压缩图片并上传到云端。用户锁屏后，App 仍希望记录路线、接收推送、补传照片；设备进入弱网环境，屏幕亮度较高，外壳温度升高。这个场景把移动 OS 的主要约束集中到一次能力路径里：显示、定位、传感器、相机、CPU / GPU、编码、蜂窝或 Wi-Fi、后台任务和通知都在竞争同一块电池、同一套散热空间和同一组用户授权。

移动 OS 的策略判断按路径展开：App 意图进入 Framework API，系统服务读取调用者身份、生命周期状态、权限状态和用户设置，再结合内核、驱动、硬件状态给出结果。Android 公开文档把 Doze、App Standby、JobScheduler、WorkManager、后台位置、Bluetooth 权限和 Thermal HAL 暴露成可观察的策略入口；Apple 公开文档把 BackgroundTasks、Core Location、Core Motion、AVFoundation、PhotosUI 和 ProcessInfo.thermalState 暴露成开发者可使用的能力表面。Apple 私有 daemon 和内部调度细节在公开材料中不可完整验证，本章只使用公开 API、公开文档和可观察平台行为进行结构化说明。

本章的核心结论是：移动平台约束模型由单个 API 决定的“是否可调用”，提升为跨层状态共同决定的“何时可执行、以什么质量执行、持续多久、失败时怎样反馈”。同一段 App 代码在前台、后台、低电量、高温、弱网、权限撤销、低数据模式或用户强制停止后会得到不同结果。移动 OS 架构阅读必须把这些约束当成系统路径的输入，而不能把它们当成 API 调用之后的附加条件。

4.1 Battery Budget 与全系统功耗模型​

Battery budget 指系统在一段时间内允许整机消耗的能量和瞬时电流范围。移动设备由电池供电，App 的一次能力请求会同时激活多个硬件块；系统评估的是整机成本，包括 CPU 计算、GPU 绘制、modem 发射、display 背光或 OLED 像素、camera ISP、sensor 采样、存储写入和后台唤醒。骑行记录 App 在地图页面中看似只是在“记录路线”，系统看到的成本链是定位硬件采样、地图渲染、屏幕刷新、网络请求、数据库写入和路线纠偏共同消耗电量。

电量预算的第一层判断是 App 当前是否处于用户可见路径。前台地图导航、拍照预览和用户刚点击的上传按钮通常获得更高执行优先级，因为用户正在等待结果。锁屏后的路线补记、图片补传和云端同步进入后台路径，系统会把它们交给调度器，根据充电状态、网络类型、空闲状态和 App 使用频率决定执行窗口。Android 官方文档在后台任务优化中建议为 WorkManager 或 JobScheduler 指定约束，例如充电约束和 unmetered network 约束，并把多个相同约束下的同步合并成一次唤醒；这说明电量模型关心的是整机被唤醒的次数和每次唤醒的硬件组合，而非单个任务名是否合理，见 Android Optimize battery use for task scheduling APIs。

电量预算的第二层判断是硬件块的功耗斜率。显示、蜂窝发射、相机、GNSS、视频编码和 GPU 持续渲染都可能把瞬时功耗推高。骑行 App 的地图页面如果保持高刷新率、频繁刷新 polyline、每秒请求高精度位置，再叠加弱蜂窝信号上传照片，modem 需要更高发射功率，CPU 处理网络栈和加密，GPU 继续输出 UI，ISP 和编码器处理照片。单个操作都能解释为用户功能，组合后会形成超过电池预算的工作负载。

电量预算的第三层判断是任务是否能推迟、合并或降级。路线记录通常要求持续性，但采样精度可调整；图片上传要求最终完成，但可等待 Wi-Fi、充电或网络恢复；步数统计可由低功耗计数器或 sensor hub 汇总后批量上报；地图 UI 可降低刷新频率。系统服务把这些差异转成策略：前台能力直接响应，后台能力进入批处理，用户可见通知获得更高机会，低优先级同步等待维护窗口。

Android 从 Android 6.0 开始引入 Doze 和 App Standby，用于在未连接电源且设备长时间未使用时推迟后台 CPU 和网络活动；官方文档明确写到 Doze 会暂停网络访问、忽略 wake lock、推迟标准 alarm、停止 Wi-Fi scan，并推迟 JobScheduler 与 WorkManager 任务，见 Android Doze and App Standby。这组行为把“后台继续运行”拆成了多个受控资源：网络、唤醒、alarm、job、sync 和 Wi-Fi scan 都有各自的系统阈值。

Apple 平台对后台执行采用公开能力声明与系统调度结合的模型。App 通过 BackgroundTasks 提交后台刷新或处理请求，通过 Core Location 的授权和后台模式处理位置，通过 background URLSession 处理传输；系统根据电量、网络、用户行为和平台策略选择执行时机，见 Apple BackgroundTasks。公开文档没有给出完整内部调度算法，工程判断应只落到可观察结果：后台任务有执行机会窗口，持续占用 CPU、网络和位置的任务会被系统收束到特定能力入口。

分析电量问题时，可以按固定顺序拆解：先看用户是否正在等待结果，再看任务是否需要持续硬件访问，接着看能否批处理或推迟，然后看是否声明了正确的后台能力，最后看系统是否处于省电、空闲、低数据或低电量状态。骑行记录 App 的路线采样、照片压缩和上传不能放在同一个“后台任务”标签下判断：路线采样绑定位置能力和传感器预算，照片压缩绑定 CPU / NPU / 编码预算，上传绑定 modem / Wi-Fi 和网络策略。

4.2 Thermal Envelope 与 Performance Throttling​

Thermal envelope 指设备在安全表面温度、电池温度、芯片温度和用户体验之间允许的发热范围。手机缺少主动风扇，热量主要通过机身和屏幕扩散；当 CPU、GPU、ISP、modem、display 和充电同时活跃时，系统会触发降频、降帧、限制后台任务、降低相机质量、暂停部分无线能力或收缩充电速度。温控约束与电量约束相关，但判断目标不同：电量关注剩余能量和续航，温控关注热量积累、表面温度和硬件安全。

Android 10 以后，公开 AOSP 文档描述了 Framework thermal service 与 Thermal HAL 2.0 的协作方式：Thermal HAL 抽象皮肤、电池、GPU、CPU、USB 等传感器，Framework thermal service 监听缓解信号，并向内部组件和 App 提供 thermal status 回调；Android 14 起 Thermal HAL 从 HIDL 迁移到 AIDL，见 AOSP Thermal mitigation。这说明温控路径跨越硬件传感器、HAL、Framework service、Binder 回调和 App 层状态。

Thermal status 的语义可以直接映射到用户体验。AOSP 文档把 THERMAL_STATUS_LIGHT、THERMAL_STATUS_MODERATE、THERMAL_STATUS_SEVERE、THERMAL_STATUS_CRITICAL、THERMAL_STATUS_EMERGENCY 和 THERMAL_STATUS_SHUTDOWN 描述为逐级加重的 throttling 状态；严重状态可能带来 display jank 和 audio jitter，emergency 状态下某些功能例如 modem 和 cellular data 可能被关闭，见 AOSP thermal status codes。骑行 App 如果在高温下继续地图渲染、相机拍摄、图片压缩和蜂窝上传，用户看到的可能是帧率下降、拍照预览卡顿、上传暂停、网络断续或系统过热提示。

Apple 公开 API 侧把温控状态暴露为 ProcessInfo.thermalState，并提供 thermal state changed 通知；开发者可据此降低工作负载，见 Apple ProcessInfo.ThermalState。公开材料无法支撑对 Apple 私有 thermal daemon、驱动策略和芯片调度细节的完整描述；可以稳定使用的判断是：App 只拿到抽象后的 thermal state，系统内部再决定 CPU / GPU 频率、屏幕、相机、充电和后台任务的调节边界。

温控触发后的处理顺序通常从低损伤降级开始。UI 层可以降低动画频率、减少地图重绘和图层特效；媒体层可以降低相机预览分辨率、视频帧率或编码质量；计算层可以延后图片分析、压缩和模型推理；网络层可以暂停大文件上传；系统层可以限制后台 job、降低频率或进入紧急保护。骑行 App 在高温状态下继续保持路线记录，比继续上传高清照片更符合用户意图，因为路线丢失会破坏核心功能，照片补传可以延后。

温控还会改变后台策略的解释。一个后台上传任务在常温且充电时可能被调度执行；同一任务在高温且蜂窝弱网时会被系统延后或终止。App 看到的错误可能只是任务超时、网络不可用或后台执行被停止，真实原因需要结合 thermal state、电量、网络状态和任务类型判断。Android 文档建议检查后台任务停止原因，例如 WorkManager 的 stop reason 或 JobScheduler 的 stop reason；这种诊断方式把“任务没跑完”转成系统策略输入的复盘入口。

4.3 传感器常驻能力与持续环境感知​

传感器常驻能力指系统在屏幕关闭、CPU 休眠或 App 不处于前台时，仍然保留某些低功耗环境感知能力。步数、加速度、陀螺仪、方向、接近、环境光、气压、GNSS、Wi-Fi 扫描和蜂窝定位都可能参与持续感知。移动 OS 的关键设计是把“连续感知”拆成采样、融合、批处理、授权、后台策略和用户可见结果，而非让每个 App 直接长时间驱动硬件。

Android Sensor Framework 把传感器分为 motion、environmental 和 position 三类，并提供查询传感器能力、读取原始数据、设置最小采样率、注册与注销监听器等 API；官方文档还区分硬件传感器和由硬件数据融合得到的软件传感器，见 Android Sensors Overview。这个抽象让 App 面向传感器事件编程，系统服务和驱动负责具体硬件差异、采样速率、功耗属性和事件分发。

持续环境感知的第一个约束是采样率。骑行记录 App 可选择每秒一次位置、每五秒一次位置、按距离变化触发、按显著位置变化触发，或结合运动状态动态调整。高采样率会提高轨迹精度，也会激活 GNSS、CPU、modem 辅助定位和存储写入；低采样率降低功耗，但路线可能变粗。系统会根据前台状态、后台授权、电量和设备策略对可持续采样进行调节。

持续环境感知的第二个约束是批处理。步数和运动状态可以由低功耗处理器、sensor hub 或 SoC 低功耗岛进行初步统计，再在合适时机唤醒主 CPU 上报。具体硬件实现因设备而异，本章只使用架构判断：系统倾向把高频、低计算量、可延迟上报的传感器任务放到低功耗路径，把需要 UI、地图纠偏、云端同步和用户交互的任务放到主处理路径。App 应根据能力语义选择事件粒度，而非固定要求主 CPU 常驻。

持续环境感知的第三个约束是位置的隐私和功耗双重属性。位置请求既可能使用 GNSS、Wi-Fi、蜂窝和蓝牙信号，也会暴露用户行动轨迹。Android 对后台位置有明确版本边界：Android 10（API level 29）及以上需要检查 ACCESS_BACKGROUND_LOCATION；Android 8.0（API level 26）及以上在后台接收位置更新的频率受到限制，官方文档说明后台 App 只能每小时收到少量位置更新，见 Android background location。这类限制同时服务续航、隐私和后台公平性。

Apple Core Motion 与 Core Location 公开 API 也把持续感知分成能力请求、授权、后台模式和回调结果。Core Motion 提供运动传感器事件入口，Core Location 提供位置授权和后台更新路径；公开文档可说明 App 能请求什么，不能完整说明每台设备的内部 sensor fusion 细节，见 Apple Core Motion 和 Apple background location updates。阅读 Apple 平台时，应把公开 API 和可观察行为作为边界，把芯片内部调度视为平台实现细节。

骑行 App 的传感器策略可以这样判断：前台导航阶段使用较高精度位置和运动传感器，以保证地图反馈；锁屏记录阶段降低 UI 相关工作，保留路线核心采样；长时间静止后减少位置请求，依赖显著变化或地理围栏；进入低电量或高温后进一步降低采样或暂停照片处理。这里的系统边界在于：App 提出精度、频率和后台能力需求，Framework 和系统服务根据权限、生命周期和硬件状态给出可用结果。

4.4 隐私敏感硬件：Camera、Microphone、Location、Photos、Bluetooth​

隐私敏感硬件的共同特征是：它们采集现实世界、用户身份、位置、环境声音、照片库或附近设备信息。移动 OS 会把这些能力包装成用户授权、系统指示器、后台限制、数据范围和撤销路径。用户看到的是权限弹窗、状态栏指示、设置里的开关和失败提示；系统内部执行的是调用者身份检查、权限状态读取、服务仲裁、驱动或 daemon 控制，以及撤销后的回调或错误返回。

Camera 和 Microphone 通常要求运行时授权和用户可见状态。相机拍照路径会经过 Framework API、媒体或相机服务、权限检查、相机设备仲裁、HAL / driver、ISP 和 buffer 返回。麦克风录音路径经过音频框架、audio service、权限检查、音频路由和设备驱动。系统指示器让用户知道摄像头或麦克风正在被使用；撤销权限后，后续 API 调用会被拒绝，已有 session 可能收到错误或被停止。Apple 在 AVFoundation 中公开 AVCaptureDevice.requestAccess 这类授权入口，见 Apple AVCaptureDevice authorization。

Location 的敏感性来自行动轨迹和身份推断。一次位置请求包含坐标、精度级别、前台或后台、持续时间、触发条件和用户可见说明。Android 后台位置需要单独权限边界，且 Play policy 要求后台位置服务于核心功能；iOS 的 When In Use、Always、Precise Location 和后台位置提示形成类似的用户授权表面。架构阅读时应区分四个层次：App 是否声明能力，用户是否授权，系统服务是否允许当前生命周期状态访问，硬件或定位提供方是否给出结果。

Photos 的隐私边界从“读取媒体库”逐步细化到“用户选择的媒体”。Android Photo Picker 提供系统 UI，让用户选择要共享给 App 的图片或视频，并把访问范围收束到用户选中的媒体；官方文档明确描述其安全、内置、只授予所选媒体访问的作用，见 Android Photo picker。Apple 的 PhotosUI PHPickerViewController 也提供系统选择器入口，见 Apple PHPickerViewController。这类设计把数据暴露面从长期权限转为一次用户选择的资源集合。

Bluetooth 的隐私边界常被低估。蓝牙扫描结果可以暴露附近设备、店铺信标、车辆、穿戴设备和位置线索。Android 12 及以上把 BLUETOOTH_SCAN、BLUETOOTH_CONNECT 和 BLUETOOTH_ADVERTISE 拆成 Nearby devices 权限；如果 App 可以强声明蓝牙扫描不用于推导物理位置，可在 BLUETOOTH_SCAN 上设置 neverForLocation，见 Android Bluetooth permissions。这说明平台把“连接设备”和“推断位置”拆成不同风险面。

隐私撤销路径是移动 OS 架构中必须追踪的返回路径。用户在设置中撤销相机、麦克风、照片、位置或蓝牙权限后，授权状态会成为系统服务检查的一部分。App 下一次调用 API 时可能收到拒绝、空结果、降级精度、部分媒体集合或 session 错误。骑行 App 如果用户撤销后台位置授权，前台地图仍可能在使用期间显示定位，但锁屏后的路线记录会失去稳定来源；如果用户撤销照片访问，已选择的单张照片可能可继续通过持久 URI 或系统 picker 结果处理，新的媒体库扫描会失败。

隐私敏感能力的判断顺序可以固定为五步：先判断数据类型是否能暴露现实世界或个人轨迹，再看授权是否覆盖当前使用场景，接着看系统是否要求用户可见提示，然后看后台状态是否改变可用性，最后看撤销后是否有明确失败路径。这个顺序比直接询问“是否有权限”更稳定，因为移动平台会把权限、生命周期和可见性组合成最终能力。

4.5 Cellular / Wi-Fi 连接与 Power Policy​

连接策略同时受网络质量、费用模型、功耗模型和后台策略影响。Wi-Fi 通常适合大文件和批量同步，蜂窝适合移动场景和即时消息，但弱信号蜂窝会增加 modem 发射功率，漫游和计量网络会触发数据策略，后台网络活动还会受 Doze、App Standby、低数据模式和用户设置约束。骑行 App 的照片上传在前台点击后可立即尝试，在锁屏后台则会被系统纳入网络与电量共同调度。

移动 OS 看待网络请求时，会把请求拆成三个层级。第一层是 App 语义：即时聊天、导航纠偏、照片备份、日志上传、广告预取的用户价值不同。第二层是系统策略：是否前台、是否后台、是否有通知、是否使用后台传输 API、是否声明了网络约束。第三层是硬件状态：Wi-Fi 是否可用、蜂窝信号强度、是否漫游、是否计量网络、modem 是否因温控或飞行模式受限。最终结果可能是立即发包、等待 Wi-Fi、等待充电、降低并发、失败重试或由 push 唤醒短窗口。

Android 后台任务文档把 unmetered network 约束作为省电和减少数据成本的典型策略；Doze 文档进一步说明设备空闲时网络访问会被暂停，维护窗口中才允许处理 pending sync、job 和 alarm，见 Android Doze maintenance windows。因此，后台照片上传的正确架构不是循环重试，而是把上传表达成可调度工作，附带网络、充电和优先级约束，让系统在合适窗口执行。

Apple 公开能力中，background URLSession 和 BackgroundTasks 共同表达后台传输和后台处理。开发者提交任务或传输请求，系统在合适条件下继续或恢复；用户开启低数据模式、设备处于低电量、网络变化或 App 被用户终止时，执行机会会发生变化。公开 API 可说明请求形态，系统内部调度仍属于平台策略。阅读 Apple 连接路径时，应把 URLSession、BackgroundTasks、Core Location、push 和用户设置放在同一个状态图中，而非孤立分析一个网络 API。

弱网场景会放大功耗与温控问题。照片上传在 Wi-Fi 下可能主要消耗 CPU 加密、存储读取和无线传输；在弱蜂窝环境下，modem 长时间保持高功率状态，重传增加，CPU 处理更多超时和重试，用户仍看到进度停滞。系统可能延后后台传输、减少网络唤醒或在热状态升高时关停部分连接能力。AOSP thermal status 文档提到 emergency 状态下 modem 和 cellular data 这类功能可能被完全关闭，这说明连接能力也在温控保护链中。

连接策略的工程判断可以使用“可见性、时效性、数据量、网络类型、重试成本”五个维度。导航纠偏请求时效性高、数据量小，适合前台即时发送；照片原图上传数据量大、可延后，适合 Wi-Fi 或充电窗口；崩溃日志数据量小但用户不可见，适合后台批处理；实时安全通知用户价值高，可通过平台认可的高优先级推送获得短窗口。用这组维度拆解后，网络策略就不再只是“有网或没网”，而是系统资源预算的一部分。

4.6 Background Work、Wakeup 与系统调度限制​

Background work 指 App 在用户未直接操作界面时请求系统执行的工作。Wakeup 指 App 或系统事件把设备、CPU、网络或进程从低功耗状态唤醒。移动平台限制后台工作的核心原因是：唤醒成本会扩散到整机，单个 App 的频繁 alarm、wake lock、job、push、location update 或网络重试会让 CPU、modem、存储和传感器反复进入活跃状态，缩短续航并干扰其他 App 的公平执行。

Android 的后台执行能力可以分成几类。Alarm 适合时间点触发，JobScheduler / WorkManager 适合带约束的可延后工作，foreground service 适合用户可见且需要持续运行的任务，FCM 适合服务器到设备的消息触发，wake lock 适合在短时间内保持 CPU 醒着完成关键工作。Doze 中系统会暂停网络、忽略 wake lock、推迟标准 alarm、推迟 job 和 WorkManager 任务；这说明 wake lock 不是绕开系统电源策略的通道，它只是受系统策略管理的唤醒请求之一。

后台工作的版本边界需要明确。Android 6.0 起 Doze 和 App Standby 改变空闲设备与不活跃 App 的后台行为；Android 8.0 起后台位置更新频率受限；Android 10 起后台位置权限成为单独边界；Android 14 对频繁超时的任务有更严格后果，官方文档说明任务频繁 timeout 后系统可能把 App 放入 restricted standby bucket，见 Android task stop reasons。这些版本差异会直接改变同一代码在不同设备上的表现。

Apple 的后台执行公开入口包括 BackgroundTasks、后台 URLSession、后台位置、音频、VoIP push 等特定能力。平台会按用户行为、能耗、网络、任务类型和授权状态决定执行机会。一个普通后台刷新任务不能等同于持续后台进程；持续路线记录需要位置授权和后台模式，音频播放需要音频后台能力，文件上传需要系统传输入口。公开 API 的共同点是把后台执行声明成受管理的能力请求，由系统选择实际运行窗口。

骑行 App 的后台路径可以拆成三条：路线记录依赖 Core Location 或 Android location service 与后台授权；照片上传依赖可调度任务或后台传输；活动摘要生成依赖 CPU 处理和可延后 job。锁屏后，这三条路径会得到不同待遇。路线记录可能继续获得有限位置更新，照片上传可能等待网络和电量条件，摘要生成可以延后到充电或空闲窗口。把它们塞进一个常驻后台线程会与移动平台模型冲突，并导致任务被系统停止、进程被回收或用户看到耗电异常。

后台调度的失败表现需要从 App 视角复盘。常见现象包括：alarm 延后、job 未运行、任务运行后被停止、push 到达后只获得短窗口、foreground service 被用户关闭、位置更新频率降低、上传在锁屏后暂停、进程被回收后由系统重建。正确的排查顺序是先确认任务类型，再确认生命周期状态，然后检查权限和后台模式，接着检查电量、Doze、standby bucket、网络约束和 thermal state，最后看用户是否通过设置限制了后台刷新、定位、移动数据或电池使用。

4.7 Hardware、Service、App 之间的策略协调​

移动平台的最终行为由硬件状态、系统服务所有权、App 生命周期和用户设置共同决定。硬件提供真实能力和状态，driver / HAL / daemon 把能力接入系统，system service 持有资源所有权并执行权限与策略检查，Framework API 把结果呈现给 App，App 再把成功、失败或降级转成用户可见体验。约束模型的价值在于把这些层级放进同一条责任链。

下面的图展示骑行记录 App 请求持续记录与上传时的策略路径。图中每个分支都可能改变最终结果；它表达的是阅读顺序，不代表某个平台的完整内部实现。

这条路径的关键是服务所有权。相机服务决定哪一个进程持有 camera device，位置服务决定哪个调用者获得何种精度和频率，网络服务决定网络能力和策略，电源服务决定唤醒与空闲状态，thermal service 反馈热状态，调度器决定后台工作窗口。App 并不直接拥有硬件；App 通过 Framework API 提交意图，系统服务把意图映射到当前平台状态。

用户设置会覆盖很多技术判断。用户关闭后台 App 刷新、撤销位置权限、限制移动数据、开启省电模式、关闭蓝牙、选择仅共享部分照片、拒绝相机权限或强制停止 App 后，同一段代码会得到不同结果。系统服务通常会在调用入口检查这些状态，再返回错误、空结果、降级数据或延后任务。用户可见设置属于系统策略输入，不应在架构图中放到最后当作 UI 细节。

硬件并发也会改变结果。相机可能被系统相机、视频会议或扫码 App 占用；麦克风可能被通话、录音或语音助手占用；音频路由可能被蓝牙耳机、扬声器和车机切换；定位可能在低电量、高温、室内弱 GNSS 和用户关闭精确位置时降级。服务层负责把这些并发冲突转成排队、抢占、失败、降级或回调。App 看到的是 API 失败，真正的责任主体在资源所有者。

把本章模型迁移到任何移动能力时，可以使用七步判断：第一，能力涉及哪些硬件块；第二，App 当前处于前台、后台、锁屏、挂起还是被系统恢复；第三，用户授权是否覆盖当前用途和数据范围；第四，是否存在资源并发或独占；第五，电量、温控和连接状态是否收缩执行窗口；第六，平台要求使用哪一种受管理的后台能力；第七，失败表现是权限错误、资源占用、任务延后、结果降级还是进程回收。

回到贯穿材料：骑行记录 App 在屏幕亮、弱蜂窝、高温、锁屏和后台上传叠加时，系统不会只回答“允许或拒绝”。它可能继续给低频位置、暂停照片上传、降低 UI 刷新、停止图片压缩、延后 job、提示高温、限制蜂窝数据，并在用户再次打开 App 时恢复队列。这个组合结果正是移动平台约束模型的核心：App 请求能力，系统根据跨层状态输出策略化结果。

最小自检任务​

一个骑行 App 在前台记录路线并拍摄照片。用户随后锁屏，把手机放进口袋；此时设备温度升高，蜂窝信号变弱，用户还开启了省电模式。App 希望继续记录路线、压缩照片、上传原图并接收服务器推送。请写出这四个动作的系统路径、主要策略检查点、可能的降级或失败表现，并说明你会优先保留哪一个动作。

答案要点​

路线记录的路径是 App 位置请求进入 Framework API，由位置服务检查调用者身份、前台或后台状态、位置授权、后台能力、精度设置、电量和温控状态，再通过定位提供方返回结果。锁屏和省电模式下，系统可能降低位置更新频率；如果后台位置授权缺失，路线记录会在后台路径中失败或只保留前台能力。这个动作最接近骑行 App 的核心用户价值，应优先保留，但应降低采样频率并减少 UI 相关工作。

照片压缩的路径是 App 把相机结果交给 CPU、GPU、NPU 或编码器相关能力处理。系统会受到热状态、电量和后台调度限制影响；高温下应停止高成本压缩或降低分辨率，等待设备降温或回到前台。照片压缩可以延后，因为它不影响路线连续性。

原图上传的路径是 App 网络请求进入系统网络栈和后台传输或任务调度能力。弱蜂窝、省电模式、后台状态和高温会共同收缩上传窗口；系统可能等待 Wi-Fi、等待充电、延后 job、暂停传输或让任务超时。原图上传应转成可恢复队列，附带网络和电量约束。

服务器推送的路径是平台推送服务收到消息后，根据优先级、用户可见性、Doze 或后台策略给 App 一个短执行机会。适合用于用户可见通知或轻量状态同步，不适合承载持续路线记录和大文件上传。高优先级推送应服务明确用户可见结果。

整体判断顺序是先保留用户正在依赖的核心能力，再降低高功耗和高热量任务，然后把可延后任务交给系统调度，最后把失败表现转成可恢复状态。这个场景中，路线记录优先级最高，照片压缩和原图上传可延后，推送只作为触发和通知入口。

本章知识点总结​

  • 约束模型：移动平台会把 App 能力请求放入电量、温控、隐私、连接、后台和用户设置共同构成的策略链中判断。
  • 电量预算：系统评估的是 CPU、GPU、modem、display、camera、sensor 和后台唤醒叠加后的整机成本。
  • 前台优先：用户正在等待结果的前台路径通常获得更高执行机会，后台路径需要进入受管理调度。
  • 任务约束：后台同步、上传和计算应表达充电、网络、空闲和时效性约束，让系统选择执行窗口。
  • 温控路径：温度状态从硬件传感器进入 HAL、服务和 App 回调，最终影响频率、帧率、相机、网络和后台任务。
  • 热降级：高温时应优先保留核心用户功能，降低 UI、编码、上传和模型推理等可延后负载。
  • 传感器常驻：持续感知依赖采样率、批处理、低功耗硬件、后台授权和系统服务分发。
  • 位置双约束：位置能力同时受功耗和隐私约束，后台位置需要单独分析生命周期、授权和更新频率。
  • 隐私硬件：Camera、Microphone、Location、Photos 和 Bluetooth 都需要追踪授权、指示器、数据范围和撤销路径。
  • 连接策略：蜂窝、Wi-Fi、漫游、弱网、计量网络和低数据设置会改变后台传输和即时请求的结果。
  • 唤醒预算：alarm、job、push、wake lock、foreground service 和 BGTask 都是受系统管理的唤醒入口。
  • 服务所有权：App 通过 Framework 提交意图，系统服务持有资源状态并决定执行、降级、延后或拒绝。
  • 用户设置：权限撤销、省电模式、后台刷新限制、数据限制和强制停止都会成为能力调用的策略输入。
  • 判断顺序：先看硬件块，再看生命周期、授权、并发、电量温控连接、后台能力和用户可见失败结果。