uni-app无法真正实现“保活”，本质是按需申请系统允许的后台能力；iOS需配置UIBackgroundModes（如audio、location）并配合原生调用，Android唯一合规方式是启动带通知的前台服务。
uni-app 无法真正实现“保活”——所谓后台持续运行，本质是按需申请系统允许的后台能力，不是让进程永不被杀。 iOS 和 Android 对后台行为有严格限制，强行保活会触发系统强制清理、审核拒批，甚至被厂商列入黑名单。真正可行的是：明确业务场景 → 申请对应后台能力 → 配合系统规则做最小化适配。
iOS 后台播放音频或定位必须配置 UIBackgroundModes
如果你的应用需要在切到后台后继续播放音乐或持续上报位置（比如导航、运动记录），iOS 要求你显式声明能力，否则切后台立即暂停。这不是可选优化，而是硬性准入条件。
- 打开
manifest.json，切换到「源码视图」 - 在
"app-plus"->"distribute"->"ios"节点下添加UIBackgroundModes字段 - 值为字符串，多个能力用英文逗号分隔，例如：
"UIBackgroundModes":"audio,location" - 仅支持有限能力：
audio（后台音频）、location（后台定位）、fetch（后台数据拉取，但实际调度不可控）等，UIBackgroundModes文档里没列的，填了也无效 - 注意：开启
location后，必须在代码中调用plus.geolocation.watchPosition并传入{enableHighAccuracy:true, background:true}，否则系统不会真正维持后台定位
Android 后台静默更新需要 WRITE_EXTERNAL_STORAGE + REQUEST_INSTALL_PACKAGES
后台下载 APK 并自动安装，核心卡点不在“后台运行”，而在文件写入和安装权限。Android 10+（targetSdkVersion ≥ 29）下，WRITE_EXTERNAL_STORAGE 已失效，必须改用作用域存储或申请 MANAGE_EXTERNAL_STORAGE（但 Google Play 不接受该权限，除非特殊理由）。
- manifest.json 中声明必要权限：
"android.permission.WRITE_EXTERNAL_STORAGE"（兼容旧版）、"android.permission.REQUEST_INSTALL_PACKAGES"（安装 APK 必须） - 运行时必须动态申请：
plus.android.requestPermissions(['android.permission.WRITE_EXTERNAL_STORAGE', 'android.permission.REQUEST_INSTALL_PACKAGES']) - 下载文件建议存到应用专属目录（
plus.io.convertLocalFileSystemURL('_doc/xxx.apk')），避免依赖外部存储，规避 Android 11+ 的限制 - 调用
plus.runtime.install安装前，需确保 APK 文件路径可被原生层读取；若用uni.downloadFile下载到临时路径，要先moveTo到持久化位置
别信“小米/华为自启动=保活”，那是用户侧手动干预
所谓“设置省电策略为无限制”“开启自启动”“允许后台弹出”，全是用户在系统设置里做的白名单操作，不是代码能控制的。这些操作对开发毫无意义——你不能要求每个用户都手动点五六次设置。
- 这些设置只影响单台设备，无法打包进 App，也不能通过
uni.openSetting直达（uni.openSetting在 Android 上只能跳转到本 App 权限页，不支持跳省电管理页） - 厂商 ROM 对后台管控越来越严，小米 HyperOS、华为鸿蒙 NEXT 均默认禁止非前台服务长时间运行，即使开了自启动，30 分钟后仍可能被冻结
- 真正该做的是：用
plus.android.foregroundService启动前台服务（带常驻通知），这是 Android 唯一被系统认可的“合法长期运行”方式，但必须展示通知，且用户可手动关闭
uni.authorize + uni.openSetting 不是保活方案，只是权限引导链路
很多开发者误以为反复调用 uni.authorize 或 uni.openSetting 能“唤醒”后台，其实它们只解决权限授权问题，和进程存活完全无关。
-
uni.authorize({scope:'scope.backgroundAudio'})在 iOS 上根本不存在，Android 上也不起作用；后台音频能力靠的是UIBackgroundModes配置 +uni.createInnerAudioContext播放时设obeyMuteSwitch: false -
uni.openSetting()只应在用户明确拒绝某项权限（如定位）后调用，且必须前置判断uni.getAuthSetting返回对应scope.xxx === false，否则在 iOS 上静默失败，Android 上可能报错 - 切后台再切回来时，务必监听
onShow并重新检查权限状态，否则 UI 显示与真实权限脱节——这是最常被忽略的生命周期陷阱
真正的难点从来不是“怎么写代码”，而是理解每个平台对“后台”的定义差异：iOS 把能力拆得极细，Android 把控制权交给用户和厂商。任何试图绕过系统规则的“保活技巧”，最终都会变成上线前的雷。
