各位小伙伴們大家早上好，不知道你的《第三行代碼》已經(jīng)讀到哪里了？

有些朋友的閱讀速度真是令人印象深刻，我記得在《第三行代碼》剛剛發(fā)售一周不到的時間里，竟然就有人已經(jīng)讀到第9章了（因為公眾號后臺有人回復(fù)第9章里隱藏的關(guān)鍵字）。現(xiàn)在，《第三行代碼》已經(jīng)出版一個月有余了，相信已經(jīng)有不少朋友將全本書都看完了。

全書都看完的朋友一定知道，《第三行代碼》的最后一章是帶著大家一起開發(fā)了一個開源庫：PermissionX。這一章的主旨是為了讓你了解一個開源庫整體的開發(fā)與發(fā)布過程，為了更好地演示這個過程，我想到了去寫PermissionX這樣一個庫。

不過，書中PermissionX庫的整體功能還是比較簡單的，因為這一章的重點不在于如何將開源庫做得完善與強大，而是強調(diào)的一個開發(fā)與發(fā)布的過程。

但是后來，我覺得PermissionX確實可以做成一個真正用于簡化Android運行時權(quán)限處理的庫，它所存在的意義應(yīng)該不僅限于書中的教學(xué)目的，而是可以真的應(yīng)用到實際的項目當(dāng)中，幫助大家解決處理運行時權(quán)限的痛點。

所以，后期我又對PermissionX進行了諸多功能拓展，現(xiàn)在已經(jīng)達到對外發(fā)布的標準了，那么今天正式向大家宣布：PermissionX已經(jīng)上線！

源碼庫地址是：https://github.com/guolindev/PermissionX

痛點在哪里？

沒有人愿意編寫處理Android運行時權(quán)限的代碼，因為它真的太繁瑣了。

這是一項沒有什么技術(shù)含量，但是你又不得不去處理的工作，因為不處理它程序就會崩潰。但如果處理起來比較簡單也就算了，可事實上，Android提供給我們的運行時權(quán)限API并不友好。

以一個撥打電話的功能為例，因為CALL_PHONE權(quán)限是危險權(quán)限，所以在我們除了要在AndroidManifest.xml中聲明權(quán)限之外，還要在執(zhí)行撥打電話操作之前進行運行時權(quán)限處理才行。

權(quán)限聲明如下：

<manifest xmlns:android='http://schemas.android.com/apk/res/android' package='com.permissionx.app'> <uses-permission android:name='android.permission.CALL_PHONE' />...</manifest>

然后，編寫如下代碼來進行運行時權(quán)限處理：

class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) makeCallBtn.setOnClickListener { if (ContextCompat.checkSelfPermission(this, Manifest.permission.CALL_PHONE) == PackageManager.PERMISSION_GRANTED) {call() } else {ActivityCompat.requestPermissions(this, arrayOf(Manifest.permission.CALL_PHONE), 1) } } } override fun onRequestPermissionsResult(requestCode: Int, permissions: Array<String>, grantResults: IntArray) { super.onRequestPermissionsResult(requestCode, permissions, grantResults) when (requestCode) { 1 -> {if (grantResults.isNotEmpty() && grantResults[0] == PackageManager.PERMISSION_GRANTED) { call()} else { Toast.makeText(this, 'You denied CALL_PHONE permission', Toast.LENGTH_SHORT).show()} } } } private fun call() { try { val intent = Intent(Intent.ACTION_CALL) intent.data = Uri.parse('tel:10086') startActivity(intent) } catch (e: SecurityException) { e.printStackTrace() } }}

這段代碼中真有正意義的功能邏輯就是call()方法中的內(nèi)容，可是如果直接調(diào)用call()方法是無法實現(xiàn)撥打電話功能的，因為我們還沒有申請CALL_PHONE權(quán)限。

那么整段代碼其他的部分就都是在處理CALL_PHONE權(quán)限申請。可以看到，這里需要先判斷用戶是否已授權(quán)我們撥打電話的權(quán)限，如果沒有的話則要進行權(quán)限申請，然后還要在onRequestPermissionsResult()回調(diào)中處理權(quán)限申請的結(jié)果，最后才能去執(zhí)行撥打電話的操作。

你可能覺得，這也不算是很繁瑣呀，代碼量并不是很多。那是因為，目前我們還只是處理了運行時權(quán)限最簡單的場景，而實際的項目環(huán)境中有著更加復(fù)雜的場景在等著我們。

比如說，你的App可能并不只是單單申請一個權(quán)限，而是需要同時申請多個權(quán)限。雖然ActivityCompat.requestPermissions()方法允許一次性傳入多個權(quán)限名，但是你在onRequestPermissionsResult()回調(diào)中就需要判斷哪些權(quán)限被允許了，哪些權(quán)限被拒絕了，被拒絕的權(quán)限是否影響到應(yīng)用程序的核心功能，以及是否要再次申請權(quán)限。

而一旦牽扯到再次申請權(quán)限，就引出了一個更加復(fù)雜的問題。你申請的權(quán)限被用戶拒絕過了一次，那么再次申請將很有可能再次被拒絕。為此，Android提供了一個shouldShowRequestPermissionRationale()方法，用于判斷是否需要向用戶解釋申請這個權(quán)限的原因，一旦shouldShowRequestPermissionRationale()方法返回true，那么我們最好彈出一個對話框來向用戶闡明為什么我們是需要這個權(quán)限的，這樣可以增加用戶同意授權(quán)的幾率。

是不是已經(jīng)覺得很復(fù)雜了？不過還沒完，Android系統(tǒng)還提供了一個“拒絕，不要再詢問”的選項，如下圖所示：

只要用戶選擇了這個選項，那么我們以后每次執(zhí)行權(quán)限申請的代碼都將會直接被拒絕。

可是如果我的某項功能就是必須要依賴這個權(quán)限才行呢？沒有辦法，你只能提示用戶去應(yīng)用程序設(shè)置當(dāng)中手動打開權(quán)限，程序方面已無法進行操作。

可以看出，如果想要在項目中對運行時權(quán)限做出非常全面的處理，是一件相當(dāng)復(fù)雜的事情。事實上，大部分的項目都沒有將權(quán)限申請這塊處理得十分恰當(dāng)，這也是我編寫PermissionX的理由。

PermissionX的實現(xiàn)原理

在開始介紹PermissionX的具體用法之前，我們先來討論一下它的實現(xiàn)原理。

其實之前并不是沒有人嘗試過對運行時權(quán)限處理進行封裝，我之前在做直播公開課的時候也向大家演示過一種運行時權(quán)限API的封裝過程。

但是，想要對運行時權(quán)限的API進行封裝并不是一件容易的事，因為這個操作是有特定的上下文依賴的，一般需要在Activity中接收onRequestPermissionsResult()方法的回調(diào)才行，所以不能簡單地將整個操作封裝到一個獨立的類中。

為此，也衍生出了一系列特殊的封裝方案，比如將運行時權(quán)限的操作封裝到BaseActivity中，或者提供一個透明的Activity來處理運行時權(quán)限等。

不過上述兩種方案都不夠輕量，因為改變Activity的繼承結(jié)構(gòu)這可是大事情，而提供一個透明的Activty則需要在AndroidManifest.xml中進行額外的聲明。

現(xiàn)在，業(yè)內(nèi)普遍比較認可使用另外一種小技巧來進行實現(xiàn)。是什么小技巧呢？回想一下，之前所有申請運行時權(quán)限的操作都是在Activity中進行的，事實上，Android在Fragment中也提供了一份相同的API，使得我們在Fragment中也能申請運行時權(quán)限。

但不同的是，F(xiàn)ragment并不像Activity那樣必須有界面，我們完全可以向Activity中添加一個隱藏的Fragment，然后在這個隱藏的Fragment中對運行時權(quán)限的API進行封裝。這是一種非常輕量級的做法，不用擔(dān)心隱藏Fragment會對Activity的性能造成什么影響。

這就是PermissionX的實現(xiàn)原理了，書中其實也已經(jīng)介紹過了這部分內(nèi)容。但是，在其實現(xiàn)原理的基礎(chǔ)之上，后期我又增加了很多新功能，讓PermissionX變得更加強大和好用，下面我們就來學(xué)習(xí)一下PermissionX的具體用法。

基本用法

要使用PermissionX之前，首先需要將其引入到項目當(dāng)中，如下所示：

dependencies {...implementation ’com.permissionx.guolindev:permissionx:1.1.1’}

我在寫本篇文章時PermissionX的最新版本是1.1.1，想要查看它的當(dāng)前最新版本，請訪問PermissionX的主頁：https://github.com/guolindev/PermissionX

PermissionX的目的是為了讓運行時權(quán)限處理盡可能的容易，因此怎么讓API變得簡單好用就是我優(yōu)先要考慮的問題。

比如同樣實現(xiàn)撥打電話的功能，使用PermissionX只需要這樣寫：

class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) makeCallBtn.setOnClickListener { PermissionX.init(this).permissions(Manifest.permission.CALL_PHONE).request { allGranted, grantedList, deniedList -> if (allGranted) { call() } else { Toast.makeText(this, '您拒絕了撥打電話權(quán)限', Toast.LENGTH_SHORT).show() }} } } ...}

是的，PermissionX的基本用法就這么簡單。首先調(diào)用init()方法來進行初始化，并在初始化的時候傳入一個FragmentActivity參數(shù)。由于AppCompatActivity是FragmentActivity的子類，所以只要你的Activity是繼承自AppCompatActivity的，那么直接傳入this就可以了。

接下來調(diào)用permissions()方法傳入你要申請的權(quán)限名，這里傳入CALL_PHONE權(quán)限。你也可以在permissions()方法中傳入任意多個權(quán)限名，中間用逗號隔開即可。

最后調(diào)用request()方法來執(zhí)行權(quán)限申請，并在Lambda表達式中處理申請結(jié)果。可以看到，Lambda表達式中有3個參數(shù)：allGranted表示是否所有申請的權(quán)限都已被授權(quán)，grantedList用于記錄所有已被授權(quán)的權(quán)限，deniedList用于記錄所有被拒絕的權(quán)限。

因為我們只申請了一個CALL_PHONE權(quán)限，因此這里直接判斷：如果allGranted為true，那么就調(diào)用call()方法，否則彈出一個Toast提示。

運行結(jié)果如下：

怎么樣？對比之前的寫法，是不是覺得運行時權(quán)限處理沒那么繁瑣了？

核心用法

然而我們目前還只是處理了最普通的場景，剛才提到的，假如用戶拒絕了某個權(quán)限，在下次申請之前，我們最好彈出一個對話框來向用戶解釋申請這個權(quán)限的原因，這個又該怎么實現(xiàn)呢？

別擔(dān)心，PermissionX對這些情況進行了充分的考慮。

onExplainRequestReason()方法可以用于監(jiān)聽那些被用戶拒絕，而又可以再次去申請的權(quán)限。從方法名上也可以看出來了，應(yīng)該在這個方法中解釋申請這些權(quán)限的原因。

而我們只需要將onExplainRequestReason()方法串接到request()方法之前即可，如下所示：

PermissionX.init(this) .permissions(Manifest.permission.CAMERA, Manifest.permission.READ_CONTACTS, Manifest.permission.CALL_PHONE) .onExplainRequestReason { deniedList -> } .request { allGranted, grantedList, deniedList -> if (allGranted) { Toast.makeText(this, '所有申請的權(quán)限都已通過', Toast.LENGTH_SHORT).show() } else { Toast.makeText(this, '您拒絕了如下權(quán)限：$deniedList', Toast.LENGTH_SHORT).show() } }

這種情況下，所有被用戶拒絕的權(quán)限會優(yōu)先進入onExplainRequestReason()方法進行處理，拒絕的權(quán)限都記錄在deniedList參數(shù)當(dāng)中。接下來，我們只需要在這個方法中調(diào)用showRequestReasonDialog()方法，即可彈出解釋權(quán)限申請原因的對話框，如下所示：

PermissionX.init(this) .permissions(Manifest.permission.CAMERA, Manifest.permission.READ_CONTACTS, Manifest.permission.CALL_PHONE) .onExplainRequestReason { deniedList -> showRequestReasonDialog(deniedList, '即將重新申請的權(quán)限是程序必須依賴的權(quán)限', '我已明白', '取消') } .request { allGranted, grantedList, deniedList -> if (allGranted) { Toast.makeText(this, '所有申請的權(quán)限都已通過', Toast.LENGTH_SHORT).show() } else { Toast.makeText(this, '您拒絕了如下權(quán)限：$deniedList', Toast.LENGTH_SHORT).show() } }

showRequestReasonDialog()方法接受4個參數(shù)：第一個參數(shù)是要重新申請的權(quán)限列表，這里直接將deniedList參數(shù)傳入。第二個參數(shù)則是要向用戶解釋的原因，我只是隨便寫了一句話，這個參數(shù)描述的越詳細越好。第三個參數(shù)是對話框上確定按鈕的文字，點擊該按鈕后將會重新執(zhí)行權(quán)限申請操作。第四個參數(shù)是一個可選參數(shù)，如果不傳的話相當(dāng)于用戶必須同意申請的這些權(quán)限，否則對話框無法關(guān)閉，而如果傳入的話，對話框上會有一個取消按鈕，點擊取消后不會重新進行權(quán)限申請，而是會把當(dāng)前的申請結(jié)果回調(diào)到request()方法當(dāng)中。

另外始終要記得將所有申請的權(quán)限都在AndroidManifest.xml中進行聲明：

<manifest xmlns:android='http://schemas.android.com/apk/res/android' package='com.permissionx.app'> <uses-permission android:name='android.permission.READ_CONTACTS' /> <uses-permission android:name='android.permission.CAMERA' /> <uses-permission android:name='android.permission.CALL_PHONE' />...</manifest>

重新運行一下程序，效果如下圖所示：

目前解釋權(quán)限申請原因?qū)υ捒虻臉邮綍簳r還無法自定義，下個版本當(dāng)中，我會加入自定義對話框樣式的功能。

當(dāng)然，我們也可以指定要對哪些權(quán)限重新申請，比如上述申請的3個權(quán)限中，我認為CAMERA權(quán)限是必不可少的，而其他兩個權(quán)限則可有可無，那么在重新申請的時候也可以只申請CAMERA權(quán)限：

PermissionX.init(this) .permissions(Manifest.permission.CAMERA, Manifest.permission.READ_CONTACTS, Manifest.permission.ACCESS_FINE_LOCATION) .onExplainRequestReason { deniedList -> val filteredList = deniedList.filter { it == Manifest.permission.CAMERA } showRequestReasonDialog(filteredList, '攝像機權(quán)限是程序必須依賴的權(quán)限', '我已明白', '取消') } .request { allGranted, grantedList, deniedList -> if (allGranted) { Toast.makeText(this, '所有申請的權(quán)限都已通過', Toast.LENGTH_SHORT).show() } else { Toast.makeText(this, '您拒絕了如下權(quán)限：$deniedList', Toast.LENGTH_SHORT).show() } }

這樣當(dāng)再次申請權(quán)限的時候就只會申請CAMERA權(quán)限，剩下的兩個權(quán)限最終會被傳入到request()方法的deniedList參數(shù)當(dāng)中。

解決了向用戶解釋權(quán)限申請原因的問題，接下來還有一個頭疼的問題要解決：如果用戶不理會我們的解釋，仍然執(zhí)意拒絕權(quán)限申請，并且還選擇了拒絕且不再詢問的選項，這該怎么辦？通常這種情況下，程序?qū)用嬉呀?jīng)無法再次做出權(quán)限申請，唯一能做的就是提示用戶到應(yīng)用程序設(shè)置當(dāng)中手動打開權(quán)限。

那么PermissionX是如何處理這種情況的呢？我相信絕對會給你帶來驚喜。PermissionX中還提供了一個onForwardToSettings()方法，專門用于監(jiān)聽那些被用戶永久拒絕的權(quán)限。另外從方法名上就可以看出，我們可以在這里提醒用戶手動去應(yīng)用程序設(shè)置當(dāng)中打開權(quán)限。代碼如下所示：

PermissionX.init(this) .permissions(Manifest.permission.CAMERA, Manifest.permission.READ_CONTACTS, Manifest.permission.CALL_PHONE) .onExplainRequestReason { deniedList -> showRequestReasonDialog(deniedList, '即將重新申請的權(quán)限是程序必須依賴的權(quán)限', '我已明白', '取消') } .onForwardToSettings { deniedList -> showForwardToSettingsDialog(deniedList, '您需要去應(yīng)用程序設(shè)置當(dāng)中手動開啟權(quán)限', '我已明白', '取消') } .request { allGranted, grantedList, deniedList -> if (allGranted) { Toast.makeText(this, '所有申請的權(quán)限都已通過', Toast.LENGTH_SHORT).show() } else { Toast.makeText(this, '您拒絕了如下權(quán)限：$deniedList', Toast.LENGTH_SHORT).show() } }

可以看到，這里又串接了一個onForwardToSettings()方法，所有被用戶選擇了拒絕且不再詢問的權(quán)限都會進行到這個方法中處理，拒絕的權(quán)限都記錄在deniedList參數(shù)當(dāng)中。

接下來，你并不需要自己彈出一個Toast或是對話框來提醒用戶手動去應(yīng)用程序設(shè)置當(dāng)中打開權(quán)限，而是直接調(diào)用showForwardToSettingsDialog()方法即可。類似地，showForwardToSettingsDialog()方法也接收4個參數(shù)，每個參數(shù)的作用和剛才的showRequestReasonDialog()方法完全一致，我這里就不再重復(fù)解釋了。

showForwardToSettingsDialog()方法將會彈出一個對話框，當(dāng)用戶點擊對話框上的我已明白按鈕時，將會自動跳轉(zhuǎn)到當(dāng)前應(yīng)用程序的設(shè)置界面，從而不需要用戶自己慢慢進入設(shè)置當(dāng)中尋找當(dāng)前應(yīng)用了。另外，當(dāng)用戶從設(shè)置中返回時，PermissionX將會自動重新請求相應(yīng)的權(quán)限，并將最終的授權(quán)結(jié)果回調(diào)到request()方法當(dāng)中。效果如下圖所示：

同樣，下個版本當(dāng)中，我也會加入自定義這個對話框樣式的功能。

更多用法

PermissionX最主要的功能大概就是這些，不過我在使用一些App的時候發(fā)現(xiàn)，有些App喜歡在第一次請求權(quán)限之前就先彈出一個對話框向用戶解釋自己需要哪些權(quán)限，然后才會進行權(quán)限申請。這種做法是比較提倡的，因為用戶同意授權(quán)的概率會更高。

那么PermissionX中要如何實現(xiàn)這樣的功能呢？

其實非常簡單，PermissionX還提供了一個explainReasonBeforeRequest()方法，只需要將它也串接到request()方法之前就可以了，代碼如下所示：

PermissionX.init(this) .permissions(Manifest.permission.CAMERA, Manifest.permission.READ_CONTACTS, Manifest.permission.CALL_PHONE).explainReasonBeforeRequest() .onExplainRequestReason { deniedList -> showRequestReasonDialog(deniedList, '即將申請的權(quán)限是程序必須依賴的權(quán)限', '我已明白') } .onForwardToSettings { deniedList -> showForwardToSettingsDialog(deniedList, '您需要去應(yīng)用程序設(shè)置當(dāng)中手動開啟權(quán)限', '我已明白') } .request { allGranted, grantedList, deniedList -> if (allGranted) { Toast.makeText(this, '所有申請的權(quán)限都已通過', Toast.LENGTH_SHORT).show() } else { Toast.makeText(this, '您拒絕了如下權(quán)限：$deniedList', Toast.LENGTH_SHORT).show() } }

這樣，當(dāng)每次請求權(quán)限時，會優(yōu)先進入onExplainRequestReason()方法，彈出解釋權(quán)限申請原因的對話框，用戶點擊我已明白按鈕之后才會執(zhí)行權(quán)限申請。效果如下圖所示：

不過，你在使用explainReasonBeforeRequest()方法時，其實還有一些關(guān)鍵的點需要注意。

第一，單獨使用explainReasonBeforeRequest()方法是無效的，必須配合onExplainRequestReason()方法一起使用才能起作用。這個很好理解，因為沒有配置onExplainRequestReason()方法，我們怎么向用戶解釋權(quán)限申請原因呢？

第二，在使用explainReasonBeforeRequest()方法時，如果onExplainRequestReason()方法中編寫了權(quán)限過濾的邏輯，最終的運行結(jié)果可能和你期望的會不一致。這一點可能會稍微有點難理解，我用一個具體的示例來解釋一下。

觀察如下代碼：

PermissionX.init(this) .permissions(Manifest.permission.CAMERA, Manifest.permission.READ_CONTACTS, Manifest.permission.CALL_PHONE).explainReasonBeforeRequest() .onExplainRequestReason { deniedList -> val filteredList = deniedList.filter { it == Manifest.permission.CAMERA } showRequestReasonDialog(filteredList, '攝像機權(quán)限是程序必須依賴的權(quán)限', '我已明白') } ...

這里在onExplainRequestReason()方法中編寫了剛才用到的權(quán)限過濾邏輯，當(dāng)有多個權(quán)限被拒絕時，我們只重新申請CAMERA權(quán)限。

在沒有加入explainReasonBeforeRequest()方法時，一切都可以按照我們所預(yù)期的那樣正常運行。但如果加上了explainReasonBeforeRequest()方法，在執(zhí)行權(quán)限請求之前會先進入onExplainRequestReason()方法，而這里將除了CAMERA之外的其他權(quán)限都過濾掉了，因此實際上PermissionX只會請求CAMERA這一個權(quán)限，剩下的權(quán)限將完全不會嘗試去請求，而是直接作為被拒絕的權(quán)限回調(diào)到最終的request()方法當(dāng)中。

效果如下圖所示：

針對于這種情況，PermissionX在onExplainRequestReason()方法中提供了一個額外的beforeRequest參數(shù)，用于標識當(dāng)前上下文是在權(quán)限請求之前還是之后，借助這個參數(shù)在onExplainRequestReason()方法中執(zhí)行不同的邏輯，即可很好地解決這個問題，示例代碼如下：

PermissionX.init(this) .permissions(Manifest.permission.CAMERA, Manifest.permission.READ_CONTACTS, Manifest.permission.CALL_PHONE).explainReasonBeforeRequest() .onExplainRequestReason { deniedList, beforeRequest -> if (beforeRequest) { showRequestReasonDialog(deniedList, '為了保證程序正常工作，請您同意以下權(quán)限申請', '我已明白') } else { val filteredList = deniedList.filter {it == Manifest.permission.CAMERA } showRequestReasonDialog(filteredList, '攝像機權(quán)限是程序必須依賴的權(quán)限', '我已明白') } } ...

可以看到，當(dāng)beforeRequest為true時，說明此時還未執(zhí)行權(quán)限申請，那么我們將完整的deniedList傳入showRequestReasonDialog()方法當(dāng)中。

而當(dāng)beforeRequest為false時，說明某些權(quán)限被用戶拒絕了，此時我們只重新申請CAMERA權(quán)限，因為它是必不可少的，其他權(quán)限則可有可無。

最終運行效果如下：

Permission-Support

這個庫的名字叫PermissionX，因此不用多說，它肯定是與AndroidX兼容的。以防還有部分朋友不清楚AndroidX是什么的，這里有一篇我之前寫的科普文章 總是聽到有人說AndroidX，到底什么是AndroidX？

但是，我相信現(xiàn)在仍然存在很多項目沒有使用AndroidX，而是在繼續(xù)使用著之前的Android Support Library。為此，我又專門提供了一份面向Android Support Library的版本：Permission-Support。

在用法層面，兩個版本沒有任何區(qū)別，本文以上討論的所有內(nèi)容在Permission-Support上都適用。只是在引用庫的時候，如果你準備使用Permission-Support，請使用以下依賴庫地址：

dependencies {...implementation ’com.permissionx.guolindev:permission-support:1.1.1’}

不過，Android Support Library注定將會在不久的將來被Google完全淘汰，因此Permission-Support我也不會維護太久的時間，只是暫時過渡一下。而PermissionX我是準備長期維護下去的，并會持續(xù)增加更多好用的新功能。

后記

最后，一定也會有朋友想要詢問，Java語言的項目能不能使用PermissionX呢？

其實早在最開始的時候，我是打算將PermissionX設(shè)計成Kotlin和Java都可以通用的一個庫。但是寫著寫著發(fā)現(xiàn)，如果想要兼容Java語言，需要放棄很多Kotlin的語法特性，這樣PermissionX用起來就不再是那么簡潔了，最終只好選擇了放棄Java語言的支持。

不過等PermissionX整體功能穩(wěn)定下來之后，我可能會專門再編寫一個Java版的PermissionX。語法層面肯定要比Kotlin版的復(fù)雜不少，但是一定比你自己去處理運行時權(quán)限簡單得多。

新庫剛剛發(fā)布，可能還存在很多我自己沒能測出來的bug，也請大家?guī)兔Χ喽鄿y試，共同將這個庫變得更加完善。

再次貼上PermissionX的開源庫地址，歡迎大家star和fork。

https://github.com/guolindev/PermissionX

到此這篇關(guān)于Android運行時權(quán)限終極方案(PermissionX)的文章就介紹到這了,更多相關(guān)Android 運行時權(quán)限內(nèi)容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！