前言
Android6.0之后的有些權(quán)限需要去動態(tài)獲取，這個(gè)過程中呢扼倘，我們或許會遇到這么幾個(gè)方法确封。
1.ContextCompat.checkSelfPermission 檢查權(quán)限是否允許
2.ActivityCompat.requestPermissions 請求某個(gè)或某幾個(gè)權(quán)限
3.onRequestPermissionsResult 手動請求權(quán)限之后的結(jié)果回調(diào)
4.shouldShowRequestPermissionRationale ？再菊？爪喘？
其中前三個(gè)的用途都非常清楚，大家也都知道怎么用的纠拔，這里不做過多解釋秉剑，今天主要看下咱們的主角shouldShowRequestPermissionRationale，看下它是干什么用的稠诲。從shouldShowRequestPermissionRationale這么長的方法名侦鹏，解釋出來就是“應(yīng)不應(yīng)該解釋下請求這個(gè)權(quán)限的目的”诡曙，接下來，咱們先看它的官方注釋略水。
官方解釋
/**
? ? * Gets whether you should show UI with rationale for requesting a permission.
? ? * You should do this only if you do not have the permission and the context in
? ? * which the permission is requested does not clearly communicate to the user
? ? * what would be the benefit from granting this permission.
? ? * <p>
? ? * For example, if you write a camera app, requesting the camera permission
? ? * would be expected by the user and no rationale for why it is requested is
? ? * needed. If however, the app needs location for tagging photos then a non-tech
? ? * savvy user may wonder how location is related to taking photos. In this case
? ? * you may choose to show UI with rationale of requesting this permission.
? ? * </p>
? ? *
? ? * @param activity The target activity.
? ? * @param permission A permission your app wants to request.
? ? * @return Whether you can show permission rationale UI.
蹩腳翻譯
獲取是否應(yīng)顯示具有請求權(quán)限理由的UI价卤，只有在沒有權(quán)限并且上下文的情況下不能清晰明了的表明為什么需要這個(gè)權(quán)限時(shí)才應(yīng)該這樣做。舉例渊涝，你要是實(shí)現(xiàn)一個(gè)照相的app慎璧，用戶可以明白你為什么需要照相的權(quán)限，然而app卻需要定位信息去給照片做標(biāo)注跨释，一個(gè)非技術(shù)又精明的用戶可能很好奇一個(gè)拍照APP怎么會想要定位權(quán)限胸私。在這種情況下您可以選擇在請求定位權(quán)限之前先在UI上解釋下為什么需要它。
返回：你是否可以展示權(quán)限的解釋說明
看完之后你明白了嗎煤傍？講真盖文，我是真不明白，這段注釋只說明了Google工程師設(shè)計(jì)這個(gè)方法的初衷是什么蚯姆，具體有什么功能五续，怎么用的，從這里我真的還看不錯(cuò)來龄恋。
網(wǎng)絡(luò)資源參考
Android6.0動態(tài)權(quán)限shouldShowRequestPermissionRationale的含義這篇文章疙驾，說明的是比較有價(jià)值的：
以某個(gè)權(quán)限為例，
1.第一次請求權(quán)限時(shí)ActivityCompat.我使用的是8.0系統(tǒng)的手機(jī)=false;
2郭毕、第一次請求權(quán)限被禁止它碎，但未選擇【不再提醒】ActivityCompat.shouldShowRequestPermissionRationale=true;
3、允許某權(quán)限后ActivityCompat.shouldShowRequestPermissionRationale=false;
4显押、 禁止權(quán)限扳肛，并選中【禁止后不再詢問】ActivityCompat.shouldShowRequestPermissionRationale=false；
文章中記錄的結(jié)果和我真實(shí)手機(jī)跑程序打印的結(jié)果是一致的（我使用的是8.0系統(tǒng)的手機(jī)）乘碑。
shouldShowRequestPermissionRationale的功能價(jià)值何在
在此之前先說明下挖息，由于不同的系統(tǒng)廠商定制的結(jié)果，
1.有的手機(jī)某些權(quán)限清單注冊了權(quán)限就能用兽肤，不用動態(tài)申請（因?yàn)橄到y(tǒng)會在安裝時(shí)自動app分配一些權(quán)限套腹，具體怎么分配的這里暫不做討論）；
2.有的手機(jī)在彈出授權(quán)時(shí)選擇拒絕就默認(rèn)了不再彈出资铡；
3.有的沿用了原生系統(tǒng)的規(guī)則电禀；
4.設(shè)置-應(yīng)用-權(quán)限中權(quán)限分“允許、詢問笤休、拒絕”三個(gè)級別尖飞，但是有的權(quán)限只有“允許、拒絕”兩個(gè)級別；
這里先統(tǒng)一下名詞：
允許-- 權(quán)限通過
拒絕--拒絕了但是還允許詢問
禁止--拒絕了且不再允許詢問（如4中所述的“拒絕”先定義為禁止）
從前面就可以看出來葫松，這個(gè)方法大部分情況下是放回false的瓦糕，只有被用戶拒絕了權(quán)限，再次獲取才會得到true腋么；如果沒有申請過咕娄，或者禁止了權(quán)限，都是返回的false珊擂。所以很多人想要通過shouldShowRequestPermissionRationale去判斷是否權(quán)限被禁止圣勒，有時(shí)候是并不準(zhǔn)確的，真要說怎樣會準(zhǔn)確的獲取到權(quán)限被禁止的情況摧扇，那就是：
1.在requestPermissions之后在
onRequestPermissionsResult中獲取到?jīng)]給權(quán)限圣贸，并且shouldShowRequestPermissionRationale是false，此時(shí)可以認(rèn)定該權(quán)限被用戶禁止了扛稽；
2.還有一個(gè)點(diǎn)是是在onRequestPermissionsResult的參數(shù)值第三個(gè)參數(shù)grantResults是null,此時(shí)權(quán)限也是被拒絕的吁峻。（權(quán)限被拒絕后再次調(diào)用requestPermissions，沒有返回結(jié)果）
總結(jié)
shouldShowRequestPermissionRationale在张，回到最初的解釋“應(yīng)不應(yīng)該解釋下請求這個(gè)權(quán)限的目的”用含。
1.都沒有請求過這個(gè)權(quán)限，用戶不一定會拒絕你帮匾，所以你不用解釋啄骇，故返回false;
2.請求了但是被拒絕了，此時(shí)返回true瘟斜，意思是你該向用戶好好解釋下了缸夹；
3.請求權(quán)限被禁止了，也不給你彈窗提醒了螺句，所以你也不用解釋了虽惭，故返回fasle;
4.請求被允許了，都給你權(quán)限了蛇尚，還解釋個(gè)啥趟妥，故返回false。
Google的初衷大概就是第一次requestPermissions的時(shí)候被拒絕時(shí)給你一次解釋的機(jī)會佣蓉，所以是讓你在請求權(quán)限的回調(diào)中使用的。
其它
動態(tài)權(quán)限的適配就是檢測亲雪、請求勇凭，然后看回調(diào)，再通過了權(quán)限后再去執(zhí)行自己的方法义辕，但是真正用的時(shí)候又很麻煩虾标，每次調(diào)用相機(jī)、短信灌砖、打電話璧函、訪問通訊錄傀蚌、定位等等都要請求權(quán)限，寫一堆跟業(yè)務(wù)無關(guān)的代碼蘸吓，是不是很煩呢善炫？? 最近整理了一個(gè)關(guān)于方便管理動態(tài)權(quán)限的庫，[Android6.0動態(tài)權(quán)限獲瓤饧獭：一個(gè)EasyPermission的權(quán)限管理庫](http://www.reibang.com/p/671fbbb48551)
