企业官网建设流程全解析

老读者应该还有印象，我这两年写了不少关于Android存储和文件操作的文章，但一直没系统整理过这个基础到不能再基础、却又让不少人踩坑的题目——读写文件。正好最近在带两个新人，他们在同一个功能上分别用不同方式实现了文件读写，结果一个在低版本机器上崩了，一个在高版本上拿不到权限，来来回回折腾了两三天。聊完之后我发现，很多人对Android文件读写的方法、适用场景和坑点都停留在“能跑就行”的状态，这不行。

先说结论：Android里读写文件没有唯一标准答案，内部存储、外部存储、缓存目录、公共目录，每种方案都有它的适用场景和代价。怎么选，取决于你的数据是什么类型、要活多久、要不要被其他应用访问，还有你的最低支持版本是多少。这篇文章我把常见的方式整理了一遍，从正统的Java IO、到Kotlin扩展函数、再到NIO和分区存储适配，全都有可直接复用的代码示例和我们平时容易忽略的细节，建议收藏后慢慢看。

1. 整体设计思路：先把存储体系盘清楚

1.1 为什么文件读写会成为问题

很多初级开发者最初接触Android时，学到的文件操作和桌面Java没什么区别：拿到一个路径，new一个File，然后开始读写。这在Demo阶段确实没问题，但一旦进入真实项目，问题立刻冒出来。

第一层问题是你可能根本拿不到想要的路径。Android的存储体系比PC要复杂得多，它区分内部存储和外部存储，外部存储又分成应用专属目录和公共目录，公共目录在Android 10之后还要区分媒体集合和文件集合，每个版本对这些目录的访问权限要求都不一样。第二层问题是就算路径对了，权限也可能不够。Android 6.0引入了运行时权限，Android 11又推出了分区存储的强制适配，直接操作公共目录里的任意文件这条路基本被堵死了。

所以在动手写代码之前，先把存储体系摸清楚，比什么都重要。不然你写出来的代码，换一个系统版本或者换一台OEM深度定制的手机就可能出问题。

1.2 Android文件存储的全景图

为了方便理解，我把Android里能放文件的地方做了个简单分类：

注意，内部存储和外部存储是从Android系统的视角区分的。“内部存储”通常指不可拆卸、系统直接管理的存储区域，它不一定是手机主板上焊死的某个芯片，而是一个逻辑分区。“外部存储”通常对应着可以被电脑识别、可以导出数据的那个共享存储空间，过去对应SD卡，现在大多数手机对应内置的大容量分区。

我们日常写的绝大多数业务文件，其实都建议放进应用的外部私有目录。只有数据库、SharedPreferences这类系统级数据才能放进内部私有目录。很多人问内部和外部究竟哪个好，我的回答是：没有绝对的好坏，看需求。需要系统级安全保障、不想被用户通过文件管理器看到，就放内部；希望文件占用空间不计算到应用数据里（实际上还是会计算，只是语义上属于媒体存储）、方便调试，就放外部。兼容性方面，内部存储永远安全，外部私有目录在Android 11之后也基本安全，关键是要避开公共目录这个大坑。

1.3 先问自己几个问题再选方案

我习惯在开始写文件代码之前，先过一遍这几个问题：

• 这个文件是临时文件还是长期数据？临时文件放cache，长期数据放files或专属目录。
• 这个文件需要被其他应用（比如相册、文件管理器）看到吗？需要才考虑公共目录，不需要一律放私有目录。
• 这个文件有多大？超过10MB的文件，建议考虑流式读写而不是一次load进内存。
• 最低支持什么版本？如果最低版本是Android 10以下，公共目录的读写需要考虑权限适配；如果在Android 10以上，就要考虑分区存储下的MediaStore方案。

这些问题想清楚了，你的方案其实已经定了一半。剩下的就是技术选型和代码实现了。

2. 核心方法与实操要点：四类主流读写方式拆解

2.1 Java IO方式的经典用法

Java IO是Android文件读写的基本功，理解它之后，其他的封装都是在它基础上做简化。先从最原始的方式说起。

写入文件的传统写法是这样：

// 写入文件 File file = new File(context.getFilesDir(), "test.txt"); FileOutputStream fos = null; try { fos = new FileOutputStream(file); String content = "这是一段测试内容"; fos.write(content.getBytes(StandardCharsets.UTF_8)); fos.flush(); } catch (IOException e) { e.printStackTrace(); } finally { if (fos != null) { try { fos.close(); } catch (IOException e) { e.printStackTrace(); } } }

读取文件的传统写法是这样：

// 读取文件 File file = new File(context.getFilesDir(), "test.txt"); FileInputStream fis = null; ByteArrayOutputStream baos = new ByteArrayOutputStream(); try { fis = new FileInputStream(file); byte[] buffer = new byte[1024]; int len; while ((len = fis.read(buffer)) != -1) { baos.write(buffer, 0, len); } String content = baos.toString(StandardCharsets.UTF_8.name()); } catch (IOException e) { e.printStackTrace(); } finally { try { if (fis != null) fis.close(); baos.close(); } catch (IOException e) { e.printStackTrace(); } }

这段代码最大的问题是啰嗦，但恰恰是这段啰嗦的代码，把Java IO的完整流程都体现出来了：打开流、读取数据到缓冲区、写数据、关闭流。每一步都不能省。

有几个细节必须注意。第一，fos.write(content.getBytes())这一个调用看起来简单，但如果content很大，一次write把所有字节推给底层，很容易造成内存抖动。更稳妥的做法是分块写入，比如用一个4KB或8KB的缓冲区循环写。第二，文件路径用context.getFilesDir()而不是硬编码/data/data/包名/files，因为你没法保证所有厂商的设备路径都完全一致，尤其是Android 11之后，某些设备的实际路径可能有差异，硬编码路径必挂。第三，关闭流的顺序要和打开顺序相反，而且要在finally里关闭，避免异常时资源泄漏。虽然Java 7有了try-with-resources，但Android对Java 8语法支持有限，我们在项目里还是习惯手动关流，或者用Kotlin的use扩展。

提示：在Android里，context.getFilesDir()对应内部存储的files目录，context.getCacheDir()对应内部存储的cache目录。这两个是使用频率最高、最安全的目录。需要其他应用访问吗？不需要，这两个就够了。

2.2 借助Context获取目录的正确姿势

实际开发中，我们很少直接new File，而是通过Context拿到标准目录，然后在此基础上操作。常用的方法有：

// 内部存储 File filesDir = context.getFilesDir(); // /data/data/包名/files File cacheDir = context.getCacheDir(); // /data/data/包名/cache // 外部存储（应用专属目录） File externalFilesDir = context.getExternalFilesDir(null); // /storage/emulated/0/Android/data/包名/files File externalCacheDir = context.getExternalCacheDir(); // /storage/emulated/0/Android/data/包名/cache // 带子目录 File imageDir = context.getExternalFilesDir(Environment.DIRECTORY_PICTURES); File downloadDir = context.getExternalFilesDir(Environment.DIRECTORY_DOWNLOADS);

注意，getExternalFilesDir()传入的参数是子目录类型，传Environment.DIRECTORY_PICTURES会帮你建好Pictures子目录。过去有人问为什么不直接用Environment.getExternalStorageDirectory()，这个API在Android 10就已经标记废弃了，它拿到的是整个外部存储的根目录，在分区存储下访问公共根目录的行为已经发生了变化，不建议再用。

我见过不少项目把文件直接写到/sdcard/xxx/这类硬编码路径，这样做的问题有三层：一是不同厂商的路径映射并不完全一致，字符串拼接容易翻车；二是这些目录属于公共存储，Android 10以上没有权限根本写不进去；三是即便你动态申请了权限，等到Android 11强制分区存储之后，写公共根目录的代码会被系统直接忽略，到时候你再想改造，整个项目的文件模块都得重写。所以再次强调：所有文件相关的目录获取，请务必通过Context或者Environment提供的API，不要手写路径。

2.3 Kotlin扩展函数：现代写法的效率革命

如果你还在用Java那一套在Kotlin项目里写文件，我建议你看看Kotlin标准库提供的扩展函数。它们本质上还是对Java IO的封装，但API设计得优雅很多，代码量减少一半以上。

// 写入文件（Kotlin版本） val file = File(context.filesDir, "test.txt") file.writeText("这是一段测试内容", Charsets.UTF_8) // 追加内容 file.appendText("追加的内容", Charsets.UTF_8) // 读取文件 val content = file.readText(Charsets.UTF_8) // 按行读取 val lines = file.readLines(Charsets.UTF_8)

是不是简洁到没朋友？writeText、appendText、readText、readLines这四个扩展函数基本覆盖了90%的日常需求。在它们背后，是Kotlin帮你处理了流的开关，即使发生异常也会自动关闭资源。

对于大文件，Kotlin也提供了流式处理的扩展：

// 大文件逐行处理 file.bufferedReader(Charsets.UTF_8).use { reader -> reader.forEachLine { line -> // 逐行处理，不会OOM } } // 大文件写入 file.bufferedWriter(Charsets.UTF_8).use { writer -> writer.write("第一行\n") writer.write("第二行\n") }

use函数是Kotlin对Closeable的扩展，它在代码块执行完毕后自动调用close，比try-with-resources更自然。我在项目里要求所有流操作必须包一层use或类似的自动关闭机制，这是底线。

用Kotlin扩展函数写文件最大的好处，除了代码量减少，更重要的是不易出错。Java版本的try-catch-finally很容易出现漏关流或者关流顺序不对的问题，Kotlin封装后，这些风险基本归零。但要注意，readText()适合小文件，如果文件超过几十MB还这么用，内存肯定扛不住。那种场景老老实实走流式读取。

2.4 Buffered流与大文件处理场景

上一节提到的大文件处理，我单独拉出来说一下。如果你要操作的文件是几十MB甚至上GB级别的，比如下载的压缩包、视频缓存，一定要注意读写方式。

正确的流式写法：

// 大文件复制：普通流式 FileInputStream(srcFile).use { input -> FileOutputStream(destFile).use { output -> val buffer = ByteArray(8 * 1024) // 8KB缓冲区 var bytesRead: Int while (input.read(buffer).also { bytesRead = it } != -1) { output.write(buffer, 0, bytesRead) } output.flush() } }

加上缓冲流之后：

// 大文件复制：Buffered流 BufferedInputStream(FileInputStream(srcFile)).use { input -> BufferedOutputStream(FileOutputStream(destFile)).use { output -> val buffer = ByteArray(8 * 1024) var bytesRead: Int while (input.read(buffer).also { bytesRead = it } != -1) { output.write(buffer, 0, bytesRead) } output.flush() } }

BufferedInputStream的作用是减少底层系统调用次数，默认缓冲区大小是8KB，实际传输效率比裸的FileInputStream高不少。我做过一次性能测试，同一个100MB文件，普通流式复制耗时约1.8秒，加上缓冲流之后约1.2秒，性能提升约30%。对于频繁做小文件读写的场景，差别不大，但对于大文件，缓冲流几乎是必须的。

需要注意：缓冲区大小不是越大越好。8KB到64KB这个区间通常有最佳性能表现，超过128KB之后，内存占用上升但性能提升已经非常有限，甚至因为GC压力增大而变慢。我们项目里统一用8KB作为一个“不会出错”的中间值，如果你有明确的性能诉求，可以自己压测后调整。

3. 实操过程与核心环节实现：从基础到现代方案的完整落地

3.1 传统Java IO的完整落地案例

用一个具体场景来说明：把用户反馈的内容保存到日志文件。需求很简单——用户在App里填写反馈文本，我们把它存成txt文件，后续上传给后台。

先看Java的完整实现，我在代码里写了详细注释：

public class FeedbackStorage { private static final String FILE_NAME = "feedback_log.txt"; public static void saveFeedback(Context context, String feedback) { // 使用内部存储，无需权限，卸载自动清除 File file = new File(context.getFilesDir(), FILE_NAME); FileOutputStream fos = null; try { fos = new FileOutputStream(file, true); // true表示追加模式 String timestamp = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.getDefault()).format(new Date()); String line = timestamp + " | " + feedback + "\n"; fos.write(line.getBytes(StandardCharsets.UTF_8)); fos.flush(); } catch (IOException e) { Log.e("FeedbackStorage", "保存反馈失败", e); } finally { if (fos != null) { try { fos.close(); } catch (IOException e) { Log.e("FeedbackStorage", "关闭流失败", e); } } } } public static String loadFeedback(Context context) { File file = new File(context.getFilesDir(), FILE_NAME); if (!file.exists()) return ""; StringBuilder content = new StringBuilder(); FileInputStream fis = null; BufferedReader reader = null; try { fis = new FileInputStream(file); reader = new BufferedReader(new InputStreamReader(fis, StandardCharsets.UTF_8)); String line; while ((line = reader.readLine()) != null) { content.append(line).append("\n"); } } catch (IOException e) { Log.e("FeedbackStorage", "读取反馈失败", e); } finally { try { if (reader != null) reader.close(); if (fis != null) fis.close(); } catch (IOException e) { Log.e("FeedbackStorage", "关闭流失败", e); } } return content.toString(); } }

这段代码我在教学时经常会拿来讲，因为它的每个细节都有讲究。new FileOutputStream(file, true)中的第二个参数是append标志，如果你不小心漏了它，每次写入都会覆盖上一次的内容，这在记录日志、追加用户反馈、追加下载分片这些高频场景下会酿成大错。SimpleDateFormat在这里只是举个例子，真实的项目里我建议用java.time或者第三方时间库，各自项目根据minSdk决定。

3.2 Kotlin协程与IO调度：异步读写不卡UI

传统写法下，文件操作放在主线程是一大禁忌。文件IO是耗时操作，哪怕一个小文件也有可能在低端设备上造成几十毫秒甚至上百毫秒的卡顿。Android的ANR阈值是5秒，如果文件操作发生在主线程并且设备I/O性能较差，用户就会看到界面卡死甚至ANR弹窗。

在Kotlin项目里，我们建议用协程来异步处理：

class FileRepository(private val context: Context) { private val ioDispatcher = Dispatchers.IO suspend fun saveFile(content: String, fileName: String): Boolean = withContext(ioDispatcher) { runCatching { val file = File(context.filesDir, fileName) file.writeText(content, Charsets.UTF_8) true }.getOrDefault(false) } suspend fun readFile(fileName: String): String? = withContext(ioDispatcher) { runCatching { val file = File(context.filesDir, fileName) if (file.exists()) file.readText(Charsets.UTF_8) else null }.getOrNull() } }

这里用withContext(Dispatchers.IO)把文件操作切到IO线程池，再用runCatching捕获异常，调用方不用try-catch也能拿到安全结果。这种写法的好处是，调用时只要在协程作用域内直接repository.saveFile("内容", "file.txt")就行了，完全不需要关心线程切换的细节。

注意：runCatching在协程里要小心使用，如果你的代码块里有throw且有自定义异常类型，runCatching默认会把所有Throwable都捕获，这在某些业务里可能掩盖问题。更严谨的做法是捕获指定异常，或者对错误做类型区分。

3.3 图片与Bitmap：MediaStore方案在现代系统的应用

文件读写里有一种特殊场景——图片、视频、音频这类媒体文件。它们的宿主目录在公共存储（Pictures、Movies、Music等），而且从Android 10开始，访问这些目录必须走MediaStore。

在Android 10之前，你可能这样保存图片：

// 旧写法（Android 10以下可用） File imageFile = new File(Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES), "my_image.jpg"); FileOutputStream fos = new FileOutputStream(imageFile); bitmap.compress(Bitmap.CompressFormat.JPEG, 90, fos);

Android 10及以上，建议这样：

@RequiresApi(Build.VERSION_CODES.Q) fun saveImageToGallery(context: Context, bitmap: Bitmap): Uri? { val values = ContentValues().apply { put(MediaStore.Images.Media.DISPLAY_NAME, "IMG_${System.currentTimeMillis()}.jpg") put(MediaStore.Images.Media.MIME_TYPE, "image/jpeg") put(MediaStore.Images.Media.RELATIVE_PATH, "${Environment.DIRECTORY_PICTURES}/MyApp") } val resolver = context.contentResolver val uri = resolver.insert(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, values) ?: return null resolver.openOutputStream(uri)?.use { output -> bitmap.compress(Bitmap.CompressFormat.JPEG, 90, output) } return uri }

这套方案不再需要申请存储权限，也不管路径，系统会按照RELATIVE_PATH自动建目录。要注意，RELATIVE_PATH里的参数只能传一级目录，比如Pictures/MyApp，其中Pictures是枚举值，后面的MyApp是自定义子目录，这个子目录名不能乱来，最好只包含英文字母和数字。

读取图片同样走MediaStore。如果是自己插入的Uri，直接用Uri读就行；如果要查询公共目录里所有图片，需要查数据库拿到Uri再读。这一点特别重要——我们经常遇到的问题是：列表里明明有图片，为什么File方式读不到？因为分区存储下，用File方式访问公共图片目录的路径，系统会返回权限错误，必须通过MediaStore查询出的Uri去读。

3.4 流式读写与性能取舍的完整对比

下面我用表格列一下各类方式的适用场景，方便你选型时对照：

有人可能会问，FileChannel到底是什么？我简单解释一下。它是Java NIO提供的文件通道，它能利用系统底层的零拷贝能力，让文件数据在磁盘之间直接传输，不走应用内存中转。典型用法是：

fun copyFileWithChannel(src: File, dest: File) { FileInputStream(src).use { input -> FileOutputStream(dest).use { output -> input.channel.transferTo(0, src.length(), output.channel) } } }

这种写法在复制大文件时性能最好，因为它减少了一次内存拷贝和一个用户态与内核态的切换。不过它的可移植性存在一些边界情况，比如某些安卓设备上的transferTo在超过2GB的文件时可能一次传不完，需要循环调用。我们项目里一般只在明确大文件复制的场景用它，日常业务还是Buffered流为主。

4. 常见问题与排坑实录：那些运行时才知道的事

4.1 路径错误与目录权限的混淆

现象：App明明运行正常，但保存的文件就是找不到。

这个问题的原因通常是对“外部存储”的理解偏差。很多人以为getExternalFilesDir()返回的是公共目录，其实返回的是外部存储里应用专属的Android/data目录，这个目录在文件管理器里默认隐藏，只有插上电脑且开启显示隐藏文件才能看见。所以“找不到”不是文件没存上，而是你没在预期的地方找。

我在排查这个问题时常用的命令：

adb shell run-as 包名 ls -l /data/data/包名/files/ adb shell ls -l /sdcard/Android/data/包名/files/

用run-as可以直接查看内部私有目录，用第二种命令查看外部专属目录。如果文件都在，就能确定只是路径认知的问题。

另一个常见问题是getExternalFilesDir()返回了null。这种情况在设备真正没有外部存储时会出现，解决方法是做一个保底策略，比如返回null时回退到getFilesDir()。

4.2 Android 10及以上版本的文件管理权限

Android官方从10开始推行分区存储，彻底改变了公共目录文件的访问方式。我自己最开始在适配时也踩过坑，有一次升级targetSdk之后，原来用来导出报表的代码直接写不进去文件，排查到夜里才发现是分区存储的限制。

分区存储规则的核心可以概括成三句话：

• 专属区域（内部和外部私有目录）：无需权限，随意读写。
• 公共媒体文件：通过MediaStore读取、插入、更新，不需要存储权限。
• 公共非媒体文件（比如PDF、txt）：Android 10上可用requestLegacyExternalStorage临时绕过，但Android 11开始必须通过用户主动授权的方式（如系统文件选择器）或者你的应用专属目录来访问。

如果你的App确实需要管理公共目录的任意文件，Android 11提供了MANAGE_EXTERNAL_STORAGE权限，但这个权限在Google Play审核中是高风险的，通常会要求你证明核心功能确实依赖它，否则不予上架。所以能不用尽量不用。

4.3 流未关闭导致的内存泄漏与文件占用

流未关闭是文件操作最常见的隐性Bug。文件流不关闭会导致三件事：文件被占用无法删除、文件描述符耗尽（当超过1024个，系统开始报 too many open files）、底层资源泄漏。尤其在Android这种内存敏感的移动平台，这种问题往往不是立刻崩溃，而是随着App运行时间增长，各种莫名其妙的问题才慢慢浮现。

排查这个问题有一个技巧：在代码里定时把当前打开的文件描述符数量打到日志里。

val count = File("/proc/self/fd").listFiles()?.size ?: 0 Log.d("FDCheck", "当前打开的文件描述符数量: $count")

如果这个数字持续上升且没有回落，基本可以断定有泄漏。定位到具体的流，然后看它是否在异常分支里没有被关闭。

为了避免这类问题，我要求团队在项目里禁用裸的FileOutputStream使用，统一通过封装好的工具类操作。每个公开方法内部都强制使用use扩展或者try-with-resources（Java项目）。

4.4 中文文件名与编码问题

中文文件名在Android上能创建、能读写，但在某些场景会出现编码乱码问题。例如，当你的文件名来自用户输入，包含中文、空格、特殊符号时，直接new File(path) 有时候会在低版本机型上出现IllegalArgumentException。这不是Kotlin或Java的bug，而是文件系统对字符的处理和不同Rom的兼容性差异。

稳妥的做法是文件名统一规范，建议遵循这几点：

• 文件名只使用字母、数字、下划线和点。
• 存储时间戳用全数字字符串。
• 用户输入的中文名称只用于显示层，存储层统一用生成的唯一标识。

内容编码同样重要。默认的getBytes()不带参数时，会使用操作系统的默认字符集，不同版本上可能不同。这会导致一个Android 9上正常读写的文件，在Android 12上中文乱码。真要避免这个问题，所有涉及字符串和字节转换的地方，显式指定UTF-8。

content.toByteArray(Charsets.UTF_8) String(bytes, Charsets.UTF_8)

4.5 常见问题速查表

这八类问题几乎是文件操盘里遇到率最高的，碰到类似情况，先按表格对号入座，能省下大半排查时间。

5. 一个完整的小型文件管理工具类封装

讲完原理和坑，最后给一个相对完整、可以直接拿去用的工具类。它同时覆盖了Java和Kotlin的使用需求，核心API按业务场景划分，小伙伴们可以直接抄作业。

import android.content.Context import android.graphics.Bitmap import android.net.Uri import android.os.Build import android.os.Environment import android.provider.MediaStore import android.content.ContentValues import java.io.File import java.io.FileInputStream import java.io.FileOutputStream import java.io.BufferedInputStream import java.io.BufferedOutputStream import kotlinx.coroutines.Dispatchers import kotlinx.coroutines.withContext /** * 文件操作统一入口 * 内部存储：内部文件长期存储 * 缓存目录：临时文件 * 外部专属：应用大文件 * MediaStore：公共媒体文件 */ object FileHelper { enum class StorageType { INTERNAL_FILES, // 内部存储 files INTERNAL_CACHE, // 内部缓存 EXTERNAL_FILES, // 外部专属 files EXTERNAL_CACHE // 外部缓存 } fun getDirectory(context: Context, type: StorageType): File? { return when (type) { StorageType.INTERNAL_FILES -> context.filesDir StorageType.INTERNAL_CACHE -> context.cacheDir StorageType.EXTERNAL_FILES -> context.getExternalFilesDir(null) StorageType.EXTERNAL_CACHE -> context.getExternalCacheDir() } } fun exist(context: Context, type: StorageType, fileName: String): Boolean { val dir = getDirectory(context, type) ?: return false return File(dir, fileName).exists() } fun write(context: Context, type: StorageType, fileName: String, content: String): Boolean { val dir = getDirectory(context, type) ?: return false val file = File(dir, fileName) return runCatching { file.writeText(content, Charsets.UTF_8) true }.getOrDefault(false) } fun append(context: Context, type: StorageType, fileName: String, content: String): Boolean { val dir = getDirectory(context, type) ?: return false val file = File(dir, fileName) return runCatching { file.appendText(content, Charsets.UTF_8) true }.getOrDefault(false) } fun read(context: Context, type: StorageType, fileName: String): String? { val dir = getDirectory(context, type) ?: return null val file = File(dir, fileName) if (!file.exists()) return null return runCatching { file.readText(Charsets.UTF_8) }.getOrNull() } fun delete(context: Context, type: StorageType, fileName: String): Boolean { val dir = getDirectory(context, type) ?: return false val file = File(dir, fileName) return file.delete() } suspend fun copyFile( context: Context, srcType: StorageType, srcName: String, destType: StorageType, destName: String ): Boolean = withContext(Dispatchers.IO) { val srcDir = getDirectory(context, srcType) val destDir = getDirectory(context, destType) if (srcDir == null || destDir == null) return@withContext false val srcFile = File(srcDir, srcName) val destFile = File(destDir, destName) runCatching { srcFile.copyTo(destFile, overwrite = true) true }.getOrDefault(false) } /** * 保存Bitmap到公共Pictures目录（Android 10+ 推荐） */ suspend fun saveBitmapToPublic( context: Context, bitmap: Bitmap, displayName: String, subDir: String = "MyApp" ): Uri? = withContext(Dispatchers.IO) { runCatching { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { val values = ContentValues().apply { put(MediaStore.Images.Media.DISPLAY_NAME, displayName) put(MediaStore.Images.Media.MIME_TYPE, "image/jpeg") put( MediaStore.Images.Media.RELATIVE_PATH, "${Environment.DIRECTORY_PICTURES}/$subDir" ) } val collection = MediaStore.Images.Media.EXTERNAL_CONTENT_URI val uri = context.contentResolver.insert(collection, values) ?: return@runCatching null context.contentResolver.openOutputStream(uri)?.use { output -> bitmap.compress(Bitmap.CompressFormat.JPEG, 90, output) } uri } else { // 低版本走传统方式 val file = File( Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES), "$subDir/$displayName" ) file.parentFile?.mkdirs() FileOutputStream(file).use { output -> bitmap.compress(Bitmap.CompressFormat.JPEG, 90, output) } Uri.fromFile(file) } }.getOrNull() } /** * 获取当前打开的文件描述符数量，用于排查泄漏 */ fun currentFdCount(): Int { return File("/proc/self/fd").listFiles()?.size ?: 0 } }

这个封装类里我特意加入了保存Bitmap到公共目录的方法，并且区分了Android 10前后的处理逻辑。因为这部分特别容易踩坑，很多项目适配分区存储时都在图片保存上出了问题。封装之后，业务方只需要一行代码调用，不需要关心版本差异。

重要提醒：工具类只是降低出错概率，不能替代对原理的理解。如果你连这个方法底层做了什么都不知道，当线上出现异常时，你依然不知道从哪里排查。我一直主张“先懂原理，再用封装”。

6. 性能测试与选型建议的实战补充

6.1 真实环境下的性能表现

我拿一台中端测试机跑了几组数据，同一个5MB文件，用不同方式写入和读取，结果供大家参考：

注意，这组数据只能作为相对参考，不同机型的磁盘性能差异远大于不同写法的差异。但在同一台机器上对比，结论还是很明显：FileChannel最快，Buffered次之，一次性读写最慢但代码最简单。

如果文件小于1MB，这些性能差异可感知的程度很低，优先选可读性好的Kotlin扩展函数；如果文件大于10MB，直接上FileChannel或Buffered流；如果介于两者之间，看团队习惯，怎么顺手怎么来。

6.2 团队项目中的统一规范

这些规范是我在团队里落地的版本，写出来给各位参考：

• 所有文件路径获取，必须通过Context或Environment提供的API，禁止硬编码。
• 流操作必须使用自动关闭机制，Java用try-with-resources，Kotlin用use。
• 字符串与字节的转换，强制指定UTF-8。
• 文件名只允许字母、数字、下划线和点，禁止中文和空格。
• 大文件操作必须切到IO线程，禁止在主线程执行任何文件操作。
• 日志类文件必须设置大小上限，建议单个文件不超过5MB，最多保留3个轮转文件。
• 文件读写失败时，必须记录失败原因和关键路径信息，方便线上排查。

这些规范看起来很简单，但能坚持下来，文件相关的线上Bug会减少八成以上。很多问题的根源不是你不会写，而是每次写的方式都不一样，有的地方用File，有的地方用MediaStore，有的地方又自己拼路径，长期下来必然出乱子。

6.3 关于FileProvider的一点补充

还有一个和文件读写强相关的组件需要提一下——FileProvider。如果你的App需要把内部文件分享出去，比如把应用生成的PDF通过微信发送，在Android 7.0及以上就不能用Uri.fromFile()了，必须使用FileProvider。

用法不复杂：在Manifest里注册FileProvider，在xml里指定共享目录，然后代码里通过FileProvider.getUriForFile()获取Uri。但很多人会忽略一个问题——FileProvider能共享的目录必须提前在xml里声明，如果文件存放在没有声明的目录，会直接抛异常。所以你的文件管理工具类里，应该把需要共享的目录和FileProvider的xml配置保持同步。

<paths> <files-path path="share/" name="shared_files" /> <external-files-path path="export/" name="exported_files" /> <cache-path path="temp/" name="temp_files" /> </paths>

这里files-path对应内部files目录下的share子目录，external-files-path对应外部专属files下的export子目录。路径配置和实际目录不一致，这是FileProvider最常见的坑。

7. 写在后面的一些个人体会

我刚开始做Android的时候，文件操作是最好写也最容易写崩的模块，因为当年的网络资料五花八门，有人说放这里，有人说放那里，最后写出来的代码自己都看不懂为什么能跑。后来慢慢理解了那棵存储体系树之后，所有的困惑都解开了。

读文件也好、写文件也好，本质上都是四个问题：文件放哪里、用什么方式访问、要不要权限、怎么处理异常。把这四个问题想清楚，代码怎么写都八九不离十。能用系统API解决的问题，别自己去手写底层逻辑；能用标准目录解决的问题，别去碰硬编码路径；能用私有目录解决的问题，别去申请公共目录权限。

项目里如果已经有了历史包袱——比如到处散落的文件读写代码，我的建议是不要急着一次性重写，先盘清楚线上都在哪些目录写了文件、都有多大、是否涉及公共目录，然后按刚才说的那套规范分批改造，每改一批就做一次回归。这样既降低风险，又能逐步把代码收敛到统一入口。

最后再分享一个小技巧：写文件相关的代码时，在关键路径打上结构化日志，包括文件路径、大小、耗时和结果。这样等线上出了诡异的问题，你能通过日志快速缩小范围，而不是靠猜。毕竟文件这个东西，磁盘满了要崩，权限变了要崩，别人把目录删了还要崩，你不能完全依赖“代码看起来没问题”就发布。

这篇文章我把知识体系、实操代码和排坑经验都串了一遍，希望能帮你少走弯路。如果你在实际操作中碰到表格里没有的问题，或者对我的选型建议有不同看法，随时在评论区聊聊，咱们共同完善这个主题。