企业官网建设流程全解析

NestedScrollView 嵌套 WebView，听起来像是能在一杯咖啡时间内搞定的小需求，实际写过的人都知道，这个组合可以让一个还算有耐心的开发者一整天都不想说话。一个页面滚动到一半开始出现大段空白、底部内容死活滚不出来、WebView 内部滚动冲突导致外层滑动“粘手”——这些问题放在一起，几乎成了 Android 滑动布局里最出名的“玄学现场”之一。

我自己在做某跨平台系统时，就曾在一个混合页面里必须同时承载图文详情、业务列表和 H5 活动页，第一版直接放到 NestedScrollView 里，结果真机上一测：华为、小米、三星各表现出不同的空白形态，有的内容只剩一屏，有的滚动到 WebView 底部后还能继续拖出半屏白纸。那段时间我基本上把 WebView 的测量、刷新、嵌套滚动机制翻了个底朝天，最后沉淀下来一套相对稳定的组合方案。

这篇博文就把这套组合方案完整拆开讲：先解释问题为什么会发生，再盘点哪些常见做法其实治标不治本，最后给出我实际工程里一直沿用的“测量 + 自定义 onMeasure + 多次校准”完整方案。适合正在被这类兼容问题折磨的 Android 开发，也适合刚接手混合页面、不想把项目写成补丁套补丁的新手参考。

1. 这个问题到底难在哪：WebView 根本不参与嵌套滚动体系

1.1 NestedScrollView 的设计目标和 WebView 的“不合作”

NestedScrollView 本身是 Android 支持库为了实现“嵌套滑动”而生的滚动容器，它能让子 View 和父 View 在同一个手势里互相协作，把一段距离的滚动得比较“顺滑”。但这套协作机制有一个前提：参与滚动的子 View 需要实现 NestedScrollingChild 接口，或者父容器能够通过监听事件来主动接管滚动。

WebView 从诞生起就是独立控件的思路，它内部维护着一套完整的渲染引擎和输入事件体系，所有触摸、滚动都在自己的内部逻辑里消化掉了。它并不主动接入外部的嵌套滚动协议，也不会把“我这边已经滚到头了，剩下的距离交给父容器”这件事主动上报给 NestedScrollView。

结果就是，你把 WebView 丢进 NestedScrollView 之后，两个滚动系统之间没有协商通道。手势落到 WebView 上时，WebView 自己响应，NestedScrollView 只能干瞪眼；而 WebView 又不像普通 ListView 那样会被父容器在事件分发层面轻松拦截，因为它在消费触摸事件后，往往已经调用了内部的 onTouchEvent 把事件“吞”得干干净净。

这也就是很多开发者发现，在 NestedScrollView 里放一个 WebView，滚动时总有一种说不出的“分裂感”：在 WebView 区域滑动，是 WebView 自己的滚动条在走；滑过 WebView 区域到了外面的布局，才是 NestedScrollView 在动。体验割裂不说，还容易出现手势已经交给 WebView、但 WebView 内部内容又不够一屏时，外层再也接不到剩余滑动事件的尴尬局面。

1.2 高度测量时机不对，才是空白问题的根源

除了事件协作，更麻烦的是 WebView 的高度测量机制。当 WebView 的布局参数设置为 wrap_content 时，外层 NestedScrollView 会向 WebView 询问“你到底有多高”。WebView 在 onMeasure 阶段通常是按当前 WebView 内部文档的可视宽度来布局的，如果这个阶段 WebView 还没完成真正的网页加载，它根本没有一个可靠的“文档真实总高度”可以返回。

于是 WebView 就退化成了“按当前视口高度来报数”，也就是把自身高度当成一个屏幕大小。NestedScrollView 根据这个高度来计算总滚动范围，滚动距离自然不够，WebView 底部的真正内容就被裁掉了。用户看到的现象就是，整个页面只能滚到一半，再往下就是空的或者滚不动了。

反过来还有一种情况，JS 注入测量时获取到了 document 的 scrollHeight，但这个值比实际渲染高度偏大，或者页面里的图片在测量之后才加载完成、进一步撑高了文档，而 WebView 的高度还停留在旧值。这种不一致就会在 WebView 底部留下一段空白区，滚动时能看到一段白得发亮的区域，俗称“大段空白”。

真实项目中，这两种问题往往同时出现：加载时机不一致时是空白，内容高度回填后是高度坍缩或者过度膨胀。如果不理解这背后的测量机制，而是单纯去改布局里的 height 数值，那基本就是按下葫芦浮起瓢。

1.3 为什么“禁用 WebView 滚动”也不能解决问题的根子

不少文章会提到“把 WebView 的滚动关掉，让外层 NestedScrollView 全权负责滚动”。思路听起来很顺，操作上一般也就是设置 setVerticalScrollBarEnabled(false)、setOverScrollMode(OVER_SCROLL_NEVER)、setHorizontalScrollBarEnabled(false) 这些。

但真正实现时你会发现，这几个设置只是隐藏了滚动条、关了边缘发光效果，WebView 内部的触摸滚动逻辑根本不会被关闭。用户的手指在 WebView 上拖动时，WebView 依然会自己滚。想让 WebView 完全不响应滚动，只能通过重写 onTouchEvent 并主动消费事件，或者在 JS 层面把页面写得不再产生可滚动区域。

这其实和“让 WebView 不自己滚”是两码事。我们在 NestedScrollView 里要的并不是“禁掉 WebView 的滚动能力”，而是“让 WebView 的内部内容完全撑开，把高度真实地报给父容器，使得 WebView 本身已经没有可滚动空间”。这样一来，手势无论交给谁，最终滚动范围都是同一个总高度，事件冲突也就不存在了。

2. 常见方案盘点：哪些是救急，哪些是伪解

2.1 纯 JS 量高度后 setLayoutParams

这是网上出现频率最高的一类方案，核心逻辑很直白：在页面加载完成后，通过 WebView 的 evaluateJavascript 执行一段 JS 代码，取 document 的高度，然后回传到 Java 层，再把这个高度设置给 WebView。

webView.setWebViewClient(new WebViewClient() { @Override public void onPageFinished(WebView view, String url) { super.onPageFinished(view, url); view.evaluateJavascript( "(function(){" + "var h=Math.max(document.documentElement.scrollHeight, document.body.scrollHeight);" + "return h;})()", value -> { try { int height = Integer.parseInt(value.replace("\"", "")); ViewGroup.LayoutParams lp = view.getLayoutParams(); lp.height = height; view.setLayoutParams(lp); } catch (Exception ignored) { } }); } });

这个方案的优点是实现简单，页面大部分情况下能正常显示；但缺点也很明显，就是“不稳定”。onPageFinished 并不是网页里所有内容都渲染完成的时刻，图片、异步脚本、懒加载组件都可能在 onPageFinished 之后继续改变文档高度。如果只测一次就锁定高度，后续图片加载完成，WebView 的高度反而不够，内容被压缩或者底部被裁切。用户滑动时还会发现 WebView 区域下方突然出现一片空白，因为外层 NestedScrollView 已经按照之前算好的高度展开了滚动距离。

2.2 把 WebView 高度设为固定值或 match_parent

有些人图省事，直接把 WebView 的高度写成一个固定数值，比如 1000dp，或者直接 match_parent。固定数值的问题是不同机型、不同字体缩放、不同分辨率下，内容多高完全不可控，写死就等于埋雷。

match_parent 看起来可以占满剩余空间，但放在 NestedScrollView 里就是一个灾难：NestedScrollView 对直接子 View 使用 wrap_content 测量时，match_parent 的孩子高度会被错误地处理成未指定高度，最终 WebView 跟着父容器的高度走，而父容器高度又是可变的，滚动总高度还是算不对，照样出现滚动不到底部的问题。

2.3 重写 WebView 的 onMeasure 但只做一半

有些开发者会尝试重写 onMeasure，把 WebView 的测量模式强制改成 AT_MOST 并传入一个很大的值，让 WebView 尽量测量出内容高度。这个方向是对的，但很多人只做了第一步，没有处理后续的“测量刷新”“多轮加载”“图片撑高”问题，结果在低版本机型上测出来了，在高端机型或长页面场景下又崩了。

另一个常见问题是没有判断 LayoutParams 的高度模式，直接在 onMeasure 里对所有场景一刀切。如果只是临时做实验还好，放到正式项目里，ImageView 等模块也会受到影响，最终表现就是页面上时不时出现莫名其妙的间距。

2.4 干脆用 LinearLayout 替代 NestedScrollView

有段时间我也想“绕开”这个问题，直接把外层容器从 NestedScrollView 换成普通 LinearLayout。只用 LinearLayout + ScrollView 确实可以避免嵌套滚动协议问题，但代价也很大：内容区域不能复用，点击事件、滚动事件的分发变回老一套逻辑，遇到键盘、焦点、复杂交互时更难处理。而且 ScrollView 本来就不支持嵌套滚动，后续接入 CoordinatorLayout、下拉刷新这类依赖 NestedScrollView 的组件时，又得推翻重来。

2.5 现有方案对比总览

3. 正解一：自定义 WebView，重写 onMeasure 支持真实内容高度

3.1 onMeasure 里的关键代码

既然 WebView 默认测量无法在 wrap_content 情况下给出真实高度，那就从测量入口下手。自定义一个 WebView，当布局参数为 wrap_content 时，把父容器传入的高度测量模式改成一个足够大的 AT_MOST 值，让 WebView 内部按内容实际尺寸来测量。

public class ResizableWebView extends WebView { public ResizableWebView(Context context, AttributeSet attrs) { super(context, attrs); setVerticalScrollBarEnabled(false); setHorizontalScrollBarEnabled(false); setOverScrollMode(OVER_SCROLL_NEVER); } @Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { ViewGroup.LayoutParams lp = getLayoutParams(); if (lp != null && lp.height == ViewGroup.LayoutParams.WRAP_CONTENT) { // 把高度测量模式替换成足够大的 AT_MOST，让 WebView 真正测量内容高度 int bigHeightSpec = MeasureSpec.makeMeasureSpec( Integer.MAX_VALUE >> 2, MeasureSpec.AT_MOST); super.onMeasure(widthMeasureSpec, bigHeightSpec); return; } super.onMeasure(widthMeasureSpec, heightMeasureSpec); } }

这里 Integer.MAX_VALUE >> 2 是一个经验值，目的不是真的要给 WebView 一个无限高度，而是告诉它“你在测量的时候不要被当前视口高度限制住，尽量按内部网页文档去计算高度”。WebView 内核会在这个约束下结合自身渲染结果，给出一个接近真实内容高度的测量值。

3.2 为什么这个方案经常不够用

只做这一步，很多场景下还是会出现高度偏差，原因有两点。

第一，onMeasure 触发时，WebView 内部的网页可能还没加载完。onMeasure 是 View 布局流程的一部分，加载完页面之后如果内容高度变化了，必须主动触发 requestLayout，否则 WebView 不会重新走上 onMeasure 流程。

第二，不同 Android 系统版本上，WebView 内核对于“内容高度”的理解并不完全一致。有些版本会按当前已渲染区域返回，有些版本会考虑整个文档高度，还有些版本会受到 CSS 中 body 高度、margin、viewport 属性的影响。所以不能完全依赖单次 onMeasure 的结果，需要和 JS 测量校准配合起来。

3.3 配套的 requestLayout 策略

在页面加载和图片加载完成之后，主动调用 requestLayout，让 WebView 重新进入测量流程。这时候 onMeasure 已经能拿到新的内部布局结果，高度也会跟着更新。

webView.setWebViewClient(new WebViewClient() { @Override public void onPageFinished(WebView view, String url) { super.onPageFinished(view, url); // 页面框架加载完并不代表高度最终确定，先请求一次布局 view.post(() -> view.requestLayout()); // 延迟再校准，给图片和异步脚本一些缓冲时间 view.postDelayed(() -> view.requestLayout(), 200); } });

很多只写了 onPageFinished 却没有补 requestLayout 的项目，问题就出在这：测量逻辑改了，但 WebView 根本没在正确的时机重新测量，一切等于白做。

4. 正解二：JS 测量 + 多轮校准，锁死最终高度

4.1 该量哪个高度：scrollHeight 还是 offsetHeight

JS 测量是绕不开的手段，因为 WebView 的 onMeasure 在一些复杂网页下依然不可靠，真正权威的内容高度还是得从 DOM 层面获取。很多教程只取 document.documentElement.scrollHeight，但页面存在 margin、body 高度、子元素溢出等情况时，单取一个值容易偏低或者偏高。

我实际采用的测量代码，会同时考虑 documentElement 和 body 的 scrollHeight、offsetHeight，并取最大值：

private static final String JS_MEASURE_HEIGHT = "(function(){" + "var d=document; " + "var h=Math.max(" + "d.documentElement.scrollHeight, " + "d.documentElement.offsetHeight, " + "d.body.scrollHeight, " + "d.body.offsetHeight);" + "return h;" + "})()";

这里取最大值是保守做法。绝大多数页面的 body 和 documentElement 高度是等价的，但遇到某些使用了绝对定位容器、浮动布局、底部工具条固定定位的页面，两个值会出现差异。取最大值可以避免内容被错误地裁掉，最坏情况也只是底部多出一点点空白，后续可以在 WebView 的父容器里做裁剪或圆角处理。

4.2 测量的时机不能只信 onPageFinished

onPageFinished 代表的是主资源加载完成，不代表所有子资源加载完成。图片是高度变化最大的因素，很多时候一张 1000px 高的图片没加载出来，页面高度就是 500px，加载完成以后文档直接翻倍。

我在工程里做的处理是：onPageFinished 后先测一次，然后用 100ms、250ms、500ms 的延时各再测一次，如果后一次结果和前一次结果相同，就认为页面高度稳定了，停止测量。如果几次结果都在变化，就继续多测几轮，直到连续两次相同或到达总超时时间。

这样做并不优雅，但确实是生产环境里最稳的做法。毕竟你无法控制第三方网页内部的图片加载逻辑，也不可能要求所有 H5 团队配合你改页面，App 端能做的是把测量做重、做密。

private void measureAndSetHeight(final WebView view) { view.evaluateJavascript(JS_MEASURE_HEIGHT, value -> { try { String cleanValue = value.replace("\"", ""); int newHeight = Integer.parseInt(cleanValue); ViewGroup.LayoutParams lp = view.getLayoutParams(); if (lp.height != newHeight) { lp.height = newHeight; view.setLayoutParams(lp); } } catch (Exception ignored) { } }); }

4.3 适配图片加载导致的二次高度变化

如果页面里有大量图片，可以在网页加载时注入一段 JS，给 document 里的所有 img 元素挂上 onload 事件。这个方式对嵌入的 H5 页面效果很好，但它要求你对加载前时机有足够把握，注入晚了图片已经加载完，事件就绑不上了。

更稳妥的做法是，在 img onload 之后回调 Java 层，再触发一次 WebView 的重新测量。我会在注入代码里加一个简单的校验，确保只绑定一次：

(function() { if (window.__resizeReady) { return; } window.__resizeReady = true; var imgs = document.images; var pending = imgs.length; function check() { if (pending <= 0) { if (window.AndroidBridge) { window.AndroidBridge.onContentResized(0); } return; } pending--; } for (var i = 0; i < imgs.length; i++) { if (imgs[i].complete) { pending--; } else { imgs[i].onload = check; imgs[i].onerror = check; } } })();

到了 Java 层，AndroidBridge.onContentResized 里只需要做一件事：再次触发 measureAndSetHeight，并配合 requestLayout 刷新布局。这里不传实际高度值，因为 Java 层重新测量本身就会覆盖旧高度。整套逻辑的核心思想是：你不必精确知道图片何时加载完，只要在事件链上不断触发校准，让最后一次校准落在高度稳定之后即可。

4.4 测量结果反而变大的“白底”问题

如果页面内容实际高度不到一个屏幕，取 scrollHeight 没问题；但有些页面在 CSS 里把 body 或者 html 的 min-height 设成了 100vh，导致 scrollHeight 恒等于屏幕高度，取最大值之后 WebView 高度就变成了至少一屏高。父容器按这个高度展开，用户看到的当然就是一块白底。

遇到这种情况，可以将测量代码改成取 Math.max(scrollHeight, offsetHeight) 中的最大值，但继续和当前 WebView 的可视高度做一次判断：如果连续测量结果都是相同的屏幕高度，且没有更多真实内容，就按这个高度锁定即可。不要试图去减少它，因为页面本身设置了 min-height，从业务角度它是合理的。

5. 滚动协作：让 WebView 从“自己滚”变成“一起滚”

5.1 处理嵌套滚动事件冲突

当 WebView 高度被校准为真实内容高度后，WebView 内部没有可滚动的空间，用户触摸 WebView 区域时，事件会自然地冒泡到外层 NestedScrollView。但这不是必然的，因为 WebView 即便没有可滚动内容，也会在某些系统版本上响应 ACTION_MOVE，导致外层滑动只动一点点就被“截胡”。

最直接的做法是重写 ResizableWebView 的 onTouchEvent，在手指按下时通过 getParent().requestDisallowInterceptTouchEvent(false) 把拦截权还给父容器。这等于告诉系统：我这边不需要独占滚动，请父容器统一处理。

@Override public boolean onTouchEvent(MotionEvent event) { ViewParent parent = getParent(); if (parent != null) { parent.requestDisallowInterceptTouchEvent(false); } return super.onTouchEvent(event); }

这行代码的作用非常微妙，它让 WebView 不会在事件分发阶段把 move 事件锁死在自己内部，上层 NestedScrollView 才有机会在同一根手指的拖拽中持续滚动。

5.2 目标不是“禁用滚动”而是“自身无滚动”

经过高度校准之后，WebView 的 getContentHeight 应该和 WebView 的实际 view 高度基本一致，所以内部滚动条自然失去滚动空间。此时即使用户在 WebView 上快速滑动，WebView 内核也会因为无可滚动范围而把事件让渡给父容器。这比强制接管 onTouchEvent 更优雅，因为它没有破坏 WebView 内部的点击、长按、手势识别逻辑。

所以在布局参数为 wrap_content 时，不要再额外重写 onTouchEvent 去做“禁止滚动”这种激进操作。只要高度测量足够准确，滚动冲突自然就消失了。如果高度测量不准，外部再用多少层拦截逻辑都会漏。

5.3 外层 NestedScrollView 的性能参数

当 WebView 内容特别长时，NestedScrollView 会把整棵视图树一次性测量并绘制，长页面容易出现掉帧。可以考虑给 NestedScrollView 设置 android:clipToPadding="false" 减少绘制裁剪计算，同时在 Java 层设置过度绘制优化选项。对于大多数资讯详情页，这个优化就够用了。

如果页面长度达到几万像素，WebView 本身会成为性能瓶颈。遇到这种极端场景，我一般会在业务层做限制：WebView 最大只展示比如 10000px，超出部分显示一个“点击查看完整版”按钮，再跳到原生全屏 WebView 页面。这个策略不是技术逃避，而是对真实用户体验负责——没有人会在一个嵌套滚动页里连续滑动几万像素看完一篇文章。

6. 工程落地实战：完整接入步骤与代码骨架

6.1 布局 XML 示例

整个方案的最终布局并不复杂，外层是 NestedScrollView，内部一个垂直 LinearLayout，WebView 放在页面内容需要内嵌的位置。

<androidx.core.widget.NestedScrollView android:id="@+id/nestedScrollView" android:layout_width="match_parent" android:layout_height="match_parent" android:fillViewport="true"> <LinearLayout android:layout_width="match_parent" android:layout_height="wrap_content" android:orientation="vertical"> <TextView android:layout_width="match_parent" android:layout_height="wrap_content" android:text="页面标题"/> <com.example.widget.ResizableWebView android:id="@+id/webView" android:layout_width="match_parent" android:layout_height="wrap_content"/> <TextView android:layout_width="match_parent" android:layout_height="wrap_content" android:text="底部业务区域"/> </LinearLayout> </androidx.core.widget.NestedScrollView>

这里有一点很重要：WebView 的 layout_height 必须设置为 wrap_content，如果写成 match_parent，ResizableWebView 里对 LayoutParams.height 的判断就走不到 wrap_content 分支，整个方案失去意义。

6.2 Activity 或 Fragment 里的初始化逻辑

初始化分为三步：第一步，设置 WebSettings；第二步，挂载 WebViewClient 和网页加载监听；第三步，在 WebView 加载前后分别处理高度校准。

private void setupWebView() { WebSettings settings = webView.getSettings(); settings.setJavaScriptEnabled(true); settings.setLoadWithOverviewMode(true); settings.setUseWideViewPort(true); settings.setDomStorageEnabled(true); webView.setWebViewClient(new WebViewClient() { @Override public void onPageStarted(WebView view, String url, Bitmap favicon) { super.onPageStarted(view, url, favicon); // 新页面开始加载时，先把高度重置，防止上一个页面残留高度影响测量 ViewGroup.LayoutParams lp = view.getLayoutParams(); lp.height = ViewGroup.LayoutParams.WRAP_CONTENT; view.setLayoutParams(lp); } @Override public void onPageFinished(WebView view, String url) { super.onPageFinished(view, url); // 首轮测量：等布局完成 view.post(() -> measureAndSetHeight(view)); // 多轮校准：给图片和异步脚本时间 view.postDelayed(() -> measureAndSetHeight(view), 120); view.postDelayed(() -> measureAndSetHeight(view), 300); } }); webView.loadUrl("https://example.com/content-page"); }

在这个流程里，onPageStarted 重置高度是很多人会漏掉的一步。H5 页面跳转时，如果上一步已经把 WebView 高度设置成真实内容高度，新页面开始加载时 WebView 内部 DOM 已经变化，但 LayoutParams 里还是旧高度，中间就会闪一段空白。

6.3 注入 JS 桥的完整封装

把测量和图片监听封装成一个工具方法，所有内嵌 WebView 的场景都可以复用它：

public static void bindResize(ResizableWebView webView) { webView.setWebViewClient(new WebViewClient() { @Override public void onPageFinished(WebView view, String url) { super.onPageFinished(view, url); view.post(() -> resize(view)); view.postDelayed(() -> resize(view), 150); view.postDelayed(() -> resize(view), 400); view.postDelayed(() -> resize(view), 800); } }); } private static void resize(WebView view) { view.evaluateJavascript(JS_MEASURE_HEIGHT, value -> { try { int height = Integer.parseInt(value.replace("\"", "")); ViewGroup.LayoutParams lp = view.getLayoutParams(); if (lp.height != height) { lp.height = height; view.setLayoutParams(lp); } } catch (Exception ignored) { } }); }

这里的 150ms、400ms、800ms 是经验值，不是固定标准。如果应用内页面都比较轻量，可以减少校准轮数；如果经常出现图片异步加载，可以增加到 1 秒、1.5 秒甚至 3 秒。重点是连续两次测量结果相同后就可以停止，避免高频执行 evaluateJavascript 带来的性能损耗。

6.4 横竖屏与 Fragment 重建时的恢复

旋转屏幕时，Activity 会重新创建，WebView 可能因为配置变更而重新加载页面。如果你的页面只是临时加载，那重新测量一次就好；如果希望保持当前滚动位置且不重新加载 H5，可以在 onSaveInstanceState 里保存 WebView 状态，并在 onRestoreInstanceState 恢复，恢复后必须重新触发一次高度测量。

@Override protected void onSaveInstanceState(Bundle outState) { super.onSaveInstanceState(outState); webView.saveState(outState); } @Override protected void onRestoreInstanceState(Bundle savedInstanceState) { super.onRestoreInstanceState(savedInstanceState); webView.restoreState(savedInstanceState); webView.postDelayed(() -> measureAndSetHeight(webView), 200); }

如果你用的是 Fragment 且 view 会在 onDestroyView 时销毁，记得在销毁前把 WebView 从父容器 removeAllViews 再销毁，否则会出现 WebView 内存泄漏相关的抖动和空白。这一步属于通用常规操作，但内嵌 WebView 页面里特别容易忽略。

7. 排查实录：那些年我踩过的“空白”坑

7.1 现场一：内容只显示一屏，再也滚不动

这个问题是高度坍缩，原因基本是 WebView 高度没走 wrap_content 校准逻辑。检查顺序：确认布局文件里 WebView 的高度是 wrap_content，确认 ResizableWebView 里确实判断了 LayoutParams.height 并走了自定义测量分支，确认加载完成后有没有触发 requestLayout。

我遇到过一个比较隐蔽的情况：代码里设置了 webView.layoutParams.height 为某个具体数值，后续 JS 校准函数判断 lp.height != newHeight 时，因为 newHeight 算出来的值和旧值一致，就不再 setLayoutParams，但旧值本身已经不对。遇到这种情况，不要只在高度不同时才设置，直接无条件更新高度参数并调用 requestLayout 更省心。

7.2 现场二：WebView 底部出现一大片白

如果你使用的是 JS 测量回填的方案，首先确认测量结果是取最大值还是取的最小值。比如只取 document.body.scrollHeight，在 body 高度小于 documentElement 高度时就会偏小；或者取 offsetHeight，在内容存在 margin 时又可能偏小。统一采用 documentElement 和 body 两个维度的最大值后，这个现场基本能解决。

如果最大值测出来依然偏大，那就是页面里存在 min-height 样式或者 100vh 容器，这种属于页面本身设计问题，App 端去猜它反而不合适。可以直接在 H5 侧和前端同事校对一下，让前端在移动端样式里去掉 min-height 约束。

7.3 现场三：图片加载完成后，内容又被截断

这是最典型的“测早”问题。onPageFinished 触发后，图片可能还在网络加载中，此时 JS 量出来的高度并不包含图片最终撑开的高度。我的多轮校准方案就是为了处理这种场景。校准轮次一定不要只调一次，否则图片加载一慢，空白就出现了。

如果项目性能要求高，不想频繁执行 evaluateJavascript，可以只监听 document.images 的 onload 事件，在所有图片加载完成后触发一次最终测量。两者结合最好：加载完成后先测一次，图片 onload 后再测一次。

7.4 现场四：外层滑到底后，WebView 区域还能继续滚

这种基本上说明 WebView 内部还有可滚动内容，也就是校准后的高度小于真实内容高度。除了检查多轮测量是否完成之外，还需要确认 WebView 的 setUseWideViewPort 是否影响到了布局宽度。窄屏页面因为 width 设置不合理，导致内容横向溢出，纵向高度反而被压缩。可以在 WebSettings 中开启 useWideViewPort 和 loadWithOverviewMode，保证网页按移动端视口正常渲染，再做高度测量。

7.5 现场五：方案在低端真机上滚动卡顿

长内容 WebView 嵌在 NestedScrollView 中，低端机型会因为纹理层和渲染树过大而出现明显掉帧。这时可以限制 WebView 最大高度，超过阈值后不再继续展开，而是显示一个“继续阅读”按钮，点击后跳转原生容器。

我在模拟项目 X 里设置的最大高度是 8000px，实际测试下来，在大多数中端机上滚动 60 帧基本能稳定在 50 帧左右，体验可以接受。超过这个长度，很多 H5 页面本身也有“全文”跳转，限制高度不会影响业务。

7.6 问题排查速查表

8. 最后一点经验：不存在一行代码的“最完美”

写到这里，估计很多人还是会问：到底有没有一段代码，粘进去就再也不用管了？我的感受是，WebView 嵌套滑动问题的本质决定了不可能有银弹。不同系统版本的 WebView 内核行为不一致，不同 H5 页面的结构和加载策略也不一致，真正能长期稳定跑在线上项目的方案，一定是一个“测量策略 + 加载时机 + 导航事件 + 多轮校准”的组合体。

我现在的项目里，所有内嵌 H5 的页面统一使用同一套 ResizableWebView + 多轮测量工具类，从最初的三星、华为、小米各出各的问题，到现在基本所有真机上都能保持一致行为。中间多写的那几十行校准代码，换来的是一整年没再收到“详情页滚不到底”的线上反馈。如果一开始只图快，看到 onPageFinished 就写死高度，后续维护成本反而会高得多。

这套方案不需要引入第三方库，也不需要依赖系统私有 API，所有逻辑都建立在公开的 WebView 方法和 JS 注入机制上，后续升级系统版本也不用担心兼容性翻车。如果你的页面恰好也踩在这个坑里，建议直接按章操作：先重写 onMeasure 解决测量入口，再用 JS 多轮校准解决异步内容，最后把滚动事件让渡给父容器。这三件事做完，页面显示不全和大段空白的问题基本就根治了。