Authorization
当我们想使用定位方面的特性的时候，首先绕不过去的一个步骤就是 Always 和 While Using 权限申请。个人认为这可以算是一个获取用户信任的问题，首先在 plist 中设置 Location Always Usage Description 和 Location When In Use Usage Description 俩个字段来告诉用户需要申请你需要权限的理由（iOS 11 以上想使用始终定位，还需要添加 Location Always and When In Use Usage Description），即使这时候说服了用户给予我们权限，后续使用中也可能因为其它原因被用户收回权限，例如耗电、应用的功能等。
先整理不同平台中对权限的支持程度。
| Always | While Using | |
|---|---|---|
| watchOS | support | support |
| tvOS | not support | support |
| macOS | \ | \ |
注：macOS 中没有这两种权限的说法。
在 iOS 13 中，权限和之前稍有不同。我们先来说说之前的权限管理，在 iOS 8 到 iOS 12 时期的时候，用户可以授权两种定位权限：（原谅我懒惰，下图中 ”asd“ 都是 plist 配置文件中权限使用的描述，实际开发中请仔细填写产品使用定位权限的用途，提高用户的信任程度）
requestWhenInUseAuthorization
2.png
在 requestWhenInUseAuthorization 图中，我们可以在应用处于前台的期间获取用户的定位数据。但是如果应用这个时候处于后台并且没有挂起的时候呢？
我们还是能获取定位数据，不过需要处理下列流程：
-
设置勾选 Capabilities > Background Modes > Location Updates
-
在 iOS 9 及以上还需要添加代码
allowsBackgroundLocationUpdates = true
但是这个时候在设备顶部会出现下图中的蓝色指示条：
image-20191101141237365.png
这个设计个人觉得也非常合理，用户没有确认当前应用有一直获取定位的权限，并且应用处于后台仍然在获取定位数据。所以用户可能也会希望：
- 知道当前什么应用还在后台使用定位
- 点击这个指示条能快速回到该使用定位的应用
但是如果应用需要在后台使用定位权限时，不展示上面的蓝色指示条。我们则需要申请下面的这个权限。
-
requestAlwaysAuthorization权限
1.png
在 requestAlwaysAuthorization 图中可以看到开发者申请 Always 权限请求后，是可以被降级为 While Using 的。所以需要后台获取定位数据的产品在决策上可能会做出一定的调整。例如先尝试引导用户获取 While Using 权限，当用户授权后再询问用户是否允许 Always 权限。代码上看起来形如：
switch CLLocationManager.authorizationStatus() {
case .AuthorizedAlways:
// 拿到了我们要的权限 Do Something
case .NotDetermined:
manager.requestWhenInUseAuthorization()
case .AuthorizedWhenInUse, .Restricted, .Denied:
// 弹出 Alert 或者自定义的界面来引导用户我们需要 Always 权限，然后去 Settings 界面等待用户操作
}
这里说的是开发者可以做的流程优化，但是如果作为用户可能还是会觉得有点疑惑。为什么同时弹出了两种权限申请范围呢？
而且当使用应用遇到这种弹窗时，一般是同意权限范围小的那个，即 While Using 。对于不信任的应用或者是新应用甚至可能直接拒绝掉。
下面则来说说 iOS 13 对于这个流程的一个变化，个人觉得是一处小优化吧。在 iOS 13 中无论开发者申请上面权限中的哪一个，都只会对用户弹出下面的这个弹窗：
4.png
对于 requestWhenInUseAuthorization 没有我们需要额外注意的地方，和之前处理和表现也都一致。
但是苹果对于 requestAlwaysAuthorization 权限请求在这里的弹窗给出的解释是临时始终权限，多了临时二字。大致流程为：
- 开发者请求 Always 权限
- 用户看见上图的弹窗，然后选择 While Using 后，系统设置中也会显示为 While Using
- 但是 CLLocationManager 记录下我们请求的是 Always 权限
- 当应用在后台使用定位数据的时候，会弹出第二个选择弹窗给予用户选择
3.png
上述的流程中，用户会认为一直允许的是 **While Using **，而开发者则是临时的 Always 。这样开发者不需要变更处理流程，而用户也不会迷惑该怎么选择权限弹窗。等到后台第一次使用定位产生事件的时候，就可以把上面的行为统一起来，继续 While Using 还是 Always ，到了这一步不管用户选择的是哪种权限结果都统一了。这样说起来是帮助开发者提高了获取权限的成功率呢，因为用户面临选择的时候更清晰了~
最后一点变更，就是权限中有一个新的 Allow Once，这个代表的当前应用生命周期内允许使用 While Using。在下一次使用应用的时候仍然会弹窗继续请求权限，也是对用户不信任应用的一个解决方案的优化，可以让用户使用一段时候后再决定是否给予权限，或者给予哪种权限。
权限在 iOS 13 的变更这里也就说完，变更我个人觉得也如同上面所说的，是一个对开发者和用户的小优化。
Beacon Ranging
IBeacon 是 iOS 7 开始支持的一个功能，主要功能就是配备有 BLE 低功耗的设备广播自己的唯一设备标识（uuid）。既然是广播，那么接受的设备（通常就是我们的手机）就可以做一些工作。白话讲主要功能就是区域检测，涉及到定位的那么就肯定需要用到 Core Location 框架了。下面有一些很典型使用场景的例子：
- 入场打卡 & 智能打卡
- 室内定位
使用过的同学应该很熟悉，主要有两种方式开启检测监听：
- startRangingBeacons(in: CLBeaconRegion)
- startMonitoring(for: CLBeaconRegion)
iOS 13 之前想使用上面的方法启动监听，首先需要申请 Always 的定位权限，而 iOS 13 开始仅需要 While Using 权限了。
然后新增了一个 CLBeaconIdentityConstraint 对象，主要是支持了可选的 major 和 minor ，类似于通配符的概念。这样监听的方案就更加自由，Beacon 更多细节可能要另起一篇，这里就不在多阐述了。
网友评论