合并受阻
【AI-Review】【严重】【基础代码问题】【代码逻辑错误】getMinZoomLevel 重复调用
● 问题：Future.wait 列表中 getMinZoomLevel 被连续调用了两次（第487行和第493行），参数完全相同，第二次调用是冗余的。虽然这是 PR 重构前就存在的问题，但本次 PR 对该代码块做了格式调整，应当一并修复。
● 影响：严重。导致对原生层发起一次不必要的平台通道调用，在慢速平台上增加额外延迟；同时 minAvailableZoom 被赋值两次，虽然值相同不会产生功能错误，但属于逻辑冗余。
● 建议：删除第493-498行的重复调用：
// 删除以下重复调用
wrapControllerMethod(
'getMinZoomLevel',
() => newController.getMinZoomLevel(),
camera: camera,
fallback: minAvailableZoom,
).then((value) => minAvailableZoom = value!),
【AI-Review】【一般】【基础代码问题】【性能和效率问题】BackdropFilter 在慢速平台上的 GPU 开销
● 问题：buildRecordStartBlur() 使用 BackdropFilter + ImageFilter.blur(sigmaX: 16*t, sigmaY: 16*t) 对整个相机预览区域进行实时高斯模糊。BackdropFilter 是 Flutter 中 GPU 开销最高的 widget 之一，每一帧都需要对底层内容重新采样和模糊。本 PR 目标平台正是"慢速平台"（鸿蒙端约166ms管线重配延迟），在此类设备上 BackdropFilter 可能导致帧率下降，与"掩盖卡顿"的初衷相悖。
● 影响：一般。在已慢的设备上引入额外 GPU 负担，可能导致模糊过渡期间出现新的卡顿，削弱本功能的视觉效果。
● 建议：考虑替代方案以降低 GPU 开销：
- 使用
AnimatedOpacity叠加半透明遮罩替代模糊（几乎零 GPU 开销，视觉上接近"对焦过渡"效果） - 如果确实需要模糊效果，可在
isRecordStarting变为 true 时用RenderRepaintBoundary+toImage()捕获一帧快照，对该静态图像应用一次模糊，然后用AnimatedOpacity淡入淡出，避免每帧实时模糊 - 至少应添加平台判断，仅在
Platform.isOhos等已知慢速平台上启用模糊过渡，在 iOS/Android 上使用更轻量的方案
【AI-Review】【一般】【基础代码问题】【常量问题】模糊过渡参数硬编码为魔法数字
● 问题：buildRecordStartBlur() 中的关键参数均为硬编码的魔法数字：动画时长 140ms、最大 sigma 16、遮罩透明度 0.06、阈值 0.01。这些值缺乏命名和注释说明选取依据，且不同平台的管线重配延迟差异较大（鸿蒙端约166ms，其他平台可能仅数ms），固定参数无法适应各平台。
● 影响：一般。未来需要调参或针对不同平台适配时，需在代码中搜索数字定位，增加维护成本；且无法通过配置覆盖。
● 建议：将魔法数字提取为命名常量或配置项，并补充选取依据的注释：
// 录制启动模糊过渡参数
static const double _recordBlurMaxSigma = 16; // 最大高斯模糊半径
static const double _recordBlurOverlayOpacity = 0.06; // 叠加暗色遮罩最大透明度
static const Duration _recordBlurDuration = Duration(milliseconds: 140); // 模糊过渡动画时长
static const double _recordBlurVisibilityThreshold = 0.01; // 低于此值不渲染模糊
feat: mask camera-pipeline reconfigure latency on slow platforms (HarmonyOS)