1. 从一次相册加载异常说起MediaScanner 到底在忙什么很多人第一次接触 Android 媒体扫描这个概念都是被一个很具体的现象逼出来的手机里明明存了几百张照片和几十段视频打开相册却只显示一部分或者新拍的照片要等好一会儿才出现。更让人摸不着头脑的是有时候重启一下手机媒体库又活过来了。这个现象背后就是MediaScanner和MediaProvider这一套机制在工作。先把这两个概念的关系理清楚。MediaProvider是 Android 系统里的一个内容提供者ContentProvider它对外暴露媒体数据库的访问接口所有 App 想查图片、音频、视频最终都是通过它去读external.db或internal.db这两个 SQLite 数据库。而MediaScanner是负责往数据库里填数据的那一方它扫描存储设备上的文件把符合媒体类型的文件信息路径、大小、时长、分辨率、缩略图等写进数据库。一个负责写一个负责读两者配合构成了 Android 媒体库的基础。那为什么需要扫描因为文件系统本身只知道自己有哪些文件它不知道哪个文件是图片、哪个是视频更不知道一段视频的时长是多少、一张照片的拍摄时间是什么时候。这些语义信息必须由扫描器解析文件头、读取元数据之后才能得到。所以 MediaScanner 的本质工作就是把文件系统里的原始文件翻译成媒体库能理解的元数据记录。这套机制涉及的角色其实比想象中多。除了 MediaScanner 和 MediaProvider还有 MediaScannerService承载扫描的 Service、MediaScannerReceiver监听广播触发扫描、MediaScannerConnection给 App 用的客户端接口以及底层真正干活的 Stagefright 系列解析器。理解它们各自的职责边界是后面做性能优化的前提。这篇文章适合三类人看一是做相册、文件管理、播放器类 App 的开发者需要理解媒体库为什么慢半拍二是做系统定制或 ROM 开发的工程师需要优化开机扫描和插卡扫描的耗时三是遇到媒体库数据不一致问题、想搞清楚排查思路的测试和运维人员。我会从流程拆解讲到性能优化尽量把每一步为什么这么做讲透而不是只丢结论。2. MediaScanner 的完整扫描链路拆解2.1 触发扫描的几种入口扫描不是凭空发生的它一定由某个事件触发。实际项目里最常见的触发入口有这么几类开机扫描系统启动完成后MediaScannerReceiver 收到ACTION_BOOT_COMPLETED触发一次全盘扫描。这是最重的一次扫描因为要遍历所有存储卷。存储挂载插入 SD 卡或外部存储挂载时收到ACTION_MEDIA_MOUNTED对该卷做扫描。单文件扫描App 通过MediaScannerConnection.scanFile()主动请求扫描某个具体文件常见于拍照后立即刷新相册。目录扫描某些场景下指定一个目录路径进行扫描。数据库变更通知文件被删除或修改时通过ACTION_MEDIA_SCANNER_SCAN_FILE之类的机制触发更新。这里有个容易被忽略的点开机扫描和插卡扫描走的是全量逻辑而单文件扫描走的是增量逻辑。全量扫描会遍历目录树逐个文件判断是否需要入库增量扫描只处理指定的那一个文件。两者的性能特征完全不同优化手段也不一样。2.2 从广播到 Service 的传递过程以开机扫描为例链路大致是这样的系统发出ACTION_BOOT_COMPLETED广播MediaScannerReceiver 的onReceive()被调用它根据 action 类型决定扫描哪个卷然后通过startService()把扫描请求交给 MediaScannerService。Service 在onStartCommand()里拿到 volume 参数最终调用scanVolume()或scanFile()。为什么中间要隔一个 Service因为扫描是耗时操作不能放在广播接收器里做。广播接收器的生命周期极短超过一定时间不返回就会 ANR。把重活丢给 Service让广播接收器快速返回这是 Android 里处理耗时任务的标准套路。理解这一点对后面分析为什么扫描会拖慢开机很关键——Service 虽然不阻塞广播但它依然占用 CPU 和 IO 资源。2.3 MediaScanner 内部的扫描主循环真正干活的是 MediaScanner 这个类底层对应 native 层的 MediaScanner。它的核心逻辑可以概括成一个递归遍历加逐文件处理的过程从扫描根目录开始用File.listFiles()或 native 的目录遍历接口拿到子项。对每个子项判断是目录还是文件。目录就递归进去文件就进入处理流程。对文件先做类型判断根据扩展名和 MIME 类型决定它是不是媒体文件、属于哪一类image/audio/video。如果是媒体文件调用doScanFile()这里会读取文件的元数据。元数据读取依赖 Stagefright 的 MediaMetadataRetriever 或对应的解析器提取时长、分辨率、码率、拍摄时间等信息。把提取到的信息组装成一条记录写入 MediaProvider 的数据库。如果文件之前已经扫过且没变化就跳过避免重复写库。第 7 步是性能优化的关键点之一。判断文件有没有变化通常靠对比文件的修改时间和大小如果两者都没变就认为内容没变直接跳过元数据解析。这个判断逻辑看似简单但实际项目里经常出问题后面会专门讲。2.4 元数据解析最耗时的环节整个扫描流程里元数据解析是绝对的性能瓶颈。原因很简单要拿到视频的时长和分辨率必须打开文件、读取文件头、解析容器格式有些格式甚至需要扫描到文件尾部。这个过程涉及大量的磁盘 IO 和 CPU 计算。以一段 4K 视频为例解析它的元数据可能需要几十毫秒甚至上百毫秒。如果手机里有几百段视频光解析这一项就能累积到几十秒。而图片相对轻量但如果是 RAW 格式或者超大尺寸的 JPEG解析 Exif 信息同样不便宜。这里有个反直觉的结论扫描耗时的大头往往不是遍历目录而是解析元数据。很多人优化时盯着目录遍历其实收益有限。真正该优化的是元数据解析环节比如缓存解析结果、延迟解析、并行解析等。2.5 数据写入 MediaProvider 的细节解析完元数据下一步是写库。MediaProvider 内部维护着files表和各类媒体专属表images、audio、video。写入时通常是一个事务里做 insert 或 update。写库这块有几个值得注意的细节批量写入 vs 单条写入单条 insert 每次都要走一次事务提交开销大。批量写入把多条记录攒在一起提交能显著减少 IO 次数。索引维护成本媒体表上通常有路径、日期等索引每次写入都要更新索引记录越多写入越慢。数据库锁竞争如果此时有 App 正在查询媒体库读写会争抢数据库锁导致双方都变慢。所以扫描性能优化不能只看扫描器本身还要看数据库这一侧的配合。3. 性能瓶颈到底卡在哪里逐环节定位3.1 用日志和耗时打点定位瓶颈优化之前必须先测量否则就是瞎猜。MediaScanner 本身有比较完善的日志可以通过logcat过滤MediaScanner关键字观察扫描进度。但光看日志不够最好在关键节点手动打点记录每个阶段的耗时。我通常会在这些位置加时间戳扫描开始、目录遍历结束、每个文件的元数据解析开始和结束、写库开始和结束、扫描整体结束。把这些时间戳一对比瓶颈立刻现形。如果发现目录遍历很快但元数据解析占了 80% 时间那优化方向就很明确了。提示打点日志建议用SystemClock.elapsedRealtime()而不是System.currentTimeMillis()前者是单调时钟不受系统时间调整影响测耗时更准。3.2 目录遍历阶段的隐藏开销目录遍历看起来简单其实也有坑。File.listFiles()在文件数量巨大的目录下会明显变慢因为它要一次性把所有文件名读进内存。如果一个目录下有上万个小文件光是列目录就可能卡住。更麻烦的是符号链接和循环目录。如果存储里存在指向父目录的软链接递归遍历会陷入死循环。正规的扫描器会记录已访问的 inode 或路径来避免重复但一些简化实现容易忽略这点。还有一个常见问题是扫描范围过大。有些实现会把整个存储根目录都扫一遍包括那些明显不可能有媒体文件的目录比如应用的私有缓存目录。提前排除这些目录能省下大量无谓的遍历。3.3 元数据解析的耗时构成把元数据解析拆开看耗时主要来自三块耗时来源说明优化空间文件打开与读取打开文件句柄、读取文件头中等可减少重复打开格式解析解析容器格式、提取轨道信息较大可缓存结果缩略图生成部分场景需要生成缩略图很大可延迟或按需生成其中缩略图生成是最容易被忽视的耗时大户。有些扫描实现会在扫描时顺手把缩略图也生成了这等于把最重的活提前做了。而实际上用户可能根本不会去看那些照片的缩略图。把缩略图生成改成按需触发扫描速度能提升一大截。3.4 数据库写入的锁与事务问题数据库这侧的瓶颈主要有两个事务粒度和锁竞争。如果每条记录都单独提交事务SQLite 每次都要做 fsync磁盘 IO 次数爆炸。正确的做法是把一批记录放在一个事务里提交比如每 100 条或每 500 毫秒提交一次。这样既保证了吞吐又不会让事务太大导致内存压力。锁竞争则更隐蔽。MediaProvider 的数据库是多个进程共享的扫描时如果 App 正在大量查询双方会互相等待。缓解办法是降低扫描写入的优先级或者把扫描安排在系统空闲时进行。有些系统会监听设备是否处于充电和息屏状态只在满足条件时才启动全量扫描这就是典型的错峰思路。3.5 一个真实的性能对比场景假设某设备存储里有 5000 张图片、300 段视频全量扫描的耗时分布大致是这样的这是基于常见实践的估算实际因设备而异目录遍历约 5%图片元数据解析约 30%视频元数据解析约 45%缩略图生成约 15%数据库写入约 5%从这个分布能看出视频解析和缩略图生成加起来占了六成。所以优化重点应该放在这两块视频解析可以并行化缩略图生成可以延迟化。而目录遍历和写库虽然也要优化但收益相对有限不该投入过多精力。4. 音视频扫描的针对性优化手段4.1 增量扫描只处理变化的文件全量扫描最大的浪费在于大部分文件其实没变过却每次都要重新解析。增量扫描的核心思路是只处理那些可能是新的或变化过的文件。判断依据通常有三条文件路径是否已在数据库中、文件的修改时间是否变化、文件大小是否变化。三条里任意一条不满足已存在且未变化就认为需要重新扫描。这个判断本身很轻量不需要打开文件所以能过滤掉绝大多数文件。但这里有个坑修改时间和大小都不变内容却变了的情况是存在的。比如某些工具修改文件后刻意保留了原始时间戳。这种情况下增量扫描会漏掉更新。所以增量扫描适合作为默认策略但要提供一个强制全量的兜底入口。4.2 并行解析把多核用起来元数据解析是 CPU 和 IO 混合型任务天然适合并行。单线程逐个解析时CPU 在等 IO 的时候是闲置的。改成多线程后一个线程等 IO 时另一个线程可以继续算整体吞吐能提升不少。并行度怎么定不是越大越好。线程太多会导致磁盘 IO 争抢反而变慢。经验值是2 到 4 个线程比较合适具体要看存储介质的随机读性能。如果是 eMMC 或 UFS随机读能力较强可以适当多开如果是低速 SD 卡开多了只会互相拖累。并行还有个顺序问题解析结果写库时要注意线程安全最好让解析和写库解耦解析线程只管产出结果写库统一由一个线程或队列处理。4.3 延迟与按需缩略图不要急着生成前面提到缩略图生成很耗时优化思路就是别在扫描时生成。扫描阶段只记录文件路径和基本元数据缩略图等到真正需要显示时再生成生成后缓存起来。Android 本身就有这套机制MediaStore 里的缩略图是懒加载的。但有些定制实现为了体验流畅在扫描时就把缩略图全生成了结果扫描慢得离谱。这是典型的用错了优化方向——为了省一次点击的等待牺牲了整个扫描的速度。如果确实需要预生成缩略图也应该限制尺寸和数量比如只对最近的照片生成或者只生成小尺寸的。全量预生成大尺寸缩略图在任何设备上都是灾难。4.4 视频解析的特殊处理视频解析比图片重得多值得单独优化。几个实用手段只读文件头大部分容器格式的元数据都在文件头部不需要读整个文件。确保解析器在拿到需要的信息后就停止读取不要傻乎乎地扫到文件尾。跳过损坏文件遇到无法解析的文件设置一个超时或重试上限别让它卡住整个扫描队列。缓存解析结果同一个文件如果被多次扫描直接复用上次的解析结果前提是文件没变。区分优先级最近修改的视频优先解析老视频可以延后。用户更可能马上看新拍的视频。4.5 数据库批量写入与索引优化写库这块除了前面说的事务批量提交还有几个细节预编译 SQL 语句反复执行同样的 insert/update 时预编译能省下解析 SQL 的开销。合理设置索引索引不是越多越好每个索引都会拖慢写入。只保留查询真正用得到的索引。定期整理数据库长期使用后数据库会产生碎片定期做一次 vacuum 能改善读写性能。注意批量写入时事务不能无限大。事务太大一旦失败回滚成本极高而且会长时间持有数据库锁。建议按条数或时间双阈值控制比如每 200 条或每 500 毫秒提交一次先到先提交。5. 踩坑实录那些让扫描变慢的隐蔽问题5.1 修改时间不准导致的重复扫描前面提过增量扫描依赖修改时间但实际项目里修改时间不准是高频问题。有些设备在拷贝文件时会把修改时间设成拷贝时刻导致每次扫描都认为文件是新的。还有些文件系统的时间精度只有秒级同一秒内多次修改无法区分。排查这类问题的办法是在扫描日志里打印出判定为需要重新扫描的文件及其修改时间看看是不是有一批文件的修改时间异常地集中在某个时刻。如果是基本可以确定是时间戳问题。解决思路是引入更可靠的判断依据比如文件内容的哈希成本高慎用或者结合其他元数据。5.2 大目录遍历卡死某次遇到一个案例扫描到某个目录时直接卡住不动。排查后发现该目录下有超过十万个小文件listFiles()一次性读取把所有文件名塞进内存触发了频繁 GC最终卡死。解决办法是分批遍历不要一次性列出所有文件。用 native 的目录遍历接口逐个读取或者对超大目录做分片处理。同时给单个目录的遍历设置上限超过就跳过并记录日志避免个别异常目录拖垮整个扫描。5.3 扫描与查询的锁竞争有用户反馈扫描进行时相册 App 卡得几乎不能用。抓 trace 发现是数据库锁竞争——扫描在写库时持有写锁相册查询要读同一张表被阻塞了。这个问题的根源是读写没有分离好。SQLite 默认的锁粒度比较粗写的时候读会被挡。缓解办法有几种一是降低扫描写入频率给读操作留出窗口二是用 WAL 模式让读写可以并发三是把扫描安排在用户不活跃的时段。实际项目里通常是几种手段组合使用。5.4 扫描被中断后的数据一致性扫描过程中如果进程被杀比如内存紧张被系统回收数据库里可能留下扫了一半的状态。下次扫描时如果不做处理可能出现重复记录或数据不一致。处理思路是引入扫描会话的概念每次扫描开始前记录一个会话 ID扫描过程中写入的记录都带上这个 ID扫描正常结束后清除标记。如果发现存在未正常结束的会话下次启动时先清理这些残留记录。这样能保证数据库最终是一致的。5.5 排查链路复盘把上面这些坑的排查过程抽象一下其实有一套通用套路先确认现象是扫描慢还是扫描结果不对还是扫描时其他功能卡不同现象指向不同原因。再看日志扫描日志能告诉你卡在哪个文件、哪个阶段。然后打点在关键节点加耗时统计定位到具体环节。接着复现构造一个能稳定复现的最小场景比如固定数量的文件。最后验证改完之后用同样的场景对比耗时确认优化有效。这套流程看着简单但很多人一上来就猜原因、直接改代码结果改了半天没效果。先测量再优化这句话在扫描优化里尤其重要。6. 把扫描做稳做快的几条实战经验6.1 扫描策略要分场景设计不存在一套通吃的扫描策略。开机扫描、插卡扫描、单文件扫描场景不同策略就该不同开机扫描用户刚开机对速度不敏感但对系统流畅度敏感。适合低优先级、后台慢慢扫甚至可以延迟到开机后一段时间再启动。插卡扫描用户刚插卡期待尽快看到内容。适合较高优先级但也要控制资源占用。单文件扫描用户刚拍完照期待立刻看到。适合最高优先级但只处理一个文件成本可控。把策略和场景绑定比用一套参数硬扛所有情况要合理得多。6.2 给扫描设置资源预算扫描是后台任务不该无限制地占用资源。给扫描设置一个资源预算比如最多占用两个 CPU 核心每秒最多写库 N 次内存占用不超过 X MB超出预算就主动降速。这样能保证扫描不会把前台体验拖垮。资源预算的另一个好处是可预测。有了预算就能估算出扫描大概要多久从而决定是立即扫还是延后扫。6.3 监控与告警不能少扫描是长期运行的后台任务出问题往往不容易第一时间发现。建议加上监控记录每次扫描的耗时、处理文件数、失败文件数超过阈值就告警。这样能在问题扩大前发现苗头。监控数据还能用来做趋势分析。比如发现扫描耗时逐月上升可能是存储里的文件越来越多或者数据库碎片化严重需要针对性处理。6.4 兼容性要提前考虑不同 Android 版本、不同厂商的存储实现差异很大。分区的挂载方式、权限模型、数据库位置都可能不同。做扫描优化时一定要在多个版本和机型上验证别只在自己手头那台设备上测通了就以为万事大吉。尤其是分区存储相关的变更对扫描路径和权限影响很大。新版本上能扫的目录老版本上可能扫不了反之亦然。提前把这些差异摸清楚能省下大量后期适配的功夫。6.5 我个人的一点体会做了这么多年的媒体扫描相关优化最大的感受是扫描慢往往不是算法问题而是策略问题。很多团队一上来就想优化解析算法结果发现算法本身已经够快了慢是因为在不该扫的时候扫了、不该解析的时候解析了、不该生成的时候生成了。所以每次遇到扫描性能问题我都会先问三个问题这次扫描真的有必要吗这些文件真的需要现在解析吗这些数据真的需要现在生成吗把这三个问题想清楚往往不用改一行核心代码性能就能提升一大截。剩下的才是算法和工程层面的优化那部分虽然也有价值但优先级要排在策略之后。另外扫描相关的 bug 往往有很强的隐蔽性因为它们依赖具体的文件状态和时序。测试时一定要构造足够多样的文件组合——大文件、小文件、损坏文件、特殊格式、超长路径、深层目录把这些边界情况都覆盖到才能在上线前把问题挡在门外。
1. 从一次相册加载异常说起MediaScanner 到底在忙什么很多人第一次接触 Android 媒体扫描这个概念都是被一个很具体的现象逼出来的手机里明明存了几百张照片和几十段视频打开相册却只显示一部分或者新拍的照片要等好一会儿才出现。更让人摸不着头脑的是有时候重启一下手机媒体库又活过来了。这个现象背后就是MediaScanner和MediaProvider这一套机制在工作。先把这两个概念的关系理清楚。MediaProvider是 Android 系统里的一个内容提供者ContentProvider它对外暴露媒体数据库的访问接口所有 App 想查图片、音频、视频最终都是通过它去读external.db或internal.db这两个 SQLite 数据库。而MediaScanner是负责往数据库里填数据的那一方它扫描存储设备上的文件把符合媒体类型的文件信息路径、大小、时长、分辨率、缩略图等写进数据库。一个负责写一个负责读两者配合构成了 Android 媒体库的基础。那为什么需要扫描因为文件系统本身只知道自己有哪些文件它不知道哪个文件是图片、哪个是视频更不知道一段视频的时长是多少、一张照片的拍摄时间是什么时候。这些语义信息必须由扫描器解析文件头、读取元数据之后才能得到。所以 MediaScanner 的本质工作就是把文件系统里的原始文件翻译成媒体库能理解的元数据记录。这套机制涉及的角色其实比想象中多。除了 MediaScanner 和 MediaProvider还有 MediaScannerService承载扫描的 Service、MediaScannerReceiver监听广播触发扫描、MediaScannerConnection给 App 用的客户端接口以及底层真正干活的 Stagefright 系列解析器。理解它们各自的职责边界是后面做性能优化的前提。这篇文章适合三类人看一是做相册、文件管理、播放器类 App 的开发者需要理解媒体库为什么慢半拍二是做系统定制或 ROM 开发的工程师需要优化开机扫描和插卡扫描的耗时三是遇到媒体库数据不一致问题、想搞清楚排查思路的测试和运维人员。我会从流程拆解讲到性能优化尽量把每一步为什么这么做讲透而不是只丢结论。2. MediaScanner 的完整扫描链路拆解2.1 触发扫描的几种入口扫描不是凭空发生的它一定由某个事件触发。实际项目里最常见的触发入口有这么几类开机扫描系统启动完成后MediaScannerReceiver 收到ACTION_BOOT_COMPLETED触发一次全盘扫描。这是最重的一次扫描因为要遍历所有存储卷。存储挂载插入 SD 卡或外部存储挂载时收到ACTION_MEDIA_MOUNTED对该卷做扫描。单文件扫描App 通过MediaScannerConnection.scanFile()主动请求扫描某个具体文件常见于拍照后立即刷新相册。目录扫描某些场景下指定一个目录路径进行扫描。数据库变更通知文件被删除或修改时通过ACTION_MEDIA_SCANNER_SCAN_FILE之类的机制触发更新。这里有个容易被忽略的点开机扫描和插卡扫描走的是全量逻辑而单文件扫描走的是增量逻辑。全量扫描会遍历目录树逐个文件判断是否需要入库增量扫描只处理指定的那一个文件。两者的性能特征完全不同优化手段也不一样。2.2 从广播到 Service 的传递过程以开机扫描为例链路大致是这样的系统发出ACTION_BOOT_COMPLETED广播MediaScannerReceiver 的onReceive()被调用它根据 action 类型决定扫描哪个卷然后通过startService()把扫描请求交给 MediaScannerService。Service 在onStartCommand()里拿到 volume 参数最终调用scanVolume()或scanFile()。为什么中间要隔一个 Service因为扫描是耗时操作不能放在广播接收器里做。广播接收器的生命周期极短超过一定时间不返回就会 ANR。把重活丢给 Service让广播接收器快速返回这是 Android 里处理耗时任务的标准套路。理解这一点对后面分析为什么扫描会拖慢开机很关键——Service 虽然不阻塞广播但它依然占用 CPU 和 IO 资源。2.3 MediaScanner 内部的扫描主循环真正干活的是 MediaScanner 这个类底层对应 native 层的 MediaScanner。它的核心逻辑可以概括成一个递归遍历加逐文件处理的过程从扫描根目录开始用File.listFiles()或 native 的目录遍历接口拿到子项。对每个子项判断是目录还是文件。目录就递归进去文件就进入处理流程。对文件先做类型判断根据扩展名和 MIME 类型决定它是不是媒体文件、属于哪一类image/audio/video。如果是媒体文件调用doScanFile()这里会读取文件的元数据。元数据读取依赖 Stagefright 的 MediaMetadataRetriever 或对应的解析器提取时长、分辨率、码率、拍摄时间等信息。把提取到的信息组装成一条记录写入 MediaProvider 的数据库。如果文件之前已经扫过且没变化就跳过避免重复写库。第 7 步是性能优化的关键点之一。判断文件有没有变化通常靠对比文件的修改时间和大小如果两者都没变就认为内容没变直接跳过元数据解析。这个判断逻辑看似简单但实际项目里经常出问题后面会专门讲。2.4 元数据解析最耗时的环节整个扫描流程里元数据解析是绝对的性能瓶颈。原因很简单要拿到视频的时长和分辨率必须打开文件、读取文件头、解析容器格式有些格式甚至需要扫描到文件尾部。这个过程涉及大量的磁盘 IO 和 CPU 计算。以一段 4K 视频为例解析它的元数据可能需要几十毫秒甚至上百毫秒。如果手机里有几百段视频光解析这一项就能累积到几十秒。而图片相对轻量但如果是 RAW 格式或者超大尺寸的 JPEG解析 Exif 信息同样不便宜。这里有个反直觉的结论扫描耗时的大头往往不是遍历目录而是解析元数据。很多人优化时盯着目录遍历其实收益有限。真正该优化的是元数据解析环节比如缓存解析结果、延迟解析、并行解析等。2.5 数据写入 MediaProvider 的细节解析完元数据下一步是写库。MediaProvider 内部维护着files表和各类媒体专属表images、audio、video。写入时通常是一个事务里做 insert 或 update。写库这块有几个值得注意的细节批量写入 vs 单条写入单条 insert 每次都要走一次事务提交开销大。批量写入把多条记录攒在一起提交能显著减少 IO 次数。索引维护成本媒体表上通常有路径、日期等索引每次写入都要更新索引记录越多写入越慢。数据库锁竞争如果此时有 App 正在查询媒体库读写会争抢数据库锁导致双方都变慢。所以扫描性能优化不能只看扫描器本身还要看数据库这一侧的配合。3. 性能瓶颈到底卡在哪里逐环节定位3.1 用日志和耗时打点定位瓶颈优化之前必须先测量否则就是瞎猜。MediaScanner 本身有比较完善的日志可以通过logcat过滤MediaScanner关键字观察扫描进度。但光看日志不够最好在关键节点手动打点记录每个阶段的耗时。我通常会在这些位置加时间戳扫描开始、目录遍历结束、每个文件的元数据解析开始和结束、写库开始和结束、扫描整体结束。把这些时间戳一对比瓶颈立刻现形。如果发现目录遍历很快但元数据解析占了 80% 时间那优化方向就很明确了。提示打点日志建议用SystemClock.elapsedRealtime()而不是System.currentTimeMillis()前者是单调时钟不受系统时间调整影响测耗时更准。3.2 目录遍历阶段的隐藏开销目录遍历看起来简单其实也有坑。File.listFiles()在文件数量巨大的目录下会明显变慢因为它要一次性把所有文件名读进内存。如果一个目录下有上万个小文件光是列目录就可能卡住。更麻烦的是符号链接和循环目录。如果存储里存在指向父目录的软链接递归遍历会陷入死循环。正规的扫描器会记录已访问的 inode 或路径来避免重复但一些简化实现容易忽略这点。还有一个常见问题是扫描范围过大。有些实现会把整个存储根目录都扫一遍包括那些明显不可能有媒体文件的目录比如应用的私有缓存目录。提前排除这些目录能省下大量无谓的遍历。3.3 元数据解析的耗时构成把元数据解析拆开看耗时主要来自三块耗时来源说明优化空间文件打开与读取打开文件句柄、读取文件头中等可减少重复打开格式解析解析容器格式、提取轨道信息较大可缓存结果缩略图生成部分场景需要生成缩略图很大可延迟或按需生成其中缩略图生成是最容易被忽视的耗时大户。有些扫描实现会在扫描时顺手把缩略图也生成了这等于把最重的活提前做了。而实际上用户可能根本不会去看那些照片的缩略图。把缩略图生成改成按需触发扫描速度能提升一大截。3.4 数据库写入的锁与事务问题数据库这侧的瓶颈主要有两个事务粒度和锁竞争。如果每条记录都单独提交事务SQLite 每次都要做 fsync磁盘 IO 次数爆炸。正确的做法是把一批记录放在一个事务里提交比如每 100 条或每 500 毫秒提交一次。这样既保证了吞吐又不会让事务太大导致内存压力。锁竞争则更隐蔽。MediaProvider 的数据库是多个进程共享的扫描时如果 App 正在大量查询双方会互相等待。缓解办法是降低扫描写入的优先级或者把扫描安排在系统空闲时进行。有些系统会监听设备是否处于充电和息屏状态只在满足条件时才启动全量扫描这就是典型的错峰思路。3.5 一个真实的性能对比场景假设某设备存储里有 5000 张图片、300 段视频全量扫描的耗时分布大致是这样的这是基于常见实践的估算实际因设备而异目录遍历约 5%图片元数据解析约 30%视频元数据解析约 45%缩略图生成约 15%数据库写入约 5%从这个分布能看出视频解析和缩略图生成加起来占了六成。所以优化重点应该放在这两块视频解析可以并行化缩略图生成可以延迟化。而目录遍历和写库虽然也要优化但收益相对有限不该投入过多精力。4. 音视频扫描的针对性优化手段4.1 增量扫描只处理变化的文件全量扫描最大的浪费在于大部分文件其实没变过却每次都要重新解析。增量扫描的核心思路是只处理那些可能是新的或变化过的文件。判断依据通常有三条文件路径是否已在数据库中、文件的修改时间是否变化、文件大小是否变化。三条里任意一条不满足已存在且未变化就认为需要重新扫描。这个判断本身很轻量不需要打开文件所以能过滤掉绝大多数文件。但这里有个坑修改时间和大小都不变内容却变了的情况是存在的。比如某些工具修改文件后刻意保留了原始时间戳。这种情况下增量扫描会漏掉更新。所以增量扫描适合作为默认策略但要提供一个强制全量的兜底入口。4.2 并行解析把多核用起来元数据解析是 CPU 和 IO 混合型任务天然适合并行。单线程逐个解析时CPU 在等 IO 的时候是闲置的。改成多线程后一个线程等 IO 时另一个线程可以继续算整体吞吐能提升不少。并行度怎么定不是越大越好。线程太多会导致磁盘 IO 争抢反而变慢。经验值是2 到 4 个线程比较合适具体要看存储介质的随机读性能。如果是 eMMC 或 UFS随机读能力较强可以适当多开如果是低速 SD 卡开多了只会互相拖累。并行还有个顺序问题解析结果写库时要注意线程安全最好让解析和写库解耦解析线程只管产出结果写库统一由一个线程或队列处理。4.3 延迟与按需缩略图不要急着生成前面提到缩略图生成很耗时优化思路就是别在扫描时生成。扫描阶段只记录文件路径和基本元数据缩略图等到真正需要显示时再生成生成后缓存起来。Android 本身就有这套机制MediaStore 里的缩略图是懒加载的。但有些定制实现为了体验流畅在扫描时就把缩略图全生成了结果扫描慢得离谱。这是典型的用错了优化方向——为了省一次点击的等待牺牲了整个扫描的速度。如果确实需要预生成缩略图也应该限制尺寸和数量比如只对最近的照片生成或者只生成小尺寸的。全量预生成大尺寸缩略图在任何设备上都是灾难。4.4 视频解析的特殊处理视频解析比图片重得多值得单独优化。几个实用手段只读文件头大部分容器格式的元数据都在文件头部不需要读整个文件。确保解析器在拿到需要的信息后就停止读取不要傻乎乎地扫到文件尾。跳过损坏文件遇到无法解析的文件设置一个超时或重试上限别让它卡住整个扫描队列。缓存解析结果同一个文件如果被多次扫描直接复用上次的解析结果前提是文件没变。区分优先级最近修改的视频优先解析老视频可以延后。用户更可能马上看新拍的视频。4.5 数据库批量写入与索引优化写库这块除了前面说的事务批量提交还有几个细节预编译 SQL 语句反复执行同样的 insert/update 时预编译能省下解析 SQL 的开销。合理设置索引索引不是越多越好每个索引都会拖慢写入。只保留查询真正用得到的索引。定期整理数据库长期使用后数据库会产生碎片定期做一次 vacuum 能改善读写性能。注意批量写入时事务不能无限大。事务太大一旦失败回滚成本极高而且会长时间持有数据库锁。建议按条数或时间双阈值控制比如每 200 条或每 500 毫秒提交一次先到先提交。5. 踩坑实录那些让扫描变慢的隐蔽问题5.1 修改时间不准导致的重复扫描前面提过增量扫描依赖修改时间但实际项目里修改时间不准是高频问题。有些设备在拷贝文件时会把修改时间设成拷贝时刻导致每次扫描都认为文件是新的。还有些文件系统的时间精度只有秒级同一秒内多次修改无法区分。排查这类问题的办法是在扫描日志里打印出判定为需要重新扫描的文件及其修改时间看看是不是有一批文件的修改时间异常地集中在某个时刻。如果是基本可以确定是时间戳问题。解决思路是引入更可靠的判断依据比如文件内容的哈希成本高慎用或者结合其他元数据。5.2 大目录遍历卡死某次遇到一个案例扫描到某个目录时直接卡住不动。排查后发现该目录下有超过十万个小文件listFiles()一次性读取把所有文件名塞进内存触发了频繁 GC最终卡死。解决办法是分批遍历不要一次性列出所有文件。用 native 的目录遍历接口逐个读取或者对超大目录做分片处理。同时给单个目录的遍历设置上限超过就跳过并记录日志避免个别异常目录拖垮整个扫描。5.3 扫描与查询的锁竞争有用户反馈扫描进行时相册 App 卡得几乎不能用。抓 trace 发现是数据库锁竞争——扫描在写库时持有写锁相册查询要读同一张表被阻塞了。这个问题的根源是读写没有分离好。SQLite 默认的锁粒度比较粗写的时候读会被挡。缓解办法有几种一是降低扫描写入频率给读操作留出窗口二是用 WAL 模式让读写可以并发三是把扫描安排在用户不活跃的时段。实际项目里通常是几种手段组合使用。5.4 扫描被中断后的数据一致性扫描过程中如果进程被杀比如内存紧张被系统回收数据库里可能留下扫了一半的状态。下次扫描时如果不做处理可能出现重复记录或数据不一致。处理思路是引入扫描会话的概念每次扫描开始前记录一个会话 ID扫描过程中写入的记录都带上这个 ID扫描正常结束后清除标记。如果发现存在未正常结束的会话下次启动时先清理这些残留记录。这样能保证数据库最终是一致的。5.5 排查链路复盘把上面这些坑的排查过程抽象一下其实有一套通用套路先确认现象是扫描慢还是扫描结果不对还是扫描时其他功能卡不同现象指向不同原因。再看日志扫描日志能告诉你卡在哪个文件、哪个阶段。然后打点在关键节点加耗时统计定位到具体环节。接着复现构造一个能稳定复现的最小场景比如固定数量的文件。最后验证改完之后用同样的场景对比耗时确认优化有效。这套流程看着简单但很多人一上来就猜原因、直接改代码结果改了半天没效果。先测量再优化这句话在扫描优化里尤其重要。6. 把扫描做稳做快的几条实战经验6.1 扫描策略要分场景设计不存在一套通吃的扫描策略。开机扫描、插卡扫描、单文件扫描场景不同策略就该不同开机扫描用户刚开机对速度不敏感但对系统流畅度敏感。适合低优先级、后台慢慢扫甚至可以延迟到开机后一段时间再启动。插卡扫描用户刚插卡期待尽快看到内容。适合较高优先级但也要控制资源占用。单文件扫描用户刚拍完照期待立刻看到。适合最高优先级但只处理一个文件成本可控。把策略和场景绑定比用一套参数硬扛所有情况要合理得多。6.2 给扫描设置资源预算扫描是后台任务不该无限制地占用资源。给扫描设置一个资源预算比如最多占用两个 CPU 核心每秒最多写库 N 次内存占用不超过 X MB超出预算就主动降速。这样能保证扫描不会把前台体验拖垮。资源预算的另一个好处是可预测。有了预算就能估算出扫描大概要多久从而决定是立即扫还是延后扫。6.3 监控与告警不能少扫描是长期运行的后台任务出问题往往不容易第一时间发现。建议加上监控记录每次扫描的耗时、处理文件数、失败文件数超过阈值就告警。这样能在问题扩大前发现苗头。监控数据还能用来做趋势分析。比如发现扫描耗时逐月上升可能是存储里的文件越来越多或者数据库碎片化严重需要针对性处理。6.4 兼容性要提前考虑不同 Android 版本、不同厂商的存储实现差异很大。分区的挂载方式、权限模型、数据库位置都可能不同。做扫描优化时一定要在多个版本和机型上验证别只在自己手头那台设备上测通了就以为万事大吉。尤其是分区存储相关的变更对扫描路径和权限影响很大。新版本上能扫的目录老版本上可能扫不了反之亦然。提前把这些差异摸清楚能省下大量后期适配的功夫。6.5 我个人的一点体会做了这么多年的媒体扫描相关优化最大的感受是扫描慢往往不是算法问题而是策略问题。很多团队一上来就想优化解析算法结果发现算法本身已经够快了慢是因为在不该扫的时候扫了、不该解析的时候解析了、不该生成的时候生成了。所以每次遇到扫描性能问题我都会先问三个问题这次扫描真的有必要吗这些文件真的需要现在解析吗这些数据真的需要现在生成吗把这三个问题想清楚往往不用改一行核心代码性能就能提升一大截。剩下的才是算法和工程层面的优化那部分虽然也有价值但优先级要排在策略之后。另外扫描相关的 bug 往往有很强的隐蔽性因为它们依赖具体的文件状态和时序。测试时一定要构造足够多样的文件组合——大文件、小文件、损坏文件、特殊格式、超长路径、深层目录把这些边界情况都覆盖到才能在上线前把问题挡在门外。
