拓冰网站定制 
之前看到不少朋友在讨论“如何戒掉手机”的话题也见过各种屏幕上瘾的数据报告。真正动手做过限制手机使用功能的人会知道这个需求并没有想象中那么简单系统自带的“屏幕时间管理”不够强制卸载 App 又不太现实第三方应用也经常因为后台被杀而失效。最近看到一个很有意思的项目Haserupt定位是 “A new way to reduce your phone usage”从产品设计和技术实现上都给了我一些启发。这篇文章不打算只停留在“这个项目不错”的层面而是完整拆解它的需求背景、核心机制以及我们可以照着实现的一版简化方案。无论你是经常被手机使用时长困扰的普通用户还是对 Android 系统能力、后台任务、Behavior 触发机制感兴趣的开发者都可以从这篇文章里找到值得参考的内容。读完以后你能理解这类应用的关键设计点是什么也能跟着我在 Android Studio 中搭建一个最小可运行版本了解辅助功能、前台服务、策略配置在其中的具体作用。1. 背景与核心概念先聊一个比较现实的问题手机为什么越来越难放下从产品设计的角度看很多 App 本身就在利用人类心理的“不确定奖励”机制比如下拉刷新、小红点、无限信息流。你要对抗的并不是“意志力不足”这么简单而是一整套经过精心设计的注意力争夺系统。以往我们尝试过的方法包括把手机调成灰度模式减少视觉刺激。把娱乐 App 放到很深的文件夹增加打开成本。使用系统自带的屏幕时间限额到时间后弹窗提醒。这些方法有一定作用但都存在一个共同问题它们依赖于“用户主动配合”。系统弹窗可以点击“忽略”灰度模式也可以随时关闭。换句话说之前的方案是“软约束”而不是“硬阻断”。Haserupt 这类应用想解决的是另一个层面的问题如何让阻断机制不太依赖用户的即时意志力。如果把减少手机使用看作一个系统工程那么核心要素可以拆成以下几点感知识别用户当前在使用哪些应用以及使用了多久。策略判断当前是否处于应该被阻断的时间段或场景。执行在达到阈值或触发条件时弹出不可轻易跳过的拦截界面或者限制对应应用的使用。反馈记录拦截次数、实际使用时长帮助用户复盘。其中“执行”环节是技术实现上最需要花心思的部分。Android 系统为了保护用户隐私和防止恶意应用并不允许普通第三方应用随意地在别的应用上层弹窗、读取当前前台应用包名。因此这类产品几乎都需要依赖系统提供的辅助功能AccessibilityService权限和“使用情况访问”权限来实现。Haserupt 这个名字来自 “has erupted” 的组合语义有点“条件满足时爆发阻断”的意思。它本质上是一个基于时间和使用行为的“数字健康约束工具”。和常规的“屏幕时间管理”不太一样的地方在于它更强调“中断感”设计当规则命中时用户看到的是一个强提醒界面而不是一个温和的系统通知。从技术架构来看一个完整的减少手机使用方案通常包括三部分Android 客户端负责监听前台应用、展示拦截界面、执行用户自定义规则。本地或远端策略中心管理规则配置比如“工作日 23:00 之后禁止使用抖音”“每天刷微博超过 30 分钟就提醒”。数据统计模块记录屏幕解锁次数、使用时长、最常用应用排名、成功阻断次数。如果你的需求只是给自己用那么客户端本地存储规则就够了。如果要做一个面向家庭或团队的产品就需要引入服务端和账号体系后面我们会详细讨论。2. 需求分析与功能拆分在动手写代码之前先把需求边界理清楚。Haserupt 和类似应用的核心场景主要有以下四类2.1 场景一按时间段限制用户设定“晚上 11 点到早上 7 点”为免打扰时段。在这个时间段内社交媒体、短视频、游戏类应用启动时会被拦截。这类需求的关键在于时间规则解析不能出错跨天场景要处理。拦截界面要有明确的剩余时间提示。不能影响电话、短信、地图、支付等必要应用。2.2 场景二按累计时长限制用户设定“每天最多刷短视频 30 分钟”。应用需要累计当天该应用的使用时长超过阈值后开始拦截。这里牵扯到一个技术难点辅助功能事件可以拿到窗口变化的包名但要准确计算“某个 App 在前台停留了多久”需要在onAccessibilityEvent中监听TYPE_WINDOW_STATE_CHANGED事件并在前后台切换时打点记录时间差。2.3 场景三按启动次数限制用户设定“每天打开购物 App 不能超过 10 次”。每次检测到对应应用进入前台就累计一次计数达到阈值后拦截。2.4 场景四专注模式用户主动开启 25 分钟专注计时期间白名单之外的应用都会被拦截。这个场景对响应速度要求很高因为用户可能刚打开一个娱乐应用立刻就要被挡住。在功能拆分上一个最小可用产品需要包含以下模块功能模块职责说明技术实现要点前台应用监听获取当前正在使用的应用包名AccessibilityService 或 UsageStatsManager规则配置设置时间段、时长阈值、白名单本地数据库或 JSON 配置文件拦截判断判断当前是否命中阻断规则规则引擎支持时间、时长、次数组合拦截界面向用户展示无法跳过的提示高优先级 Dialog 或独立 Activity数据统计记录使用时长和拦截历史本地 SQLite/Room 数据库设置面板让用户自行配置规则Android 原生 UI 或 Compose对于想要做成一款真正靠谱产品的团队还需要加上家长控制或家庭共享需要服务端账号体系。防卸载机制需要设备管理器权限可做但要注意合规边界。多设备同步需要后端存储策略。心率或运动场景联动如果接入手环数据可以在用户高压力时自动放宽限制。这些功能会显著增加复杂度本文后续只实现一个本地 MVP减少对外部服务的依赖方便你在自己手机上直接跑起来。3. 环境准备与工具栈本项目的核心是 Android 客户端同时为了展示“策略中心”的思路我会加一个非常轻量的 Spring Boot 后端接口示例。整体开发环境以常见配置为例你在自己机器上需要根据实际安装版本调整。3.1 开发环境项目推荐配置说明操作系统Windows 10/11 或 macOS均可Android 开发与操作系统关系不大JDKJDK 17Android Gradle Plugin 8.x 依赖Android StudioHedgehog 或更新版本建议使用稳定版Gradle8.2 以上Android Studio 会自带Android SDKAPI 34 编译版本项目compileSdk使用 34手机系统Android 8.0 及以上辅助功能相关 API 在低版本上有差异后端可选Spring Boot 3.x H2 数据库仅用于实验策略发布如果你的 JDK 版本是 11 或 8需要把 Gradle 插件版本调低否则会出现兼容性报错。具体版本对应关系可以参考 Android Gradle Plugin 官方发布说明这里不把话说死。3.2 核心技术选型Android 端Kotlin 作为开发语言。AccessibilityService 实现前台应用监听和拦截跳转。UsageStatsManager 辅助统计应用使用时长。Room 数据库存储本地规则和统计数据。Jetpack Compose 或传统 View 都可以本文示例用 Activity XML 布局便于阅读。服务端可选Spring Boot 提供规则下发接口。H2 数据库保存规则配置重启不丢数据。如果你不想引入服务端直接跳过第 4.4 节即可不影响客户端功能。3.3 注意事项在开始之前需要理解一个容易被忽略的事实Android 系统对“读取当前前台应用包名”的权限控制得非常严格。第三方应用无法直接拿到“现在打开的是什么 App”只能通过以下两种方式间接获取AccessibilityService当窗口状态变化时系统会回调onAccessibilityEvent事件里面带有packageName。这种方式最实时但需要用户开启无障碍权限。UsageStatsManager在 Android 5.0 之后开放可以查询应用使用统计但获取的不是实时瞬间状态只能通过轮询和排序推断当前前台应用。Haserupt 要想做到“打开即拦截”的低延迟体验基本必须采用 AccessibilityService 方案。而使用无障碍权限收集前台应用信息一定要在隐私政策中明确说明数据用途否则应用市场审核会有风险。4. 核心原理与实现拆解理解原理比直接复制代码更重要。这一节我会把四个关键知识点的实现思路讲清楚。4.1 无障碍服务的原理与配置AccessibilityService 是一个系统级服务它可以在系统产生无障碍事件时回调我们的代码。常见的应用场景包括 TalkBack 语音辅助、自动点击工具、以及现在的屏幕使用管理。要定义一个无障碍服务需要在res/xml目录下创建配置文件并在AndroidManifest.xml中注册。新建res/xml/accessibility_service_config.xml?xml version1.0 encodingutf-8? accessibility-service xmlns:androidhttp://schemas.android.com/apk/res/android android:accessibilityEventTypestypeWindowStateChanged|typeWindowContentChanged android:accessibilityFeedbackTypefeedbackGeneric android:accessibilityFlagsflagDefault|flagRetrieveInteractiveWindows android:canRetrieveWindowContenttrue android:descriptionstring/accessibility_service_desc android:notificationTimeout100 android:settingsActivitycom.example.haserupt.MainActivity /这里解释几个关键属性android:accessibilityEventTypes声明我们想监听哪些事件。typeWindowStateChanged表示窗口状态变化也就是从一个 App 切换到另一个 App 时会触发typeWindowContentChanged表示页面内容变化一般用来辅助分析。android:canRetrieveWindowContent允许服务读取窗口内容。如果不需要解析具体控件可以不开但有些机型上不开会影响前台应用判断的准确性。notificationTimeout两个事件之间的最小通知间隔单位毫秒。设置 100ms 可以避免高频事件导致性能问题。settingsActivity用户在“无障碍设置”中点击该服务的“设置”入口时会跳到我们指定的 Activity。在AndroidManifest.xml中注册服务service android:name.service.AppMonitorService android:exportedtrue android:labelstring/app_name android:permissionandroid.permission.BIND_ACCESSIBILITY_SERVICE intent-filter action android:nameandroid.accessibilityservice.AccessibilityService / /intent-filter meta-data android:nameandroid.accessibilityservice android:resourcexml/accessibility_service_config / /service写到这里也许你会问为什么exportedtrue不会带来安全风险因为系统要求这个服务必须声明android.permission.BIND_ACCESSIBILITY_SERVICE权限。这是一个 signature 级别的系统权限只有系统才能绑定它。外部应用虽然能看到这个组件但无法直接拉起或绑定。4.2 前台应用监听实现服务启动后系统会不断回调onAccessibilityEvent。我们要做的是从事件中取出包名并且防止重复处理同一个前台应用。// 文件路径app/src/main/java/com/example/haserupt/service/AppMonitorService.kt package com.example.haserupt.service import android.accessibilityservice.AccessibilityService import android.view.accessibility.AccessibilityEvent import android.content.Intent import com.example.haserupt.interceptor.BlockActivity class AppMonitorService : AccessibilityService() { private var lastPackageName: String? null private var lastEventTime: Long 0 override fun onAccessibilityEvent(event: AccessibilityEvent?) { if (event null) return val packageName event.packageName?.toString() ?: return // 过滤掉自己避免拦截界面弹出时形成循环 if (packageName packageName) return // 只在窗口状态变化时处理避免同一窗口内多次回调 if (event.eventType ! AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED) return val now System.currentTimeMillis() // 防止同一事件被重复回调 if (packageName lastPackageName now - lastEventTime 1000) return lastPackageName packageName lastEventTime now val shouldBlock RuleChecker.shouldBlock(this, packageName) if (shouldBlock) { val intent Intent(this, BlockActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP) putExtra(packageName, packageName) } startActivity(intent) } } override fun onInterrupt() { // 系统中断服务时回调可以在这里做清理工作 } }这段代码的核心逻辑并不复杂获取事件携带的包名。判断包名是否是白名单内的系统应用。调用RuleChecker.shouldBlock检查是否命中规则。如果命中拉起一个BlockActivity作为拦截页面。这里有一个细节容易踩坑拦截页面本身的启动也会触发无障碍事件如果不加过滤可能会出现“BlockActivity 弹出后再次触发 onAccessibilityEvent然后再次拉起 BlockActivity”的循环。上面代码里我简单判断了packageName packageName实际开发时应该判断为“不是自己应用的包名时再继续处理”。4.3 阻断页面的实现思路BlockActivity的设计决定了用户的“被阻断感”有多强。理想状态是无法通过返回键退出。无法点击“忽略并继续”。展示明确的剩余时间或原因说明。提供“进入专注模式”或“暂时放行 5 分钟”的选项。从系统窗口层级来看普通 Activity 无法阻挡用户按 Home 键回到桌面也无法完全禁用最近任务列表。要真正做到“硬阻断”需要系统级的SYSTEM_ALERT_WINDOW权限或设备管理器能力。对于 Haserupt 这样偏个人工具的项目比较现实的方案是使用全屏 Activity并锁定任务栈。重写onBackPressed不执行默认返回。加入无障碍服务的“暂停功能”按钮防止用户直接关闭整个服务。一个简化版的BlockActivity代码如下// 文件路径app/src/main/java/com/example/haserupt/interceptor/BlockActivity.kt package com.example.haserupt.interceptor import android.os.Bundle import android.widget.Button import android.widget.TextView import androidx.appcompat.app.AppCompatActivity import com.example.haserupt.R class BlockActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_block) val packageName intent.getStringExtra(packageName) ?: unknown val reasonText findViewByIdTextView(R.id.tvBlockReason) val btnGiveUp findViewByIdButton(R.id.btnGiveUp) val btnFocus findViewByIdButton(R.id.btnFocus) reasonText.text 当前应用 $packageName 已被规则拦截 btnGiveUp.setOnClickListener { // 关闭当前拦截页回到桌面 finishAndRemoveTask() } btnFocus.setOnClickListener { // 启动一个 25 分钟专注计时器 startFocusTimer() finishAndRemoveTask() } } private fun startFocusTimer() { // TODO: 启动前台服务倒计时 25 分钟 } }这里不做一个真正意义上的“无法跳过”设计因为那涉及到设备管理器和多窗口模式的处理会超出本文范围。但对个人使用来说这个程度已经足够提供阻力。4.4 服务端策略中心可选当你有多个设备或者想把规则分享给家人时把配置信息放到本地文件里就不太方便了。这时候可以引入一个极简的服务端策略中心。下面是一个使用 Spring Boot 实现的接口示例只需要提供两个功能GET /api/rules/{deviceId}根据设备 ID 返回规则列表。POST /api/rules新增或更新规则。// 文件路径server/src/main/java/com/example/haserupt/controller/RuleController.java package com.example.haserupt.controller; import com.example.haserupt.entity.Rule; import com.example.haserupt.service.RuleService; import org.springframework.web.bind.annotation.*; import java.util.List; RestController RequestMapping(/api/rules) public class RuleController { private final RuleService ruleService; public RuleController(RuleService ruleService) { this.ruleService ruleService; } GetMapping(/{deviceId}) public ListRule getRules(PathVariable String deviceId) { return ruleService.getRulesByDevice(deviceId); } PostMapping public Rule saveRule(RequestBody Rule rule) { return ruleService.saveRule(rule); } }对应的实体类// 文件路径server/src/main/java/com/example/haserupt/entity/Rule.java package com.example.haserupt.entity; import jakarta.persistence.Entity; import jakarta.persistence.GeneratedValue; import jakarta.persistence.GenerationType; import jakarta.persistence.Id; import java.time.LocalTime; Entity public class Rule { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String deviceId; private String packageName; private LocalTime startTime; private LocalTime endTime; private Integer dailyLimitMinutes; private Boolean enabled; // 省略 getter/setter }这个后端不做登录鉴权真实项目中必须加上接口签名或者 token 机制否则任何人拿到 deviceId 都可以修改规则这不符合安全要求。5. 完整实战搭建一个最小可用 Android 应用了解了原理之后下面我们完整走一遍从创建项目到运行验证的流程。这里的目标是让你能快速在自己手机上跑通“监测到指定应用打开时弹出拦截页”的闭环。5.1 创建项目与基础配置打开 Android Studio选择 “New Project”模板选 “Empty Views Activity”。项目名称填HaseruptDemo包名填com.example.haserupt。语言选择 KotlinMinimum SDK 建议选 26Android 8.0。等待 Gradle 同步完成后修改app/build.gradle.kts确保编译版本为 34android { namespace com.example.haserupt compileSdk 34 defaultConfig { applicationId com.example.haserupt minSdk 26 targetSdk 34 versionCode 1 versionName 1.0 } }5.2 添加所需权限在AndroidManifest.xml中声明权限uses-permission android:nameandroid.permission.FOREGROUND_SERVICE / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS / uses-permission android:nameandroid.permission.QUERY_ALL_PACKAGES tools:ignoreQueryAllPackagesPermission /说明一下FOREGROUND_SERVICE用于确保应用在后台时监听服务仍然存活。POST_NOTIFICATIONS用于在 Android 13 以上发送通知方便用户知道服务正在运行。QUERY_ALL_PACKAGES用于查询设备上安装的应用列表。这个权限属于敏感权限如果应用市场不支持可以换成queries声明你需要查询的应用减少合规风险。在项目根目录创建app/src/main/res/xml/accessibility_service_config.xml配置内容参考第 4.1 节。5.3 编写规则检查器为了不让代码全部堆在服务里我们把规则判断逻辑单独抽出来。// 文件路径app/src/main/java/com/example/haserupt/service/RuleChecker.kt package com.example.haserupt.service import android.content.Context import java.util.Calendar object RuleChecker { // 简化示例只检查一个“屏蔽抖音”的固定规则 private val blockedApps setOf( com.ss.android.ugc.aweme, com.tencent.qqlive, com.smile.gifmaker ) fun shouldBlock(context: Context, packageName: String): Boolean { // 1. 白名单直接放行 if (!blockedApps.contains(packageName)) return false // 2. 获取当前小时 val now Calendar.getInstance() val hour now.get(Calendar.HOUR_OF_DAY) val minute now.get(Calendar.MINUTE) val currentMinutes hour * 60 minute // 示例规则每天 22:00 - 07:00 之间拦截娱乐类应用 // 跨天逻辑简化22点之后到7点之前都属于拦截时段 if (currentMinutes 22 * 60 || currentMinutes 7 * 60) { return true } // 3. 可以继续扩展检查当天累计时长是否超过阈值 return false } }这段代码只演示了“时间段命中”的场景。真实项目中你还需要把规则表设计成数据库表支持多种规则组合。不过原理一致判断规则命中后返回 true。5.4 主界面与权限引导用户第一次打开应用时需要引导去“无障碍设置”开启权限并且申请“使用情况访问”权限。主界面代码保持简单// 文件路径app/src/main/java/com/example/haserupt/MainActivity.kt package com.example.haserupt import android.content.Intent import android.net.Uri import android.os.Bundle import android.provider.Settings import android.widget.Button import androidx.appcompat.app.AppCompatActivity class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val btnOpenAccessibility findViewByIdButton(R.id.btnOpenAccessibility) val btnOpenUsage findViewByIdButton(R.id.btnOpenUsage) btnOpenAccessibility.setOnClickListener { startActivity(Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS)) } btnOpenUsage.setOnClickListener { startActivity(Intent(Settings.ACTION_USAGE_ACCESS_SETTINGS)) } } }activity_main.xml里放两个按钮和一行说明文字即可这里不贴完整布局避免文章过长。你只需要明确界面的作用是引导用户开启权限。5.5 构建与运行验证把手机通过 USB 连接到电脑开启开发者选项和 USB 调试然后点击 Android Studio 的 Run 按钮。首次安装后依次执行以下步骤打开应用点击“开启无障碍服务”。在系统设置中找到 HaseruptDemo开启无障碍权限。回到应用点击“开启使用情况访问权限”。打开被屏蔽的应用例如抖音观察是否自动弹出BlockActivity。如果弹出了拦截页面说明整个链路已经跑通如果没有大概率是无障碍服务没开启成功或者包名不对。这里有一个调试技巧你可以在AppMonitorService的onAccessibilityEvent中加一行日志打印当前收到的包名通过 Logcat 观察确认服务有没有收到事件。android.util.Log.d(Haserupt, Foreground app: $packageName)注意如果你没有安装抖音可以把blockedApps改成你本机任意一个应用包名比如微信com.tencent.mm或哔哩哔哩tv.danmaku.bili测试效果是一样的。5.6 验证结果说明正常运行时Logcat 中应该出现类似输出D/Haserupt: Foreground app: com.ss.android.ugc.aweme D/Haserupt: Block rule matched, starting BlockActivity同时在手机上会看到刚才打开的娱乐应用被拦截页覆盖。按返回键不会回到原 App而是回到桌面或者拦截页具体取决于你的系统版本和 BlockActivity 的实现。6. 安全、隐私与合规设计在实现这类应用时安全与隐私是非常重要的一环。不要因为只做个人工具就忽略这些细节尤其是如果未来有上架计划合规性会直接影响应用是否能通过审核。6.1 最小权限原则利用无障碍服务读取前台应用包名是这个方案绕不开的能力但这不代表你可以随意扩大权限范围。下面的做法值得坚持只获取你需要监控的应用包名不要把整个设备上的窗口内容都解析出来。不要在代码中保存用户输入密码、验证码等敏感内容。如果不需要读取窗口内容就不要打开canRetrieveWindowContent。6.2 数据存储与传输安全本地规则数据如果是敏感配置建议使用 Android Keystore 加密后再落盘。与服务端通信时必须使用 HTTPS并且在接口层面做签名校验防止中间人攻击和数据篡改。示例客户端请求服务端时增加签名头。val signature sha256(deviceId secret timestamp)不过这只是示意真正实现时需要把 secret 安全存储在 Keystore 中。6.3 防滥用与防卸载边界家长控制类应用倾向于加入“防卸载”机制但这需要申请设备管理器权限而且这类权限在 Android 10 之后的版本上限制越来越严格。从合规角度讲强制防卸载并不适合个人开发者上架也不符合 Android 对用户掌控权的要求。如果你的目标是减少自己的手机使用时间完全没必要做得那么硬。稍微留一点“软后门”反而符合产品伦理用户主动想开启也能自主关闭。6.4 审核策略提醒应用市场对无障碍权限的审核非常严格。如果你的应用在使用无障碍服务必须在应用内显著位置说明无障碍服务的用途。在隐私政策中列出收集的数据类型和数据使用方式。不能将该权限用于广告、自动点击、模拟操作等违反平台政策的行为。即使 Haserupt 本身是一个“戒瘾工具”也需要把这些说明写得清楚完整避免被误判为恶意应用。7. 常见问题与排查思路结合我实际开发类似工具的经历这里整理几个高频问题以及对应的排查方法。问题现象常见原因解决思路服务已开启但 Logcat 中一直没有事件输出无障碍服务没有真正激活或系统给服务关了权限重新进入“无障碍设置”确认开关打开查看系统日志是否有AccessibilityService崩溃能收到事件但包名一直是桌面启动器TYPE_WINDOW_STATE_CHANGED事件被频繁触发应用切换时收到了桌面包名在代码中过滤桌面启动器包名只记录状态持续时间超过 1 秒的包名拦截页面一闪而过马上回到原应用Activity 启动模式问题或者原应用又切换了窗口给BlockActivity设置android:launchModesingleInstance并在事件过滤中增加冷却时间Android 13 上通知不显示缺少运行时通知权限动态申请POST_NOTIFICATIONS权限应用被杀后功能失效国产 ROM 后台清理策略太激进引导用户开启“自启动”“后台运行”“锁屏保持”等权限考虑使用前台服务并显示常驻通知无法读取“使用情况访问”权限状态Android 版本差异使用AppOpsManager查询但要注意不同厂商 ROM 对OP_GET_USAGE_STATS的实现差异拦截页出现循环弹出BlockActivity的启动也触发了无障碍事件增加自身包名过滤在onAccessibilityEvent开头判断是否为本应用排查时建议按“服务是否活着 - 事件是否到达 - 规则是否命中 - UI 是否正常展示”四步走每一步都可以通过 Logcat 验证这样能快速定位问题出现在哪个环节。8. 最佳实践与工程建议写到这里整个最小闭环已经跑通。如果想把这个 Demo 发展成一个真正好用的产品下面几条建议可以参考。8.1 规则引擎与代码解耦初学者容易犯的错误是把所有判断逻辑堆在onAccessibilityEvent里。一旦规则增多代码会变得非常难维护。更好的做法是抽象出一个RuleEngine输入是当前包名、时间、当日累计时长输出是“拦截 or 放行”。// 设计示意非完整代码 interface Rule { fun evaluate(context: RuleContext): RuleResult } data class RuleContext( val packageName: String, val currentTime: LocalTime, val dailyUsageMinutes: MapString, Long ) data class RuleResult( val blocked: Boolean, val reason: String? )这样每增加一种规则只需要新增一个实现类而不需要改动服务主流程。8.2 使用数据库持久化规则不要用SharedPreferences存放复杂规则建议使用 Room 数据库。原因很简单规则会越来越多而且可能存在多设备同步的场景。数据库可以更自然地表达“时间段、包名、阈值、白名单”这些结构。Room 实体示例Entity(tableName block_rules) data class BlockRule( PrimaryKey(autoGenerate true) val id: Long 0, val packageName: String, val startHour: Int, val endHour: Int, val dailyLimitMinutes: Int?, val enabled: Boolean )8.3 事件防抖与性能优化无障碍事件非常频繁如果在onAccessibilityEvent中做大量数据库查询和 IO 操作会导致 UI 卡顿和耗电增加。建议采取以下优化措施事件处理中只做轻量判断把结果通过Handler或协程发到后台线程执行复杂计算。对同一包名加上冷却时间比如 2 秒内不重复处理。批量更新数据库避免每条使用记录都立刻写入。8.4 通知栏常驻提示由于无障碍服务属于敏感权限被系统回收的概率远高于普通 Service。建议使用前台服务并发布一条常驻通知让用户知道“数字健康监控正在运行”。这样既提高了进程存活率也符合用户知情权。8.5 设计“可被用户掌控”的退出机制这一点在产品伦理上很重要。减少手机使用工具如果做成了“用户无法关闭”的牢笼反而会激起强烈反感和抗拒心理。建议在拦截页设置“暂停 5 分钟”“今日不再拦截”等选项让用户有掌控感长期使用率反而更高。9. 总结与下一步这篇文章从 Haserupt 的产品理念出发完整梳理了“减少手机使用应用”的需求背景和技术实现路径。我们完成了以下关键能力理解无障碍服务在监听前台应用方面的工作原理。掌握规则检查与拦截页面触发的基本逻辑。实现了一个最小可运行的 Android 原型可以拦截指定应用。讨论了服务端策略中心的思路以及安全合规设计。如果你想继续深入可以从这几个方向入手完善规则系统支持“每日时长累计”“启动次数限制”“不同日期不同规则”。接入 Room 数据库让规则可以持久化编辑。增加使用统计报表通过图表展示每天减少了多少手机使用时间。研究 Android 13 对无障碍服务的新限制以及如何适配不同厂商 ROM。减少手机使用这件事本质上是人和注意力经济的对抗。工具只能提供一堵“减速墙”真正决定效果的是你是否愿意在墙面前停下。Haserupt 给了我一个很好的启发好的数字健康工具不是让人彻底不能玩手机而是让每一次打开手机这个动作从无意识变成有意识。如果你也正被手机使用时长困扰不妨照着这篇文章做一个让自己满意的版本规则自己定数据自己掌握这种感觉会比任何通用 App 都踏实。 Android无障碍服务实现应用拦截：手机使用限制应用开发实战
之前看到不少朋友在讨论“如何戒掉手机”的话题也见过各种屏幕上瘾的数据报告。真正动手做过限制手机使用功能的人会知道这个需求并没有想象中那么简单系统自带的“屏幕时间管理”不够强制卸载 App 又不太现实第三方应用也经常因为后台被杀而失效。最近看到一个很有意思的项目Haserupt定位是 “A new way to reduce your phone usage”从产品设计和技术实现上都给了我一些启发。这篇文章不打算只停留在“这个项目不错”的层面而是完整拆解它的需求背景、核心机制以及我们可以照着实现的一版简化方案。无论你是经常被手机使用时长困扰的普通用户还是对 Android 系统能力、后台任务、Behavior 触发机制感兴趣的开发者都可以从这篇文章里找到值得参考的内容。读完以后你能理解这类应用的关键设计点是什么也能跟着我在 Android Studio 中搭建一个最小可运行版本了解辅助功能、前台服务、策略配置在其中的具体作用。1. 背景与核心概念先聊一个比较现实的问题手机为什么越来越难放下从产品设计的角度看很多 App 本身就在利用人类心理的“不确定奖励”机制比如下拉刷新、小红点、无限信息流。你要对抗的并不是“意志力不足”这么简单而是一整套经过精心设计的注意力争夺系统。以往我们尝试过的方法包括把手机调成灰度模式减少视觉刺激。把娱乐 App 放到很深的文件夹增加打开成本。使用系统自带的屏幕时间限额到时间后弹窗提醒。这些方法有一定作用但都存在一个共同问题它们依赖于“用户主动配合”。系统弹窗可以点击“忽略”灰度模式也可以随时关闭。换句话说之前的方案是“软约束”而不是“硬阻断”。Haserupt 这类应用想解决的是另一个层面的问题如何让阻断机制不太依赖用户的即时意志力。如果把减少手机使用看作一个系统工程那么核心要素可以拆成以下几点感知识别用户当前在使用哪些应用以及使用了多久。策略判断当前是否处于应该被阻断的时间段或场景。执行在达到阈值或触发条件时弹出不可轻易跳过的拦截界面或者限制对应应用的使用。反馈记录拦截次数、实际使用时长帮助用户复盘。其中“执行”环节是技术实现上最需要花心思的部分。Android 系统为了保护用户隐私和防止恶意应用并不允许普通第三方应用随意地在别的应用上层弹窗、读取当前前台应用包名。因此这类产品几乎都需要依赖系统提供的辅助功能AccessibilityService权限和“使用情况访问”权限来实现。Haserupt 这个名字来自 “has erupted” 的组合语义有点“条件满足时爆发阻断”的意思。它本质上是一个基于时间和使用行为的“数字健康约束工具”。和常规的“屏幕时间管理”不太一样的地方在于它更强调“中断感”设计当规则命中时用户看到的是一个强提醒界面而不是一个温和的系统通知。从技术架构来看一个完整的减少手机使用方案通常包括三部分Android 客户端负责监听前台应用、展示拦截界面、执行用户自定义规则。本地或远端策略中心管理规则配置比如“工作日 23:00 之后禁止使用抖音”“每天刷微博超过 30 分钟就提醒”。数据统计模块记录屏幕解锁次数、使用时长、最常用应用排名、成功阻断次数。如果你的需求只是给自己用那么客户端本地存储规则就够了。如果要做一个面向家庭或团队的产品就需要引入服务端和账号体系后面我们会详细讨论。2. 需求分析与功能拆分在动手写代码之前先把需求边界理清楚。Haserupt 和类似应用的核心场景主要有以下四类2.1 场景一按时间段限制用户设定“晚上 11 点到早上 7 点”为免打扰时段。在这个时间段内社交媒体、短视频、游戏类应用启动时会被拦截。这类需求的关键在于时间规则解析不能出错跨天场景要处理。拦截界面要有明确的剩余时间提示。不能影响电话、短信、地图、支付等必要应用。2.2 场景二按累计时长限制用户设定“每天最多刷短视频 30 分钟”。应用需要累计当天该应用的使用时长超过阈值后开始拦截。这里牵扯到一个技术难点辅助功能事件可以拿到窗口变化的包名但要准确计算“某个 App 在前台停留了多久”需要在onAccessibilityEvent中监听TYPE_WINDOW_STATE_CHANGED事件并在前后台切换时打点记录时间差。2.3 场景三按启动次数限制用户设定“每天打开购物 App 不能超过 10 次”。每次检测到对应应用进入前台就累计一次计数达到阈值后拦截。2.4 场景四专注模式用户主动开启 25 分钟专注计时期间白名单之外的应用都会被拦截。这个场景对响应速度要求很高因为用户可能刚打开一个娱乐应用立刻就要被挡住。在功能拆分上一个最小可用产品需要包含以下模块功能模块职责说明技术实现要点前台应用监听获取当前正在使用的应用包名AccessibilityService 或 UsageStatsManager规则配置设置时间段、时长阈值、白名单本地数据库或 JSON 配置文件拦截判断判断当前是否命中阻断规则规则引擎支持时间、时长、次数组合拦截界面向用户展示无法跳过的提示高优先级 Dialog 或独立 Activity数据统计记录使用时长和拦截历史本地 SQLite/Room 数据库设置面板让用户自行配置规则Android 原生 UI 或 Compose对于想要做成一款真正靠谱产品的团队还需要加上家长控制或家庭共享需要服务端账号体系。防卸载机制需要设备管理器权限可做但要注意合规边界。多设备同步需要后端存储策略。心率或运动场景联动如果接入手环数据可以在用户高压力时自动放宽限制。这些功能会显著增加复杂度本文后续只实现一个本地 MVP减少对外部服务的依赖方便你在自己手机上直接跑起来。3. 环境准备与工具栈本项目的核心是 Android 客户端同时为了展示“策略中心”的思路我会加一个非常轻量的 Spring Boot 后端接口示例。整体开发环境以常见配置为例你在自己机器上需要根据实际安装版本调整。3.1 开发环境项目推荐配置说明操作系统Windows 10/11 或 macOS均可Android 开发与操作系统关系不大JDKJDK 17Android Gradle Plugin 8.x 依赖Android StudioHedgehog 或更新版本建议使用稳定版Gradle8.2 以上Android Studio 会自带Android SDKAPI 34 编译版本项目compileSdk使用 34手机系统Android 8.0 及以上辅助功能相关 API 在低版本上有差异后端可选Spring Boot 3.x H2 数据库仅用于实验策略发布如果你的 JDK 版本是 11 或 8需要把 Gradle 插件版本调低否则会出现兼容性报错。具体版本对应关系可以参考 Android Gradle Plugin 官方发布说明这里不把话说死。3.2 核心技术选型Android 端Kotlin 作为开发语言。AccessibilityService 实现前台应用监听和拦截跳转。UsageStatsManager 辅助统计应用使用时长。Room 数据库存储本地规则和统计数据。Jetpack Compose 或传统 View 都可以本文示例用 Activity XML 布局便于阅读。服务端可选Spring Boot 提供规则下发接口。H2 数据库保存规则配置重启不丢数据。如果你不想引入服务端直接跳过第 4.4 节即可不影响客户端功能。3.3 注意事项在开始之前需要理解一个容易被忽略的事实Android 系统对“读取当前前台应用包名”的权限控制得非常严格。第三方应用无法直接拿到“现在打开的是什么 App”只能通过以下两种方式间接获取AccessibilityService当窗口状态变化时系统会回调onAccessibilityEvent事件里面带有packageName。这种方式最实时但需要用户开启无障碍权限。UsageStatsManager在 Android 5.0 之后开放可以查询应用使用统计但获取的不是实时瞬间状态只能通过轮询和排序推断当前前台应用。Haserupt 要想做到“打开即拦截”的低延迟体验基本必须采用 AccessibilityService 方案。而使用无障碍权限收集前台应用信息一定要在隐私政策中明确说明数据用途否则应用市场审核会有风险。4. 核心原理与实现拆解理解原理比直接复制代码更重要。这一节我会把四个关键知识点的实现思路讲清楚。4.1 无障碍服务的原理与配置AccessibilityService 是一个系统级服务它可以在系统产生无障碍事件时回调我们的代码。常见的应用场景包括 TalkBack 语音辅助、自动点击工具、以及现在的屏幕使用管理。要定义一个无障碍服务需要在res/xml目录下创建配置文件并在AndroidManifest.xml中注册。新建res/xml/accessibility_service_config.xml?xml version1.0 encodingutf-8? accessibility-service xmlns:androidhttp://schemas.android.com/apk/res/android android:accessibilityEventTypestypeWindowStateChanged|typeWindowContentChanged android:accessibilityFeedbackTypefeedbackGeneric android:accessibilityFlagsflagDefault|flagRetrieveInteractiveWindows android:canRetrieveWindowContenttrue android:descriptionstring/accessibility_service_desc android:notificationTimeout100 android:settingsActivitycom.example.haserupt.MainActivity /这里解释几个关键属性android:accessibilityEventTypes声明我们想监听哪些事件。typeWindowStateChanged表示窗口状态变化也就是从一个 App 切换到另一个 App 时会触发typeWindowContentChanged表示页面内容变化一般用来辅助分析。android:canRetrieveWindowContent允许服务读取窗口内容。如果不需要解析具体控件可以不开但有些机型上不开会影响前台应用判断的准确性。notificationTimeout两个事件之间的最小通知间隔单位毫秒。设置 100ms 可以避免高频事件导致性能问题。settingsActivity用户在“无障碍设置”中点击该服务的“设置”入口时会跳到我们指定的 Activity。在AndroidManifest.xml中注册服务service android:name.service.AppMonitorService android:exportedtrue android:labelstring/app_name android:permissionandroid.permission.BIND_ACCESSIBILITY_SERVICE intent-filter action android:nameandroid.accessibilityservice.AccessibilityService / /intent-filter meta-data android:nameandroid.accessibilityservice android:resourcexml/accessibility_service_config / /service写到这里也许你会问为什么exportedtrue不会带来安全风险因为系统要求这个服务必须声明android.permission.BIND_ACCESSIBILITY_SERVICE权限。这是一个 signature 级别的系统权限只有系统才能绑定它。外部应用虽然能看到这个组件但无法直接拉起或绑定。4.2 前台应用监听实现服务启动后系统会不断回调onAccessibilityEvent。我们要做的是从事件中取出包名并且防止重复处理同一个前台应用。// 文件路径app/src/main/java/com/example/haserupt/service/AppMonitorService.kt package com.example.haserupt.service import android.accessibilityservice.AccessibilityService import android.view.accessibility.AccessibilityEvent import android.content.Intent import com.example.haserupt.interceptor.BlockActivity class AppMonitorService : AccessibilityService() { private var lastPackageName: String? null private var lastEventTime: Long 0 override fun onAccessibilityEvent(event: AccessibilityEvent?) { if (event null) return val packageName event.packageName?.toString() ?: return // 过滤掉自己避免拦截界面弹出时形成循环 if (packageName packageName) return // 只在窗口状态变化时处理避免同一窗口内多次回调 if (event.eventType ! AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED) return val now System.currentTimeMillis() // 防止同一事件被重复回调 if (packageName lastPackageName now - lastEventTime 1000) return lastPackageName packageName lastEventTime now val shouldBlock RuleChecker.shouldBlock(this, packageName) if (shouldBlock) { val intent Intent(this, BlockActivity::class.java).apply { addFlags(Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP) putExtra(packageName, packageName) } startActivity(intent) } } override fun onInterrupt() { // 系统中断服务时回调可以在这里做清理工作 } }这段代码的核心逻辑并不复杂获取事件携带的包名。判断包名是否是白名单内的系统应用。调用RuleChecker.shouldBlock检查是否命中规则。如果命中拉起一个BlockActivity作为拦截页面。这里有一个细节容易踩坑拦截页面本身的启动也会触发无障碍事件如果不加过滤可能会出现“BlockActivity 弹出后再次触发 onAccessibilityEvent然后再次拉起 BlockActivity”的循环。上面代码里我简单判断了packageName packageName实际开发时应该判断为“不是自己应用的包名时再继续处理”。4.3 阻断页面的实现思路BlockActivity的设计决定了用户的“被阻断感”有多强。理想状态是无法通过返回键退出。无法点击“忽略并继续”。展示明确的剩余时间或原因说明。提供“进入专注模式”或“暂时放行 5 分钟”的选项。从系统窗口层级来看普通 Activity 无法阻挡用户按 Home 键回到桌面也无法完全禁用最近任务列表。要真正做到“硬阻断”需要系统级的SYSTEM_ALERT_WINDOW权限或设备管理器能力。对于 Haserupt 这样偏个人工具的项目比较现实的方案是使用全屏 Activity并锁定任务栈。重写onBackPressed不执行默认返回。加入无障碍服务的“暂停功能”按钮防止用户直接关闭整个服务。一个简化版的BlockActivity代码如下// 文件路径app/src/main/java/com/example/haserupt/interceptor/BlockActivity.kt package com.example.haserupt.interceptor import android.os.Bundle import android.widget.Button import android.widget.TextView import androidx.appcompat.app.AppCompatActivity import com.example.haserupt.R class BlockActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_block) val packageName intent.getStringExtra(packageName) ?: unknown val reasonText findViewByIdTextView(R.id.tvBlockReason) val btnGiveUp findViewByIdButton(R.id.btnGiveUp) val btnFocus findViewByIdButton(R.id.btnFocus) reasonText.text 当前应用 $packageName 已被规则拦截 btnGiveUp.setOnClickListener { // 关闭当前拦截页回到桌面 finishAndRemoveTask() } btnFocus.setOnClickListener { // 启动一个 25 分钟专注计时器 startFocusTimer() finishAndRemoveTask() } } private fun startFocusTimer() { // TODO: 启动前台服务倒计时 25 分钟 } }这里不做一个真正意义上的“无法跳过”设计因为那涉及到设备管理器和多窗口模式的处理会超出本文范围。但对个人使用来说这个程度已经足够提供阻力。4.4 服务端策略中心可选当你有多个设备或者想把规则分享给家人时把配置信息放到本地文件里就不太方便了。这时候可以引入一个极简的服务端策略中心。下面是一个使用 Spring Boot 实现的接口示例只需要提供两个功能GET /api/rules/{deviceId}根据设备 ID 返回规则列表。POST /api/rules新增或更新规则。// 文件路径server/src/main/java/com/example/haserupt/controller/RuleController.java package com.example.haserupt.controller; import com.example.haserupt.entity.Rule; import com.example.haserupt.service.RuleService; import org.springframework.web.bind.annotation.*; import java.util.List; RestController RequestMapping(/api/rules) public class RuleController { private final RuleService ruleService; public RuleController(RuleService ruleService) { this.ruleService ruleService; } GetMapping(/{deviceId}) public ListRule getRules(PathVariable String deviceId) { return ruleService.getRulesByDevice(deviceId); } PostMapping public Rule saveRule(RequestBody Rule rule) { return ruleService.saveRule(rule); } }对应的实体类// 文件路径server/src/main/java/com/example/haserupt/entity/Rule.java package com.example.haserupt.entity; import jakarta.persistence.Entity; import jakarta.persistence.GeneratedValue; import jakarta.persistence.GenerationType; import jakarta.persistence.Id; import java.time.LocalTime; Entity public class Rule { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; private String deviceId; private String packageName; private LocalTime startTime; private LocalTime endTime; private Integer dailyLimitMinutes; private Boolean enabled; // 省略 getter/setter }这个后端不做登录鉴权真实项目中必须加上接口签名或者 token 机制否则任何人拿到 deviceId 都可以修改规则这不符合安全要求。5. 完整实战搭建一个最小可用 Android 应用了解了原理之后下面我们完整走一遍从创建项目到运行验证的流程。这里的目标是让你能快速在自己手机上跑通“监测到指定应用打开时弹出拦截页”的闭环。5.1 创建项目与基础配置打开 Android Studio选择 “New Project”模板选 “Empty Views Activity”。项目名称填HaseruptDemo包名填com.example.haserupt。语言选择 KotlinMinimum SDK 建议选 26Android 8.0。等待 Gradle 同步完成后修改app/build.gradle.kts确保编译版本为 34android { namespace com.example.haserupt compileSdk 34 defaultConfig { applicationId com.example.haserupt minSdk 26 targetSdk 34 versionCode 1 versionName 1.0 } }5.2 添加所需权限在AndroidManifest.xml中声明权限uses-permission android:nameandroid.permission.FOREGROUND_SERVICE / uses-permission android:nameandroid.permission.POST_NOTIFICATIONS / uses-permission android:nameandroid.permission.QUERY_ALL_PACKAGES tools:ignoreQueryAllPackagesPermission /说明一下FOREGROUND_SERVICE用于确保应用在后台时监听服务仍然存活。POST_NOTIFICATIONS用于在 Android 13 以上发送通知方便用户知道服务正在运行。QUERY_ALL_PACKAGES用于查询设备上安装的应用列表。这个权限属于敏感权限如果应用市场不支持可以换成queries声明你需要查询的应用减少合规风险。在项目根目录创建app/src/main/res/xml/accessibility_service_config.xml配置内容参考第 4.1 节。5.3 编写规则检查器为了不让代码全部堆在服务里我们把规则判断逻辑单独抽出来。// 文件路径app/src/main/java/com/example/haserupt/service/RuleChecker.kt package com.example.haserupt.service import android.content.Context import java.util.Calendar object RuleChecker { // 简化示例只检查一个“屏蔽抖音”的固定规则 private val blockedApps setOf( com.ss.android.ugc.aweme, com.tencent.qqlive, com.smile.gifmaker ) fun shouldBlock(context: Context, packageName: String): Boolean { // 1. 白名单直接放行 if (!blockedApps.contains(packageName)) return false // 2. 获取当前小时 val now Calendar.getInstance() val hour now.get(Calendar.HOUR_OF_DAY) val minute now.get(Calendar.MINUTE) val currentMinutes hour * 60 minute // 示例规则每天 22:00 - 07:00 之间拦截娱乐类应用 // 跨天逻辑简化22点之后到7点之前都属于拦截时段 if (currentMinutes 22 * 60 || currentMinutes 7 * 60) { return true } // 3. 可以继续扩展检查当天累计时长是否超过阈值 return false } }这段代码只演示了“时间段命中”的场景。真实项目中你还需要把规则表设计成数据库表支持多种规则组合。不过原理一致判断规则命中后返回 true。5.4 主界面与权限引导用户第一次打开应用时需要引导去“无障碍设置”开启权限并且申请“使用情况访问”权限。主界面代码保持简单// 文件路径app/src/main/java/com/example/haserupt/MainActivity.kt package com.example.haserupt import android.content.Intent import android.net.Uri import android.os.Bundle import android.provider.Settings import android.widget.Button import androidx.appcompat.app.AppCompatActivity class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val btnOpenAccessibility findViewByIdButton(R.id.btnOpenAccessibility) val btnOpenUsage findViewByIdButton(R.id.btnOpenUsage) btnOpenAccessibility.setOnClickListener { startActivity(Intent(Settings.ACTION_ACCESSIBILITY_SETTINGS)) } btnOpenUsage.setOnClickListener { startActivity(Intent(Settings.ACTION_USAGE_ACCESS_SETTINGS)) } } }activity_main.xml里放两个按钮和一行说明文字即可这里不贴完整布局避免文章过长。你只需要明确界面的作用是引导用户开启权限。5.5 构建与运行验证把手机通过 USB 连接到电脑开启开发者选项和 USB 调试然后点击 Android Studio 的 Run 按钮。首次安装后依次执行以下步骤打开应用点击“开启无障碍服务”。在系统设置中找到 HaseruptDemo开启无障碍权限。回到应用点击“开启使用情况访问权限”。打开被屏蔽的应用例如抖音观察是否自动弹出BlockActivity。如果弹出了拦截页面说明整个链路已经跑通如果没有大概率是无障碍服务没开启成功或者包名不对。这里有一个调试技巧你可以在AppMonitorService的onAccessibilityEvent中加一行日志打印当前收到的包名通过 Logcat 观察确认服务有没有收到事件。android.util.Log.d(Haserupt, Foreground app: $packageName)注意如果你没有安装抖音可以把blockedApps改成你本机任意一个应用包名比如微信com.tencent.mm或哔哩哔哩tv.danmaku.bili测试效果是一样的。5.6 验证结果说明正常运行时Logcat 中应该出现类似输出D/Haserupt: Foreground app: com.ss.android.ugc.aweme D/Haserupt: Block rule matched, starting BlockActivity同时在手机上会看到刚才打开的娱乐应用被拦截页覆盖。按返回键不会回到原 App而是回到桌面或者拦截页具体取决于你的系统版本和 BlockActivity 的实现。6. 安全、隐私与合规设计在实现这类应用时安全与隐私是非常重要的一环。不要因为只做个人工具就忽略这些细节尤其是如果未来有上架计划合规性会直接影响应用是否能通过审核。6.1 最小权限原则利用无障碍服务读取前台应用包名是这个方案绕不开的能力但这不代表你可以随意扩大权限范围。下面的做法值得坚持只获取你需要监控的应用包名不要把整个设备上的窗口内容都解析出来。不要在代码中保存用户输入密码、验证码等敏感内容。如果不需要读取窗口内容就不要打开canRetrieveWindowContent。6.2 数据存储与传输安全本地规则数据如果是敏感配置建议使用 Android Keystore 加密后再落盘。与服务端通信时必须使用 HTTPS并且在接口层面做签名校验防止中间人攻击和数据篡改。示例客户端请求服务端时增加签名头。val signature sha256(deviceId secret timestamp)不过这只是示意真正实现时需要把 secret 安全存储在 Keystore 中。6.3 防滥用与防卸载边界家长控制类应用倾向于加入“防卸载”机制但这需要申请设备管理器权限而且这类权限在 Android 10 之后的版本上限制越来越严格。从合规角度讲强制防卸载并不适合个人开发者上架也不符合 Android 对用户掌控权的要求。如果你的目标是减少自己的手机使用时间完全没必要做得那么硬。稍微留一点“软后门”反而符合产品伦理用户主动想开启也能自主关闭。6.4 审核策略提醒应用市场对无障碍权限的审核非常严格。如果你的应用在使用无障碍服务必须在应用内显著位置说明无障碍服务的用途。在隐私政策中列出收集的数据类型和数据使用方式。不能将该权限用于广告、自动点击、模拟操作等违反平台政策的行为。即使 Haserupt 本身是一个“戒瘾工具”也需要把这些说明写得清楚完整避免被误判为恶意应用。7. 常见问题与排查思路结合我实际开发类似工具的经历这里整理几个高频问题以及对应的排查方法。问题现象常见原因解决思路服务已开启但 Logcat 中一直没有事件输出无障碍服务没有真正激活或系统给服务关了权限重新进入“无障碍设置”确认开关打开查看系统日志是否有AccessibilityService崩溃能收到事件但包名一直是桌面启动器TYPE_WINDOW_STATE_CHANGED事件被频繁触发应用切换时收到了桌面包名在代码中过滤桌面启动器包名只记录状态持续时间超过 1 秒的包名拦截页面一闪而过马上回到原应用Activity 启动模式问题或者原应用又切换了窗口给BlockActivity设置android:launchModesingleInstance并在事件过滤中增加冷却时间Android 13 上通知不显示缺少运行时通知权限动态申请POST_NOTIFICATIONS权限应用被杀后功能失效国产 ROM 后台清理策略太激进引导用户开启“自启动”“后台运行”“锁屏保持”等权限考虑使用前台服务并显示常驻通知无法读取“使用情况访问”权限状态Android 版本差异使用AppOpsManager查询但要注意不同厂商 ROM 对OP_GET_USAGE_STATS的实现差异拦截页出现循环弹出BlockActivity的启动也触发了无障碍事件增加自身包名过滤在onAccessibilityEvent开头判断是否为本应用排查时建议按“服务是否活着 - 事件是否到达 - 规则是否命中 - UI 是否正常展示”四步走每一步都可以通过 Logcat 验证这样能快速定位问题出现在哪个环节。8. 最佳实践与工程建议写到这里整个最小闭环已经跑通。如果想把这个 Demo 发展成一个真正好用的产品下面几条建议可以参考。8.1 规则引擎与代码解耦初学者容易犯的错误是把所有判断逻辑堆在onAccessibilityEvent里。一旦规则增多代码会变得非常难维护。更好的做法是抽象出一个RuleEngine输入是当前包名、时间、当日累计时长输出是“拦截 or 放行”。// 设计示意非完整代码 interface Rule { fun evaluate(context: RuleContext): RuleResult } data class RuleContext( val packageName: String, val currentTime: LocalTime, val dailyUsageMinutes: MapString, Long ) data class RuleResult( val blocked: Boolean, val reason: String? )这样每增加一种规则只需要新增一个实现类而不需要改动服务主流程。8.2 使用数据库持久化规则不要用SharedPreferences存放复杂规则建议使用 Room 数据库。原因很简单规则会越来越多而且可能存在多设备同步的场景。数据库可以更自然地表达“时间段、包名、阈值、白名单”这些结构。Room 实体示例Entity(tableName block_rules) data class BlockRule( PrimaryKey(autoGenerate true) val id: Long 0, val packageName: String, val startHour: Int, val endHour: Int, val dailyLimitMinutes: Int?, val enabled: Boolean )8.3 事件防抖与性能优化无障碍事件非常频繁如果在onAccessibilityEvent中做大量数据库查询和 IO 操作会导致 UI 卡顿和耗电增加。建议采取以下优化措施事件处理中只做轻量判断把结果通过Handler或协程发到后台线程执行复杂计算。对同一包名加上冷却时间比如 2 秒内不重复处理。批量更新数据库避免每条使用记录都立刻写入。8.4 通知栏常驻提示由于无障碍服务属于敏感权限被系统回收的概率远高于普通 Service。建议使用前台服务并发布一条常驻通知让用户知道“数字健康监控正在运行”。这样既提高了进程存活率也符合用户知情权。8.5 设计“可被用户掌控”的退出机制这一点在产品伦理上很重要。减少手机使用工具如果做成了“用户无法关闭”的牢笼反而会激起强烈反感和抗拒心理。建议在拦截页设置“暂停 5 分钟”“今日不再拦截”等选项让用户有掌控感长期使用率反而更高。9. 总结与下一步这篇文章从 Haserupt 的产品理念出发完整梳理了“减少手机使用应用”的需求背景和技术实现路径。我们完成了以下关键能力理解无障碍服务在监听前台应用方面的工作原理。掌握规则检查与拦截页面触发的基本逻辑。实现了一个最小可运行的 Android 原型可以拦截指定应用。讨论了服务端策略中心的思路以及安全合规设计。如果你想继续深入可以从这几个方向入手完善规则系统支持“每日时长累计”“启动次数限制”“不同日期不同规则”。接入 Room 数据库让规则可以持久化编辑。增加使用统计报表通过图表展示每天减少了多少手机使用时间。研究 Android 13 对无障碍服务的新限制以及如何适配不同厂商 ROM。减少手机使用这件事本质上是人和注意力经济的对抗。工具只能提供一堵“减速墙”真正决定效果的是你是否愿意在墙面前停下。Haserupt 给了我一个很好的启发好的数字健康工具不是让人彻底不能玩手机而是让每一次打开手机这个动作从无意识变成有意识。如果你也正被手机使用时长困扰不妨照着这篇文章做一个让自己满意的版本规则自己定数据自己掌握这种感觉会比任何通用 App 都踏实。