记录一下使用 AntiGravity 压榨 AI 开发一个 Android APP 的事情，并推广这个 APP

说在前面：关于节点的选择

我知道站内推广的东西应该放到推广节点，但是这不单单是一篇推广的文章，更像是一份给予 AI 高权限之后的心得体会记录（姑且可以成为“用后感”吧，哈哈）

为什么有这个想法？

关于 AI 的使用大家都有各自的原因，我这里就不过多赘述了，从刚开始的不信任，到现在的授予高权限，AI 的发展整体是向上并且超出我预期的，在公司也要求我们更多的将一些工作内容尝试交给 AI 完成，因此最近几个月来我用 AI 用的越来越多，这为 Pixel Meter 项目埋下了一开始的种子。

其实自从李跳跳不再维护开始，我是有想过自己写一个跳过广告的 APP ，为此我创建了仓库，参考一些别人博客的文章在开发自己的 APP ，但是从最开始的兴趣满满，到最后不想打开 IDE 写代码，一时兴起而产生的想法动力越发的不足，最后我放弃了，相信不少人都有过这样子的经历与体会（我不止是弃坑了这一个 app ，还有很多的东西都经历过这个流程）。

那时候我总觉得产生一个想法很简单，但是实现这个想法，哪怕是最开始的原型验证试水，对于个人来说成本还是太高了一些（毕竟需要花自己的空闲时间）。

同样的，这个周一开始（ 2025 年 12 月 22 日起），我突然就想要在我的 Pixel 10 Pro 上面能够实时查看网速的显示。几年前玩过 Android （类）原生的玩家都知道，因为（类）原生系统都是毛坯房，所谓的设备维护者其实更多是因为他们自己在使用这部设备，因此维护者偶尔会添加他们认为应该有的东西，例如一些系统动画、CJK 字重、网速显示等。而这些东西，国产 Rom 基本都是自带，而我们 Pixel 用户要么不用，要么只能自己想办法了。

于是我开始寻找网速显示的一些 APP ，并就此询问了 Gemini 的一些推荐（它居然在推荐列表里面把 Windows 的 TrafficMonitor 混进去，还告诉我说有 Android 版）。最终呢下载了几年前就在用的一些 APP ，当然都有缺点：

• NetSpeed Indicator：网速显示统计 VPN ，经典问题，流量数据翻倍（流量从 tun0 到网卡，计算的时候把所有网卡加起来，导致实际流量被重复计算）
• Internet Speed Meter Lite：统计数据粗略查看应该是没有重复，但是界面太老了，让我回想起了刚使用 Material Design 的感觉，免费版本带有广告，看着膈应，还塞进去了一个对我毫无卵用的流量统计功能
• Netspeed Indicator Magisk Module：要 ROOT 或者刷模块，直接 pass
• 其他的一些 app 以前没听过名字，现在也没兴趣一个个去试

突然，我有一个想法：为什么我不自己写一个？

因此我开始询问 AI ，被 Gemini 吹了一通彩虹屁，我觉得自己突然行了

付诸实施

既然有了想法，加上没有太多空闲时间，因此这一次我打算给 Gemini 高权限，如果可以的话，让它从 0 开始生成代码，直到所有功能完成

于是，我开始和它进行架构设计的探讨（架构探讨并不是第一次，公司的一些项目我也在和 AI 进行架构设计），技术栈的选型

最终敲定了使用双模式的方案进行开发：普通模式尽量精准，不准也无所谓；高权限模式（借助 Shizuku ）从数据源层面排除掉 VPN 网卡的流量数据，做到绝对的准确。

当然，这里我犯了一个错误，一开始我就应该在 AntiGravity 中发起会话的，这样 Gemini 能拿到完整的上下文直接开始生成代码，网页版 Gemini 则需要将这些“记忆”压缩成 md 文件再喂给 AntiGravity 。

压榨 AI

拿到这些压缩记忆的 md 文件之后，我通过 Android Studio 创建新项目，然后删除默认创建的一些测试依赖和测试类，使用 AntiGravity 打开项目，切到 Agent Manager 模式。

让 AI 根据这些压缩的记忆开始完善信息丢失的部分（信息在传递的过程中是会有丢失的），哪怕都是 Gemini ，毕竟是在两个地方打开，就像现实中的两个开发人员一样，同 A 沟通的内容，让 B 去做需要让 B 能够完全理解。这个步骤就是让 AI 根据文档对我发起反问，然后根据我的回答完善它的记忆以及文档。

具体的压榨过程就不一一描述了，扔个图就行，反正让它从昨晚工作到了现在（当然我睡觉的时候它也在“睡觉”），详细的一些方向性变更通过仓库提交记录也反映了出来。

整个使用过程我还觉得挺不错的，在这个过程中，我主要复杂代码审查和方向把控，代码审查是为了看它有没有按照我的想法进行编写，方向把控是为了纠正它可能出现的牛角尖状态，我觉得会话长了或者需要开启一个和当前任务关联性很小的需求，就单独开了一个会话。

到最后，整个项目 90%的代码（我手动写过一些代码，主要是审查以及纠正）、所有的文档内容（ README 、ChangeLog 、隐私政策）、上架 Google Play 的一些说明内容（简短说明、详细说明，甚至置顶大图） 都是让 Gemini 生成的。

用后感

和两年前我开发 SkipperL （跳广告的项目，已归档） 相比，AI 发展的太快了。两年前我还在为快速消退的热情而觉得可惜，两年后我们完全可以让 AI 帮助我们短时间内完成原型的验证，甚至完成开发！

项目推广

最后推广一下让 Gemini 做的这个项目吧： Pixel Meter （是的，它甚至是开源的）

Pixel Meter 是一款专为 Google Pixel 和原生 Android 设备设计的网速监控应用。它可以解决在使用 VPN 时，传统网速显示应用因同时统计物理接口和虚拟接口流量而导致显示速度翻倍的问题。

它和那些老前辈相比，除了更加现代化的 UI 界面之外，更重要的是使用标准的 API 解决了 VPN 网卡的流量计算问题（没有使用 Shizuku ）。

核心原理就是 TrafficStats.getRxBytes(ifaceName) 这个从 Android S 新增的 API ，它允许 app 获取指定网卡的流量数据，因此我们只需要遍历所有网卡，然后排除 VPN 网卡就行了，整体用起来达到的效果是：有 TrafficStats 的效率，有 NetworkStatsManager 的精准。

旧版本 API 的局限性：

• 老版本中只有 TrafficStats.getTotalRxBytes() 和 TrafficStats.getTotalTxBytes() 函数，获取到的数据已经包含了重复计算的部分，但是这个 API 响应快，计算差值也方便
• 而 NetworkStatsManager 并不适合用差值来计算网速，因为这个 API 主要用来统计流量，它是隔一段时间将数据写入，所以用起来的时候会出现一些奇怪的情况：上一秒流量显示正常，下一秒流量为 0 ，具体原因如下：

解决了数据源的问题之后，另一个难受的点是：网速显示太小了，虽然我们使用了绘制 Bitmap 的方案实时生成一个“通知图标”，但是这个图标的区域太小了，勉强只能看清楚数字，而单位很不清楚（一众老前辈都是用的这个方案）。另一个展示的方案是悬浮窗，这倒是能解决大小问题，但是会带来一个讨厌的顽固通知“XXX 正在其他应用的上层显示内容”

而 Pixel Meter 带来了一个创新的展示方案：Live Update Notification

这还是我在查阅关于发送通知的相关 API 的时候，偶尔看到的，实时活动+比通知图标宽 的两大优势，让我瞬间觉得，这就是应用层最适合网速显示场景的东西，因此，我开始让 AI 基于此进行代码开发。

另一个大的改变是：我懒得适配旧版本的系统（旧版本系统就用老旧 APP 足够了，反正都用不了实时活动），并且这东西优先向我进行适配，因此我将项目的 MinSDK 设置为了 36 。（旧版本如果有需要可以自行 fork 进行修改，符合开源协议即可）

)

而推广的目的，除了让大家知道这个方案之外，也是为了上架 Google Play 需要大家一起进行 14 天的封闭测试，期间收到邀请的账号才能够下载 APP ，感兴趣的小伙伴可以留下你们的 Google 账号，也可以通过邮箱发送给我。

邮箱地址：bXlzdGVyeTBkeWw1MjBAZ21haWwuY29t

本文同步发布： https://blog.mystery0.vip/archives/ai_power_for_pixel_meter