引言

在開發視頻類應用時，我們常常會遇到需要同時請求相機和麥克風權限的場景。比如，在用戶發布視頻動態時，相機用于捕捉畫面，麥克風用于錄制聲音；又或者在直播功能中，只有獲得這兩項權限，用戶才能順利開播。

然而，權限管理在實際開發中往往會變得復雜：用戶拒絕某項權限后如何處理？權限請求的彈窗順序如何優化用戶體驗？如何保證邏輯清晰，代碼易于維護？

本文將從實際項目出發，分析 iOS 平臺權限管理的核心要點，并分享一種同時請求相機和麥克風權限的最佳實踐方案，幫助開發者在代碼實現和用戶體驗之間找到平衡。

Info.plist 文件中的權限聲明

iOS系統對于權限的使用十分敏感，幾乎所有的權限都需要到Info.plist文件中進行配置，NSCameraUsageDescription添加使用相機權限的用途，NSMicrophoneUsageDescription以及使用麥克風權限的用戶。

如果在info.plist文件中缺少聲明和描述，當我們請求或者獲取權限時會發生崩潰，即便是描述不清晰也有可能會直接影響App的上架審核。

權限狀態的分類與處理

iOS中關于相機和麥克風的權限狀態通常通過系統的API返回，目前分為以下4種：

public enum AVAuthorizationStatus : Int, @unchecked Sendable {case notDetermined = 0case restricted = 1case denied = 2case authorized = 3
}

• .notDetermined：表示用戶尚未對權限做出選擇，對于這種情況我們可以直接請求權限讓用戶來選擇。
• .restricted：權限被系統限制，用戶無法更改，這種情況我們需要告知用戶權限受限。
• .denied：用戶明確拒絕了權限的申請，對于這種情況我們可以提示用戶到設置中更改權限，并引導用戶跳轉到設置頁面。
• .authorized：用戶已授權，對于這種情況用戶可以直接使用對應功能。

實現同時請求兩種權限的常見問題

權限請求的回調處理混亂

• 相機和麥克風的權限請求是獨立的，各自的請求都有單獨的回調。開發者容易將邏輯分散在多個地方，導致代碼難以維護。
• 權限回調的狀態難以同步，可能會出現兩者之一被拒絕但仍嘗試啟動功能的情況。
• 回調嵌套或分散，代碼結構混亂。

彈窗順序不一致

• 同時請求兩個權限時，系統會分別彈出權限請求對話框。若不加控制，可能導致用戶體驗不佳。
• 彈窗順序不統一，每次操作順序可能不同（相機在前或麥克風在前）。

權限狀態處理不全面

• 開發者可能忽略了部分權限狀態（如?.restricted?或?.denied），導致權限請求邏輯存在漏洞
• 用戶禁用麥克風后，界面沒有任何反饋提示。
• 系統限制導致功能不可用時，沒有明確的用戶引導。
• 如果用戶拒絕了其中一個權限，應用可能直接報錯或終止功能，而沒有提供任何替代方案。
• 沒有明確的引導用戶重新授權的提示，可能導致用戶無法恢復使用功能。

最優實現方案

我們以直播間開播準備頁為例，用戶啟動開播之后首先會檢查麥克風和相機的權限，如果兩個權限都未獲取到則顯示第一個頁面需要申請兩個權限。

如果只是其中一個權限尚未獲取，我們需要需要顯示對應的UI，并在點擊授權時進行申請。

為此我們創建了一個權限管理類MWAccessHelper，專門處理權限的檢查和申請。

權限檢查

對于相機和麥克風我們定義兩個不同的方法來進行權限的檢查。

    /// 查看相機權限public static func checkCameraAccess() -> Bool {let authStatus = AVCaptureDevice.authorizationStatus(for: .video)if authStatus == .restricted || authStatus == .denied || authStatus == .notDetermined {return false}return true}/// 查看麥克風權限public static func checkMicrophoneAccess() -> Bool {let authStatus = AVCaptureDevice.authorizationStatus(for: .audio)if authStatus == .restricted || authStatus == .denied || authStatus == .notDetermined{return false}return true}

如果權限尚未全都獲取，則直接根據權限狀態顯示權限需要申請的UI頁面。

        // 查看權限let cameraAccess =  MWAccessHelper.checkCameraAccess()let micAccess = MWAccessHelper.checkMicrophoneAccess()if cameraAccess && micAccess {....} else {addAllowAccessView()allowAccessView?.refreshAccessStatus(isCamera: cameraAccess, isMicrophone: micAccess)}

權限申請

為了統一申請權限，我們還定義了一個公共的權限申請方法，以及單獨的麥克風權限和相機權限申請方法。

    /// 申請麥克風和相機權限public static func requestCameraAndMicrophoneAccess(_ completion: @escaping (Bool) -> Void) {if checkCameraAccess() && checkMicrophoneAccess() {completion(true)return}// 請求相機權限requestCameraAccess { (cameraGranted) inif cameraGranted {// 請求麥克風權限requestMicrophoneAccess { (microphoneGranted) incompletion(microphoneGranted)}} else {completion(false)}}}

1. 首先檢查權限是否已經獲取，如果已經獲取則直接回調true。
2. 優先請求相機權限。
3. 相機權限獲取成功后，請求麥克風權限。
4. 相機權限獲取失敗直接回調false結束。
5. 麥克風權限獲取成功后，回調true結束。
6. 麥克風權限獲取失敗后回調false結束。

請求相機權限方法：

    /// 請求相機權限public static func requestCameraAccess(_ completion: @escaping (Bool) -> Void) {let authStatus = AVCaptureDevice.authorizationStatus(for: .video)if authStatus == .authorized {completion(true)} else if authStatus == .notDetermined {AVCaptureDevice.requestAccess(for: .video) { (videoGranted) incompletion(videoGranted)}} else if authStatus == .denied || authStatus == .restricted {// 去設置UIApplication.shared.open(URL(string: UIApplication.openSettingsURLString)!, options: [:], completionHandler: nil)}}

1. 如果已經獲取到了相機權限直接回調true。
2. 如果尚未決定權限，則直接申請，根據用戶授權情況回調結果。
3. 如果用戶已經明確拒絕權限，或者系統原因權限未獲取到，則直接跳轉設置頁面。

請求麥克風權限方法：

    /// 請求麥克風權限public static func requestMicrophoneAccess(_ completion: @escaping (Bool) -> Void) {let authStatus = AVCaptureDevice.authorizationStatus(for: .audio)if authStatus == .notDetermined {AVCaptureDevice.requestAccess(for: .audio) { (audioGranted) incompletion(audioGranted)}} else if authStatus == .denied || authStatus == .restricted {// 去設置UIApplication.shared.open(URL(string: UIApplication.openSettingsURLString)!, options: [:], completionHandler: nil)}}

1. 如果已經獲取到了麥克風權限直接回調true。
2. 如果尚未決定權限，則直接申請，根據用戶授權情況回調結果。
3. 如果用戶已經明確拒絕權限，或者系統原因權限未獲取到，則直接跳轉設置頁面。

結語

在 iOS 開發中，同時請求相機和麥克風權限是一個常見但容易被忽視的難點。通過對權限狀態的全面分析和邏輯封裝，我們不僅可以提高代碼的可讀性和復用性，還能大幅優化用戶體驗。

權限管理不僅僅是一個技術問題，更是對用戶隱私和體驗的尊重。在實現過程中，務必要關注權限的彈窗順序、拒絕后的引導文案，以及替代功能的提供，確保應用在各種權限狀態下都能優雅地運行。

未來，隨著用戶隱私意識的提升和系統權限機制的不斷演進，權限管理將變得更加復雜和重要。希望本文的最佳實踐能夠為開發者提供思路，幫助大家在實際項目中輕松應對類似場景，為用戶帶來更加流暢和安全的使用體驗。