2. IT
    3. Android WebView 的缓存机制 & 资源预加载方案

    Android WebView 的缓存机制 & 资源预加载方案

    xiaoxiao2021-03-25  11

     

    一、简介

    Retrofit是Square公司开发的一款针对Android网络请求的框架，Retrofit2底层基于OkHttp实现的，OkHttp现在已经得到Google官方认可，大量的app都采用OkHttp做网络请求，其源码详见OkHttp Github。

    本文全部是在Retrofit2.0+版本基础上论述，所用例子全部来自豆瓣Api

    首先先来看一个完整Get请求是如何实现：

    创建业务请求接口，具体代码如下：

    前言

    由于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页面，都会产生较多网络请求（上面提到） 每一个请求都串行的，这么多请求串起来，这导致消耗的流量也会越多

    1.3 总结

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

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

    2. 解决方案

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

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

    下面我将详细介绍。

    2.1 前端H5的缓存机制

    定义  缓存，即离线存储

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

    作用

    离线浏览：用户可在没有网络连接时进行H5页面访问提高页面加载速度 & 减少流量消耗：直接使用已缓存的资源，不需要重新加载

    具体应用  此处讲解主要讲解 前端H5的缓存机制 的缓存机制 & 缓存模式 ：  a. 缓存机制：如何将加载过的网页数据保存到本地  b. 缓存模式：加载网页时如何读取之前保存到本地的网页缓存

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

    2.1.1 缓存机制

    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，有更新回包200Etag 和 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 文件。 <!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）的空间限制 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. 具体实现

    // 通过设置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() 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. 具体实现

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

    4. Web SQL Database 缓存机制

    a. 原理

    基于 `SQL` 的数据库存储机制

    b. 特点

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

    c. 应用场景

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

    d. 具体实现

    // 通过设置WebView的settings实现 WebSettings settings = getSettings(); String cacheDirPath = context.getFilesDir().getAbsolutePath()+"cache/"; settings.setDatabasePath(cacheDirPath); // 设置缓存路径 settings.setDatabaseEnabled(true); // 开启 数据库存储机制 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. 具体实现：

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

    6 . File System

    a. 原理

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

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

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

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

    b. 特点

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

    c. 应用场景

    通过文件系统 管理数据

    d. 具体使用

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

    缓存机制汇总

    使用建议

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

    2.1.2 缓存模式

    定义  缓存模式是一种 当加载 H5网页时 该如何读取之前保存到本地缓存  从而进行使用 的方式  即告诉 Android WebView 什么时候去读缓存，以哪种方式去读缓存 Android WebView 自带的缓存模式有4种： // 缓存模式说明: // LOAD_CACHE_ONLY: 不使用网络，只读取本地缓存数据 // LOAD_NO_CACHE: 不使用缓存，只从网络获取数据. // LOAD_DEFAULT: （默认）根据cache-control决定是否从网络上取数据。 // LOAD_CACHE_ELSE_NETWORK，只要本地有，无论是否过期，或者no-cache，都使用缓存中的数据。 1 2 3 4 5 具体使用 WebView.getSettings().setCacheMode(WebSettings.LOAD_CACHE_ELSE_NETWORK); // 设置参数即可 1 2 3

    2.2 资源预加载

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

    使用时直接取过来用而不用在需要时才去加载

    具体实现  预加载WebView对象 & 预加载H5资源

    2.2.1 预加载WebView对象

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

    2.2.2 预加载H5资源

    原理 

    在应用启动、初始化第一个WebView对象时，直接开始网络请求加载H5页面后续需打开这些H5页面时就直接从该本地对象中获取 

     

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

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

    2.2.3 应用场景

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

    2.3 自身构建缓存

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

    2.3.1 需求场景

    2.3.2 实现步骤

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

    2.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); } }); } 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.3.5 具体实例

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

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

    具体步骤 & 代码如下

    步骤1：定义WebView布局 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> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

    步骤2：进行资源的拦截、检测 & 替换（详细请看注释） 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); } }); } } 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

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

    Demo地址

    Carson_Ho的Github地址：https://github.com/Carson-Ho/WebView_InterceptRequest

    特别注意

    关于上述放到本地的静态资源也是可以更新的：  1. 发布新版本安装更新  2. 增量更新：在用户处于WIFI环境时让服务器推送到本地

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

    这种缓存机制的好处

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

    开发成本低

    没有改变前端H5的任何代码，不需要为 APP 做定制化的东西该方法只是更好地加快H5加载速度，哪怕失效，也不会对H5页面产生其他负面影响

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

     

    这里需要稍作说明，@GET注解就表示get请求，@Query表示请求参数，将会以key=value的方式拼接在url后面

    需要创建一个Retrofit的示例，并完成相应的配置

    1 2 3 4 5 6 Retrofit retrofit = new Retrofit.Builder() .baseUrl("https://api.douban.com/v2/") .addConverterFactory(GsonConverterFactory.create()) .build(); BlueService service = retrofit.create(BlueService.class);

    这里的baseUrl就是网络请求URL相对固定的地址，一般包括请求协议（如Http）、域名或IP地址、端口号等，当然还会有很多其他的配置，下文会详细介绍。还有addConverterFactory方法表示需要用什么转换器来解析返回值，GsonConverterFactory.create()表示调用Gson库来解析json返回值，具体的下文还会做详细介绍。

    调用请求方法，并得到Call实例

    1 Call<BookSearchResponse> call = mBlueService.getSearchBooks("小王子", "", 0, 3);

    Call其实在Retrofit中就是行使网络请求并处理返回值的类，调用的时候会把需要拼接的参数传递进去，此处最后得到的url完整地址为

    https://api.douban.com/v2/book/search?q=小王子&tag=&start=0&count=3

    使用Call实例完成同步或异步请求

    同步请求

    1 BookSearchResponse response = call.execute().body();

    这里需要注意的是网络请求一定要在子线程中完成，不能直接在UI线程执行，不然会crash

    异步请求

    1 2 3 4 5 6 7 8 9 10 call.enqueue(new Callback<BookSearchResponse>() { @Override public void onResponse(Call<BookSearchResponse> call, Response<BookSearchResponse> response) { asyncText.setText("异步请求结果: " + response.body().books.get(0).altTitle); } @Override public void onFailure(Call<BookSearchResponse> call, Throwable t) { } });

    二、如何使用

    首先需要在build.gradle文件中引入需要的第三包，配置如下：

    1 2 3 compile 'com.squareup.retrofit2:retrofit:2.1.0' compile 'com.squareup.retrofit2:converter-gson:2.1.0' compile 'com.squareup.retrofit2:adapter-rxjava:2.1.0'

    引入完第三包接下来就可以使用Retrofit来进行网络请求了。接下来会对不同的请求方式做进一步的说明。

    Get方法

    1. @Query

    Get方法请求参数都会以key=value的方式拼接在url后面，Retrofit提供了两种方式设置请求参数。第一种就是像上文提到的直接在interface中添加@Query注解，还有一种方式是通过Interceptor实现，直接看如何通过Interceptor实现请求参数的添加。

    1 2 3 4 5 6 7 8 9 10 11 public class CustomInterceptor implements Interceptor { @Override public Response intercept(Chain chain) throws IOException { Request request = chain.request(); HttpUrl httpUrl = request.url().newBuilder() .addQueryParameter("token", "tokenValue") .build(); request = request.newBuilder().url(httpUrl).build(); return chain.proceed(request); } }

    addQueryParameter就是添加请求参数的具体代码，这种方式比较适用于所有的请求都需要添加的参数，一般现在的网络请求都会添加token作为用户标识，那么这种方式就比较适合。

    创建完成自定义的Interceptor后，还需要在Retrofit创建client处完成添加

    1 addInterceptor(new CustomInterceptor())

    2. @QueryMap

    如果Query参数比较多，那么可以通过@QueryMap方式将所有的参数集成在一个Map统一传递，还以上文中的get请求方法为例

    1 2 3 4 public interface BlueService { @GET("book/search") Call<BookSearchResponse> getSearchBooks(@QueryMap Map<String, String> options); }

    调用的时候将所有的参数集合在统一的map中即可

    1 2 3 4 5 6 Map<String, String> options = new HashMap<>(); map.put("q", "小王子"); map.put("tag", null); map.put("start", "0"); map.put("count", "3"); Call<BookSearchResponse> call = mBlueService.getSearchBooks(options);

    3. Query集合

    假如你需要添加相同Key值，但是value却有多个的情况，一种方式是添加多个@Query参数，还有一种简便的方式是将所有的value放置在列表中，然后在同一个@Query下完成添加，实例代码如下：

    1 2 3 4 public interface BlueService { @GET("book/search") Call<BookSearchResponse> getSearchBooks(@Query("q") List<String> name); }

    最后得到的url地址为

    1 https://api.douban.com/v2/book/search?q=leadership&q=beyond feelings

    4. Query非必填

    如果请求参数为非必填，也就是说即使不传该参数，服务端也可以正常解析，那么如何实现呢？其实也很简单，请求方法定义处还是需要完整的Query注解，某次请求如果不需要传该参数的话，只需填充null即可。

    针对文章开头提到的get的请求，加入按以下方式调用

    1 Call<BookSearchResponse> call = mBlueService.getSearchBooks("小王子", null, 0, 3);

    那么得到的url地址为

    1 https://api.douban.com/v2/book/search?q=小王子&start=0&count=3

    5. @Path

    如果请求的相对地址也是需要调用方传递，那么可以使用@Path注解，示例代码如下：

    1 2 @GET("book/{id}") Call<BookResponse> getBook(@Path("id") String id);

    业务方想要在地址后面拼接书籍id，那么通过Path注解可以在具体的调用场景中动态传递，具体的调用方式如下：

    1 Call<BookResponse> call = mBlueService.getBook("1003078");

    此时的url地址为

    1 https://api.douban.com/v2/book/1003078

    @Path可以用于任何请求方式，包括Post，Put，Delete等等

    Post请求

    1. @field

    Post请求需要把请求参数放置在请求体中，而非拼接在url后面，先来看一个简单的例子

    1 2 3 4 @FormUrlEncoded @POST("book/reviews") Call<String> addReviews(@Field("book") String bookId, @Field("title") String title, @Field("content") String content, @Field("rating") String rating);

    这里有几点需要说明的

    @FormUrlEncoded将会自动将请求参数的类型调整为application/x-www-form-urlencoded，假如content传递的参数为Good Luck，那么最后得到的请求体就是

    1 content=Good+Luck

    FormUrlEncoded不能用于Get请求

    @Field注解将每一个请求参数都存放至请求体中，还可以添加encoded参数，该参数为boolean型，具体的用法为

    1 @Field(value = "book", encoded = true) String book

    encoded参数为true的话，key-value-pair将会被编码，即将中文和特殊字符进行编码转换

    2. @FieldMap

    上述Post请求有4个请求参数，假如说有更多的请求参数，那么通过一个一个的参数传递就显得很麻烦而且容易出错，这个时候就可以用FieldMap

    1 2 3 @FormUrlEncoded @POST("book/reviews") Call<String> addReviews(@FieldMap Map<String, String> fields);

    3. @Body

    如果Post请求参数有多个，那么统一封装到类中应该会更好，这样维护起来会非常方便

    1 2 3 4 5 6 7 8 9 10 @FormUrlEncoded @POST("book/reviews") Call<String> addReviews(@Body Reviews reviews); public class Reviews { public String book; public String title; public String content; public String rating; }

    其他请求方式

    除了Get和Post请求，Http请求还包括Put,Delete等等，用法和Post相似，所以就不再单独介绍了。

    上传

    上传因为需要用到Multipart，所以需要单独拿出来介绍，先看一个具体上传的例子

    首先还是需要新建一个interface用于定义上传方法

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public interface FileUploadService { // 上传单个文件 @Multipart @POST("upload") Call<ResponseBody> uploadFile( @Part("description") RequestBody description, @Part MultipartBody.Part file); // 上传多个文件 @Multipart @POST("upload") Call<ResponseBody> uploadMultipleFiles( @Part("description") RequestBody description, @Part MultipartBody.Part file1, @Part MultipartBody.Part file2); }

    接下来我们还需要在Activity和Fragment中实现两个工具方法，代码如下：

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 public static final String MULTIPART_FORM_DATA = "multipart/form-data"; @NonNull private RequestBody createPartFromString(String descriptionString) { return RequestBody.create( MediaType.parse(MULTIPART_FORM_DATA), descriptionString); } @NonNull private MultipartBody.Part prepareFilePart(String partName, Uri fileUri) { File file = FileUtils.getFile(this, fileUri); // 为file建立RequestBody实例 RequestBody requestFile = RequestBody.create(MediaType.parse(MULTIPART_FORM_DATA), file); // MultipartBody.Part借助文件名完成最终的上传 return MultipartBody.Part.createFormData(partName, file.getName(), requestFile); }

    好了，接下来就是最终的上传文件代码了

    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 Uri file1Uri = ... // 从文件选择器或者摄像头中获取 Uri file2Uri = ... // 创建上传的service实例 FileUploadService service = ServiceGenerator.createService(FileUploadService.class); // 创建文件的part (photo, video, ...) MultipartBody.Part body1 = prepareFilePart("video", file1Uri); MultipartBody.Part body2 = prepareFilePart("thumbnail", file2Uri); // 添加其他的part RequestBody description = createPartFromString("hello, this is description speaking"); // 最后执行异步请求操作 Call<ResponseBody> call = service.uploadMultipleFiles(description, body1, body2); call.enqueue(new Callback<ResponseBody>() { @Override public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) { Log.v("Upload", "success"); } @Override public void onFailure(Call<ResponseBody> call, Throwable t) { Log.e("Upload error:", t.getMessage()); } });

    三、其他必须知道的事项

    1. 添加自定义的header

    Retrofit提供了两个方式定义Http请求头参数：静态方法和动态方法，静态方法不能随不同的请求进行变化，头部信息在初始化的时候就固定了。而动态方法则必须为每个请求都要单独设置。

    静态方法

    1 2 3 4 5 6 7 public interface BlueService { @Headers("Cache-Control: max-age=640000") @GET("book/search") Call<BookSearchResponse> getSearchBooks(@Query("q") String name, @Query("tag") String tag, @Query("start") int start, @Query("count") int count); }

    当然你想添加多个header参数也是可以的，写法也很简单

    1 2 3 4 5 6 7 8 9 10 public interface BlueService { @Headers({ "Accept: application/vnd.yourapi.v1.full+json", "User-Agent: Your-App-Name" }) @GET("book/search") Call<BookSearchResponse> getSearchBooks(@Query("q") String name, @Query("tag") String tag, @Query("start") int start, @Query("count") int count); }

    此外也可以通过Interceptor来定义静态请求头

    1 2 3 4 5 6 7 8 9 10 11 12 public class RequestInterceptor implements Interceptor { @Override public Response intercept(Chain chain) throws IOException { Request original = chain.request(); Request request = original.newBuilder() .header("User-Agent", "Your-App-Name") .header("Accept", "application/vnd.yourapi.v1.full+json") .method(original.method(), original.body()) .build(); return chain.proceed(request); } }

    添加header参数Request提供了两个方法，一个是header(key, value)，另一个是.addHeader(key, value)，两者的区别是，header()如果有重名的将会覆盖，而addHeader()允许相同key值的header存在

    然后在OkHttp创建Client实例时，添加RequestInterceptor即可

    1 2 3 4 5 6 private static OkHttpClient getNewClient(){ return new OkHttpClient.Builder() .addInterceptor(new RequestInterceptor()) .connectTimeout(DEFAULT_TIMEOUT, TimeUnit.SECONDS) .build(); }

    动态方法

    1 2 3 4 5 6 7 public interface BlueService { @GET("book/search") Call<BookSearchResponse> getSearchBooks( @Header("Content-Range") String contentRange, @Query("q") String name, @Query("tag") String tag, @Query("start") int start, @Query("count") int count); }

    2. 网络请求日志

    调试网络请求的时候经常需要关注一下请求参数和返回值，以便判断和定位问题出在哪里，Retrofit官方提供了一个很方便查看日志的Interceptor，你可以控制你需要的打印信息类型，使用方法也很简单。

    首先需要在build.gradle文件中引入logging-interceptor

    1 compile 'com.squareup.okhttp3:logging-interceptor:3.4.1'

    同上文提到的CustomInterceptor和RequestInterceptor一样，添加到OkHttpClient创建处即可，完整的示例代码如下：

    1 2 3 4 5 6 7 8 9 private static OkHttpClient getNewClient(){ HttpLoggingInterceptor logging = new HttpLoggingInterceptor(); logging.setLevel(HttpLoggingInterceptor.Level.BODY); return new OkHttpClient.Builder() .addInterceptor(new CustomInterceptor()) .addInterceptor(logging) .connectTimeout(DEFAULT_TIMEOUT, TimeUnit.SECONDS) .build(); }

    HttpLoggingInterceptor提供了4中控制打印信息类型的等级，分别是NONE，BASIC，HEADERS，BODY，接下来分别来说一下相应的打印信息类型。

    NONE

    没有任何日志信息

    Basic

    打印请求类型，URL，请求体大小，返回值状态以及返回值的大小

    1 2 D/HttpLoggingInterceptor$Logger: --> POST /upload HTTP/1.1 (277-byte body) D/HttpLoggingInterceptor$Logger: <-- HTTP/1.1 200 OK (543ms, -1-byte body)

    Headers

    打印返回请求和返回值的头部信息，请求类型，URL以及返回值状态码

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <-- 200 OK https://api.douban.com/v2/book/search?q=小王子&start=0&count=3&token=tokenValue (3787ms) D/OkHttp: Date: Sat, 06 Aug 2016 14:26:03 GMT D/OkHttp: Content-Type: application/json; charset=utf-8 D/OkHttp: Transfer-Encoding: chunked D/OkHttp: Connection: keep-alive D/OkHttp: Keep-Alive: timeout=30 D/OkHttp: Vary: Accept-Encoding D/OkHttp: Expires: Sun, 1 Jan 2006 01:00:00 GMT D/OkHttp: Pragma: no-cache D/OkHttp: Cache-Control: must-revalidate, no-cache, private D/OkHttp: Set-Cookie: bid=D6UtQR5N9I4; Expires=Sun, 06-Aug-17 14:26:03 GMT; Domain=.douban.com; Path=/ D/OkHttp: X-DOUBAN-NEWBID: D6UtQR5N9I4 D/OkHttp: X-DAE-Node: dis17 D/OkHttp: X-DAE-App: book D/OkHttp: Server: dae D/OkHttp: <-- END HTTP

    Body

    打印请求和返回值的头部和body信息

    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 <-- 200 OK https://api.douban.com/v2/book/search?q=小王子&tag=&start=0&count=3&token=tokenValue (3583ms) D/OkHttp: Connection: keep-alive D/OkHttp: Date: Sat, 06 Aug 2016 14:29:11 GMT D/OkHttp: Keep-Alive: timeout=30 D/OkHttp: Content-Type: application/json; charset=utf-8 D/OkHttp: Vary: Accept-Encoding D/OkHttp: Expires: Sun, 1 Jan 2006 01:00:00 GMT D/OkHttp: Transfer-Encoding: chunked D/OkHttp: Pragma: no-cache D/OkHttp: Connection: keep-alive D/OkHttp: Cache-Control: must-revalidate, no-cache, private D/OkHttp: Keep-Alive: timeout=30 D/OkHttp: Set-Cookie: bid=ESnahto1_Os; Expires=Sun, 06-Aug-17 14:29:11 GMT; Domain=.douban.com; Path=/ D/OkHttp: Vary: Accept-Encoding D/OkHttp: X-DOUBAN-NEWBID: ESnahto1_Os D/OkHttp: Expires: Sun, 1 Jan 2006 01:00:00 GMT D/OkHttp: X-DAE-Node: dis5 D/OkHttp: Pragma: no-cache D/OkHttp: X-DAE-App: book D/OkHttp: Cache-Control: must-revalidate, no-cache, private D/OkHttp: Server: dae D/OkHttp: Set-Cookie: bid=5qefVyUZ3KU; Expires=Sun, 06-Aug-17 14:29:11 GMT; Domain=.douban.com; Path=/ D/OkHttp: X-DOUBAN-NEWBID: 5qefVyUZ3KU D/OkHttp: X-DAE-Node: dis17 D/OkHttp: X-DAE-App: book D/OkHttp: Server: dae D/OkHttp: {"count":3,"start":0,"total":778,"books":[{"rating":{"max":10,"numRaters":202900,"average":"9.0","min":0},"subtitle":"","author":["[法] 圣埃克苏佩里"],"pubdate":"2003-8","tags":[{"count":49322,"name":"小王子","title":"小王子"},{"count":41381,"name":"童话","title":"童话"},{"count":19773,"name":"圣埃克苏佩里","title":"圣埃克苏佩里"} D/OkHttp: <-- END HTTP (13758-byte body)

    3. 为某个请求设置完整的URL

    ​ 假如说你的某一个请求不是以base_url开头该怎么办呢？别着急，办法很简单，看下面这个例子你就懂了

    1 2 3 4 5 6 7 8 9 10 11 public interface BlueService { @GET public Call<ResponseBody> profilePicture(@Url String url); } Retrofit retrofit = Retrofit.Builder() .baseUrl("https://your.api.url/"); .build(); BlueService service = retrofit.create(BlueService.class); service.profilePicture("https://s3.amazon.com/profile-picture/path");

    ​ 直接用@Url注解的方式传递完整的url地址即可。

    4. 取消请求

    Call提供了cancel方法可以取消请求，前提是该请求还没有执行

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 String fileUrl = "http://futurestud.io/test.mp4"; Call<ResponseBody> call = downloadService.downloadFileWithDynamicUrlSync(fileUrl); call.enqueue(new Callback<ResponseBody>() { @Override public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) { Log.d(TAG, "request success"); } @Override public void onFailure(Call<ResponseBody> call, Throwable t) { if (call.isCanceled()) { Log.e(TAG, "request was cancelled"); } else { Log.e(TAG, "other larger issue, i.e. no network connection?"); } } }); } // 触发某个动作，例如用户点击了取消请求的按钮 call.cancel(); }

     

     

    转载请注明原文地址: https://ju.6miu.com/read-156101.html

    技术

    最新回复(0)