1. 项目缘起为什么我们需要一个独立的计步器在Android生态里计步功能早已不是新鲜事。从各大手机厂商自带的健康应用到微信、支付宝等国民级App内置的“微信运动”、“蚂蚁森林”计步似乎已经无处不在。那为什么我们还需要一个独立的、名为“Android Pedometer”的应用呢作为一个在移动健康领域摸爬滚打多年的开发者我见过太多用户和初学者的困惑系统自带的健康App数据不准、功能臃肿且无法导出大厂App的计步数据往往与社交、营销深度绑定隐私和安全边界模糊更重要的是如果你想学习传感器开发、理解Android健康数据框架或者只是想拥有一个完全由自己掌控、简洁高效的步数追踪工具市面上现成的方案都难以满足。这正是“Android Pedometer”这个项目的核心价值所在。它不是一个简单的功能演示而是一个从零开始、深度整合Android传感器框架、数据持久化、界面交互和后台服务的完整工程实践。通过亲手构建它你不仅能获得一个完全免费、无广告、数据本地存储的私人健康助手更能透彻理解Android平台上运动健康类应用的核心技术栈。最近在开发者社区和搜索引擎上关于android中协调布局banner、android动态图标主题、android蓝牙、android compose以及android studio recyclerview等话题热度不减这些都从侧面反映了开发者们对构建现代化、高性能、用户体验良好的原生应用有着持续且强烈的需求。本项目将串联起这些热点技术为你呈现一个活生生的综合案例。2. 核心架构设计从传感器到用户界面构建一个健壮的计步器远不止读取一个步数传感器数据那么简单。它需要一个清晰、可扩展的架构来应对数据采集的实时性、数据存储的可靠性、电量消耗的优化以及用户界面的流畅性等多重挑战。经过多次迭代我总结出以下核心架构它由四个层次组成自底向上分别是数据源层、数据处理层、数据持久层和表现层。2.1 数据源层与硬件传感器的第一次握手数据源是整个应用的基石。在Android上计步主要依赖两种传感器加速度传感器TYPE_ACCELEROMETER和步数探测器传感器TYPE_STEP_DETECTOR或步数计数器传感器TYPE_STEP_COUNTER。这里有一个关键选择是使用原始加速度数据自己实现计步算法还是直接使用系统提供的步数传感器我的建议是对于学习型和追求极致控制的项目可以从加速度传感器入手但对于一个追求稳定、准确且低功耗的生产级应用强烈推荐使用TYPE_STEP_COUNTER。为什么是TYPE_STEP_COUNTERTYPE_STEP_COUNTER是一个自设备启动以来累计步数的硬件传感器如果设备支持。它的最大优点是功耗极低并且由系统底层或协处理器如Qualcomm的Sensors Low Power Island直接维护计数准确性非常高不受应用进程生命周期影响。即使你的应用被杀死步数仍在持续累积下次启动时读取当前值减去上次记录的值就能得到期间的新增步数。这完美解决了后台持续计步的难题。而TYPE_STEP_DETECTOR则是每检测到一步就触发一次事件适合需要实时反馈步态的应用但需要应用持续在后台监听对电量不友好。自己用加速度传感器实现算法通过检测波峰波谷则更复杂准确率受设备放置位置、人体姿态影响大且同样需要持续唤醒CPU是电量杀手。实操注册传感器监听在实现了SensorEventListener的类中通常是一个Service或ViewModel进行如下操作class StepSensorService : Service(), SensorEventListener { private lateinit var sensorManager: SensorManager private var stepCounterSensor: Sensor? null private var lastSavedStepCount 0L // 持久化存储的上次步数 override fun onCreate() { super.onCreate() sensorManager getSystemService(Context.SENSOR_SERVICE) as SensorManager stepCounterSensor sensorManager.getDefaultSensor(Sensor.TYPE_STEP_COUNTER) if (stepCounterSensor ! null) { // 关键参数SENSOR_DELAY_UI 足以因为STEP_COUNTER变化不频繁 sensorManager.registerListener(this, stepCounterSensor, SensorManager.SENSOR_DELAY_UI) } else { // 设备不支持硬件计步需要降级方案如使用加速度传感器或提示用户 handleNoStepCounter() } // 从本地数据库或SharedPreferences加载lastSavedStepCount loadLastStepCount() } override fun onSensorChanged(event: SensorEvent?) { event?.let { if (it.sensor.type Sensor.TYPE_STEP_COUNTER) { val totalStepsSinceReboot it.values[0].toLong() // 计算新增步数 当前总步数 - 上次保存的总步数 val newSteps totalStepsSinceReboot - lastSavedStepCount if (newSteps 0) { // 更新UI和数据层 updateStepCount(newSteps) // 更新lastSavedStepCount为当前总步数并持久化 lastSavedStepCount totalStepsSinceReboot saveLastStepCount(lastSavedStepCount) } } } } override fun onAccuracyChanged(sensor: Sensor?, accuracy: Int) { // 通常不需要处理 } }注意TYPE_STEP_COUNTER的值会在设备重启后重置为0。因此我们的lastSavedStepCount也必须对应的是“上次记录时的总步数”而不是一个绝对日期下的累计步数。我们需要在每次记录后保存这个“总步数快照”并在应用启动或服务创建时加载它。2.2 数据处理与持久层Room数据库的优雅实践计步数据是时间序列数据我们需要存储每天、甚至每小时的步数以便生成历史图表。这里我选择Jetpack Room作为持久化方案因为它提供了编译时SQL校验、方便的RxJava或Coroutines集成以及与LiveData/Flow的无缝结合非常适合Android开发。首先定义数据实体Entity。我们不仅要存步数还要关联卡路里、距离等健康数据这些可以通过步数估算。Entity(tableName daily_step_records) data class DailyStepRecord( PrimaryKey val date: String, // 使用“yyyy-MM-dd”格式作为主键方便按天查询 val totalSteps: Int 0, val estimatedCalories: Float 0f, // 估算卡路里 val estimatedDistance: Float 0f // 估算距离米 ) { // 提供一个从步数估算卡路里和距离的便捷方法 // 简单公式卡路里 ≈ 步数 * 0.04 距离米≈ 步数 * 0.762 (假设步幅0.762米) fun calculateDerivedData() this.copy( estimatedCalories totalSteps * 0.04f, estimatedDistance totalSteps * 0.762f ) }接着定义数据访问对象Dao。这里的设计要考虑到常见的查询需求获取今天的数据、获取某一时间范围内的数据用于绘图、插入或更新某天的数据。Dao interface DailyStepRecordDao { Query(SELECT * FROM daily_step_records WHERE date :date) suspend fun getRecordByDate(date: String): DailyStepRecord? Query(SELECT * FROM daily_step_records WHERE date BETWEEN :startDate AND :endDate ORDER BY date ASC) fun getRecordsBetweenDates(startDate: String, endDate: String): FlowListDailyStepRecord Insert(onConflict OnConflictStrategy.REPLACE) suspend fun insertOrUpdate(record: DailyStepRecord) // 初始化时可能需要创建最近N天的空记录 Insert(onConflict OnConflictStrategy.IGNORE) suspend fun insertAll(records: ListDailyStepRecord) }最后在onSensorChanged中获取新增步数后我们需要更新数据库。这里有一个细节用户可能在同一天多次打开应用。我们需要先查询今天是否已有记录有则更新步数累加无则创建。private suspend fun updateStepCountInDatabase(newSteps: Int) { val today SimpleDateFormat(yyyy-MM-dd, Locale.getDefault()).format(Date()) val database AppDatabase.getInstance(applicationContext) val recordDao database.dailyStepRecordDao() val todayRecord recordDao.getRecordByDate(today) val updatedRecord if (todayRecord ! null) { todayRecord.copy(totalSteps todayRecord.totalSteps newSteps).calculateDerivedData() } else { DailyStepRecord(date today, totalSteps newSteps).calculateDerivedData() } recordDao.insertOrUpdate(updatedRecord) }使用Flow从数据库查询数据可以很方便地在UI层如ViewModel进行观察实现数据的实时响应。2.3 表现层用Compose打造现代化界面UI层我们采用Jetpack Compose这是当前Android原生UI开发的主流和未来方向。相比于传统的View系统Compose的声明式编程模型能让我们更专注于描述UI在不同状态下的样子状态管理也更加清晰。结合架构中的ViewModel和Flow我们可以构建一个响应式界面。首先在ViewModel中暴露UI状态。我们使用StateFlow或MutableStateFlow来持有状态。class StepTrackerViewModel( private val stepRepository: StepRepository ) : ViewModel() { // UI状态数据类 data class StepUiState( val todaySteps: Int 0, val todayCalories: Float 0f, val todayDistance: Float 0f, val weeklyData: ListDailyStepRecord emptyList(), val isLoading: Boolean false ) private val _uiState MutableStateFlow(StepUiState(isLoading true)) val uiState: StateFlowStepUiState _uiState.asStateFlow() init { viewModelScope.launch { // 合并多个Flow今日数据和本周数据 combine( stepRepository.getTodayStepRecord(), stepRepository.getWeeklyStepRecords() ) { todayRecord, weeklyRecords - StepUiState( todaySteps todayRecord?.totalSteps ?: 0, todayCalories todayRecord?.estimatedCalories ?: 0f, todayDistance todayRecord?.estimatedDistance ?: 0f, weeklyData weeklyRecords, isLoading false ) }.collect { newState - _uiState.value newState } } } }在Compose的Composable函数中我们收集这个uiState并据此绘制界面。主界面可能包含几个关键部分顶部数据卡片显示今日步数、卡路里、距离。可以使用Card和Column布局数字部分用Text配合animate*AsState实现平滑的数字变化动画。历史图表展示最近一周或一个月的步数趋势。这里可以集成第三方图表库如MPAndroidChart的Compose版本或者使用Compose Canvas自己绘制简单的柱状图/折线图。从uiState.weeklyData中获取数据源。目标设置与进度环一个常见的功能是设置每日步数目标如10000步并用一个圆环进度条显示完成度。这可以用Canvas配合drawArc来实现。Composable fun StepTrackerScreen(viewModel: StepTrackerViewModel viewModel()) { val uiState by viewModel.uiState.collectAsStateWithLifecycle() if (uiState.isLoading) { CircularProgressIndicator(modifier Modifier.fillMaxSize().wrapContentSize()) } else { Column( modifier Modifier .fillMaxSize() .verticalScroll(rememberScrollState()) .padding(16.dp) ) { // 1. 今日数据卡片 TodayStatsCard(uiState) Spacer(modifier Modifier.height(24.dp)) // 2. 目标进度环 DailyGoalRing(uiState.todaySteps) Spacer(modifier Modifier.height(24.dp)) // 3. 周历史图表 WeeklyChart(uiState.weeklyData) } } } Composable fun DailyGoalRing(steps: Int, goal: Int 10000) { val progress remember(steps, goal) { steps.toFloat() / goal.coerceAtLeast(1) } val animatedProgress by animateFloatAsState(targetValue progress, label goalProgress) Box(contentAlignment Alignment.Center) { Canvas(modifier Modifier.size(200.dp)) { // 绘制背景灰环 drawCircle(color Color.LightGray, style Stroke(width 20f)) // 绘制进度弧 drawArc( color Color.Green, startAngle -90f, sweepAngle 360f * animatedProgress, useCenter false, style Stroke(width 20f, cap StrokeCap.Round) ) } Column(horizontalAlignment Alignment.CenterHorizontally) { Text(text $steps, style MaterialTheme.typography.h2) Text(text 步, style MaterialTheme.typography.body1) Text(text 目标: $goal, style MaterialTheme.typography.caption) } } }3. 后台服务与电量优化让计步在后台持续运行这是计步器项目的核心挑战之一。用户希望即使关闭了应用屏幕步数也能被准确记录。这就需要我们的应用在后台持续运行。在Android上后台运行意味着要处理好生命周期、唤醒锁和电量消耗的平衡。3.1 前台服务Foreground Service的必要性从Android 8.0API 26开始后台执行限制变得非常严格。简单的Service在应用进入后台后很快就会被系统停止。为了确保计步服务能长期稳定运行我们必须使用前台服务。前台服务会在状态栏显示一个持续的通知告知用户该应用正在后台执行任务。这提升了用户体验的透明度也是系统允许你长时间运行的条件。创建并启动前台服务class StepForegroundService : Service() { companion object { const val NOTIFICATION_CHANNEL_ID step_tracker_channel const val NOTIFICATION_ID 1 } override fun onCreate() { super.onCreate() // 1. 创建通知渠道Android 8.0必需 createNotificationChannel() // 2. 启动前台服务 startForeground(NOTIFICATION_ID, createStepNotification()) // 3. 初始化传感器监听见2.1节 initStepSensor() } private fun createNotificationChannel() { if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { val channel NotificationChannel( NOTIFICATION_CHANNEL_ID, 步数追踪, NotificationManager.IMPORTANCE_LOW // 低重要性避免打扰用户 ).apply { description 用于在后台持续追踪您的步数 setShowBadge(false) // 可选不在应用图标上显示角标 } val manager getSystemService(NotificationManager::class.java) manager.createNotificationChannel(channel) } } private fun createStepNotification(): Notification { // 构建一个简洁的通知显示当前步数 val intent Intent(this, MainActivity::class.java).apply { flags Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK } val pendingIntent PendingIntent.getActivity(this, 0, intent, PendingIntent.FLAG_IMMUTABLE) return NotificationCompat.Builder(this, NOTIFICATION_CHANNEL_ID) .setContentTitle(步数追踪中) .setContentText(正在记录您的每一步...) .setSmallIcon(R.drawable.ic_walk) // 一个步行图标 .setContentIntent(pendingIntent) .setOngoing(true) // 持续通知用户无法滑动清除 .setPriority(NotificationCompat.PRIORITY_LOW) .build() } }在Activity或Application中启动这个服务val serviceIntent Intent(context, StepForegroundService::class.java) if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { context.startForegroundService(serviceIntent) } else { context.startService(serviceIntent) }重要提示从Android 12API 31开始前台服务需要声明新的权限uses-permission android:nameandroid.permission.FOREGROUND_SERVICE /并且对于某些类型的前台服务如位置、摄像头还需要声明更具体的权限如uses-permission android:nameandroid.permission.FOREGROUND_SERVICE_DATA_SYNC /。计步服务通常使用FOREGROUND_SERVICE_HEALTH类型但需注意其使用限制和Google Play政策。3.2 WorkManager的定时任务数据备份与同步虽然前台服务能保证传感器监听持续进行但我们还需要一个机制来定期比如每天凌晨执行一些任务例如数据归档与清理将当天的最终数据备份到云端或本地文件。重置日计步逻辑虽然我们依赖STEP_COUNTER的绝对值和日期判断但每日初始化时可能需要执行一些逻辑。生成健康报告。对于这种“定期执行”且“不需要实时传感器”的任务使用WorkManager是比让服务一直做轮询更省电的方案。WorkManager能根据设备情况是否充电、空闲状态智能调度任务并保证任务最终会被执行。定义一个每日同步的Workerclass DailySyncWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) { override suspend fun doWork(): Result { return try { // 1. 获取昨天的日期 val calendar Calendar.getInstance().apply { add(Calendar.DATE, -1) } val yesterday SimpleDateFormat(yyyy-MM-dd, Locale.getDefault()).format(calendar.time) // 2. 从数据库获取昨天数据 val record AppDatabase.getInstance(applicationContext) .dailyStepRecordDao() .getRecordByDate(yesterday) // 3. 执行同步逻辑例如上传到健康平台、备份到文件 record?.let { syncToCloud(it) } Result.success() } catch (e: Exception) { // 失败重试 Result.retry() } } private suspend fun syncToCloud(record: DailyStepRecord) { // 模拟网络请求 delay(1000) Log.d(DailySyncWorker, Synced record for ${record.date}) } }在应用初始化时设置一个每日一次的周期性工作请求val dailySyncRequest PeriodicWorkRequestBuilderDailySyncWorker( 1, TimeUnit.DAYS, // 重复间隔 15, TimeUnit.MINUTES // 弹性时间窗口系统可在此窗口内灵活执行 ).setConstraints( Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) // 仅在联网时执行 .setRequiresBatteryNotLow(true) // 电量不低时执行 .build() ).build() WorkManager.getInstance(context).enqueueUniquePeriodicWork( daily_sync, ExistingPeriodicWorkPolicy.KEEP, // 如果已有相同名称的任务保留旧的 dailySyncRequest )3.3 电量优化实战AlarmManager的谨慎使用与Doze模式适配即使使用了低功耗的STEP_COUNTER和WorkManager我们仍需关注Android的Doze模式和应用待机模式。这些机制会在设备长时间未使用时限制网络访问、延迟作业和警报以节省电量。对我们的影响前台服务在Doze模式下前台服务通常仍能运行但网络访问可能被限制。WorkManagerWorkManager的作业会被延迟直到设备退出Doze模式或进入维护窗口。应对策略使用setAndAllowWhileIdle或setExactAndAllowWhileIdle如果某些任务对时间要求相对精确如整点提醒可以使用AlarmManager的这两个方法它们即使在Doze模式下也能触发但频率受限每15分钟最多一次。声明REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限慎用可以引导用户将你的应用加入电池优化白名单。但这会带来不好的用户体验且Google Play对滥用此权限的应用审核严格。仅当你的应用是核心健康或医疗设备类应用时才考虑使用并必须提供充分的理由。优化网络请求所有同步操作应批量进行避免频繁、零碎的网络请求。使用WorkManager的约束条件如仅在充电和Wi-Fi下同步大文件是很好的实践。一个常见的坑在onSensorChanged中不要每次步数变化都立刻更新数据库或进行网络操作。应该设置一个阈值或时间间隔进行批量操作。例如可以每累积50步或每5分钟才将数据写入数据库一次。// 在SensorEventListener中 private var stepBuffer 0 private var lastSaveTime System.currentTimeMillis() private val SAVE_INTERVAL 5 * 60 * 1000 // 5分钟 private val STEP_BUFFER_THRESHOLD 50 // 50步 override fun onSensorChanged(event: SensorEvent?) { // ... 计算newSteps stepBuffer newSteps val currentTime System.currentTimeMillis() if (stepBuffer STEP_BUFFER_THRESHOLD || (currentTime - lastSaveTime) SAVE_INTERVAL) { viewModelScope.launch { updateStepCountInDatabase(stepBuffer) stepBuffer 0 lastSaveTime currentTime } } }4. 高级功能与性能调优一个基础的计步器完成后我们可以考虑添加更多提升用户体验和应用健壮性的功能。4.1 动态图标与主题适配根据当前步数目标完成度动态改变应用图标或主界面颜色能增强用户的参与感。这涉及到动态应用图标Adaptive Icons和动态主题。动态主题基于步数在Compose中我们可以根据步数进度动态计算颜色。Composable fun StepTrackerAppTheme( progress: Float, // 完成度0.0~1.0 content: Composable () - Unit ) { // 根据进度从绿色渐变到橙色再到红色 val primaryColor remember(progress) { when { progress 0.5 - lerp(Color.Green, Color.Yellow, progress * 2) else - lerp(Color.Yellow, Color.Red, (progress - 0.5f) * 2) } } MaterialTheme( colors MaterialTheme.colors.copy(primary primaryColor), typography Typography, shapes Shapes, content content ) }动态应用图标仅限支持Launcher Shortcuts或第三方Launcher的有限方式完全动态更换主屏幕图标在原生Android中限制较多。一个变通方案是使用应用快捷方式App Shortcuts创建多个带有不同图标的快捷方式但无法替换主入口。另一种更复杂的方式是使用一些第三方Launcher提供的API但这不具备普适性。对于大多数应用更可行的方案是在应用内提供一个“徽章”或“角标”来显示步数但这需要特定厂商如小米、华为的推送或角标SDK支持实现起来非常碎片化。因此我建议将重点放在应用内的视觉动态化上。4.2 数据可视化使用MPAndroidChart绘制历史趋势图虽然Compose Canvas可以画图但对于复杂的图表使用成熟的库更高效。MPAndroidChart是一个功能强大的图表库它也有适用于Compose的版本虽然官方未直接提供但可以通过AndroidView封装使用。首先在build.gradle中添加依赖implementation com.github.PhilJay:MPAndroidChart:v3.1.0。然后创建一个可组合函数来封装图表Composable fun WeeklyChart(records: ListDailyStepRecord) { val context LocalContext.current AndroidView( factory { ctx - LineChart(ctx).apply { // 1. 基本配置 description.isEnabled false // 隐藏描述 setTouchEnabled(true) // 启用触摸交互 isDragEnabled true setScaleEnabled(true) setPinchZoom(true) setDrawGridBackground(false) // 2. 设置X轴日期 xAxis.position XAxis.XAxisPosition.BOTTOM xAxis.granularity 1f xAxis.setDrawGridLines(false) xAxis.valueFormatter object : ValueFormatter() { override fun getFormattedValue(value: Float): String { // 假设records列表顺序对应X轴value是索引 val index value.toInt() return if (index in records.indices) { records[index].date.substring(5) // 显示“MM-DD” } else { } } } // 3. 设置Y轴步数 axisLeft.setDrawGridLines(true) axisLeft.axisMinimum 0f axisRight.isEnabled false // 关闭右侧Y轴 // 4. 设置数据 val entries records.mapIndexed { index, record - Entry(index.toFloat(), record.totalSteps.toFloat()) } val dataSet LineDataSet(entries, 每日步数).apply { color Color.BLUE valueTextColor Color.BLACK lineWidth 2f setDrawCircles(true) setDrawValues(true) // 在点上显示数值 } data LineData(dataSet) // 5. 动画 animateX(1000) invalidate() // 刷新视图 } }, update { chart - // 当records数据更新时刷新图表 val entries records.mapIndexed { index, record - Entry(index.toFloat(), record.totalSteps.toFloat()) } chart.data.dataSets[0].clear() (chart.data.dataSets[0] as LineDataSet).entries entries as MutableListEntry? chart.data.notifyDataChanged() chart.notifyDataSetChanged() chart.invalidate() }, modifier Modifier .fillMaxWidth() .height(300.dp) .padding(8.dp) ) }4.3 性能监控与疑难排查在开发过程中性能问题可能悄然出现。我们需要借助工具进行监控。使用Android ProfilerCPU Profiler检查onSensorChanged回调是否过于频繁导致主线程阻塞。确保将耗时的数据库操作放在协程或子线程中。Memory Profiler监控是否有内存泄漏。特别注意SensorManager的监听器要在适当的生命周期如onPause或onDestroy中注销Service要在任务完成后正确停止。Network Profiler如果集成了数据同步功能检查网络请求是否合理有无冗余调用。常见的坑与解决方案计步服务被系统杀死现象应用退到后台一段时间后步数不再增加。排查检查是否使用了前台服务并显示了通知。在Android 9上需要请求FOREGROUND_SERVICE权限。在Android 12上需要确保通知渠道重要性不是IMPORTANCE_NONE并且用户没有手动关闭该渠道的通知。解决在onStartCommand中返回START_STICKY使服务被杀死后尝试重启。但这不是绝对可靠的最终还是要引导用户将应用加入电池优化白名单谨慎操作。设备重启后步数重置现象设备重启后应用内步数从0开始或大幅减少。根因TYPE_STEP_COUNTER传感器值在设备重启后归零。我们的lastSavedStepCount存储的是上次的“绝对总步数”重启后这个值可能远大于新的传感器读数导致newSteps计算为负数或极大值。解决在每次保存lastSavedStepCount时同时保存时间戳。当应用启动发现传感器值小于上次保存的值时可以判定为设备已重启。此时应将lastSavedStepCount重置为0并记录“设备重启”事件当天的步数从新传感器的值开始累计。// 在SharedPreferences中存储 val prefs getSharedPreferences(step_prefs, MODE_PRIVATE) val editor prefs.edit() editor.putLong(last_sensor_value, totalStepsSinceReboot) editor.putLong(last_save_time, System.currentTimeMillis()) // 保存时间戳 editor.apply()不同设备计步精度差异现象同一人在不同手机上步数统计有差异。说明这是硬件和算法差异导致的属于正常现象。TYPE_STEP_COUNTER是硬件或底层算法提供我们无法控制。可以在应用设置中提供一个“步幅校准”功能让用户输入身高或实际步幅来更准确地计算距离。卡路里估算公式也可以提供选择不同体重、运动强度系数。构建一个完整的Android计步器应用是一次对Android传感器、后台服务、数据持久化、现代UI框架和性能优化的综合演练。从选择低功耗的STEP_COUNTER传感器到用Room管理数据再用Compose和ViewModel构建响应式UI最后用前台服务和WorkManager解决后台运行与定时任务问题每一步都充满了工程实践的细节。在这个过程中我最大的体会是对于移动健康应用电量友好和数据准确性是用户体验的基石任何炫酷的功能都必须建立在这两者之上。希望这个详细的拆解能帮助你不仅做出一个可用的应用更能理解其背后的设计哲学与技术权衡。