Android端文件扫描的“边界感”—— 为什么我们要主动避开某些目录？
在构建 SmartPDF 的全盘扫描引擎时，开发者往往面临一个诱惑：既然有了权限，为什么不把手机翻个底朝天？然而，深度实践证明：全量扫描（Full Scan）不等于全路径扫描（All-Path Scan）。
一、 核心痛点：扫描中的“噪音”与“性能陷阱”
如果不对扫描路径进行预过滤，你的 App 将面临以下三个致命问题：
-
用户体验噪音（UX Noise）：
现代 App 经常在私有目录存储临时的 PDF 格式文件（如广告缓存、操作手册、电子票据快照）。-
后果：用户打开 PDF 列表时，会看到数百个无意义的
cache_001.pdf或temp_v2.pdf。这会稀释用户真正关心的文档（如论文、合资协议），让 App 显得极度不专业。
-
后果：用户打开 PDF 列表时，会看到数百个无意义的
-
性能的“指数级”恶化：
/Android/data/目录下可能存在成千上万个小文件。- IO 瓶颈：磁盘寻道是昂贵的。扫描 1,000 个分散在不同子目录的缓存文件，其耗时远超扫描一个包含 1,000 个 PDF 的下载文件夹。
- 无效做功：在系统缓存区搜寻到“用户主动存储文档”的概率不足 0.1%，却占用了 90% 的扫描耗时。
权限与安全边界：
在 Android 10+ 的分区存储（Scoped Storage）机制下，即使拥有全盘访问权，强行扫描其他 App 的私有目录也会频繁触发Access Denied异常，甚至触发系统的安全策略警告。
二、 扫描路径的“红绿灯”策略
在 PdfScanner 的递归算法中，我们需要建立一套路径白黑名单机制。
1. 绿灯区：高价值路径（优先挖掘）
这些是用户主动交互的区域，应当深度递归：
-
/Download：浏览器下载的文档中心。 -
/Documents：用户手动存放资料的区域。 -
/WeChat、/QQ、/DingTalk的文件接收路径：中国移动办公环境的核心数据源。
2. 红灯区：严格屏蔽路径（断然跳过）
在 while 队列循环中，遇到以下特征直接 continue：
| 目录特征 | 理由 |
|---|---|
Android/ |
包含所有 App 的 data 和 obb 私有数据，噪音最大且有权限风险。 |
.*/ (隐藏目录) |
主要是系统索引（如 .thumbnails）或 App 配置文件。 |
cache/, temp/
|
明确定义的临时交换区，文件不具长期保存价值。 |
三、 代码实现建议：带“过滤器”的递归扫描
在你的 scanFullStorage 流式引擎中，应当嵌入如下逻辑：
/**
* 判断是否应当跳过该目录
* 逻辑：排除隐藏目录、系统敏感目录、以及已知的缓存/临时文件夹
*/
private fun shouldSkipDirectory(file: File): Boolean {
// 1. 基础安全校验：如果不是目录或不可读，直接跳过
if (!file.isDirectory || !file.canRead()) return true
val name = file.name
// 2. 过滤隐藏目录 (以 . 开头，如 .thumbnails, .nomedia)
if (name.startsWith(".")) return true
// 3. 过滤系统级和应用私有数据目录 (噪音最大区)
// 这里的匹配忽略大小写，确保稳定性
val blackList = sSetOf("android", "data", "obb", "cache", "temp", "tmp", "libs", "debug")
if (blackList.contains(name.lowercase())) return true
return false
}
四、 性能分析
"这种判断耗时吗？”，这是一个深入的性能问题。对于 4,000 个文件甚至更多（考虑到文件夹数量可能过万）的深度扫描场景，shouldSkipDirectory 的耗时确实不可忽视，但它的存在本质上是为了“以小博大”，节省成千上万倍的磁盘 IO 时间。
我们可以从 CPU 开销和磁盘开销两个维度来拆解：
1. shouldSkipDirectory 的内部耗时拆解
这个方法里的操作，耗时从高到低排列如下：
-
file.canRead()(最高)：
这是一个系统调用 (System Call)。它需要操作系统去检查文件系统的权限表。虽然单次很快，但在几万个文件夹上循环时，它是这个方法里最重的逻辑。 -
file.isDirectory(次之)：
同样是系统调用，涉及读取文件的元数据（Metadata）。 -
字符串操作 (
name.startsWith,lowercase,set.contains) (最低)：
这是纯内存操作。只要你的黑名单用的是HashSet（即setOf），匹配速度是，在现代 CPU 上几乎可以忽略不计。
2. 为什么“耗时”的方法反而能“提速”？
这就是扫描算法中的“剪枝效应 (Pruning)”。
-
如果不执行这个方法：
你的引擎会进入Android/data/目录。这里可能有 10,000+ 个小文件分布在 500+ 个子目录下。-
代价：你需要执行 500 次
listFiles()（极其缓慢的磁盘 IO）和 10,000 次后缀名检查。
-
代价：你需要执行 500 次
-
如果执行这个方法：
你在进入Android/目录前花了几微秒做判断，决定continue。- 收益：你瞬间省掉了后面 10,500 次磁盘访问。
结论：shouldSkipDirectory 就像是导航里的“避开拥堵”逻辑。虽然计算路线多花了一点 CPU，但它让你免于陷入交通瘫痪。
3. 性能优化：如何让它快到极致？
为了处理 4,000+ PDF 这种大场景，我们可以对这个方法进行“工业级优化”：
A. 调整判断顺序（先内存，后系统）
原则： 先做耗时极低的内存判断，最后才做昂贵的系统调用。
private fun shouldSkipDirectory(file: File): Boolean {
// 1. 最快：内存字符串匹配 (O(1))
val name = file.name
if (name.startsWith(".")) return true
if (BLACK_LIST.contains(name.lowercase())) return true
// 2. 较慢：访问元数据 (System Call)
// 注意：在 scanStorage 循环里，currentDir 已经是文件夹了，
// 所以 isDirectory 其实可以省略，除非你担心路径发生了动态变化。
if (!file.canRead()) return true
return false
}
B. 静态化黑名单
千万不要在方法内部声明 setOf(...)，否则每次循环都会创建一个新的对象。
// 放在类成员位置，只创建一次
private val BLACK_LIST = setOf("android", "data", "obb", "cache", "temp", "tmp")
C. 利用 yield()
既然 shouldSkipDirectory 在处理海量目录时会占用 CPU，在调用它的循环里保留 yield() 是非常英明的。它能保证即使在扫描极深的文件夹树时，主线程的 UI 渲染也能“插队”执行。
4. 数据量级的直观感受
假设你的手机里有 5,000 个文件夹：
-
内存判断 (
name)：5,000 次大约耗时 < 1ms。 -
系统调用 (
canRead)：5,000 次大约耗时 10-50ms。 - 被省掉的垃圾目录扫描：可能节省 2,000-5,000ms。
总结
shouldSkipDirectory 本身会有微小的 CPU 负载，但它通过牺牲极小的 CPU 时间，换取了海量的磁盘 IO 节约。
对于 SmartPDF 扫描引擎，这个方法不是性能负担，而是性能保镖。如果没有它，扫描 4,000 个文件的过程可能会从“几秒钟”变成“几十秒钟”，且伴随严重的电量消耗。
