说实话，ZuoAndroid开发这么久，Zui让人抓狂的组件之一非WebView莫属。你有没有遇到过这种情况？明明页面加载完了你想把WebView的高度自适应一下结果要么是内容被截断，要么就是下面留了一大截空白，甚至有时候拿到的高度数值大得离谱，仿佛在嘲笑你的无知。别担心，你不是一个人在战斗。今天咱们就抛开那些枯燥的官方文档，像老朋友聊天一样，彻底把“如何获取Android WebView内容高度”这个问题给掰扯清楚。

这不仅仅是一个简单的API调用问题，这背后涉及到渲染机制、线程通信，甚至是Web世界与Native世界的单位换算。咱们一步步来kankan怎么才Neng优雅地解决这个问题。

一、 为什么直接调用API总是“翻车”？

hen多刚入门的朋友在遇到这个问题时第一反应往往是去Google搜一下然后kan到类似 `getContentHeight` 这样的方法，心想：“这不就结了吗？” 于是代码一写，运行起来结果发现——坑爹呢，数值不对啊！

其实这真不Neng全怪你。Android原生提供的 `getContentHeight` 方法，听起来hen美好，但它有几个让人头疼的“脾气”。

1. 单位的陷阱：dp与px的爱恨情仇

你拿到的这个数值，它到底是什么单位？在hen多情况下它返回的是基于屏幕密度的逻辑像素，也就是我们常说的dp。但是你在设置布局参数或者进行绘图的时候，Android往往需要的是物理像素。这就好比你跟一个美国人说“我要一百块钱”，他给你的是一百美刀，而你心里想的是一百人民币，这中间的汇率换算要是没搞对，结果肯定是一团糟。

Ru果你直接拿这个值去用，hen可Neng会发现数值特别大，或者特别小。这就是典型的单位不统一造成的灾难。咱们来kankan一段常见的代码逻辑：

// hen多开发者会这么写，kan起来没毛病，实则暗藏杀机
int rawHeight = webView.getContentHeight;
// 这里的转换逻辑是必须的，但往往被忽略
float density = webView.getContext.getResources.getDisplayMetrics.density;
int actualHeight =  ;
// Log.d;

你kan，Ru果不乘以那个 `density`，在高清屏上你的WebView可Neng就显示那么一丁点高。所以Ru果你坚持要用原生方法，千万记得把单位换算这事儿给办了。

2. 时机不对：心急吃不了热豆腐

除了单位，还有一个geng隐蔽的坑，那就是调用时机。WebView加载网页是一个异步过程，什么意思呢？就是你发出了指令，但页面渲染需要时间，图片要下载，JS要执行，布局要计算。

Ru果你在 `onPageStarted` 或者刚 `loadUrl` 之后就去获取高度，这时候页面可Neng还是空的，或者只有个框架，内容根本没渲染出来。这时候你拿到的高度，要么是0，要么是某个默认值。这就好比你蛋糕还没烤熟就想去量高度，那肯定是不准的。

通常大家会去 `WebViewClient` 的 `onPageFinished` 里调用，但说实话，这个回调也不一定靠谱。它只是代表主HTML加载完了里面的图片或者异步AJAX请求可Neng还在路上呢。

二、 终极方案：JavaScript注入法

既然原生方法有点“不靠谱”，咱们不如换个思路。WebView本质上是什么？是一个浏览器内核。浏览器Zui懂谁？当然是HTML和JavaScript。所以Zui精准的高度，其实藏在DOM树里。

通过注入 JavaScript 直接去问DOM：“嘿，兄弟，你现在有多高？” 这种方式通常比原生方法要精准得多，因为它获取的是渲染引擎计算完后的真实高度。

1. 使用 scrollHeight 获取真实高度

在Web前端开发中，`document.documentElement.scrollHeight` 或者 `document.body.scrollHeight` 是获取页面总高度的黄金标准。我们Ke以利用 Android 的 `evaluateJavascript` 方法，把这段脚本扔进去执行。

这里有个小细节要注意，`evaluateJavascript` 是异步的，而且回调回来的结果是个字符串。别直接拿去当int用，记得解析一下还要处理一下可Neng出现的null值。

// 这里的逻辑稍微绕一点，但为了精准，值得！
webView.evaluateJavascript {
    @Override
    public void onReceiveValue {
        // 1. 先判空，JS有时候会返回个"null"字符串，得防着点
        if ) {
            try {
                // 2. 解析字符串，拿到CSS像素值
                float cssHeight = Float.parseFloat;
                // 3. 
强调单位换算！Web那边给的是CSS像素，
                //    咱们Android这边要转成物理像素，还得乘以density
                float density = getResources.getDisplayMetrics.density;
                float actualPx = cssHeight * density;
                // Log.d;
                // 拿到这个 actualPx，你就Ke以去设置布局参数了
                // 比如：webView.getLayoutParams.height =  actualPx;
            } catch  {
                e.printStackTrace;
            }
        }
    }
});

这种方法虽然多写了几行代码，还要处理回调，但它Neng解决90%的高度获取不准的问题。特别是当你的页面内容比较复杂，有hen多动态生成的元素时JS的视角往往比Nativegeng准确。

三、 进阶场景：动态内容的高度监听

现在的Web页面越来越花哨了什么折叠面板、异步加载评论、无限滚动列表……这些东西dou有一个特点：高度是会变的！

你刚加载完页面高度是500，用户点了个“展开geng多”，高度瞬间变成1000了。这时候Ru果你只在初始化时获取一次高度，那后面肯定又要出问题。怎么办？难不成每隔几秒轮询一次？别，那样太耗性Neng了而且显得henlow。

这时候，Web前端的一个神器就派上用场了——ResizeObserver。

1. 利用 ResizeObserver 实现实时监听

这是现代浏览器提供的一个API，专门用来监听元素尺寸的变化。我们Ke以配合 Android 的 `JavascriptInterface`，让Web页面在高度变化时主动“通知”Android端。

这就像是给WebView装了个“报警器”，一旦高度不对劲，立马发消息过来。

你得在Java/Kotlin这边定义一个接口，供JS调用：

// 定义一个桥接对象
public class WebBridge {
    @JavascriptInterface
    public void onHeightChanged {
        // 注意！JS回调过来的线程通常不是主线程
        // Ru果你要geng新UI，必须切回主线程，不然会报错
        new Handler).post -> {
            // 这里Ke以拿到Zui新的高度了
            // Log.d;
            // 在这里geng新你的WebView布局或者其他UI逻辑
            // 比如：recyclerView.requestLayout;
        });
    }
}
// 记得把这个接口加进去
webView.addJavascriptInterface, "AndroidBridge");

然后在页面加载完成后注入一段JS代码来启动监听：

webView.setWebViewClient {
    @Override
    public void onPageFinished {
        super.onPageFinished;
        // 这段JS代码的意思是：创建一个观察者，盯着document.body
        // 一旦尺寸变了就通过 AndroidBridge 把高度传给 Native
        String jsCode = "new ResizeObserver(entries => {" +
                        "  for  {" +
                        "    // 获取Zui新的高度，这里取 contentRect.height 或者 scrollHeight douKe以" +
                        "    let h = document.documentElement.scrollHeight;" +
                        "    AndroidBridge.onHeightChanged;" +
                        "  }" +
                        "}).observe;";
        view.evaluateJavascript;
    }
});

这套组合拳打下来基本上就Neng覆盖所有动态高度的场景了。不管你是异步加载图片，还是展开隐藏的div，Android端douNeng第一时间感知到。

四、 常见问题排查与避坑指南

虽然方案dou给你了但实际开发中总有些奇奇怪怪的问题。这里几个大家Zui容易踩的坑，希望Neng帮你省点调试时间。

1. 为什么获取到的数值大得离谱？

Ru果你发现拿到的数值是几万甚至几十万，别慌，先检查一下单位换算。

原因： hen大概率是你把CSS像素直接当成了物理像素，或者反过来又或者是在 `getContentHeight` 的基础上又乘以了一个错误的density。还有一种可Neng，就是页面里某个元素的宽度或者高度设置成了极大的值，导致 `scrollHeight` 异常。这时候你得用Chrome DevTools连上手机kankan，到底是哪个元素把页面撑爆了。

2. 为什么有时候拿到的是0？

原因： 除了前面说的“调用时机过早”，还有一个可Neng是WebView本身的布局问题。Ru果WebView的父容器是 `wrap_content`，而WebView里的内容还没渲染出来那WebView的高度可Neng就是0。这时候你去获取内容高度，虽然可Neng不是0，但视觉上什么doukan不到。

建议在布局文件里先给WebView一个默认的高度，等内容加载出来并获取到真实高度后再动态修改它的高度。

3. 混淆打包后 JS 接口不生效？

Ru果你用了 `JavascriptInterface`，记得在 ProGuard 或者 R8 的混淆规则里加上保护：

-keepattributes *JavascriptInterface*
-keep class com.yourpackage.WebBridge { *; }

不然打包发布后JS找不到你的Java方法，回调就会静默失败，排查起来非常困难。

获取 WebView 内容高度，虽然是个老生常谈的问题，但真要把它Zuo得完美、适配各种机型和各种复杂的网页结构，还是需要点耐心的。别指望一行代码就Neng走天下多理解一点Web的渲染机制，多懂一点Android的UI绘制原理，你会发现这些所谓的“坑”，其实dou是系统设计留下的必然结果。

希望今天分享的这些“实战经验”Neng帮你解决项目中的麻烦。下次再遇到高度不对的问题，别再怀疑人生了拿出这篇文章，对照着排查一遍，问题大概率也就迎刃而解了。代码写累了就喝杯咖啡吧，毕竟身体才是革命的本钱啊！

---