React Native鸿蒙化实践：手写签名审批系统从选型到落地全记录

今年年中接到一个政务类应用的改造任务：证件核查完成后，审批人要在移动设备上完成在线审批，并且用手写笔迹完成电子签名，核查结果、签名图片、审批意见都要一起归档。最初我以为只是做一个手写签名组件，真正落地方案时才发现，核心难点根本不在画布上，而在于：React Native怎么在鸿蒙设备上稳定运行，笔迹采集怎么保证不丢点、不漂移，签名数据怎么和审批状态绑定，以及归档数据怎么才能做到可追溯、不可抵赖。这篇文章把整个项目的选型、鸿蒙化改造、签名组件实现、审批联动、存档合规和踩坑记录完整写出来，给准备做RN鸿蒙化或者电子签名功能的朋友一个参考。

1. 证件核查审批的业务链路：签名不是画布，而是流程终态

1.1 真实场景：核查、审批、签名、归档这四个环节分别是谁

这种需求通常出现在政务窗口、金融机构远程柜面、行政执法现场、保险定损等场景里。业务链路大致是：一线核查人员先录入证件信息，上传到后端调用外部证件核查接口，拿到核查结果；结果返回后并不是直接生效，而是需要有一个审批动作，通常由带权限的组长、主管或授权审批人对核查结果进行确认；确认的动作在移动端体现为手写电子签名，同时附上一句审批意见（同意或驳回）；确认后的完整数据包——核查结果、签名图片、签名人、审批意见、操作时间——一起落库归档，后续随时可以调出来审计。

我见过不少团队把这种需求简单理解成“做一个签名板”，结果交付后业务方不满意，因为签名画上去之后，既没有跟核查记录绑定，也没有审批状态流转，更没有归档审计能力。所以项目启动前，一定要先把业务链路里的角色和环节理清楚。

1.2 把需求拆成四层，避免做成一坨“会画画的页面”

从技术实现角度，这个需求可以拆成四个层次：

• 交互层：签名面板，负责采集用户手写笔迹，支持清空、重签、确认。
• 数据层：签名图片数据、签名人ID、签名时间、审批意见、设备信息、核查结果快照。
• 控制层：审批状态机，从待审批到审批中，再到已通过或已驳回。
• 归档层：持久化存储、防篡改校验、审计查询。

四个层次缺一不可。只做交互层，需求完成度可能不到30%。整个项目的难点分布也很不均匀：交互层大概占20%的工作量，控制层占30%，归档层占30%，剩下的20%是鸿蒙化和联调排查。

我当时的实现顺序是：先确定数据模型，再搭审批状态机，最后才写Canvas签名面板。因为签名面板界面改起来最直观，最容易返工，放在后面做反而能避免返工。

1.3 跨平台的硬约束：Android存量、鸿蒙试点、iOS后台并存

为什么不直接做一个鸿蒙原生App？因为项目现场有三个硬性约束：

• 存量Android设备上已经有一套稳定的业务App，里面包含证件录入、核查结果展示、历史记录查询等功能，不能推倒重来。
• 新采购的一批终端是鸿蒙设备，可能是HarmonyOS NEXT这种不兼容Android APK的系统，旧App装不上去。
• iOS设备主要用于后台管理的只读场景，也需要同一套业务逻辑覆盖。

这就意味着：前端必须跨平台，业务逻辑尽量复用一套代码，Android、鸿蒙、iOS三个端各自只做薄薄的原生壳和必要的桥接模块。React Native在这种情况下几乎是顺理成章的选择。团队原本就有RN的开发和调试经验，存量功能里有很大一部分业务页面可以直接迁移，不需要用ArkTS重写一遍。

2. 方案对比与最终选型：React Native如何进入鸿蒙战场

2.1 三个候选方案横评：纯鸿蒙原生、Flutter、React Native

立项时团队内部开了两次会，列出的候选方案很典型：纯ArkTS原生开发、Flutter、React Native。三者的取舍点不太一样。

从上面看，Flutter本身是个很好的框架，但在这个项目里的最大问题不是性能，而是存量业务资产。已有的RN页面、状态管理、接口请求层、工具函数都是现成的，如果切到Flutter，相当于把老业务重写一遍，而且重写过程中还会引入大量与业务无关的兼容性Bug。纯ArkTS原生就更不用说了。

2.2 最终选型理由：存量业务复用和团队技术栈

最终拍板选React Native，核心原因就两条。

第一个原因是存量业务复用。我们原有的证件核查业务页面、拍照上传逻辑、表单校验、列表筛选这些模块，全部是RN实现的，逻辑代码大部分可以原样搬到鸿蒙工程里。移动端只需要对相机、文件、签名这几个强原生依赖做鸿蒙桥接，其余页面能快速跑通。

第二个原因是团队技术栈。团队里前端工程师比原生工程师多，RN相关的招聘和培训成本明显更低。如果选了纯ArkTS，等于要所有人从头学一门新语言，项目排期根本兜不住。

不能说React Native是“最优解”，但在我们这个项目里，它就是当时约束条件下的“最满意解”。

2.3 选型前必须向老板和团队确认的三件事

选型不能只看技术文档，落地前有几件事要先确认好，不然后面全是坑。

第一，确认目标鸿蒙设备的系统版本是API 10还是API 12，以及是否兼容Android APK。HarmonyOS NEXT这种不兼容APK的设备，要求RN桥接层走完整的react-native-harmony适配，工程量明显更大；如果是兼容Android APK的旧鸿蒙版本，甚至可以直接用原有APK包。

第二，确认react-native-harmony支持的RN版本。这个步骤很关键，react-native-harmony的版本与React Native版本是严格对应的，RN 0.72要配0.72.x的适配库，RN 0.73要配0.73.x，不能混用。我们当时用的是RN 0.72.x，react-native-harmony对应版本为0.72.x，官方文档里也明确给出了映射关系。

第三，确认第三方原生组件的鸿蒙版有没有现成方案。项目里如果用了react-native-camera、react-native-file-viewer这类强依赖原生代码的库，必须逐一排查是否有鸿蒙适配版本；没有的话，就需要自己封装原生Module或者换用WebView方案。我们在做证件拍照时，就发现原用的相机库没有鸿蒙版，最终改用系统相机Intent+文件路径回传的方式绕过去。

3. 鸿蒙化改造工程细节：从RN源码到hap包

3.1 环境与版本对齐：先用一张表钉死版本

鸿蒙化改造的第一步不是写代码，而是把环境版本全部钉死。我们踩过一次版本不匹配的坑，花了两天才查出来是SDK版本和适配库不一致导致的编译失败。建议项目一开始就维护一张版本表，类似下面这样：

版本锁定的过程中，尽量用npm的package-lock.json或yarn.lock把依赖树固定住。鸿蒙适配项目的依赖比普通RN项目更脆弱，稍微升级一个小版本都可能引入新的编译错误。

3.2 接入react-native-harmony的两种方式

react-native-harmony的接入方式有两种：源码集成和SDK集成。

源码集成是把react-native-harmony的源码放进鸿蒙工程的third-party目录，然后在build-profile.json5里配置依赖。优点是便于自定义桥接层，遇到Bug可以直接改源码排查；缺点是升级适配库时要处理冲突。

SDK集成则是在鸿蒙工程里通过ohpm方式引入react-native-harmony的har包，配置相对简单，但遇到问题时能动的空间小。

我这边的建议是：如果是正式商用项目，优先用源码方式，因为RN鸿蒙生态还不算成熟，线上问题往往需要深入到桥接层去定位。源码方式的工程结构大概是这样：

code复制entry/
  src/main/
    ets/
      MainAbility/
      pages/
        Index.ets
        RNApp.ets
    resources/
  oh-package.json5
harmony/
  react-native-harmony/  // 源码方式引入的适配库
build-profile.json5

在鸿蒙原生侧，需要定义一个名为RNAppPage的组件，用来挂载RN实例。核心逻辑是创建ReactNativeHost，指定bundle的加载路径和入口模块名。

3.3 Metro bundle与首屏白屏的完整排查链路

项目里最容易翻车的就是启动白屏。“react native 启动白屏”在搜索里频繁出现，我们项目里也真实遇到过，而且不止一次。白屏的完整排查链路我放在第7章详细展开，这里先记住一个判断：白屏时不要急着改JS代码，先分清是native层没起来，还是JS bundle没加载，还是JS执行报错。三者的排查路径完全不同。

通常做法是在鸿蒙原生工程的日志里搜RN相关关键字，如果能看到“ReactNativeHost started”之类的日志，说明native层已经起来；再看Metro服务或者内置bundle是否加载成功；最后才看JS层有没有抛exception。

3.4 双端联调：JS断点与原生日志配合

鸿蒙环境下调RN有个很实用的做法——真机日志和Metro日志同时开着。RN侧console.log会输出到Metro终端，原生错误会输出到DevEco Studio的HiLog窗口。遇到问题先看Metro终端有没有红色报错，再看HiLog里有没有原生异常，基本能把问题缩小到JS层还是桥接层。

签名功能涉及触摸事件、Canvas、图片导出，这些在模拟器上的表现和真机差异很大，我建议从第一天起就坚持用真机联调，不要依赖模拟器。

4. 签名组件实现：触摸轨迹、Canvas渲染与图片导出

4.1 签名面板方案选型：为什么用RN Canvas而不是原生View

签名面板有几种实现路线：纯RN CameraRoll之类的不相关；通用方案主要是三个。

第一种是原生View方案，在鸿蒙或Android侧写一个原生的签名控件，通过RN桥接暴露给JS层。优点是可以调用系统级的绘图API，性能好，笔迹平滑；缺点是要维护Android和鸿蒙两套原生代码，纯原生代码量约等于每个端各写一个完整的签名组件，联调成本高。

第二种是WebView+Canvas方案，在RN的WebView里加载一个HTML页面，用H5的Canvas来绘图。优点是兼容性好、跨三端一致；缺点是手势事件经过WebView转发会有延迟，在低端设备上笔迹会出现“画完后才追上手指”的滞后感。

第三种就是RN的Canvas相关库，比如@shopify/react-native-skia。但我们排查后发现，这类库在鸿蒙适配上的成熟度还有限，而且为了一个签名功能引入一个庞大的渲染引擎，有点小题大做。

最终我们选了“原生透明View层 + JS层Canvas绘制”的折中方案：触摸事件由RN的View层捕获，但点击区域不渲染背景，然后用RN自带的绘图能力把笔迹画在一个离屏Canvas上。之所以可行，是因为签名笔迹本质上就是一堆折线路径，复杂度远低于图片处理，不需要Skia的完整能力。

这里要补充一个关键点：HarmonyOS ArkTS侧本身提供了Canvas组件，也可以通过原生Module方式暴露给RN。但考虑到我们还有Android端要维护，刻意只封装了一个“无UI的签名数据采集桥接模块”，UI统一用RN层绘制，这样两个端的主逻辑只维护一份。

4.2 触摸事件处理：坐标采集与归一化

签名组件的核心输入是触摸轨迹。React Native的View组件提供onTouchStart、onTouchMove、onTouchEnd事件，事件里带locationX和locationY，这是相对于当前View左上角的坐标。

我遇到的一个坑是：RN在鸿蒙上获取到的locationX/locationY，在某些版本里并不是绝对精确的像素值，而是受屏幕density影响。直接拿它去Canvas绘制时，会发现笔迹在部分平板设备上明显偏移，而且签名区域越大偏移越明显。解决办法是在触摸事件回调里做一层坐标归一化：

javascript复制const normalizePoint = (event, layout) => {
  const { locationX, locationY } = event.nativeEvent;
  const width = layout.width;
  const height = layout.height;
  return {
    x: (locationX / width) * CANVAS_WIDTH,
    y: (locationY / height) * CANVAS_HEIGHT,
  };
};

先把触摸坐标转换成相对比例，再乘上Canvas的逻辑尺寸。由于导出签名图时也按比例缩放，这样无论设备屏幕大小如何变化，签名在图上位置始终一致。归一化还有一个好处：签名图可以固定输出一个标准尺寸，比如1280x640，方便归档端统一处理。

状态管理上，不要在onTouchMove里频繁调用setState，否则会触发频繁的React渲染，笔迹明显卡顿。做法是维护一个ref数组，先实时把触摸点推进数组，同时直接调用Canvas的绘制方法。

4.3 绘制逻辑：贝塞尔插值让笔迹更平滑

笔迹如果只是把触摸点用直线连起来，写出来的字会显得又硬又毛糙。尤其是手写汉字，横竖撇捺转折处特别明显。优化做法是在两个采集点之间做贝塞尔插值。

具体实现思路是：每次onTouchMove拿到新坐标点时，不直接连线，而是以“上一个点的中点”作为贝塞尔起点，再结合当前点计算出中间控制点，画一条平滑曲线。经典的做法是用二次贝塞尔曲线：

javascript复制const drawSmoothLine = (ctx, points) => {
  if (points.length < 2) return;
  ctx.beginPath();
  ctx.moveTo(points[0].x, points[0].y);
  for (let i = 1; i < points.length - 1; i++) {
    const xc = (points[i].x + points[i + 1].x) / 2;
    const yc = (points[i].y + points[i + 1].y) / 2;
    ctx.quadraticCurveTo(points[i].x, points[i].y, xc, yc);
  }
  ctx.lineTo(points[points.length - 1].x, points[points.length - 1].y);
  ctx.stroke();
};

这种方式画出来的曲线更接近人手的自然笔迹。同时还要设置lineCap为round、lineJoin为round，避免笔画端点出现方角。如果需要模拟笔锋效果，可以根据触摸点的移动速度动态调整线宽：速度快线窄，速度慢线宽。这个属于体验优化，内部审批场景不强求，但做了之后明显提升了审批人的签字观感。

4.4 导出策略：透明背景、高清归档与压缩上传

签名图导出要同时满足两个诉求：屏幕显示要快，归档质量要高。

我们用Canvas的toDataURL导出PNG格式的base64，导出时保持透明背景，方便后续把签名盖在审批单的指定位置上。导出尺寸按固定逻辑尺寸1280x640来，不要按屏幕物理像素，因为不同设备density不一样，签名区域布局位置也不同，按固定逻辑尺寸导出才能保证签名图片在不同设备上是同一套标准。

导出的PNG base64体积通常在100KB到300KB之间，对于审批列表这种需要加载多张图片的场景来说偏大。所以我的做法是保存两份：

• 热数据：签名图转成JPEG格式，压缩到80KB以内，用于列表快速展示。
• 归档数据：保留原始高清PNG透明底图，用于正式存档和打印。

转换和压缩可以放在RN层用Canvas重绘实现，不需要额外引库，减少鸿蒙适配负担。

4.5 交互细节：清空、确认、二次弹窗

签名面板的交互细节决定了这个功能好不好用。我们的设计是做两步确认：

第一步，点击“确认签名”后，不直接提交，而是弹出一个预览弹窗，把签名图放大展示在核查结果上，审批人确认位置和笔迹没问题后，再点“确认提交”。

第二步，如果是驳回操作，还需要强制填写驳回原因。这个属于业务规则里比较复杂的地方，下一步细说。

清空按钮要放在一屏之内能点到的地方，同时要防误触，设计成“点击后还要再点一次确认清空”的双击交互。我在实际使用中发现，审批人有时候签完觉得不满意会想清空重签，但如果清空按钮太灵敏，容易误触把刚签好的名字清掉。

另外，签名面板要预留“签名人姓名”“签署时间”的展示区域。虽然这些数据最终会以结构化字段形式存储，但在签名预览里直接展示出来，审批人会更直观地确认自己签的是哪份单子。

5. 审批流与签名数据绑定：一份核查结果对应一次有效审批

5.1 审批状态机与签名时机控制

签名不是任何时候都能签的，它必须受审批状态机约束。我们的状态机设计得很简单，只有四个状态：

• PENDING：待审批，核查结果已生成，等待审批人处理。
• APPROVING：审批中，审批人已打开审批页面，尚未提交结果。
• APPROVED：已通过，签名完成，数据进入归档。
• REJECTED：已驳回，需要填写驳回原因，驳回后不可二次签名。

状态流转规则里有两个关键约束：

• 只有APPROVING状态才允许调起签名面板；PENDING状态时签名按钮置灰。
• 已APPROVED或REJECTED的记录，签名区域锁定，不能再弹出来修改笔迹。

状态机放在后端统一控制，前端展示状态和按钮可用性。因为审批这种操作涉及责任认定，如果状态控制放在前端，很容易被绕过，签名记录的可靠性就打折扣了。

5.2 数据模型设计：签名、核查结果、审批意见如何关联

审批模块的表结构，我建议至少拆成三张表：核查记录表、审批记录表、签名记录表。

核查记录表存证件信息、核查结果JSON、核查时间、核查人ID。审批记录表存审批任务ID、关联的核查记录ID、审批人ID、审批意见、审批状态、流转时间。签名记录表存审批记录ID、签名图片URL、签名坐标位置、签名图片哈希、签名时间、设备信息。

签名记录为什么单独拆表？因为签名图片属于大字段，如果把base64直接塞进审批记录表，列表查询时数据量会变得很大，拖慢页面响应。单独拆表后，列表页只查审批记录，进去看详情时才按需加载签名图片。

后端返回给前端的审批详情JSON大致结构如下：

json复制{
  "approvalId": "AP20240612001",
  "checkRecordId": "CK202406120089",
  "status": "APPROVING",
  "approver": {
    "id": "u_10086",
    "name": "张审批"
  },
  "approvalOpinion": "",
  "verificationResult": {
    "name": "李明",
    "idCardNo": "410***********0012",
    "resultCode": "PASS",
    "riskLevel": "LOW"
  },
  "signature": null
}

审批人提交时，前端把签名图片base64、签名图片哈希、审批意见、签名人ID和时间一起POST到后端，后端校验状态机后再落库。

5.3 接口设计与幂等处理

审批接口要特别注意幂等性。移动端弱网环境下，用户点了提交没反应，往往会再点一次，这时候如果接口没有幂等处理，就会生成两条审批记录，导致同一份核查结果被重复审批。

解决办法有两个层面。前端层面：提交按钮点击后置灰，显示loading，promise resolve前不可重复点击。后端层面：审批记录表加唯一约束，approval_id + approver_id + status做唯一索引，重复提交直接返回已有记录。

签名提交接口也需要做超时重试，因为图片上传可能比较慢。建议拆两个接口：一个先提交审批元数据，返回签名上传的临时凭证；再单独传签名图片。这样即使图片上传失败，也不会把整个审批记录搞成脏数据。

实际联调时，我们遇到过一个场景：平板端签名提交后，网络超时，实际后端已经写入成功，App却提示失败。用户重新提交，由于唯一索引冲突，后端返回“该审批已处理”。前端需要识别这种场景，做一次本地查单，而不是直接报错。这类问题不解决，审批系统很容易被一线人员吐槽“不好用”。

6. 合规与存档：让签名记录可追溯、不可抵赖

6.1 手写签名图与法律意义上电子签名的边界

必须明确一个概念：我们做的这个手写签名功能，本质上属于“审批留痕”，距离法律意义上的“可靠电子签名”还有一段距离。《电子签名法》里说的可靠电子签名，通常需要满足“签字人专有”“仅由签字人控制”“签署后对数据和签名任何改动都能被发现”等条件。

内部审批场景里，手写笔迹图像用于确认审批人身份和审批意愿，配合操作日志和时间戳，基本够用。但如果这个签名要用于正式合同、法律文书、对公业务凭证，就需要接入CA机构颁发的数字证书，或者对接合规的第三方电子签约平台，由平台生成符合法律标准的数字签名。这个边界在项目立项时就要跟业务方讲清楚，避免后续被误解为“有了手写签名就等于有了法律效力”。

6.2 数据保全手段：摘要、时间戳、国密算法

归档数据要做防篡改，最简单可靠的方案就是哈希摘要+时间戳。

每次审批提交时，前端或后端把审批元数据（核查记录ID、审批人ID、审批意见、签名图片base64）做一次哈希。哈希算法如果业务有信创要求的话，优先用国密SM3，我们项目用的就是SM3，因为客户是政务背景，对国密算法有明确要求。

签名图片的防篡改有两种强度。弱一点的方案：只存图片的SM3哈希，归档时重新计算图片哈希比对一下，能发现图片是否被换掉，但发现时间可能是很久之后。强一点的方案：哈希值和审批时间一起提交到权威时间戳服务，生成时间戳证书。有了时间戳证书，可以证明“这个数据在某个时间点就已经是这个形态了”，法律层面的可信度更高。

时间戳服务的对接通常在服务端做，App端不需要自己处理。但要注意，前端提交的哈希值计算方式必须和后端一致，比如统一对base64字符串做SM3还是对解压后的二进制文件做SM3，要提前约定好，否则校验永远对不上。

6.3 归档存储策略：热数据与冷数据分层

审批完成后的数据，按频率可以分为热数据和冷数据。

热数据是最近三个月的审批记录，App里会频繁查询，需要放在性能好的数据库里，比如MySQL或者PostgreSQL，签名图片放在对象存储里，CDN加速访问。

冷数据是超过三个月的历史归档，查询频率很低，但保留周期很长（我们项目要求5年以上）。这类数据可以定期同步到更便宜的存储介质，比如OSS低频访问层、MinIO冷存储，甚至可以做离线备份。归档任务用定时任务每天跑一次，归档完成时把数据库里的记录标记为“已归档”。

移动端查询历史审批时，默认只查热数据，冷数据要用户主动选择“查询历史归档”，再通过异步任务生成下载链接。这样能避免列表初始加载被慢速冷存储拖垮。

归档还有一个细节：签名图片的原始高清PNG必须永久保留，不要只留压缩后的JPEG。压缩图片用来展示可以，但遇到审计或纠纷时，清晰的原始笔迹图才能提供有效依据。

7. 落地踩坑实录：鸿蒙设备上签名功能最容易翻车的五个位置

7.1 白屏问题到底怎么查

我们遇到的白屏原因前后有三种，表现都是“App打开后一片空白”。

第一次是Metro bundle没加载出来。开发阶段，RN默认从Metro服务器拉取bundle，如果DevEco运行鸿蒙工程时Metro服务没有启动，或者手机和电脑不在同一局域网，就会白屏。解决方法是写一个启动脚本，同时拉起Metro和鸿蒙工程，并且把Metro的端口固定下来。

第二次是bundle内置路径错误。发布包不能依赖Metro服务，必须把bundle打包进App。react-native-harmony读取bundle的路径是通过原生工程配置指定的，我们当时把bundle文件放到了assets目录下，但代码里写的是绝对路径，导致找不到文件。调整成正确的相对路径后解决。

第三次是so库缺失。部分鸿蒙真机在动态加载RN引擎时，会提示找不到某个native库，但页面不报红，只是一直白屏。这种情况要看HiLog里的dlopen相关错误，把缺失的so库har包正确引入后就好了。

排查白屏，建议按这个顺序：先看native日志有没有启动成功，再看bundle文件是否存在且能被读取，最后看JS层有没有抛未捕获异常。不要上来就怀疑RN框架本身。

7.2 笔迹坐标偏移：平板、折叠屏、不同density

签名笔迹漂移这个问题花了我两天时间。现象是：在手机上签名很正常，换到鸿蒙平板上，笔迹整体向下偏，而且签名区域高度越大，偏移越明显。

最终定位是坐标归一化没做对。我最初直接使用locationX和locationY，但鸿蒙ArkTS Bridge层返回的坐标在某些设备上不是真实像素，而是vp逻辑像素，绘制时RN Canvas默认用的是普通px，导致坐标被放大了一轮。

修复方法就是前面4.2节写的归一化方案——不直接使用原始坐标，而是先用“触摸点相对签名区域的归一化比例”，再映射到Canvas逻辑坐标。修完之后，在手机、平板、折叠屏三种形态下各测了一轮，笔迹位置都准确了。

另外，折叠屏还有一个坑：签名中途如果发生窗口尺寸变化（比如展开折叠），之前采集的坐标点对应的参考尺寸已经变了，绘制结果会全部错位。解决方案是签名过程中锁定屏幕方向，不允许旋转和尺寸变化。

7.3 图片上传太大导致审批列表卡顿

签名图片如果直接以base64方式上传到后端并塞进审批记录表，列表页会卡到没法用。我们第一个版本就是这样的，签名图一张200KB，审批列表一页20条，光图片数据就是4MB。

优化方案分三步：

• 签名预览和列表缩略图使用JPEG压缩版本，50~80KB以内。
• 归档高清PNG单独存对象存储，列表接口不返回base64，只返回缩略图URL。
• 列表接口默认不查签名表，点进详情页再单独加载签名大图。

优化之后列表页从2秒多降到300毫秒以内，效果非常明显。

7.4 键盘弹起与状态栏导致签名区错位

审批意见输入框弹出软键盘时，如果签名组件使用的是绝对定位布局，键盘会把签名区域顶上去，或者键盘收起后签名区域回不到原位，用户再签名时笔迹位置全乱了。

解决方法是签名过程中禁用软键盘的自动调整，或者把签名面板做成全屏半透明浮层，避免与输入框同时出现在布局流里。我在设计里把签名确认放到独立页面，进入签名页面时自动收起键盘并锁定布局，避免键盘和签名区互相干扰。

7.5 setState导致笔画卡顿：用离屏Canvas和Ref解决

这个坑非常隐蔽。最初实现时，我在onTouchMove里把当前坐标push进数组，再setState更新数组，然后渲染层根据points数组重绘Canvas。结果在鸿蒙低端机上写签名时，笔画一快就断断续续，体验很差。

原因很简单：setState会触发React组件重新渲染，渲染过程中会打断Canvas的绘制，导致点与点之间的路径没有被画上去。

修复方法：触摸点数组完全用ref保存，不参与React渲染；Canvas只初始化一次，绘制逻辑全部走ref持有的canvas上下文，绘制指令是命令式调用，不依赖React组件状态更新。

javascript复制const pointsRef = useRef([]);
const canvasRef = useRef(null);

const handleTouchMove = (e) => {
  const point = normalizePoint(e, layoutRef.current);
  pointsRef.current.push(point);
  drawLine(canvasRef.current, pointsRef.current);
};

这样改完之后，快速连笔也没有卡顿，CPU占用稳定。这也是我给所有RN签名组件的建议：画布这种高频更新场景，能绕开React渲染就绕开React渲染。

项目交付之后我最大的体会是：把一个“签名功能”做成真的能在鸿蒙设备上稳定跑通的电子签名审批模块，难点通常不在签名本身，而在于你有没有把流程、数据、合规和设备适配都当成一个整体来设计。如果我的经验能帮你在选型和排坑时少走一次弯路，那这篇记录就没白写。后面如果你的项目里也遇到签名笔迹漂移或者RN鸿蒙白屏的问题，欢迎按我上面的排查链路走一遍，大概率能少熬几个夜。