做图像编辑界面时，裁剪框看起来只是四根线和八个拖拽点。真正容易出错的时刻却不在拖动，而在折叠屏从展开切到收起：预览面板宽度改变，原来保存的像素坐标如果继续被当成视图坐标，裁剪区域就会偏移。这篇把问题缩小到一个可解释的业务场景：同一张2400×1600的山景照片，在540宽和320宽的预览容器之间切换，仍应指向照片中同一个矩形区域。Demo叫CropFrame，任务编号FOLD-3010；它是一套纯ArkUI布局和坐标计算示例。

一、为什么不能保存一份屏幕矩形

编辑者最初框出的是一段内容，而不是一组固定的屏幕像素。假设展开时，预览宽540、高360，画面中框的左上角是（135，72），大小是270×180。此时把这四个数直接存入业务模型，屏幕收窄后再画回去，框仍然是270×180，右侧会超出较窄的图片区域；如果简单把框宽缩到160而没有同步改变位置，选中的内容也会移动。这不是ArkUI渲染错误，而是状态单位混在了一起。

CropFrame规定业务状态保存归一化比例：x=0.25、y=0.20、w=0.50、h=0.50。四个数字表示原图可见区域的比例，不依赖当前设备窗口。映射到源图后，左上角是（600，320），裁剪宽1200、高800。折叠之后，无论右侧栏变宽还是变窄，仍然使用这四个比例重新计算矩形。读者看到的变化是预览框随容器缩放，而不是素材选区改变。

这里还有一个经常被忽略的限制：本文假定图片以完整3:2比例适配预览框，既不使用cover裁切，也不包含旋转、镜像和自由透视。若实际产品使用ImageFit.Cover，需要先扣除被裁掉的边缘偏移，再进行归一化；直接套本文的屏幕公式会选错地方。把这一点写在界面模型旁边，比等测试才发现更划算。

二、先锁住业务协议，再谈界面尺寸

裁剪动作可能从拖拽手势、历史草稿或云端配置进入。不能因为当前例子的数据合法，就省略区间检查。系统不应接受NaN、Infinity、负宽度、零高度，或者x+w大于1的矩形。对于靠近边界的浮点舍入，可以接受非常小的误差，但不应该把越界数据悄悄修成另一块区域。下面的函数只负责协议校验和源图像素映射，它不读取窗口尺寸，也不关心折叠态。

interface RatioCrop {
  x: number; y: number; w: number; h: number;
}
interface PixelCrop {
  x: number; y: number; width: number; height: number;
}
function sourceCrop(r: RatioCrop, srcW: number, srcH: number): PixelCrop {
  const v: number[] = [r.x, r.y, r.w, r.h, srcW, srcH];
  if (!v.every((n: number) => Number.isFinite(n))) {
    throw new Error('NON_FINITE');
  }
  if (srcW <= 0 || srcH <= 0 || r.x < 0 || r.y < 0 ||
      r.w <= 0 || r.h <= 0 || r.x + r.w > 1.000001 ||
      r.y + r.h > 1.000001) {
    throw new Error('CROP_OUT_OF_RANGE');
  }
  const x0 = Math.round(r.x * srcW);
  const y0 = Math.round(r.y * srcH);
  const x1 = Math.min(srcW, Math.round((r.x + r.w) * srcW));
  const y1 = Math.min(srcH, Math.round((r.y + r.h) * srcH));
  return { x: x0, y: y0, width: x1 - x0, height: y1 - y0 };
}

这段实现特意对左右边界分别四舍五入，再用两端相减得到宽度；它避免先舍入起点、再舍入宽度造成的一像素差。更严格的图像产品还要约束最小选区尺寸，并检查返回宽高是否为正。这里的源图宽高是业务输入，不能把压缩后的缩略图尺寸误当作原始解码数据的尺寸。

一个很实际的工程分层是：RatioCrop归模型持有，PixelCrop仅在发起保存、裁剪导出时临时生成。UI状态刷新不应该触发写盘，更不应该在onAreaChange里修改模型的比例。如果用户在窗口变化过程中拖动边框，可以把手势坐标先转换到归一化空间，形成一个新的模型版本；这样即使下一帧布局变了，旧手势也不会覆盖选中的源图区域。

三、ArkUI界面只消费当前容器宽度

对于这个示例，不需要猜测设备的折叠角度，也不必从全局屏幕宽度判断有几栏。更稳妥的做法是直接监听承载预览图的容器尺寸。在真实多栏界面中，侧栏宽度、分屏模式、字体缩放甚至系统窗口调整都可能影响可用空间；用onAreaChange测得的宽度比硬编码某一款设备断点更贴近实际内容。

@Entry
@Component
struct CropFramePage {
  @State paneWidth: number = 540;
  private crop: RatioCrop = { x: 0.25, y: 0.20, w: 0.50, h: 0.50 };

  build() {
    Column({ space: 12 }) {
      Text('CropFrame · FOLD-3010').fontSize(20).fontWeight(FontWeight.Bold)
      Stack({ alignContent: Alignment.TopStart }) {
        Image($r('app.media.mountain'))
          .width(this.paneWidth).height(this.paneWidth * 2 / 3)
          .objectFit(ImageFit.Fill)
        Rect()
          .width(this.paneWidth * this.crop.w)
          .height(this.paneWidth * 2 / 3 * this.crop.h)
          .fill(Color.Transparent)
          .stroke('#35D8B3').strokeWidth(3)
          .position({ x: this.paneWidth * this.crop.x,
            y: this.paneWidth * 2 / 3 * this.crop.y })
      }
      .width(this.paneWidth).height(this.paneWidth * 2 / 3)
      Text(`比例：25% / 20% / 50% / 50%`)
      Text(`原图：2400×1600 ｜ 选区：600,320,1200,800`)
    }
    .width('100%')
    .onAreaChange((_old: Area, now: Area) => {
      const w: number = Number(now.width);
      if (Number.isFinite(w) && w >= 240 && w <= 660 &&
          Math.abs(w - this.paneWidth) > 0.5) {
        this.paneWidth = w;
      }
    })
  }
}

资源app.media.mountain是Demo需要自行添加的示例照片，并不是SDK内置资源。onAreaChange读到的是当前组件布局区域，返回的宽度可能是字符串，所以代码先转换为数字并过滤不可用值。为了突出坐标关系，这里把预览容器和Column设成同宽；在实际项目中应给预览加最大宽度和父容器留白，并避开由测量自身引起的反复重布局。使用Rect描边不等于图片本身已经被裁剪，真正导出时仍要将业务选区交给图像处理链路。

界面层还有一个值得写清楚的取舍：当前示例的状态只有paneWidth，裁剪比例不是响应式编辑状态。如果添加八个拖拽点，需要把比例改成@State或者独立的可观察业务模型，避免改动普通字段却无法触发更新。默认Frame值只用于首屏排版，首轮实际测量到达后再由容器修正；不要把这一瞬间误判为用户手动改变了裁剪范围。

四、把“重投影”写成一条可重复的计算路径

光看屏幕变化，很难确定到底有没有偏移。最省事的验收方式是把源选区和预览选区分开打印。前者无论何时都必须等于600、320、1200、800；后者随着预览宽度改变而变化。将预览矩形计算独立成一个纯函数，截图标注和自动测试都可以调用同一套公式。

interface PreviewBox { left: number; top: number; width: number; height: number; }
function previewCrop(r: RatioCrop, paneW: number): PreviewBox {
  const paneH: number = paneW * 2 / 3;
  return {
    left: paneW * r.x,
    top: paneH * r.y,
    width: paneW * r.w,
    height: paneH * r.h
  };
}
const selection: RatioCrop = { x: 0.25, y: 0.20, w: 0.50, h: 0.50 };
const wide: PreviewBox = previewCrop(selection, 540);
const narrow: PreviewBox = previewCrop(selection, 320);
console.info(`FOLD-3010 WIDE ${wide.left},${wide.top} ${wide.width}x${wide.height}`);
console.info(`FOLD-3010 NARROW ${narrow.left},${narrow.top.toFixed(2)} ${narrow.width}x${narrow.height.toFixed(2)}`);

按照这组确定性输入，WIDE是135,72 270x180，NARROW约为80,42.67 160x106.67；这就是开发环境示例图底部HiLog应看到的数值。对比的重点不是框的尺寸相同，而是框相对原图的覆盖比例不变。若输出图片来自压缩缓存，应该另行区分缓存宽高与源图宽高，以免渲染正常但实际裁剪错位。

五、状态变化时会出现的三种边界

第一种是事件密集。拖动窗口分隔线时，onAreaChange可能短时间触发很多次。业务层不能每次都去解码整张照片。本文的组件变化只更新几何尺寸，图像资源复用同一张预览；若以后要请求更清晰的缩略图，应在稳定尺寸后重新评估目标采样率，并给旧异步结果增加版本校验。这样可以把UI重布局的频率与耗时解码的频率彻底分开。

第二种是异常源图。假设导入图片记录写着2400×1600，但实际读取失败，或者记录为0×1600，sourceCrop会拒绝继续计算。这时应该在界面显示“源图尺寸不可用”，保留上一次合法裁剪比例，不要拿零宽度计算出Infinity，也不要在异常分支直接清空用户选区。错误码要带上FOLD-3010和资源ID，后面排查才能分清数据坏了还是窗口切换造成的。

第三种是页面生命周期。onAreaChange跟随组件布局，不需要主动注册一个常驻全局窗口监听。示例也没有定时器或后台任务，因此离开页面时无需编造一个释放流程。真实工程若注册额外窗口事件、图像解码订阅或拖拽节流任务，必须在页面离开时成对注销并取消未完成任务；比例值可以保存在草稿仓库，但不能让旧页面实例继续写入当前页面的状态。

七、最后要验证的不是动画，而是内容

可以设计三组验收：540→320→540连续往返，比较PixelCrop四个整数是否保持原值；把比例放到靠右下角的位置，验证舍入后终点不越过源图范围；再输入负数、NaN、零尺寸，确认错误码清晰且未覆盖用户草稿。若要扩展到ImageFit.Cover、旋转、镜像以及两指缩放，需要引入仿射变换矩阵和逆矩阵，把预览坐标映射回源图，此时本文的简化投影不够用。

这套Demo的工程价值不在于绘制了一个漂亮的绿色框，而在于把“用户选了图片的哪一部分”与“当前设备把图片画成多大”分成了两份独立状态。折叠屏只是触发问题的一个窗口形态。平板分屏、桌面缩放乃至横竖屏切换都可以沿用相同判断：保存归一化或源图语义，显示时再计算屏幕矩形。对图像工具来说，这比追着每一款设备写一组坐标补丁可靠得多。

参考资料：华为开发者文档中心（ArkUI/组件通用属性及onAreaChange相关指南）https://developer.huawei.com/consumer/cn/doc/ 。