之前 MCompass 项目的博文引来不少流量，Cloudflare 后台的数据看得我挺惊喜。原本想过把这个小装置做成产品，但版权和量产成本确实是个砍。于是我开始想，能不能通过 AdSense 这种成熟的平台，让这些流量转化成一点维护网站的服务器成本。
结果没想到，Google 在接连几次申请中都给我发了“需要采取行动”的回执。信里说申请需要调整，但具体的“痛苦面”在哪又没说清楚。
我意识到，单纯堆内容是不够的，站点的“技术卫生习惯”——也就是 SEO 和抓取合规性，可能已经烂透了。于是，我决定给博客做一次彻底的底层清理。
之前买的Jetpack Compose教程的群群主最近一直在称赞Codex,Claude Code之类的有多么强大, 激发了我对这种CLI式的AI兴趣.是时候研究一下了.
在哔哩哔哩上简单搜索到几个介绍视频, 尤其是看到了Codex的那个演示, 一个人下发多个任务,然后每个任务后面都有一个AI在不同分支为他自动修改代码,调试代码直到完成任务,更是迫不及待的体验一下这种一个人就是一个团队的力量.
入行安卓开发已有一段时间。学生时期曾注册并使用过
Google Play 开发者账号，在当时的审核环境下完成过
多款应用的发布与实践。
随着平台政策和合规要求的持续调整，
该历史账号已主动终止使用，相关应用亦已停止维护。
该阶段的经历主要作为个人技术成长过程的一部分予以记录。
在原生Android开发的世界, 创建模版项目后就会得到一个MainActivity和activity_main.xml.
我们习惯了在MainActivity里去绑定Button和Text再设置各种属性. 他们都是内存中看得见,摸得着的View.
但是到了Flutter中, 得到的了却是main()函数和一堆StatelessWidget和StatefulWidget.
不仅仅是Flutter, 连Jetpack Compose也在向这种’声明式UI’靠拢.
Compose中同样找不到onResume(入口Activity除外),取而代之的而是层层嵌套的Composable函数
这种转变本质上是：我们不再持有 UI 的“句柄”，我们只持有“数据”。
正因为我们持有的只是数据，而数据本身是没有‘前后台’概念的（一个 String 字符串哪里知道自己是否在前台？）。所以，在声明式 UI 中寻找 onResume 本身就是一个伪命题。
只有当数据需要根据系统状态（如用户回来了）进行刷新时，我们才去主动询问系统。
(2025年11月 重制版说明):
这篇文章的初版我曾发布于第三方平台（简书+Bilibili），并累计获得了50,000+ 次阅读 和大量开发者的反馈。
为了提供更好的阅读体验，我对文章排版和部分内容进行了优化，并将其独家发布在此个人博客
不知道多久前看到了MIUI更新了”动态字体系统“功能,不过当时没太在意(毕竟我用的也不是MIUI,哈哈哈,不过确实挺方便的),演示视频里面展示了随意调节字体粗细的功能,后来知道这个参数叫做字重(zhong第四声).
19年8月30日晚7点，坐标上海唐镇，马路上一弱智掏出手机领完3周年签到补贴300石头后开始抽卡，10S后抽卡结束，没有看到CBA。
我抽了，1秒十连有什么好说的，一定是阿B在后台动了出货概率！
我一定要调查清楚，不出货肯定不是我的原因。
这时候想起了Fgo的B站官网有个实时滚动的出货信息，打开Chrome，F12查看调试信息。
得到如下两个链接，
YOLO是一个实时目标检测系统，通俗点说就是在输入数据(图片或者视频)中查找特定的目标。举个例子，如果让一个专门识别龙的YOLO模型观看《权力的游戏》，在理想情况下，一旦画面中出现了龙，YOLO系统就会激动地用框框标记出画面中的龙。
为什么是YOLO-tiny大概是贫穷限制了我的运算速度吧，YOLO-tiny用精确度换来了速度快和性能要求低的优点，适合练手和学习或者像我一样玩一玩的用户。
因为Mix Music解码的需求,所以得选择合适的解码工具.尝试了4种解码方式,最后还是FFmpeg的效果最好
