Android 运行 时间许可 api "requestPermission()" 设计
Android Run time permission api "requestPermission()" design
由于 Android 去年添加， 运行 时间许可在 Android API 版本 23 及以上，我有一个关于
的问题
ActivityCompat.requestPermissions(thisActivity,
new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
和
ActivityCompat.requestPermissions(new String[]Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
api 请求许可。在上面的库中，要么我们必须提供 Activity 应该实现 ActivityCompat.OnRequestPermissionsResultCallback 接口的实例。 fragment和AppcompatActivity的支持版本，FragmentActivity默认实现了这个
为什么我们需要以 Activity 或 Fragment 的形式提供回调参考？我们可以将此 API 设计为
ActivityCompat.requestPermissions(context,
new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS,ActivityCompat.OnRequestPermissionsResultCallback callback);
我的意思是我们必须提供 Activity 或 Fragment 的支持版本。如果我们想在任何其他简单的 class 中检查 activity 之外怎么办？举个例子，我有一个 GeofenceManager class，它需要位置权限，许多活动或 classes 需要来自这个 GeofenceManager 单例 class.
的一些信息
我是否必须在每个活动中实施 OnRequestPermissionsResultCallback？我认为如果 Api 在上面建议的设计中会好得多。以这种方式设计 API 肯定有一些重要原因。我的小经验搞不定。
所有 AppCompat API 都旨在尽可能轻松地由其本机对应项替换。
表示 API 23 上的原生 android.app.Activity 实现是一个 public final void requestPermissions 方法和一个 public void onRequestPermissionsResult 回调。
以便将它们转换为 AppCompat。将它们作为单独的实体肯定会导致更灵活的方法，但也会导致将来无法在设备更新时弃用 AppCompat。
你可能会争论为什么 API23 activity 不这样做，但这就是一般的 Android 如何始终存在并且是他们处理一切的方法，例如 onActivityResult
此外，这些必须附加到 activity，因为只有在前台时才会请求权限。
编辑：
仔细想想，还有一个原因。回转！
由于 activity 在轮换期间被销毁并重建，基于 interface 的回调可能非常棘手。
回调方法需要某种类型的上下文或执行进一步的操作（转到下一个 activity，或 load/read 来自新授予的权限的内容）。因此，如果编码器将接口作为匿名内部 class 传递或使其 activity 扩展该接口并发生轮换，它将泄漏 activity。或者回调方法需要接收上下文参数，但框架必须跟踪哪个 activity 是当前上下文以发送回回调。所有这些都会很快变得非常复杂。因此，一种简单直接的方法是使其成为 activity.
的实际方法
我知道现在回答我自己的问题有点晚了，但我仍然认为我的回答会对这个话题有所帮助。
在Android中，有5种进程，大体上是基于优先级的。这些是前台进程，然后是任何可见进程、服务进程、后台进程，最后是“空”进程。
前台进程具有最高优先级，因为在大多数情况下用户直接使用这些进程的组件，例如 Activity 或前台服务。但是我们的案例属于第二种过程。一个可见的过程。
注意：权限对话框不会显示在请求权限的activity中。事实上，它是一个 Activity!
有些情况下您的 activity 可以看到但不在前景中。一个简单的例子是当前景 activity 开始一个新的 activity 与 Dialog 主题或半透明 activity。
但是请记住，仅仅因为您可见并不意味着您不会被杀死。如果前台进程有足够的内存压力，您的可见进程仍有可能被杀死。从用户的角度来看，这意味着当前 activity 后面的可见 activity 被替换为黑屏。当然，如果您正确地重新创建 activity，您的进程和 Activity 将在前台 Activity 关闭后立即恢复，不会丢失任何数据。
即使可见，您的 activity 和进程也可能被终止，这是 startActivityForResult()+onActivityResult() 和 requestPermissions()+onRequestPermissionsResult() 流程不接受回调的原因之一 class 实例 — 如果你的整个进程都死了，那么每个回调 class 实例也会死。如果您看到使用回调方法的库，请意识到它无法适应低内存压力的情况。
注意：Android只杀死进程，不杀死组件。永远记住这一点。
这是 Android 中的 requestPermission() API 被设计成现在的样子，而不是我提到的那个的主要原因之一。
由于 Android 去年添加， 运行 时间许可在 Android API 版本 23 及以上，我有一个关于
的问题ActivityCompat.requestPermissions(thisActivity,
new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
和
ActivityCompat.requestPermissions(new String[]Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
api 请求许可。在上面的库中，要么我们必须提供 Activity 应该实现 ActivityCompat.OnRequestPermissionsResultCallback 接口的实例。 fragment和AppcompatActivity的支持版本，FragmentActivity默认实现了这个
为什么我们需要以 Activity 或 Fragment 的形式提供回调参考？我们可以将此 API 设计为
ActivityCompat.requestPermissions(context,
new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS,ActivityCompat.OnRequestPermissionsResultCallback callback);
我的意思是我们必须提供 Activity 或 Fragment 的支持版本。如果我们想在任何其他简单的 class 中检查 activity 之外怎么办？举个例子，我有一个 GeofenceManager class，它需要位置权限，许多活动或 classes 需要来自这个 GeofenceManager 单例 class.
的一些信息我是否必须在每个活动中实施 OnRequestPermissionsResultCallback？我认为如果 Api 在上面建议的设计中会好得多。以这种方式设计 API 肯定有一些重要原因。我的小经验搞不定。
所有 AppCompat API 都旨在尽可能轻松地由其本机对应项替换。
表示 API 23 上的原生 android.app.Activity 实现是一个 public final void requestPermissions 方法和一个 public void onRequestPermissionsResult 回调。
以便将它们转换为 AppCompat。将它们作为单独的实体肯定会导致更灵活的方法，但也会导致将来无法在设备更新时弃用 AppCompat。
你可能会争论为什么 API23 activity 不这样做，但这就是一般的 Android 如何始终存在并且是他们处理一切的方法，例如 onActivityResult
此外，这些必须附加到 activity，因为只有在前台时才会请求权限。
编辑：
仔细想想，还有一个原因。回转！
由于 activity 在轮换期间被销毁并重建，基于 interface 的回调可能非常棘手。
回调方法需要某种类型的上下文或执行进一步的操作（转到下一个 activity，或 load/read 来自新授予的权限的内容）。因此，如果编码器将接口作为匿名内部 class 传递或使其 activity 扩展该接口并发生轮换，它将泄漏 activity。或者回调方法需要接收上下文参数，但框架必须跟踪哪个 activity 是当前上下文以发送回回调。所有这些都会很快变得非常复杂。因此，一种简单直接的方法是使其成为 activity.
的实际方法我知道现在回答我自己的问题有点晚了，但我仍然认为我的回答会对这个话题有所帮助。
在Android中，有5种进程，大体上是基于优先级的。这些是前台进程，然后是任何可见进程、服务进程、后台进程，最后是“空”进程。
前台进程具有最高优先级，因为在大多数情况下用户直接使用这些进程的组件，例如 Activity 或前台服务。但是我们的案例属于第二种过程。一个可见的过程。
注意：权限对话框不会显示在请求权限的activity中。事实上，它是一个 Activity!
有些情况下您的 activity 可以看到但不在前景中。一个简单的例子是当前景 activity 开始一个新的 activity 与 Dialog 主题或半透明 activity。 但是请记住，仅仅因为您可见并不意味着您不会被杀死。如果前台进程有足够的内存压力，您的可见进程仍有可能被杀死。从用户的角度来看，这意味着当前 activity 后面的可见 activity 被替换为黑屏。当然，如果您正确地重新创建 activity，您的进程和 Activity 将在前台 Activity 关闭后立即恢复，不会丢失任何数据。
即使可见，您的 activity 和进程也可能被终止，这是 startActivityForResult()+onActivityResult() 和 requestPermissions()+onRequestPermissionsResult() 流程不接受回调的原因之一 class 实例 — 如果你的整个进程都死了，那么每个回调 class 实例也会死。如果您看到使用回调方法的库，请意识到它无法适应低内存压力的情况。
注意：Android只杀死进程，不杀死组件。永远记住这一点。
这是 Android 中的 requestPermission() API 被设计成现在的样子，而不是我提到的那个的主要原因之一。