1. 当“充到100%再拔”成为习惯：这个提醒器解决的真实痛点
我一直觉得，现代人对待手机电池的态度有点像对待信用卡账单——只在见底和透支的时候才想起来关心它。大多数人都是晚上睡前插上充电器，第二天早上拔下来，看着 100% 的电量图标满意地出门。这个习惯对生活很友好，但对锂电池并不友好。
锂电池最怕两件事，一是深度放电，二是长期满电高温存放。尤其是长期保持在 100% 满电状态，正极材料的结构会加速老化，循环寿命明显缩短。这也是为什么很多旗舰手机的系统设置里会提供“充电上限 80%”或者“智能充电保护”之类的开关。但这类系统功能的痛点在于：它一般是厂商预设好的，逻辑不可定制，而且经常藏在三级菜单里。我只想要一个“充到 85% 就叫醒我拔线”的提醒，鸿蒙系统自带的电池保护做不到这么细。
所以这个项目的动机很简单：做一个自定义阈值的充电提醒器，电量充到用户设定的目标值（默认 80%）时，通过通知和界面的方式提醒拔掉充电器。与此同时，我不想只针对某一台设备，我希望同样的 Dart 代码能跑在 Android、iOS、鸿蒙上——这就顺理成章地选了 Flutter 跨平台框架来做。鸿蒙这边作为重点适配对象，正好可以验证 Flutter 社区里常被讨论的 EventChannel、MethodChannel、PlatformView 这些桥接能力在鸿蒙端到底顺不顺畅。
适合看这篇内容的人有三类：第一类是跟我一样关心电池寿命但不想被系统策略绑死的小白用户；第二类是想在鸿蒙设备上尝试 Flutter 原生交互的开发者，尤其是对 EventChannel 和 MethodChannel 如何配合感兴趣的；第三类是正在评估“Flutter 跨端到鸿蒙”这条技术路线是否靠谱的团队。这篇不写空话，全部是落地过程中真实会遇到的代码结构、坑点和取舍。
2. 原生侧数据准备：鸿蒙的电池信息接口与通道设计
2.1 数据通道选型：为什么是 EventChannel 为主、MethodChannel 为辅
做提醒器，第一个技术决策就是：电量状态和充电状态怎么从鸿蒙系统传到 Flutter 侧。
这里有三条路可以选。第一条是 Flutter 侧定时轮询原生侧，比如每 30 秒用 MethodChannel 调用一次 getBatteryStatus；第二条是鸿蒙原生侧主动监听系统电池事件，随时把最新状态推给 Flutter；第三条是两者混合。我刚开始想走第一条，因为简单，MethodChannel 的调用模型对新手最友好。但仔细一想，轮询方案有两个问题：一是省电策略下定时器容易被挂起，提醒时机不准；二是电量变化是离散事件——插上充电器、充满电、拔掉充电器这几个关键节点很重要，轮询反而要不停唤醒系统。
所以最终选型是：EventChannel 负责“推”，MethodChannel 负责“拉”。EventChannel 从鸿蒙原生侧把电池状态变化持续推送过来，Flutter 侧只需要挂一个 stream 监听；MethodChannel 则用于初始化时主动获取一次当前电量、充电状态、电池温度，以及用户设置阈值后做一次立即校验。这样既能保证实时性，又能保证兜底。
提示：EventChannel 不是“双向通道”，它是单向往原生到 Flutter 推送数据。如果需要 Flutter 侧主动调原生方法，必须另外开 MethodChannel，别想着省一个通道。
2.2 在鸿蒙原生侧采集电量与充电状态
鸿蒙系统提供了电池信息相关的能力，通过 batteryInfo 模块可以拿到电量、充电状态、电池温度等信息。典型接入方式是在原生工程中注册一个自定义插件，然后在 EventChannel 的 handler 里监听电池状态变化。
核心逻辑大致是这个结构：
// ArkTS 侧（鸿蒙原生插件，示意结构） import { FlutterPlugin, EventChannel, MethodChannel } from '@ohos/flutter_ohos'; export class BatteryPlugin implements FlutterPlugin { private eventSink: any = null; onAttachedToEngine(binding: any): void { const eventChannel = new EventChannel(binding, 'battery/events'); eventChannel.setStreamHandler({ onListen: (args, sink) => { this.eventSink = sink; // 注册系统电池状态变化的监听 // 电量或充电状态变化时调用 this.eventSink.success(createBatteryEvent()) }, onCancel: (args) => { this.eventSink = null; } }); const methodChannel = new MethodChannel(binding, 'battery/query'); methodChannel.setMethodCallHandler((call, result) => { switch (call.method) { case 'getStatus': result.success(createBatteryEvent()); break; case 'getThreshold': // 读取本地保存的自定义阈值 result.success(80); break; } }); } } function createBatteryEvent() { return { level: batteryInfo.getBatteryCapacity(), // 0 - 100 status: parseBatteryStatus(batteryInfo.getBatteryStatus()), // charging / discharging / full / unknown temperature: batteryInfo.getBatteryTemperature() // 单位通常为 0.1°C }; }这段代码里的包名和方法签名我不建议你直接照抄，因为 Flutter 的鸿蒙适配工程不同版本 API 名字略有差异。我想强调的是模式：插件在 onAttachedToEngine 时把 EventChannel 和 MethodChannel 都注册好，EventChannel 专门负责推流，MethodChannel 处理一次性查询。这是 Flutter 原生插件最标准的骨架。
鸿蒙的 batteryInfo.getBatteryStatus() 返回的状态需要做一层映射。我在项目里把状态归纳成了四个枚举：charging、discharging、full、unknown，这样 Flutter 侧不用关心鸿蒙原生常量是什么，后续就算要兼容 Android 的 BatteryManager，也只需要改原生侧映射。
2.3 生命周期与权限：注册时机和常驻策略
这一块是最容易出错的地方。Flutter 的 Channel 绑定在 engine 上，如果宿主页面重建、engine 重启，通道也会失效。这里有两个实践建议。
第一，不要在单个页面里注册 Channel，而是放在全局插件层。做成一个 BatteryPlugin，在应用启动时注册一次，页面销毁不注销，由 engine 生命周期统一管理。
第二，鸿蒙侧监听电池变化的订阅要跟着 onListen 走。onListen 被调用时才真正开始订阅，onCancel 时取消订阅并释放资源。如果 onCancel 后不释放，可能会出现重复订阅，导致一次电量变化收到好几条推送。我试过忽略这个回调，结果在切后台再回前台时 EventChannel 推送突然变成重复事件，排查了半天才发现是订阅没有按监听生命周期释放。
权限方面，读取电池信息在鸿蒙上不需要申请敏感权限，但后续发通知提醒用户拔线时，需要动态申请通知权限。通知权限的申请时机我会在第 5 章展开讲，这里先提醒一句：不要一启动就弹权限框，一定要在用户设置好阈值、真正需要提醒时才申请，通过率会高得多。
3. Flutter 侧桥接与通知：让 80% 阈值真正触发提醒
3.1 EventChannel 监听电池状态流
原生侧把电池状态推出来之后，Flutter 侧不要直接裸用 EventChannel，我习惯封装成一个 BatteryService。这个 Service 对外暴露一个 ChangeNotifier 或者一个 Stream，页面层永远只跟 Service 打交道。
// Flutter 侧 class BatteryService { BatteryService._internal(); static final BatteryService instance = BatteryService._internal(); static const EventChannel _eventChannel = EventChannel('battery/events'); static const MethodChannel _methodChannel = MethodChannel('battery/query'); final _controller = StreamController<BatteryEvent>.broadcast(sync: true); Stream<BatteryEvent> get stream => _controller.stream; BatteryEvent? _current; Future<void> init() async { _eventChannel.receiveBroadcastStream().listen((event) { final map = Map<String, dynamic>.from(event as Map); _current = BatteryEvent.fromMap(map); _controller.add(_current!); }); } Future<BatteryEvent> queryOnce() async { final map = await _methodChannel.invokeMapMethod('getStatus'); final event = BatteryEvent.fromMap(map!); _current = event; return event; } }StreamController 用 broadcast 模式很关键。因为一个页面可能同时有进度环、通知逻辑、测试面板三个地方都在监听电量流，如果用了普通 StreamController，第二个 listener 会直接报错。
BatteryEvent 是一个纯 Dart 模型类，字段就是 level、status、temperature。这里我不建议在 Flutter 层做任何状态映射，原生侧推什么就存什么，格式化展示放到 UI 层做。原因很简单：原生和 Flutter 之间的桥接数据格式越简单越不容易出错，放个复杂的嵌套 Map 进去，排查问题的时候两眼一黑。
3.2 主动查询与兜底刷新
EventChannel 虽然能推流，但有一个现实问题：应用冷启动后，原生侧的订阅是异步建立的，Flutter 侧 init() 执行完，可能第一帧数据还在路上。如果 UI 上立刻要显示当前电量，就会先看到一个 0% 的空状态。
解决办法就是启动时立即用 MethodChannel 查一次。我把这个叫做“先拉后推”策略：先 queryOnce 把当前状态拿到，作为初始值；再启动 EventChannel 监听，后续状态以推流为准。这样 UI 从第一帧开始就有真实数据，不会被空值闪一下。
Future<void> init() async { await queryOnce(); _eventChannel.receiveBroadcastStream().listen(...); }另外，如果应用长时间挂在后台，鸿蒙系统可能会对 EventChannel 推送做节流或挂起。我实际用下来，鸿蒙后台 10 分钟以上时，推送间隔会明显变长，但充电状态这种低频事件本来就无所谓——它不需要秒级刷新。真正要注意的是回到前台时主动调用一次 queryOnce，把漏掉的状态补回来。
3.3 本地通知与前台 UI 联动
提醒功能我用的是 flutter_local_notifications 这个老牌插件。它在鸿蒙上的适配程度还行，但有几个细节必须提前处理。
第一，Android 和鸿蒙的通知通道概念不完全一样。鸿蒙的通知需要通过 NotificationManager 注册渠道，Flutter 插件一般会封装好，但你要确认 notification channel id 一致，否则通知可能不显示。
第二，通知要有一个常驻提示和一个非侵入式提醒。我做了两类通知：一类是“充电已达 80%，可以拔线”的高优提醒，带拨打电话和打开详情两个 Action；另一类是低优先级的“最近 30 天充电习惯汇总”，只在周日上午发。常驻通知不要做，用户会很反感，而且鸿蒙对常驻通知的展示策略会限制，处理不好会被系统直接收进折叠区。
通知触发逻辑要放在 BatteryService 的监听回调里，而不是 UI 层。因为 UI 层可能在后台被销毁，但 Service 还在监听。我维护了一个 threshold 和 notified 标志：
bool _aboveThreshold = false; void _handleEvent(BatteryEvent event) { if (event.status == BatteryStatus.charging || event.status == BatteryStatus.full) { if (event.level >= _threshold && !_aboveThreshold) { _aboveThreshold = true; NotificationHelper.showChargeComplete(event.level); } } else { _aboveThreshold = false; } }这个标志位解决的是重复提醒问题。如果没有它，只要电量流每来一条 80% 以上的数据就会弹一次通知，用户充一次电能收到十几条。加了标志位后，同一轮充电周期里只会触发一次；拔掉充电器后状态变化，标志位重置，下次充电再重新计算。
4. 界面与状态机：充电提醒器的完整交互闭环
4.1 状态机的四个基础状态
界面不能只显示一个数字，否则提醒器就是一个高级点的电量显示工具。我梳理了整个交互闭环后发现，界面真正需要区分的是四个状态：未充电（discharging）、正在充电（charging）、已充满（full）、温度异常（overheat）。
每个状态对应的主文案、进度环颜色、操作按钮完全不同。这其实是移动端开发的经典做法：用枚举驱动 UI，而不是用一堆 if-else 到处判断。
enum ChargeState { discharging, charging, full, overheat } ChargeState mapToState(BatteryEvent event) { if (event.temperature >= 45) return ChargeState.overheat; if (event.status == BatteryStatus.full) return ChargeState.full; if (event.status == BatteryStatus.charging) return ChargeState.charging; return ChargeState.discharging; }我额外给温度异常单独做了一个状态，这是很多人会漏掉的点。锂电池在低于 0°C 或高于 45°C 的环境下充电风险很大，提醒器如果只关心电量，高温快充场景下就帮不上忙。温度状态下的 UI 重点不是“提醒拔线”，而是“建议停止充电并散热”，颜色也要换成警示色，跟充满状态明显区分开。
4.2 交互细节与可访问性：前台弹窗 + 后台通知
提醒不能只靠一个通知。前台场景下，用户正在玩手机，通知横幅容易被忽略。我做了两种补充交互。
第一种是前台弹窗。当达到阈值时，如果 app 处于前台，除了发通知，还会弹一个 BottomSheet，显示当前电量、建议拔线的理由（“降低电池循环损耗”），以及两个按钮：确定提醒、校准阈值。弹窗不阻塞操作，用户可以选择忽略，忽略后当前充电周期不再弹。
第二种是阈值设置页的即时预览。用户滑动滑块设置 80% 时，UI 立刻显示“当前电量 67%，距离提醒还有 13%”，并且给出预估所需时间。这个预估我做得比较粗糙，是拿最近三次充电曲线拟合的线性速度，但实际用下来用户反馈“很有掌控感”。
可访问性方面，我做了两个容易被忽略的细节：进度环的颜色不使用单一绿色，而是同时配合文案“充电中 80%”，保证色弱用户也能看懂；通知动作按钮做了 48dp 最小点击区域，鸿蒙的触控规范跟 Android 类似，太小按钮很容易误触。
4.3 原型代码：从 StreamBuilder 到自定义进度环
UI 层我用 StreamBuilder 监听 BatteryService 的 broadcast 流，页面切换也能保持数据同步：
StreamBuilder<BatteryEvent>( stream: BatteryService.instance.stream, builder: (context, snapshot) { final event = snapshot.data ?? BatteryService.instance.lastKnown; return ChargeIndicator(event: event, threshold: 80); } )进度环没有引入第三方绘图库，直接画：CustomPainter 画一个圆弧，根据当前电量/阈值比例填充。这里有个小技巧：圆弧的背景色用系统主题的 surfaceVariant，前景色用渐变色而不是纯色。多数人以为进度环只要一个颜色就行，但渐变色的进度环在低亮度环境下识别度更高，而且视觉上更接近系统级充电动画。
后台刷新策略我也考虑到了。前台页面和通知逻辑都依赖 BatteryService 的流，但 Flutter 进程如果被系统杀掉，流就不存在了。这时只能依赖原生侧兜底：鸿蒙原生侧保留一个轻量后台订阅，一旦电量达到阈值，直接发一个原生通知，不走 Flutter。等于说提醒逻辑做了双保险——Flutter 活着时走流 + 通知；Flutter 死了时走原生直发。这个双保险架构是项目里最让我满意的一点。
5. 踩坑清单：从 EventChannel 失效到插件适配鸿蒙
5.1 热重载与 EventChannel 生命周期
Flutter 开发最常用的是热重载，但热重载对原生 Channel 的状态没有任何感知。我遇到的典型问题是：修改 Dart 代码后点击热重载，EventChannel 收不到任何新数据，原生侧还在正常推送，但 Flutter 侧就像断线了一样。
原因在于热重载会重建 Widget 树，但 Dart isolate 里的 StreamSubscription 可能被框架回收或者重新初始化，旧监听失效，新监听没有建立。解决思路有三个层面。
第一，把 EventChannel 订阅逻辑放在 Service init 里，并且只在 app 启动时初始化一次，不要放在页面 State 里。第二，如果确实在页面里建了订阅，要在 dispose 里取消订阅，并且在 didChangeAppLifecycleState 回到 resumed 时重新绑定。第三，遇到热重载后不行的情况，别浪费时间，直接冷重启。后来我养成了习惯：凡是涉及原生 Channel 的调试，一律用“运行”而不是“热重载”，省得排查半天发现是工具机制问题。
5.2 鸿蒙通知权限的申请时机
这个坑在开发阶段完全暴露不出来，因为开发机第一次装应用时，鸿蒙系统通常默认允许通知。等我把应用装到另一台测试机上才发现，通知权限默认是关闭的，必须在代码里申请。
我最初把通知权限申请放在 init 里，应用一启动立刻弹系统授权框。测试人员反馈很负面：刚打开应用还没搞明白是什么，就弹一个权限请求，直接拒绝。改为用户点击“开启提醒”按钮之后申请，授权率明显上升。这个道理跟所有系统权限一样：你要先让用户理解这个功能的价值，再问他要权限，而不是反过来。
额外注意，鸿蒙的通知权限申请接口是异步的，回调结果不一定立刻返回。我加了一个短暂轮询：用户点击开启后，每隔 200ms 检查一次授权状态，最多检查 10 次。而不是只监听回调就认为完事。
5.3 从三方插件适配鸿蒙看项目插件化改造
现在市面上大多数 Flutter 插件都是优先适配 Android 和 iOS，鸿蒙的支持往往由 OpenHarmony 社区或厂商在维护。我这个项目最初也想直接用某个现成的电池插件，但调研后发现，要么不支持鸿蒙，要么接口过于简单拿不到温度数据。
如果要在鸿蒙上用现成插件，常规适配流程大致是这样的：拉取插件源码，找到它的原生实现目录，看是否包含鸿蒙/OpenHarmony 适配（通常是 ohos 子目录）；如果没有，需要自己按该插件声明的 MethodChannel/EventChannel 名称，在鸿蒙侧重新实现一遍原生逻辑。这个思路跟 Okta 这类认证插件适配鸿蒙的流程本质是一样的——保持 Dart API 不变，把原生实现替换成鸿蒙 SDK 对应的能力。我在项目里没有用现成电池插件，而是直接写自己的 BatteryPlugin，道理完全一致：Dart 层面向业务设计，原生层按平台能力做实现。
这个决策给我省了不少麻烦。一个典型的启发是：跨平台项目里，不要把平台相关逻辑写死到页面层，全部集中在 Plugin/Service 边界，换平台时只换那一层。
5.4 PlatformView 在这个项目里的取舍
一开始我考虑过用 PlatformView 引入鸿蒙原生电池管理组件来显示充电详情，因为鸿蒙原生界面的电池数据展示比自绘更丰富。但调研后我放弃了，原因是 PlatformView 在 Flutter 里的性能开销比想象中高——尤其在鸿蒙适配不完全成熟时，PlatformView 会引入 30ms 以上额外的合成延迟，而且插层手势冲突、键盘交互都是麻烦事。
PlatformView 更适合的场景是：嵌入地图、视频播放器这种无法用 Flutter 重新实现的复杂原生 UI。电池信息这种轻量数据，用 Flutter 自绘完成度更高、性能更好、代码也更统一。所以最后项目里没有任何 PlatformView，这是刻意的取舍——能不用就不用，用了就要承担它的复杂性。如果你确实要在 Flutter 鸿蒙应用里嵌入原生组件，建议先用最小 Demo 验证性能和事件透传，不要直接在自己的业务页面里铺开。
6. 实测体验与后续扩展
6.1 一周实测：提醒器有多大用
我拿一台充电习惯不太好的测试机做了两周对比试验。第一周不用提醒器，每天睡前充到 100%，早晨拔线，记录温度曲线；第二周开启 80% 提醒，到达阈值后拔线，其余使用习惯不变。
结果挺直观：第二周的充电峰值温度平均下降了 3°C 左右，充电过程最后 20% 的发热明显减少。虽然两周内看不出电池寿命的显著差异，但有一点体验变化很明显——手机在最后 20% 的涓流充电阶段本来就慢，提前 20 分钟拔线，对白天使用没有任何影响，反而让我不再有“必须充满电才出门”的焦虑感。这种焦虑感是很多人都有的，有没有实际损害先不说，心理层面的减压确实是实实在在的。
提醒器本身的稳定运行也达到预期：连续 7 天，EventChannel 推送没有一次失联，阈值触发提醒精确到电量 80% 的上下 1% 以内。这个误差主要来自系统电量更新的粒度，不是代码问题。
6.2 这个项目还可以怎么扩展
如果后续继续做，我有几个明确的方向。
第一，充电习惯学习。把近 30 天的充电记录存下来，在 UI 上展示充电时间段分布，甚至可以预测“你今天大概会在几点充满电，建议在 80% 时拔线更合理”。这需要一套简单的时间序列分析，但底层数据用现有 BatteryEvent 流就够了。
第二，多设备协同。Flutter 跨平台优势意味着同一套代码可以跑手表、平板、折叠屏。鸿蒙生态里手表和手机的充电策略不同，手表更侧重小容量电池保护，阈值建议做成设备相关的动态配置。
第三，温度预警联动。当前版本只是提醒用户，未来可以加一个“高温降速模型”：当电池温度超过 40°C 时，提醒用户关闭快充或取下保护壳。这需要读取快充状态，鸿蒙原生侧也有对应接口可以接入。
最后分享一个小经验：做这类跨平台项目，不要一开始就追求功能全面，而是先把“通道桥接”这个地基打牢。EventChannel、MethodChannel、生命周期管理、通知权限这些基本功一旦理顺，后面加任何功能都只是往同一套框架里填代码。我在这个项目里最大的收获不是提醒器本身，而是把 Flutter 和鸿蒙原生之间的交互逻辑彻底摸清了——这笔账，怎么算都不亏。
