在 Android6.0 之后运行时权限成了每个 App 必须面对的“硬核”挑战。hen多同学在项目里写了一堆 if‑else，结果代码像迷宫一样难以维护；还有的团队甚至直接把所有权限写进 Manifest，却忽略了用户的感受，导致评分直线下降。

今天我们不走寻常路，用一种geng温柔、geng系统的方式，把“请求‑判断‑回调”这三大环节捏合进一个轻量级工具类，让你的项目从此告别“Permission Hell”。下面我会一步步拆解需求、挑选核心 API、设计封装思路，并配上完整示例代码。准备好了吗？让我们一起把这道“菜”端上桌吧！

在真正动手之前，先把要实现的功Neng列出来——这一步往往被忽视，却是后期迭代的根基。

统一入口一次调用即可完成多个权限的批量请求。

状态感知区分「Yi授权」「未授权」「永久拒绝」三种状态。

灵活回调支持 Lambda/匿名内部类，也Neng自定义 UI 提示。

生命周期安全防止 Activity/Fragment 销毁后仍持有引用导致内存泄漏。

可 性以后想加日志或埋点，只需要在一个地方改动。

有了这些目标，我们才Neng在代码里写出「既简洁又强大」的实现。

权限请求与回调‑API：

// ActivityCompat.requestPermissions;
@Override
public void onRequestPermissionsResult(int requestCode,
                                         @NonNull String permissions,
                                         @NonNull int grantResults) { … }

权限判断‑API：

// ContextCompat.checkSelfPermission
int result = ContextCompat.checkSelfPermission;
if  { … }

有权限 → PackageManager.PERMISSION_GRANTED 无权限 → PackageManager.PERMISSION_DENIED

无权限且不再询问 → PackageManager.PERMISSION_DENIED + !activity.shouldShowRequestPermissionRationale

AOSP 为我们提供了两把钥匙：

ContextCompat.checkSelfPermission: 用来同步判断当前是否拥有某项许可。

ActivityCompat.requestPermissions: 发起弹窗请求，并将结果抛给回调方法。

不过仅靠这两招并不Neng覆盖所有场景——比如用户勾选了「不再提醒」后你必须自行引导去设置页。因此，一个完整的库需要把「shouldShowRequestPermissionRationale」也纳入判定链路。

先说说为什么我把这个过程比作烹饪——因为每一步dou需要配料和火候。Ru果火候太早或太晚，dou可Neng让成品变得苦涩。

public enum PermissionState {
    GRANTED,
    DENIED,
    PERMANENTLY_DENIED
}

public interface PermissionCallback {
    void onResult;
}

public final class PermissionHelper {
    private static volatile PermissionHelper sInstance;
    private final WeakReference mActivity;
    private PermissionHelper {
        mActivity = new WeakReference<>;
    }
    public static PermissionHelper with {
        if  {
            synchronized  {
                if  {
                    sInstance = new PermissionHelper;
                }
            }
        }
        return sInstance;
    }
    // …后续方法省略
}

public void checkAndRequest(@NonNull String perms,
                           @NonNull PermissionCallback callback) {
   Map status = new HashMap<>;
   List toRequest = new ArrayList<>;
   for  {
       int res = ContextCompat.checkSelfPermission, p);
       if  {
           status.put;
       } else if .shouldShowRequestPermissionRationale) {
           status.put;
       } else {
           status.put;
           toRequest.add;
       }
   }
   if ) {
       callback.onResult;
       return;
   }
   // 发起真正的系统弹窗
   ActivityCompat.requestPermissions,
           toRequest.toArray,
           REQUEST_CODE);
   // 将 callback 暂存，以便 onRequestPermissionsResult 中使用
   mPendingCallback = callback;
}

@Override
public void onRequestPermissionsResult(int requestCode,
                                     @NonNull String permissions,
                                     @NonNull int grantResults) {
   if  return;
   Map resultMap = new HashMap<>;
   for  {
       if  {
           resultMap.put;
       } else if ) {
           resultMap.put;
       } else {
           resultMap.put;
       }
   }
   // 合并之前Yi判断好的状态
   mPendingCallback.onResult;
}

AOP 思维告诉我们：「调用方只需要声明需求，框架负责执行」。下面给出一个完整示例，展示从声明到处理全流程：

public class MainActivity extends AppCompatActivity {
    private static final String REQUIRED_PERMS = new String{
            Manifest.permission.CAMERA,
            Manifest.permission.READ_EXTERNAL_STORAGE,
            Manifest.permission.ACCESS_FINE_LOCATION};
    @Override
    protected void onCreate {
        super.onCreate;
        setContentView;
        // 开始上菜~
        PermissionHelper.with
                .checkAndRequest;
    }
    private void handlePermissionResult {
        // 小贴士tips: 这里Ke以直接根据状态决定下一步操作
        boolean allGranted = true;
        for ) {
            switch ) {
                case GRANTED:
                    Log.d + " Yi授权");
                    break;
                case DENIED:
                    allGranted = false;
                    Toast.makeText(this,
                            e.getKey + " 被拒绝，需要重新申请", Toast.LENGTH_SHORT).show;
                    break;
                case PERMANENTLY_DENIED:
                    allGranted = false;
                    showSettingDialog);
                    break;
            }
        }
        if  {
            // 权限全部 OK，继续业务逻辑
            startCameraPreview;
        }
    }
    private void showSettingDialog {
        new AlertDialog.Builder
                .setTitle
                .setMessage
                .setPositiveButton->{
                    Intent intent = new Intent;
                    Uri uri = Uri.fromParts, null);
                    intent.setData;
                    startActivity;
                })
                .setNegativeButton
                .show;
}
@Override
public void onRequestPermissionsResult(int requestCode,
                                     @NonNull String permissions,
                                     @NonNull int grantResults) {
     super.onRequestPermissionsResult;
     // 将结果交给帮助类处理
     PermissionHelper.with.onRequestPermissionsResult(requestCode,
                                                            permissions,
                                                            grantResults);
}
}

kan完这段代码，你会发现原本散乱的「if…else」Yi经被整齐地收进了一个类里；而业务层只要关注「是否全部通过」这一件事，再也不用为每个 permission 写重复代码。哎呀，这种轻盈感真的让人忍不住想给自己鼓掌！👏

记得使用 WeakReference 包裹 Activity/Fragment：否则在页面销毁后仍持有强引用会导致内存泄漏。尤其是长时间等待用户操作时geng要小心。

"shouldShowRequestPermissionRationale" 并非一次性判断：a/b 两次dou返回 false 时才说明是真正的永久拒绝。别忘记在弹窗解释完毕后 检查一次！

"REQUEST_CODE" 必须唯一：A 项目里若有多个库同时使用 runtime permission，请务必约定不同区间，否则会出现结果错位的问题。

"Fragment" 场景下同样适用：AFAIK，只要把 Activity 换成 Fragment 的 getContext 并转成 FragmentActivity 即可。Ru果你用的是 Jetpack Navigation，请把帮助类注入 ViewModel 中，以免因 Fragment 重建丢失回调。

"兼容 Android 10+" 的分区存储限制：a/b 对文件访问进行额外授权，请结合 Storage Access Framework 或 MediaStore 使用，否则即便拿到了读写许可也会出现 “文件不可见”。

温馨提醒：不要在主线程里Zuo大量磁盘 IO，否则即使拥有读写许可，也可Neng因为卡顿被系统判为 ANR，影响用户体验哦！

"方案1这菜有点老，我们整点新鲜的方案2。" 正如上文所述，把繁琐且易错的运行时权限逻辑抽象为一个独立模块，你不仅Neng提升代码可读性，还Neng在团队协作中快速统一标准。geng重要的是这套方案天然支持 Kotlin 协程、LiveData 或 RxJava，只要把 callback 成对应类型，即可无缝接入现有架构。

Ru果你Yi经按照本文步骤实现了自己的工具库，请大胆分享到社区，让geng多开发者受益；Ru果还有疑惑，欢迎在评论区留言，我会抽空帮你排查细节。祝大家编码愉快，App 下载量一路飙升！ 🎉