基础能力

1. 存储

每个小程序都可以有自己的本地缓存，可以通过 ft.setStorage、ft.getStorage、ft.clearStorage，ft.removeStorage 对本地缓存进行读写和清理。

2. 文件系统

文件系统是小程序提供的一套以小程序和用户维度隔离的存储以及一套相应的管理接口。通过 ft.getFileSystemManager() 可以获取到全局唯一的文件系统管理器，所有文件系统的管理操作通过 FileSystemManager 来调用。

var fs = ft.getFileSystemManager()

文件主要分为两大类：

• 代码包文件：代码包文件指的是在项目目录中添加的文件。
• 本地文件：通过调用接口本地产生，或通过网络下载下来，存储到本地的文件。 其中本地文件又分为三种：

代码包文件

由于代码包文件大小限制，代码包文件适用于放置首次加载时需要的文件，对于内容较大或需要动态替换的文件，不推荐用添加到代码包中，推荐在小游戏启动之后再用下载接口下载到本地。

访问代码包文件

代码包文件的访问方式是从项目根目录开始写文件路径，不支持相对路径的写法。如：/a/b/c、a/b/c 都是合法的，./a/b/c ../a/b/c 则不合法。

修改代码包文件

代码包内的文件无法在运行后动态修改或删除，修改代码包文件需要重新发布版本。

本地文件

本地文件指的是小程序被用户添加到手机后，会有一块独立的文件存储区域，

本地文件的文件路径均为以下格式：

{{协议名}}://文件路径

本地临时文件

本地临时文件只能通过调用特定接口产生，不能直接写入内容。本地临时文件产生后，仅在当前生命周期内保证有效，重启之后不一定可用。如果需要保证在下次启动时无需下载，可通过 FileSystemManager.saveFile() 或 FileSystemManager.copyFile() 接口把本地临时文件转换成本地缓存文件或本地用户文件。

临时文件的清理策略为：小程序退出后系统会检查该小程序的临时文件占用，若不超过2GB则不进行清理，超过上限则以文件为维度按照最近使用时间从远到近进行清理。同时也会检查所有小程序的临时文件占用，若超过6GB则以小程序为维度进行清理。

因此，开发者在下载临时文件时，可先通过FileSystemManager.access()检查该文件是否存在，减少重复文件下载，提升用户体验。

示例

wx.chooseImage({
  success: function (res) {
    var tempFilePaths = res.tempFilePaths // tempFilePaths 的每一项是一个本地临时文件路径
  }
})

本地缓存文件

本地缓存文件只能通过调用特定接口产生，不能直接写入内容。本地缓存文件产生后，重启之后仍可用。本地缓存文件只能通过 FileSystemManager.saveFile() 接口将本地临时文件保存获得。

示例

fs.saveFile({
  tempFilePath: '', // 传入一个本地临时文件路径
  success(res) {
    console.log(res.savedFilePath) // res.savedFilePath 为一个本地缓存文件路径
  }
})

注意：本地缓存文件是最初的设计，1.7.0 版本开始，提供了功能更完整的本地用户文件，可以完全覆盖本地缓存文件的功能，如果不需要兼容低于 1.7.0 版本，可以不使用本地缓存文件。

本地用户文件

小程序提供了一个用户文件目录给开发者，开发者对这个目录有完全自由的读写权限。通过 ft.env.USER_DATA_PATH 可以获取到这个目录的路径。

示例

// 在本地用户文件目录下创建一个文件 hello.txt，写入内容 "hello, world"
const fs = ft.getFileSystemManager()
fs.writeFileSync(`${ft.env.USER_DATA_PATH}/hello.txt`, 'hello, world', 'utf8')

读写权限

接口、组件	读	写
代码包文件	有	无
本地临时文件	有	无
本地缓存文件	有	无
本地用户文件	有	有

清理策略

• 本地临时文件只保证在小程序当前生命周期内，一旦小程序被关闭就可能被清理，即下次冷启动不保证可用。
• 本地缓存文件和本地用户文件的清理时机跟代码包一样，只有在代码包被清理的时会被清理。

3. 分包

某些情况下，开发者需要将小程序划分成不同的子包，在构建时打包成不同的分包，用户在使用时按需进行加载。

在构建小程序分包项目时，构建会输出一个或多个分包。每个使用分包小程序必定含有一个主包。所谓的主包，即放置默认启动页面/TabBar 页面，以及一些所有分包都需用到公共资源/JS 脚本；而分包则是根据开发者的配置进行划分。

在小程序启动时，默认会下载主包并启动主包内页面，当用户进入分包内某个页面时，客户端会把对应分包下载下来，下载完成后再进行展示

4. 画布

所有在canvas中的画图必须用 JavaScript 完成。

<canvas canvas-id="myCanvas" style="border: 1px solid;"/>

const ctx = ft.createCanvasContext('myCanvas')
ctx.setFillStyle('red')
ctx.fillRect(10, 10, 150, 75)
ctx.draw()

创建一个 Canvas 绘图上下文

首先，我们需要创建一个 Canvas 绘图上下文 CanvasContext。
CanvasContext 是小程序内建的一个对象，有一些绘图的方法：

const ctx = ft.createCanvasContext('myCanvas')

使用 Canvas 绘图上下文进行绘图描述

接着，我们来描述要在 Canvas 中绘制什么内容。
设置绘图上下文的填充色为红色：

ctx.setFillStyle('red')

用 fillRect(x, y, width, height) 方法画一个矩形，填充为刚刚设置的红色：

ctx.fillRect(10, 10, 150, 75)

画图

告诉 canvas 组件你要将刚刚的描述绘制上去：

ctx.draw()

5. 自定义 tabBar

自定义 tabBar 可以让开发者更加灵活地设置 tabBar 样式，以满足更多个性化的场景。

在自定义 tabBar 模式下

• 为了保证低版本兼容以及区分哪些页面是 tab 页，tabBar 的相关配置项需完整声明，但这些字段不会作用于自定义 tabBar 的渲染。
• 此时需要开发者提供一个自定义组件来渲染 tabBar，所有 tabBar 的样式都由该自定义组件渲染。推荐用 fixed 在底部的 cover-view + cover-image 组件渲染样式，以保证 tabBar 层级相对较高。
• 与 tabBar 样式相关的接口，如 wx.setTabBarItem 等将失效。
• 每个 tab 页下的自定义 tabBar 组件实例是不同的，可通过自定义组件下的 getTabBar 接口，获取当前页面的自定义 tabBar 组件实例。 注意：如需实现 tab 选中态，要在当前页面下，通过 getTabBar 接口获取组件实例，并调用 setData 更新选中态。可参考底部的代码示例。

配置信息

• 在 app.json 中的 tabBar 项指定 custom 字段，同时其余 tabBar 相关配置也补充完整。
• 所有 tab 页的 json 里需声明 usingComponents 项，也可以在 app.json 全局开启。 示例：

{
  "tabBar": {
    "custom": true,
    "color": "#000000",
    "selectedColor": "#000000",
    "backgroundColor": "#000000",
    "list": [{
      "pagePath": "page/component/index",
      "text": "组件"
    }, {
      "pagePath": "page/API/index",
      "text": "接口"
    }]
  },
  "usingComponents": {}
}

添加 tabBar 代码文件

在代码根目录下添加入口文件:

custom-tab-bar/index.js
custom-tab-bar/index.json
custom-tab-bar/index.fxml
custom-tab-bar/index.ftss

编写 tabBar 代码

用自定义组件的方式编写即可，该自定义组件完全接管 tabBar 的渲染。另外，自定义组件新增 getTabBar 接口，可获取当前页面下的自定义 tabBar 组件实例。