HarmonyOS 鸿蒙Next 大文件拷贝案例
HarmonyOS 鸿蒙Next 大文件拷贝案例
HarmonyOS Next应用开发案例(持续更新中……)
本案例完整代码,请访问:https://gitee.com/harmonyos-cases/cases/tree/master/CommonAppDevelopment/feature/bigfilecopy
本案例已上架HarmonyOS NEXT开源组件市场,如需获取或移植该案例,可安装此插件。开发者可使用插件获取鸿蒙组件,添加到业务代码中直接编译运行。
介绍
文件拷贝是应用开发中的一个常见场景,通常有两种方式,一是直接读写文件的全部内容,二是使用buffer多次读写。前者的优点在于使用简单,但是在大文件场景下,内存占用较高,影响应用性能;后者的优点在于内存占用较小,但是编程稍显复杂。本例将展示如何使用buffer来将大文件的rawfile复制到应用沙箱。
效果图预览
使用说明
- 点击Start Copy按钮开始复制
- 当复制进度达到100%之后,点击Preview按钮进行文件的预览,以验证文件复制的正确性
- 如果要反复验证本场景,请在复制完成之后,点击Reset按钮,重置进度,再进行后续验证
实现思路
- 根据rawfile文件名获取其所属hap包的RawFileDescriptor,其内部包含真正rawfile文件的长度、在hap包中的偏移量,hap包的fd
let data: resourceManager.RawFileDescriptor = this.context.resourceManager.getRawFdSync(this.fileName);
- 打开即将写入的目标文件
let targetPath: string = this.context.filesDir + "/" + this.fileName; let destFile: fs.File = fs.openSync(targetPath, fs.OpenMode.CREATE | fs.OpenMode.READ_WRITE);
- 创建buffer,用于读写文件内容
let buffSize: number = BigFileCopyConstants.BUFF_SIZE; let buffer: ArrayBuffer = new ArrayBuffer(buffSize);
- 使用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; } }
- 因为复制的是图片文件,复制完毕之后使用Image组件加载该图片进行显示,以验证复制过程的正确性
Image(BigFileCopyConstants.SANDBOX_PREFIX + this.targetFilePath)
高性能知识点
不涉及
工程结构&模块类型
bigfilecopy // har类型
|---constants
| |---BigFileCopyConstants // 常量
|---view
| |---BigFileCopyView.ets // 视图层-文件复制页面
模块依赖
- 路由模块:供entry模块实现路由导航
参考资料
挺不错
谢谢楼主提供的思路,解决我的问题。
测到一个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进行多次读写。
具体步骤如下:
- 获取源文件的RawFileDescriptor,它包含了文件的长度、在包中的偏移量等信息。
- 打开目标文件,准备写入数据。
- 创建一个buffer,用于读写文件内容。buffer的大小可以根据实际情况设定,但不宜过大或过小。
- 使用循环,通过buffer读取源文件的内容,并写入到目标文件中。每次读取后,需要更新读取位置的偏移和已读文件长度。
- 当读取的内容长度不为0时,表示文件内容还未读取完毕,继续循环。当读取的内容长度为0时,表示文件已经读取完毕。
在实际应用中,这种方法可以有效地减少内存占用,提高文件拷贝的效率。但需要注意的是,在处理大文件时,还需要考虑文件的完整性校验、错误处理等问题。
此外,如果在拷贝过程中遇到“文件损坏”等问题,可以尝试使用文件校验和(如MD5、SHA等)来验证文件的完整性,或者检查文件处理代码中是否存在潜在的错误。
如果问题依旧没法解决请联系官网客服,官网地址是:https://www.itying.com/category-93-b0.html。