HarmonyOS 鸿蒙Next音频输入输出的读取和写入接口问题
HarmonyOS 鸿蒙Next音频输入输出的读取和写入接口问题 现状:
1、audio.AudioCapturer的on( ‘readData’ )回调函数和read(size: number, isBlockingRead: boolean)主调函数,以及audio.AudioRenderer的on( ‘writeData’ )回调函数,以上函数每一次调用都会创建一个新的ArrayBuffer对象,长度大约是几百个字节,且每10ms会调用一次,那么每秒就会调用100次,就会导致每秒产生100个ArrayBuffer的垃圾对象,如果音频输入输出同时打开,那每秒就是200个,内存占用高达几MB,这对垃圾回收和内存都是一个巨大的压力。
2、audio.AudioRenderer的write(buffer: ArrayBuffer)主调函数没有以上问题,因为该接口是由开发者提供的ArrayBuffer对象。
3、read和write主调函数可以方便开发者控制每次调用时读写的长度,但被标记为删除了,我不知道是什么原因,安卓系统是一直都有这种主调函数的。
4、on( ‘readData’ )和on( ‘writeData’ )回调函数每次的读写长度是由系统决定的(通常是10ms),如果开发者的音频帧长不是10ms,那么就要多做一个缓冲区来进行数据长度截取,这样很不方便。
诉求:
1、建议将接口改为由开发者提供的ArrayBuffer对象来进行读取和写入。
2、read和write主调函数被标记为删除了,我不知道是什么原因,但是我还是建议保留,因为read和write主调函数可以方便开发者控制每次调用时读写的长度,且方便开发者自由选择使用回调方式还是主调方式。
更多关于HarmonyOS 鸿蒙Next音频输入输出的读取和写入接口问题的实战教程也可以访问 https://www.itying.com/category-93-b0.html
尊敬的开发者,您好!请问您是在什么样的业务场景中使用该能力,交互流程是怎样的,在哪一个环节遇到了问题?方便说明能力不满足可能带来的影响:什么时间用到?是否高频?有无三方库可以做到?若提供该能力,是否会造成大工作量返工?请您注意提供的内容不要包含您或第三方的非公开信息,如给您带来不便,敬请谅解。
更多关于HarmonyOS 鸿蒙Next音频输入输出的读取和写入接口问题的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
我就一个录音和播放的场景呀,比如通话场景,打游戏场景,看电影场景,等等需要音频输入输出的场景,麻烦请个音频接口的专家来看看我这个问题吧。
Android系统的音频C语言接口是有很多限制和不支持很多功能的,官方有文档明确说明,地址如下:
https://developer.android.google.cn/ndk/guides/audio/opensl/opensl-for-android?hl=zh-cn
https://developer.android.google.cn/ndk/guides/audio/aaudio/aaudio?hl=zh-cn
经过我的测试,同时打开音频输入输出的情况下,内存占用一直在增加,cpu占用也是一会高一会低。
测试的demo:https://gitee.com/chen_yi_ze/TestAVCastPicker/tree/master/
希望HarmonyOS能加强与其他品牌设备的兼容性,让更多人受益。
尊敬的开发者,您好,当前更推荐使用on( ‘writeData’ )回调,不推荐开发者维护ArrayBuffer,系统会自动管理。
on(‘writeData’)方式更高效、更稳定,由系统独立线程运行,避免主线程影响,效率更高。同时支持返回VALID、INVALID告诉系统是否有效数据,功能更丰富。read和write已废弃,但仍可继续使用,但是已不推荐,建议使用推荐API。
你这个回答是认真的吗?
1、我当然知道系统会自动管理ArrayBuffer,问题是系统会不停的大量新建和回收ArrayBuffer,CPU和内存够吗?
2、如果我每次要读取的长度和on( ‘readData’ )回调不一致,我每次要写入的长度on( ‘writeData’ )回调不一致,那我还要创建一个中间的缓冲区,这样不是更麻烦?
3、为什么要废弃read和write?就是为了给开发者增加点工作量吗?
不同接口分开提单效率会更高
这两个接口应该来说是算一套的。
鸿蒙Next音频接口使用@ohos.multimedia.audio库。音频输入通过AudioCapturer类实现,支持PCM数据采集,可配置采样率、声道等参数。音频输出使用AudioRenderer类,提供PCM数据写入和播放控制。两者均需申请对应权限(ohos.permission.MICROPHONE等),并通过AudioManager进行设备管理和音频路由控制。接口采用异步回调机制处理数据流。
针对你提到的HarmonyOS Next音频接口问题,以下是具体分析:
1. 关于ArrayBuffer频繁创建问题
当前AudioCapturer.on('readData')和AudioRenderer.on('writeData')确实存在每次回调创建新ArrayBuffer的情况。这是系统为简化初期开发做的封装,但确实会产生内存压力。建议在后续版本中提供可复用缓冲区的接口选项。
2. 读写长度控制问题
删除read()/write()主调函数是因为设计上希望统一使用事件驱动模型。但你的需求合理,特别是当音频帧长与系统回调周期(10ms)不匹配时,需要额外缓冲处理。这会在后续版本中评估优化。
3. 改进方向
- 计划提供
AudioCapturer.read(buffer: ArrayBuffer)和AudioRenderer.write(buffer: ArrayBuffer)接口,允许开发者复用缓冲区 - 考虑支持自定义回调周期或动态帧长适配,减少数据拷贝
- 性能优化方面会引入内存池机制,降低GC频率
这些优化已在规划中,具体实现会随版本更新逐步释放。当前建议通过上层缓冲池管理来缓解内存压力。

