前言
Android6.0之后的有些權(quán)限需要去動態(tài)獲取捡偏，這個過程中呢唤冈，我們或許會遇到這么幾個方法。
1.ContextCompat.checkSelfPermission 檢查權(quán)限是否允許
2.ActivityCompat.requestPermissions 請求某個或某幾個權(quán)限
3.onRequestPermissionsResult 手動請求權(quán)限之后的結(jié)果回調(diào)
4.shouldShowRequestPermissionRationale 银伟？你虹？？
其中前三個的用途都非常清楚彤避，大家也都知道怎么用的傅物，這里不做過多解釋，今天主要看下咱們的主角shouldShowRequestPermissionRationale琉预，看下它是干什么用的董饰。從shouldShowRequestPermissionRationale這么長的方法名，解釋出來就是“應(yīng)不應(yīng)該解釋下請求這個權(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)限并且上下文的情況下不能清晰明了的表明為什么需要這個權(quán)限時才應(yīng)該這樣做也祠。舉例，你要是實現(xiàn)一個照相的app近速，用戶可以明白你為什么需要照相的權(quán)限诈嘿，然而app卻需要定位信息去給照片做標注，一個非技術(shù)又精明的用戶可能很好奇一個拍照APP怎么會想要定位權(quán)限数焊。在這種情況下您可以選擇在請求定位權(quán)限之前先在UI上解釋下為什么需要它永淌。
返回：你是否可以展示權(quán)限的解釋說明
看完之后你明白了嗎？講真佩耳，我是真不明白遂蛀，這段注釋只說明了Google工程師設(shè)計這個方法的初衷是什么，具體有什么功能干厚，怎么用的李滴，從這里我真的還看不錯來。
網(wǎng)絡(luò)資源參考
Android6.0動態(tài)權(quán)限shouldShowRequestPermissionRationale的含義這篇文章蛮瞄，說明的是比較有價值的：
以某個權(quán)限為例所坯，
1.第一次請求權(quán)限時ActivityCompat.我使用的是8.0系統(tǒng)的手機=false;
2、第一次請求權(quán)限被禁止挂捅，但未選擇【不再提醒】ActivityCompat.shouldShowRequestPermissionRationale=true;
3芹助、允許某權(quán)限后ActivityCompat.shouldShowRequestPermissionRationale=false;
4、 禁止權(quán)限，并選中【禁止后不再詢問】ActivityCompat.shouldShowRequestPermissionRationale=false状土；
文章中記錄的結(jié)果和我真實手機跑程序打印的結(jié)果是一致的（我使用的是8.0系統(tǒng)的手機）无蜂。
shouldShowRequestPermissionRationale的功能價值何在
在此之前先說明下，由于不同的系統(tǒng)廠商定制的結(jié)果蒙谓，
1.有的手機某些權(quán)限清單注冊了權(quán)限就能用斥季，不用動態(tài)申請（因為系統(tǒng)會在安裝時自動app分配一些權(quán)限，具體怎么分配的這里暫不做討論）累驮；
2.有的手機在彈出授權(quán)時選擇拒絕就默認了不再彈出酣倾；
3.有的沿用了原生系統(tǒng)的規(guī)則；
4.設(shè)置-應(yīng)用-權(quán)限中權(quán)限分“允許谤专、詢問躁锡、拒絕”三個級別，但是有的權(quán)限只有“允許毒租、拒絕”兩個級別稚铣；
這里先統(tǒng)一下名詞：
允許 -- 權(quán)限通過
拒絕--拒絕了但是還允許詢問
禁止--拒絕了且不再允許詢問（如4中所述的“拒絕”先定義為禁止）
從前面就可以看出來，這個方法大部分情況下是放回false的墅垮，只有被用戶拒絕了權(quán)限惕医，再次獲取才會得到true；如果沒有申請過算色，或者禁止了權(quán)限抬伺，都是返回的false。所以很多人想要通過shouldShowRequestPermissionRationale去判斷是否權(quán)限被禁止灾梦，有時候是并不準確的峡钓，真要說怎樣會準確的獲取到權(quán)限被禁止的情況，那就是：
1.在requestPermissions之后在
onRequestPermissionsResult中獲取到?jīng)]給權(quán)限若河，并且shouldShowRequestPermissionRationale是false能岩，此時可以認定該權(quán)限被用戶禁止了；
2.還有一個點是是在onRequestPermissionsResult的參數(shù)值第三個參數(shù)grantResults是null,此時權(quán)限也是被拒絕的萧福。（權(quán)限被拒絕后再次調(diào)用requestPermissions拉鹃，沒有返回結(jié)果）
總結(jié)
shouldShowRequestPermissionRationale，回到最初的解釋“應(yīng)不應(yīng)該解釋下請求這個權(quán)限的目的”鲫忍。
1.都沒有請求過這個權(quán)限膏燕，用戶不一定會拒絕你，所以你不用解釋悟民，故返回false;
2.請求了但是被拒絕了坝辫，此時返回true，意思是你該向用戶好好解釋下了射亏；
3.請求權(quán)限被禁止了近忙，也不給你彈窗提醒了竭业，所以你也不用解釋了，故返回fasle;
4.請求被允許了银锻，都給你權(quán)限了永品，還解釋個啥，故返回false击纬。
Google的初衷大概就是第一次requestPermissions的時候被拒絕時給你一次解釋的機會，所以是讓你在請求權(quán)限的回調(diào)中使用的钾麸。
其它
動態(tài)權(quán)限的適配就是檢測更振、請求，然后看回調(diào)饭尝，再通過了權(quán)限后再去執(zhí)行自己的方法肯腕，但是真正用的時候又很麻煩，每次調(diào)用相機钥平、短信实撒、打電話、訪問通訊錄涉瘾、定位等等都要請求權(quán)限知态，寫一堆跟業(yè)務(wù)無關(guān)的代碼，是不是很煩呢立叛？
最近整理了一個關(guān)于方便管理動態(tài)權(quán)限的庫负敏，[Android 6.0動態(tài)權(quán)限獲取：一個EasyPermission的權(quán)限管理庫](http://www.reibang.com/p/671fbbb48551)
附github源碼：https://github.com/githubZYQ/easypermission
最后
祝所有人平安幸福秘蛇、家庭和睦其做、身體健康。
愿世界和平赁还，不再被戰(zhàn)爭所累妖泄。
有任何疑問，可以及時反饋給我艘策；
如果你覺得還不錯蹈胡，請點贊o(￣▽￣)ｄ。
