文章归档

Android 性能优化不是上线前临时跑一次 Profiler，也不是看到卡顿后盲目改几行代码。真正稳定的做法，是把性能问题拆成可观测、可复现、可验证的工程流程：先知道慢在哪里，再判断为什么慢，最后用指标证明优化确实有效。

一、问题背景

本地使用 Codex CLI 时，如果日志级别过细，~/.codex/logs_2.sqlite 可能会持续写入大量 TRACE / DEBUG 日志。

这类问题不一定会立刻表现为程序异常，但会带来几个隐患：

• SQLite 主库文件持续变大。
• WAL 文件频繁增长。
• 磁盘出现持续小块写入。
• 日志价值不高，但占用大量 IO。
• 长时间运行后影响终端工具响应。

这次排查的目标很明确：

1. 确认 logs 表是否被 TRACE 日志高频写入。
2. 如果中招，先备份数据库。
3. 使用 SQLite trigger 拦截 logs 表 insert。
4. 对 WAL 执行 checkpoint / truncate。
5. 采样确认 MAX(id) 和 WAL 不再增长。

一、命令行效率的核心不是记命令

命令行用得快，不是因为记住了很多冷门参数，而是把高频操作变成稳定的工作流。

日常开发里最常见的操作其实很固定：

• 找文件。
• 搜索代码。
• 查看日志。
• 执行构建。
• 连接服务器。
• 清理临时文件。
• 重复执行一组检查。

如果每次都从头输入路径、拼参数、复制命令，时间会被这些小摩擦持续消耗。更好的方式是把常用工具组合起来，让命令行成为一个可重复、可沉淀的操作界面。

一、为什么要管理开发环境

开发环境一旦积累几年，就会变成很多零散配置：Shell、Git、编辑器、终端主题、常用脚本、SSH 配置、语言工具链。换电脑或重装系统时，如果没有记录，恢复成本很高。

一、先确认问题边界

网络问题最怕一上来就改配置。排障前先确认边界：是本机不能访问外部，还是外部不能访问本机；是所有域名都失败，还是只有某个服务失败。

一、什么是幂等

幂等指同一个操作执行一次和执行多次，最终产生的业务结果一致。

例如查询接口天然是幂等的：

1

GET /api/orders/1001

多查几次不会改变订单状态。

一、协程解决什么问题

协程不是为了让代码“看起来更高级”，而是为了用同步写法组织异步任务。网络请求、数据库读写、文件 IO、定时任务都可以放进协程里，让代码更容易串联和取消。

一、为什么 Compose 更强调状态

传统 View 体系里，页面通常是“找到控件，然后修改控件属性”：

1
2

textView.text = user.name
progressBar.visibility = View.GONE

Compose 的思路更接近“状态是什么，界面就长什么样”。当状态变化时，相关 Composable 会重新执行，生成新的 UI 描述。

一、NAS 解决什么问题

NAS 是 Network Attached Storage，也就是挂在网络上的存储设备。它不只是一个“大硬盘盒”，更像家庭或小团队的数据中心。

图片来源：Unsplash。

一、日志为什么需要治理

日志是排查线上问题最直接的证据，但不加治理的日志也会带来风险：

• 文件无限增长，磁盘被写满。
• 多进程写同一个文件，内容交错。
• 日志级别混乱，关键错误被淹没。
• 服务重启后旧日志无法关联。
• 没有采集和告警，问题只能靠人工发现。

日志治理要解决三个问题：写到哪里、保留多久、怎么发现异常。