原文 ?iOS 10 的坑：新機首次安裝 app统捶，請求網(wǎng)絡(luò)權(quán)限“是否允許使用數(shù)據(jù)”
這個坑最近弄得我很抓狂，不過現(xiàn)在基本弄清楚了柄粹。記錄一下過程中我收集到的信息喘鸟，分享給大家。
癥狀
iOS 10 之后驻右，陸陸續(xù)續(xù)地有用戶聯(lián)系我們什黑，說新機第一次安裝、第一次啟動的時候堪夭，app 首屏一片空白愕把，完全沒數(shù)據(jù)。kill 掉重新打開就好了森爽。
一開始以為是用戶網(wǎng)絡(luò)情況不好恨豁，但隨著越來越多的用戶報告這個問題，我意識到這并不是偶然情況爬迟。但是并非所有用戶都如此橘蜜。
而且卸載掉之后，如果再裝付呕，也不會出現(xiàn)這現(xiàn)象计福。問題只會出現(xiàn)在這臺設(shè)備第一次安裝、第一次啟動的情況下凡涩。如果把手機抹掉棒搜、重置，問題還能重現(xiàn)活箕。
定位問題
這個問題真的很棘手力麸，也很難定位。幸運的是育韩，公司同事想到把手機抹掉重置克蚂，得以在我眼前重現(xiàn)問題。
我發(fā)現(xiàn)的是筋讨，app 首次啟動會彈出一個詢問用戶“是否允許應(yīng)用訪問數(shù)據(jù)”的彈框埃叭，類似下圖：
詢問網(wǎng)絡(luò)權(quán)限的彈框
雖然 app 剛打開的時候是一片空白，但我發(fā)現(xiàn)進去之后悉罕，登錄赤屋、下拉刷新等都沒問題立镶。因此很容易猜測出這樣的結(jié)論：用戶點“允許”之前，網(wǎng)絡(luò)請求全都是失敗的类早；而點“允許”之后媚媒，網(wǎng)絡(luò)請求就能正常進行了。
問題原因
有了方向之后就好查了涩僻。很快查到了掘金的這篇文章缭召，得知這個彈框來自于工信部的要求。這篇文章里還有如果彈框不出現(xiàn)逆日，用戶可以采取的解決方案嵌巷。另外，從少數(shù)派的這篇文章看到室抽，只有國行手機有這個功能搪哪。這也就解釋了為何有些用戶出現(xiàn)、而有些用戶沒出現(xiàn)這個問題坪圾。
蜂窩移動網(wǎng)絡(luò)的兩種界面
進到手機的 設(shè)置->蜂窩移動網(wǎng)絡(luò)噩死，如果看到如左圖就說明是不會彈框的機型，如果看到如右圖，說明是會彈框的機型。
那么這個新功能會為用戶帶來哪些問題呢皇钞？問題主要在于嘿架，用戶點擊“允許”之前，所有網(wǎng)絡(luò)請求都是被禁止的栅屏。具體有兩種表現(xiàn)：
少部分用戶根本不顯示彈框飘千，所以網(wǎng)絡(luò)請求一直被禁止。針對這部分用戶栈雳，只能通過客服引導(dǎo)护奈，按照掘金的這篇文章，逐個嘗試里面的解決方案哥纫；
對于絕大部分用戶霉旗，彈框會正確顯示；然而從 app 啟動到用戶點擊“允許”需要一段時間蛀骇，在這段時間內(nèi)發(fā)出的網(wǎng)絡(luò)請求全都會直接失斞崦搿；
如果用戶點擊“不允許”擅憔，app 永遠無法訪問網(wǎng)絡(luò)鸵闪，Wifi 和數(shù)據(jù)流量均不可以。當然暑诸，這是用戶自己的選擇蚌讼，我們沒什么可做的辟灰。我們主要需要解決的是上面的第二個問題。
影響范圍
這個特性推出之后篡石，大部分 app 應(yīng)該都會受到不同程度的影響芥喇。可以著重在這幾個方面檢查一下自己的 app：
首屏數(shù)據(jù)夏志。首屏幾個 tab 的數(shù)據(jù)往往在 app 啟動時即加載乃坤，也就是在用戶點“允許”之前。很容易造成用戶第一次進入時沟蔑，首屏數(shù)據(jù)空白湿诊。
推送。通常的處理邏輯是瘦材，把注冊設(shè)備遠程推送的代碼寫在 appDelegate 里厅须。經(jīng)過測試發(fā)現(xiàn)，這種寫法下允許推送的彈框和允許使用網(wǎng)絡(luò)的彈框出現(xiàn)的順序沒有一定食棕。如果先出允許推送的彈框朗和，用戶點擊允許，此時注冊 deviceToken 是不能成功的簿晓。當然如果用戶允許訪問網(wǎng)絡(luò)眶拉，第二次打開 app 時也會走一遍注冊遠程推送方法，此時就能注冊成功了憔儿。
其他首次啟動的處理忆植。諸如廣告頁、活動頁之類谒臼，需要在啟動時請求的數(shù)據(jù)朝刊。新版本的更新檢查往往也在啟動時進行，但這一點影響不大蜈缤，因為首次打開的用戶一般都是處于最新版拾氓。另外，常常會在新設(shè)備首次啟動時底哥，上傳一個設(shè)備唯一標識用于統(tǒng)計目的咙鞍，例如 IDFA。
解決方案
在重置過的手機上趾徽，嘗試裝了一些大大小小的 app奶陈，發(fā)現(xiàn)不少 app 在適配這個新特性上都存在一些小問題。而有些 app 也做了比較有特色的處理附较。
不幸的是吃粒，蘋果這個功能可能出得太倉促，并沒有給開發(fā)者提供相應(yīng)的 API拒课。所以徐勃，我們沒辦法檢測到用戶點擊“允許”或“不允許”網(wǎng)絡(luò)請求的回調(diào)事示，也沒法檢測到當前用戶是否授權(quán)的狀態(tài)。只能通過一些特殊處理僻肖，來盡量減小對用戶的影響肖爵。
總體來說，主要有如下幾個解決方案：
延遲請求臀脏。對于首次啟動的所有接口劝堪，如果能延遲到用戶點擊“允許”之后再請求，或者重新請求一次揉稚，就能把對用戶的影響降到最低秒啦，是一個比較好的解決方案。因為首次啟動往往有幾屏引導(dǎo)頁搀玖，一個比較好的時機是引導(dǎo)頁結(jié)束時余境。此時用戶已經(jīng)進行了授權(quán)，數(shù)據(jù)都能正確得到灌诅。所以我自己的做法是把請求推遲到了引導(dǎo)頁芳来。另外下面評論里饒志臻大神提了一個特別好的思路，就是用 AFN 監(jiān)聽網(wǎng)絡(luò)狀態(tài)猜拾，有網(wǎng)時開始請求即舌。雖然沒有試過（我自己手機不是國行，不太好實驗）挎袜，但感覺應(yīng)該也能比較完美地處理這個問題侥涵。
允許用戶手動重新請求。出現(xiàn)數(shù)據(jù)空白時宋雏，如果在空白頁面上有“重新加載”的按鈕，也可以讓用戶體驗好一些务豺。比較有趣的是磨总，測試中發(fā)現(xiàn)網(wǎng)易嚴選的處理是這樣的：
網(wǎng)易嚴選的首屏界面
加了一個“查看解決方案”的按鈕。點擊這個按鈕會跳轉(zhuǎn)到一個描述解決方案的頁面笼沥，內(nèi)容跟上面掘金的文章類似蚪燕。很有意思的處理，雖然不能避免白屏奔浅，但用戶會嘗試重新打開馆纳，還可以幫到少部分始終不顯示彈框的用戶。
稍后重新請求汹桦。網(wǎng)絡(luò)框架如果做了請求失敗時鲁驶，定時重新請求的處理，應(yīng)該也能解決首次請求失敗的問題舞骆。另外钥弯，首次啟動時各種處理的邏輯都可以寫成一旦失敗径荔，下次啟動重試。如每次啟動都會注冊遠程推送脆霎。另一個例子是上傳設(shè)備唯一標識的邏輯总处，可以寫成類似這樣：
1
2
3
4
5
6
7
8
9
10NSString?*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 都調(diào)用這段代碼，而上傳成功時才保存到本地睛蛛。這樣首次請求失敗也無妨鹦马，下次打開時仍能重試上傳，直到成功為止忆肾。
開發(fā)者的無奈
臨時出現(xiàn)這種變故荸频，作為開發(fā)者也表示很無奈。為了排查問題难菌，技術(shù)同事犧牲手機反復(fù)重置试溯，老板還一副不相信的樣子：“那其他家 app 怎么就沒出問題？”
好在總算能用各種特殊處理郊酒，把問題先掩蓋過去遇绞。還是希望蘋果能在 iOS 系統(tǒng)的新版本里完善這個新功能，提供類似相機權(quán)限的 api 吧燎窘。不要再折磨廣大開發(fā)者了摹闽。
