Android之WebView解析思维导图模板_ProcessOn思维导图、流程图

1. 简介

一个基于webkit引擎、展现web页面的控件

2. 作用

1.在 Android 客户端上加载h5页面

2.在本地与 h5页面实现交互 & 调用

3.对 url 请求、页面加载、渲染、对话框进行额外处理。

3.使用介绍

常见方法

1.加载url

2.WebView的状态

3. 关于前进 / 后退网页

问题：在不做任何处理前提下，浏览网页时点击系统的“Back”键,整个 Browser 会调用 finish()而结束自身

4.清除缓存数据

工具类

WebSettings

1.生成一个WebView组件

2.进行配置

3.设置WebView缓存

WebViewClient

1.shouldOverrideUrlLoading()

2.onPageStarted()

3.onPageFinished()

4.onLoadResource()

5.onReceivedError()

6.onReceivedSslError()

WebChromeClient

1. onProgressChanged()

2. onReceivedTitle()

3.onJsAlert()

4.onJsConfirm()

5.onJsPrompt()

4.WebView与JS交互

Android调用JS代码

1.通过WebView的loadUrl（）

优点：方便简洁

缺点：效率低，获取返回值麻烦

使用场景：不需要返回值，对性能要求低

2.通过WebView的evaluateJavascript（"Javascript:方法名",回调）

优点：效率高

缺点：兼容性差（仅Android4.4以上）

使用场景：Android4.4以上

JS调用Android代码

1.通过WebView的addJavascriptInterface（）进行对象映射

优点：方便简洁

缺点：Android4.2以下存在漏洞

使用场景：Android4.2以上

2.通过 WebViewClient 的shouldOverrideUrlLoading ()方法回调拦截 url

优点：不存在漏洞

缺点：使用复杂：1.需要进行协议的约束；2.从Native层往Web层传递值比较繁琐）

使用场景：1.不需要返回值情况；2.IOS主要使用该方式

3.通过 WebChromeClient 的onJsAlert()、onJsConfirm()、onJsPrompt（）方法回调拦截JS对话框alert()、confirm()、prompt（）消息

优点：不存在漏洞

缺点：使用复杂：1.需要进行协议的约束；

使用场景：满足大多数情况

5.使用漏洞

1.任意代码执行漏洞

1,WebView 中 addJavascriptInterface（）接口

1.addJavascriptInterface 接口引起远程代码执行漏洞

2,产生原因:当JS拿到Android这个对象后，就可以调用这个Android对象中所有的方法

3,解决方案

Android 4.2版本之后

Android 4.2版本之前

4,注意:两个细节

2,WebView 内置导出的 searchBoxJavaBridge_对象

1,产生原因 :Android 3.0以下

2,解决方案:删除searchBoxJavaBridge_接口

3,WebView 内置导出的 accessibility 和 accessibilityTraversalObject 对象

2.密码明文存储漏洞

1,产生原因:WebView默认开启密码保存功能

2,解决方案:关闭密码保存提醒

3.域控制不严格漏洞

1,产生原因:Android的Mainifest.xml设置exported属性

2,分析

1. setAllowFileAccess（）设置是否允许 WebView 使用 File 协议

2. setAllowFileAccessFromFileURLs（）是否允许通过 file url 加载的 Js代码读取其他的本地文件

3. setAllowUniversalAccessFromFileURLs（）是否允许通过 file url 加载的 Javascript 可以访问其他的源

4. setJavaScriptEnabled（）是否允许 WebView 使用 JavaScript（默认是不允许）

3,解决方案:(1)不需要使用 file 协议的应用，禁用 file 协议; (2)需要使用 file 协议的应用，禁止 file 协议加载 JavaScript

6. 缓存机制构建

性能问题

1,Android WebView 里 H5 页面加载速度慢

渲染速度慢

页面资源加载缓慢

2,耗费流量

解决方案

1,前端H5的缓存机制

1,浏览器缓存机制

a. 原理

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

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

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

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

b. 特点

优点：支持 Http协议层

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

c. 应用场景

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

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

d. 具体实现

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

2,Application Cache 缓存机制

a. 原理

以文件为单位进行缓存，且文件有一定更新机制（类似于浏览器缓存机制）

AppCache 原理有两个关键点：manifest 属性和 manifest 文件。

b. 特点

方便构建Web App的缓存

c. 应用场景

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

d. 具体实现

3,Dom Storage 缓存机制

a. 原理

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

b. 特点

存储空间大（ 5MB）：存储空间对于不同浏览器不同，如Cookies 才 4KB

存储安全、便捷： Dom Storage 存储的数据在本地，不需要经常和服务器进行交互

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

c. 应用场景

存储临时、简单的数据

d. 具体实现

4,Web SQL Database 缓存机制

a. 原理

基于 SQL 的数据库存储机制

b. 特点

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

c. 应用场景

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

d. 具体实现

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

5,Indexed Database 缓存机制

a. 原理

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

b. 特点

功能强大,使用简单

通过数据库的事务(transtion)机制进行数据操作

可对对象任何属性生成索引,方便查询

存储空间大

较大的存储空间,默认250M

使用灵活

以key-value的方式存取对象,可以是任何类型值或对象.包括二进制

异步的API调用,避免造成等待而影响体验

c. 应用场景

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

d. 具体实现

6,File System 缓存机制（H5页面新加入的缓存机制， 虽然Android WebView暂时不支持，但会进行简单介绍）

a. 原理

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

b. 特点

可存储数据体积较大的二进制数据

可预加载资源文件

可直接编辑文件

c. 应用场景

通过文件系统管理数据

d. 具体使用

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

建议:

存储静态资源文件(JS等)

浏览器缓存机制

application cache存储机制

存储  临时,简单的数据

Dom Storage 缓存机制

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

IndexedDB 缓存机制

2, 缓存模式

缓存模式是一种当加载 H5网页时该如何读取之前保存到本地缓存 从而进行使用的方式

3,资源预加载

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

1, 预加载WebView对象

首次使用WebView对象

在Android的baseApplication里初始化1个WebView对象

后续使用WebView对象

自身构建WebView复用池,采用多个WebView, 每次页面跳转需要清空上1个页面, 即置空WebView

2, 预加载H5资源

原理

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

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

应用场景

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

4, 自身构建缓存

需求场景

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

实现步骤

1,事先将更新频率较低、常用 & 固定的H5静态资源文件（如JS、CSS文件、图片等）放到本地

2,拦截H5页面的资源网络请求并进行检测

3,如果检测到本地具有相同的静态资源就直接从本地读取进行替换而不发送该资源的网络请求到服务器获取

具体实现

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

本地的静态资源更新

发布新版本安装更新

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

好处

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

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

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

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

问题：在不做任何处理前提下，浏览网页时点击系统的“Back”键,整个 Browser 会调用 finish()而结束自身