簡介
今天早上收到一個用戶的反饋睹酌，說我們公司的APP在他手機上 上不了網侯养，但是手機上的其它APP都可以正常上網，而且在設置中也已經允許該設備上網了鲸鹦，很是奇怪慧库，結果到網上搜了下，不少人都遇到過這個問題馋嗜，感覺這篇文章寫得挺好齐板，收錄在這里，以方便日后查看：
尊重版權葛菇，請閱讀原文
癥狀
iOS 10 之后甘磨，陸陸續(xù)續(xù)地有用戶聯(lián)系我們，說新機第一次安裝眯停、第一次啟動的時候济舆，app 首屏一片空白，完全沒數據莺债。kill 掉重新打開就好了滋觉。
一開始以為是用戶網絡情況不好，但隨著越來越多的用戶報告這個問題齐邦，我意識到這并不是偶然情況椎侠。但是并非所有用戶都如此。
而且卸載掉之后措拇，如果再裝我纪，也不會出現(xiàn)這現(xiàn)象。問題只會出現(xiàn)在這臺設備第一次安裝丐吓、第一次啟動的情況下宣羊。如果把手機抹掉、重置汰蜘，問題還能重現(xiàn)。
定位問題
這個問題真的很棘手之宿，也很難定位族操。幸運的是，公司同事想到把手機抹掉重置比被，得以在我眼前重現(xiàn)問題色难。
我發(fā)現(xiàn)的是，app 首次啟動會彈出一個詢問用戶“是否允許應用訪問數據”的彈框等缀，類似下圖：
詢問網絡權限的彈框
雖然 app 剛打開的時候是一片空白枷莉，但我發(fā)現(xiàn)進去之后，登錄尺迂、下拉刷新等都沒問題笤妙。因此很容易猜測出這樣的結論：用戶點“允許”之前冒掌，網絡請求全都是失敗的；而點“允許”之后蹲盘，網絡請求就能正常進行了股毫。
問題原因
有了方向之后就好查了。很快查到了掘金的這篇文章召衔，得知這個彈框來自于工信部的要求铃诬。這篇文章里還有如果彈框不出現(xiàn)，用戶可以采取的解決方案苍凛。另外趣席，從少數派的這篇文章 看到，只有國行手機有這個功能醇蝴。這也就解釋了為何有些用戶出現(xiàn)宣肚、而有些用戶沒出現(xiàn)這個問題。
蜂窩移動網絡的兩種界面
進到手機的 設置->蜂窩移動網絡哑蔫，如果看到如左圖就說明是不會彈框的機型钉寝，如果看到如右圖，說明是會彈框的機型闸迷。
那么這個新功能會為用戶帶來哪些問題呢嵌纲？問題主要在于，用戶點擊“允許”之前腥沽，所有網絡請求都是被禁止的逮走。具體有兩種表現(xiàn)：
少部分用戶根本不顯示彈框，所以網絡請求一直被禁止今阳。針對這部分用戶师溅，只能通過客服引導，按照的這篇文章盾舌，逐個嘗試里面的解決方案墓臭；
對于絕大部分用戶，彈框會正確顯示妖谴；然而從 app 啟動到用戶點擊“允許”需要一段時間窿锉，在這段時間內發(fā)出的網絡請求全都會直接失敗膝舅；
如果用戶點擊“不允許”嗡载，app 永遠無法訪問網絡，Wifi 和數據流量均不可以仍稀。當然洼滚，這是用戶自己的選擇，我們沒什么可做的技潘。我們主要需要解決的是上面的第二個問題遥巴。
影響范圍
這個特性推出之后千康，大部分 app 應該都會受到不同程度的影響∨埠澹可以著重在這幾個方面檢查一下自己的 app：
首屏數據吧秕。首屏幾個 tab 的數據往往在 app 啟動時即加載，也就是在用戶點“允許”之前迹炼。很容易造成用戶第一次進入時砸彬，首屏數據空白。
推送斯入。通常的處理邏輯是砂碉，把注冊設備遠程推送的代碼寫在 appDelegate 里。經過測試發(fā)現(xiàn)刻两，這種寫法下允許推送的彈框和允許使用網絡的彈框出現(xiàn)的順序沒有一定增蹭。如果先出允許推送的彈框，用戶點擊允許磅摹，此時注冊 deviceToken 是不能成功的滋迈。當然如果用戶允許訪問網絡，第二次打開 app 時也會走一遍注冊遠程推送方法户誓，此時就能注冊成功了饼灿。
其他首次啟動的處理。諸如廣告頁帝美、活動頁之類碍彭，需要在啟動時請求的數據。新版本的更新檢查往往也在啟動時進行悼潭，但這一點影響不大庇忌，因為首次打開的用戶一般都是處于最新版。另外舰褪，常常會在新設備首次啟動時皆疹，上傳一個設備唯一標識用于統(tǒng)計目的，例如 IDFA占拍。
解決方案
在重置過的手機上墙基，嘗試裝了一些大大小小的 app，發(fā)現(xiàn)不少 app 在適配這個新特性上都存在一些小問題刷喜。而有些 app 也做了比較有特色的處理。
不幸的是立砸，蘋果這個功能可能出得太倉促掖疮，并沒有給開發(fā)者提供相應的 API。所以颗祝，我們沒辦法檢測到用戶點擊“允許”或“不允許”網絡請求的回調浊闪，也沒法檢測到當前用戶是否授權的狀態(tài)恼布。只能通過一些特殊處理，來盡量減小對用戶的影響搁宾。
總體來說折汞，主要有如下幾個解決方案：
延遲請求。對于首次啟動的所有接口盖腿，如果能延遲到用戶點擊“允許”之后再請求爽待，或者重新請求一次，就能把對用戶的影響降到最低翩腐，是一個比較好的解決方案鸟款。因為首次啟動往往有幾屏引導頁，一個比較好的時機是引導頁結束時茂卦。此時用戶已經進行了授權何什，數據都能正確得到。所以我自己的做法是把請求推遲到了引導頁等龙。另外下面評論里饒志臻大神提了一個特別好的思路处渣，就是用 AFN 監(jiān)聽網絡狀態(tài)，有網時開始請求蛛砰。雖然沒有試過（我自己手機不是國行罐栈，不太好實驗），但感覺應該也能比較完美地處理這個問題暴备。
允許用戶手動重新請求悠瞬。出現(xiàn)數據空白時，如果在空白頁面上有“重新加載”的按鈕涯捻，也可以讓用戶體驗好一些浅妆。比較有趣的是，測試中發(fā)現(xiàn)網易嚴選的處理是這樣的：
加了一個“查看解決方案”的按鈕障癌。點擊這個按鈕會跳轉到一個描述解決方案的頁面凌外，內容跟上面掘金的文章類似。很有意思的處理涛浙，雖然不能避免白屏康辑，但用戶會嘗試重新打開，還可以幫到少部分始終不顯示彈框的用戶轿亮。
- 稍后重新請求疮薇。網絡框架如果做了請求失敗時，定時重新請求的處理我注，應該也能解決首次請求失敗的問題按咒。另外，首次啟動時各種處理的邏輯都可以寫成一旦失敗但骨，下次啟動重試励七。如每次啟動都會注冊遠程推送智袭。另一個例子是上傳設備唯一標識的邏輯，可以寫成類似這樣：
NSString *storedIDFA = [[NSUserDefaults standardUserDefaults] objectForKey:kIDFAKey];
NSString *idfaString = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];
if ([storedIDFA isEqualToString:idfaString]) {
return;
}
[HAMCommonBusinessStore requestUploadIDFA:idfaString success:^(id response) {
[[NSUserDefaults standardUserDefaults] saveObject:idfaString forKey:kIDFAKey];
}];
每次打開 app 都調用這段代碼掠抬，而上傳成功時才保存到本地吼野。這樣首次請求失敗也無妨，下次打開時仍能重試上傳两波，直到成功為止瞳步。
