我以为是向量数据库拖慢了 AI，相册项目性能复盘后发现真正的锅在这里

最近我对项目里的 AI 主链路做了一轮比较系统的性能复盘，目标很明确：
搞清楚单张图片处理为什么慢，以及应该优先优化哪里。

项目当前是Isar 业务真相层 + ObjectBox 向量索引层的混合架构，前面已经接入了 MobileCLIP、ObjectBox 向量索引、Android NNAPI hardware 路径和 Benchmark 能力。README 里也明确把 ObjectBox 定位成“向量索引层”，后续主要负责近邻查询、相似图、主题候选召回等，而不是业务主存储。

这轮优化做下来，我最大的收获不是“把某个函数快了几十毫秒”，而是终于把主链路的真实账本看清楚了。

一、先把误区纠正：当前瓶颈不是 ObjectBox

在最开始，我也怀疑过是不是混合架构拖慢了主链路，尤其是向量索引写入会不会成为热路径瓶颈。
但真实 profiling 数据很快把这个猜想排除了。

在一轮 100 张图片的真实 AI 分析中：

• objectBoxAvgMs=5.8

• tagAvgMs=0.2

• inferenceAvgMs=379

• loadAvgMs=1089

• auxAvgMs=526

• faceAvgMs=488

• wallAvgMs=3793

• wallP90Ms=5677

而completed-only样本里更明显：

• loadAvgMs=1161

• auxAvgMs=1012

• analysisDecodeAvgMs=234

• faceAvgMs=938

• faceStoreAvgMs=266

• inferenceAvgMs=378

• objectBoxAvgMs=5.8

• wallAvgMs=4802

• wallP90Ms=6415

这组数据说明得非常清楚：

ObjectBox 不是当前主瓶颈。
真正拖慢整条链路的，是：

1. 输入读图

2. 辅助分析图生成

3. 分析图二次 decode

4. 人脸检测/人脸链路

5. 以前还有同步 caption，现在已经被摘掉

换句话说，这轮优化最大的价值，就是把“是不是数据库慢”这个问题彻底回答掉了：
不是。

二、第一阶段：先把 caption 从热路径摘掉

在更早的一轮 profiling 里，caption 是最大单项：

• captionAvgMs=2002

• faceStoreAvgMs=1047

• loadAvgMs=631

• wallAvgMs=5702

completed 样本里甚至出现了更夸张的长尾：

• 某些图captionMs=5177

• 某些图captionMs=7046

• 某些图wallMs甚至到15373、21559

所以第一刀很直接：
把远程 caption 改成受控小并发异步补全。

改完以后，新的 summary 里能看到：

• captionDeferred=52

• captionAvgMs=0.0

这说明 completed 图已经全部不再等待同步 caption，caption 真正从主链路里摘出去了。

这个改动的意义，不是“caption 更快了”，而是：

主链路终于只统计“照片进入可用完成态”的时间，不再被 2 秒级 caption 阻塞。

三、第二阶段：把 profiling 做细，不再靠平均值猜

为了让后续优化不再拍脑袋，我补了两类 profiler 能力。

1）汇总口径拆成三种

除了总 summary，还加了：

• final.completed-only

• final.cache-miss-only

并补了：

• wallP50Ms

• wallP90Ms

这样就不会再被“junk 图把 completed 图平均值稀释”这个问题误导。

2）人脸链路彻底拆白盒

单张 AI profile 里新增了这些 face 子段：

• faceReadMs

• faceDecodeSrcMs

• faceWarmMs

• faceCropMs

• faceTempMs

• faceEmbedMs

• faceStoreIsarMs

• faceStoreObxMs

• faceCleanupMs

这一步特别关键。因为它让我第一次确认：

faceStore 慢，不是库写入慢，而是前面的读旧脸、源图 decode、临时文件和 embedding 在拖。

例如 completed-only 里：

• faceAvgMs=938

• faceStoreAvgMs=266

• faceReadAvgMs=139

• faceDecodeSrcAvgMs=51.8

• faceTempAvgMs=20.3

• faceEmbedAvgMs=36.9

• faceStoreIsarAvgMs=8.3

• faceStoreObxAvgMs=0.8

这意味着真正该优化的并不是“数据库写回”，而是人脸链路前半段。

四、第三阶段：对输入读图策略做 A/B 实验

既然 completed-only 里loadAvgMs一直很高，我就把_prepareAnalysisInput做成了可切换策略，并补进 profiler：

• thumbnail_first

• original_first

• thumbnail_timeout

同时把这些字段打进单张 profile 和 summary：

• inputStrategy

• thumbnailAttempted

• thumbnailTimedOut

• fallbackToOriginal

• fallbackReason

• strategyMix

• fallbackMix

这轮实验最核心的目的，就是回答一个问题：

MobileCLIP 输入阶段，到底应该优先走系统缩略图，还是直接读原图？

五、A/B 实验结论：默认继续保留thumbnail_first

1）thumbnail_first：当前最佳默认档

在thumbnail_first下，final.completed-only的结果是：

• strategyMix=thumbnail_first:54

• thumbTimedOut=0

• fallbackToOriginal=0

• loadAvgMs=1277

• decodeAvgMs=54.7

• auxAvgMs=1068

• faceAvgMs=976

• wallAvgMs=5803

• wallP50Ms=4936

• wallP90Ms=7412

它的问题是前面 load 不算便宜，但好处也非常明显：
后面的 decode 成本被压得很低。

2）thumbnail_timeout(120ms)：当前配置下明显不合适

这档实验的final.completed-only结果是：

• thumbTimedOut=59

• fallbackToOriginal=59

• strategyMix=thumbnail_timeout:65

• loadAvgMs=734

• decodeAvgMs=1582

• auxAvgMs=1425

• analysisDecodeAvgMs=451

• wallAvgMs=6646

• wallP50Ms=6679

• wallP90Ms=9125

表面上看，loadAvgMs确实降了。
但问题是：120ms 这个 timeout 太激进，导致大多数图都超时后回退原图，后面的 decode、辅助图、分析图二次 decode 成本全面放大，最终整体吞吐更差。

3）original_first：当前也不适合作默认

从拿到的滚动汇总看，original_first的趋势也不理想：

• loadAvgMs=428

• decodeAvgMs=856

• auxAvgMs=1041

• faceAvgMs=955

• faceStoreAvgMs=1087

• wallAvgMs=6375

• wallP50Ms=6072

• wallP90Ms=12570

这说明original_first虽然把前置 load 变低了，但很快在后面的 decode 和 face 链路里把成本重新放大。

最终结论

这轮 A/B 的答案很明确：

• thumbnail_first：当前最佳默认

• thumbnail_timeout(120ms)：当前阈值不可用

• original_first：不适合作默认

所以目前最合理的默认策略仍然是：

继续保持thumbnail_first。

六、这轮实验真正证明了什么

如果只看表面，可能会觉得“那不就是换了个读图策略吗”。
但我觉得这轮最大的工程价值是：

1）证明了当前性能热点确实在输入链路和分析链路

不是 ObjectBox，不是 ANN，也不是 tag retrieval。
而是：

• load

• decode

• aux

• analysisDecode

• face

2）证明了“更快拿到 bytes”不等于“整体更快”

original_first和thumbnail_timeout都在某些阶段缩短了输入时间，但由于后面的 decode 和辅助图链路成本更高，整体 wall 反而更差。

3）证明了 profiler 设计方向是对的

如果没有：

• completed-only

• cache-miss-only

• wallP50 / wallP90

• strategyMix / fallbackMix

• face 子段 breakdown

这轮实验根本不可能这么明确地下结论。

七、现阶段我对项目性能优化的判断

到这一步，我会把项目当前状态总结成一句话：

向量索引层第一阶段已经站住了，但主链路吞吐瓶颈不在索引层，而在读图、辅助分析图和人脸链路。

所以接下来最值得继续优化的顺序应该是：

1. _createAuxiliaryAnalysisFile
   先打辅助图生成和磁盘往返

2. _readImageDimensions
   尽量不要为拿尺寸再做 full decode

3. rebuildFacesForPhoto/ face pipeline
   优先减少旧脸读取、临时文件、重复 decode 和 embedding 中转

4. 最后才考虑继续抠 provider、ANN 或 ObjectBox

八、我的阶段性结论

这一轮优化最重要的结果，不是某个指标掉了多少，而是我终于可以非常有底气地说：

• 不是 ObjectBox 慢

• 不是 ANN 该优先救火

• 不是继续纠结 NNAPI/CPU 差 10%

• 真正该打的是输入读图、辅助图生成、分析图 decode 和人脸链路

如果用一句适合放在文章结尾的话来概括，我会写成这样：

这轮优化把 AI 主链路从“黑盒慢”变成了“白盒慢”：caption 已经成功摘出热路径，ObjectBox 已被排除为主瓶颈，下一阶段的优化重心应明确转向读图策略之外的辅助分析图和 ML Kit/face 链路。