开门见山先说结论：
我认为 App 在设计过程中，因考虑到用户体验的问题而巧妙地设置请求获取权限的时间、方式，甚至样式的这些举措，在 GDPR 生效后，产生了能够更进一步的用户体验提升空间。
为什么需要获取权限
与 iOS 不同，在 Android 6.0 之前，虽然安装 App 之前也会提示用户此 App 需要获取什么权限，但除非全盘接受，否则只能取消安装 App，。直到 2015 年底发布了 6.0 Marshmallow 之后，用户才能够对 App 获取的权限进行单独控制。在这之后，向用户请求获取权限这一问题，作为用户体验的一部分，才被更广泛地拿来讨论，并延伸出大量实践用例，并形成设计理论。
通常来说，App 初始化及运行过程中会对 2 种类型数据请求获取权限：
- 设备硬件数据及权限，如位置信息、传感器、摄像头和麦克风；
- 用户数据及文件读取，如短信及通话记录、联系人、文件管理器；
这些数据或权限中，根据 App 功能的区别，有的是用来确保 App 能够运作的，如地图定位应用需要当前位置、录音应用需要开启麦克风录入声音，短信应用对短信的收发读写（没错 Android 里甚至能关闭短信应用的短信权限）；有的是用来提供功能或服务的，如 Instagram 需要相机权限拍摄照片和视频，某些应用的分享邀请功能需要读取联系人列表等等。
Android 中将可请求的权限分为 9 个权限许可组别，如日历、相机、联系人、位置等等，不同组别根据应用对象的不同，将读写删除等操作绑定在一起，从产品设计及开发层面来看，这种打包做法可以实现用户一次许可就能够获得关联业务流程所需要的权限，避免为了获取用途相近的权限分别请求许可的繁琐操作，同时也便于用户理解。
常见的请求获取权限的方式
相比 Apple 在 HIG 里对请求获取权限的简要介绍，Google 在 Material Design 里所做的权限说明则要详细得多，并形成了关于请求类型的方法论（见下图），从权限的重要性以及明确性两个维度，划分出四种适用于不同需求、场景以及不同表现能力的请求方式。
在这个方法论里，根据请求明确性的清晰程度，分为询问与引导两种类型；而根据权限的重要性轻重，则分有请求前置与情境请求两个不同的阶段。
根据不同重要性与明确程度所组成的四个象限，在设计实践中则分别应用为预先请求，使用具体功能时请求，Onboarding引导，业务界面引导等等有区别的做法。同时对 iOS 在使用过程中只能请求一次权限的限制，也衍生出预请求和权限设置页面引导等曲线处理方法。
看到这里，可能会有人问，获取授权与 GPDR 有什么关系？
什么是 GDPR ？
GDPR 全称《通用数据保护条例》(General Data Protection Regulation)，2016年5月25日通过，两年后的2018年5月25日开始在欧盟28个国家内实施，对所有在欧盟国家有经营业务的企业生效。
在知乎找到了一张对 EU GDPR: Data Rights and Security Obligations 这篇文章里的信息图进行中文翻译的版本，对 GDPR 包含的内容有非常容易理解的讲解。简单地说，用户需要知道自己在使用互联网服务的过程中，有哪些数据被收集、以及数据被处理的方式。同时用户也能够撤回同意被收集数据的许可，并请求转移数据，甚至删除个人数据。
互联网对 GDPR 的适应
由于违反 GDPR 可能会导致高达企业全球营业额2%的罚款，在5月份中旬开始至5月25日，许多人的Email收件箱是下方配图里那样的画风 —— 大量公司更新用户协议或服务条款中关于用户数据权益的部分，并通过邮件提醒用户是否确认条款更新，并决定是否继续使用服务。
同时，也有越来越多的在线服务提供了像是 Medium 这样删除账号的功能。
数据与权限的关系
数据是用户属性及行为所产生的价值信息，而权限则是数据在用户终端与互联网企业之间流通所必须获得用户许可的闸门。
如果说注册账号时所勾选的知晓服务协议选项，是用户与提供服务的企业之间达成一致的证明（即时很多人基本不看具体内容），在获取数据的业务流程与产品设计层面，也有责任帮助用户获得相比当前更全面、更有效地对 App 获取权限的管理与控制。对于那些不需要注册账号即可使用服务或工具型 App 来说更是如此。
GDPR 所带来的一个启示是，对于互联网企业在提供服务过程中所获得的数据，需要明确地提示用户对其拥有完全可控的权利。如果用户数据是理应交由用户自主控制的，那么在我看来，对获得数据而请求权限的操作，也应该交由用户自主控制，包括自由地授予和解除授权。
面向用户权益的设计
常见的请求获取权限流程中，权限获取在 App 内是单向、不可逆转的。无论 iOS 或 Android 系统内， 在 App 内部的业务流程均停留在获得权限这一步。
除非特意去寻找解除权限授权的方式，否则通常情况下，用户无法直接通过 App 内部的操作或引导，来完成解除授权这一动作。如果需要解除对 App 的权限许可，只能退出 App 后，从系统设置或应用信息里另外操作。
仅从「请求获取权限时如何让用户不因厌恶或不解而给予权限」这方面来看，我认为无论 Android 还是 iOS 开发者，在既有的设计体系中已经进行了非常深入的讨论与实践。
假设这样一种情况：你希望分享 App 活动给好友来获得奖励，此时 App 希望获得读取你联系人的权限来完成分享操作。因为奖励丰厚，你同意让 App 获得权限并完成分享。但这不应该代表这种授权方式在业务流程中是永久的，或者毫无明示的。
虽然受限于 iOS 和 Android 系统所提供的请求权限接口的一些限制，我认为在设计 App 的业务流程时，应满足以下对于请求获取权限的要求，来实现用户对权限的自主控制：
- 允许设置单次或一定期限内的权限授予；
- 单独列出 App 运行或业务所需要使用的权限，以及权限授予状态；
- 可以直接完成授权撤回的操作，或引导用户前往设置页面撤回授权；
如此这样，用户对数据及权限授予两方面才获得了更完整的控制权。相比「处心积虑」地降低用户对请求权限的厌恶感，我对如何让用户感受到更多的安全感更有兴趣。从这样的思路出发，也在 App 设计过程中，产生了能够更进一步提升用户体验的空间。
参考资料
关于 App 请求获取权限的设计文章很多，我认为下面这 3 个链接进行的说明比较完整，所提供的案例也具有参考性，可以仔细看看。
Nick Babich 在 uxplanet 上非常高产，他的这篇 Mobile UX Design: The Right Ways to Ask Users for Permissions 可能是中文交互圈内关于获取用户权限讨论的元文本。
Elizabeth Ballou 的这篇 Why Permission Priming is Good UX 分别列举了几种在预请求权限方面做得好与不好的几个例子，其中 Youtube 和 Starbuck 的应用因突兀且直接而略有遗憾，而 Bitmoji 和 Duolingo 所设计的流程，引导并让用户更主动的开启权限。
原文同步发表在 Medium @liyishan
