第2章应用沙箱机制

应用沙箱机制：应用隔离原理、沙箱目录结构、文件访问限制

大家好，我是老张。今天我们来聊聊鸿蒙系统里一个非常核心的机制——应用沙箱。说实话，我刚开始接触鸿蒙开发时，也被这套沙箱机制绕晕过。但搞懂之后你会发现，它其实很巧妙，也很必要。

你想想看，手机里装了那么多应用，有银行的、有社交的、有游戏的。如果每个应用都能随便读写其他应用的数据，那不乱套了？

应用沙箱，说白了就是给每个应用建一个独立的“小房间”。应用在自己的房间里想怎么折腾都行，但出了这个房间，就得守规矩。我在项目中遇到过好几次，刚转鸿蒙的同事问：“为什么我存的文件找不到了？”——嗯，大概率是没搞懂沙箱目录。

核心原则：每个应用只能访问自己的沙箱目录和系统开放的公共区域。应用之间默认是隔离的，不能互相访问数据。

鸿蒙的隔离机制，其实是在操作系统层面做了三件事：

UID隔离：每个应用安装时，系统会分配一个唯一的用户ID（UID）。文件系统里，每个文件的权限都和这个UID绑定。应用A的进程，根本打不开UID为应用B的文件。
进程空间隔离：每个应用运行在自己的进程里，有自己的虚拟地址空间。A应用崩溃了，不会影响到B应用。这个和Linux的进程隔离是一个道理。
安全策略管控：就算UID对了、进程对了，系统还会检查你有没有对应的权限。比如你要读相册，得先申请“读取媒体文件”权限。

我记得有一次排查问题，发现一个应用老是崩溃。查了半天，原来是它试图去读另一个应用的数据库文件。系统直接返回了“权限拒绝”，代码没处理好就崩了。这就是典型的隔离机制在起作用。

每个应用安装后，系统会为它创建一套标准的目录结构。我个人习惯把这个结构画成一张图，方便理解。

这张图展示的是应用沙箱的典型目录结构。每个应用安装后，系统会在 /data/app/ 下创建一个以应用包名命名的文件夹。这里面主要分三个区域：

小提示：我个人习惯把重要的用户配置放在 files/ 下，把下载的图片缩略图放在 cache/ 下。这样系统清理缓存时，不会误删用户的重要数据。

搞清楚了目录结构，接下来就是文件访问的限制规则。这部分我踩过不少坑，跟大家分享一下。

应用在自己的沙箱目录里，拥有完全的读写权限。你可以随意创建文件、删除文件、修改文件。这个没什么好说的，自己的地盘自己做主。

默认情况下，应用A不能访问应用B的沙箱目录。如果你非要这么做，得走系统提供的文件共享机制，比如 FileProvider 或者 Want 传参。我曾经试过直接拼接路径去读另一个应用的文件，结果返回的是 Permission denied。嗯，这个坑我替你们踩过了。

系统提供了一些公共目录，比如 Download/、Documents/、Pictures/ 等。应用要访问这些目录，需要申请对应的权限：

注意：从鸿蒙3.0开始，系统对公共目录的访问管控越来越严。以前申请一个 READ_USER_STORAGE 就能读所有文件，现在得按类型申请。比如你要读图片，就申请 READ_MEDIA，系统会弹窗让用户选择具体哪些图片给你访问。这个变化很大，老项目迁移时一定要注意。

有些目录是应用绝对不能碰的，比如 /system/、/vendor/、其他应用的 /data/app/ 目录。这些是系统的红线，碰了就崩。

说了这么多理论，来点实际的。我在项目里总结了几条经验：

获取沙箱路径要用API：不要自己拼接路径。用 Context.getFilesDir() 获取 files/ 路径，用 Context.getCacheDir() 获取 cache/ 路径。系统版本升级时，路径格式可能会变，用API最保险。
缓存文件要设过期策略：我见过一个应用，缓存目录里堆了几百兆的临时文件，用户反馈手机空间越来越小。后来加了定期清理逻辑，问题就解决了。
数据库文件要加锁：多线程写数据库时，不加锁容易出问题。鸿蒙的 RelationalStore 默认是线程安全的，但如果你直接用 SQLiteDatabase，就得自己处理并发。
文件读写要加异常处理：沙箱机制下，文件操作可能因为权限不足、磁盘空间不足等原因失败。代码里一定要捕获 IOException 和 SecurityException。

核心总结：应用沙箱是鸿蒙安全体系的基石。它通过UID隔离、进程隔离、权限管控三层机制，确保每个应用的数据安全。开发时记住一句话：自己的数据放沙箱，共享数据走权限，系统目录别乱碰。

好了，关于应用沙箱机制就聊到这里。搞懂了这些，你在做文件读写、数据存储时就能少踩很多坑。下一节我们聊聊权限申请的那些事儿，到时候见。