Android斬首行動(dòng)接口預(yù)請(qǐng)求問題怎么解決

本篇內(nèi)容介紹了“Android斬首行動(dòng)接口預(yù)請(qǐng)求問題怎么解決”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

前言

開發(fā)同學(xué)應(yīng)該都很熟悉我們頁面的渲染過程一般是從Activity#onCreate開始，再發(fā)起網(wǎng)絡(luò)請(qǐng)求，等請(qǐng)求回調(diào)回來后，再基于網(wǎng)絡(luò)數(shù)據(jù)渲染頁面?？梢杂孟旅孢@幅圖來粗略描述這個(gè)過程：

可以看到，目標(biāo)頁面渲染完成前必須得等待網(wǎng)絡(luò)請(qǐng)求，導(dǎo)致渲染速度并沒有那么快。尤其是當(dāng)網(wǎng)絡(luò)并不好的時(shí)候感受會(huì)更加明顯。并且，當(dāng)目標(biāo)頁面是H5頁面或者是Flutter頁面的時(shí)候，因?yàn)樯婕暗紿5容器與Flutter容器的創(chuàng)建，白屏?xí)r間會(huì)更長。

那么有沒有可能提前發(fā)起請(qǐng)求，來縮短網(wǎng)絡(luò)請(qǐng)求這一部分的等待時(shí)間呢？這就是我們今天要講的部分，接口預(yù)請(qǐng)求。

目標(biāo)

我們要達(dá)到的目標(biāo)很簡單，就是提前異步發(fā)起目標(biāo)頁面的網(wǎng)絡(luò)請(qǐng)求，從而加快目標(biāo)頁面的渲染速度。改善后的過程可以用下圖表示：

并且，我們的預(yù)請(qǐng)求能力需要盡量少地侵入業(yè)務(wù)，與業(yè)務(wù)解耦，并保證能力的通用性，適用于工程內(nèi)的任意頁面（Android頁面、H5頁面、Flutter頁面）。

整體鏈路

首先給大家看一下整體鏈路，具體的細(xì)節(jié)可以先不用去摳，下面會(huì)一一講到。

預(yù)請(qǐng)求時(shí)機(jī)

預(yù)請(qǐng)求時(shí)機(jī)一般有三種選擇：

• 由業(yè)務(wù)層自行選擇時(shí)機(jī)進(jìn)行異步預(yù)請(qǐng)求

• 點(diǎn)擊控件時(shí)進(jìn)行異步預(yù)請(qǐng)求

• 路由最終跳轉(zhuǎn)前進(jìn)行異步預(yù)請(qǐng)求

第1種選擇，由業(yè)務(wù)層自行選擇時(shí)機(jī)進(jìn)行預(yù)請(qǐng)求，需要涉及到業(yè)務(wù)層的改造，以及對(duì)時(shí)機(jī)合理性的把握。一方面是存在改造成本，另一方面是無法保證業(yè)務(wù)側(cè)調(diào)用時(shí)機(jī)的合理性。

第2種選擇，點(diǎn)擊控件時(shí)進(jìn)行預(yù)請(qǐng)求。若點(diǎn)擊時(shí)進(jìn)行預(yù)請(qǐng)求，點(diǎn)擊事件監(jiān)聽并不是業(yè)務(wù)域統(tǒng)一的，無法形成有效封裝。并且，若后續(xù)路由攔截器修改了參數(shù)，或是終止了跳轉(zhuǎn)，這次預(yù)請(qǐng)求就失去了意義。

因此這里我們選擇第3種，基于統(tǒng)一路由框架，在路由最終跳轉(zhuǎn)前進(jìn)行預(yù)請(qǐng)求。既保證了良好的封裝性，也實(shí)現(xiàn)了對(duì)業(yè)務(wù)的零侵入，同時(shí)也做到了懶請(qǐng)求，即用戶必然要發(fā)起該請(qǐng)求時(shí)才會(huì)去預(yù)請(qǐng)求。這里需要注意的是必須是在最終跳轉(zhuǎn)前進(jìn)行預(yù)請(qǐng)求，可以理解為是路由的最后一個(gè)前置異步攔截器。

預(yù)請(qǐng)求規(guī)則配置

我們通過本地的json文件（當(dāng)然，有需要也可以上云通過配置后臺(tái)下發(fā)），對(duì)預(yù)請(qǐng)求的規(guī)則進(jìn)行配置，并將這份配置在App啟動(dòng)階段異步讀入到內(nèi)存。后續(xù)在路由過程中，只有命中了預(yù)請(qǐng)求規(guī)則，才能發(fā)起預(yù)請(qǐng)求。配置demo如下：

{
  "routeConfig":{
    "scheme://domain/path?param1=true&itemId=123":["prefetchKey"],
    "route2":["prefetchKey2"],
    "route3":["prefetchKey3","prefetchKey4"]
  },
  "prefetcher":{
    "prefetchKey":{
      "prefetchType":"network",
      "prefetchInfo":{
        "api":"network.api.name",
        "apiVersion":"1.0",
        "method":"post",
        "needLogin":"false",
        "showLoginUI":"false",
        "params": {
          "itemId":"$route.itemId",
          "firstTime":"true"
        },
        "headers": {
          
        },
        "prefetchImgInResponse": [
          {
            "imgUrl":"$data.imgData.img",
            "imgWidth":"$data.imgData.imgWidth",
            "imgHeight":150
          }
        ]
      }
    },
    "prefetchKey2":{
      "prefetchType":"network",
      "prefetchInfo":{
        "api":"network.api.name2",
        "apiVersion":"1.0",
        "method":"post",
        "needLogin":"false",
        "showLoginUI":"false",
        "params": {
          "itemId":"$route.productId",
          "firstTime":"false"
        },
        "headers": {
          
        }
    },
    "prefetchKey3":{
      "prefetchType":"image",
      "prefetchInfo":{
        "imgUrl":"$route.imgUrl",
        "imgWidth":"$route.imgWidth",
        "imgHeight": 150
      }
    },
    "prefetchKey4":{
      "prefetchInfo":{}
    }
  }
}

規(guī)則解讀

舉例說明

網(wǎng)絡(luò)預(yù)請(qǐng)求

例如跳轉(zhuǎn)目標(biāo)頁面，它的路由是scheme://domain/path?param1=true&itemId=123。

首先我們?cè)谔D(zhuǎn)路由時(shí)，若跳轉(zhuǎn)的路由是這個(gè)目標(biāo)頁面，我們就會(huì)嘗試去發(fā)起預(yù)請(qǐng)求。根據(jù)上面的demo配置文件，它將匹配到prefetchKey這個(gè)預(yù)請(qǐng)求。

那么我們?cè)敿?xì)看prefetchKey這個(gè)預(yù)請(qǐng)求，預(yù)請(qǐng)求類型prefetchType為network，是一個(gè)網(wǎng)絡(luò)預(yù)請(qǐng)求，prefetchInfo中具備了請(qǐng)求的基本參數(shù)（如apiName、apiVersion、method、請(qǐng)求params與請(qǐng)求headers，不同工程不一樣，大家可以根據(jù)自己的工程項(xiàng)目進(jìn)行修改）。具體看params中，有一個(gè)參數(shù)為itemId:$route.itemId。以$route.開頭的意思，就是這個(gè)value值要從路由中獲取，即itemId=123，那么這個(gè)值就是123。

圖片預(yù)請(qǐng)求

在做網(wǎng)絡(luò)預(yù)請(qǐng)求的過程中，我忽然想到圖片做預(yù)請(qǐng)求也是可以大大提升用戶體驗(yàn)的，尤其是當(dāng)大圖片首次下載到內(nèi)存中渲染需要的時(shí)間會(huì)比較長。圖片預(yù)請(qǐng)求分為url已知與url未知兩種場景，下面各舉兩個(gè)例子。

圖片url已知

什么是圖片url已知呢？比如我們?cè)谑醉撎D(zhuǎn)首頁的二級(jí)頁面時(shí)，如果二級(jí)頁面需要預(yù)加載的圖片跟首頁的某張圖是一樣的（尺寸可能不同），那么首頁跳轉(zhuǎn)路由時(shí)我們是能夠提前知道這個(gè)圖片的url的，所以我們看到prefetchKey3中配置了prefetchType為image的預(yù)請(qǐng)求。image的信息來自于路由參數(shù)，需要在跳轉(zhuǎn)時(shí)將圖片url和寬高作為路由參數(shù)之一。

比如scheme://domain/path?imgUrl=${encodeUrl}&imgWidth=200，那么根據(jù)配置項(xiàng)，我們將提前將encodeUrl這個(gè)圖片以寬200，高150的尺寸，加載到內(nèi)存中去。當(dāng)目標(biāo)頁面用到這個(gè)圖片時(shí)，將能很快渲染出來。

圖片url未知

相反，當(dāng)跳轉(zhuǎn)目標(biāo)頁面時(shí)，目標(biāo)頁面所要加載的圖片url沒法取到，就對(duì)應(yīng)了圖片url未知的場景。

例如閃屏頁跳轉(zhuǎn)首頁時(shí)，如果需要預(yù)加載首頁頂部的圖片，此時(shí)閃屏頁是無法獲取到圖片的url的，因?yàn)檫@個(gè)圖片url是首頁接口返回的。這種情況下，我們只能依賴首頁的預(yù)請(qǐng)求進(jìn)行。

在demo配置文件中，我們可以看到prefetchImgFromResponse字段。這個(gè)字段代表著，當(dāng)這個(gè)預(yù)請(qǐng)求響應(yīng)回來之后，我需要去預(yù)請(qǐng)求某張圖片。其中，imgUrl是$data.param格式，以$data.開頭，代表著這份數(shù)據(jù)是來自于響應(yīng)數(shù)據(jù)的。響應(yīng)數(shù)據(jù)就是一串json串，可以憑此，索引到預(yù)請(qǐng)求響應(yīng)中圖片url的位置，就能實(shí)現(xiàn)圖片的提前加載了。

至于圖片怎么提前加載到內(nèi)存中，以及真實(shí)圖片的加載怎么匹配到內(nèi)存中的圖片，這一部分是通過glide已有的preload機(jī)制實(shí)現(xiàn)的，感興趣的同學(xué)可以去看一下源碼了解一下，這里就不展開了。后面講的預(yù)請(qǐng)求的方案細(xì)節(jié)，都只限于網(wǎng)絡(luò)請(qǐng)求。

預(yù)請(qǐng)求匹配

預(yù)請(qǐng)求匹配指的是實(shí)際的業(yè)務(wù)請(qǐng)求怎樣與已經(jīng)執(zhí)行的預(yù)請(qǐng)求匹配上，從而節(jié)省請(qǐng)求的空中時(shí)間，直接返回預(yù)請(qǐng)求的結(jié)果。

首先網(wǎng)絡(luò)預(yù)請(qǐng)求執(zhí)行前先在內(nèi)存中生成一份PrefetchRecord，代表著已經(jīng)執(zhí)行的預(yù)請(qǐng)求，其中的字段跟配置文件中差不多，主要就是記錄預(yù)請(qǐng)求相關(guān)的信息：

class PrefetchRecord {
    // 請(qǐng)求信息
    String api;
    String apiVersion;
    String method;
    String needLogin;
    String showLoginUI;
    JSONObject params;
    JSONObject headers;

    // 預(yù)請(qǐng)求狀態(tài)
    int status;
    // 預(yù)請(qǐng)求結(jié)果
    ResponseModel response;
    // 生成的請(qǐng)求id
    String requestId;

    boolean isMatch(RealRequest realRequest) {
        requestId.equals(realRequest.requestId)
    }
}

每一個(gè)PrefetchRecord生成時(shí)，都會(huì)生成一個(gè)requestId，用于跟實(shí)際業(yè)務(wù)請(qǐng)求進(jìn)行匹配。requestId的生成規(guī)則可以自行制定，比如將所有請(qǐng)求信息包一起做一下md5處理之類。

在實(shí)際業(yè)務(wù)請(qǐng)求發(fā)起之前，也會(huì)根據(jù)同樣的規(guī)則生成requestId。若內(nèi)存中存在相同requestId對(duì)應(yīng)的PrefetchRecord，那么就相當(dāng)于匹配成功了。匹配成功后，再根據(jù)預(yù)請(qǐng)求的狀態(tài)進(jìn)行進(jìn)一步的處理。

預(yù)請(qǐng)求狀態(tài)

預(yù)請(qǐng)求狀態(tài)分為START、FINISH、ABORT，對(duì)應(yīng)“正在發(fā)起預(yù)請(qǐng)求”、“已經(jīng)獲得預(yù)請(qǐng)求結(jié)果”、“預(yù)請(qǐng)求被拋棄”。ABORT狀態(tài)下一節(jié)再講。

為什么要記錄這個(gè)狀態(tài)呢？因?yàn)槲覀儫o法保證，預(yù)請(qǐng)求的響應(yīng)一定在實(shí)際請(qǐng)求之前。用圖來表示：

因?yàn)轭A(yù)請(qǐng)求是一個(gè)并發(fā)行為。當(dāng)預(yù)請(qǐng)求的空中時(shí)間特別長，長到目標(biāo)頁面已經(jīng)發(fā)出實(shí)際請(qǐng)求了，預(yù)請(qǐng)求的響應(yīng)還沒回來，即預(yù)請(qǐng)求狀態(tài)為START，而非FINISH。那么此時(shí)該怎么辦？我們就需要讓實(shí)際請(qǐng)求在一旁等著（記錄到內(nèi)存中，RealRequestRecord），等預(yù)請(qǐng)求接收到響應(yīng)了，再根據(jù)requestId去進(jìn)行匹配，匹配到RealRequestRecord了，就觸發(fā)RealRequestRecord中的回調(diào)，返回?cái)?shù)據(jù)。

另外，在匹配過程中需要注意一點(diǎn)，因?yàn)槊看温酚商D(zhuǎn)，如果發(fā)起預(yù)請(qǐng)求了，總會(huì)生成一個(gè)Record在內(nèi)存中等待匹配。因此在匹配結(jié)束后，不管是匹配成功還是匹配失敗，都要及時(shí)釋放將Record從內(nèi)存中釋放掉。

超時(shí)重試機(jī)制

基于實(shí)際請(qǐng)求等待預(yù)請(qǐng)求響應(yīng)的場景，我們?cè)傺由煲幌?。若預(yù)請(qǐng)求請(qǐng)求超時(shí)，遲遲拿不到響應(yīng)，該怎么辦？用圖表示：

假設(shè)目前的網(wǎng)絡(luò)請(qǐng)求，端上默認(rèn)的超時(shí)時(shí)間是30s。那么在超時(shí)場景下，實(shí)際的業(yè)務(wù)請(qǐng)求在30s內(nèi)若拿不到預(yù)請(qǐng)求的結(jié)果，就需要重新發(fā)起業(yè)務(wù)請(qǐng)求，拋棄預(yù)請(qǐng)求，并將預(yù)請(qǐng)求的狀態(tài)置為ABORT，這樣即使后面預(yù)請(qǐng)求響應(yīng)回來了也不做任何處理。

忽然想到一個(gè)很貼切的場景來比喻這個(gè)預(yù)請(qǐng)求方案。

我們把跳轉(zhuǎn)頁面理解為去柜臺(tái)取餐。

預(yù)請(qǐng)求代表著我們?nèi)诉€沒到柜臺(tái)，就先遠(yuǎn)程下單讓柜員去準(zhǔn)備食物。

如果柜員準(zhǔn)備得比較快，那么我們到柜臺(tái)后就能直接把食物拿走了，就能快點(diǎn)吃上了（代表著頁面渲染速度變快）。

如果柜員準(zhǔn)備得比較慢，那么我們到柜臺(tái)后還是得等一會(huì)兒才能取餐，但總體上吃上食物的速度還是要比到柜臺(tái)后再點(diǎn)餐來得快。

但如果這個(gè)柜員消極怠工準(zhǔn)備得太慢了，我們到柜臺(tái)等了很久都沒拿到食物，那么我們就只能換個(gè)柜員重新點(diǎn)了（超時(shí)后發(fā)起實(shí)際的業(yè)務(wù)請(qǐng)求），同時(shí)還不忘投訴一把（預(yù)請(qǐng)求空中時(shí)間太慢了）。

“Android斬首行動(dòng)接口預(yù)請(qǐng)求問題怎么解決”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！