@
happyzed ”难道 google 连 app 引导用户授权这种业务需求都要管吗？我不信 ios 没有这种情况。“
要管的，不管就会出现滥用。而在管着的 iOS 上可以认为不会出现这些问题：
1 ，“不给权限就不允许”的情况。
2 ，暴露了设备不需要的设备识别码的情况(不考虑使用了苹果所禁止的私有 api 的情况)。
具体：
1 ，
这里权限指的是比较广义的非必要权限：
比方说，定位权限对于一个地图应用是非必要的，因为用户可能仅为了查看地图。
在这种情况下，以下的做法是好的：
应用启动时索取定位权限--->用户不同意--->应用以不提供定位能力，但可以查看地图的方式运行，此时应用具备提供地图的能力
如果用户想用定位了，点击定位按钮，应用提示用户授权定位权限--->如果这个时候用户不同意，应用则拒绝提供定位，因为此时应用自身就没有定位的能力。
2 ，
在 iOS 上，应用找不到任何一个(1)在刷机之后还能保留的，或(2)不同 Vendor 之间共享的设备识别码。
不同应用之间可以通过 Vendor Id 共享设备识别码。
微信公众号的 openId 也有类似的设计。
在 Android 上，应用可以获得以下的识别码：
1 ， SSAID(即 Android Id ，刷机后重置，同一设备的不同账户的 SSAID 不同)
2 ， Build.SERIAL(不随刷机改变)
3 ， IMEI/MEID(不随刷机改变)
4 ， ICCID(随 sim 卡改变)
其中 1 是可以跨应用共享的，即所有应用读到的 SSAID 是相同的
其中 2 读取时不要任何权限，且是 Android CDD 规定的
其中获得 3/4 需要电话权限---->这就是国产应用几乎都要电话权限，稍微坏一点的，不给电话权限就退出的原因。
3/4 的问题可以通过 AppOps 给应用返回 null 进行缓解，但是目前不能解决 1/2 的问题。
而正确的做法是， 1~4 它们一个都不应该使用。 SSAID 应该降级成一个对每个应用独立，在卸载之前不改变的值(这样的角色目前由 Instance ID 承担)。
当然对于涉及钱的应用，使用 IMEI/ICCID 还是有一定合理性的。
而谷歌官方对这些识别码的使用并没有加上任何的强制限制
https://developer.android.com/training/articles/user-data-ids.html#version_specific_details_identifiers_in_m反倒是在 Instance App 上，做出了不允许获取全部 1~4 的强制限制。
除此以外 Instance App 还不允许访问 /sdcard 。