HarmonyOS 鸿蒙Next 大文件拷贝案例

发布于 1周前 作者 nodeper 最后一次编辑是 5天前 来自 鸿蒙OS

HarmonyOS 鸿蒙Next 大文件拷贝案例

HarmonyOS Next应用开发案例(持续更新中……)

本案例完整代码,请访问:https://gitee.com/harmonyos-cases/cases/tree/master/CommonAppDevelopment/feature/bigfilecopy

本案例已上架HarmonyOS NEXT开源组件市场如需获取或移植该案例,可安装此插件。开发者可使用插件获取鸿蒙组件,添加到业务代码中直接编译运行。

介绍

文件拷贝是应用开发中的一个常见场景,通常有两种方式,一是直接读写文件的全部内容,二是使用buffer多次读写。前者的优点在于使用简单,但是在大文件场景下,内存占用较高,影响应用性能;后者的优点在于内存占用较小,但是编程稍显复杂。本例将展示如何使用buffer来将大文件的rawfile复制到应用沙箱。

效果图预览

使用说明

  1. 点击Start Copy按钮开始复制
  2. 当复制进度达到100%之后,点击Preview按钮进行文件的预览,以验证文件复制的正确性
  3. 如果要反复验证本场景,请在复制完成之后,点击Reset按钮,重置进度,再进行后续验证

实现思路

  1. 根据rawfile文件名获取其所属hap包的RawFileDescriptor,其内部包含真正rawfile文件的长度、在hap包中的偏移量,hap包的fd
    let data: resourceManager.RawFileDescriptor = this.context.resourceManager.getRawFdSync(this.fileName);
    
  2. 打开即将写入的目标文件
    let targetPath: string = this.context.filesDir + "/" + this.fileName;
    let destFile: fs.File = fs.openSync(targetPath, fs.OpenMode.CREATE | fs.OpenMode.READ_WRITE);
    
  3. 创建buffer,用于读写文件内容
    let buffSize: number = BigFileCopyConstants.BUFF_SIZE;
    let buffer: ArrayBuffer = new ArrayBuffer(buffSize);
    
  4. 使用buffer进行文件内容的循环读写,只要实际读入buffer的内容长度不为0,就表示文件内容没有读取完毕,就将读到的内容写入目标文件。注意,这里使用了buffSize来控制想要读取内容的长度,因此需要注意在循环体内对其进行更新
     let off: number = 0; // 记录读取位置的偏移(相较于文件起始偏移)
     let len: number = 0; // 本次读取内容的实际长度
     let readedLen: number = 0; // 记录已读文件长度
     while (len = fs.readSync(data.fd, buffer, { offset: data.offset + off, length: buffSize })) {
       readedLen += len;
       fs.writeSync(destFile.fd, buffer, { offset: off, length: len });
       off = off + len;
       if ((data.length - readedLen) < buffSize) {
         buffSize = data.length - readedLen;
       }
     }
    
  5. 因为复制的是图片文件,复制完毕之后使用Image组件加载该图片进行显示,以验证复制过程的正确性
    Image(BigFileCopyConstants.SANDBOX_PREFIX + this.targetFilePath)
    

高性能知识点

不涉及

工程结构&模块类型

bigfilecopy                                        // har类型
|---constants
|    |---BigFileCopyConstants                      // 常量
|---view
|    |---BigFileCopyView.ets                       // 视图层-文件复制页面

模块依赖

  1. 路由模块:供entry模块实现路由导航

参考资料

  1. 资源分类与访问
  2. resourceManager
4 回复

谢谢楼主提供的思路,解决我的问题。
测到一个bug:

循环体最后一次读数据到buff,buff要清空一下,否则,因最后一笔数据小于buff预设的大小,导致buff后面一部分内容是上次读取的数据,这个bug 我查了好久 ^_^

感谢分享思路及示例,对于目前系统api设计来说。两个地方是注意点:

1.let data: resourceManager.RawFileDescriptor = this.context.resourceManager.getRawFdSync(this.fileName);

其中data.fd对于rawFile下所有的文件名称都是一样的,只有文件起始位置offset和length来代码中控制后续的读写。

2.文件复制关键逻辑:

 let off: number = 0; // 记录读取位置的偏移(相较于文件起始偏移)

 let len: number = 0; // 本次读取内容的实际长度

 let readedLen: number = 0; // 记录已读文件长度

 while (len = fs.readSync(data.fd, buffer, { offset: data.offset + off, length: buffSize })) {

   readedLen += len;

   fs.writeSync(destFile.fd, buffer, { offset: off, length: len });

   off = off + len;

   if ((data.length - readedLen) < buffSize) {

     buffSize = data.length - readedLen;

   }

 }

其中fs.readSync参数中使用fd,offset需要注意是对应文件名称的起始offset,而不是通常普通文件流默认从0开始(简直是个天坑)。并且还要程序中自己主动判断文件总的长度length是否已经超过,否则能一直读取到整个编译后app包的末尾。而不是通常安卓及其他文件流方式的,fd读取系统会自动控制其流的结束,不可能读到其他文件中去,会自动触发-1文件结束。

这个api设计,我认为此处系统设计是个严重的缺陷及风险:1.不方便开发者通过文件名称获取文件描述符,然后使用描述符读取文件流直到无数据(读取大小返回-1)。api实际所有rawFile文件均为同一个fd。

2.安全风险:依赖开发者程序主动控制读取的offset和length来保证文件完整性。实际上整个app的包都可以任意读取。

希望官网能看到这个问题,修改内部实现。

1.对rawFile下每一个文件名返回不同的文件描述符fd。起始偏移量最好是0,开发者不需要关注开始位置,并且不能够从整个app包位置读取。

2.api内部对通过fs.readSync读取文件流时,内部根据文件length自动控制结束,返回通用的流结束标志-1,表示无数据。不能让可以一直读数据直到整个app包的末尾。

作为IT专家,对于HarmonyOS 鸿蒙Next的大文件拷贝案例,我们可以讨论一种常见的实现方法:

在HarmonyOS应用开发中,处理大文件拷贝时,通常不建议直接读写文件的全部内容,因为这可能会导致内存占用过高,影响应用性能。更好的方法是使用buffer进行多次读写。

具体步骤如下:

  1. 获取源文件的RawFileDescriptor,它包含了文件的长度、在包中的偏移量等信息。
  2. 打开目标文件,准备写入数据。
  3. 创建一个buffer,用于读写文件内容。buffer的大小可以根据实际情况设定,但不宜过大或过小。
  4. 使用循环,通过buffer读取源文件的内容,并写入到目标文件中。每次读取后,需要更新读取位置的偏移和已读文件长度。
  5. 当读取的内容长度不为0时,表示文件内容还未读取完毕,继续循环。当读取的内容长度为0时,表示文件已经读取完毕。

在实际应用中,这种方法可以有效地减少内存占用,提高文件拷贝的效率。但需要注意的是,在处理大文件时,还需要考虑文件的完整性校验、错误处理等问题。

此外,如果在拷贝过程中遇到“文件损坏”等问题,可以尝试使用文件校验和(如MD5、SHA等)来验证文件的完整性,或者检查文件处理代码中是否存在潜在的错误。

如果问题依旧没法解决请联系官网客服,官网地址是:https://www.itying.com/category-93-b0.html。

回到顶部