使用“突發(fā)-延遲”策略重新設(shè)計(jì)手機(jī)干預(yù)彈窗iOS 的“屏幕使用時(shí)間”、Android 的“數(shù)字健康”以及各類專注 App本質(zhì)上都在解決同一個(gè)問題手機(jī)如何奪回了我們的注意力。但多數(shù)工具只做了“統(tǒng)計(jì)”和“限制”兩層工作——告訴用戶今天解鎖了多少次到了設(shè)定時(shí)間就鎖住應(yīng)用。真正困難的部分在于用戶在被攔截的那一刻往往處于無意識滑手機(jī)的狀態(tài)冷冰冰的鎖屏和剩余時(shí)間倒計(jì)時(shí)很難觸發(fā)反思反而容易養(yǎng)成“點(diǎn)掉彈窗繼續(xù)刷”的肌肉記憶。Haserupt 這個(gè)項(xiàng)目提出的思路很有意思。它沒有把“減少手機(jī)使用”當(dāng)作一個(gè)簡單的計(jì)時(shí)器問題而是把每次解鎖、打開社交應(yīng)用的過程設(shè)計(jì)成一次有敘事節(jié)奏的打斷體驗(yàn)。用戶不是面對“今日已使用 3 小時(shí)”的統(tǒng)計(jì)數(shù)字而是會先看到一段突發(fā)提示經(jīng)歷一段延遲等待再在情緒和注意力都被拉回現(xiàn)實(shí)之后自行選擇是否繼續(xù)進(jìn)入應(yīng)用。這篇文章會圍繞這種“突發(fā)-延遲”的干預(yù)模式拆解它背后的產(chǎn)品邏輯、狀態(tài)流轉(zhuǎn)、配置體系和技術(shù)實(shí)現(xiàn)思路并給出一個(gè)可以本地跑通的最小示例。國內(nèi)做防沉迷和數(shù)字健康產(chǎn)品時(shí)通常會遇到幾個(gè)實(shí)際問題系統(tǒng)級限制權(quán)限難以獲取、不同手機(jī)廠商對后臺彈窗的管理策略差異很大、用戶繞過限制的成本太低。Haserupt 這類方案最大的參考價(jià)值在于它沒有試圖從系統(tǒng)層“鎖死”應(yīng)用而是通過更聰明的交互設(shè)計(jì)在用戶和應(yīng)用之間插入一個(gè)反思窗口。只要用戶愿意停留在這個(gè)窗口里產(chǎn)品目標(biāo)就已經(jīng)完成一半。1. 先理解 Haserupt 解決的問題注意力干預(yù)不是靠權(quán)限而是靠交互節(jié)奏1.1 為什么傳統(tǒng)的“限制時(shí)長”方案很容易失效先看一個(gè)非常常見的場景。用戶給抖音設(shè)置了 30 分鐘限額時(shí)間到后系統(tǒng)彈出提示“已到達(dá)使用限額”。很多人的第一反應(yīng)不是關(guān)掉手機(jī)而是點(diǎn)擊“忽略限額”繼續(xù)使用。即便系統(tǒng)提供了“再多用 15 分鐘”的選項(xiàng)這個(gè)過程也幾乎沒有帶來任何認(rèn)知負(fù)擔(dān)。問題出在哪里問題在于傳統(tǒng)限制方案的“干預(yù)點(diǎn)”放在了錯(cuò)誤的位置。它在用戶已經(jīng)沉浸大量時(shí)間之后才出現(xiàn)此時(shí)用戶處于多巴胺驅(qū)動的連續(xù)瀏覽狀態(tài)突然冒出的系統(tǒng)提示只是一個(gè)需要被關(guān)閉的彈窗。關(guān)閉彈窗的成本極低而繼續(xù)刷內(nèi)容帶來的即時(shí)滿足卻非常強(qiáng)人的本能會傾向選擇后者。更關(guān)鍵的是“剩余時(shí)間倒計(jì)時(shí)”這類統(tǒng)計(jì)信息需要用戶具備足夠的自制力才能轉(zhuǎn)化為行動。但數(shù)字健康產(chǎn)品的核心用戶恰恰是自制力不足以自行對抗算法推薦的人。如果產(chǎn)品把行為的最終決定權(quán)完全交還給用戶同時(shí)又不提供任何心理緩沖那它實(shí)際上沒有完成“干預(yù)”的任務(wù)只是在“記錄”。1.2 突發(fā)-延遲機(jī)制是如何改變用戶決策路徑的Haserupt 的干預(yù)模型可以拆成三個(gè)階段突發(fā)提示、延遲等待、自主選擇。突發(fā)提示相當(dāng)于在用戶即將無意識進(jìn)入應(yīng)用時(shí)先用一條有敘事感的消息打斷自動化行為。它不是“你又超時(shí)了”這種指責(zé)性語言而更像是一個(gè)意外事件比如“你上次打開相冊時(shí)發(fā)現(xiàn)了一張 2019 年拍的照片。需要我?guī)湍阏一貋砜纯磫帷边@種提示的核心目的是打破動作慣性讓用戶從“手指自動點(diǎn)開應(yīng)用”切換成“意識到自己正在打開應(yīng)用”。延遲等待是在用戶點(diǎn)擊“仍然要繼續(xù)”之后再插入一段短暫的等待時(shí)間。這段時(shí)間不需要很長幾秒鐘就足以讓大腦從前額葉皮層從被動狀態(tài)切換到主動思考狀態(tài)。TikTok 類的短視頻產(chǎn)品之所以讓人停不下來關(guān)鍵就是內(nèi)容切換之間的間隔幾乎為零用戶沒有機(jī)會產(chǎn)生“我該停下來了”這個(gè)念頭。反過來如果一個(gè)產(chǎn)品刻意制造 3 到 5 秒的等待用戶就會開始評估自己“打開應(yīng)用”這個(gè)行為的必要性。最后才是自主選擇。經(jīng)過突發(fā)提示和延遲等待之后用戶如果再點(diǎn)擊“進(jìn)入應(yīng)用”說明他已經(jīng)做出了有意識決定。此時(shí)產(chǎn)品不應(yīng)該再攔截而是放行并且可以記錄這一次決定供后續(xù)分析。這個(gè)設(shè)計(jì)非常關(guān)鍵它把工具從“家長監(jiān)控模式”轉(zhuǎn)換成了“自我決策輔助模式”用戶的抵觸感會明顯降低。1.3 Haserupt 的產(chǎn)品定位不是鎖手機(jī)而是調(diào)節(jié)手機(jī)的使用節(jié)奏Haserupt 的命名里帶有“爆發(fā)”的含義它強(qiáng)調(diào)的不是阻止而是“在某個(gè)瞬間突然喚起注意”。這和冥想類、正念類產(chǎn)品的克制風(fēng)格不同它更直接、更有存在感。但從干預(yù)效果來看這種主動打斷恰恰是當(dāng)前數(shù)字健康工具缺少的一環(huán)。類比一下物理世界的“防沉迷”超市里想控制自己買零食最有效的不是出門前把零食鎖進(jìn)柜子里而是每次伸手拿薯片時(shí)貨架旁突然彈出一張“你已經(jīng)連續(xù)買了三天薯片”的提示卡并且收銀臺還要多等五秒才能結(jié)算。Haserupt 做的就是這個(gè)“貨架提示卡”和“收銀等待”的角色。作者在算法、交互和文案上選擇了“沉浸式打斷”路線。它面向的用戶不是完全不刷手機(jī)的那批人而是意識到自己用手機(jī)太多、但單靠意志力很難改變的人。對這批用戶來說一刀切的封鎖并不可行真正需要的是一個(gè)能反復(fù)打斷循環(huán)、并給用戶留出決策空間的中間層。2. 核心架構(gòu)狀態(tài)機(jī)、攔截點(diǎn)、提示生成器三塊缺一不可2.1 干預(yù)流程的完整狀態(tài)流轉(zhuǎn)把 Haserupt 的“突發(fā)-延遲”流程做工程化拆解整個(gè)交互可以建模為一個(gè)狀態(tài)機(jī)。每個(gè)狀態(tài)都有明確的進(jìn)入條件、停留事件和退出條件這樣可以避免出現(xiàn)用戶被連續(xù)彈出多個(gè)提示、或在某個(gè)環(huán)節(jié)死循環(huán)的情況。狀態(tài)機(jī)設(shè)計(jì)如下IDLE - TRIGGERED - PRESENTED - WAITING - ADMIT / DISMISS - IDLEIDLE用戶當(dāng)前沒有需要干預(yù)的行為系統(tǒng)只做后臺監(jiān)測。TRIGGERED用戶打開了目標(biāo)應(yīng)用或超過了設(shè)定閾值干預(yù)條件被觸發(fā)。PRESENTED系統(tǒng)已經(jīng)顯示了突發(fā)提示彈窗等待用戶響應(yīng)。WAITING用戶點(diǎn)擊了“我仍然要繼續(xù)”進(jìn)入延遲等待階段顯示倒計(jì)時(shí)或進(jìn)度動畫。ADMIT用戶完成等待后再次確認(rèn)放行目標(biāo)應(yīng)用。DISMISS用戶在突發(fā)提示階段或延遲等待階段退出回到桌面或系統(tǒng)界面。實(shí)現(xiàn)這套狀態(tài)機(jī)時(shí)最重要的一點(diǎn)是把“狀態(tài)”和“界面”解耦。也就是說突發(fā)提示彈窗顯示到什么進(jìn)度、用戶點(diǎn)擊了哪個(gè)按鈕這些是界面層的事件而處于哪個(gè)狀態(tài)、下一步應(yīng)該跳轉(zhuǎn)到哪里則是狀態(tài)機(jī)層的邏輯。否則產(chǎn)品經(jīng)理一旦調(diào)整交互文案開發(fā)就必須跟著大規(guī)模重構(gòu)。2.2 可注冊的攔截點(diǎn)不是只能攔截應(yīng)用啟動Haserupt 的攔截點(diǎn)設(shè)計(jì)應(yīng)該比傳統(tǒng)方案更細(xì)。常見的攔截時(shí)機(jī)包括攔截點(diǎn)類型觸發(fā)示例干預(yù)強(qiáng)度實(shí)現(xiàn)成本應(yīng)用啟動攔截用戶點(diǎn)擊 App 圖標(biāo)低中應(yīng)用內(nèi)場景攔截打開短視頻信息流前高高時(shí)長閾值攔截單日使用超過 60 分鐘中低頻率攔截10 分鐘內(nèi)解鎖超過 5 次中低特定動作攔截打開購物應(yīng)用準(zhǔn)備搜索高高在 Android 端無障礙服務(wù)可以監(jiān)聽窗口變化也能讀取當(dāng)前前臺應(yīng)用包名這是實(shí)現(xiàn)“應(yīng)用啟動攔截”相對可行的路徑。更細(xì)粒度的“應(yīng)用內(nèi)場景攔截”需要應(yīng)用本身配合比如通過深度鏈接進(jìn)入特定頁面時(shí)攔截這對第三方應(yīng)用來說受限很多。因此現(xiàn)實(shí)中的實(shí)現(xiàn)策略是優(yōu)先做系統(tǒng)級可到達(dá)的攔截點(diǎn)再根據(jù)自身產(chǎn)品能力做應(yīng)用內(nèi) SDK 級別的攔截。2.3 提示生成器為什么不能用固定的“別玩了”文案不少防沉迷應(yīng)用只提供固定的“該休息了”“今日使用時(shí)間已達(dá)上限”文案。這種文案的問題在于用戶第一次看到還有一點(diǎn)觸動到第十次就完全麻木了。真正有效的突發(fā)提示需要具備兩個(gè)特點(diǎn)一是與用戶當(dāng)前行為之間有關(guān)聯(lián)二是每次出現(xiàn)有變化感。Haserupt 的提示生成器在實(shí)現(xiàn)上應(yīng)該包含模板庫和變量池。模板庫負(fù)責(zé)定義提示的句式和類型變量池則從用戶的使用記錄中抽取信息比如最近打開的應(yīng)用、長時(shí)間未查看的照片、昨天完成的待辦事項(xiàng)。把模板和變量組合起來才能生成“你昨天保存了五張截圖還沒有整理進(jìn)相冊”這類貼近個(gè)人情況的提示。實(shí)現(xiàn)思路可以簡化為三層數(shù)據(jù)采集層 - 用戶畫像/行為記錄 - 提示渲染層數(shù)據(jù)采集層負(fù)責(zé)記錄行為日志行為記錄層產(chǎn)出提示所需的變量提示渲染層從模板庫中挑選模板結(jié)合變量生成最終展示給用戶的文案。這里要格外注意隱私邊界所有行為數(shù)據(jù)都應(yīng)當(dāng)只在本地處理不上傳到云端。3. 技術(shù)選型與項(xiàng)目結(jié)構(gòu)從最小可用版本開始搭建3.1 用 Android 無障礙服務(wù)作為首個(gè)載體如果從零實(shí)現(xiàn)一個(gè) Haserupt 這樣理念的產(chǎn)品優(yōu)先選擇 Android 平臺會比 iOS 容易很多。iOS 的 Screen Time API 面向的是家長的“限制”場景應(yīng)用難以為自身獲取足夠的屏幕觀測權(quán)限而 Android 的無障礙服務(wù)在用戶授權(quán)之后可以監(jiān)聽窗口變化、讀取當(dāng)前應(yīng)用并模擬一定的交互這給“攔截-提示-延遲-放行”的完整鏈路提供了實(shí)現(xiàn)基礎(chǔ)。無障礙服務(wù)本身很敏感Play 商店和國內(nèi)應(yīng)用市場對用途審核都相當(dāng)嚴(yán)格。開發(fā)者在申請?jiān)摍?quán)限時(shí)應(yīng)當(dāng)明確聲明服務(wù)只用于數(shù)字健康場景不讀取用戶輸入內(nèi)容不采集密碼或支付信息并在隱私政策中清晰說明數(shù)據(jù)用途。3.2 項(xiàng)目目錄設(shè)計(jì)按照模塊職責(zé)拆分一個(gè)最小可運(yùn)行的項(xiàng)目可以這樣組織haserupt/ ├── app/ │ ├── src/main/java/com/haserupt/app/ │ │ ├── service/ │ │ │ └── BlockerAccessibilityService.kt │ │ ├── state/ │ │ │ ├── InterventionStateMachine.kt │ │ │ └── InterveneEvent.kt │ │ ├── engine/ │ │ │ ├── RuleEngine.kt │ │ │ └── TriggerCondition.kt │ │ ├── content/ │ │ │ ├── PromptTemplate.kt │ │ │ ├── PromptGenerator.kt │ │ │ └── BehaviorStore.kt │ │ ├── ui/ │ │ │ ├── HazeDialogActivity.kt │ │ │ └── DelayFragment.kt │ │ └── config/ │ │ └── AppConfig.kt │ └── src/main/res/ │ ├── layout/ │ │ ├── dialog_haze.xml │ │ └── fragment_delay.xml │ └── values/ │ └── strings.xml └── build.gradleservice包負(fù)責(zé)系統(tǒng)級事件監(jiān)聽state包對應(yīng)前文的狀態(tài)機(jī)engine包是規(guī)則判斷content包負(fù)責(zé)提示文案的生成和本地行為存儲ui包展示突發(fā)提示和延遲等待界面。模塊之間單向依賴ui依賴state和contentstate依賴engineengine依賴content的存儲結(jié)果。3.3 依賴清單盡量少盡量穩(wěn)定對于最小版本第三方依賴可以控制得非常少依賴用途備注AndroidX Core基礎(chǔ)兼容必選AndroidX AppCompatActivity 兼容必選Kotlin Coroutines異步任務(wù)、延遲等待建議Room行為日志本地存儲可選DataStore偏好配置存儲可選不建議在一開始就引入網(wǎng)絡(luò)請求庫和云同步 SDK。本地單機(jī)版本把核心鏈路跑通之后再考慮賬號體系和跨設(shè)備同步更穩(wěn)妥。4. 核心代碼實(shí)現(xiàn)狀態(tài)機(jī)、規(guī)則引擎和提示生成器4.1 狀態(tài)機(jī)實(shí)現(xiàn)用 Kotlin 實(shí)現(xiàn)一個(gè)安全的狀態(tài)機(jī)重點(diǎn)是把“非法跳轉(zhuǎn)”攔截在代碼層。sealed class InterventionState { object Idle : InterventionState() object Triggered : InterventionState() object Presented : InterventionState() object Waiting : InterventionState() data class Admitted(val timestamp: Long) : InterventionState() object Dismissed : InterventionState() } sealed class InterveneEvent { object OnAppOpened : InterveneEvent() object OnPromptShown : InterveneEvent() object OnContinueClick : InterveneEvent() object OnDelayFinished : InterveneEvent() object OnExitClick : InterveneEvent() } class InterventionStateMachine { private lateinit var currentState: InterventionState fun transition(event: InterveneEvent): InterventionState { currentState when (currentState) { InterventionState.Idle - when (event) { InterveneEvent.OnAppOpened - InterventionState.Triggered else - currentState } InterventionState.Triggered - when (event) { InterveneEvent.OnPromptShown - InterventionState.Presented else - currentState } InterventionState.Presented - when (event) { InterveneEvent.OnContinueClick - InterventionState.Waiting InterveneEvent.OnExitClick - InterventionState.Dismissed else - currentState } InterventionState.Waiting - when (event) { InterveneEvent.OnDelayFinished - InterventionState.Admitted(System.currentTimeMillis()) InterveneEvent.OnExitClick - InterventionState.Dismissed else - currentState } else - currentState } return currentState } fun isIdle() currentState is InterventionState.Idle }這里的狀態(tài)機(jī)沒有實(shí)現(xiàn)“自動恢復(fù)到 Idle”的邏輯。實(shí)際使用時(shí)需要在用戶回到桌面或經(jīng)過一定冷卻時(shí)間后主動把狀態(tài)重置為 Idle否則會出現(xiàn)“攔截一次之后后續(xù)所有打開操作都不再觸發(fā)”的問題。4.2 規(guī)則引擎判斷是否觸發(fā)干預(yù)規(guī)則引擎不負(fù)責(zé)彈窗它只回答一個(gè)問題當(dāng)前場景需要干預(yù)嗎把規(guī)則和界面分離后續(xù)調(diào)整算法時(shí)就不會動到 UI 代碼。data class UserContext( val currentPackageName: String, val todayUsageMinutes: Long, val lastTriggerTimestamp: Long, val currentStreakCount: Int ) class RuleEngine( private val targetPackages: SetString, private val dailyThresholdMinutes: Long 60L ) { fun shouldIntervene(context: UserContext): Boolean { val isTargetApp context.currentPackageName in targetPackages val isOverDailyLimit context.todayUsageMinutes dailyThresholdMinutes val isCooldownFinished System.currentTimeMillis() - context.lastTriggerTimestamp 10 * 60 * 1000 return isTargetApp (isOverDailyLimit || isCooldownFinished) } }這段代碼展示的是兩個(gè)判斷維度命中目標(biāo)應(yīng)用且超過日限額或命中目標(biāo)應(yīng)用且冷卻期已結(jié)束。實(shí)際產(chǎn)品中規(guī)則配置可以從本地文件或 DataStore 中讀取讓用戶能自定義哪些應(yīng)用需要干預(yù)、每日限額多少、冷卻時(shí)間多長。4.3 提示生成器從行為記錄生成突發(fā)文案提示生成器需要聚合行為數(shù)據(jù)并渲染文案。下面是一個(gè)簡化實(shí)現(xiàn)data class BehaviorSnapshot( val unorganizedScreenshotCount: Int, val unreadMessageCount: Int, val lastSavingTime: String, val lastPhotoYear: Int? ) class PromptGenerator(private val behaviorStore: BehaviorStore) { private val templates listOf( 你還有 {screenshotCount} 張截圖沒有整理確定現(xiàn)在要繼續(xù)下滑嗎, 上次打開這個(gè)應(yīng)用前你正在處理 {lastSavingTime} 保存的文檔。, 相冊里有一張 {year} 年的照片要先去回憶一下嗎 ) fun generate(): String { val snapshot behaviorStore.getSnapshot() val template templates.random() return template .replace({screenshotCount}, snapshot.unorganizedScreenshotCount.toString()) .replace({lastSavingTime}, snapshot.lastSavingTime) .replace({year}, snapshot.lastPhotoYear?.toString() ?: 久遠(yuǎn)) } }實(shí)際項(xiàng)目里模板和變量要做好比例控制不能每次都隨機(jī)選擇導(dǎo)致用戶產(chǎn)生“提示內(nèi)容與我無關(guān)”的感受。更好的做法是依據(jù)用戶當(dāng)前的時(shí)間、最近行為、上次干預(yù)結(jié)果來打分選擇得分最高的模板。4.4 延遲等待界面延遲等待界面是整個(gè)交互中技術(shù)含量最低、但體驗(yàn)影響最大的部分。它不需要復(fù)雜動畫核心是讓用戶清晰感知到“我在等待”并且給用戶一個(gè)隨時(shí)可以退出的出口。一個(gè)簡單的 Compose 實(shí)現(xiàn)如下Composable fun DelayScreen( totalMillis: Long 5000L, onDelayFinished: () - Unit, onExitClick: () - Unit ) { var remain by remember { mutableStateOf(totalMillis) } val animation remember { Animatable(0f) } LaunchedEffect(Unit) { while (remain 0) { delay(100) remain - 100 } onDelayFinished() } Column( modifier Modifier.fillMaxSize(), horizontalAlignment Alignment.CenterHorizontally, verticalArrangement Arrangement.Center ) { Text(text 稍等一下, style MaterialTheme.typography.headlineSmall) Spacer(modifier Modifier.height(24.dp)) LinearProgressIndicator( progress { 1f - remain / totalMillis.toFloat() } ) Spacer(modifier Modifier.height(24.dp)) TextButton(onClick onExitClick) { Text(text 回桌面) } } }4.5 無障礙服務(wù)中的攔截邏輯無障礙服務(wù)負(fù)責(zé)監(jiān)聽窗口變化并調(diào)用狀態(tài)機(jī)和規(guī)則引擎。class BlockerAccessibilityService : AccessibilityService() { private val stateMachine InterventionStateMachine() private val ruleEngine RuleEngine(targetPackages setOf(com.ss.android.ugc.aweme)) private val promptGenerator PromptGenerator(BehaviorStore(context this)) override fun onAccessibilityEvent(event: AccessibilityEvent?) { if (event null) return val packageName event.packageName?.toString() ?: return if (event.eventType AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED) { val context buildUserContext(packageName) if (ruleEngine.shouldIntervene(context)) { showHazeDialog(packageName) } } } private fun showHazeDialog(packageName: String) { val prompt promptGenerator.generate() val intent HazeDialogActivity.createIntent(context this, prompt prompt) intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) startActivity(intent) } override fun onInterrupt() { // 服務(wù)被系統(tǒng)中斷時(shí)的兜底 } }需要注意Android 12 及之后對無障礙服務(wù)啟動 Activity 的限制更嚴(yán)格背景啟動 Activity 會被系統(tǒng)阻止。實(shí)際開發(fā)中要考慮使用系統(tǒng)窗口Toast 型全屏彈窗或使用SYSTEM_ALERT_WINDOW權(quán)限來展示干預(yù)層。5. 關(guān)鍵參數(shù)配置與推薦值5.1 突發(fā)提示、延遲時(shí)長、釋放條件的參數(shù)關(guān)系Haserupt 的體驗(yàn)極大程度依賴三組參數(shù)突發(fā)內(nèi)容強(qiáng)度、延遲等待時(shí)長、釋放條件。三者的關(guān)系不是孤立的提示越強(qiáng)延遲就可以適當(dāng)越短提示太弱延遲就應(yīng)拉長給用戶更多反思時(shí)間。參數(shù)含義參考值過長/過短影響突發(fā)提示強(qiáng)度文案是否足夠與用戶個(gè)人相關(guān)中高太弱沒有打斷感太強(qiáng)引發(fā)焦慮延遲等待時(shí)長用戶點(diǎn)擊“繼續(xù)”后需等待的時(shí)間3 到 8 秒太短無效果太長觸發(fā)煩躁釋放確認(rèn)按鈕WAITING 結(jié)束后是否需要再次確認(rèn)需要缺少二次確認(rèn)會削弱決策感冷卻時(shí)間兩次干預(yù)的最小間隔10 到 30 分鐘過短導(dǎo)致頻繁打擾釋放后放行時(shí)長等待結(jié)束后允許使用多久再觸發(fā)5 到 10 分鐘過短容易讓用戶感到被戲弄5.2 不同場景的差異化配置同一個(gè)用戶在不同時(shí)間段、不同應(yīng)用上的干預(yù)策略也應(yīng)當(dāng)不同。白天通勤時(shí)刷短視頻可以允許更快的釋放睡前刷社交軟件時(shí)延遲時(shí)間則應(yīng)該加長。場景推薦突發(fā)提示內(nèi)容延遲等待說明工作日上午打開短視頻提示今天還有三個(gè)待辦任務(wù)5 秒強(qiáng)調(diào)時(shí)間成本晚上十點(diǎn)后打開社交 App提示“今天已經(jīng)刷了 2 小時(shí)”8 秒強(qiáng)調(diào)輕度焦慮周末打開游戲不強(qiáng)制攔截只提示3 秒避免周末強(qiáng)限制引發(fā)卸載頻繁解鎖手機(jī)提示“距離上次解鎖只有 2 分鐘”6 秒打破無意識解鎖循環(huán)這些參數(shù)在生產(chǎn)環(huán)境中應(yīng)該支持 A/B 測試而不是拍腦袋定死。無代碼策略配置平臺或者遠(yuǎn)程配置中心可以解決“不同版本用戶看到不同參數(shù)”的問題。5.3 配置化不把參數(shù)寫死在代碼里把參數(shù)集中定義在一個(gè)配置類或配置文件中避免散落到各個(gè) Fragment 和 Activity。{ global: { cooldownMinutes: 10, dailyLimitMinutes: 60 }, apps: { com.ss.android.ugc.aweme: { enabled: true, delaySeconds: 5, promptStyle: SCREENSHOT_REMIND }, com.tencent.mm: { enabled: false, delaySeconds: 3, promptStyle: WORK_REMIND } } }上文 JSON 采用本地配置文件是理解邏輯用的生產(chǎn)環(huán)境建議使用遠(yuǎn)程配置中心下發(fā)并保留本地緩存兜底。這樣產(chǎn)品經(jīng)理調(diào)整參數(shù)時(shí)不依賴發(fā)版。6. 運(yùn)行驗(yàn)證從單元測試到用戶調(diào)研6.1 單元測試至少覆蓋狀態(tài)流和規(guī)則引擎狀態(tài)機(jī)是整個(gè)項(xiàng)目最容易出 bug 的地方。用單元測試把所有合法跳轉(zhuǎn)和非法跳轉(zhuǎn)都覆蓋到比手動點(diǎn)擊驗(yàn)證快得多。class InterventionStateMachineTest { Test fun idle to presented when app opened and prompt shown() { val machine InterventionStateMachine() val afterTrigger machine.transition(InterveneEvent.OnAppOpened) val afterPresent machine.transition(InterveneEvent.OnPromptShown) assertEquals(afterPresent, InterventionState.Presented) } Test fun continue click moves to waiting() { val machine InterventionStateMachine() machine.transition(InterveneEvent.OnAppOpened) machine.transition(InterveneEvent.OnPromptShown) val afterWait machine.transition(InterveneEvent.OnContinueClick) assertEquals(afterWait, InterventionState.Waiting) } }6.2 真機(jī)驗(yàn)證清單單元測試通過之后需要準(zhǔn)備一份真機(jī)驗(yàn)收清單目標(biāo)應(yīng)用首次啟動時(shí)是否彈出突發(fā)提示。點(diǎn)擊“繼續(xù)”后延遲等待界面是否穩(wěn)定顯示進(jìn)度條是否平滑。延遲結(jié)束后目標(biāo)應(yīng)用是否被正常放行。點(diǎn)擊“回桌面”后是否回到桌面且不會再次觸發(fā)彈窗。冷卻時(shí)間內(nèi)再次打開目標(biāo)應(yīng)用是否不再觸發(fā)。無障礙服務(wù)在系統(tǒng)重啟后是否能自動重連。每個(gè)檢查點(diǎn)都要有一個(gè)預(yù)期結(jié)果。拿“冷卻時(shí)間內(nèi)不再觸發(fā)”來說預(yù)期是打開應(yīng)用后直接進(jìn)入沒有任何彈窗或延遲。6.3 小范圍用戶調(diào)研關(guān)注拒絕率和撤銷率產(chǎn)品上線后的核心指標(biāo)不是“每日干預(yù)次數(shù)”而是“干預(yù)后繼續(xù)進(jìn)入應(yīng)用的比例”和“用戶主動卸載無障礙服務(wù)的比例”。前者說明打斷是否帶來了反思后者說明產(chǎn)品是否過于煩人。兩個(gè)指標(biāo)需要放在一起看如果干預(yù)次數(shù)很高但用戶第二天就卸載那說明提示或延遲策略強(qiáng)度過強(qiáng)需要回調(diào)參數(shù)。在產(chǎn)品早期建議招募 10 到 20 名目標(biāo)用戶做短周期測試收集內(nèi)容除了問卷還應(yīng)有主動退出攔截后的訪談。用戶“為什么在延遲等待 2 秒時(shí)放棄”比“你覺得這個(gè)功能好用嗎”更能指導(dǎo)迭代。7. 落地過程中的常見問題與排查路徑7.1 無障礙服務(wù)被系統(tǒng)回收現(xiàn)象剛開啟時(shí)功能正常使用一兩天后打開目標(biāo)應(yīng)用不再出現(xiàn)任何提示?？赡茉驀a(chǎn) ROM 對無障礙服務(wù)的后臺行為有嚴(yán)格限制或服務(wù)內(nèi)部拋出了未捕獲異常導(dǎo)致服務(wù)被系統(tǒng)關(guān)閉。排查方式在系統(tǒng)設(shè)置里查看“無障礙-已下載的服務(wù)”狀態(tài)。查看adb logcat --pid$(pidof com.haserupt.app)日志確認(rèn)服務(wù)是否仍存活。檢查服務(wù)是否實(shí)現(xiàn)了onInterrupt()這是服務(wù)異常終止的入口。解決方式在onInterrupt()中增加日志和狀態(tài)重置邏輯引導(dǎo)用戶將應(yīng)用加入電池優(yōu)化白名單對華為、小米、Oppo 等主流機(jī)型分別測試。7.2 彈窗頻繁觸發(fā)或完全不觸發(fā)現(xiàn)象用戶在五分鐘內(nèi)連續(xù)被攔截三次或者設(shè)置了閾值后一次都不觸發(fā)?？赡茉蛞?guī)則引擎中的“冷卻時(shí)間”計(jì)算邏輯使用了錯(cuò)誤的系統(tǒng)時(shí)間來源或包名白名單沒有匹配到前臺應(yīng)用。排查方式先開啟日志打印每次事件的currentPackageName確認(rèn)無障礙服務(wù)是否真的識別到了目標(biāo)應(yīng)用。再打印規(guī)則引擎的判定結(jié)果和時(shí)間戳。解決方式時(shí)間比較統(tǒng)一使用System.currentTimeMillis()不要混用elapsedRealtime。包名比較時(shí)注意去掉進(jìn)程號后綴只比較純包名。提示真機(jī)上彈出的應(yīng)用包名可能帶有冒號后綴比如com.ss.android.ugc.aweme:push直接用event.packageName.toString()做精確匹配會漏判。建議總是取冒號前的部分再比對。7.3 延遲等待界面狀態(tài)錯(cuò)亂現(xiàn)象用戶點(diǎn)擊“回桌面”后仍會再次彈出等待框或者延遲結(jié)束后沒有跳轉(zhuǎn)到目標(biāo)應(yīng)用?？赡茉驙顟B(tài)機(jī)沒有在正確時(shí)機(jī)重置Activity 的啟動模式設(shè)置錯(cuò)誤導(dǎo)致多個(gè)彈窗實(shí)例疊加。排查方式查看onNewIntent和onDestroy的調(diào)用順序確認(rèn)用戶在退出后是否觸發(fā)了多余的生命周期回調(diào)。解決方式為 HazeDialogActivity 配置android:launchModesingleInstance并把狀態(tài)機(jī)重置動作放在目標(biāo)應(yīng)用恢復(fù)前臺或用戶回到桌面的事件里而不是放在彈窗界面的onDestroy中。8. 最佳實(shí)踐與擴(kuò)展方向8.1 可復(fù)用的發(fā)布前檢查清單在把這類數(shù)字健康產(chǎn)品推向更大規(guī)模前應(yīng)該逐項(xiàng)確認(rèn)以下內(nèi)容無障礙服務(wù)的用途說明是否清晰隱私政策是否聲明不采集敏感信息。所有行為數(shù)據(jù)是否只保存在本地或至少完成匿名化。每個(gè)目標(biāo)應(yīng)用都有獨(dú)立的提示模板和延遲參數(shù)沒有使用全局統(tǒng)一配置。狀態(tài)機(jī)覆蓋三種用戶路徑接受等待、中途退出、后臺被殺。冷卻時(shí)間設(shè)置合理避免同一時(shí)段重復(fù)打擾。卸載或關(guān)閉無障礙服務(wù)后的兜底邏輯是否平穩(wěn)不會導(dǎo)致應(yīng)用崩潰。在主流國產(chǎn) ROM 上測試后服務(wù)存活率達(dá)標(biāo)。有監(jiān)控日志上報(bào)能遠(yuǎn)程查看服務(wù)被回收、規(guī)則異常等關(guān)鍵事件。8.2 擴(kuò)展方向一從“應(yīng)用級攔截”升級為“內(nèi)容級反思”目前的攔截點(diǎn)都在應(yīng)用層面用戶通過“打開應(yīng)用”這個(gè)動作觸發(fā)提示。更進(jìn)一步的方案是在應(yīng)用內(nèi)部接入 SDK當(dāng)用戶準(zhǔn)備進(jìn)入短視頻信息流或開始搜索商品時(shí)觸發(fā)提示。這種方案對第三方應(yīng)用不現(xiàn)實(shí)但可以做成開源 SDK讓自家生態(tài)應(yīng)用接入或在瀏覽器插件維度實(shí)現(xiàn)類似能力。8.3 擴(kuò)展方向二讓突發(fā)提示成為“個(gè)人時(shí)間管理助手”Haserupt 的風(fēng)格天然適合擴(kuò)展為“個(gè)人時(shí)間管理助手”。它可以讀取用戶的日歷、待辦事項(xiàng)和真實(shí)生活目標(biāo)在用戶使用手機(jī)到失控邊緣時(shí)把用戶的注意力拉回“現(xiàn)實(shí)世界”。但這種能力帶來兩個(gè)代價(jià)其一需要更多個(gè)人數(shù)據(jù)必須把隱私說明做透其二提示從“該休息了”變?yōu)椤澳阌幸粋€(gè)會議馬上要開”之后用戶會產(chǎn)生被監(jiān)控感產(chǎn)品調(diào)性需要重新拿捏。8.4 擴(kuò)展方向三家庭模式與共同干預(yù)未成年人防沉迷場景下家長的訴求是“限制”孩子的訴求是“獨(dú)立空間”。完全把 Haserupt 的“自主選擇”理念照搬進(jìn)家庭模式并不現(xiàn)實(shí)。比較合理的做法是家長可以設(shè)置更長的延遲時(shí)間和不可跳過的提示但每一次強(qiáng)行跳過或放棄使用都會向家長端生成一份記錄。這種方式既保留了“延遲-反思”的機(jī)制又兼顧了家庭場景對權(quán)威的訴求。8.5 對開發(fā)者最重要的建議Haserupt 這類產(chǎn)品真正復(fù)雜的地方不在于技術(shù)而在于產(chǎn)品理念能否從“懲罰性限制”轉(zhuǎn)化為“建設(shè)性干預(yù)”。代碼層面障礙服務(wù)、狀態(tài)機(jī)、提示模板都不難實(shí)現(xiàn)難的是判斷什么時(shí)候該打斷用戶、用什么樣的語氣打斷以及用戶在被打斷之后有沒有獲得一個(gè)“自己做出選擇”的出口。如果要做類似方向的項(xiàng)目建議先從一個(gè)目標(biāo)應(yīng)用、一種提示風(fēng)格開始。跑通核心循環(huán)之后再慢慢擴(kuò)展規(guī)則、內(nèi)容模板和平臺邊界。等用戶愿意主動開啟并長期保留你的無障礙權(quán)限這個(gè)產(chǎn)品才算真正成立。