前言：
好久没更新文章了，距离上次更新已经有5个月时间了，前段时间结合自己在处理的权限方面的问题写了这么篇水文，希望能帮到其他人。同时还是比较佩服那些高产的作者，在兼顾工作的同时还能持续输出优秀的技术文章。
感慨下，回到正题，本文主要要说的是在权限请求体验上的一些优化，并非权限适配方面的文章，角度上和目前市面上的权限文章可能不太一样。
文章主要是针对目前公司app在权限请求使用上的一些改进与优化，大致可以分为三个部分
（1）权限库权限回调bug修复
（2）系统权限请求弹框重叠解决
（3）系统权限开关引起的app进程杀死重启
（1）权限库权限请求回调
其实目前市面上有不少高质量的权限请求库可以使用，几行代码就能帮助我们完成权限的请求，但说来比较有意思，不管是我目前公司还是之前公司对于权限请求这块的处理，似乎更加偏向于自己去实现类似的库。
其实不管是自己造轮子还是使用三方开源库，只要能做到对于其中的原理掌握都是可取的，使用三方库更多的优势在于敏捷开发，节约时间成本，但是使用三方库一个比较明显的缺点就是可定制化方面确实弱了点，尤其是在你没有完全摸清开源库代码的情况下，贸然的修改可能会引起各种问题。
扯的有点跑题了，回到权限问题上来，如果是自己去实现一个权限库，其中一个问题肯定是绕不开的，那就是权限请求结果回调如何处理的问题。Activity通过
@Override
public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults)
方法处理权限请求的结果，那么问题来了实现权限库必然需要在
onRequestPermissionsResult
去处理请求，然后将处理结果通过callback的形式进行回调。之前大致研究过个别开源权限库，主要做法大概有三种
(1)在项目的BaseActivity中复写onRequestPermissionsResult方法，通过调用权限库的处理方法实现回调，类似
@Override
public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
PermissionManager.getInstance(this).onRequestPermissionsResult(requestCode,permissions,grantResults);
}
这种方案简单有效，也是最容易想到的方案，但是对于一个权限库，还需要入侵到BaseActivity中去做一些事情，个人觉得多少差点意思，你都是一个成熟的权限库，要时候学会自己处理权限回调问题了
(2)开启一个透明的activity，然后在该activity中得到回调的结果，通过PermissionManager传入的callback实现回调这种方案也是比较容易想到的，也是一种可行的方案，目前公司就是采用这种方案，但是同事在实现上存在一个bug，这个等下说到
(3)通过给Activity添加一个fragment来实现权限结果的回调
这个方案是我认为最为巧妙的实现，通过fragment上同名的方法对回调进行处理。这其实就是对于fragment的巧妙利用，jetpack在实现liftcycle也是使用的类似的技巧。感兴趣的可以自行搜索相关文章。
回到文章说的第二种实现上，一般我们的权限请求使用方式都是类似这种形式（不包括利用apt实现的注解形式）
PermissionManager.getInstance(context,permissionItems).checkPermission(new PermissionCallback() {
@Override
public void onGuaranteed(String permission) {
...
}
@Override
public void onDenied(String permission, boolean shouldShowAgain) {
...
}
@Override
public void onFinished(boolean isAllGuaranteed) {
...
}
});
如果是开启透明Activity处理权限请求，必须将permissionCallback传递给透明Activity，公司内部权限库在处理这块时，采用了简单粗暴的方式
···
RequestPermissionActivity.setCallback(permissionCallback)
···
RequestPermissionActivity就是文章所说的透明Activity，通过静态方法将permissionCallback保存为Activity的静态变量，然后在Activity销毁的时候调用
@Override
protected void onDestroy() {
super.onDestroy();
permissionCallback = null;
}
避免内存的泄露问题，看起来简单有效，但是作为一个static类型的callback，当同时单独发起两个权限请求就会导致后一个callback覆盖掉前一个callback。这种场景在目前公司的业务环境是有可能出现的，比如最常见的在账号登录之后会，由于业务关系会发起一次数据校验请求，等到校验正确后才会发起定位权限请求，如果网络存在延迟的情况下在数据返回之前直接切换到其他需要权限的页面就会导致callback覆盖问题。
问题说明白之后剩下的解决思路就清晰了，禁止将callback设置为activity的静态变量，通过LocalBroadcastManager来实现透明Activity和PermissionManager之间的通信，解决方式参考如下
PermissionManager部分相关代码:
private void startRequest(PermissionCallback callback) {
//给PermissionManager注册一个本地广播
InnerBroadcastReceiver receiver = new InnerBroadcastReceiver(callback, mId);
LocalBroadcastManager.getInstance(mContext)
.registerReceiver(receiver, new IntentFilter(PERMISSION_CALLBACK));
Intent intent = new Intent(mContext, RequestPermissionActivity.class);
...
intent.putExtra(RequestPermissionActivity.INTENT_KEY_DATA, permissionParcelable);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
mContext.startActivity(intent);
...
}
private static class InnerBroadcastReceiver extends BroadcastReceiver {
PermissionCallback callback;
int mId;
InnerBroadcastReceiver(PermissionCallback callback, int id) {
this.callback = callback;
this.mId = id;
}
@Override
public void onReceive(Context context, Intent intent) {
if (intent == null) {
return;
}
int id = intent.getIntExtra(ID, -1);
if (id != mId) {
return;
}
boolean unregister = intent.getBooleanExtra(UNREGISTER, false);
//Activity销毁时需要及时注销掉对应广播，防止内存泄露
if (unregister) {
LocalBroadcastManager.getInstance(context).unregisterReceiver(this);
} else if (callback != null) {
boolean finish = intent.getBooleanExtra(CHECK_FINISH, false);
if (finish) {
boolean isAllGuaranteed = intent.getBooleanExtra(IS_ALL_GUARANTEED, false);
callback.onFinished(isAllGuaranteed);
} else {
boolean approve = intent.getBooleanExtra(APPROVE, false);
String name = intent.getStringExtra(PERMISSION_NAME);
boolean shouldShowAgain = intent.getBooleanExtra(SHOULD_SHOW_AGAIN, true);
if (approve) {
//将透明Activity中的callback移到InnerBroadcastReceiver内部
callback.onGuaranteed(name);
} else {
callback.onDenied(name, shouldShowAgain);
}
}
}
}
}
省略了部分和权限库具体实现相关的代码，不影响整体思路的理解。在startRequest发起权限请求时先注册一个本地广播，广播的接收在onReceive中处理，主要就是分析返回的数据来决定调用onGuaranteed还是onDenied。本地广播被注册成功后，必须有一个广播的发送者，透明Activity就是这么一个角色。
透明Activity部分代码如下:
private void sendPermissionSignal(String permission, boolean approve, boolean shouldShowAgain) {
Intent intent = new Intent();
intent.setAction(PERMISSION_CALLBACK);
intent.putExtra(ID, mId);
intent.putExtra(APPROVE, approve);
intent.putExtra(PERMISSION_NAME, permission);
intent.putExtra(SHOULD_SHOW_AGAIN, shouldShowAgain);
LocalBroadcastManager.getInstance(this).sendBroadcast(intent);
}
private void onGuarantee(String permission) {
sendPermissionSignal(permission, true, true);
}
private void onDeny(String permission, boolean shouldShowAgain) {
sendPermissionSignal(permission, false, shouldShowAgain);
}
@Override
protected void onDestroy() {
super.onDestroy();
Intent intent = new Intent();
intent.putExtra(UNREGISTER, true);
intent.putExtra(ID, mId);
intent.setAction(PERMISSION_CALLBACK);
LocalBroadcastManager.getInstance(this).sendBroadcast(intent);
}
在透明Activity中权限请求的结果通过sendPermissionSignal通知到PermissionManager，同时在onDestroy时反注册掉对应的本地广播，经上述代码处理后即可解决callback覆盖问题。
(2)系统权限请求框重叠问题
直接上图秒懂
可以看出出现了两个系统权限框重叠的现象，当同时有两个权限单独发起权限请求时就会导致这种情况，比如两个不同的组件模块同时发起权限请求，虽然不影响app的正常运行，但看到这种弹框重叠总觉得app显得有点low，作为一个有追求的开发者肯定要解决掉这个问题，主要思路就是通过一个管理类来统一调用app中的所有权限，类似于AsyncTask中默认串行执行任务行为，只有当一个任务执行完毕之后才会继续执行下一个任务。
具体关于PermissionDispatcher实现如下：
public class PermissionDispatcher {
private volatile static PermissionDispatcher dispatcher;
private List tasks;//每次权限请求封装成一个task
private Handler handler;
private Context context;
private PermissionDispatcher(Context context) {
handler = new Handler(Looper.getMainLooper());//UI线程执行任务，避免多线程并发可能导致的问题
tasks = new LinkedList<>();
this.context = context.getApplicationContext();
}
public static PermissionDispatcher getInstance(Context context) {
if (dispatcher == null) {
synchronized (PermissionDispatcher.class) {
if (dispatcher == null) {
dispatcher = new PermissionDispatcher(context);
}
}
}
return dispatcher;
}
public void checkPermissions(final boolean showCustomDialog, final boolean autoNext, final List items, final PermissionCallback callback) {
handler.post(new Runnable() {
@Override
public void run() {
PermissionDispatcher.Task task = new PermissionDispatcher.Task(items, showCustomDialog, callback, autoNext);
tasks.add(task);
if (tasks.size() == 1) {
PermissionDispatcher.Task current = tasks.get(0);
current.execute();
}
}
});
}
public void checkPermissions(final boolean showCustomDialog, final List items, final PermissionCallback callback) {
checkPermissions(showCustomDialog, true, items, callback);
}
public void checkPermission(final boolean showCustomDialog, boolean autoNext, final PermissionItem item, final PermissionCallback callback) {
List list = Collections.singletonList(item);
checkPermissions(showCustomDialog, autoNext, list, callback);
}
public void checkPermission(final boolean showCustomDialog, final PermissionItem item, final PermissionCallback callback) {
List list = Collections.singletonList(item);
checkPermissions(showCustomDialog, true, list, callback);
}
private class Task {
private List items;
private PermissionCallback callback;
private boolean showCustomDialog;
private boolean complete; //表示task是否执行完毕
private boolean autoNext;
private Task(List items, boolean showCustomDialog
, PermissionCallback callback, boolean autoNext) {
this.items = items;
this.showCustomDialog = showCustomDialog;
this.callback = callback;
this.autoNext = autoNext;
}
private void execute() {
PermissionManager instance = PermissionManager.getInstance(context, showCustomDialog);
if (items != null && !items.isEmpty()) {
for (PermissionItem item : items) {
instance.addPermission(item);
}
}
instance.checkPermission(new PermissionCallback() {
@Override
public void onGuaranteed(String permission) {
complete = true;
callback.onGuaranteed(permission);
}
@Override
public void onDenied(String permission, boolean shouldShowAgain) {
// Log.e("mandy", "dispatcher onDenied");
complete = true;
callback.onDenied(permission, shouldShowAgain);
}
@Override
public void onFinished(boolean isAllGuaranteed) {
// Log.e("mandy", "onFinished???");
callback.onFinished(isAllGuaranteed);
if (autoNext) {
nextInternal();
}
}
});
}
}
private void nextInternal() {
if (tasks.isEmpty()) {
return;
}
tasks.remove(0);
if (!tasks.isEmpty()) {
PermissionDispatcher.Task task = tasks.get(0);
task.execute();
}
}
public void next() {
if (tasks.isEmpty()) {
return;
}
PermissionDispatcher.Task current = tasks.get(0);
if (current.autoNext) {
return;
}
if (current.complete) {
nextInternal();
}
}
}
具体的实现就是上述代码了，当每次发起权限请求时都会封装成task，将该task保存到tasks容器内部，当task是容器中的第一个元素时会去执行task的excute方法，如果不是第一个元素则等待被调用。当task执行完毕之后就会从容器中被移除然后继续执行下一个task。
唯一需要特别说明的就是autoNext这个变量，一般情况下当一个task执行完毕后会自动继续执行下一个task这种情况下autoNext为true，但当你请求的权限会调用起系统的一些页面时情况会复杂一些，比如拍照请求摄像头权限成功后手机会调用系统相机页面，如果这时PermissionDispatcher中还有未执行的task，当该task被取出执行时就会导致出现权限弹框覆盖系统页面的问题，如图用户正在拍着照，突然画面中间弹个一个权限请求，是不是显得有点突兀，在使用体验上是不是略差。理解上述场景之后就可以明白这种情况下就不能将autoNext设置为true，需要等拍照结束调用onActivityResult之后再继续执行PermissionDispatcher中剩余的task，这就是autoNext字段的具体作用。当autoNext设置为false时就不会主动调用下一个需要执行的task，这时候就需要通过手动调用PermissionDispatcher的next方法触发下一个task的执行。
需要特别说明下的是，这个权限请求弹框覆盖系统页面问题不是引入PermissionDispatcher才导致的，一般的app如果没做特殊处理都是有可能存在这个问题的。
(3)系统权限开关导致的app进程杀死问题
这也是权限请求处理过程中避不开的一个坑，复现场景很简单当你在手机系统设置页面关闭app中某一个权限时，就会导致你的app进程被杀死！,这时候你再回到app页面，系统会重走Activity的生命周期方法重建该Activity，这里会导致的一个问题就是Activity中一些字段由于进程被杀死时得不到保存而导致状态错误，严重的可能导致页面恢复时出现app崩溃问题。
这里可以参考微信的做法，当在系统设置中关闭权限回到app时让app进行重启操作，重启的代码如下：
private static void restart(Activity activity) {
final Intent intent = new Intent();
intent.setClassName(activity, sSplashPage);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);
activity.startActivity(intent);
activity.overridePendingTransition(0, 0);
}
sSplashPage即为启动页的全名，通过startActivity重走启动页，并通过FLAG_ACTIVITY_CLEAR_TASK清除掉栈中其余的activity，达到重启app的目的
剩下的一个问题就是如何判断app需要重启，显然必须是权限在系统设置中被关闭这时回到app页面才需要触发重启。进程被杀死然后恢复Activity一个显著的特点就是savedInstanceState不为null，但是仅仅根据savedInstanceState不为null就判断app需要重启显然是不靠谱的。app横竖屏切换就是典型的应用场景，难道你要每次横竖屏切换都重启app？
关于系统权限关闭导致app进程杀死，网上有一篇文章可以参考https://www.jianshu.com/p/cb68ca511776，文章底部留言有人指出判断重启的方案，
但是经过自己实测发现该思路并不可行，如公司的测试三星手机，在系统中权限关闭后会直接触发application的onCreate方法，而华为手机的application的onCreate方法会在你点击app时才会执行。这种差异就注定了留言中的方案不可行。
这里提供一下自己解决这个问题的思路，寻找app每次正常启动必经的activity，如果检测到该activity就认为app是正常启动 ，之后即使出现savedInstanceState不为null也不触发重启，这种必经的activity一般都为splashActivity，特殊一点的如通过通知栏进入app或者通过deeplink形式进入app，可以这个必经Activity会变成一个中间过渡的Activity，但是思路上是和SplashActivity是一样的。
如果app进程被杀死然后恢复app页面这种情况会直接跳过该splashActivity，从而就可以触发app的重启逻辑了。
根据以上思路便可以得到如下代码:
public class RestartWatcher {
private static String sSplashPage = null;
private static List sWhiteList;
private static boolean sRestartDisable;
private static void restart(Activity activity) {
final Intent intent = new Intent();
intent.setClassName(activity, sSplashPage);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);
activity.startActivity(intent);
activity.overridePendingTransition(0, 0);
}
static void watch(Activity activity, Bundle savedInstanceState) {
try {
if (sSplashPage == null) {
sSplashPage = getLauncherActivityName(activity.getApplication());
}
if (TextUtils.isEmpty(sSplashPage) || savedInstanceState == null) {
return;
}
String name = activity.getClass().getCanonicalName();
if (TextUtils.isEmpty(name)) {
return;
}
if (sWhiteList != null && sWhiteList.contains(name)) {
return;
}
//noinspection ConstantConditions
if (name.equalsIgnoreCase(sSplashPage)) {
sRestartDisable = true;
}
if (!sRestartDisable) {
restart(activity);
}
} catch (Exception e) {
e.printStackTrace();
LogUtil.e("", "restart fail");
}
}
private static String getLauncherActivityName(Application application) {
Intent mainIntent = new Intent(Intent.ACTION_MAIN, null);
mainIntent.setPackage(application.getPackageName());
mainIntent.addCategory(Intent.CATEGORY_LAUNCHER);
// 通过查询，获得所有ResolveInfo对象.
List resolveInfos = application.getPackageManager()
.queryIntentActivities(mainIntent, 0);
if (resolveInfos != null && !resolveInfos.isEmpty()) {
return resolveInfos.get(0).activityInfo.name;
}
return "";
}
}
}
通过如下代码进行注册
registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {
@Override
public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
RestartWatcher.watch(activity, savedInstanceState);
}
...
}
因为app重启本质上是和权限设置相关，所以可以考虑将这部分的代码挪到权限库当中。
总结：
到此就将自己在改造app权限时遇到的三个问题都阐述完毕了，除了第一个问题可能和公司内部权限库实现相关外，剩下的两个问题应该是比较共性的问题。文章分享了自己在解决上述问题时的思路，不一定是最合理的方案，但是可以给其他人一些参考。