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

最近我对项目里的 AI 主链路做了一轮比较系统的性能复盘目标很明确搞清楚单张图片处理为什么慢以及应该优先优化哪里。项目当前是Isar 业务真相层 ObjectBox 向量索引层的混合架构前面已经接入了 MobileCLIP、ObjectBox 向量索引、Android NNAPI hardware 路径和 Benchmark 能力。README 里也明确把 ObjectBox 定位成“向量索引层”后续主要负责近邻查询、相似图、主题候选召回等而不是业务主存储。这轮优化做下来我最大的收获不是“把某个函数快了几十毫秒”而是终于把主链路的真实账本看清楚了。一、先把误区纠正当前瓶颈不是 ObjectBox在最开始我也怀疑过是不是混合架构拖慢了主链路尤其是向量索引写入会不会成为热路径瓶颈。但真实 profiling 数据很快把这个猜想排除了。在一轮 100 张图片的真实 AI 分析中objectBoxAvgMs5.8tagAvgMs0.2inferenceAvgMs379loadAvgMs1089auxAvgMs526faceAvgMs488wallAvgMs3793wallP90Ms5677而completed-only样本里更明显loadAvgMs1161auxAvgMs1012analysisDecodeAvgMs234faceAvgMs938faceStoreAvgMs266inferenceAvgMs378objectBoxAvgMs5.8wallAvgMs4802wallP90Ms6415这组数据说明得非常清楚ObjectBox 不是当前主瓶颈。真正拖慢整条链路的是输入读图辅助分析图生成分析图二次 decode人脸检测/人脸链路以前还有同步 caption现在已经被摘掉换句话说这轮优化最大的价值就是把“是不是数据库慢”这个问题彻底回答掉了不是。二、第一阶段先把 caption 从热路径摘掉在更早的一轮 profiling 里caption 是最大单项captionAvgMs2002faceStoreAvgMs1047loadAvgMs631wallAvgMs5702completed 样本里甚至出现了更夸张的长尾某些图captionMs5177某些图captionMs7046某些图wallMs甚至到15373、21559所以第一刀很直接把远程 caption 改成受控小并发异步补全。改完以后新的 summary 里能看到captionDeferred52captionAvgMs0.0这说明 completed 图已经全部不再等待同步 captioncaption 真正从主链路里摘出去了。这个改动的意义不是“caption 更快了”而是主链路终于只统计“照片进入可用完成态”的时间不再被 2 秒级 caption 阻塞。三、第二阶段把 profiling 做细不再靠平均值猜为了让后续优化不再拍脑袋我补了两类 profiler 能力。1汇总口径拆成三种除了总 summary还加了final.completed-onlyfinal.cache-miss-only并补了wallP50MswallP90Ms这样就不会再被“junk 图把 completed 图平均值稀释”这个问题误导。2人脸链路彻底拆白盒单张 AI profile 里新增了这些 face 子段faceReadMsfaceDecodeSrcMsfaceWarmMsfaceCropMsfaceTempMsfaceEmbedMsfaceStoreIsarMsfaceStoreObxMsfaceCleanupMs这一步特别关键。因为它让我第一次确认faceStore 慢不是库写入慢而是前面的读旧脸、源图 decode、临时文件和 embedding 在拖。例如 completed-only 里faceAvgMs938faceStoreAvgMs266faceReadAvgMs139faceDecodeSrcAvgMs51.8faceTempAvgMs20.3faceEmbedAvgMs36.9faceStoreIsarAvgMs8.3faceStoreObxAvgMs0.8这意味着真正该优化的并不是“数据库写回”而是人脸链路前半段。四、第三阶段对输入读图策略做 A/B 实验既然 completed-only 里loadAvgMs一直很高我就把_prepareAnalysisInput做成了可切换策略并补进 profilerthumbnail_firstoriginal_firstthumbnail_timeout同时把这些字段打进单张 profile 和 summaryinputStrategythumbnailAttemptedthumbnailTimedOutfallbackToOriginalfallbackReasonstrategyMixfallbackMix这轮实验最核心的目的就是回答一个问题MobileCLIP 输入阶段到底应该优先走系统缩略图还是直接读原图五、A/B 实验结论默认继续保留thumbnail_first1thumbnail_first当前最佳默认档在thumbnail_first下final.completed-only的结果是strategyMixthumbnail_first:54thumbTimedOut0fallbackToOriginal0loadAvgMs1277decodeAvgMs54.7auxAvgMs1068faceAvgMs976wallAvgMs5803wallP50Ms4936wallP90Ms7412它的问题是前面 load 不算便宜但好处也非常明显后面的 decode 成本被压得很低。2thumbnail_timeout(120ms)当前配置下明显不合适这档实验的final.completed-only结果是thumbTimedOut59fallbackToOriginal59strategyMixthumbnail_timeout:65loadAvgMs734decodeAvgMs1582auxAvgMs1425analysisDecodeAvgMs451wallAvgMs6646wallP50Ms6679wallP90Ms9125表面上看loadAvgMs确实降了。但问题是120ms 这个 timeout 太激进导致大多数图都超时后回退原图后面的 decode、辅助图、分析图二次 decode 成本全面放大最终整体吞吐更差。3original_first当前也不适合作默认从拿到的滚动汇总看original_first的趋势也不理想loadAvgMs428decodeAvgMs856auxAvgMs1041faceAvgMs955faceStoreAvgMs1087wallAvgMs6375wallP50Ms6072wallP90Ms12570这说明original_first虽然把前置 load 变低了但很快在后面的 decode 和 face 链路里把成本重新放大。最终结论这轮 A/B 的答案很明确thumbnail_first当前最佳默认thumbnail_timeout(120ms)当前阈值不可用original_first不适合作默认所以目前最合理的默认策略仍然是继续保持thumbnail_first。六、这轮实验真正证明了什么如果只看表面可能会觉得“那不就是换了个读图策略吗”。但我觉得这轮最大的工程价值是1证明了当前性能热点确实在输入链路和分析链路不是 ObjectBox不是 ANN也不是 tag retrieval。而是loaddecodeauxanalysisDecodeface2证明了“更快拿到 bytes”不等于“整体更快”original_first和thumbnail_timeout都在某些阶段缩短了输入时间但由于后面的 decode 和辅助图链路成本更高整体 wall 反而更差。3证明了 profiler 设计方向是对的如果没有completed-onlycache-miss-onlywallP50 / wallP90strategyMix / fallbackMixface 子段 breakdown这轮实验根本不可能这么明确地下结论。七、现阶段我对项目性能优化的判断到这一步我会把项目当前状态总结成一句话向量索引层第一阶段已经站住了但主链路吞吐瓶颈不在索引层而在读图、辅助分析图和人脸链路。所以接下来最值得继续优化的顺序应该是_createAuxiliaryAnalysisFile先打辅助图生成和磁盘往返_readImageDimensions尽量不要为拿尺寸再做 full decoderebuildFacesForPhoto/ face pipeline优先减少旧脸读取、临时文件、重复 decode 和 embedding 中转最后才考虑继续抠 provider、ANN 或 ObjectBox八、我的阶段性结论这一轮优化最重要的结果不是某个指标掉了多少而是我终于可以非常有底气地说不是 ObjectBox 慢不是 ANN 该优先救火不是继续纠结 NNAPI/CPU 差 10%真正该打的是输入读图、辅助图生成、分析图 decode 和人脸链路如果用一句适合放在文章结尾的话来概括我会写成这样这轮优化把 AI 主链路从“黑盒慢”变成了“白盒慢”caption 已经成功摘出热路径ObjectBox 已被排除为主瓶颈下一阶段的优化重心应明确转向读图策略之外的辅助分析图和 ML Kit/face 链路。