简介一套基于Android平台的四合一应用源码集闹钟、秒表、倒计时、时钟于一体面向Android开发者与毕业设计学生可作为理解Android核心组件、UI交互及综合项目架构的实战样例也便于功能扩展与二次开发。包内共335个文件体积仅4.3MB包含147个png界面切图、34个java逻辑源码、40个xml布局与配置、100个class编译产物同时带有ogg音频、jar依赖库及可直接安装的apk文件便于对照源码理解运行效果。已有258人学习/下载。源码覆盖多个关键知识点闹钟模块基于AlarmManager与PendingIntent实现定时触发及广播接收秒表利用Chronometer实时计时倒计时使用CountDownTimer处理分段回调时钟通过系统时间获取与界面刷新完成显示。资源中还包含WheelView选择器、AlarmAlertFullScreen全屏提醒界面等模块体现了从布局定义、资源引用到Activity生命周期管理的完整开发流程能为毕业设计文档撰写与功能演示提供直接支撑。1. 四合一 Android 源码看着简单拆开全是生命周期问题把闹钟、秒表、倒计时、时钟四个功能塞进同一个工程标签又是“毕业设计”很多人第一反应是“这有什么难的四个页面拼个 Tab 就完了”。但真正把一个四合一源码 zip 导入 Android Studio 之后要回答的问题比写页面多得多闹钟设置了是不是必须把应用杀掉也不影响倒计时在手机进入低功耗模式后还准不准秒表切到后台再回来为什么多了几秒。这四个模块对应到 Android 端的 Handler、AlarmManager、BroadcastReceiver、Chronometer、CountDownTimer 这些基础组件每一组都有各自的生命周期和时间源约束。下面按我接手这类源码时的处理顺序展开先把工程骨架的可改范围摸清再逐个模块确认实现最后用边界条件验证它能不能过答辩这一关。2. 拿到四合一 Android 源码后的工程骨架解压、编译、改版本参数2.1 先看包结构确定模块拆分粒度这类项目很少用复杂架构。常见做法是app/src/main/java下面按activity、fragment、receiver、service分包一个MainActivity当容器里面用 Fragment 或 ViewPager 放时钟、秒表、倒计时三个页面闹钟因为涉及列表和编辑单独拆成AlarmListActivity和AlarmEditActivity。这种划分对毕业设计很合适交给答辩老师看没有理解成本真要加功能也容易定位文件。这里最值得看的不是某个 Activity 里写了什么而是AndroidManifest.xml里注册了哪些组件。闹钟的BroadcastReceiver必须显式注册否则收不到 AlarmManager 发出的启动信号BOOT_COMPLETED接收器不能靠动态注册必须写进 manifest 并申请权限如果秒表需要长时间后台运行前台服务类型也要提前确认。我一般会把组件和职责列成一张表再对照源码逐项核对组件常见职责需要盯住的点时钟页面显示当前时间onResume 启动刷新onPause 移除回调闹钟接收器接收 AlarmManager 广播锁屏弹出精确闹钟权限重启恢复秒表页面计时 / 暂停 / 复位时间源用 elapsedRealtime不依赖系统时间倒计时页面按设置时间递减onTick 掉帧处理后台功耗控制如果压缩包里连BOOT_COMPLETED接收器都没有那闹钟重启后必丢这一条在开题阶段就要先记下来因为后续所有代码都要往这个接收器上靠。顺便提一个中文源码包高概率出现的问题注释乱码。打开某个 Java 文件看到中文注释变成大段“锟斤拷”不是 Android Studio 坏了而是工程文件是 GBK 编码Studio 默认按 UTF-8 读。要在File - Settings - Editor - File Encodings里把 Global Encoding 和 Project Encoding 都改成 UTF-8 后重新打开文件。这和“android studio 怎么设置中文”这类 IDE 界面汉化完全无关改菜单语言治不好编码问题。2.2 用 Gradle 命令代替 Android Studio 图形界面验证工程完整性拿到源码的第一步我习惯不直接双击导入 Android Studio而是在终端里先把编译链路跑通。因为很多四合一源码是从别的机器上整体拷过来的SDK 路径、Gradle 版本都可能带着本机的绝对路径图形界面会自动下载依赖反而会把真正的编译错误盖住。先在终端解压并构建unzip android应用源码闹钟秒表倒计时时钟四合一源码-IT计算机-毕业设计.zip -d fourinone cd fourinone ls -la ./gradlew :app:assembleDebug第一条把压缩包解压到fourinone目录-d指定目标目录避免解出一堆散文件ls -la是确认工程根目录下有没有gradlew脚本和settings.gradle这两者缺一个都不能叫完整工程。最后一条assembleDebug生成调试签名的 APK跳过单元测试和 lint只验证“源码能不能编译、打包、再签名”这条主链路。如果提示SDK location not found就在工程根目录的local.properties里补一行sdk.dir/你的Android SDK路径。Android Studio 里能自动识别 SDK命令行构建必须靠这个文件。这个文件是本机路径配置不要提交到 git每换一台机器都要重新生成。2.3 先改掉三个和 Android 版本相关的默认配置四合一源码的build.gradle经常带着旧版本 Stamp。最常见的三个问题是compileSdk低于 31精确闹钟权限无法声明targetSdk低于 31在 Android 12 上无法请求SCHEDULE_EXACT_ALARM没有运行时申请 Android 13 的通知权限导致闹钟响铃时只弹出页面却无法推送通知。这三个问题分别对应编译期、安装期和运行期一个都不能省。针对闹钟模块最直接的做法是在AndroidManifest.xml里先声明权限uses-permission android:nameandroid.permission.SCHEDULE_EXACT_ALARM / uses-permission android:nameandroid.permission.USE_EXACT_ALARM / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS / uses-permission android:nameandroid.permission.RECEIVE_BOOT_COMPLETED /SCHEDULE_EXACT_ALARM对应 API 31USE_EXACT_ALARM是 API 34 引入的只给日历、闹钟这类核心功能用。普通应用不要两个都写滥用会被应用市场审核盯上。POST_NOTIFICATIONS必须配合运行时弹窗申请单靠 manifest 声明不生效。RECEIVE_BOOT_COMPLETED是普通权限声明即可但国内部分 ROM 会在“自启动管理”里默认关闭要在真机上单独检查。这一步做完顺手就把 Android SDK 版本差异和“精确闹钟权限”这两块知识写进论文里答辩时被问到的概率很高。3. 时钟和闹钟模块的实现取舍Handler 与 AlarmManager 的边界在哪3.1 时钟页面每秒刷新用 Handler 定时回调不要用 while 循环时钟页面最简单也最容易写错。有人用while(true)加Thread.sleep(1000)更新 UI在线程里改 View 直接崩有人用Timer.schedule控制刷新离开页面时忘了cancel线程池一直挂着页面越多泄漏越明显。四合一源码里出现这种代码我的建议是重写。一个合理的方案是用主线程 Handler 的postDelayed循环刷秒private final Handler clockHandler new Handler(Looper.getMainLooper()); private final Runnable clockRunnable new Runnable() { Override public void run() { clockText.setText( DateFormat.format(HH:mm:ss, System.currentTimeMillis()).toString() ); clockHandler.postDelayed(this, 1000); } }; Override protected void onResume() { super.onResume(); clockHandler.post(clockRunnable); } Override protected void onPause() { super.onPause(); clockHandler.removeCallbacks(clockRunnable); }postDelayed只是告诉主线程“下一次什么时候再来看”它不会一直占着 CPU。onResume里用post立即执行一次保证页面一进来就有正确时间onPause里用removeCallbacks把回调从消息队列里去掉页面切到后台后就不再执行。显示文本时直接读System.currentTimeMillis()而不是维护一个累加秒数即使某个回调被系统延迟了下一次显示出来的时间依然是准的。3.2 闹钟设置RTC_WAKEUP 和 setExactAndAllowWhileIdle 配合闹钟模块在四合一源码里的定位最特殊其他三个功能都是用户打开页面才工作闹钟必须应用不在前台、屏幕熄灭、甚至系统进入低功耗模式时也能在约定时刻唤醒。这不是页面代码能解决的要依赖AlarmManager。设置一个一次性闹钟的常见写法是AlarmManager alarmManager (AlarmManager) getSystemService(Context.ALARM_SERVICE); Intent intent new Intent(this, AlarmReceiver.class); intent.putExtra(alarmId, alarmId); long triggerAtMillis calendar.getTimeInMillis(); PendingIntent pendingIntent PendingIntent.getBroadcast( this, alarmId, intent, PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE ); if (Build.VERSION.SDK_INT Build.VERSION_CODES.S !alarmManager.canScheduleExactAlarms()) { // API 31 以上需要先引导用户到“闹钟和提醒”页面开启权限 return; } alarmManager.setExactAndAllowWhileIdle( AlarmManager.RTC_WAKEUP, triggerAtMillis, pendingIntent );这里容易踩的坑有三个。第一PendingIntent的requestCode要使用闹钟的 ID不能每次传 0否则新建的闹钟会把旧的顶掉最后只留下一条。第二FLAG_IMMUTABLE在 Android 12 必须加一些高版本设备上缺少它直接抛SecurityException。第三RTC_WAKEUP表示触发时把设备从休眠状态拉起来如果换成RTC屏幕熄灭后闹钟不会响这正是很多源码“在模拟器上能跑、真机锁屏就哑”的原因。这几个参数我一般会画成一张排错表方便答辩证人问到底参数常犯错误作用requestCode一直传 0和闹钟 ID 一一对应决定 PendingIntent 是否复用triggerAtMillis用 currentTimeMillis delay表示触发时刻的绝对时间戳单位毫秒type误用 RTC响铃场景必须用 RTC_WAKEUPRTC 不唤醒休眠设备flags不加 FLAG_IMMUTABLEAPI 31 不加会抛异常应用直接崩溃3.3 响铃界面用 Activity而不是 Dialog并处理锁屏显示闹钟时间到之后AlarmReceiver收到广播需要唤起一个全屏界面。常见做法是在BroadcastReceiver的onReceive里直接启动AlarmActivitypublic class AlarmReceiver extends BroadcastReceiver { Override public void onReceive(Context context, Intent intent) { Intent activityIntent new Intent(context, AlarmActivity.class); activityIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(activityIntent); } }从 BroadcastReceiver 启动 Activity必须加FLAG_ACTIVITY_NEW_TASK因为接收器没有 Activity 栈不加会在高版本上报Calling startActivity() from outside of an Activity context requires FLAG_ACTIVITY_NEW_TASK。锁屏显示还依赖 AlarmActivity 在onCreate里设置窗口标志getWindow().addFlags( WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED | WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON | WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON );FLAG_KEEP_SCREEN_ON只在屏幕亮着时阻止熄屏FLAG_TURN_SCREEN_ON负责把屏幕点亮FLAG_SHOW_WHEN_LOCKED在 Android 10 以上已废弃但对老设备仍然有效。工程里如果targetSdk没拉到特别新这三个标志组合是兼容面最广的方案。3.4 重启丢闹钟用本地存储保存配置在 BOOT_COMPLETED 里重建普通应用设置过的闹钟系统重启后不会自动保留。四合一源码里如果看到设置闹钟只放到内存、没有监听开机广播就可以补这一段public class BootReceiver extends BroadcastReceiver { Override public void onReceive(Context context, Intent intent) { if (!Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) { return; } // 从本地存储读取闹钟列表逐条重新 setExactAndAllowWhileIdle ListAlarmItem alarms AlarmRepository.load(context); for (AlarmItem alarm : alarms) { scheduleExactAlarm(context, alarm); } } }BOOT_COMPLETED接收器需要先在 manifest 里注册。数据存到SharedPreferences还是数据库都行关键是重建闹钟时要用同一个alarmId否则 UI 上显示“已开启”的闹钟实际上对应一个全新的 PendingIntent取消旧闹钟时会出现删不掉的残留。调试这段逻辑时用adb shell dumpsys alarm | grep 包名能看到下一条触发时间和 PendingIntent 的创建次数比反复改代码重装靠谱得多。4. 秒表和倒计时的计时精度为什么两个模块不能共用同一套时间源4.1 秒表实现Chronometer 的基准时间是 elapsedRealtime 而不是系统当前时间秒表这个功能很多人会直接用System.currentTimeMillis()相减。但这个值在用户手动修改系统时间、网络对时、时区切换时会跳变秒表数字突然多了几个小时就很奇怪。Android 专门为这种“计算间隔”的场景提供了SystemClock.elapsedRealtime()它表示设备开机以来的毫秒数不受系统时间设置影响。一个可用的秒表用自带的Chronometer组件能省掉大部分刷新逻辑Chronometer android:idid/chronometer android:layout_widthwrap_content android:layout_heightwrap_content android:textSize48sp android:format%s /Chronometer chronometer findViewById(R.id.chronometer); long base SystemClock.elapsedRealtime() - savedElapsedMillis; chronometer.setBase(base); chronometer.start();Chronometer内部显示逻辑基于elapsedRealtimesetBase传入的是“当作 0 点的时间戳”。秒表暂停时要把elapsedMillis保存起来恢复时用SystemClock.elapsedRealtime() - savedElapsedMillis重新算一个基准直接沿用旧的基准会导致时间翻倍。如果还要展示毫秒需要调用setOnChronometerTickListener自己格式化默认format%s只显示到秒。顺便说一个容易被追问的点如果秒表页放了个ProgressBar表示“已跑时长占目标时长的比例”进度更新也要放在同一个onChronometerTick回调里而不是再开一个定时器。两个定时器同时走页面一卡进度条和文字会对不上。4.2 倒计时实现CountDownTimer 的 onTick 延迟用“算剩余时间”兜底倒计时比秒表难在结束时刻固定、中间还要平滑展示。CountDownTimer是 Android SDK 自带的封装几行代码就能把 ProgressBar 和剩余时间串起来long totalMillis 5 * 60 * 1000L; CountDownTimer timer new CountDownTimer(totalMillis, 1000) { Override public void onTick(long millisUntilFinished) { progressBar.setProgress((int) (millisUntilFinished / 1000)); textView.setText(剩余 millisUntilFinished / 1000 秒); } Override public void onFinish() { textView.setText(时间到); } }; timer.start();第二个参数是interval这里传 1000 毫秒但系统并不保证每隔一秒都刚好回调。Doze 模式下屏幕熄灭后onTick被推迟几秒甚至几十秒都是正常的。所以最终时间显示要以millisUntilFinished为准不要在回调里写remaining - 1000否则任何一次回调延迟都会让剩余时间越走越慢。这里有一个方向性错误经常出现以为倒计时只能靠CountDownTimer。其实它只是把手动 Handler 封装了一层真正的倒计时只依赖一个结束时间戳。可以在开始时记录long endTime SystemClock.elapsedRealtime() totalMillis;然后在界面刷新时用endTime - SystemClock.elapsedRealtime()计算剩余时间。屏幕亮着时一秒一刷屏幕灭了被系统拖住也没关系每次刷新都从endTime重新算差显示永远是准的。闹钟级别的结束提醒仍然由AlarmManager负责这里单独靠页面回调只能满足前台场景。4.3 四合一里的时间源分工时钟日历时间、计时用开机时钟四个模块放在一个应用里最值得记住的分工是面向用户展示的“现在几点”、闹钟触发点用System.currentTimeMillis()秒表和倒计时的“经过了多久”“还剩多久”用SystemClock.elapsedRealtime()。时间源重启后修改系统时间适合模块System.currentTimeMillis()按新时间重算受影响可能跳变时钟、闹钟触发点、日期SystemClock.elapsedRealtime()重新从 0 开始但差值不变不影响秒表、倒计时、动画时长这个分工看起来基础但源码里经常混用。有人在秒表里记录startMillis System.currentTimeMillis()下一次开机数据就没意义有人在闹钟设置里用SystemClock.elapsedRealtime() delay当触发时间结果重启后闹钟直接丢。AlarmManager 的RTC类型跟currentTimeMillis对应ELAPSED_REALTIME跟elapsedRealtime对应顺序颠倒重启和改系统时间都是坑。如果界面同时保存一个绝对时间戳和一个相对剩余时长修改系统时间的场景会更容易排查闹钟触发点用绝对时间倒计时显示用相对值两侧各取所长不会互相污染。5. 毕业设计答辩前用 adb 把闹钟、秒表、倒计时一起压一遍5.1 用 dumpsys 验证闹钟是否真的排进了系统队列模拟器上测试的价值有限因为 Doze 模式在模拟器上很弱真机才是最终验收环境。连接真机后先安装 Debug 包再设置一个 2 分钟后的闹钟然后用dumpsys查系统里的闹钟队列adb install -r app-debug.apk adb shell am start -n com.example.fourinone/.MainActivity adb shell dumpsys alarm | grep -A 5 com.example.fourinone这里的包名要换成build.gradle里的applicationId实际值。dumpsys alarm输出里会列出下一次触发时间、触发类型和待发送的PendingIntent。如果看不到本包的 Alarm 记录说明AlarmManager调用没有生效先查requestCode是否和 PendingIntent 保持一致如果能看见但时间不对检查传入setExactAndAllowWhileIdle的时间戳毫秒还是秒错一个数量级整个排程都会飘。5.2 强制进入 Doze再观察倒计时和闹钟的表现Android 提供了强制进入低功耗模式的命令不需要把手机放桌上等几个小时待机adb shell dumpsys deviceidle force-idle adb shell dumpsys deviceidle unforce进入force-idle后把倒计时设成 2 分钟锁屏放在桌上。到时间后重新亮屏如果剩余时间出现跳变说明倒计时用的是“每次减固定值”而不是“结束时间戳减当前时间”如果连结束提醒都没触发说明闹钟没有走setExactAndAllowWhileIdle这条精确路线。这个结果在答辩报告里是很好的性能数据比口头说“我优化过”有说服力。测试完记得执行unforce否则手机会一直停在这个低功耗状态后面 apk 更新都可能变得迟钝。5.3 时间跳变、横竖屏切换、快速连点三个边界秒表和倒计时共同要防的是系统改时间。断开网络连接把系统时间往后调两小时切回秒表页面。时间源写错的应用这一下会露出破绽秒表多跑两小时倒计时直接归零。正确实现下秒表受elapsedRealtime保护不会受任何影响。横竖屏切换主要看状态恢复。页面销毁重建后秒表是否从暂停前的值继续倒计时有没有从头开始进度条进度和文字是否同步。建议在onSaveInstanceState里保存elapsedMillis和倒计时的endTime在onCreate里先恢复再开始刷新否则转一次屏幕计时就从零再来答辩现场演示时非常尴尬。快速连点“开始”“暂停”“复位”看是否出现负值终点是格式化拼接完不出现-1:59。最后一招是打包成 release APK关掉 Android Studio 的 Instant Run 再走一遍完整流程。毕业设计现场演示最怕遇到“有改动请等待重新构建”的提示先用 release 包把整个流程走通现场压力会小很多。本文还有配套的精品资源点击获取 
长河君 · 2026/9/12 16:30:52 · 阅读 1.2k Android四合一源码解析：闹钟、秒表、倒计时与时钟的生命周期管理
简介一套基于Android平台的四合一应用源码集闹钟、秒表、倒计时、时钟于一体面向Android开发者与毕业设计学生可作为理解Android核心组件、UI交互及综合项目架构的实战样例也便于功能扩展与二次开发。包内共335个文件体积仅4.3MB包含147个png界面切图、34个java逻辑源码、40个xml布局与配置、100个class编译产物同时带有ogg音频、jar依赖库及可直接安装的apk文件便于对照源码理解运行效果。已有258人学习/下载。源码覆盖多个关键知识点闹钟模块基于AlarmManager与PendingIntent实现定时触发及广播接收秒表利用Chronometer实时计时倒计时使用CountDownTimer处理分段回调时钟通过系统时间获取与界面刷新完成显示。资源中还包含WheelView选择器、AlarmAlertFullScreen全屏提醒界面等模块体现了从布局定义、资源引用到Activity生命周期管理的完整开发流程能为毕业设计文档撰写与功能演示提供直接支撑。1. 四合一 Android 源码看着简单拆开全是生命周期问题把闹钟、秒表、倒计时、时钟四个功能塞进同一个工程标签又是“毕业设计”很多人第一反应是“这有什么难的四个页面拼个 Tab 就完了”。但真正把一个四合一源码 zip 导入 Android Studio 之后要回答的问题比写页面多得多闹钟设置了是不是必须把应用杀掉也不影响倒计时在手机进入低功耗模式后还准不准秒表切到后台再回来为什么多了几秒。这四个模块对应到 Android 端的 Handler、AlarmManager、BroadcastReceiver、Chronometer、CountDownTimer 这些基础组件每一组都有各自的生命周期和时间源约束。下面按我接手这类源码时的处理顺序展开先把工程骨架的可改范围摸清再逐个模块确认实现最后用边界条件验证它能不能过答辩这一关。2. 拿到四合一 Android 源码后的工程骨架解压、编译、改版本参数2.1 先看包结构确定模块拆分粒度这类项目很少用复杂架构。常见做法是app/src/main/java下面按activity、fragment、receiver、service分包一个MainActivity当容器里面用 Fragment 或 ViewPager 放时钟、秒表、倒计时三个页面闹钟因为涉及列表和编辑单独拆成AlarmListActivity和AlarmEditActivity。这种划分对毕业设计很合适交给答辩老师看没有理解成本真要加功能也容易定位文件。这里最值得看的不是某个 Activity 里写了什么而是AndroidManifest.xml里注册了哪些组件。闹钟的BroadcastReceiver必须显式注册否则收不到 AlarmManager 发出的启动信号BOOT_COMPLETED接收器不能靠动态注册必须写进 manifest 并申请权限如果秒表需要长时间后台运行前台服务类型也要提前确认。我一般会把组件和职责列成一张表再对照源码逐项核对组件常见职责需要盯住的点时钟页面显示当前时间onResume 启动刷新onPause 移除回调闹钟接收器接收 AlarmManager 广播锁屏弹出精确闹钟权限重启恢复秒表页面计时 / 暂停 / 复位时间源用 elapsedRealtime不依赖系统时间倒计时页面按设置时间递减onTick 掉帧处理后台功耗控制如果压缩包里连BOOT_COMPLETED接收器都没有那闹钟重启后必丢这一条在开题阶段就要先记下来因为后续所有代码都要往这个接收器上靠。顺便提一个中文源码包高概率出现的问题注释乱码。打开某个 Java 文件看到中文注释变成大段“锟斤拷”不是 Android Studio 坏了而是工程文件是 GBK 编码Studio 默认按 UTF-8 读。要在File - Settings - Editor - File Encodings里把 Global Encoding 和 Project Encoding 都改成 UTF-8 后重新打开文件。这和“android studio 怎么设置中文”这类 IDE 界面汉化完全无关改菜单语言治不好编码问题。2.2 用 Gradle 命令代替 Android Studio 图形界面验证工程完整性拿到源码的第一步我习惯不直接双击导入 Android Studio而是在终端里先把编译链路跑通。因为很多四合一源码是从别的机器上整体拷过来的SDK 路径、Gradle 版本都可能带着本机的绝对路径图形界面会自动下载依赖反而会把真正的编译错误盖住。先在终端解压并构建unzip android应用源码闹钟秒表倒计时时钟四合一源码-IT计算机-毕业设计.zip -d fourinone cd fourinone ls -la ./gradlew :app:assembleDebug第一条把压缩包解压到fourinone目录-d指定目标目录避免解出一堆散文件ls -la是确认工程根目录下有没有gradlew脚本和settings.gradle这两者缺一个都不能叫完整工程。最后一条assembleDebug生成调试签名的 APK跳过单元测试和 lint只验证“源码能不能编译、打包、再签名”这条主链路。如果提示SDK location not found就在工程根目录的local.properties里补一行sdk.dir/你的Android SDK路径。Android Studio 里能自动识别 SDK命令行构建必须靠这个文件。这个文件是本机路径配置不要提交到 git每换一台机器都要重新生成。2.3 先改掉三个和 Android 版本相关的默认配置四合一源码的build.gradle经常带着旧版本 Stamp。最常见的三个问题是compileSdk低于 31精确闹钟权限无法声明targetSdk低于 31在 Android 12 上无法请求SCHEDULE_EXACT_ALARM没有运行时申请 Android 13 的通知权限导致闹钟响铃时只弹出页面却无法推送通知。这三个问题分别对应编译期、安装期和运行期一个都不能省。针对闹钟模块最直接的做法是在AndroidManifest.xml里先声明权限uses-permission android:nameandroid.permission.SCHEDULE_EXACT_ALARM / uses-permission android:nameandroid.permission.USE_EXACT_ALARM / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS / uses-permission android:nameandroid.permission.RECEIVE_BOOT_COMPLETED /SCHEDULE_EXACT_ALARM对应 API 31USE_EXACT_ALARM是 API 34 引入的只给日历、闹钟这类核心功能用。普通应用不要两个都写滥用会被应用市场审核盯上。POST_NOTIFICATIONS必须配合运行时弹窗申请单靠 manifest 声明不生效。RECEIVE_BOOT_COMPLETED是普通权限声明即可但国内部分 ROM 会在“自启动管理”里默认关闭要在真机上单独检查。这一步做完顺手就把 Android SDK 版本差异和“精确闹钟权限”这两块知识写进论文里答辩时被问到的概率很高。3. 时钟和闹钟模块的实现取舍Handler 与 AlarmManager 的边界在哪3.1 时钟页面每秒刷新用 Handler 定时回调不要用 while 循环时钟页面最简单也最容易写错。有人用while(true)加Thread.sleep(1000)更新 UI在线程里改 View 直接崩有人用Timer.schedule控制刷新离开页面时忘了cancel线程池一直挂着页面越多泄漏越明显。四合一源码里出现这种代码我的建议是重写。一个合理的方案是用主线程 Handler 的postDelayed循环刷秒private final Handler clockHandler new Handler(Looper.getMainLooper()); private final Runnable clockRunnable new Runnable() { Override public void run() { clockText.setText( DateFormat.format(HH:mm:ss, System.currentTimeMillis()).toString() ); clockHandler.postDelayed(this, 1000); } }; Override protected void onResume() { super.onResume(); clockHandler.post(clockRunnable); } Override protected void onPause() { super.onPause(); clockHandler.removeCallbacks(clockRunnable); }postDelayed只是告诉主线程“下一次什么时候再来看”它不会一直占着 CPU。onResume里用post立即执行一次保证页面一进来就有正确时间onPause里用removeCallbacks把回调从消息队列里去掉页面切到后台后就不再执行。显示文本时直接读System.currentTimeMillis()而不是维护一个累加秒数即使某个回调被系统延迟了下一次显示出来的时间依然是准的。3.2 闹钟设置RTC_WAKEUP 和 setExactAndAllowWhileIdle 配合闹钟模块在四合一源码里的定位最特殊其他三个功能都是用户打开页面才工作闹钟必须应用不在前台、屏幕熄灭、甚至系统进入低功耗模式时也能在约定时刻唤醒。这不是页面代码能解决的要依赖AlarmManager。设置一个一次性闹钟的常见写法是AlarmManager alarmManager (AlarmManager) getSystemService(Context.ALARM_SERVICE); Intent intent new Intent(this, AlarmReceiver.class); intent.putExtra(alarmId, alarmId); long triggerAtMillis calendar.getTimeInMillis(); PendingIntent pendingIntent PendingIntent.getBroadcast( this, alarmId, intent, PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE ); if (Build.VERSION.SDK_INT Build.VERSION_CODES.S !alarmManager.canScheduleExactAlarms()) { // API 31 以上需要先引导用户到“闹钟和提醒”页面开启权限 return; } alarmManager.setExactAndAllowWhileIdle( AlarmManager.RTC_WAKEUP, triggerAtMillis, pendingIntent );这里容易踩的坑有三个。第一PendingIntent的requestCode要使用闹钟的 ID不能每次传 0否则新建的闹钟会把旧的顶掉最后只留下一条。第二FLAG_IMMUTABLE在 Android 12 必须加一些高版本设备上缺少它直接抛SecurityException。第三RTC_WAKEUP表示触发时把设备从休眠状态拉起来如果换成RTC屏幕熄灭后闹钟不会响这正是很多源码“在模拟器上能跑、真机锁屏就哑”的原因。这几个参数我一般会画成一张排错表方便答辩证人问到底参数常犯错误作用requestCode一直传 0和闹钟 ID 一一对应决定 PendingIntent 是否复用triggerAtMillis用 currentTimeMillis delay表示触发时刻的绝对时间戳单位毫秒type误用 RTC响铃场景必须用 RTC_WAKEUPRTC 不唤醒休眠设备flags不加 FLAG_IMMUTABLEAPI 31 不加会抛异常应用直接崩溃3.3 响铃界面用 Activity而不是 Dialog并处理锁屏显示闹钟时间到之后AlarmReceiver收到广播需要唤起一个全屏界面。常见做法是在BroadcastReceiver的onReceive里直接启动AlarmActivitypublic class AlarmReceiver extends BroadcastReceiver { Override public void onReceive(Context context, Intent intent) { Intent activityIntent new Intent(context, AlarmActivity.class); activityIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(activityIntent); } }从 BroadcastReceiver 启动 Activity必须加FLAG_ACTIVITY_NEW_TASK因为接收器没有 Activity 栈不加会在高版本上报Calling startActivity() from outside of an Activity context requires FLAG_ACTIVITY_NEW_TASK。锁屏显示还依赖 AlarmActivity 在onCreate里设置窗口标志getWindow().addFlags( WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED | WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON | WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON );FLAG_KEEP_SCREEN_ON只在屏幕亮着时阻止熄屏FLAG_TURN_SCREEN_ON负责把屏幕点亮FLAG_SHOW_WHEN_LOCKED在 Android 10 以上已废弃但对老设备仍然有效。工程里如果targetSdk没拉到特别新这三个标志组合是兼容面最广的方案。3.4 重启丢闹钟用本地存储保存配置在 BOOT_COMPLETED 里重建普通应用设置过的闹钟系统重启后不会自动保留。四合一源码里如果看到设置闹钟只放到内存、没有监听开机广播就可以补这一段public class BootReceiver extends BroadcastReceiver { Override public void onReceive(Context context, Intent intent) { if (!Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) { return; } // 从本地存储读取闹钟列表逐条重新 setExactAndAllowWhileIdle ListAlarmItem alarms AlarmRepository.load(context); for (AlarmItem alarm : alarms) { scheduleExactAlarm(context, alarm); } } }BOOT_COMPLETED接收器需要先在 manifest 里注册。数据存到SharedPreferences还是数据库都行关键是重建闹钟时要用同一个alarmId否则 UI 上显示“已开启”的闹钟实际上对应一个全新的 PendingIntent取消旧闹钟时会出现删不掉的残留。调试这段逻辑时用adb shell dumpsys alarm | grep 包名能看到下一条触发时间和 PendingIntent 的创建次数比反复改代码重装靠谱得多。4. 秒表和倒计时的计时精度为什么两个模块不能共用同一套时间源4.1 秒表实现Chronometer 的基准时间是 elapsedRealtime 而不是系统当前时间秒表这个功能很多人会直接用System.currentTimeMillis()相减。但这个值在用户手动修改系统时间、网络对时、时区切换时会跳变秒表数字突然多了几个小时就很奇怪。Android 专门为这种“计算间隔”的场景提供了SystemClock.elapsedRealtime()它表示设备开机以来的毫秒数不受系统时间设置影响。一个可用的秒表用自带的Chronometer组件能省掉大部分刷新逻辑Chronometer android:idid/chronometer android:layout_widthwrap_content android:layout_heightwrap_content android:textSize48sp android:format%s /Chronometer chronometer findViewById(R.id.chronometer); long base SystemClock.elapsedRealtime() - savedElapsedMillis; chronometer.setBase(base); chronometer.start();Chronometer内部显示逻辑基于elapsedRealtimesetBase传入的是“当作 0 点的时间戳”。秒表暂停时要把elapsedMillis保存起来恢复时用SystemClock.elapsedRealtime() - savedElapsedMillis重新算一个基准直接沿用旧的基准会导致时间翻倍。如果还要展示毫秒需要调用setOnChronometerTickListener自己格式化默认format%s只显示到秒。顺便说一个容易被追问的点如果秒表页放了个ProgressBar表示“已跑时长占目标时长的比例”进度更新也要放在同一个onChronometerTick回调里而不是再开一个定时器。两个定时器同时走页面一卡进度条和文字会对不上。4.2 倒计时实现CountDownTimer 的 onTick 延迟用“算剩余时间”兜底倒计时比秒表难在结束时刻固定、中间还要平滑展示。CountDownTimer是 Android SDK 自带的封装几行代码就能把 ProgressBar 和剩余时间串起来long totalMillis 5 * 60 * 1000L; CountDownTimer timer new CountDownTimer(totalMillis, 1000) { Override public void onTick(long millisUntilFinished) { progressBar.setProgress((int) (millisUntilFinished / 1000)); textView.setText(剩余 millisUntilFinished / 1000 秒); } Override public void onFinish() { textView.setText(时间到); } }; timer.start();第二个参数是interval这里传 1000 毫秒但系统并不保证每隔一秒都刚好回调。Doze 模式下屏幕熄灭后onTick被推迟几秒甚至几十秒都是正常的。所以最终时间显示要以millisUntilFinished为准不要在回调里写remaining - 1000否则任何一次回调延迟都会让剩余时间越走越慢。这里有一个方向性错误经常出现以为倒计时只能靠CountDownTimer。其实它只是把手动 Handler 封装了一层真正的倒计时只依赖一个结束时间戳。可以在开始时记录long endTime SystemClock.elapsedRealtime() totalMillis;然后在界面刷新时用endTime - SystemClock.elapsedRealtime()计算剩余时间。屏幕亮着时一秒一刷屏幕灭了被系统拖住也没关系每次刷新都从endTime重新算差显示永远是准的。闹钟级别的结束提醒仍然由AlarmManager负责这里单独靠页面回调只能满足前台场景。4.3 四合一里的时间源分工时钟日历时间、计时用开机时钟四个模块放在一个应用里最值得记住的分工是面向用户展示的“现在几点”、闹钟触发点用System.currentTimeMillis()秒表和倒计时的“经过了多久”“还剩多久”用SystemClock.elapsedRealtime()。时间源重启后修改系统时间适合模块System.currentTimeMillis()按新时间重算受影响可能跳变时钟、闹钟触发点、日期SystemClock.elapsedRealtime()重新从 0 开始但差值不变不影响秒表、倒计时、动画时长这个分工看起来基础但源码里经常混用。有人在秒表里记录startMillis System.currentTimeMillis()下一次开机数据就没意义有人在闹钟设置里用SystemClock.elapsedRealtime() delay当触发时间结果重启后闹钟直接丢。AlarmManager 的RTC类型跟currentTimeMillis对应ELAPSED_REALTIME跟elapsedRealtime对应顺序颠倒重启和改系统时间都是坑。如果界面同时保存一个绝对时间戳和一个相对剩余时长修改系统时间的场景会更容易排查闹钟触发点用绝对时间倒计时显示用相对值两侧各取所长不会互相污染。5. 毕业设计答辩前用 adb 把闹钟、秒表、倒计时一起压一遍5.1 用 dumpsys 验证闹钟是否真的排进了系统队列模拟器上测试的价值有限因为 Doze 模式在模拟器上很弱真机才是最终验收环境。连接真机后先安装 Debug 包再设置一个 2 分钟后的闹钟然后用dumpsys查系统里的闹钟队列adb install -r app-debug.apk adb shell am start -n com.example.fourinone/.MainActivity adb shell dumpsys alarm | grep -A 5 com.example.fourinone这里的包名要换成build.gradle里的applicationId实际值。dumpsys alarm输出里会列出下一次触发时间、触发类型和待发送的PendingIntent。如果看不到本包的 Alarm 记录说明AlarmManager调用没有生效先查requestCode是否和 PendingIntent 保持一致如果能看见但时间不对检查传入setExactAndAllowWhileIdle的时间戳毫秒还是秒错一个数量级整个排程都会飘。5.2 强制进入 Doze再观察倒计时和闹钟的表现Android 提供了强制进入低功耗模式的命令不需要把手机放桌上等几个小时待机adb shell dumpsys deviceidle force-idle adb shell dumpsys deviceidle unforce进入force-idle后把倒计时设成 2 分钟锁屏放在桌上。到时间后重新亮屏如果剩余时间出现跳变说明倒计时用的是“每次减固定值”而不是“结束时间戳减当前时间”如果连结束提醒都没触发说明闹钟没有走setExactAndAllowWhileIdle这条精确路线。这个结果在答辩报告里是很好的性能数据比口头说“我优化过”有说服力。测试完记得执行unforce否则手机会一直停在这个低功耗状态后面 apk 更新都可能变得迟钝。5.3 时间跳变、横竖屏切换、快速连点三个边界秒表和倒计时共同要防的是系统改时间。断开网络连接把系统时间往后调两小时切回秒表页面。时间源写错的应用这一下会露出破绽秒表多跑两小时倒计时直接归零。正确实现下秒表受elapsedRealtime保护不会受任何影响。横竖屏切换主要看状态恢复。页面销毁重建后秒表是否从暂停前的值继续倒计时有没有从头开始进度条进度和文字是否同步。建议在onSaveInstanceState里保存elapsedMillis和倒计时的endTime在onCreate里先恢复再开始刷新否则转一次屏幕计时就从零再来答辩现场演示时非常尴尬。快速连点“开始”“暂停”“复位”看是否出现负值终点是格式化拼接完不出现-1:59。最后一招是打包成 release APK关掉 Android Studio 的 Instant Run 再走一遍完整流程。毕业设计现场演示最怕遇到“有改动请等待重新构建”的提示先用 release 包把整个流程走通现场压力会小很多。本文还有配套的精品资源点击获取