2021年适配API18到30的Android闹钟/定时器应用最新开发方案是什么？

核心定时调度逻辑 #

这部分是精准触发的核心，原生AOSP的DeskClock应用就是依赖该层级的接口优先级实现无延迟触发，不同API版本对应调用不同的最高优先级定时接口：

• API 18~22：调用AlarmManager.setExact(AlarmManager.RTC_WAKEUP, 触发时间戳, 触发PendingIntent)，该版本无系统定时节流逻辑，只要声明WAKE_LOCK权限即可保证休眠场景下正常触发
• API 23~28：调用AlarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, 触发时间戳, 触发PendingIntent)，该接口可以绕过Doze模式第一阶段的空闲限制，仅针对单次非高频定时场景有效，完全满足时钟类应用的提醒需求
• API 29~30：优先调用AlarmManager.setAlarmClock(AlarmManager.AlarmClockInfo(触发时间戳, 点击闹钟跳转的PendingIntent), 触发PendingIntent)，该接口是系统为闹钟类应用开放的最高优先级调度接口，不受电源管理节流、Doze模式、应用待机分组限制，即使应用被后台杀死、设备深度休眠，到点也会被系统主动拉起触发，是DeskClock实现零延迟的核心逻辑。

必要权限与配置 #

需要提前在应用中完成以下配置，否则会出现概率性不触发问题：

• 基础唤醒权限：在Manifest中声明<uses-permission android:name="android.permission.WAKE_LOCK" />，保证触发时可以唤醒CPU执行后续逻辑
• 前台服务权限：API26及以上版本声明<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />，触发后播放音频等长时间运行的逻辑需要依托前台服务执行，避免被系统回收
• 忽略电池优化申请：首次启动时引导用户开启应用的「忽略电池优化」权限，调用逻辑参考：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Intent intent = new Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
    intent.setData(Uri.parse("package:" + getPackageName()));
    startActivity(intent);
}

触发后可靠性保障 #

定时触发后的逻辑需要符合系统后台限制要求，避免触发到一半被系统终止：

• 优先用BroadcastReceiver接收定时触发的PendingIntent，比Service响应速度更快，不受后台服务启动限制
• 接收到广播后立即获取WakeLock锁，避免CPU重新休眠导致逻辑中断，参考代码：

PowerManager powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "AppName::AlarmWakeLock");
// 最长持有10分钟，避免长时间持有被系统判定为耗电异常
wakeLock.acquire(10 * 60 * 1000L);

• 播放音频、弹出通知等逻辑如果运行时长超过10秒，必须启动前台服务执行，前台服务需要绑定非0的id对应通知，符合API26+的后台运行限制要求。

常见坑点规避 #

• 不要使用WorkManager、JobScheduler实现精准定时，两者都是系统调度的非准时接口，最小误差在10分钟以上，仅适用于非准时的后台任务
• 不要频繁调用定时接口，同一个定时任务仅设置一次，频繁调用setExact类接口会被系统判定为恶意应用，加入节流黑名单，导致后续所有定时任务都被延迟
• 国产ROM额外适配：小米、华为、OPPO等厂商有自研的后台管理机制，需要单独引导用户开启应用的「自启动权限」「后台活动权限」，否则原生逻辑正常也会被厂商定制规则拦截。

内容的提问来源于stack exchange，提问作者The_Sympathizer