WearOS手表蓝牙传步数，配套安卓App UI无法即时同步更新的调试问题

已确认的异常表现 #

• 数据传输链路：WearOS手表采集到步数数据后，通过蓝牙以消息形式发送给配套的安卓手机应用
• 存储层异常：应用将接收的步数数据写入SharedPreferences时存在表现延迟，往往要等手表发送下一条消息、手机端完成接收流程后，才能看到存储的数值更新
• 日志校验结果：日志打印确认，SharedPreferences中最终存储的步数数值是最新的正确值
• UI层异常：负责展示步数的ActivityRecord页面，已经确认接收到了有效的最新步数数据，但视图始终无法同步刷新展示最新内容
• 现有实现的刷新逻辑：仅提供手动触发的页面跳转逻辑，通过新建ActivityRecord实例实现页面重载，无自动数据感知与刷新机制

现有代码的核心问题 #

• 遗漏核心控件的赋值逻辑：在onCreate的日期匹配有效分支中，读取了step_count_value对应的数值变量，但完全没有将该数值赋值给step_count这个TextView控件，仅在跨天重置的else分支中给step_count设置了初始的"0"值，日常页面运行场景下该控件永远不会展示真实步数
• 无数据变化感知机制：页面仅在onCreate生命周期执行时读取一次SharedPreferences的数值，后续蓝牙接收端在后台将新数据写入SharedPreferences时，前台正在运行的ActivityRecord完全无法感知到存储值的变化，自然不会触发UI更新
• 存储写入的异步延迟：如果蓝牙接收端写入数据时使用了SharedPreferences默认的异步写入方法apply()，修改会先暂存到内存，后台异步完成磁盘落盘，就会出现“等下一次写入操作触发时，上一次的暂存修改才完成提交”的延迟表现
• 刷新逻辑冗余：现有手动刷新方法直接重新启动一个新的ActivityRecord实例，会造成Activity栈冗余，增加不必要的性能开销

针对性修复方案 #

• 补全缺失的控件赋值：在读取到步数数值的代码分支下，增加对应逻辑，将读取到的步数值设置给step_count控件：step_count.setText(String.valueOf((int) testStepCount));
• 新增SharedPreferences数据变化监听：在ActivityRecord的onStart生命周期中注册OnSharedPreferenceChangeListener，当activity_val存储文件中的步数、行走时长、久坐时长等字段发生变化时，立刻重新读取最新存储值并刷新对应控件的展示文本

  需在onStop生命周期中反注册监听器，避免内存泄漏

• 优化存储写入逻辑：蓝牙接收端写入关键实时数据时，改用同步写入方法commit()，保证数据立刻完成落盘、可被其他读取方即时获取，消除异步写入带来的延迟
• 重构刷新逻辑：抽出独立的refreshUI()方法，将所有从SharedPreferences读取数据、设置控件文本的逻辑统一封装到该方法中
  • onCreate中完成控件初始化后，直接调用一次refreshUI()完成初始数据展示
  • SharedPreferences数据变化的回调中直接调用refreshUI()，实现数据更新后的实时刷新
  • 原有手动刷新方法直接改为调用refreshUI()，不再通过新建Activity实例实现刷新

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