這個坑最近弄得我很抓狂，不過現在基本弄清楚了。記錄一下過程中我收集到的資訊，分享給大家。
症狀
iOS 10 之後，陸陸續續地有使用者聯絡我們，說新機第一次安裝、第一次啟動的時候，app 首屏一片空白，完全沒資料。kill 掉重新開啟就好了。
一開始以為是使用者網路情況不好，但隨著越來越多的使用者報告這個問題，我意識到這並不是偶然情況。但是並非所有使用者都如此。
而且解除安裝掉之後，如果再裝，也不會出現這現象。問題只會出現在這臺裝置第一次安裝、第一次啟動的情況下。如果把手機抹掉、重置，問題還能重現。
定位問題
這個問題真的很棘手，也很難定位。幸運的是，公司同事想到把手機抹掉重置，得以在我眼前重現問題。
我發現的是，app 首次啟動會彈出一個詢問使用者“是否允許應用訪問資料”的彈框，類似下圖：
雖然 app 剛開啟的時候是一片空白，但我發現進去之後，登入、下拉重新整理等都沒問題。因此很容易猜測出這樣的結論：使用者點“允許”之前，網路請求全都是失敗的；而點“允許”之後，網路請求就能正常進行了。
問題原因
有了方向之後就好查了。很快查到了掘金的這篇文章，得知這個彈框來自於工信部的要求。這篇文章裡還有如果彈框不出現，使用者可以採取的解決方案。另外，從少數派的這篇文章 看到，只有國行手機有這個功能。這也就解釋了為何有些使用者出現、而有些使用者沒出現這個問題。
進到手機的 設定->蜂窩行動網路，如果看到如左圖就說明是不會彈框的機型，如果看到如右圖，說明是會彈框的機型。
那麼這個新功能會為使用者帶來哪些問題呢？問題主要在於，使用者點選“允許”之前，所有網路請求都是被禁止的。具體有兩種表現：
- 少部分使用者根本不顯示彈框，所以網路請求一直被禁止。針對這部分使用者，只能通過客服引導，按照掘金的這篇文章，逐個嘗試裡面的解決方案；
- 對於絕大部分使用者，彈框會正確顯示；然而從 app 啟動到使用者點選“允許”需要一段時間，在這段時間內發出的網路請求全都會直接失敗；
如果使用者點選“不允許”，app 永遠無法訪問網路，Wifi 和資料流量均不可以。當然，這是使用者自己的選擇，我們沒什麼可做的。我們主要需要解決的是上面的第二個問題。
影響範圍
這個特性推出之後，大部分 app 應該都會受到不同程度的影響。可以著重在這幾個方面檢查一下自己的 app：
- 首屏資料。首屏幾個 tab 的資料往往在 app 啟動時即載入，也就是在使用者點“允許”之前。很容易造成使用者第一次進入時，首屏資料空白。
- 推送。通常的處理邏輯是，把註冊裝置遠端推送的程式碼寫在 appDelegate 裡。經過測試發現，這種寫法下允許推送的彈框和允許使用網路的彈框出現的順序沒有一定。如果先出允許推送的彈框，使用者點選允許，此時註冊 deviceToken 是不能成功的。當然如果使用者允許訪問網路，第二次開啟 app 時也會走一遍註冊遠端推送方法，此時就能註冊成功了。
- 其他首次啟動的處理。諸如廣告頁、活動頁之類，需要在啟動時請求的資料。新版本的更新檢查往往也在啟動時進行，但這一點影響不大，因為首次開啟的使用者一般都是處於最新版。另外，常常會在新裝置首次啟動時，上傳一個裝置唯一標識用於統計目的，例如 IDFA。
解決方案
在重置過的手機上，嘗試裝了一些大大小小的 app，發現不少 app 在適配這個新特性上都存在一些小問題。而有些 app 也做了比較有特色的處理。
不幸的是，蘋果這個功能可能出得太倉促，並沒有給開發者提供相應的 API。所以，我們沒辦法檢測到使用者點選“允許”或“不允許”網路請求的回撥，也沒法檢測到當前使用者是否授權的狀態。只能通過一些特殊處理，來儘量減小對使用者的影響。
總體來說，主要有如下幾個解決方案：
- 延遲請求。對於首次啟動的所有介面，如果能延遲到使用者點選“允許”之後再請求，或者重新請求一次，就能把對使用者的影響降到最低，是一個比較好的解決方案。因為首次啟動往往有幾屏引導頁，一個比較好的時機是引導頁結束時。此時使用者已經進行了授權，資料都能正確得到。所以我自己的做法是把請求推遲到了引導頁。另外饒志臻大神提了一個特別好的思路，就是用 AFN 監聽網路狀態，有網時開始請求。雖然沒有試過（我自己手機不是國行，不太好實驗），但感覺應該也能比較完美地處理這個問題。
允許使用者手動重新請求。出現資料空白時，如果在空白頁面上有“重新載入”的按鈕，也可以讓使用者體驗好一些。比較有趣的是，測試中發現網易嚴選的處理是這樣的：
網易嚴選的首屏介面
加了一個“檢視解決方案”的按鈕。點選這個按鈕會跳轉到一個描述解決方案的頁面，內容跟上面掘金的文章類似。很有意思的處理，雖然不能避免白屏，但使用者會嘗試重新開啟，還可以幫到少部分始終不顯示彈框的使用者。- 稍後重新請求。網路框架如果做了請求失敗時，定時重新請求的處理，應該也能解決首次請求失敗的問題。另外，首次啟動時各種處理的邏輯都可以寫成一旦失敗，下次啟動重試。如每次啟動都會註冊遠端推送。另一個例子是上傳裝置唯一標識的邏輯，可以寫成類似這樣：
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 都呼叫這段程式碼，而上傳成功時才儲存到本地。這樣首次請求失敗也無妨，下次開啟時仍能重試上傳，直到成功為止。
開發者的無奈
臨時出現這種變故，作為開發者也表示很無奈。為了排查問題，技術同事犧牲手機反覆重置，老闆還一副不相信的樣子：“那其他家 app 怎麼就沒出問題？”
好在總算能用各種特殊處理，把問題先掩蓋過去。還是希望蘋果能在 iOS 系統的新版本里完善這個新功能，提供類似相機許可權的 api 吧。不要再折磨廣大開發者了。