接手这个项目的时候，我第一反应是：这活儿听着简单，实际上是个深水坑。OpenHarmony设备要想跑Flutter应用，本身就有一堆兼容性债要还，现在还要把一个安全检测组件从Android/iOS那一套逻辑里搬上去——意味着不仅要把Flutter引擎拉到新平台，还要把原生的检测能力通过Channel桥接过去，每一步都在跟平台差异较劲。
不过反过来想，这也是Flutter跨平台开发最有意思的地方：当标准插件市场里没有现成方案时，你对这套框架的理解深度，就决定了你能走多远。这篇文章就把我这次适配的完整过程、踩过的坑、以及最后的取舍逻辑全部摊开讲，给正在做类似事情的开发者参考。
1. 项目背景：为什么安全检测组件在OpenHarmony上是个硬骨头
1.1 OpenHarmony的生态现实与Flutter适配现状
先看大环境。OpenHarmony作为一个独立的操作系统，在外界看来最大的问题是生态不够繁荣，但真正懂的人知道，它最大的麻烦是兼容性分叉。不同厂商的设备跑的OpenHarmony版本、API等级、内核改造程度都不一样。官方有兼容性测试来约束，但落到具体设备上，你敢信它跟模拟器行为一致，那就是给自己埋雷。
Flutter在OpenHarmony上跑，目前不能直接用官方SDK。原因很简单：Flutter官方只认Android和iOS两套embedding层，而OpenHarmony既不是一个"兼容AOSP"的系统（至少在API策略和系统服务上不是），也不是Linux桌面那种可以直接套壳的环境。所以你需要在社区Fork里选一个可用的Flutter鸿蒙化版本，这套东西内部对引擎做了大量改造：从Dart VM的编译目标、到引擎的图形栈对接、再到平台通道的注册表重写，全都要适配。
这部分工作如果自己从零做，工程量是个无底洞，好在社区已经有相对成熟的方案，但"能用"和"稳定"之间差得很远。我在项目初期做技术预研时，拿真机跑了一个最简单的Hello World，就发现两个问题：一是首帧渲染时间明显偏长，二是某些系统服务的调用路径跟Android上完全不同。后者直接影响了安全检测组件的设计思路。
1.2 安全检测组件为什么不能照搬Android逻辑
安全检测组件，顾名思义，是针对运行环境做安全评估的模块。在移动端它通常干这些事：检测设备是否被Root、是否有调试器附着、是否能被动态注入、包是否被重打包或签名篡改、运行环境是不是模拟器、以及是否存在危险的服务暴露。这类组件在银行类App、企业办公App、内容版权保护类App里很常见，位于客户端风控链路的最前端。
在Android上做这些检测，路子很成熟：查文件系统里的su路径、检查调试属性、比对签名、遍历已安装应用的异常特征、用Native层Mach-O或ELF解析来做完整性校验等等。可一旦搬到OpenHarmony，几乎所有前提都变了。
OpenHarmony的应用沙箱模型不一样，文件系统布局不一样，进程调试接口不一样，包管理机制也不一样。更致命的是，它没有Android的PackageManager那些现成API，很多"看系统怎么想"的操作你根本找不到对应接口。这意味着安全检测组件不能靠移植，必须做一次"语义保留、逻辑重写"的工程。你得把每一个检测项的底层原理吃透，知道它到底在检测什么，然后才能在新平台上找到对应的实现路径。
1.3 项目目标与最终交付样态
我们要交付的组件，从用户视角看是一个Flutter插件包，业务开发者在Flutter层调用几个看起来很简单的API，就能拿到一个综合安全评分和明细项结果。
从架构视角看，它实际上要横跨四层：最上层是Dart层的统一抽象接口，中间是Flutter的MethodChannel通信层，再往下是OpenHarmony侧的ArkTS插件实现（负责能通过系统API完成的那部分检测），最底层是C/C++实现的检测核心（负责文件系统、调试标志、内存特征这类需要贴近内核和系统底座的检测项）。
这个分层是刻意设计的。ArkTS层做"系统相关、常规能力"的检测，编译期跟着系统API走，行为透明；C/C++层做"对抗性较强"的检测，因为它更接近底层，不容易被应用层的Hook影响。两个层次的结果汇总后统一通过Channel返回给Dart层，由Dart层做评分策略。后面我会详细讲这个分层是怎么落地的。
2. 整体方案与技术选型：两条路线的取舍理由
2.1 路线一：改造开源安全库的思路
一开始团队内部讨论过一套方案：在开源社区已有的Flutter安全检测插件（比如某些项目里自带的各种Security插件）基础上，把它的Android实现逻辑梳理清楚，然后针对OpenHarmony的系统API重写原生部分，Dart部分保留。
这个方案的优势是省事。Dart层的API设计、状态管理、错误码体系都是现成的，理论上只要保证原生侧实现了通道里的方法，上层就不用动。但实际做下去，问题暴露得很快。
最大的坑在于：这些插件大多数把检测逻辑写死在Android的Java/Kotlin层，很多检测项依赖Android特有的类。比如判断是否调试模式，Android上可以看Debug.isDebuggerConnected()，也可以读/proc/self/status里的TracerPid；但在OpenHarmony上，ArkTS并没有直接等价接口（至少在当前可用的API版本上找不到），你只能自己通过Native层去读/proc。类似这样的"依赖漂移"几乎遍布每个检测项。
也就是说，"复用现有插件"只是看起来美，真正动起手来，你要么被Android API绑架，要么就是花大量精力把每个检测项从Android依赖中剥出来，重新实现一遍。中间的通信协议可能还得跟着改，到最后跟上一种方案的工作量差不了太多。
2.2 路线二：从零设计分层插件架构
第二条路线就是最终我们走的这条：Dart层完全自己写，接口设计以实际业务需要为锚点，不迁就任何历史包袱；原生侧拆分ArkTS和C/C++两层，根据每个检测项的检测原理决定放在哪一层。
这个方案的优点是：每个模块都清楚自己为什么存在、依赖什么能力、在什么情况下可能失效。安全检测组件最忌讳模糊边界，检测逻辑如果混在一起，任何一个环节被Hook或者被绕过，整条链路的可信度都会崩塌。分层设计虽然是基本功，但在安全组件这个场景里，它的重要性被放大了很多倍。
另一个重要的点是，这套架构后续扩展起来很方便。OpenHarmony系统在快速迭代，API不断在变。如果架构上把系统API相关的检测逻辑全部集中在ArkTS插件层，把底层的Native检测核心保持相对独立，那么系统升级导致的API变更，影响范围就能控制在很小。
2.3 为什么最终选择了Route B
说实话，最终选从零设计不完全是因为技术洁癖，更多是工期和安全性的双重压力。
安全检测组件跟普通业务组件不一样，它的代码是要被对抗的。如果一个检测组件大量依赖第三方未被审计的代码，你根本不知道它的哪一行判断会被攻击者反编译利用。从零设计意味着每一行核心逻辑我都能说清楚背后的检测原理，这对后续的代码混淆、反调试加固也有好处。
而且，这套方案真正落地之后，我们发现工作量并没有比改造成熟插件大多少，反而在调试上省了很多时间，因为问题边界非常清晰：Dart层的bug不会跑到原生层去查，原生层的问题也不会被Dart层的历史代码干扰。
最后做个简单对比，便于理解为什么直接迁移行不通：
| 决策点 | 直接迁移现有插件 | 从零分层设计 |
|---|---|---|
| 短期工作量 | 看似较小，实际拆解成本高 | 前期偏大，中期稳定 |
| Android API依赖 | 高，容易被绑定 | 低，按原理重写 |
| 检测可对抗性 | 一般 | 更强 |
| 系统版本适配成本 | 高，随插件历史包袱拖累 | 低，模块边界清晰 |
| 后续扩展 | 需要绕开旧逻辑 | 直接加检测项 |
3. 核心实现：安全检测组件的分层设计与Channel适配细节
3.1 Flutter侧的接口设计：让业务方拿到的只有"结果"
先讲Dart层。在Flutter应用里，业务方不关心你到底检测了什么、检测机制是什么，他们只想要一个结果，以及必要时可以定位问题的明细。所以我们把接口设计成两个层次。
第一层是总入口，业务方只需要调用一个异步方法，传入一个可选的配置对象，就能拿到一个SecurityReport对象。它里面包含一个整体评分（0到100分）和每个检测项的枚举结论、对应的证据描述、以及建议动作。整体评分是"建议性"的，组件只做事实输出，不做强硬的拒绝动作——因为是否拦截行为应该由业务方自己决定，安全组件越权做拦截反而容易被绕过。
第二层是诊断入口，允许业务方按需只跑某几个检测项，比如上线前自检时可以只跑"环境完整性"相关的两个检测，不用把全部检测项都过一遍。这个设计主要是考虑性能。安全检测如果全量跑，在低端设备上可能要几百毫秒到一秒多，某些检测项还会触发系统底层调用，频繁跑并不合适。
在实现上，Dart层用了一个简单的类结构来管理请求码，检测方法通过MethodChannel.invokeMethod调用原生侧，方法名和参数用Map封装。这里有个细节：Dart侧不要抛裸异常，所有Channel调用错误都要转换成自定义的SecurityPluginException，这样才能保证业务方接的时候不会被一堆PlatformException搞晕。
3.2 Channel通道适配：注册表、名称、参数编码的坑
Flutter和原生侧的通信靠的是Platform Channel。在标准Flutter SDK里，Channel名称是一个字符串，两端各自维护一份对应的注册逻辑。Android侧需要实现MethodChannel.MethodCallHandler，然后在configureFlutterEngine里注册。在OpenHarmony的社区Fork里，这套机制被重写成了另一套更贴近系统自身插件框架的形式。
先说注册。OpenHarmony侧支持用ABI中的C接口做插件注册，但更常采用的是它自带的插件扩展机制，然后在Flutter引擎初始化时通过特定的注册表绑定。这里要注意的是：注册表名称有长度限制，如果Channel名取太长，超过了系统内部缓冲区的阈值，会出现"注册成功但调用时无响应"的诡异问题。我被这个坑卡了大半天，后来把Channel名从一长串语义化命名改短为sec_detect，问题直接消失。
参数编码也有讲究。Flutter的StandardMethodCodec在编解码时是跨平台统一的，理论上你传Map给OpenHarmony侧，它收到的是一个Map。但OpenHarmony的ArkTS侧拿到的Map在迭代时要注意类型判断，尤其是整数和长整型，有时候Dart侧传个int过去，ArkTS侧拿到的可能是double或者long，需要做显式转换。这个小问题在Android上几乎不存在，但在OpenHarmony上，标准编解码的边界处理确实还不够圆滑，稳妥做法是统一把数字全转成String再传，成本低、可读性好、避免一系列类型问题。
3.3 ArkTS原生插件：系统API能做什么、不能做什么
ArkTS侧的插件职责，我的定位是：只用系统公开的API完成能用公开API完成的检测。
比如设备基本信息：通过系统的设备信息API拿设备型号、系统版本、硬件标识，跟运行时环境做比对，检查是否出现明显的"识别漂移"。系统API这里够用，而且这些信息是安全风控里最基础的特征。
再比如应用自身完整性相关的部分信息：ArkTS能拿到当前应用的安装来源、应用包名、版本号，但拿不到更底层的签名信息。因为OpenHarmony当前的API策略里，签名校验并没有完全开放给普通应用。所以签名完整性这块就只能放到Native层，用运行时特征的方式来辅助判断（比如运行时Dart侧记录的包哈希和原生侧计算出的哈希比对）。这个思路跟Android上的做法不一样，Android可以直接用PackageManager拿签名，OpenHarmony得靠"自证"和"交叉验证"。
ArkTS层的实现难点在于异常处理。系统API在某些设备上会返回空的枚举值或抛出业务异常，你不能假设所有API在所有版本上都稳定。所以我在ArkTS侧统一做了一个SafeCall的封装：任何API访问都包一层try-catch，捕获后返回一个表示"能力不可用"的状态码，由上层决定是降级还是直接报风险。安全组件里，"能力不可用"本身就是一种风险信号，容易被拿来绕过。
3.4 C/C++侧不可信环境检测：把核心边界筑牢
Native层是这次适配中风险最高、回报也最高的工作。它负责的内容，核心就是那些"系统不会给你答案、你得自己去看"的部分。
第一个是Root/越狱检测的OpenHarmony变体。Android上查su文件路径、查build.prop里特定字段这些招，在OpenHarmony上对应的做法是检查系统分区是否被解锁、某些系统路径是否出现了开发者特征的覆盖文件、以及/system/bin下有没有不该存在的调试工具痕迹。具体实现上，我是遍历一组特征路径，检查文件是否存在、是否可执行，再结合权限位做加权判断。这里要小心误报：有些厂商的工程机本身就带调试工具，如果一刀切全报"高风险"，那真机测试时满屏报警，业务方也会烦。
第二个是模拟器检测。OpenHarmony的官方模拟器常见特征包括：CPU型号不是真实ArmSoC榜单内的型号、传感器数据返回异常（比如重力感应永远返回同一组值）、系统属性里存在模拟器专用字段。Native层可以直接通过读取系统属性文件和尝试调用某些只在真机上才有的设备节点来做特征提取。这个检测项有个技巧：不要把某一个特征单独当结论，要做加权投票，至少命中多个特征才判定为疑似模拟器，否则误杀率很高。
第三个是进程调试与动态注入检测。这个需要在Native层读/proc/self/status的TracerPid，如果非零，说明有进程在跟踪当前进程。同时在ELF的链接映射表里检查是否加载了非预期路径的共享库。这类检测逻辑要写得隐蔽，循环时机要随机化，不能让攻击者找到固定返回点去Hook。
第四个是完整性校验。我们在Native层预埋了一段哈希值，运行时对自己关键代码段的特定区域做实时哈希计算，和预埋值比对。OpenHarmony的加载机制和ELF重定位跟Android不完全一样，所以计算区域的选择要避开会被运行时重写的数据段。这个参数调了一整天，最后锁定在代码段对齐页的偏移范围内。
Native层的编译目标：OpenHarmony的Native开发使用它自带的NDK思路，通过CMake构建.so库，然后在Flutter插件里用System.loadLibrary类似的机制去加载（OpenHarmony的API路径略有不同）。这里的构建配置有个重点：必须同时编译arm64-v8a和x86_64两套ABI，因为模拟器通常是x86_64，真机是arm64，否则模拟器测试直接加载不了so库。
3.5 数据回传与聚合判定：评分口径要能解释
各检测项的结果最后汇总到Dart层，由Dart层做聚合评分。评分不做简单的等权重求平均，而是给每个检测项分配一个风险权重，并且预留了一个"一票否决"的逻辑：当某个高危项（比如检测到动态注入迹象）确认命中时，综合信任分直接压到低档。道理很简单，安全检测组件不是做学术打分，它输出的是给风控决策用的信号，如果某个致命风险已经确认存在，其他项的分再高也没有意义。
明细项的返回值里，每一项除了枚举结论，还带一个可选的风险描述文本。这个描述文本在Native层就生成好，直接以字符串传回，Dart层不做二次映射。这么做的好处是，后续想调整描述文案，只需要改原生层，不需要发新版Flutter包。
聚合评分完了之后，Dart层还悄悄做了一件事：记录本次检测的耗时和各个子项的序号，但不上报，只在调试模式暴露一个开关。这个设计是给后续线上问题排查用的。安全检测最怕"灵异事件"，业务方说检测结果变了，你连是哪一项变了都查不出，那就彻底抓瞎。
4. 实操落地与验证：从源码编译到真机联调
4.1 构建环境准备与依赖版本锁定
先说环境。Flutter的OpenHarmony社区版目前需要单独拉一套基于指定Flutter版本的Fork，然后在本地编译引擎。这里有个建议：不要用最新版，选择社区里issue解决数量最多、文档相对完善的中等版本，至少在项目周期内它会比较稳。版本锁定很重要，因为Flutter引擎的鸿蒙化适配每次升级都会带来一批新问题，尤其在平台通道行为上，回归风险不可控。
OpenHarmony侧的SDK也需要指定版本。我这次用的是API 11级别的SDK，对应DevEco Studio的某稳定版本。项目里的build-profile.json5配置要核对清楚，尤其是signingConfigs，因为OpenHarmony应用安装强制要求签名，调试签名和发布签名要在配置阶段就分开，不然后期切环境很痛苦。
构建时我建议先跑官方提供的最简示例，确认从编译到真机安装这条链路是通的，再往里加业务代码。这一步虽然浪费时间，但能帮你把"环境问题"和"业务问题"隔离出来。我就吃过这个亏，一上来直接编译整个组件，报错信息铺天盖地，根本分不清是Flutter Fork没配好，还是插件代码问题。
4.2 插件集成路径与加载确认
把组件集成到Flutter工程里，走的是pubspec.yaml里的path依赖方式，指向本地插件目录。在OpenHarmony的Flutter工程里，插件要被识别，需要在原生工程的module.json5里声明依赖的.so文件和HAP包中的Java/SO目录结构，否则运行时找不到Native符号。
集成后最值得花时间做的一步是确认Flutter引擎确实加载了OpenHarmony Plugin。在Dart侧可以写一小段自检，同时原生侧在插件初始化时输出一条标记日志，跑一次flutter logs（Fork版里对应的是hilog），能同时看到两端的日志，说明通道建立成功。这个验证不能跳过，因为社区Fork对插件的注册时机要求很苛刻：如果插件初始化在Flutter引擎的某些生命周期事件之后才注册，调用就会出现"方法未实现"的错误。
4.3 真机联调与日志分析：安全检测的"现场感"很重要
联调阶段，我强烈建议用真机+可控弱网环境这一组合。真机是为了拿到真实的系统行为，OpenHarmony模拟器在安全检测领域有很多假象（比如某些调试特征模拟器天然存在，真机上根本不会出现），所以以模拟器结果作为联调依据是会误导开发的。
调试时把hilog按照-D全量输出打开，重点看两个地方：一是Native层打印的每一个检测项的执行耗时和结论，二是Channel通信的二进制数据是否按预期返回。OpenHarmony的hilog比Android的logcat略繁琐一点，但信息量够大，而且能关联到具体进程。
我在真机联调时发现过一个有意思的现象：同一台设备，冷启动后第一次全量检测耗时约800ms，第二次就掉到200ms左右。原因是Native层的文件系统特征查询结果做了缓存，第二次直接从缓存拿。这个表现其实是符合预期的，但如果在做检测结果上报，就要注意加时间戳标记，避免业务方把两次结果混为一谈。
另外，安全组件的真机联调一定要覆盖几种典型设备形态：标准手机、可折叠设备、以及某类特殊行业终端。不同设备在传感器配置、文件系统权限上差异很大，我在可折叠设备上就遇到了上一次展开状态影响系统属性读数的问题，虽然影响不大，但这种case不跑真机根本不会暴露。
4.4 回归测试设计：造一个"可控的风险环境"
安全组件测试最头疼的是风险环境难复现。我建议造一个专门的"风险实验室"设备，按下面这个梯度来做测试：
- 安全基线：官方固件、未解锁、无调试工具、正规应用安装
- 轻度风险：开启开发者模式、打开USB调试、安装少量外部应用
- 中风险：通过某种方式修改系统部分属性（模拟部分root特征但不完全root）
- 高风险：完整root环境、挂载Frida类似的注入框架
每个梯度跑一遍全量检测，看结论是否落在预期区间。重点不是看单项检测准不准，而是看组合判断逻辑会不会在某个梯度出现跳变异常（比如从低风险直接跳到最高风险，中间没有过渡），这类跳变往往代表某个检测项误报率不稳定。
另一个要测的是组件在检测过程中被打断的行为。比如Flutter引擎被Android或OpenHarmony系统回收、插件所在页面被压入后台导致Native层stop等。安全组件有个特性：检测不能因为生命周期中断而挂起。我给每个检测项设置了超时控制，超时直接返回"超时不决"，统一按风险处理，宁可误判也不放过。这个策略在业务落地时可能给用户带来少许体验损耗，但安全本质上就是对不确定性的保守处理。
5. 踩坑实录与排查技巧：给后来者省时间
5.1 高频问题速查表
先整理一个速查表，这些是我这次适配过程中碰到的高频问题，按频率排序：
| 现象 | 根因指向 | 排查路径 |
|---|---|---|
| Channel调用后Dart侧收不到响应 | 注册表名称超长或插件注册时机晚 | 缩短Channel名，检查插件初始化日志 |
| Native层返回int类型在Dart侧变成String或double | 标准编解码在OpenHarmony侧的类型边界处理不统一 | 统一参数做字符串化传参 |
| ArkTS调用系统API偶发空指针或undefined | 不同API版本能力差异 | 用SafeCall包一层，捕获后返回能力不可用 |
| Native检测某特征在真机上误报 | 特征选取过窄或依赖系统属性的非稳定字段 | 改加权投票，结合多个特征 |
| .so库加载失败，报undefined symbol | ABI不一致或CMake链接参数漏了库 | 检查target_link_libraries，确认编译两套ABI |
| hilog里检测项执行顺序乱序 | Native层多线程运行时输出竞争 | 用统一带序号的日志格式，以Dart侧结果为准 |
排查方法论上，我建议一条铁律：先确认通道通不通，再检查数据对不对。很多安全组件的bug，表面看是检测逻辑算错了，实际上是Channel传参类型踩雷或者注册时机不对导致数据根本没到原生侧，后面全是瞎忙。
5.2 独家避坑心得一：Channel名称是隐形炸弹
这个我前面提过，但值得单独拿出来说。Flutter的Channel名称在Android和iOS上随便起都没事，但在OpenHarmony的社区Fork里，注册表对名称长度有内部限制。一旦超了，表现不是报错，而是"方法注册成功、调用无响应"，日志里连个warn都未必有。定位方法可以写一个最小Demo，分别测试短名称和长名称的通道调用，几分钟就能确认。所以后续我干脆定了个规矩：所有Channel名控制在20个ASCII字符以内，多出来的语义放在方法名上。
5.3 独家避坑心得二：系统API的"能力枚举"不是标准的
OpenHarmony跟Android一个很大的不同在于，它的系统API里很多返回值是"能力枚举"，带有明显的版本标记。同一个API在API 10和API 11上的行为可能完全不同。比如获取某些设备标识时，API 11版本会附带完整的硬件特征字段，API 10可能只返回部分内容甚至空字符串。这本身不是bug，但对安全检测来说是致命的：你的特征规则如果没有做版本适配，换一台系统版本不同的设备，检测结果就会静默变化。
解决办法是在ArkTS层统一做一次系统版本收集，把版本号作为参数传给Native层，Native层的特征规则按版本号分组。虽然代码量增加了一些，但安全检测组件的生命周期比普通业务模块长得多，这种版本分组能显著降低后续维护压力。
5.4 逻辑补充：为什么全量检测要做"随机化执行序"
安全检测组件还有一个不太容易注意到的点：检测项的执行顺序。如果每次执行顺序都一样，攻击者可以在固定时序上对某些检测项做定向绕过。所以我在Native层让检测项的执行顺序带一点随机性，每次全量检测时，非关键依赖项之间交换执行次序。代价是检测耗时会有波动，但换来的是对抗性更强。类似这种造价不大但收益明显的小机制，在安全类开发里挺值得积累的。
5.5 性能与耗电的平衡实践
安全检测组件的性能表现不能只看单次耗时，还得看它对设备整体电量和CPU占用率的影响。我做过一次对比测试：全量检测开启时，在低端设备上CPU瞬时冲到接近满载，持续几百毫秒，这对界面流畅度有肉眼可见的影响。优化方向有两条。第一是把部分低频检测项放到后台空闲时再跑，不在启动路径上全部执行。第二是Native层对某些文件扫描用异步IO，减少阻塞线程的时间，让CPU密集型操作不至于跟UI渲染抢资源。
5.6 与业务方的协作经验：安全评分的解释成本
最后补充一个非技术但很实际的坑：业务方经常把安全评分当成一票否决的硬指标，看到分低就直接拒绝用户操作，结果引发大量线上客诉。原因在于安全检测组件的评分是"信号参考"，不是"权威结论"。所以方案设计时，我强烈建议给业务方提供"建议动作等级"（提示、二次验证、拒绝、人工审核）而不是单纯的分数，让业务方根据自身场景选择不同动作。这个沟通如果在开发阶段就做好，能避免上线后反复扯皮。
6. 测试工具链与验收清单：确保组件在目标设备上可信
6.1 自带检测引擎与自检模式
为方便现场验收和问题定位，我在组件里内置了一个SelfInspect模式。调用后，组件把所有检测项的判定依据、关键特征路径、耗时、版本信息全部结构化输出。这个模式在生产环境默认关闭，但在测试阶段和售后排障时极其有用。操作员拿一台设备跑一遍自检，把输出结果贴给研发，基本就能定位八九成的问题，替代了来回传日志的流程。实现上其实就是在Dart层增加一个开关参数，原生层把原本用于聚合的明细数据直接JSON序列化回传。
6.2 验收清单模板
下面这份清单是我每次发布新版本前必过的，也分享出来给你参考：
- [ ] 环境基线：固件为指定版本且未被改造
- [ ] 风险梯度：模拟器和真机分别跑四个梯度的检测场景
- [ ] 进程级验证：在Frida挂载时是否能被准确识别并拉高风险评级
- [ ] 性能基准：低端设备上全量检测耗时不超过1.5秒，中高端设备不超过800毫秒
- [ ] 并发验证：多个业务模块同时调用组件时不会互相阻塞
- [ ] 版本兼容：至少覆盖API 10、API 11、API 12三档系统版本
- [ ] 签名验证：发布签名和调试签名下的安装包完整性校验逻辑不同结果符合预期
- [ ] 断电异常测试：检测过程中强制杀进程，重启后组件能正常自恢复
6.3 退出机制与降级方案
安全检测组件背后挂着风控，最怕的就是“组件挂了业务就瘫了”。因此必须设计明确的降级链路。我的做法是在Dart层做了一个状态机：原生侧如果有任意一个核心检测项返回“能力不可用”或出现异常，组件会进入Degraded模式，此时不再阻塞业务调用，统一返回一个低置信度的中性评分，并附带标记字段告知系统当前检测降级。业务方可以依据这个标记决定是放行还是转入人工审核，至少不会因为组件的故障而让整个业务不可用。设置这道防线之后，实际线上运行中即使遇到系统API变更或底层环境异常，用户侧基本是无感知的。
7. 本次适配的一个重要领悟：跨端适配的价值在"梳理"
完整做完这轮适配，我最大的感觉是：跨平台开发最容易低估的不是编码量，而是"梳理成本"。每跨一个平台，你都要把旧平台的隐含前提全部翻出来，重新审视一遍。安全检测组件尤其如此：你以为在Android上"查某个文件是否存在"是个简单动作，到了OpenHarmony才知道，这个文件在文件系统里存不存在不取决于路径，而取决于分区挂载策略和沙箱对当前应用的可见性规则。
Flutter的跨端能力和OpenHarmony的系统特性结合到一起，做的事情远比"在一个新平台上跑通"更有价值。它在逼着你把安全组件的每个检测项还原到原理层，然后再从原理层推导出新平台上的实现路径。这个过程的产出，是那颗对所有平台一视同仁的检测核心，而不是一堆堆在系统API上的搬砖代码。
如果你们团队也在做类似的适配，我的建议很简单：先别急着写代码，把你现有安全组件每一个检测项的原理写成一页纸，标清楚依赖的系统能力边界，再决定哪些放ArkTS、哪些放C/C++、哪些干脆不做。这个梳理做完，后面所有的代码工作基本就是按图索骥，排错时间能省掉一大半。
