系統權限(相機、位置、通知、麥克風)的請求對話框由作業系統控制,app 只能決定「什麼時候觸發」和「觸發前顯示什麼說明」。使用者拒絕後,再次請求不會彈出系統對話框 — 必須引導使用者到系統設定手動開啟。這意味著第一次請求的時機和說明內容直接影響授權率。

請求時機

首次開啟時一次性請求

App 首次啟動時依序請求所有需要的權限。優點是使用者只被打斷一次;缺點是使用者尚未使用任何功能,不理解每個權限的用途,傾向拒絕。

這個模式適合權限數量少(1-2 個)且和 app 核心功能直接相關的情境。相機 app 在首次開啟時請求相機權限,使用者能直覺理解原因。

功能使用時即時請求

使用者點擊需要權限的功能時才請求。優點是使用者在操作 context 中,能理解為什麼需要這個權限;缺點是操作流程被打斷。

這個模式適合權限和特定功能綁定的情境。掃描 QR code 時請求相機權限,使用者正在嘗試掃描,理解為什麼需要相機。

推薦策略

功能使用時即時請求是多數場景的推薦策略。使用者有操作 context,授權率較高。打斷可以透過 pre-permission 說明畫面降低突兀感。

Pre-permission 說明畫面

在觸發系統權限對話框之前,app 先顯示自己的說明畫面,解釋為什麼需要這個權限和用途。

說明畫面的設計要點:

說明用途而非技術細節。「需要相機來掃描裝置上的 QR code」比「app 需要存取 AVCaptureDevice」更有用。使用者關心的是「為什麼」,不是「用什麼 API」。

提供「稍後再說」選項。使用者可能想先了解 app 再決定是否授權。強制授權(沒有跳過選項)會讓使用者選擇拒絕。

視覺化說明。用截圖或圖示展示「授權後這個功能長什麼樣」,讓使用者預覽授權的價值。

拒絕後的處理

使用者拒絕權限後,app 需要:

記住拒絕狀態。不要在每次使用者操作同一功能時都顯示 pre-permission 說明(使用者已經表達不想授權,反覆詢問是騷擾)。

提供功能降級。如果可能,提供不需要權限的替代方案。掃描 QR code 可以改成手動輸入配對碼。

在適當時機再提醒。使用者多次使用需要權限的功能但都因為沒有權限而失敗時,用非侵入式提示(Snackbar)說明「開啟相機權限可以使用掃描功能」加設定連結。

引導到系統設定。一旦使用者在系統對話框中選擇「不再詢問」(Android)或拒絕(iOS 拒絕後系統不再彈窗),唯一的路徑是引導使用者到系統設定手動開啟。提供直接跳轉到 app 設定頁面的按鈕。

下一步路由