ScrollView(或NestedScrollView)嵌套WebView只加载图片无文字的巨坑

ScrollView嵌套WebView+原生控件的实现,可参考我的最新文章:ScrollView嵌套WebView与原生控件组合的一些问题


最近项目有一个需求,大概是上面为H5页面,下面是原生的List(用RecyclerView实现),拼接在一起。很自然想到用ScrollView来嵌套吧,虽然官方不建议,但也没办法咯!
谷歌的NestedScollView还是很好用的,解决了很多滑动冲突,尤其是配合ListView、RecyclerView这类控件时。

基本操作

布局大概是这样(省略其余无关内容):

<android.support.v4.widget.NestedScrollView
    android:id="@+id/test_scroll_view"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical">

        <WebView
            android:id="@+id/test_web_view"
            android:layout_width="match_parent"
            android:layout_height="match_parent" />

        <include layout="@layout/layout_list" />

    </LinearLayout>

</android.support.v4.widget.NestedScrollView>

然后按照常规操作初始化WebView布局,各种settings各种client重写方法,destroy时回收资源等等,这里就不赘述了(因为最后发现巨坑和这些初始化设置都无关)。
推荐一篇:史上最全WebView使用,附送Html5Activity一份

进坑

标题里说的坑是什么呢?
case1: 项目业务要求,在WebView所在的Activity启动之后,再通过网络请求去获取Web的url链接,请求成功回调才开始loadUrl。这个操作非常关键,因为中间有不确定的时差(测试的时候可以通过起一个延时线程来模拟)。
case2: 我们平时使用WebView,一般都是在初始化操作完成后立马loadUrl,而我们的WebView初始化往往都是在onCreate中进行的。
上述两个case是有区别的,其差异也是这个坑的起源。
坑来了:
对于case1,当我在网络请求的回调中加载url时,发现图文并茂的H5页面只剩下了铺满宽度的图片,文字内容完全没有了,原本很长的文章,其高度变成了屏幕的高度,不过下面的原生控件还是正常加载了的,ScrollView依然可以滑动。
WebView内的效果就像那种响应式的布局被宽高严重挤压一样,或者说是网页样式没有加载完全,但我JS支持也开启了的。
猜测原因,尝试出坑:
1、第一就想到了ScrollView嵌套的问题,因为WebView也是可以滑动的,这俩玩意在一起肯定会导致高度之类的坑,然后我把WebView移出ScrollView,果然就不会有问题了,但这并不能满足业务需求,只是缩小了问题分析范围。
2、然后谷歌百度了大量ScrollView嵌套WebView的坑,所有方法试了个遍,这篇文章基本上总结了所有相关解决办法(ScrollView嵌套WebView卡顿,进度条无限),什么JS注入,什么重新set布局参数,包括该文博主最后把WebView改为wrap_content解决问题,对我来说,全都没用。好气啊!
3、于是,我开始瞎搞,把网络请求强行延时3秒再回调,发现竟然没问题了,图文网页可以正常加载了。WTF?这到底是怎么回事?接着我又把测试用的url直接hard-coding到初始化后立即加载(相当于上述case2),也没有问题。
坑外分析:
这就怪了,也即是说loadUrl方法立即调用没问题,很久之后再调用也没问题,偏偏就网络请求并回调那几十毫秒~几百毫秒的区间中出问题。
联系刚才的高度问题,和方法调用的时机问题,想了下,可能跟ScrollView和WebView绘制测量布局的时刻有关,当我们在onCreate中loadUrl时,这时候用户还不可见呢,UI也没绘制,但网页的总高度已经拿到了,所以当ScrollView开始绘制时,已经知道了子控件WebView的高度,那么最终也就没有问题。
那为何很久之后再loadUrl也没问题呢?猜测是此时所有控件都已经绘制完了,但网页还没开始加载,所以高度是0,当再次加载时,触发重新测量,内容正常填充到WebView当中。
问题出在,控件在绘制过程中,由于网络请求回调是异步的,此刻加载网页,导致高度计算错误。
其实说了这么多,基本上都是我个人结合现象的猜测,具体没有实证,还望各位大佬指正原因。

妥协的解决

最终还是得解决问题,经过上述的分析,在满足业务需要的前提下,我的处理方式还是在初始化WebView结束后立即loadUrl,但这时候没有图文的真实url咋办呢?我们可以load一个空页面,比如"about:blank"之类的,或者让前端同学写一个简单的内容空白的html,这样即便加载实际的url时高度和空白页面高度不一样,也不会出现异常。

后话

其实后来我又想了下,现在这种混合实现方式的App这么多,为何它们没有任何问题?于是我去扒了下头条那些信息流的文章url,换到我的WebView里加载,竟然完美显示,不管我loadUrl的时刻是何时。这就很尴尬了,看来这个和网页本身也有关系的,仔细对比有问题的网页源代码,也没看出啥端倪,毕竟对前端不是特别熟悉,但总之这也是掉入巨坑的因素之一吧。
不过在我们不知道网页来源优质与否、是否可天然适应这种嵌套布局时,还是自己从原生层面规避比较好。

展开阅读全文
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值