The file system is a set of storage isolated by the Mini App and the user dimension and a set of corresponding management interfaces provided by the Mini App.

The globally unique file system manager can be obtained via 'ft.getFileSystemManager()', and all file system management operations are called via 'FileSystemManager'.

Documents are mainly divided into two main categories:

• Code package files: Code package files are files that are added to the project directory.
• Local files: Files that are generated locally through the call interface, or downloaded over the network and stored locally. There are three types of local files:

1. Code package file

Due to the code package file size limitation, the code package file is suitable for placing the files needed for the first load, for files with large content or need to be dynamically replaced, it is not recommended to add to the code package, it is recommended to use the download interface to download to the local after the mini game starts.

1.1 Access the code package file

Code package files are accessed by writing file paths starting from the project root directory and do not support writing relative paths. For example: '/a/b/c', 'a/b/c' are all legal, './a/b/c' '.. /a/b/c' is illegal.

1.2 Modify the code package file

Files within a code package cannot be dynamically modified or deleted after running, and modifying code package files requires a republished version.

2. Local files

Local files refer to the fact that after the Mini App is added to the phone by the user, there will be a separate file storage area.

The file paths for local files are in the following format:

2.1 Local temporary files

Local temporary files can only be generated by calling specific interfaces and cannot be written directly. After a local temporary file is generated, it is only valid for the current lifetime, and may not be available after a restart. If you need to ensure that you do not need to download it the next time you start, you can convert local temporary files to local cache files or local user files through the 'FileSystemManager.saveFile()'or 'FileSystemManager.copyFile()' interface.

The cleaning strategy for temporary files is: after the Mini App exits, the system will check the temporary file occupancy of the Mini App, if it does not exceed 2GB, it will not be cleaned, and if it exceeds the upper limit, the file will be cleaned according to the recent use time from far to near. At the same time, it will also check the temporary file occupation of all Mini Apps, and if it exceeds 6GB, it will be cleaned up in the dimension of the Mini App.

Therefore, when downloading a temporary file, developers can first check whether the file exists through 'FileSystemManager.access()', which reduces duplicate file downloads and improves the user experience.

Example

2.2 Local cache files

Local cache files can only be generated by calling specific interfaces and cannot be written directly. After the local cache file is generated, it is still available after the restart. Local cache files can only be obtained by saving local temporary files through the 'FileSystemManager.saveFile()' interface.

Example

note

The local cache file is originally designed, starting with version 1.7.0, providing a more complete local user file that can completely overwrite the function of the local cache file, and if you do not need to be compatible with versions earlier than 1.7.0, you can not use the local cache file.

2.3 Local user files

The Mini App provides a user file directory to the developer, and the developer has completely free read and write permissions to this directory. The path to this directory can be obtained via 'ft.env.USER_DATA_PATH'.

Example

2.4 Read and write permissions

Interfaces, Components,	Read	Write
Code package file	Yes	None
Local temporary file	Yes	None
The local cache file	Yes	None
The local user file	Yes	Yes

2.5 Cleanup Policy

• Local temporary files are only guaranteed to be within the current life cycle of the Mini App, and may be cleaned up once the Mini App is closed, that is, the next cold boot is not guaranteed to be available.
• Local cache files and local user files are cleaned up at the same time as code packages, and are only cleaned up when code packages are cleaned.