WebView中H5元素尺寸与原生视图坐标不一致的排查

背景与起因

需求：在 H5 中获取某个元素的宽高和位置，通过 JS Bridge 传给 ArkTS 端，希望能够在对应位置覆盖一个原生 View（或者叠加一个WebView等）。
现象：H5 拿到的尺寸/位置（CSS像素）和设备分辨率（物理像素）比例不一致，存在一定的比例缩放。
设备：分辨率 1260×2844；H5 里 window.screen 得到 374×843。
比例：1260/374≈3.369，不是 1。

这时让我不由的想起若干年前的Android问题：Android 4.4 之前 WebView 里有个 getScale 能直接用，但是当时经常遇到scale还会动态变化，比如WebView初始化时是一个值，DOM渲染完成后又变了；但4.4系统之后就恒为1，再也不是个问题了。然而现在到了鸿蒙ArkWeb，这个比例的问题又来了，让我第一反应是深深地“恐惧”。

分析思路

这个问题起初因为未找到原因，搁置了好多天，所以最终这个问题拖得时间比较长。总结了一下大概是这样的历程：

初始（发帖时）：H5 拿到的 CSS 尺寸与设备物理分辨率比例不为 1，怀疑两边坐标系不一致；尝试从 WebView scale、viewport 配置切入，未得到确定结论。
中期：用 devicePixelRatio 把 CSS 尺寸换算到物理像素，基本能对上；但仍缺少与原生单位 vp 的映射依据。
最终（2025-08-11）：验证 window.devicePixelRatio 与 ArkUI 的 display.getDefaultDisplaySync().density 一致，据此确定：在ArkWeb内，可以把 H5 的 CSS px 当作 ArkUI 的 vp 直接使用在原生覆盖层。

注：暂未找到官方对“DPR 与 density 等价”的明确说明，但实践中两者相等。

视口（viewport）配置问题

论坛中的朋友还提出，应当避免使用已废弃的 target-densitydpi。推荐标准写法：

1	<meta name="viewport" content="width=device-width, initial-scale=1.0">

这能让 CSS 像素与 DPR 模型按浏览器内核的默认策略工作，避免额外缩放带来的偏差。

不过实际运行中发现，这个已过时的用法代码的存在并不会影响具体的逻辑。

考虑过的方案

H5 侧：拿到元素的“物理像素”矩形

<script>
function getElementPhysicalRect(el) {
  const dpr = window.devicePixelRatio; // 设备像素比
  const rect = el.getBoundingClientRect(); // CSS px
  return {
    x: Math.round(rect.left * dpr),
    y: Math.round(rect.top * dpr),
    width: Math.round(rect.width * dpr),
    height: Math.round(rect.height * dpr),
    dpr
  };
}

// 通过JSBridge发送给ArkTS：
</script>

要点：

getBoundingClientRect() 返回的是相对于视口的 CSS px，需乘以 DPR 才是物理 px；
如页面存在缩放/滚动，rect 已考虑滚动偏移；如原生覆盖层相对 ArkWeb 容器定位，还需保证容器自身偏移一致。

存在问题：

JSBridge框架的API早已定义，传参写法也已经固化在各个项目代码中，改变这些元素的倍率计算方式无疑工作量巨大，对于大部分价值不大的老旧项目来说性价比不高。

改进方向：

将获取到的devicePixelRatio值，在每个页面初始化完成后，自动通过JSBridge传递给ArkTS端，作为页面范围内的变量使用。这个方法可行，但是仍然需要ArkTS端进行转换。

转移到ArkTS侧：获取密度进行比较，发现devicePixelRatio和density相等

import { display } from '@kit.ArkUI';

// 获取屏幕密度（同步接口）
const metrics = display.getDefaultDisplaySync();
const density = metrics.density; // 如 2.0 / 3.0 / 3.375 等

论坛中提供的其他可选方案

同层渲染原生组件：从根上减少对齐难度，适合新项目或可改造页面；受限于历史 H5 兼容，暂不采用。