Flutter跨平台开发实战：基于OpenHarmony的护眼提醒App设计

1. 项目背景与页面设计思路

最开始想做这个视力保护提醒App，原因其实挺直接的——我自己每天盯着屏幕的时间往少了说也有八九个小时，眼睛干涩、视疲劳这些问题基本是常态。市面上现成的护眼提醒工具不是广告太多，就是提醒逻辑太死板，要么就是只支持手机端。后来接触到了Flutter在OpenHarmony上的适配方案，发现可以一套代码同时跑在不同形态的设备上，加上刚好需要练手跨平台移植，就决定自己动手写一个。

这个小项目表面上是一个“到点提醒你休息”的工具，但真正做起来之后才发现，最花心思的其实不是提醒逻辑本身，而是怎么把各个应用页面设计得既符合直觉、又能真正让人愿意用。视力保护提醒这种工具类App有个通病：用户装完之后很容易忘记打开，或者提醒弹出来之后随手就关掉，根本不按照引导去休息。所以页面设计从一开始就不能只做“功能展示”，必须把“提醒—引导—反馈”这条链路完整地串起来。

我规划的页面一共有四个核心模块：主倒计时页、休息引导页、使用统计页、设置页。其中主倒计时页是用户打开App之后第一眼看到的内容，承担着“当前护眼状态”和“距离下次休息还有多久”的核心信息展示；休息引导页是在倒计时结束时弹出的全屏页面，它的任务是让用户真正停下来，而不是划掉提醒继续刷；使用统计页负责记录每日的用眼时长和休息完成率，给用户一个正向反馈；设置页则提供番茄钟时长、休息时长、提醒方式等可调节的参数。

整个项目的技术选型上，我坚定地走了Flutter + OpenHarmony的组合路线。Flutter负责UI层和业务逻辑，OpenHarmony作为底层运行平台提供系统能力。一个很现实的原因是：Flutter的Widget树模型在表达倒计时、动画、过渡效果这类场景时非常顺手，而且谷歌风格的Material Design组件在OpenHarmony上也能正常渲染，视觉上不会出现明显的违和感。另一个原因则是性能表现——帧率稳定在60fps以上，页面切换没有掉帧，这个对倒计时动画的流畅度来说很重要。

页面结构的设计上，我遵循了一个比较朴素的原则：主功能一步可达，次要功能最多两次点击。主倒计时页就放在App的首页，用户打开即见；统计页和设置页通过底部Tab栏切换。这个结构没有做什么新颖的交互创新，但胜在稳定、好用，用户几乎不需要学习成本就能上手。对于一个工具类App来说，这个选择比花里胡哨的交互方式更稳妥。

2. 页面架构与路由方案的选型

2.1 主框架结构：底部Tab与页面容器的组合

整个App的页面骨架我选择了最常见的底部Tab导航方案，三个Tab分别是“护眼”“统计”“设置”。在Flutter里实现起来非常直接，使用BottomNavigationBar加IndexedStack的组合即可。这里有一个容易踩坑的小细节：如果用普通的页面切换方式(直接替换当前Widget)，每次切换Tab时页面状态都会丢失，例如主倒计时页的计时进度会重新初始化，设置页里滚动的位置也会跳回顶部。用IndexedStack把所有Tab页面一次性全部装载，只是通过索引切换显示，就能完整保留每个页面的状态。

Scaffold( body: IndexedStack( index: _currentIndex, children: const [ CountdownPage(), StatisticsPage(), SettingsPage(), ], ), bottomNavigationBar: BottomNavigationBar( currentIndex: _currentIndex, onTap: (index) => setState(() => _currentIndex = index), items: const [ BottomNavigationBarItem(icon: Icon(Icons.timer_outlined), label: '护眼'), BottomNavigationBarItem(icon: Icon(Icons.bar_chart), label: '统计'), BottomNavigationBarItem(icon: Icon(Icons.settings), label: '设置'), ], ), )

IndexedStack的代价是三个页面会同时驻留在内存里，不能像懒加载那样按需创建。不过对于这个项目的页面体量来说，三个页面的Widget树并不复杂，内存开销完全在可接受范围内。实测在低端设备上，内存占用增量大约只有十几MB，可以忽略不计。

2.2 休息引导页的路由方式：全屏Dialog还是独立路由

休息引导页的跳转方式我纠结了一段时间。刚开始用的是Navigator.push跳转到一个独立路由，逻辑上没问题，但实际体验上有一个明显的缺陷：从底部滑入的新页面会覆盖整个屏幕，包括状态栏和系统导航条，视觉上用户会觉得自己“离开了App”，更容易下意识地划掉页面回到桌面。

后来换成了showGeneralDialog实现的全屏Dialog方式，通过自定义过渡动画让新页面从顶部淡入，同时也遮住整个屏幕。这个方案的好处是：Dialog本身带有一条半透明的遮罩层，视觉上给用户的感觉是“当前页面上弹出了一个必须处理的提醒”，而不是“跳转到了另一个页面”，这种心理暗示对于提醒类工具非常重要——用户更倾向于完成当前弹层的操作，而不是直接返回桌面逃避提醒。两个方案的代码实现差距不大，但产品体验上的差异非常明显，我强烈建议做提醒类功能时优先考虑Dialog式跳转。

2.3 路由命名与参数传递的规范

虽然这个项目的页面数量不多，我仍然坚持用了命名路由的方式统一管理页面跳转。主要原因是后期调试方便——在开发阶段经常需要在不同页面之间跳转复现某个Bug，命名路由可以让我直接从任意入口指定跳转目标，而不用关心页面之间的参数传递链路。

路由配置统一放在一个单独的文件里管理，页面路径用字符串常量定义，避免魔法字符串散落在代码各处。传递参数时使用arguments字段携带一个自定义的RouteArgument对象，而不是直接把多个参数拼成一个Map传入。这样做的优势在于：编译期能检查出传参类型错误，而不是等到运行时才发现参数缺失。比如休息引导页需要接收“休息时长”和“提醒类型”两个参数，如果直接在路由里传Map，写错一个key不会报错，页面只能拿到空值；而定义成强类型的RouteArgument对象后，编译期间就会提示字段缺失或者类型不匹配。

3. 核心模块页面详解

3.1 主倒计时页：状态管理与时间格式化的实现

主倒计时页是全App的核心页面，承担着展示倒计时进度、启动暂停倒计时、快速开启一次休息三个核心功能。这个页面的状态管理我选择了比较轻量的方案：单页面内使用StatefulWidget自带的setState，跨页面共享的数据(例如每日累计用眼时长)使用一个简单的全局单例模型来维护，没有引入Bloc或Provider这类重型状态管理框架。

原因很直接：项目的页面层级不深，状态共享的规模有限，使用框架带来的收益主要体现在代码组织上，但对于这种小体量的工具App来说，引入框架的复杂度反而得不偿失。工作量完全在可控范围内。

时间格式化的实现上，有一个容易出错的地方：倒计时显示的值不是直接用剩余秒数格式化，而是要先计算成“分:秒”的结构再补零。比如剩余90秒，要显示成“01:30”，如果直接取模拼接，就会在分钟数小于10时出现“1:30”的格式不统一问题。我的做法是单独写了一个时间格式化函数，统一处理个位数补零：

String formatTime(int totalSeconds) { final minutes = totalSeconds ~/ 60; final seconds = totalSeconds % 60; return '${minutes.toString().padLeft(2, '0')}:${seconds.toString().padLeft(2, '0')}'; }

倒计时的主循环使用Timer.periodic来实现，每秒触发一次回调更新剩余时间。这里有一个细节值得说明：使用Timer每秒更新就会触发setState刷新整个页面，重建所有Widget，包括背景渐变、文字、按钮等。如果页面比较复杂，这种重建会带来不必要的性能开销。优化方案是把倒计时数字单独提取成一个独立Widget，只在这个Widget内部刷新数字文本，不触发整个页面的重建。

Timer.periodic(const Duration(seconds: 1), (timer) { if (_remainingSeconds <= 0) { timer.cancel(); _showRestDialog(); return; } setState(() { _remainingSeconds--; }); });

另一个可能踩坑的地方是页面不可见时Timer仍在运行。在Flutter里，页面切换到后台时Widget树并不会销毁，Timer也不会自动暂停，这会导致一个明显的问题：用户切到后台忙别的事情，回来之后发现倒计时已经结束了，休息引导页早就弹出过甚至被系统回收了。处理方案是在WidgetsBindingObserver的didChangeAppLifecycleState回调里监听App前后台切换状态，回到前台时重新同步倒计时数据源，确保显示的时间与真实时间一致。

3.2 休息引导页：动画过渡与交互限制设计

休息引导页的产品目标非常明确：让用户在这个页面停留至少20秒，做一组简单的眼保健操动作，再返回工作。为了实现这个目标，页面交互做了几个刻意的设计。

全屏遮罩使用showGeneralDialog实现，自定义了从透明度0到1、位移动从10%到0的过渡动画，整体时长控制在300毫秒。300毫秒这个数值不是拍脑袋定的——太短了会显得突兀，太长了用户会着急。在视觉层级上，页面中央放置一个大大的进度环，显示休息剩余时间；下方是三个简易的眼保健操动作示意图，每个动作配文字说明；底部是一个“跳过休息”按钮，但这个按钮默认是禁用的，只有等到休息时间过半(例如总时长20秒，过了10秒后)才可点。

这个“冷却时间”的设计一开始被同行的朋友吐槽过，说这样太强制了，用户想关都关不掉。但实际调研了同类应用的做法之后，我发现稍微带一点强制性的引导反而对用户更有益——如果跳过按钮从一开始就可用，绝大多数人会在3秒内直接跳过，休息功能形同虚设。折中方案是设一个半程冷却时间，既不完全强制，也不完全自由。代码上通过一个状态标志位控制按钮的可用性，倒计时过半时置为true。

进度环的绘制用的是CustomPainter，通过绘制圆弧来表征剩余时间的比例。这里有一个动画平滑度的细节：每秒刷新一次进度环的话，圆弧的跳动会有明显的阶梯感。实测把圆弧的进度值存储在一个AnimationController中，通过动画插值让圆弧在1秒内平滑地从当前角度过渡到目标角度，就能消除阶梯感，视觉上圆滑很多。

class _CircleProgressPainter extends CustomPainter { final double progress; // 0.0 ~ 1.0 @override void paint(Canvas canvas, Size size) { final paint = Paint() ..style = PaintingStyle.stroke ..strokeWidth = 12 ..strokeCap = StrokeCap.round; // 背景圆环 canvas.drawArc( Rect.fromLTWH(0, 0, size.width, size.height), 0, 2 * pi, false, paint..color = Colors.grey.shade300, ); // 进度圆环 canvas.drawArc( Rect.fromLTWH(0, 0, size.width, size.height), -pi / 2, 2 * pi * progress, false, paint..color = const Color(0xFF6750A4), ); } }

还有一个隐藏的细节：休息引导页弹出时，需要把系统状态栏的样式改成浅色主题(浅色背景、深色文字)，避免状态栏和全屏遮罩的深色背景产生割裂感。从引导页关闭后，再恢复原来的状态栏样式。这个逻辑在Flutter中通过AnnotatedRegion<SystemUiOverlayStyle>组件包裹页面内容来实现。

3.3 统计页：图表绘制与终身数据存储方案

统计页展示的是“今日用眼时长”“今日休息完成次数”“最近7天趋势”三块数据。其中趋势部分使用柱状图展示，没有引入第三方图表库，直接用CustomPaint手绘。原因一是图表需求简单，犯不上引入一个上百KB的库；二是第三方图表库在OpenHarmony上的兼容性没有经过充分验证，很可能出现字体渲染或Canvas绘制异常的问题。

手绘柱状图的核心逻辑不复杂：把7天的数据映射成等宽的柱子，柱子高度按数值比例缩放，柱顶标注数值。真正的难点在于坐标系的转换——Flutter的Canvas坐标系原点在左上角，y轴向下增长，而图表数据是y轴向上的常规习惯。处理方式是先计算出绘图区域的矩形，再把每个数据点的高度换算成相对于绘图区域底部的偏移量。

方案选好了还要考虑数据的持久化。首次启动时默认从本地读取历史记录，数据结构是嵌套的Map：外层按日期索引，内层记录当日总用眼秒数、休息完成次数、番茄钟周期数。使用SharedPreferences存JSON字符串，每次统计页打开时反序列化展示。这里有个值得注意的细节：为了避免频繁写入造成卡顿，不是每次倒计时结束时都立即写入SharedPreferences，而是先缓存在内存中，每隔5分钟或者App进入后台时统一落盘一次。这样既保证了数据不丢失，也避免了高频IO操作对性能的影响。

3.4 设置页：参数配置与系统能力对接

设置页的UI很简单，本质上是一个参数列表，每个条目左侧是功能名称，右侧是当前配置值，点击后弹出选择器或者滑杆。设置项包括：单次专注时长(15/25/45分钟三档)、休息时长(20/30/60秒三档)、每日护眼目标时长、是否开启通知栏常驻提醒、提醒音效开关。

这个页面在实现上有一个值得一提的细节：所有设置项的值都存储在一个SettingsModel单例中，使用ValueNotifier监听变化。设置页修改参数后，主倒计时页需要立即感知到新的时间配置。通过ValueNotifier而不是全局事件总线，好处是类型安全、作用域清晰，也不会出现事件泄漏的问题。

系统通知栏常驻提醒这个功能，在OpenHarmony上的实现和标准Android逻辑略有差异。OpenHarmony的Ability框架提供了发布通知的API，需要先申请通知权限，再构建NotificationRequest发布。这里遇到的主要坑是：通知权限的申请结果回调是异步的，而API的调用时机是同步判断的。处理方案是封装一个权限申请工具类，使用异步回调判断授权结果，授权成功后再触发通知发布动作。同时在设置页里增加了权限状态展示，如果用户关闭了通知权限，页面上会明确提示“通知未开启，提醒将无法在锁屏状态显示”，并提供一个跳转到系统设置页的按钮。

4. 视觉风格与交互优化的实践

4.1 配色方案与主题统一

颜色选择的整体思路是：以绿色为主色调，以灰色和米白色为辅助色。绿色在视觉心理上直接关联“健康”和“放松”，和护眼主题的调性高度匹配。同时确定了两个具体的色值作为主题色：主色#4CAF50(Material Green 500)，辅助色#81C784(Green 300)和#388E3C(Green 700)。在生成不同状态下的按钮、进度条和图标时，通过Material主题的ColorScheme.fromSeed自动推导出完整的色板。

主题统一的处理上，我没有使用硬编码的颜色值散落在各个页面里，而是在ThemeData里统一配置了colorScheme、appBarTheme、cardTheme等全局样式。这样做的直接好处是：后期如果想要改成蓝色主题或者暗黑模式，只需要修改一处主题配置即可全局生效，不需要逐个页面去改颜色。

暗黑模式的适配其实比想象中重要。很多用户习惯晚上关灯后用手机，如果App不支持暗黑模式，刺眼的白底背景反而会加重眼睛负担，这和护眼App的产品理念完全背道而驰。所以项目一开始就把暗黑模式作为一等公民来对待，通过ThemeData.dark()派生一套暗色色板，并在MaterialApp的themeMode属性中配置跟随系统。

4.2 动效与反馈设计

工具的动效应做到“恰到好处”的标准：有反馈但不喧宾夺主。具体到页面上，主要的动效有三处。

第一处是主倒计时页的数字切换效果。倒计时数字更新时，数字不是生硬地原地替换，而是有一个轻微的缩放淡入效果。实现方式是在数字外层包一个AnimatedSwitcher，切换时旧数字向下淡出，新数字向上淡入，持续200毫秒。200毫秒是长还是短需要根据实际设备反复调试，我实测过150到300毫秒之间的几个档位，200毫秒在视觉上最舒适——既不会让人觉得卡顿，也不会因为动画时间太长而显得拖沓。

第二处是休息完成后的反馈动效。当休息结束时，引导页中央的进度环变成对勾图标，同时整个页面背景从深绿色淡变为浅绿色，暗示“你已经完成了一次有效的休息，可以回去工作了”。这个反馈动效虽然简单，但对用户的成就感建立很关键。

第三处是Tab切换时的图标过渡效果。使用自定义的AnimatedIcon实现图标从计时器形态切换到柱状图形态的平滑过渡。这个动效纯属锦上添花，但在实际体验中确实提升了App的精致感，开发工作量也完全可以接受。

4.3 布局适配与不同屏幕尺寸的处理

OpenHarmony运行设备的屏幕形态跨度比Android更大，从小尺寸的智能手表到平板再到电视都有。虽然这个App的目标用户主要集中在手机和平板，但布局适配依然要做到基本可用。

页面适配的策略是：使用Flexible和Expanded组件弹性布局，避免使用固定像素宽度；文字字号使用Material的textScaleFactor随系统字体缩放；页面的安全区域通过SafeArea组件自动处理，避免刘海屏和圆角屏的内容遮挡问题。

有一个比较容易忽视的适配点：横竖屏切换。竖屏下主倒计时页是上下结构，时间在上、按钮在下；横屏时如果还保持上下结构，两侧就会出现大量留白。处理方案是监听MediaQuery的orientation属性，根据横竖屏状态切换布局方向：竖屏用Column，横屏用Row。这样保证了不同握持姿势下都有合理的视觉结构。

final isLandscape = MediaQuery.of(context).orientation == Orientation.landscape; return isLandscape ? Row(children: [timeArea, Expanded(child: actionArea)]) : Column(children: [timeArea, actionArea]);

5. Flutter在OpenHarmony上的适配笔记

5.1 环境搭建与工程配置要点

开发环境的搭建是整个项目中踩坑最多的环节，值得单独记录一下。Flutter对OpenHarmony的支持目前还不是官方稳定渠道，需要从社区拉取适配分支的Flutter SDK，同时安装对应版本的DevEco Studio和HarmonyOS SDK。

版本匹配是个最容易出问题的地方：Flutter SDK的版本和OpenHarmony SDK的版本必须严格对应，差一个小版本都可能导致编译失败或者运行时的API匹配错误。我在开始阶段就吃过亏，用的是某版本的Flutter SDK搭配最新版的OpenHarmony SDK，结果编译时大量报错，查了半天才发现是API Level对不上。

建议的做法是在项目的pubspec.yaml里锁定Flutter SDK的版本范围，同时把DevEco Studio的SDK版本信息记录在项目的README里。这样不管是自己换电脑还是团队协作，都能快速恢复一致的开发环境。

5.2 平台通道与OpenHarmony能力的调用

Flutter工程在OpenHarmony上运行的原理是：Flutter引擎运行在OpenHarmony的Ability框架之上，通过平台通道(Platform Channel)和原生侧进行通信。在需要调用系统能力(比如通知、震动、传感器)时，通过MethodChannel发起调用，原生侧在OpenHarmony的Ability里接收处理。

定义频道名称时有个小规范：频道名应该用反域名格式命名，例如com.example.eye_guard/notification，避免和其他插件冲突。我在项目里维护了一个单独的PlatformBridge类，统一管理所有MethodChannel的调用，不在页面里直接写PlatformChannel相关代码。这种集中管理的方式方便后期排查问题，而且通道实例只创建一次，避免了重复创建导致的资源泄漏。

调用震动的场景中，OpenHarmony接口和Android差异很大。Android直接调用Vibrator服务即可，OpenHarmony则需要通过VibratorAgent的startVibration接口并且需要传入VibrationAttribute配置。如果尝试直接套用Android的代码，编译能通过但运行时会静默失败——没有任何报错，就是不振。排查了很长时间才发现是接口调用方式的问题。

5.3 页面渲染差异与常见白屏问题

Flutter在OpenHarmony上的渲染性能整体不错，但有一个高频问题必须提前预防：在某些设备上打开应用会白屏数秒才出现首帧内容。这个问题的根因是首帧GPU渲染管线在低端设备上启动较慢，不是代码层面的Bug。

应对方案是设置一个启动闪屏页(Splash Screen)，Flutter内容加载完成后自动切换到主页面。在项目的入口main.dart中监听WidgetsBinding的帧回调，首帧渲染完成后通过路由替换移除闪屏页。这个方案虽然简单，但能明显改善用户的第一印象——没有人愿意对着白屏等3秒钟。

另外还有一点适配经验：字体渲染在OpenHarmony上对中文的支持表现良好，但个别字体权重(如w300细体)存在渲染变形的情况。解决方案是尽量使用系统默认字体，不引入自定义字体文件。如果产品设计上必须要特殊字体，需要提前在目标设备上做渲染测试。

5.4 后台运行与生命周期管理的差异

OpenHarmony上App的生命周期管理和Android有细微差别。当App切到后台时，Flutter的Widget树状态保持机制本身是正常的，但OpenHarmony的Ability框架会在资源紧张时直接回收整个Ability实例。这意味着倒计时页面可能被系统杀到连单例数据都保留不住，恢复前台时从零开始。

针对这个问题的应对策略是：必要的数据在每次变更时就同步写入本地存储，而不是攒批落盘。虽然前面提到5分钟批量落盘是一种性能优化手段，但对于倒计时这种一旦丢失就造成功能失效的关键数据，必须在每个关键状态变更点(ex：倒计时启动时、暂停时、结束时)立即写盘。用空间换时间，换的是数据的安全性。

另一个生命周期管理差异是：OpenHarmony的UIAbility在后台被系统清理后，用户从最近任务列表重新进入时可能拿到一个全新的Ability实例。此时单例数据模型已经被清空，必须从本地存储重建数据。我在工程入口的main函数里加了数据恢复逻辑：启动时先读取本地存储，如果发现存在未完成的倒计时任务，就直接进入休息引导页，而不是让用户回到一个空白的主页面。

6. 常见问题与调试记录

6.1 页面卡顿和帧率不稳的排查实录

开发中期遇到过一个非常隐蔽的卡顿问题：主倒计时页在数字更新时，偶尔会有明显的顿挫感，但关闭掉倒计时动画后又恢复正常。排查思路先是怀疑是动画性能问题，反复优化CustomPainter的绘制逻辑却没有任何改善。

后来用Flutter Performance Overlay工具检测帧渲染耗时，才发现问题根本不在页面绘制上，而是Timer的回调触发的重建时机有问题。数字切换动画和每分钟的长针动画重叠时，两处动画同时触发重建导致掉帧。解决方案是让动画统一由同一个AnimationController驱动，用一个单一的帧回调处理所有动画更新，避免多路动画线程竞争渲染资源。

这个排查过程的经验是：Flutter的卡顿问题90%都不是绘制本身的问题，而是重建策略不合理导致的。定位问题要有数据支撑，不能只凭感觉去优化。优先打开性能检测工具，确认瓶颈所在，再做针对性的调整。

6.2 中文资源与字体加载的兼容性问题

在某个开源鸿蒙为目标系统的测试设备上，运行App时中文显示为方框乱码。查阅资料后确认是设备ROM中缺少中文字体文件导致的，不是App自身的问题。

临时方案是把一个开源中文字体文件打包进Assets目录，通过TextStyle的fontFamily属性指定为这个自定义字体。这个方案确实解决了显示问题，但也有明显的副作用：字体文件大小约4MB，App安装包体积显著增加，同时自定义字体的渲染性能不如系统字体。

这个问题的长期解决思路是推动系统层完善字体配置，App这边的处理方式则应该做成fallback：优先使用系统字体，检测到系统字体缺失时才加载Assets里的备用字体。

6.3 状态恢复与数据丢失的边界场景处理

在低内存设备上测试时发现一个边界问题：用户正在休息引导页倒计时，系统内存吃紧，App被系统回收。恢复后用户回到主页面，但休息引导页的状态已经完全丢失，等于一次休息被“跳过”了。

解决这个问题的思路是：不仅要把数据写入本地存储，还要写入“当前页面栈状态”。在App切到后台时，记录当前页面栈、内部倒计时剩余值、页面间传递的参数等关键信息，把整个运行状态序列化保存。App恢复时，如果记录到正处于休息引导页，就直接重建引导页并且恢复剩余时间，而不是贸然导航到主页面。

这个方案实现起来不麻烦，主要是把一个保存状态的类写好，在关键生命周期节点调用存取逻辑。带来的收益是用户感知不到App曾经被系统回收过，体验上实现了一定程度的“无缝恢复”。

6.4 常见问题速查表

7. 实践总结与下一步方向

这个项目的核心开发周期大约两周，从最初的页面原型到最终的可用版本，过程中经历了多轮调整和重构。回顾整个开发过程，最大的体会是：工具类App的页面设计不能只看视觉效果，更要注重交互链路和心理引导的细节。一个“跳过休息”按钮什么时候出现、提醒弹层用什么形式展现、倒计时走完给什么样的反馈，这些细节的差别直接决定了用户能不能真正坚持使用这个工具。

从技术的角度来说，Flutter在OpenHarmony上的跨平台能力已经相当能打了。UI层开发效率接近原生，性能表现达到可用标准，部分动画场景甚至比预期更流畅。当前阶段的限制主要在系统能力对接方面，部分OpenHarmony独有特性的API还没有完善的Flutter插件封装，需要开发者通过平台通道自己处理。

后续计划中，有几个明确的扩展方向。第一是增加远端数据统计能力，把每日护眼数据同步到服务端，支持多设备数据合并。因为目前的统计页数据只保存在本地，换设备之后历史记录就看不到了。第二是增加基于传感器数据的使用状态判断。通过加速度传感器检测手机是否处于手持状态，如果检测到用户已放下手机休息，可以提前结束倒计时而不是干等时间走完。第三是探索一次性同时提醒多个设备的方案。用户可能在手机和平板上同时工作，目前的提醒机制只作用于单个设备，多设备协同提醒需要设计一套服务端消息推送方案。

最后再分享一个小经验：这个项目让我对SharedPreferences这类轻量数据存储方案的使用边界有了更清晰的认识。数据量小、结构简单的场景下，用它完全没问题，读写快、代码简单。但一旦数据的规模和复杂度上升到需要查询、聚合、多表关联的时候，还是老老实实引入数据库方案更稳妥，不要在前期的代码结构上偷懒。我目前的项目里数据规模还比较小，所以SharedPreferences扛得住，但这个决策点需要提前做好判断，避免后期返工。