这个坑最近弄得我很抓狂，不过现在基本弄清楚了。记录一下过程中我收集到的信息，分享给大家。

症状

iOS 10 之后，陆陆续续地有用户联系我们，说新机第一次安装、第一次启动的时候，app 首屏一片空白，完全没数据。kill 掉重新打开就好了。

一开始以为是用户网络情况不好，但随着越来越多的用户报告这个问题，我意识到这并不是偶然情况。但是并非所有用户都如此。

而且卸载掉之后，如果再装，也不会出现这现象。问题只会出现在这台设备第一次安装、第一次启动的情况下。如果把手机抹掉、重置，问题还能重现。

定位问题

这个问题真的很棘手，也很难定位。幸运的是，公司同事想到把手机抹掉重置，得以在我眼前重现问题。

我发现的是，app 首次启动会弹出一个询问用户“是否允许应用访问数据”的弹框，类似下图：

询问网络权限的弹框

虽然 app 刚打开的时候是一片空白，但我发现进去之后，登录、下拉刷新等都没问题。因此很容易猜测出这样的结论：用户点“允许”之前，网络请求全都是失败的；而点“允许”之后，网络请求就能正常进行了。

问题原因

有了方向之后就好查了。很快查到了掘金的这篇文章，得知这个弹框来自于工信部的要求。这篇文章里还有如果弹框不出现，用户可以采取的解决方案。另外，从少数派的这篇文章 看到，只有国行手机有这个功能。这也就解释了为何有些用户出现、而有些用户没出现这个问题。

蜂窝移动网络的两种界面

进到手机的 设置->蜂窝移动网络，如果看到如左图就说明是不会弹框的机型，如果看到如右图，说明是会弹框的机型。

那么这个新功能会为用户带来哪些问题呢？问题主要在于，用户点击“允许”之前，所有网络请求都是被禁止的。具体有两种表现：

1. 少部分用户根本不显示弹框，所以网络请求一直被禁止。针对这部分用户，只能通过客服引导，按照掘金的这篇文章，逐个尝试里面的解决方案；
2. 对于绝大部分用户，弹框会正确显示；然而从 app 启动到用户点击“允许”需要一段时间，在这段时间内发出的网络请求全都会直接失败；

如果用户点击“不允许”，app 永远无法访问网络，Wifi 和数据流量均不可以。当然，这是用户自己的选择，我们没什么可做的。我们主要需要解决的是上面的第二个问题。

影响范围

这个特性推出之后，大部分 app 应该都会受到不同程度的影响。可以着重在这几个方面检查一下自己的 app：

1. 首屏数据。首屏几个 tab 的数据往往在 app 启动时即加载，也就是在用户点“允许”之前。很容易造成用户第一次进入时，首屏数据空白。
2. 推送。通常的处理逻辑是，把注册设备远程推送的代码写在 appDelegate 里。经过测试发现，这种写法下允许推送的弹框和允许使用网络的弹框出现的顺序没有一定。如果先出允许推送的弹框，用户点击允许，此时注册 deviceToken 是不能成功的。当然如果用户允许访问网络，第二次打开 app 时也会走一遍注册远程推送方法，此时就能注册成功了。
3. 其他首次启动的处理。诸如广告页、活动页之类，需要在启动时请求的数据。新版本的更新检查往往也在启动时进行，但这一点影响不大，因为首次打开的用户一般都是处于最新版。另外，常常会在新设备首次启动时，上传一个设备唯一标识用于统计目的，例如 IDFA。

解决方案

在重置过的手机上，尝试装了一些大大小小的 app，发现不少 app 在适配这个新特性上都存在一些小问题。而有些 app 也做了比较有特色的处理。

不幸的是，苹果这个功能可能出得太仓促，并没有给开发者提供相应的 API。所以，我们没办法检测到用户点击“允许”或“不允许”网络请求的回调，也没法检测到当前用户是否授权的状态。只能通过一些特殊处理，来尽量减小对用户的影响。

总体来说，主要有如下几个解决方案：

1. 延迟请求。对于首次启动的所有接口，如果能延迟到用户点击“允许”之后再请求，或者重新请求一次，就能把对用户的影响降到最低，是一个比较好的解决方案。因为首次启动往往有几屏引导页，一个比较好的时机是引导页结束时。此时用户已经进行了授权，数据都能正确得到。所以我自己的做法是把请求推迟到了引导页。另外下面评论里饶志臻大神提了一个特别好的思路，就是用 AFN 监听网络状态，有网时开始请求。虽然没有试过（我自己手机不是国行，不太好实验），但感觉应该也能比较完美地处理这个问题。

2. 允许用户手动重新请求。出现数据空白时，如果在空白页面上有“重新加载”的按钮，也可以让用户体验好一些。比较有趣的是，测试中发现网易严选的处理是这样的：

   
   

   网易严选的首屏界面

   
   加了一个“查看解决方案”的按钮。点击这个按钮会跳转到一个描述解决方案的页面，内容跟上面掘金的文章类似。很有意思的处理，虽然不能避免白屏，但用户会尝试重新打开，还可以帮到少部分始终不显示弹框的用户。

3. 稍后重新请求。网络框架如果做了请求失败时，定时重新请求的处理，应该也能解决首次请求失败的问题。另外，首次启动时各种处理的逻辑都可以写成一旦失败，下次启动重试。如每次启动都会注册远程推送。另一个例子是上传设备唯一标识的逻辑，可以写成类似这样：

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 吧。不要再折磨广大开发者了。