鸿蒙踩坑记之一招解决等待多个并发结果

即使工作再忙,也要停下来,思考一下自己想要的是什么?

前言

年前公司与华为签订了合作备忘录,加入了鸿蒙生态这个大家庭。。公司想赶着鸿蒙纯血系统上市之前,发布自己的鸿蒙软件。开发鸿蒙NEXT版本软件就变成了今年的一个工作重心。

本文主要讲解开发过程中遇到的并发问题,官方API 11文档写的太简单了,根本没有解决方案,小编也是苦思冥想,绞尽脑汁才找到解决方案。需要开发鸿蒙的小伙伴可以仔细阅读,避免踩坑。

问题

在开发清除缓存的功能时,鸿蒙NEXT提供的文档中说明,应用缓存文件有四个,需要清除指定的四个缓存文件夹。如图所示:

清除缓存代码如下:

typescript 复制代码
import fs from '@ohos.file.fs'
          
    fs.access("文件路径").then((isHas:boolean) => {
      if(isHas) { //判断文件是否存在
        fs.rmdirSync("文件路径")//删除文件
       
      }
    })
  

需要同时清除这四个文件夹,然后再计算这四个文件夹的大小。由于fs.access 方法是耗时操作。所以只能在异步线程中执行。

解决方案

一般思路

鸿蒙官方文档API 11 提供了使用Promise和async/await处理异步并发问题。

注意是单次I/O任务,可问题是我们需要解决同时并发问题,一次拿到四次清除缓存结果再去统计缓存大小。这个时候可能有的小伙伴就会说,那就先清除第一个,等一个结果返回再清除第二个,以此类推。也能解决问题。如下图所示:

scss 复制代码
        
    fs.access("文件路径1").then((isHas:boolean) => {
      if(isHas) { //判断文件是否存在
        fs.rmdirSync("文件路径1")//删除文件
               
       fs.access("文件路径2").then((isHas:boolean) => {
         if(isHas) { //判断文件是否存在
           fs.rmdirSync("文件路径2")//删除文件
             .....................
        }
    })
      }
    })

但是这样就会带来两个问题:多层嵌套与代码混乱。在Flutter中这个问题非常好解决。这里就不详细描述了。

优雅方案

使用Promise.all 解决。小编在官方文档中并没有找到Promise.all 相关说明,可能是鸿蒙还没注意到这种需求场景吧。直接上代码。

  1. 先将文件清除包装成一个异步任务。
typescript 复制代码
asyncClear(dir: string): Promise<void> {
    return new Promise((resolve, reject) => {
      fs.access(dir).then((isHas: boolean) => {
        if (isHas) {
          fs.rmdir(dir)
        }
        resolve()
      })
    })
  }
  1. 将四个缓存文件夹对应的任务放在一个数组中。
kotlin 复制代码
  let promises = [
      this.asyncClear("文件夹1"),
      this.asyncClear("文件夹2"),
      this.asyncClear("文件夹3"),
      this.asyncClear("文件夹4")
    ]
  1. 将任务数组放进Promis.all中,等待四个任务执行结束。
javascript 复制代码
 Promise.all(promises).then(() => {
      // 结束回调
    })
  1. 在结束回调中 再去调用计算缓存大小的方法。
ini 复制代码
 storageStatistics.getCurrentBundleStats().then((bundleStats) => {
        let cacheSizeNum = bundleStats.cacheSize
        let unit = "KB"
        if (cacheSizeNum > 1024) {
          cacheSizeNum = Math.floor(cacheSizeNum) / 1024
          unit = "KB"
        }
        if (cacheSizeNum > 1024) {
          cacheSizeNum = Math.floor(cacheSizeNum) / 1024
          unit = "MB"
        }
        if (cacheSizeNum > 1024) {
          cacheSizeNum = Math.floor(cacheSizeNum) / 1024
          unit = "GB"
        }
        if (cacheSizeNum > 1024) {
          cacheSizeNum = Math.floor(cacheSizeNum) / 1024
          unit = "TB"
        }
        let chacheSizeString = "" + Math.floor(cacheSizeNum) + unit
      });

总结

鸿蒙NEXT的API还不算完善,需要每个开发者的参与,发现问题,提出问题,鸿蒙开发人员才能更好的解决问题。如果您也是鸿蒙开发者,有其他更好的解决方案,欢迎评论区交流 ,互相学习,互相成长!

相关推荐
CHB3 小时前
uni-app x 蒸汽模式 性能测试基准报告 Benchmark
uni-app·harmonyos
kymjs张涛4 小时前
OpenClaw 学习小组:初识
android·linux·人工智能
范特西林7 小时前
实战演练——从零实现一个高性能 Binder 服务
android
范特西林8 小时前
代码的生成:AIDL 编译器与 Parcel 的序列化艺术
android
范特西林8 小时前
深入内核:Binder 驱动的内存管理与事务调度
android
范特西林9 小时前
解剖麻雀:Binder 通信的整体架构全景图
android
范特西林9 小时前
破冰之旅:为什么 Android 选择了 Binder?
android
奔跑中的蜗牛66610 小时前
一次播放器架构升级:Android 直播间 ANR 下降 60%
android
开心就好202511 小时前
iOS App 安全加固流程记录,代码、资源与安装包保护
后端·ios
开心就好202511 小时前
iOS App 性能测试工具怎么选?使用克魔助手(Keymob)结合 Instruments 完成
后端·ios