Android WebView缓存机制优化加载慢问题

2026-01-26 13:29:24

一、前言

由于H5具备开发周期短、灵活性好的特点，所以现在 Android App大多嵌入了 Android Webview 组件进行 Hybrid 开发

但我知道你一定在烦恼 Android Webview 的性能问题，特别突出的是：加载速度慢 & 消耗流量

今天，我将针对 Android Webview 的性能问题，提出一些有效解决方案。

二、WebView存在的性能问题

Android WebView 里 H5 页面加载速度慢
耗费流量

2.1 H5 页面加载速度慢

2.1.1 渲染速度慢

前端H5页面渲染的速度取决于两个方面：

Js 解析效率

Js 本身的解析过程复杂、解析速度不快 & 前端页面涉及较多 JS 代码文件，所以叠加起来会导致 Js 解析效率非常低

手机硬件设备的性能

由于Android机型碎片化，这导致手机硬件设备的性能不可控，而大多数的Android手机硬件设备无法达到很好很好的硬件性能

总结：上述两个原因导致 H5页面的渲染速度慢。

2.1.2 页面资源加载缓慢

H5 页面从服务器获得，并存储在 Android手机内存里：

H5页面一般会比较多

每加载一个 H5页面，都会产生较多网络请求

1.HTML 主 URL 自身的请求；

2.HTML外部引用的JS、CSS、字体文件，图片也是一个独立的 HTTP 请求

每一个请求都串行的，这么多请求串起来，这导致 H5页面资源加载缓慢

总结：H5页面加载速度慢的原因：渲染速度慢 & 页面资源加载缓慢导致。

2.2 耗费流量

每次使用 H5页面时，用户都需要重新加载 Android WebView的H5 页面
每加载一个 H5页面，都会产生较多网络请求（上面提到）
每一个请求都串行的，这么多请求串起来，这导致消耗的流量也会越多

2.3 总结

综上所述，产生Android WebView性能问题主要原因是：

上述问题导致了Android WebView的H5 页面体验与原生Native 存在较大差距。

三、解决方案

针对上述Android WebView的性能问题，我提出了3种解决方案：

前端H5的缓存机制（WebView 自带）
资源预加载
资源拦截

3.1 前端H5的缓存机制

定义

缓存，即离线存储

1.这意味着 H5网页加载后会存储在缓存区域，在无网络连接时也可访问
2.WebView的本质 = 在 Android中嵌入 H5页面，所以，Android WebView自带的缓存机制其实就是 H5页面的缓存机制
3.Android WebView除了新的File System缓存机制还不支持，其他都支持。

作用

1.离线浏览：用户可在没有网络连接时进行H5页面访问

2.提高页面加载速度 & 减少流量消耗：直接使用已缓存的资源，不需要重新加载

具体应用

此处讲解主要讲解前端H5的缓存机制的缓存机制 & 缓存模式：

a. 缓存机制：如何将加载过的网页数据保存到本地

b. 缓存模式：加载网页时如何读取之前保存到本地的网页缓存

前者是保存，后者是读取，请注意区别

3.1.1 缓存机制

Android WebView自带的缓存机制有5种：

浏览器缓存机制
Application Cache 缓存机制
Dom Storage 缓存机制
Web SQL Database 缓存机制
Indexed Database 缓存机制
File System 缓存机制（H5页面新加入的缓存机制，虽然Android WebView暂时不支持，但会进行简单介绍）

下面将详细介绍每种缓存机制。

浏览器缓存机制

a. 原理

根据 HTTP 协议头里的 Cache-Control（或 Expires）和 Last-Modified（或Etag）等字段来控制文件缓存的机制
下面详细介绍Cache-Control、Expires、Last-Modified & Etag四个字段

1.Cache-Control：用于控制文件在本地缓存有效时长

如服务器回包：Cache-Control:max-age=600，则表示文件在本地应该缓存，且有效时长是600秒（从发出请求算起）。在接下来600秒内，如果有请求这个资源，浏览器不会发出 HTTP 请求，而是直接使用本地缓存的文件。

2.Expires：与Cache-Control功能相同，即控制缓存的有效时间

Expires是 HTTP1.0 标准中的字段，Cache-Control 是 HTTP1.1 标准中新加的字段

当这两个字段同时出现时，Cache-Control 优先级较高

3.Last-Modified：标识文件在服务器上的最新更新时间

下次请求时，如果文件缓存过期，浏览器通过 If-Modified-Since 字段带上这个时间，发送给服务器，由服务器比较时间戳来判断文件是否有修改。如果没有修改，服务器返回304告诉浏览器继续使用缓存；如果有修改，则返回200，同时返回最新的文件。

4.Etag：功能同Last-Modified ，即标识文件在服务器上的最新更新时间。

不同的是，Etag 的取值是一个对文件进行标识的特征字串。

在向服务器查询文件是否有更新时，浏览器通过If-None-Match 字段把特征字串发送给服务器，由服务器和文件最新特征字串进行匹配，来判断文件是否有更新：没有更新回包304，有更新回包200

Etag 和 Last-Modified 可根据需求使用一个或两个同时使用。两个同时使用时，只要满足基中一个条件，就认为文件没有更新。

常见用法是：

Cache-Control与 Last-Modified 一起使用；
Expires与 Etag一起使用；

即一个用于控制缓存有效时间，一个用于在缓存失效后，向服务查询是否有更新

特别注意：浏览器缓存机制是浏览器内核的机制，一般都是标准的实现

b. 特点

优点：支持 Http协议层

不足：缓存文件需要首次加载后才会产生；浏览器缓存的存储空间有限，缓存有被清除的可能；缓存的文件没有校验。

c. 应用场景

静态资源文件的存储，如JS、CSS、字体、图片等。

Android Webview会将缓存的文件记录及文件内容会存在当前 app 的 data 目录中。

d. 具体实现

Android WebView内置自动实现，即不需要设置即实现

Android 4.4后的 WebView 浏览器版本内核：Chrome

浏览器缓存机制是浏览器内核的机制，一般都是标准的实现

Application Cache 缓存机制

a. 原理

以文件为单位进行缓存，且文件有一定更新机制（类似于浏览器缓存机制）
AppCache 原理有两个关键点：manifest 属性和 manifest 文件。

<!DOCTYPE html>
<html manifest="demo_html.appcache">
// HTML 在头中通过 manifest 属性引用 manifest 文件
// manifest 文件：就是上面以 appcache 结尾的文件，是一个普通文件文件，列出了需要缓存的文件
// 浏览器在首次加载 HTML 文件时，会解析 manifest 属性，并读取 manifest 文件，获取 Section：CACHE MANIFEST 下要缓存的文件列表，再对文件缓存
<body>
...
</body>
</html>
// 原理说明如下：
// AppCache 在首次加载生成后，也有更新机制。被缓存的文件如果要更新，需要更新 manifest 文件
// 因为浏览器在下次加载时，除了会默认使用缓存外，还会在后台检查 manifest 文件有没有修改（byte by byte)
发现有修改，就会重新获取 manifest 文件，对 Section：CACHE MANIFEST 下文件列表检查更新
// manifest 文件与缓存文件的检查更新也遵守浏览器缓存机制
// 如用户手动清了 AppCache 缓存，下次加载时，浏览器会重新生成缓存，也可算是一种缓存的更新
// AppCache 的缓存文件，与浏览器的缓存文件分开存储的，因为 AppCache 在本地有 5MB（分 HOST）的空间限制

b. 特点

方便构建Web App的缓存

专门为 Web App离线使用而开发的缓存机制

c. 应用场景

存储静态文件（如JS、CSS、字体文件）

应用场景同浏览器缓存机制

但AppCache 是对浏览器缓存机制的补充，不是替代。

d. 具体实现

        // 通过设置WebView的settings来实现
        WebSettings settings = getSettings();
        String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/";
        settings.setAppCachePath(cacheDirPath);
        // 1. 设置缓存路径
         settings.setAppCacheMaxSize(20*1024*1024);
        // 2. 设置缓存大小
        settings.setAppCacheEnabled(true);
        // 3. 开启Application Cache存储机制
// 特别注意
// 每个 Application 只调用一次 WebSettings.setAppCachePath() 和
 WebSettings.setAppCacheMaxSize()

Dom Storage 缓存机制

a. 原理

通过存储字符串的 Key - Value 对来提供

DOM Storage 分为 sessionStorage & localStorage；二者使用方法基本相同，区别在于作用范围不同：

a. sessionStorage：具备临时性，即存储与页面相关的数据，它在页面关闭后无法使用

b. localStorage：具备持久性，即保存的数据在页面关闭后也可以使用。

b. 特点

存储空间大（ 5MB）：存储空间对于不同浏览器不同，如Cookies 才 4KB存储安全、便捷： Dom Storage 存储的数据在本地，不需要经常和服务器进行交互

不像 Cookies每次请求一次页面，都会向服务器发送网络请求

c. 应用场景

存储临时、简单的数据

代替 **将不需要让服务器知道的信息存储到 cookies **的这种传统方法
Dom Storage 机制类似于 Android 的 SharedPreference机制

d. 具体实现

// 通过设置 `WebView`的`Settings`类实现
WebSettings settings = getSettings();
settings.setDomStorageEnabled(true);
// 开启DOM storage

Dom Storage 缓存机制

a. 原理

基于 SQL 的数据库存储机制

b. 特点

充分利用数据库的优势，可方便对数据进行增加、删除、修改、查询

c. 应用场景

存储适合数据库的结构化数据

d. 具体实现

// 通过设置WebView的settings实现
WebSettings settings = getSettings();
String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/";
settings.setDatabasePath(cacheDirPath);
// 设置缓存路径
settings.setDatabaseEnabled(true);
// 开启 数据库存储机制

特别说明

根据官方说明，Web SQL Database存储机制不再推荐使用（不再维护）
取而代之的是 IndexedDB缓存机制，下面会详细介绍

IndexedDB 缓存机制

a. 原理

属于 NoSQL 数据库，通过存储字符串的 Key - Value 对来提供

类似于 Dom Storage 存储机制的key-value存储方式

b. 特点

c. 应用场景

存储复杂、数据量大的结构化数据

d. 具体实现

// 通过设置WebView的settings实现
        WebSettings settings = getSettings();
        settings.setJavaScriptEnabled(true);
        // 只需设置支持JS就自动打开IndexedDB存储机制
        // Android 在4.4开始加入对 IndexedDB 的支持，只需打开允许 JS 执行的开关就好了。

File System

a. 原理

为 H5页面的数据提供一个虚拟的文件系统

1.可进行文件（夹）的创建、读、写、删除、遍历等操作，就像 Native App 访问本地文件系统一样
2.虚拟的文件系统是运行在沙盒中
3.不同 WebApp 的虚拟文件系统是互相隔离的，虚拟文件系统与本地文件系统也是互相隔离的。

虚拟文件系统提供了两种类型的存储空间：临时 & 持久性

1.临时的存储空间：由浏览器自动分配，但可能被浏览器回收
2.持久性的存储空间：需要显式申请；自己管理（浏览器不会回收，也不会清除内容）；存储空间大小通过配额管理，首次申请时会一个初始的配额，配额用完需要再次申请。

b. 特点

可存储数据体积较大的二进制数据
可预加载资源文件
可直接编辑文件

c. 应用场景

通过文件系统管理数据

d. 具体使用

由于 File System是 H5 新加入的缓存机制，所以Android WebView暂时不支持

缓存机制汇总

使用建议

综合上述缓存机制的分析，我们可以根据需求场景的不同（缓存不同类型的数据场景）从而选择不同的缓存机制（组合使用）
以下是缓存机制的使用建议

3.1.2 缓存模式

定义

缓存模式是一种当加载 H5网页时该如何读取之前保存到本地缓存

从而进行使用的方式

即告诉Android WebView 什么时候去读缓存，以哪种方式去读缓存

Android WebView 自带的缓存模式有4种：

// 缓存模式说明:
      // LOAD_CACHE_ONLY: 不使用网络，只读取本地缓存数据
      // LOAD_NO_CACHE: 不使用缓存，只从网络获取数据.
      // LOAD_DEFAULT: （默认）根据cache-control决定是否从网络上取数据。
      // LOAD_CACHE_ELSE_NETWORK，只要本地有，无论是否过期，或者no-cache，都使用缓存中的数据。

具体使用

// 设置参数即可
WebView.getSettings().setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK);

3.2 资源预加载

定义

提早加载将需使用的H5页面，即提前构建缓存

具体实现

预加载WebView对象 & 预加载H5资源

3.2.1 预加载WebView对象

此处主要分为2方面：首次使用的WebView对象 & 后续使用的WebView对象

3.2.2 预加载H5资源

原理

1.在应用启动、初始化第一个WebView对象时，直接开始网络请求加载H5页面

2.后续需打开这些H5页面时就直接从该本地对象中获取

a. 从而事先加载常用的H5页面资源（加载后就有缓存了）
b. 此方法虽然不能减小WebView初始化时间，但数据请求和WebView初始化可以并行进行，总体的页面加载时间就缩短了；缩短总体的页面加载时间：

具体实现

在Android 的BaseApplication里初始化一个WebView对象（用于加载常用的H5页面资源）；当需使用这些页面时再从BaseApplication里取过来直接使用 3.2.3 应用场景

对于Android WebView的首页建议使用这种方案，能有效提高首页加载的效率

3.3 自身构建缓存

为了有效解决 Android WebView 的性能问题，除了使用 Android WebView 自身的缓存机制，还可以自己针对某一需求场景构建缓存机制。

3.3.1 需求场景

3.3.2 实现步骤

事先将更新频率较低、常用 & 固定的H5静态资源文件（如JS、CSS文件、图片等）放到本地
拦截H5页面的资源网络请求并进行检测
如果检测到本地具有相同的静态资源就直接从本地读取进行替换而不发送该资源的网络请求到服务器获取

3.3.3 具体实现

重写WebViewClient 的 shouldInterceptRequest 方法，当向服务器访问这些静态资源时进行拦截，检测到是相同的资源则用本地资源代替

// 假设现在需要拦截一个图片的资源并用本地资源进行替代
        mWebview.setWebViewClient(new WebViewClient() {
            // 重写 WebViewClient  的  shouldInterceptRequest （）
            // API 21 以下用shouldInterceptRequest(WebView view, String url)
            // API 21 以上用shouldInterceptRequest(WebView view, WebResourceRequest request)
            // 下面会详细说明
             // API 21 以下用shouldInterceptRequest(WebView view, String url)
            @Override
            public WebResourceResponse shouldInterceptRequest(WebView view, String url) {
                // 步骤1:判断拦截资源的条件，即判断url里的图片资源的文件名
                if (url.contains("logo.gif")) {
                // 假设网页里该图片资源的地址为：http://abc.com/imgage/logo.gif
                // 图片的资源文件名为:logo.gif
                    InputStream is = null;
                    // 步骤2:创建一个输入流
                    try {
                        is =getApplicationContext().getAssets().open("images/abc.png");
                        // 步骤3:获得需要替换的资源(存放在assets文件夹里)
                        // a. 先在app/src/main下创建一个assets文件夹
                        // b. 在assets文件夹里再创建一个images文件夹
                        // c. 在images文件夹放上需要替换的资源（此处替换的是abc.png图片）
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    // 步骤4:替换资源
                    WebResourceResponse response = new WebResourceResponse("image/png",
                            "utf-8", is);
                    // 参数1：http请求里该图片的Content-Type,此处图片为image/png
                    // 参数2：编码类型
                    // 参数3：存放着替换资源的输入流（上面创建的那个）
                    return response;
                }
                return super.shouldInterceptRequest(view, url);
            }
           // API 21 以上用shouldInterceptRequest(WebView view, WebResourceRequest request)
            @TargetApi(Build.VERSION_CODES.LOLLIPOP)
            @Override
            public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {
               // 步骤1:判断拦截资源的条件，即判断url里的图片资源的文件名
                if (request.getUrl().toString().contains("logo.gif")) {
                // 假设网页里该图片资源的地址为：http://abc.com/imgage/logo.gif
                // 图片的资源文件名为:logo.gif
                    InputStream is = null;
                    // 步骤2:创建一个输入流
                    try {
                        is = getApplicationContext().getAssets().open("images/abc.png");
                         // 步骤3:获得需要替换的资源(存放在assets文件夹里)
                        // a. 先在app/src/main下创建一个assets文件夹
                        // b. 在assets文件夹里再创建一个images文件夹
                        // c. 在images文件夹放上需要替换的资源（此处替换的是abc.png图片
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    // 步骤4:替换资源
                    WebResourceResponse response = new WebResourceResponse("image/png",
                            "utf-8", is);
                    // 参数1：http请求里该图片的Content-Type,此处图片为image/png
                    // 参数2：编码类型
                    // 参数3：存放着替换资源的输入流（上面创建的那个）
                    return response;
                }
                return super.shouldInterceptRequest(view, request);
            }
    });
}

3.3.4 具体实例

下面我将通过替换主页面（http:// ip.cn/）中的一个图片（http:// s.ip-cdn.com/img/logo.gif）来对静态资源拦截进行说明。

为了更好的表现效果，我将替换的图片换成别的图片

具体步骤 & 代码如下

Manifest.xml

<uses-permission android:name="android.permission.INTERNET"/>

activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:paddingBottom="@dimen/activity_vertical_margin"
    android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingRight="@dimen/activity_horizontal_margin"
    android:paddingTop="@dimen/activity_vertical_margin"
    tools:context="scut.carson_ho.webview_interceptrequest.MainActivity">
    <WebView
        android:id="@+id/webview"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
</RelativeLayout>

MainActivity.java

public class MainActivity extends AppCompatActivity {
    WebView mWebview;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mWebview = (WebView) findViewById(R.id.webview);
        // 创建WebView对象
        mWebview.getSettings().setJavaScriptEnabled(true);
        // 支持与JS交互
        mWebview.loadUrl("http://ip.cn/");
        // 加载需要显示的网页
        mWebview.setWebViewClient(new WebViewClient() {
             // 复写shouldInterceptRequest
             //API21以下用shouldInterceptRequest(WebView view, String url)
            @Override
            public WebResourceResponse shouldInterceptRequest(WebView view, String url) {
                // 步骤1:判断拦截资源的条件，即判断url里的图片资源的文件名
                // 此处网页里图片的url为:http://s.ip-cdn.com/img/logo.gif
                // 图片的资源文件名为:logo.gif
                if (url.contains("logo.gif")) {
                    InputStream is = null;
                    // 步骤2:创建一个输入流
                    try {
                        is =getApplicationContext().getAssets().open("images/error.png");
                        // 步骤3:打开需要替换的资源(存放在assets文件夹里)
                        // 在app/src/main下创建一个assets文件夹
                        // assets文件夹里再创建一个images文件夹,放一个error.png的图片
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    // 步骤4:替换资源
                    WebResourceResponse response = new WebResourceResponse("image/png",
                            "utf-8", is);
                    // 参数1:http请求里该图片的Content-Type,此处图片为image/png
                    // 参数2:编码类型
                    // 参数3:替换资源的输入流
                    System.out.println("旧API");
                    return response;
                }
                return super.shouldInterceptRequest(view, url);
            }
            // API21以上用shouldInterceptRequest(WebView view, WebResourceRequest request)
            @TargetApi(Build.VERSION_CODES.LOLLIPOP)
            @Override
            public WebResourceResponse shouldInterceptRequest(WebView view, WebResourceRequest request) {
                // 步骤1:判断拦截资源的条件，即判断url里的图片资源的文件名
                // 此处图片的url为:http://s.ip-cdn.com/img/logo.gif
                // 图片的资源文件名为:logo.gif
                if (request.getUrl().toString().contains("logo.gif")) {
                    InputStream is = null;
                    // 步骤2:创建一个输入流
                    try {
                        is = getApplicationContext().getAssets().open("images/error.png");
                        // 步骤3:打开需要替换的资源(存放在assets文件夹里)
                        // 在app/src/main下创建一个assets文件夹
                        // assets文件夹里再创建一个images文件夹,放一个error.png的图片
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    //步骤4:替换资源
                    WebResourceResponse response = new WebResourceResponse("image/png",
                            "utf-8", is);
                    // 参数1：http请求里该图片的Content-Type,此处图片为image/png
                    // 参数2：编码类型
                    // 参数3：存放着替换资源的输入流（上面创建的那个）
                    return response;
                }
                return super.shouldInterceptRequest(view, request);
            }
    });
}
}

特别注意

关于上述放到本地的静态资源也是可以更新的：

发布新版本安装更新
增量更新：在用户处于WIFI环境时让服务器推送到本地

很多著名的App（如微信）就是采用小范围更新本地资源的

这种缓存机制的好处

有效解决 H5页面静态资源加载速度慢 & 流量消耗多的问题

开发成本低

1.没有改变前端H5的任何代码，不需要为 APP 做定制化的东西

2.该方法只是更好地加快H5加载速度，哪怕失效，也不会对H5页面产生其他负面影响

同样能获得相应的cookie 发送的网络请求会直接带上先前用户操作所留下的 cookie 而都能够留下来，因为我们没有更改资源的URL地址

到此这篇关于Android WebView缓存机制优化加载慢问题的文章就介绍到这了,更多相关Android WebView 内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

浅谈Android开发Webview的Loading使用效果

目录前言 1. loading的选择 2. loading显示时机的问题 3. 体验优化 4. loading最终设计效果总结前言在开发webview的loading效果的时候会有一些问题,这边记录一些碰到的常见的问题,并且设计出一套Loading的方案来解决相关的问题. 1. loading的选择开发loading效果的原因在于webview加载页面的时候,有时候会耗时,导致不显示内容又没有任何提示,效果不太好,所以需要在webview使用的地方加上loading的效果,其实更好的体
Android WebView预渲染介绍

目录前言术语对齐客户端可以从哪些方面优化h5页面的加载速度? 优化思路预渲染的基本实现逻辑是怎样的? 预创建预创建个数预创建时机预创建复用预渲染预渲染时机预渲染有效性校验时间有效性状态有效性页面显示状态通知其它注意事项预渲染存在哪些局限性? 总结前言在一个Hybrid项目中,必不可少的就是加载h5页面.h5页面的加载性能极大影响着用户体验,并会从各方面影响到我们APP的业务数据.试想,假设一个h5页面要花好几秒才能打开,那用户还会使用我们的APP吗?所以今天我们
Android WebView控件基本使用示例

Android WebView用于在 android 中显示网页.可以从相同的应用程序或 URL 加载网页.它用于在 android 活动中显示在线内容. Android WebView 使用 webkit 引擎来显示网页. android.webkit.WebView 是 AbsoluteLayout 类的子类. Android WebView 类的loadUrl()和loadData()方法用于加载和显示网页. Android WebView 示例让我们看看使用 Web 视图显示 baid
Android WebView软键盘遮挡输入框方案详解

目录背景纪实方案实现总结背景笔者在使用 WebView 加载含有输入框的 H5 页面时,点击输入框后,输入框会被软键盘遮挡住,无法看到输入的内容,这很影响用户体验. 笔者想着这种业务场景比较常见,遂上网搜索一番,果不其然,有不少同志遇到这个问题,想来这个问题很好解决了.笔者一一尝试了同志们提供的解决方案,结果要不是没有作用,要不是效果不太满意,只好自己另辟蹊径了. 注:在笔者的业务场景中,App是全屏的,即没有顶部的系统栏,也没有底部的导航栏,所以笔者的解决方案,可能不适用于其他场
Android webView加载数据时内存溢出问题及解决

目录 Android webView加载数据时内存溢出 Android内存问题 (内存溢出内存泄漏内存抖动) 总结 Android webView加载数据时内存溢出今天使用webView加载数据时如果数据太长就会崩溃,造成内存溢出,在网上查找了一下资料之后终于把它解决了,谨在此记录 1.不要在XML里面写webView 可以使用一个占位布局 <FrameLayout android:id="@+id/layoutWebView" android:
Android WebView输入框被档问题升级解析

目录前言 issue 5497问题布局顶起后距离软键盘有一定距离 Activity的webview输入框被挡总结前言之前写过一篇文章,有讲如何处理Android输入框被软键盘挡住的问题,无论是原生的还是webview的,这里面主要的问题是webview的问题比较难处理,没有看过的可以先看看 Android 输入框被挡问题完美解决方案主要是issue 5497这个问题.然后可能有些朋友觉得,这篇文章没能解决他的问题,或者说按照我的代码去写又会出现新的问题.这说明没有能理解这篇文章写的
Android WebView如何判断是否滚动到底部

目录场景: 分析: 实现: 总结场景: 我们有时候需要弹一些必读公告,但是呢可能会要去你看完之后才可以关掉,所以就需要滚动到底部才显示关闭按钮,而公告什么的往往又是基于富文本的,那么在展示在Android上时就要用到WebView,基于这个要求就有了判断 WebView 判断是否滚动到底部. 分析: 要判断是否到底部那么我们先来分析有哪几种情况,当html文档加载到WebView后会有一下两种情况. WebView里的html内容没有填充满,就是无滚动条情况.html内容的高度比WebVie
Android WebView基础应用详解

目录一.WebView的基础配置二.WebView支持播放音乐三.WebView支持视频播放四.WebChromeClient 五.WebViewClient 1.重定向问题 2.实现预加载 3.增加错误页面展示限制 4.解决页面白屏问题附GitHub源码:WebViewExplore 一.WebView的基础配置 WebSettings ws = getSettings(); ws.setBuiltInZoomControls(true);// 隐藏缩放按钮 ws.setLayout
Android WebView实现全屏播放视频

目录介绍主要代码介绍最近项目开发中用到了WebView播放视频的功能,总结了开发中犯过的错误,这些错误在开发是及容易遇到的,所以我这里总结了一下,希望大家看到后不要再犯类似的错误,尽可能提高开发效率: 这个Demo我这里也参考了网上写的一个比较好的一个Demo,经过总结修改,写出来的. 主要代码以下是相应代码: MainActivity: package com.androidwebviewdemo; import android.app.Activity; import androi
解决Android WebView拦截url,视频播放加载失败的问题

需求:Android调用webView加载网页的时候,拦截某一个链接不执行此链接,执行指定跳转到其他activity页面. webview的setWebViewClient方法中提供了几个api: // 此回调是拦截点击要跳转的url链接,并对请求的url链接做修改(添加删除字段) public WebResourceResponse shouldInterceptRequest(WebView view, String url) // 在点击请求的是链接是才会调用,重写此方法返回true表明点
Android WebView如何判定网页加载的错误

一前言在WebView加载网页的过程中,有时会页面加载不出来的情况,如下: 那么如何知道网页加载错误了呢? 二解决方法 webview.webViewClient = object : WebViewClient() { override fun onPageFinished(view: WebView?, url: String?) { super.onPageFinished(view, url) Log.d(TAG, "onPageFinished: ") } overri
Android中使用二级缓存、异步加载批量加载图片完整案例

一.问题描述 Android应用中经常涉及从网络中加载大量图片,为提升加载速度和效率,减少网络流量都会采用二级缓存和异步加载机制,所谓二级缓存就是通过先从内存中获取.再从文件中获取,最后才会访问网络.内存缓存(一级)本质上是Map集合以key-value对的方式存储图片的url和Bitmap信息,由于内存缓存会造成堆内存泄露, 管理相对复杂一些,可采用第三方组件,对于有经验的可自己编写组件,而文件缓存比较简单通常自己封装一下即可.下面就通过案例看如何实现网络图片加载的优化. 二.案例介绍案例新
Android使用缓存机制实现文件下载及异步请求图片加三级缓存

首先给大家介绍Android使用缓存机制实现文件下载在下载文件或者在线浏览文件时,或者为了保证文件下载的正确性,需要使用缓存机制,常使用SoftReference来实现. SoftReference的特点是它的一个实例保存对一个Java对象的软引用,该软引用的存在不妨碍垃圾收集线程对该Java对象的回收.也就是说,一旦SoftReference保存了对一个Java对象的软引用后,在垃圾线程对这个Java对象回收前,SoftReference类所提供的get()方法返回Java对象的强引用.另外
Android开发实现webview中img标签加载本地图片的方法

本文实例讲述了Android开发实现webview中img标签加载本地图片的方法.分享给大家供大家参考,具体如下: 在网上查了很多教程,感觉很麻烦,各种方法,最后实践很简单,主要是两步: WebSettings webSettings=webView.getSettings(); //允许webview对文件的操作 webSettings.setAllowUniversalAccessFromFileURLs(true); webSettings.setAllowFileAccess(true)
Android编程学习之异步加载图片的方法

本文实例讲述了Android编程学习之异步加载图片的方法.分享给大家供大家参考,具体如下: 最近在android开发中碰到比较棘手的问题,就是加载图片内存溢出.我开发的是一个新闻应用,应用中用到大量的图片,一个界面中可能会有上百张图片.开发android应用的朋友可能或多或少碰到加载图片内存溢出问题,一般情况下,加载一张大图就会导致内存溢出,同样,加载多张图片内存溢出的概率也很高. 列一下网络上查到的一般做法: 1.使用BitmapFactory.Options对图片进行压缩 2.优化加载图片的
Android WebView 缓存详解

Android WebView 缓存详解一. 两种缓存类型: 页面缓存:加载一个网页时的html.JS.CSS等页面或者资源数据,这些缓存资源是由于浏览器的行为而产生,开发者只能通过配置HTTP响应头影响浏览器的行为才能间接地影响到这些缓存数据. 而缓存的索引放在:/data/data//databases 对应的文件放在:/data/data/package_name/cache/webviewCacheChromunm下数据缓存:分为AppCache和DOM Storage两种我们
Android 图片缓存机制的深入理解

Android 图片缓存机制的深入理解 Android加载一张图片到用户界面是很简单的,但是当一次加载多张图片时,情况就变得复杂起来.很多情况下(像ListView.GridView或ViewPager等组件),屏幕上已显示的图片和即将滑动到当前屏幕上的图片数量基本上是没有限制的. 这些组件通过重用已经移除屏幕的子视图来将降低内存的使用,垃圾回收器也会及时释放那些已经不再使用的已下载的图片,这些都是很好的方法,但是为了保持一个流畅的.快速加载的用户界面,就应该避免当再次回到某个页面时而重新处理图
Android ListView实现ImageLoader图片加载的方法

本文实例讲述了Android ListView实现ImageLoader图片加载的方法.分享给大家供大家参考,具体如下: 最近一直忙着做项目,今天也是忙里偷闲,想写篇博客来巩固下之前在应用中所用的知识.之前我们可能会也会肯定遇到了图片的异步加载问题,然而我们也可能会遇到图片二次或多次加载,这是ListView的特性造成的,具体原因不在这里讨论,又或者是OOM等问题.今天要讲的是一个开源框架Imageloader,个人觉得非常的好用. 该框架在github的地址.https://github.co
Android开发实现ListView异步加载数据的方法详解

本文实例讲述了Android开发实现ListView异步加载数据的方法.分享给大家供大家参考,具体如下: 1.主Activity public class MainActivity extends Activity { private ListView listView; private ArrayList<Person> persons; private ListAdapter adapter; private Handler handler=null; //xml文件的网络地址 final