用 AI Agent 把桌面宠物搬进 Android，dsh-pet-android 顺手记了点踩坑笔记

先说这个项目是啥

dsh-pet 是 DeepSeek Harness 生态里的一个桌面宠物插件，一只蓝色大肥鱼，待机呼吸、随机动作、点击弹台词、拖拽甩抛反弹，一百多段透明动画无缝切换。

桌面端它跑在 Electron 的透明 BrowserWindow 里。

但 Android 上没有 Electron，也没有“透明桌面窗口”这种东西。所以我做的事情，说白了就一句：把 Electron 那个透明窗口，换成 Android 的系统悬浮窗，让这只鱼飘在手机桌面上[reference:3]。

蓝色大肥鱼桌宠运行效果

仓库已经开源了，MIT，dsh-pet-android。

技术路线：没有重写，也没有硬搬

这里有一个很容易踩进去的坑：拿到一个移植任务，第一反应往往是“用目标平台的语言重写一遍”。

我也想过。dsh-pet 的上游是 TypeScript/Electron 那一套，如果全部用 Kotlin 重写，动画系统、状态机、台词逻辑、渲染循环，工作量直接起飞，而且很容易在重写过程中把原作者调好的手感丢掉。

最后的决定是：渲染层原封不动，平台层自己写。

宠物动画、渲染逻辑、台词、素材，全部来自上游。Android 这边只做平台适配——悬浮窗、触摸事件、前台服务、后台保活、设置页。渲染容器用 WebView，把上游的渲染代码直接塞进去跑。

上游 dsh-pet（Electron）
  ├── 动画 / 渲染 / 台词 / 素材  ← 原样保留
  └── 平台层（Electron 透明窗口） ← 替换
              ↓
Android 移植
  ├── WebView 承载渲染
  └── 系统悬浮窗（SYSTEM_ALERT_WINDOW）承载显示

这个决定让整个项目的核心复杂度降了一个数量级。Agent 不需要去理解那一百多段动画是怎么逐帧调度的，它只需要把“窗口”和“通信”这两件事在 Android 上搭对。

Agent 干得最好的，是“翻译”

这次用 Agent 的过程里，最顺畅的部分基本都是有明确对照物的翻译工作。

比如，上游用 Electron 的 BrowserWindow 设置透明和鼠标穿透。Android 这边对应的就是悬浮窗的 FLAG_NOT_TOUCHABLE 和 PixelFormat.TRANSLUCENT。把这两边的语义对应关系丢给 Agent，让它生成 Kotlin 代码，基本一遍过。

再比如触摸事件。上游处理拖拽和点击的逻辑是现成的，Agent 只需要把 Android 悬浮窗的 MotionEvent 翻译成上游能理解的坐标和事件类型，通过 WebView 的 JS Bridge 传进去。这部分它写得又快又准。

还有设置页、通知栏控制、版本检查这些“边角料”，模式固定、重复度高，交给 Agent 批量生成，比手敲舒服太多。仓库从 v1.0.9 到 v1.2.23，二十多个版本迭代下来，这些东西基本都是 Agent 铺出来的。

一句话概括：Agent 擅长“已知 A 在 B 上对应什么”的问题。

Agent 搞不定的，是“Android 本身的脾气”

但一到 Android 平台特有的那些隐形规则上，Agent 就开始表演什么叫“一本正经地给你埋雷”。

第一个坑：悬浮窗的触摸焦点

早期版本桌宠是能拖了，但长按菜单和 AI 对话的输入框死活弹不出键盘。

查下来是悬浮窗的 FLAG_NOT_FOCUSABLE 标志在作祟——它让窗口不抢焦点，好处是不影响桌面其他应用，坏处是需要键盘输入的时候，键盘根本不出来。社区补丁版也踩了同一个坑，把 setInteractive() 做成了空实现。

Agent 写这段的时候非常自信，因为它“见过”悬浮窗代码的常见写法。但它不理解 Android 的焦点模型和 Electron 的窗口焦点完全不是一回事。这个只能自己拿着真机一遍遍试。

第二个坑：国产 ROM 的保活

桌宠这东西，用户切到别的应用，它得一直在。但国产 ROM 的杀后台策略，用 Agent 的话说叫“非确定性行为”。

我最后的方案是三层保活 + 用户手动放行：电池优化白名单、自启动权限、最近任务加锁。文档里写得很直白：被系统清理后最多 15 分钟内自动回来，手动强制停止不会恢复。这个策略不是 Agent 想出来的，是翻了一堆踩坑帖之后自己定的，Agent 只负责把代码写出来。

第三个坑：完全体模式的无障碍权限

“完全体模式”允许宠物透明度拉到 100% 且不影响桌面点击，靠的是无障碍权限。Agent 能生成申请权限的代码，但它不会告诉你：这个权限在部分 ROM 上会被用户当成“可疑行为”。要不要做、怎么引导，是产品判断，不是代码生成。

所以 Agent 到底省了多少事？

Agent 到底省了多少事

说实话，省了很多，但没有省掉“想”的部分。

我的体感是：代码产出速度大概快了三四倍，但调试和决策的时间几乎没变。Agent 把“写”的成本打下来了，“想清楚”的成本还是原封不动摆在那里。

而且它有一个隐蔽的坏习惯：倾向于给你一个“看起来完整”的方案。悬浮窗 + WebView + 保活，一套组合拳给你摆得整整齐齐，你一眼扫过去觉得没问题，真机一跑，键盘不出来。

后来我养成一个习惯：Agent 生成的 Android 平台层代码，每一条系统 flag 都自己过一遍，不认识的查文档，不确定的写个最小 demo 先跑。它写的业务逻辑可以信任，它写的平台适配，得打问号。

最后说两句

这个项目从第一个开源版本到现在，二十多个小版本迭代下来，功能已经比较稳了：多宠物、AI 对话（OpenAI 兼容接口）、完全体模式、检查更新，不填 API Key 也能当普通桌宠用。

回看整个过程，AI Agent 确实让“一个人把桌面插件搬到 Android”这件事从“想想就算了”变成了“一个周末能出第一个能跑的版本”。但它没有让移植变成“无脑操作”。Electron 和 Android 之间那条语义鸿沟，Agent 能帮你搭桥，但桥搭在哪、承重多少、会不会塌，还是得自己盯着。

工具越强，判断越值钱。这话放在这次移植上，挺贴切的。

P.S. 项目地址在 github.com/ldyivan/dsh-pet-android，README 里写了安装和使用方法，想自己改的可以直接 fork。上游素材仅限开源使用，别拿去商用。