首页 ›存档› 技术 › 查看内容

Android WebView详解，常见漏洞详解和安全源码（上）

2018-3-30 13:00 |来自: 互联网 411 0

摘要: Android Hybrid 和 WebView 解析现在市面上的 APP 根据类型大致可以分为 3 类：Native APP、Web APP 和 Hybrid APP，而 Hybrid APP 兼具 “Native APP 良好用户交互体验的优势”和 “Web APP 跨平台开发的优势”， ...

Android Hybrid 和 WebView 解析

现在市面上的 APP 根据类型大致可以分为 3 类：Native APP、Web APP 和 Hybrid APP，而 Hybrid APP 兼具 “Native APP 良好用户交互体验的优势”和 “Web APP 跨平台开发的优势”，现在很多的主流应用也是使用 Hybrid 模式开发的。

Hybrid 的优势与原生的体验差距

Hybrid 的优势

为什么要使用 Hybrid 开发呢，这就要提到 native 开发的限制：

1.客户端发板周期长

众所周知，客户端的发板周期在正常情况下比较长，就算是创业公司的迭代也在一到两个星期一次，大公司的迭代周期一般都在月这个数量级别上，而且Android还好，iOS的审核就算变短了也有几天，而且可能会有审核不通过的意外情况出现，所谓为了应对业务的快速发展，很多业务比如一些活动页面就可以使用 H5 来进行开发。

2.客户端大小体积受限

如果所有的东西都使用 native 开发，比如上面提到的活动页面，就会造成大量的资源文件要加入到 APK 中，这就造成 APK 大小增加，而且有的活动页面更新很快，造成资源文件可能只会使用一个版本，如果不及时清理，就会造成资源文件的残留。

3.web 页面的体验问题

使用纯 Web 开发，比以前迭代快速很多，但是从某种程度上来说，还是不如原生页面的交互体验好；

4.无法跨平台

一般情况下，同一样的页面在 android 和 iOS 上需要写两份不同的代码，但是现在只需要写一份即可，Hybrid 具有跨平台的优势。

所以综上这两种方式单独处理都不是特别好，考虑到发版周期不定，而且体验交互上也不能很差，所以就把两种方式综合起来，让终端和前端共同开发一个 APP，这样一些迭代很稳定的页面就可以使用原生，增加体验性；一些迭代很快速的页面就可以使用 H5，让两种优点结合起来，弥补原来单个开发模式的缺点。

H5 与 Native 的体验差距

H5 和 Native 的体验差距主要在两个方面：

1.页面渲染瓶颈

第一个是前端页面代码渲染，受限于 JS 的解析效率，以及手机硬件设备的一些性能，所以从这个角度来说，我们应用开发者是很难从根本上解决这个问题的；

2.资源加载缓慢

第二个方面是 H5 页面是从服务器上下发的，客户端的页面在内存里面，在页面加载时间上面，根据网络状况的不同，H5 页面的体验和 Native 在很多情况下相比差距还是不小的，但是这种问题从某种程度上来说也是可以弥补的，比如说我们可以做一些资源预加载的方案，在资源预加载方面，其实也有很多种方式，下面主要列举了一些：

第一种方式是使用 WebView 自身的缓存机制：

如果我们在 APP 里面访问一个页面，短时间内再次访问这个页面的时候，就会感觉到第二次打开的时候顺畅很多，加载速度比第一次的时间要短，这个就是因为 WebView 自身内部会做一些缓存，只要打开过的资源，他都会试着缓存到本地，第二次需要访问的时候他直接从本地读取，但是这个读取其实是不太稳定的东西，关掉之后，或者说这种缓存失效之后，系统会自动把它清除，我们没办法进行控制。基于这个 WebView 自身的缓存，有一种资源预加载的方案就是，我们在应用启动的时候可以开一个像素的 WebView ，事先去访问一下我们常用的资源，后续打开页面的时候如果再用到这些资源他就可以从本地获取到，页面加载的时间会短一些。

第二种方案是，我们自己去构建，自己管理缓存：

把这些需要预加载的资源放在 APP 里面，他可能是预先放进去的，也可能是后续下载的，问题在于前端这些页面怎么去缓存，两个方案，第一种是前端可以在 H5 打包的时候把里面的资源 URL 进行替换，这样可以直接访问本地的地址；第二种是客户端可以拦截这些网页发出的所有请求做替换：

这个是美团使用的预加载方案（详情请看：

美团大众点评 Hybrid 化建设

），归属于第二种加载方案，每当 WebView 发起资源请求的时候，我们会拦截这些资源的请求，去本地检查一下我们这些静态资源本地离线包有没有。针对本地的缓存文件我们有些策略能够及时的去更新它，为了安全考虑，也需要同时做一些预下载和安全包的加密工作。预下载有以下几点优势：

我们拦截了 WebView 里面发出的所有的请求，但是并没有替换里面的前端应用的任何代码，前端这套页面代码可以在 APP 内，或者其他的 APP 里面都可以直接访问，他不需要为我们 APP 做定制化的东西；
这些 URL 请求，他会直接带上先前用户操作所留下的 Cookie ，因为我们没有更改资源原始 URL 地址；
整个前端在用离线包和缓存文件的时候是完全无感知的，前端只用管写一个自己的页面，客户端会帮他处理好这样一些静态资源预加载的问题，有这个离线包的话，加载速度会变快很多，特别是在弱网情况下，没有这些离线包加载速度会慢一些。而且如果本地离线包的版本不能跟 H5 匹配的话，H5 页面也不会发生什么问题。

实际资源预下载也确实能够有效的增加页面的加载速度，具体的对比可以去看美团的那片文章。

那么什么地方需要使用 Native 开发，什么地方需要使用 H5 开发呢：一般来说 Hybrid 是用在一些快速迭代试错的地方，另外一些非主要产品的页面，也可以使用 Hybrid 去做；但是如果是一些很重要的流程，使用频率很高，特别核心的功能，还是应该使用 Native 开发，让用户得到一个极致的产品体验。

WebView 详细介绍

我们来看看 Google 官网关于 WebView 的介绍：

A View that displays web pages. This class is the basis upon which you can roll your own web browser
 or simply display some online content within your Activity. It uses the WebKit rendering engine 
 to display web pages and includes methods to navigate forward and backward through a history, 
 zoom in and out, perform text searches and more.

可以看到 WebView 是一个显示网页的控件，并且可以简单的显示一些在线的内容，并且基于 WebKit 内核，在 Android4.4(API Level 19) 引入了一个基于 Chromium 的新版本 WebView ，这让我们的 WebView 能支持HTML5和CSS3以及JavaScript，有一点需要注意的是由于 WebView 的升级，对于我们的程序也带来了一些影响，如果我们的 targetSdkVersion 设置的是 18 或者更低， single and narrow column 和 default zoom levels 不再支持。Android4.4 之后有一个特别方便的地方是可以通过 setWebContentDebuggingEnabled() 方法让我们的程序可以进行远程桌面调试。