如何用不同的方式來處理安卓的權限管理？

隨著 Marshmallow 的發布，安卓增加了一種新的權限管理模式，要求開發者們采用一種不同的方式來處理安卓的權限管理。在本系列文章中，我們將會從技術角度和如何提供流暢用戶體驗的角度來探討權限問題的處理方法。（#Permissions – Part 1）

在深入探討之前，必須先說明一點：一個 app 需要的權限實際分為以下兩種：app 操作的核心權限——如果沒有這些核心權限，應用程序就無法正確運行；以及輔助功能所需的權限。舉個例子，對于一個拍照 app 來說，CAMERA 權限是核心功能的一部分——不能拍照的拍照 app 完全沒用。不過，還有一些額外功能，例如為照片標記拍攝地點（需要開啟ACCESS_FINE_LOCATION），但是沒有這些功能 app 也可以正常使用。

接下來的系列文章中，我們將要以某個 app 為例展開討論，但是要想正常使用，需要開啟兩個權限： RECORD_AUDIO 和 MODIFY_AUDIO_SETTINGS。為了獲得這些權限，我們必須按照常規在 Manifest 中聲明：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools"
  package="com.stylingandroid.permissions">
 
  <uses-permission android:name="android.permission.RECORD_AUDIO" />
  <uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
 
  <application
    android:allowBackup="false"
    android:fullBackupContent="false"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:supportsRtl="true"
    android:theme="@style/AppTheme.NoActionBar"
    tools:ignore="GoogleAppIndexingWarning">
 
    <activity android:name=".MainActivity" />
 
    <activity
      android:name=".PermissionsActivity"
      android:label="@string/title_activity_permissions"
      android:theme="@style/AppTheme.NoActionBar">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
 
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
  </application>
 
</manifest>

這是從 API 1就開始執行的安卓權限聲明的標準操作。但是，一旦我們指定 targetSdkVersion 23 或其后版本，我們還需要請求開放運行時所需的權限。這一點非常重要，因為已經有很多失敗案例，開發者直接將 targetSdkVersion 更新到最新版本，卻發現他們的 app 總是崩潰，這是因為他們沒有實現請求運行時所需權限的代碼。如果你在Google Play 應用商店發布了基于 API 23 或之后版本的 app，之后你就無法用基于更低版本開發的 APK 替換此 app，這就成了大問題。

另外在這里需要說明的是，現在已經有很多庫可以簡化運行權限的請求流程。它們的效果和用處各不相同，但是筆者覺得關鍵是在使用之前，先理解基本流程，否則就會因為不了解所選庫的實際功能而出現問題。這也是促成本系列文章的主要原因。

我們請求的兩個權限實際上屬于不同的類別：RECORD_AUDIO 被看做是一個高風險的權限，MODIFY_AUDIO_SETTINGS 則被看做是低風險的權限。高風險權限指的是那些可能危害安全或隱私的權限；而低風險權限指的是需要訪問 app 域以外的資源，但是對用戶的隱私幾乎沒有危害。低風險權限將會被系統自動批準使用，而高風險權限則需要運行時用戶明確授權。

在這個流程中，首先要做的是確定我們是否已經獲得所需權限。在 API 23 中，Context 增加了一些新方法來檢驗是否已經獲得某項權限。但是，使用 ContextCompat 總是比直接使用 Context、并且進行 API 層面的檢查更好：

class PermissionsChecker {
    private final Context context;
 
    public PermissionsChecker(Context context) {
        this.context = context;
    }
 
    public boolean lacksPermissions(String... permissions) {
        for (String permission : permissions) {
            if (lacksPermission(permission)) {
                return true;
            }
        }
        return false;
    }
 
    private boolean lacksPermission(String permission) {
        return ContextCompat.checkSelfPermission(context, permission) == PackageManager.PERMISSION_DENIED;
    }
 
}

這點其實很簡單——ContextCompat#checkSelfPermission 方法的作用不言自明，它會返回 PackageManager.PERMISSION_DENIED 或者 PackageManager.PERMISSION_GRANTED。筆者還增加了更進一步的邏輯，可用于檢查一個 app 是否已經獲得所需權限。

這里有必要重申 ContextCompat 的作用。在未升級到 Marshmallow系統、不支持新的運行權限管理模式的設備上運行 checkSelfPermission() 方法時，總會返回 PackageManger.PERMISSION_GRANTED——在舊的操作系統中，權限已經得到隱式授權，因此我們只需要通過 Manifest 聲明，就能實現適用于所有操作系統的方法，也不需要在代碼中寫入任何 API 層面的特定檢查。

以防你不明白為什么筆者要專門講解這個問題，原因是之后我們要在 app 內的所有 Activity 中進行這些檢查。因此，如果能夠將邏輯檢查與 Activity 區別開來，就能減少重復，提高代碼的可維護性。

要想在 Activity 中實際使用該方法，我們只需用 Activity 所需的權限列表來調用之：