Android 息屏網(wǎng)絡請求失敗問題簡單總結

短信攔截APP，正常情況下網(wǎng)絡請求正常，息屏情況下網(wǎng)絡請求失敗（錯誤信息提示： W/IInputConnectionWrapper: showStatusIcon on inactive InputConnection 、 Failed to connect to /XXX 等）

從網(wǎng)站建設到定制行業(yè)解決方案，為提供網(wǎng)站設計、成都網(wǎng)站設計服務體系，各種行業(yè)企業(yè)客戶提供網(wǎng)站建設解決方案，助力業(yè)務快速發(fā)展。成都創(chuàng)新互聯(lián)公司將不斷加快創(chuàng)新步伐，提供優(yōu)質的建站服務。

以測試機紅米3為例：

1.設置-WLAN-高級設置-在休眠狀態(tài)下保持WLan 網(wǎng)絡連接（始終）；

2.設置-電能和性能-省電優(yōu)化-應用智能省電-選擇要被設置的應用-選擇無限制；

Android 網(wǎng)路請求列表返回邏輯處理

我們在網(wǎng)絡請求時，總有分頁加載等，處理業(yè)務邏輯也是比較混亂的，容易出現(xiàn)各種Bug，下面我這種模式用了很久，記錄一下，有任何問題，歡迎指正。

采用 SmartRefreshLayout框架，下拉刷新采用autoRefresh()，上拉加載更多是根據(jù)addOnScrollListener（）自定義寫的。

注意：什么時候加載更多，完全可以自定義。 （本文是滑動到數(shù)據(jù)一半，開始加載更多。）

1、開始請求數(shù)據(jù)

2、加載更多請求

3、數(shù)據(jù)請求完成處理：

4、布局的顯示和隱藏：

采用 SmartRefreshLayout框架，下拉刷新采用autoRefresh()，上拉加載更多采用setEnableAutoLoadMore（）。

注意：setEnableAutoLoadMore（）只有滑到底部才會加載第二頁。

完美解決Android 9.0以上HTTP網(wǎng)絡請求被限制問題

Android P 9.0以上系統(tǒng)，HTTP網(wǎng)絡被限制。HTTPS無影響。

Android 10系統(tǒng)同樣的問題。

Android P以上要求網(wǎng)絡請求必須為Https，Http請求會拋異常。

??Android P以上的應用默認都被限制了明文流量的網(wǎng)絡請求，非加密的流量請求都會被系統(tǒng)禁止掉。同時，目標API級別為27或更低的應用程序的默認值為“ true”。面向API級別28或更高級別的應用默認為“ false”。

需要在AndroidManifest.xml文件中設置：

??android：usesCleartextTraffic 指示應用程序是否打算使用明文網(wǎng)絡流量，例如明文HTTP。

忽略證書，可以使用明文流量訪問，httpshttp都可以訪問。

??避免明文通信的主要原因是缺乏機密性，真實性和防篡改保護；網(wǎng)絡攻擊者可以竊聽所傳輸?shù)臄?shù)據(jù)，并且還可以對其進行修改而不會被檢測到。

別忘記在Android.Manifest.xml文件中添加網(wǎng)絡訪問權限哦！

Android網(wǎng)絡請求庫【OkHttp4.9.3】基本用法與原理分析

OkHttp是一套處理 HTTP 網(wǎng)絡請求的依賴庫，由 Square 公司設計研發(fā)并開源，目前可以在 Java 和 Kotlin 中使用。對于 Android App 來說，OkHttp 現(xiàn)在幾乎已經(jīng)占據(jù)了所有的網(wǎng)絡請求操作，Retrofit + OkHttp實現(xiàn)網(wǎng)絡請求似乎成了一種標配。因此它也是每一個 Android 開發(fā)工程師的必備技能，了解其內部實現(xiàn)原理可以更好地進行功能擴展、封裝以及優(yōu)化。

OkHttp的高效性體現(xiàn)在：

第一步：創(chuàng)建OkHttpClient，創(chuàng)建OkHttpClient有兩種方式：

OkHttpClient提供了豐富的配置方法，例如添加攔截器、指定連接池、設置請求超時等等。

第二步：創(chuàng)建請求

使用Request.Builder() 構建Request實例

第三步：發(fā)起網(wǎng)絡請求

OkHttp支持同步和異步兩種請求方式

OkHttp的使用方法非常簡單，三步操作就可以發(fā)起一個簡單的同步或異步請求。我們也可以很輕松地對網(wǎng)絡請求進行配置，例如添加請求頭、設置請求方式、設置請求超時等等，這些配置參數(shù)會在源碼分析過程中詳細介紹。

現(xiàn)在我們已經(jīng)學會了三步操作發(fā)起網(wǎng)絡請求，接下來以這三個步驟為切入點，深入到源碼中學習OkHttp的實現(xiàn)原理，廢話少說馬上開車。

OkHttpClient創(chuàng)建方式有兩種，我們看看兩種方式有什么區(qū)別。

第一種直接使用默認構造函數(shù)，內部依然是使用建造者模式

第二種使用建造者模式

兩種方式最終都是調用構造函數(shù)OkHttpClient(builder:Builder)，由參數(shù)builder負責所有的參數(shù)配置工作。

當您創(chuàng)建單個OkHttpClient實例并將其用于所有 HTTP 調用時，OkHttp 性能最佳。 這是因為每個OkHttpClient都擁有自己的連接池和線程池，重用連接和線程可減少延遲并節(jié)省內存。 相反，為每個請求創(chuàng)建一個客戶端會浪費空閑池上的資源。

Request同樣使用建造者模式來創(chuàng)建，這里貼上部分重要源碼，很簡單就不細說了。

OkHttp發(fā)起網(wǎng)絡請求分為同步請求和異步請求兩種方式，我們只分析異步請求流程，因為只要理解了異步請求過程，基本上也就明白同步請求是怎么一回事了。

RealCall是連接應用層與網(wǎng)絡層的橋梁，負責處理連接、請求、響應和數(shù)據(jù)流。

Dispatcher維護著一套異步任務執(zhí)行策略，分析策略之前先介紹幾個重要概念：

client.dispatcher.enqueue(AsyncCall(responseCallback)) 執(zhí)行步驟為：

AsyncCall實現(xiàn)了Runnable接口，因此一旦被線程池中的線程處理就會調用它的run()方法：

話休絮煩，我們開始分析攔截器責任鏈：

責任鏈執(zhí)行流程：首先獲取當前攔截器interceptor，并且調用interceptor.intercept(next)執(zhí)行攔截器操作。這里的next表示的是index+1后的責任鏈對象，攔截器的intercept()方法內部會調用next.proceed(request)方法再次進入到責任鏈，由于此時index已經(jīng)加1，所以處理的是下一個攔截器。

如此循環(huán)往復，直到處理完責任鏈上最后一個攔截器為止。

注意除最后一個攔截器CallServerInterceptor不會調用chain.proceed(request)方法之外，其他攔截器都應該至少調用一次chain.proceed(request)方法。

為了驗證上面的結論，我們進入到RetryAndFollowUpInterceptor的intercept()方法一探究竟：

可以看到注釋1處重新進入責任鏈處理下一個攔截器。

有興趣可以自行查看最后一個攔截器CallServerInterceptor源碼，此處只給出本人閱讀源碼后得出的結論：

以上就是攔截器責任鏈的工作流程，我們再通過流程圖仔細感受一下。

分析完攔截器責任鏈，我們繼續(xù)分析AsyncCall#run()方法：

我們看到，如果getResponseWithInterceptorChain()方法成功獲得服務端返回的數(shù)據(jù)，則調用responseCallback.onResponse(this@RealCall, response)方法完成異步回調；如果服務端數(shù)據(jù)獲取失敗（請求異常），則調用responseCallback.onFailure(this@RealCall, canceledException)方法完成異步回調

需要注意的是，responseCallback回調是在子線程中完成的，所以如果想把數(shù)據(jù)顯示到UI上，需要切換回主線程進行UI操作。

OkHttp發(fā)起網(wǎng)絡請求全過程：

【知識點】OkHttp 原理 8 連問

Android 9.0 無法請求網(wǎng)絡問題

手機版本升級到9.0后，發(fā)現(xiàn)App一直請求網(wǎng)絡失敗，特奇怪...以為是手機出毛病了，后來發(fā)現(xiàn)原來是android 9.0系統(tǒng)已經(jīng)默認不支持http請求了，這個可以讓后臺改成https就行，不過我們還是沒解決我們移動端的問題。目前有兩個方法處理：

1.把targetSdkVersion 改成27或者以下

2.在res目錄添加一個xml文件夾和network_security_config.xml：

xml內容是：

然后再在AndroidManifest.xml的application里加入

這樣就行了。

Android網(wǎng)絡請求知識（三）授權，TCP/IP，HTTPS建立過程

由身份或持有的令牌確認享有的權限，登錄過程實質上的目的也是為了確認權限。

Cookie是客戶端給服務器用的，setCookie是服務器給客戶端用的。cookie由服務器處理，客戶端負責存儲

客戶端發(fā)送cookie：賬戶和密碼

服務端收到后確認登錄setCookie：sessionID=1，記下sessionID

客戶端收到sessionID后記錄，以后請求服務端帶上對比記錄下sessionID，說明已經(jīng)登錄

會話管理：登錄狀態(tài)，購物車

個性化：用戶偏好，主題

Tracking：分析用戶行為

XXS：跨腳本攻擊，及使用JavaScript拿到瀏覽器的cookie之后，發(fā)送到自己的網(wǎng)站，以這種方式來盜用用戶Cookie。Server在發(fā)送Cookie時，敏感的Cookie加上HttpOnly，這樣Cookie只能用于http請求，不能被JavaScript調用

XSRF:跨站請求偽造。Referer 從哪個網(wǎng)站跳轉過來

兩種方式：Basic和Bearer

首先第三方網(wǎng)站向授權網(wǎng)站申請第三方授權合作，拿到授權方頒發(fā)的client_id和client_secret（一般都是appid+appkey的方式）。

在這就過程中申請的client_secret是服務器持有的，安全起見不能給客戶端，用服務端去和授權方獲取用戶信息，再傳給客戶端，包括④，⑤的請求過程也是需要加密的。這才是標準的授權過程。

有了access_token之后，就可以向授權方發(fā)送請求來獲取用戶信息

步驟分析就是上面的內容，這里把第4,6,8請求的參數(shù)分析一下

第④步參數(shù)：

response_type：指授權類型，必選，這里填固定值‘code’

client_id：指客戶端id，必選，這里填在平臺報備時獲取的appid

redirect_uri：指重定向URI，可選

scope：指申請的權限范圍，可選

state：指客戶端當前狀態(tài)，可選，若填了，則認證服務器會原樣返回該值

第⑥步參數(shù)：

grant_type：指使用哪種授權模式，必選，這里填固定值‘a(chǎn)uthorization_code’

code：指從第⑤步獲取的code，必選

redirect_uri：指重定向URI，必選，這個值需要和第④步中的redirect_uri保持一致

client_id：指客戶端id，必選，這里填在平臺報備時獲取的appid

client_secret：指客戶端密鑰，必選，這里填在平臺報備時獲取的appkey

第⑧步參數(shù)：

access_token：指訪問令牌，必選，這里填第⑦步獲取的access_token

token_type：指令牌類型，必選，大小寫不敏感，bearer類型 / mac類型

expires_in：指過期時間，單位秒，當其他地方已設置過期時間，此處可省略該參數(shù)

refresh_token：指更新令牌，可選，用即將過期token換取新token

scope：指權限范圍，可選，第④步中若已申請過某權限，此處可省略該參數(shù)

我們在上面的第八步中會有refresh_token的參數(shù)，這個在實際操作中也比較常見

有時候我們在自己的項目中，將登陸和授權設計成類似OAuth2的過程，不過去掉Authorization code。登陸成功返回access_token，然后客戶端再請求時，帶上access_token。

我們常常會說到TCP/IP，那到底是什么呢。這就需要講到網(wǎng)絡分層模型。TCP在傳輸層，IP在網(wǎng)絡層。那為什么需要分層？因為網(wǎng)絡不穩(wěn)定，導致需要重傳的問題。為了提高傳輸效率我們就需要分塊，在傳輸層中就會進行分塊。TCP還有兩個重要的內容就是三次握手，四次分手。

HTTPS 協(xié)議是由 HTTP 加上TLS/SSL協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，主要通過數(shù)字證書、加密算法、非對稱密鑰等技術完成互聯(lián)網(wǎng)數(shù)據(jù)傳輸加密，實現(xiàn)互聯(lián)網(wǎng)傳輸安全保護

1.客戶端通過發(fā)送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件列表（所使用的加密算法及密鑰長度），客戶端隨機數(shù)，hash算法。

2.服務器可進行SSL通信時，會以Server Hello報文作為應答。和客戶端一樣，在報文中包含SSL版本以及加密組件，服務端隨機數(shù)。服務器的加密組件內容是從接收到客戶端加密組件內篩選出來的。

3.之后服務器發(fā)送Certificate報文。報文中包含公開密鑰證書。一般實際有三層證書嵌套，其實像下面圖二直接用根證書機構簽名也是可以的，但是一般根證書機構比較忙，需要類似中介的證書機構來幫助。

4.最后服務器發(fā)送Server Hello Done報文通知客戶端，最初階段的SSL握手協(xié)商部分結束。

5.SSL第一次握手結束后，客戶端以Client Key Exchange報文作為回應。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。

6.接著客戶端繼續(xù)發(fā)送Change Cipher Spec報文。該報文會提示服務器，在此報文之后的通信會采用Pre-master secret密鑰加密。

7.客戶端發(fā)送Finished報文。該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功，要以服務器是否能夠正確解密報文作為判定標準。

8.服務器同樣發(fā)送Change Cipher Spec報文。

9.服務器同樣發(fā)送Finished報文。

10.服務器和客戶端的Finished報文交換完畢之后，SSL連接就算建立完成。當然，通信會受到SSL的保護。從此處開始進行應用層協(xié)議的通信，即發(fā)送HTTP響應。

11.應用層協(xié)議通信，即發(fā)送HTTP響應。

12.最后由客戶端斷開連接。斷開連接時，發(fā)送close_notify報文。這步之后再發(fā)送TCP FIN報文來關閉與TCP的通信。

利用客戶端隨機數(shù)，服務端隨機數(shù)，per-master secret隨機數(shù)生成master secret，再生成客戶端加密密鑰，服務端加密密鑰，客戶端MAC secert，服務端MAC secert。MAC secert用于做報文摘要，這樣能夠查知報文是否遭到篡改，從而保護報文的完整性。

Android網(wǎng)絡請求知識（一）HTTP基礎概念

Android網(wǎng)絡請求知識（二）對稱和非對稱加密、數(shù)字簽名，Hash，Base64編碼

Android網(wǎng)絡請求知識（三）授權，TCP/IP，HTTPS建立過程

網(wǎng)頁名稱：android網(wǎng)絡請求,android網(wǎng)絡請求失敗 如何重試
新聞來源：http://chinadenli.net/article49/dsechhh.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、網(wǎng)站設計、定制網(wǎng)站、網(wǎng)站內鏈、網(wǎng)站營銷、關鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)