鸿蒙Next开发 获取APP缓存大小和清除缓存

1. 鸿蒙Next开发 获取APP缓存大小和清除缓存

1.1. 介绍

1.1.1. 文件系统分类

  在最新的Core File Kit套件中,按文件所有者的不同。分为如下三类:
  (1)应用文件:文件所有者为应用,包括应用安装文件、应用资源文件、应用缓存文件等。
  (2)用户文件:文件所有者为登录到该终端设备的用户,包括用户私有的图片、视频、音频、文档等。
  (3)系统文件:与应用和用户无关的其它文件,包括公共库、设备文件、系统资源文件等。这类文件普通开发者不需要关注。
在这里插入图片描述

1.1.2. 访问范围和方式

  我们的应用缓存目录,实质是系统在内部存储空间上映射出一个专属应用沙箱目录其中的一部分,它是应用文件目录与一部分系统文件(应用运行必需的少量系统文件)所在的目录组成的集合。
  (1)应用可以在应用沙箱目录下保存和处理自己的应用文件;
  (2)系统文件及其目录对于应用是只读的;
  (3)应用若需访问用户文件,则需要通过特定API同时经过用户的相应授权才能进行(即读写权限申请)。
  下图展示了在鸿蒙上,应用可访问的文件范围和方式:
在这里插入图片描述

1.1.2. 应用文件目录与路径

在这里插入图片描述
如上图所示,这是应用文件的目录结构图。
  一级目录data/:代表应用文件目录。
  二级目录storage/:代表本应用持久化文件目录。
  三级目录el1/、el2/:代表不同文件加密类型。
    el1,设备级加密区:设备开机后即可访问的数据区。
    el2,用户级加密区:设备开机后,需要至少一次解锁对应用户的锁屏界面(密码、指纹、人脸等方式或无密码状态)后,才能够访问的加密数据区。(应用如无特殊需要,应将数据存放在el2加密目录下,以尽可能保证数据安全。)
  四级、五级目录:
  ApplicationContext:可以获取distributedfiles目录或者base下的files、cache、preferences、temp等目录的应用文件路径,应用全局信息可以存放在这些目录下。
  UIAbilityContext、AbilityStageContext、ExtensionContext:HAP级别应用文件路径(上图中的haps//下的目录)。HAP信息可以存放在这些目录下,存放在此目录的文件会跟随HAP的卸载而删除,不会影响App级别目录下的文件。

1.2. 获取APP缓存大小

1.2.1. 缓存目录介绍

  目录名:cache
  Context属性名称:cacheDir
  类型:应用缓存文件路径
  说明:应用在本设备内部存储上,用于缓存下载的文件或可重新生成的缓存文件的路径,应用cache目录大小超过配额或者系统空间达到一定条件,自动触发清理该目录下文件;用户通过系统空间管理类应用也可能触发清理该目录。应用需判断文件是否仍存在,决策是否需重新缓存该文件。 可以用于保存应用的缓存数据,主要包括离线数据、图片缓存、数据库备份以及临时文件等。此路径下存储的数据可能会被系统自动清理,因此不要存储重要数据。

1.2.2. 缓存目录路径

/data/storage/el1/base/cache
/data/storage/el1/base/haps/entry/cache
/data/storage/el2/base/cache
/data/storage/el2/base/haps/entry/cache

1.2.3. 获取缓存目录

  el1分区获取:
  (1)切换到el1加密分区

context.getApplicationContext().area = contextConstant.AreaMode.EL1;
context.area = contextConstant.AreaMode.EL1;
context.getApplicationContext().cacheDir
context.cacheDir
//结果:
/data/storage/el1/base/cache
/data/storage/el1/base/haps/app/cache

  (2)切换到el2加密分区

context.getApplicationContext().area = contextConstant.AreaMode.EL2;
context.area = contextConstant.AreaMode.EL2;
context.getApplicationContext().cacheDir
context.cacheDir
//结果:
/data/storage/el2/base/cache
/data/storage/el2/base/haps/app/cache

1.2.4. 获取缓存大小

import storageStatistics from "@ohos.file.storageStatistics";
const bundleStats = await storageStatistics.getCurrentBundleStats()
return bundleStats.cacheSize

1.2.5. 清除缓存

static async cleanAppCache(context: Context): Promise<boolean> {
  context.getApplicationContext().area = contextConstant.AreaMode.EL1;
  context.area = contextConstant.AreaMode.EL1;
  const el1AppCacheDir = context.getApplicationContext().cacheDir
  const el1HapCacheDir = context.cacheDir
  context.getApplicationContext().area = contextConstant.AreaMode.EL2;
  context.area = contextConstant.AreaMode.EL2;
  const el2AppCacheDir = context.getApplicationContext().cacheDir
  const el2HapCacheDir = context.cacheDir

  const task = [
    AppInfoUtils.clearCacheTask(el1AppCacheDir),
    AppInfoUtils.clearCacheTask(el1HapCacheDir),
    AppInfoUtils.clearCacheTask(el2AppCacheDir),
    AppInfoUtils.clearCacheTask(el2HapCacheDir)
  ]

  await Promise.all(task)
  return true
}

private static clearCacheTask(dir: string): Promise<boolean> {
  return new Promise((resolve) => {
    fileIo.access(dir).then((exist: boolean) => {
      if (exist) {
        fileIo.rmdir(dir)
      }
      resolve(true)
    })
  })
}

1.3. 示例

1.3.1. 获取缓存大小

  storageStatistics.getCurrentBundleStats 第三方应用异步获取当前应用存储空间大小(单位为Byte),以Promise方式返回。

  @State
  cache: string = ''
  calcCache() {
//获取当前应用的资源信息
    storageStatistics.getCurrentBundleStats()
      .then(res => {
        this.cache = (res.cacheSize / (1000 * 1000)).toFixed(2) + 'MB'
      })
  }
  onPageShow(): void {
    this.calcCache()
  }

1.3.2. 清理缓存

  (1)accessSync(path: string, mode?: AccessModeType): boolean 以同步方法检查文件是否存在。
  (2)rmdirSync(path: string): void 以同步方法删除目录。
  (3)应用有两个缓存目录,一个 entry hap的,一个应用的
  实现步骤:获取上下文–》获取cache目录–》判断是否有该目录–》删除该目录。

clearCache() {
    const ctx = getContext()
//获取当前ability的缓存路径
    const ctxCacheDir = ctx.cacheDir
//判断是否有这个文件
    const ctxExist = fileIo.accessSync(ctxCacheDir)
    if (ctxExist) {
//清除缓存
      fileIo.rmdirSync(ctxCacheDir)
    }
//获得应用级的上下文
    const app = ctx.getApplicationContext()
//应用级的缓存目录
    const appCacheDir = app.cacheDir
//判断有无文件
    const appExist = fileIo.accessSync(appCacheDir)
    if (appExist) {
//清除缓存
      fileIo.rmdirSync(appCacheDir)
    }
    promptAction.showToast({ message: '清理完毕' })
    this.calcCache()
  }
<think>嗯,用户遇到了在构建HarmonyOS应用时的签名失败问题,错误信息是“Signing failed error in build process”,需要重新配置签名或者清除文件夹来解决。根据用户提供的引用内容,特别是引用[1][2],我需要先理解HarmonyOS Next的签名机制常见问题。 首先,引用[1]提到HarmonyOS Next的签名配置在工程级的build-profile.json5文件中。自动签名会导致每个人的本地路径不同,多人协作时可能会冲突,因为git无法忽略这个文件。而用户clone的代码可能已经包含作者的签名配置,导致路径不一致,从而签名失败。引用[2]也指出,当项目配置的签名路径不存在时,会出现找不到签名的错误。 接下来,我需要考虑用户可能的操作步骤。用户可能直接克隆了项目,但原作者的签名路径在本地不存在,所以构建失败。解决方案可能需要重新配置签名或者清除原有的签名配置。 可能的解决步骤包括:清除原有签名配置,重新生成自动签名,或者手动配置统一路径。但自动签名可能导致build-profile.json5文件中的路径不一致,所以手动配置可能更可靠。另外,检查是否忽略了build-profile.json5文件,但根据引用[1],该文件不能忽略,所以需要团队统一配置或使用相对路径。 另外,可能需要清理构建文件夹,因为旧的缓存可能导致问题。比如删除build目录或执行clean操作。 总结,解决方案应该是:首先尝试清除原有配置构建缓存,然后重新配置签名,可以选择自动或手动。如果自动签名导致路径问题,手动配置统一的路径,并确保团队成员的路径一致。或者让每个成员生成自己的签名,但路径可能不同,这样可能需要调整git策略,但引用[1]提到无法忽略该文件,所以可能需要手动处理。 最后,生成相关问题时要围绕HarmonyOS签名机制、多人协作配置、自动签名与手动签名的差异,以及解决签名错误的其他方法。</think>### 解决方案 #### 1. 清除原有签名配置构建缓存 若项目克隆后因签名路径不一致导致失败,需清除旧配置: - **删除`build-profile.json5`中的签名字段**:定位到`signingConfig`相关配置并移除,避免残留错误路径[^1] - **清理构建缓存**:删除项目根目录下的`build`文件夹或执行`hvigor clean`命令 #### 2. 重新配置签名 **方法1:使用自动签名** 在DevEco Studio中: 1. 打开`File > Project Structure > Project > Signing Configs` 2. 勾选`Automatically generate signing`,系统将生成新签名并更新`build-profile.json5` 3. 注意:需确保团队成员各自生成签名后提交`build-profile.json5`的变更,或通过脚本统一路径 **方法2:手动统一签名路径** 1. 团队协商统一签名文件存储路径(如`项目根目录/signing/xxx.p7b`) 2. 修改`build-profile.json5`中`signingConfigs`的路径为相对路径: ```json "signingConfigs": [ { "name": "release", "material": { "certpath": "signing/release.p7b", "storePassword": "******", "keyAlias": "******", "keyPassword": "******", "storeFile": "signing/release.p12", "profile": "signing/yourProfile.p7b" } } ] ``` 3. 将签名文件放入约定目录并添加到.gitignore中,避免提交到仓库[^2] #### 3. 验证构建 执行`hvigor assembleRelease`重新构建,观察签名步骤是否通过 --- ### 相关问题 1. HarmonyOS应用签名与Android签名机制的主要区别是什么? 2. 如何通过脚本自动化处理多人协作中的签名路径问题? 3. 签名文件泄露会导致哪些安全风险?如何防范? 4. 为什么HarmonyOS Next要求严格的签名机制?与iOS有何相似性? : AndroidHarmonyOS签名机制的核心差异在于配置文件的集中管理方式,后者通过工程级配置实现更严格的签名控制 [^2]: 签名路径冲突是多人协作常见问题,需通过约定或自动化工具规避
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值