为什么有这个想法？

关于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](https://developer.android.com/develop/ui/views/notifications/live-update)

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

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