转载自http://blog.youkuaiyun.com/carson_ho/article/details/71402764
前言
- 由于
H5
具备 开发周期短、灵活性好 的特点,所以现在Android App
大多嵌入了Android Webview
组件进行Hybrid
开发 - 但我知道你一定在烦恼
Android Webview
的性能问题,特别突出的是:加载速度慢 & 消耗流量 - 今天,我将针对
Android Webview
的性能问题,提出一些有效解决方案。
目录
1. Android WebView 存在什么性能问题?
Android WebView
里H5
页面加载速度慢- 耗费流量
下面会详细介绍。
1.1 H5 页面加载速度慢
下面会详细介绍:
1.1.1 渲染速度慢
前端H5
页面渲染的速度取决于 两个方面:
Js
解析效率
Js
本身的解析过程复杂、解析速度不快 & 前端页面涉及较多JS
代码文件,所以叠加起来会导致Js
解析效率非常低- 手机硬件设备的性能
由于Android
机型碎片化,这导致手机硬件设备的性能不可控,而大多数的Android手机硬件设备无法达到很好很好的硬件性能
总结:上述两个原因 导致 H5页面的渲染速度慢。
1.1.2 页面资源加载缓慢
H5
页面从服务器获得,并存储在 Android
手机内存里:
H5
页面一般会比较多- 每加载一个
H5
页面,都会产生较多网络请求:
HTML
主URL
自身的请求;HTML
外部引用的JS、CSS
、字体文件,图片也是一个独立的HTTP
请求
每一个请求都串行的,这么多请求串起来,这导致 H5
页面资源加载缓慢
总结:H5页面加载速度慢的原因:渲染速度慢 & 页面资源加载缓慢 导致 。
1.2 耗费流量
- 每次使用
H5
页面时,用户都需要重新加载Android WebView
的H5
页面 - 每加载一个
H5
页面,都会产生较多网络请求(上面提到) - 每一个请求都串行的,这么多请求串起来,这导致消耗的流量也会越多
总结
- 综上所述,产生
Android WebView
性能问题主要原因是:
- 上述问题导致了
Android WebView
的H5
页面体验 与 原生Native
存在较大差距。
2. 解决方案
针对上述Android WebView
的性能问题,我提出了两种解决方案:
- 使用
Android WebView
自身的缓存机制 - 自身构建缓存机制(主要是
H5
页面资源的预加载)
下面我将详细介绍。
2.1 Android WebView
自身的缓存机制
- 定义
缓存,即离线存储
这意味着
H5
网页 加载过之后会存储在缓存区域,在没有网络连接时也可以进行访问 -
作用
- 离线浏览:用户可在没有网络连接时进行
H5
页面访问 - 提高页面加载速度 & 减少流量消耗:直接使用已缓存的资源,不需要重新加载
- 离线浏览:用户可在没有网络连接时进行
-
具体应用
此处讲解主要讲解Android WebView
的缓存机制 & 缓存模式 :
a. 缓存机制:如何将加载过的网页数据保存到本地
b. 缓存模式:加载网页时如何读取之前保存到本地的网页缓存前者是保存,后者是读取,请注意区别
2.1.1 缓存机制
Android WebView
的本质:在Android 中嵌入H5
页面- 所以,
Android WebView
自带的缓存机制其实就是H5
页面的缓存机制
Android WebView
除了新的File System
缓存机制还不支持,其他都支持。 Android WebView
自带的缓存机制有5种:
- 浏览器 缓存机制
Application Cache
缓存机制Dom Storage
缓存机制Web SQL Database
缓存机制Indexed Database
缓存机制File System
缓存机制(H5
页面新加入的缓存机制,虽然Android WebView
暂时不支持,但会进行简单介绍)
下面将详细介绍每种缓存机制。
1. 浏览器缓存机制
a. 原理
- 根据
HTTP
协议头里的Cache-Control
(或Expires
)和Last-Modified
(或Etag
)等字段来控制文件缓存的机制 -
下面详细介绍
Cache-Control
、Expires
、Last-Modified
&Etag
四个字段-
Cache-Control
:用于控制文件在本地缓存有效时长如服务器回包:
Cache-Control:max-age=600
,则表示文件在本地应该缓存,且有效时长是600秒(从发出请求算起)。在接下来600秒内,如果有请求这个资源,浏览器不会发出 HTTP 请求,而是直接使用本地缓存的文件。 -
Expires
:与Cache-Control
功能相同,即控制缓存的有效时间Expires
是HTTP1.0
标准中的字段,Cache-Control 是HTTP1.1
标准中新加的字段- 当这两个字段同时出现时,
Cache-Control
优先级较高
-
Last-Modified
:标识文件在服务器上的最新更新时间下次请求时,如果文件缓存过期,浏览器通过 If-Modified-Since 字段带上这个时间,发送给服务器,由服务器比较时间戳来判断文件是否有修改。如果没有修改,服务器返回304告诉浏览器继续使用缓存;如果有修改,则返回200,同时返回最新的文件。
-
Etag
:功能同Last-Modified
,即标识文件在服务器上的最新更新时间。- 不同的是,
Etag
的取值是一个对文件进行标识的特征字串。 - 在向服务器查询文件是否有更新时,浏览器通过
If-None-Match
字段把特征字串发送给服务器,由服务器和文件最新特征字串进行匹配,来判断文件是否有更新:没有更新回包304,有更新回包200 Etag
和Last-Modified
可根据需求使用一个或两个同时使用。两个同时使用时,只要满足基中一个条件,就认为文件没有更新。
- 不同的是,
-
常见用法是:
Cache-Control
与Last-Modified
一起使用;Expires
与Etag
一起使用;
即一个用于控制缓存有效时间,一个用于在缓存失效后,向服务查询是否有更新
特别注意:浏览器缓存机制 是 浏览器内核的机制,一般都是标准的实现
即
Cache-Control
、Last-Modified
、Expires
、Etag
都是标准实现,你不需要操心
b. 特点
- 优点:支持
Http
协议层 - 不足:缓存文件需要首次加载后才会产生;浏览器缓存的存储空间有限,缓存有被清除的可能;缓存的文件没有校验。
对于解决以上问题,可以参考手 Q 的离线包
c. 应用场景
静态资源文件的存储,如` JS、CSS`、字体、图片等。
Android Webview
会将缓存的文件记录及文件内容会存在当前 app 的 data 目录中。
d. 具体实现
`Android WebView`内置自动实现,即不需要设置即实现
Android
4.4后的WebView
浏览器版本内核:Chrome
- 浏览器缓存机制 是 浏览器内核的机制,一般都是标准的实现
2. Application Cache 缓存机制
a. 原理
- 以文件为单位进行缓存,且文件有一定更新机制(类似于浏览器缓存机制)
AppCache
原理有两个关键点:manifest 属性和 manifest 文件。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
b. 特点
方便构建Web App
的缓存
专门为
Web App
离线使用而开发的缓存机制
c. 应用场景
存储静态文件(如JS
、CSS
、字体文件)
- 应用场景 同 浏览器缓存机制
- 但AppCache 是对 浏览器缓存机制 的补充,不是替代。
d. 具体实现
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
3. 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. 具体实现
- 1
- 2
- 3
- 4
- 5
4. Web SQL Database 缓存机制
a. 原理
基于 SQL
的数据库存储机制
b. 特点
充分利用数据库的优势,可方便对数据进行增加、删除、修改、查询c. 应用场景
存储适合数据库的结构化数据d. 具体实现
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
特别说明
- 根据官方说明,
Web SQL Database
存储机制不再推荐使用(不再维护) - 取而代之的是
IndexedDB
缓存机制,下面会详细介绍
5. IndexedDB 缓存机制
a. 原理
属于 NoSQL
数据库,通过存储字符串的 Key - Value
对来提供
类似于
Dom Storage 存储机制
的key-value
存储方式
b. 特点
c. 应用场景
存储 复杂、数据量大的结构化数据
d. 具体实现:
- 1
- 2
- 3
- 4
- 5
- 6
6 . File System
a. 原理
-
为
H5
页面的数据 提供一个虚拟的文件系统- 可进行文件(夹)的创建、读、写、删除、遍历等操作,就像
Native App
访问本地文件系统一样 - 虚拟的文件系统是运行在沙盒中
- 不同
WebApp
的虚拟文件系统是互相隔离的,虚拟文件系统与本地文件系统也是互相隔离的。
- 可进行文件(夹)的创建、读、写、删除、遍历等操作,就像
-
虚拟文件系统提供了两种类型的存储空间:临时 & 持久性:
- 临时的存储空间:由浏览器自动分配,但可能被浏览器回收
- 持久性的存储空间:需要显式申请;自己管理(浏览器不会回收,也不会清除内容);存储空间大小通过配额管理,首次申请时会一个初始的配额,配额用完需要再次申请。
b. 特点
- 可存储数据体积较大的二进制数据
- 可预加载资源文件
- 可直接编辑文件
c. 应用场景
通过文件系统 管理数据
d. 具体使用
由于 File System
是 H5
新加入的缓存机制,所以Android WebView
暂时不支持
缓存机制汇总
使用建议
- 综合上述缓存机制的分析,我们可以根据 需求场景的不同(缓存不同类型的数据场景) 从而选择不同的缓存机制(组合使用)
- 以下是缓存机制的使用建议:
小技巧
- 在使用了上述说的
Android WebView
的缓存机制后,短时间内再次访问同一个H5
页面时,加载速度会比第一次的时间短、更加流畅 - 基于
Android WebView
自身的这些缓存机制,有一种小技巧能更好地去减少H5
页面的加载速度 & 提高性能:在应用启动时就初始化一个WebView
,事先加载常用H5
页面资源(加载后就有缓存了),后续需要打开这些H5
页面时就直接从本地获取。
这种技巧其实是采用了 资源预加载 的思想:提早加载将来需要使用的
H5
页面(有缓存了),使用时直接取过来用,而不用在需要时才去加载 - 具体实现:在
Android
的BaseApplication
就初始化一个WebView
对象用于加载常用的H5
页面资源;当需要使用这些页面时再从BaseApplication
里取过来直接使用
1. 对于Android WebView
的首页建议使用这种方案,能有效提高首页加载的效率
2. 当然这里的BaseApplication
只是举个例子,你也可以选择在其他地方提前加载。
2.1.2 缓存模式
- 定义
缓存模式是一种 当加载H5
网页时 该如何读取之前保存到本地缓存
从而进行使用 的方式
即告诉
Android WebView
什么时候去读缓存,以哪种方式去读缓存 Android WebView
自带的缓存模式有4种:
- 1
- 2
- 3
- 4
- 5
- 具体使用
- 1
- 2
- 3
2.2. 自身构建缓存
为了有效解决 Android WebView
的性能问题,除了使用 Android WebView
自身的缓存机制,还可以自己针对某一需求场景构建缓存机制。
2.2.1 需求场景
- 背景:
H5
页面有一些更新频率低、常用 & 固定的静态资源文件(如JS
、CSS
文件、图片等)
如一些图片,
JS、CSS
文件等 - 需求场景:每次重新加载会浪费很多资源(时间 & 流量)
2.2.2 解决方案(原理)
通过拦截`H5`页面的资源网络请求 从而 直接从本地读取资源 而不需要发送网络请求到服务器读取。2.2.3 具体步骤
- 事先将更新频率较低、常用 & 固定的
H5
静态资源 文件(如JS
、CSS
文件、图片等) 放到本地 - 拦截
H5
页面的资源网络请求 并进行检测 - 如果检测到本地具有相同的静态资源 就 直接从本地读取进行替换 而 不发送该资源的网络请求 到 服务器获取
2.2.4 具体实现
重写`WebViewClient` 的 `shouldInterceptRequest` 方法,当向服务器访问这些静态资源时进行拦截,检测到是相同的资源则用本地资源代替- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
2.2.5 具体实例
下面我将通过 替换主页面(http:// ip.cn/
)中的一个图片(http:// s.ip-cdn.com/img/logo.gif
) 来对静态资源拦截 进行说明。
为了更好的表现效果,我将替换的图片换成别的图片
具体步骤 & 代码如下
步骤1:定义WebView
布局
activity_main.xml
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
步骤2:进行资源的拦截、检测 & 替换(详细请看注释)
MainActivity.java
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
步骤3:加入网络权限
Manifest.xml
- 1
Demo地址
Carson_Ho的Github地址:https://github.com/Carson-Ho/WebView_InterceptRequest
特别注意
关于上述放到本地的静态资源也是可以更新的:- 发布新版本安装更新
- 增量更新:在用户处于
WIFI
环境时让服务器推送到本地
很多著名的
App
(如微信)就是采用小范围更新本地资源的
这种缓存机制的好处
- 有效解决
H5
页面静态资源 加载速度慢 & 流量消耗多的问题 -
开发成本低
- 没有改变前端
H5
的任何代码,不需要为 APP 做定制化的东西 - 该方法只是更好地加快
H5
加载速度,哪怕失效,也不会对H5
页面产生其他负面影响
- 没有改变前端
-
同样能获得相应的
cookie
发送的网络请求会直接带上先前用户操作所留下的cookie
而都能够留下来,因为我们没有更改资源的 URL 地址
参考:WebView缓存目录及清理http://blog.youkuaiyun.com/jamkier/article/details/45850833