小程序•小故事(19)——文件系统能力
原创： link 微信开发者 昨天文件系统能力
文件系统能力可便于用户在客户端保存文件资源，并在下次启动客户端之后可以使用已保存的文件。
只要用户不主动删除小程序或小游戏，并保持一定的使用频率，文件都可以一直被保留。
合理的使用文件系统能力来缓存资源文件，可以给开发者更好的使用体验。
今天，我们来分享文件系统能力的小故事。
1
文件系统的演进历史
小程序在最早发布的版本中就已提供了最基础的文件存储和删除接口：wx.saveFile、wx.removeSavedFile ;
对于绝大部分的小程序来说，这两个接口已经能够满足开发者的需求。但对于小游戏来说，需要更完整的能力来做支撑。
因此，发布小游戏的时候我们便提供了一套更完整的文件管理系统： FileSystemManager，其中主要包含了目录管理、文件内容读写等能力。
2
文件系统的设计背景
文件系统能力是应小游戏开发需求的迭代而逐步增强的。在小程序的场景下，很多时候只是需要把一个图片或视频资源缓存起来便可继续使用，文件内容与文件存储的目录结构都不是开发者所关心的。
但是在小游戏场景下情况则不同——
一方面，小游戏除了有图片和视频文件、还有游戏引擎生成的配置文件，游戏需要能够去读取并理解配置文件的具体内容;
另一方面，游戏使用的资源文件会比普通小程序更多，若没有内容目录管理的功能，维护成本会变高。
除此之外，由于小游戏代码包大小限制只有4MB (加上分包最多8MB)，对于一些偏重的游戏，资源甚至容易超100MB。
因此在此大背景下，我们给文件系统主要增加了目录管理、文件内容读写等两项接口——
目录管理的需求场景是在使用游戏引擎时需要按目录来管理资源文件，文件内容读写的需求场景是在使用游戏引擎时需要读取配置文件;同时，我们对小游戏类目的本地存储容量的规范限制扩容到50MB。
开发者可能会疑惑，为什么在小程序的文件系统中会有一些功能相接近的接口?例如，想缓存一个文件，可以用 saveFile 或 copyFile ;再比如 removeSavedFile 和 unlink 都可以用来删除一个文件。
上述情况的原因是我们在早期便提供了基础的文件存储接口 saveFile 和 removeFile ，但不提供自定义目录相关的能力，开发者调用 saveFile 之后只能得到微信返回到的一个随机文件名。
小游戏应运而生的同时也增强了对文件系统能力扩展的需求，为了保证向后兼容，我们保留了这批基础接口，并在这个基础上增加了目录管理接口以及对应的文件操作接口。因此，便出现了上述一些相似接口的情况。
3
文件系统的优势—存储隔离
有不少开发者询问过关于文件存储的问题，他们担心文件内容被其他小程序读取到，也担心多个登录用户之间的文件内容会互相影响。为了保证用户的隐私安全，也为了保证小程序的数据安全，本地文件存储的一个重要规则便是保证隔离。
文件被存储到本地后，会以小程序账号和用户账号两个不同的维度来区分和隔离。即：同个微信用户使用不同小程序之间的文件存储会互相隔离;不同微信用户(在同一台手机中)使用同个小程序时，不同用户间的文件存储也会互相隔离。
4
适当的存储容量
考虑到存储的问题，我们规范了小游戏文件存储的容量。普通小程序是10MB，小游戏则是50MB，当文件存储超出限制时，写入的文件会失败。
功能上线以后，我们曾收到过若干宝贵意见与反馈，希望能提高容量限制。但在经过反复论证与评估后，我们认为如果将文件存储的容量再往上提，就会有用户新增需要管理或清理手机存储空间的需求，小程序和小游戏将会变得不再“小”了。对于资源文件超过上述标准限制的小程序与小游戏，应该合理地管理本地文件，及时清理不常用的文件，这样在大多数情况下，手机存储空间便能保证顺畅。
标签：小程序故事
