三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

Android AudioTrack音频投递全解析：从核心原理到低延迟优化实践

发布时间：2026/8/15 14:09:31 三亩地 编程学习日记
Android AudioTrack音频投递全解析：从核心原理到低延迟优化实践

1. 项目概述：深入AudioTrack的音频投递之路

在Android应用开发中，音频播放是一个基础且高频的需求。无论是短视频的背景音乐、在线课程的语音讲解，还是游戏中的音效，最终都需要将PCM音频数据准确地送到底层硬件进行播放。AudioTrack就是这个过程中的核心“搬运工”和“指挥官”。很多开发者对它的理解停留在play()和write()的简单调用上，但一旦遇到音频延迟、卡顿、杂音或者内存占用异常等问题，往往就束手无策。究其原因，是对AudioTrack内部的工作流程、线程模型以及它与Android音频子系统（AudioFlinger, HAL）的交互机制缺乏深入的了解。

本文旨在彻底解析AudioTrack的工作流程。我们将从一次标准的播放调用出发，穿越Java层、JNI层，直抵Native层的核心逻辑，并追踪数据是如何经过AudioFlinger最终抵达音频硬件的。理解这个过程，不仅能帮助你在遇到问题时快速定位根因（比如，是应用层写入太慢，还是AudioFlinger混音负载过高？），更能让你在设计高性能、低延迟的音频应用时做出正确的架构选择，例如在游戏音效中选用MODE_STATIC模式，或在流媒体播放中合理设置bufferSize以避免欠载。我们将结合源码逻辑（基于Android 13）和实际调试经验，把这条路径上的关键节点、潜在瓶颈和优化技巧一一拆解清楚。

2. AudioTrack的整体架构与核心模式解析

在深入流程之前，我们必须先建立对AudioTrack整体架构和两种核心工作模式的理解。这决定了后续数据流和控制流的根本行为。

2.1 核心架构分层

AudioTrack并非一个孤立的类，而是一个跨越多个层级的复杂系统。我们可以将其分为三个主要层次：

  1. Java API层 (android.media.AudioTrack): 这是开发者直接接触的接口。它提供了构建、配置、控制播放的各种方法，如play(),pause(),write(),stop()等。这一层主要处理参数校验、状态管理和对Native层的封装调用。

  2. JNI与Native层 (frameworks/av/media/libaudioclient/AudioTrack.cpp): 这是AudioTrack真正的核心实现。JNI层负责Java与C++之间的通信。Native层的AudioTrack类（我们称之为android::AudioTrack）扮演了“客户端代理”的角色。它内部维护着与AudioFlinger服务通信的IAudioTrack接口代理，管理着用于数据交换的共享内存（AudioTrackShared），并负责创建和管理播放线程。

  3. 系统服务层 (AudioFlinger): 这是Android音频系统的中枢。AudioFlinger运行在mediaserver进程（或audioserver）中，负责管理所有音频流。当NativeAudioTrack被创建时，它会向AudioFlinger发起请求。AudioFlinger会为其创建一个对应的PlaybackThread::Track对象，并将其加入到某个PlaybackThread（如MixerThread）中进行混音和后续处理。

数据流的方向是：应用调用AudioTrack.write(byte[])-> Java层将数据拷贝到Native层的缓冲区 -> NativeAudioTrack的播放线程通过共享内存将数据推送给AudioFlinger->AudioFlinger进行混音、重采样、效果处理等 -> 通过HAL层写入音频硬件。

2.2 两种关键数据投递模式：MODE_STREAM 与 MODE_STATIC

AudioTrack的工作模式是其设计的精髓，直接影响了数据管理方式和适用场景。

MODE_STREAM（流模式）这是最常用、最灵活的模式。在这种模式下，你需要在一个循环中，不断地将音频数据块（chunks）通过write()方法写入AudioTrack的内部缓冲区。AudioTrack会维护一个“双缓冲”或“环形缓冲”机制：一个缓冲区正在被AudioFlinger消费（播放），另一个缓冲区则准备接收你写入的新数据。

  • 工作原理：应用线程和AudioTrack的内部播放线程（或AudioFlinger的消费线程）异步操作。写入操作是非阻塞的，只要目标缓冲区有空间就会立即返回。如果缓冲区满了，write()方法会阻塞，直到有空间可用（除非指定非阻塞模式）。
  • 适用场景：播放未知长度或实时生成的音频，如网络流媒体（在线音乐）、语音通话、TTS（文本转语音）或实时合成的游戏音效。它允许你“边下/边生成、边播”。
  • 核心参数：bufferSizeInBytes至关重要。设置太小容易导致“欠载”（Underrun），即AudioFlinger消耗数据的速度快于你写入的速度，产生卡顿或爆音。设置太大会增加延迟。通常需要通过AudioTrack.getMinBufferSize()计算一个最小值，并根据可接受的延迟适当放大。

MODE_STATIC（静态模式）这种模式适用于短小的、可预加载的音频片段，特别是需要极低延迟触发的音效。

  • 工作原理：在播放开始前，通过一次write()调用，将完整的音频数据（比如一个“砰”的音效文件）全部传输到AudioTrack内部。数据被存储在通过AudioFlinger分配的一块共享内存中。调用play()后，AudioTrack只是向AudioFlinger发送一个启动指令，数据无需再从应用层拷贝，可以直接从共享内存中读取并播放。
  • 适用场景：游戏中的爆炸、枪击等短音效，UI交互提示音。它的优势是延迟极低，因为播放启动时没有数据拷贝的开销。同时，同一份数据可以被重复播放（play()多次）而无需重新加载，节省CPU和内存带宽。
  • 注意事项：音频数据必须一次性准备好且大小固定。不适合长音频，因为会占用大量共享内存。

实操心得：模式选择与性能我曾在一个游戏项目中，将所有短于2秒的音效改用MODE_STATIC模式加载。对比之前的MODE_STREAM循环写入，同一场景下的音效触发延迟从平均15-20ms降低到了5ms以内，CPU占用也下降了约5%。对于长背景音乐，则继续使用MODE_STREAM。这个选择对体验的提升是立竿见影的。

2.3 AudioTrack的关键构造参数解析

创建一个AudioTrack时，一系列参数共同定义了它的行为特性。除了模式，以下几个参数对流程有深远影响：

  • streamType: 如STREAM_MUSIC,STREAM_ALARM。这决定了音频流的优先级和路由策略（例如，按音量键时控制的是哪个流）。在Android O（API 26）之后，官方推荐使用AudioAttributes来提供更丰富的描述信息。
  • sampleRateInHz: 采样率。必须与你的PCM数据采样率一致，否则会产生音调变化。常见的如44100Hz（CD质量）、48000Hz。
  • channelConfig: 声道配置，如CHANNEL_OUT_MONO,CHANNEL_OUT_STEREO。它影响了数据帧（frame）的大小计算。一帧数据 = 通道数 × 采样位数（如16bit=2字节）。
  • audioFormat: 采样位数和编码格式，如ENCODING_PCM_16BIT,ENCODING_PCM_FLOAT。ENCODING_PCM_FLOAT能提供更高的动态范围和精度，适合音频处理中间环节。
  • bufferSizeInBytes: 内部缓冲区大小。这是平衡延迟和稳定性的关键。计算公式通常为：最小缓冲区大小 = 最小帧数 × 每帧字节数。AudioTrack.getMinBufferSize()会根据你传入的采样率、声道和格式，返回系统建议的最小安全缓冲区大小。在实际使用中，为了应对系统调度抖动，通常会取这个值的2-4倍。
  • sessionId: 音频会话ID。可以用于将多个AudioTrack（或AudioRecord）关联到同一个音频效果会话中（如全局的均衡器、重低音）。

3. AudioTrack生命周期与核心流程拆解

现在，我们跟随一次典型的MODE_STREAM播放流程，深入每个阶段的内幕。

3.1 初始化与创建：从Java到AudioFlinger

当你执行new AudioTrack(...)时，背后发生了一系列连锁反应。

Java层构造Java层的构造函数进行参数校验和归一化。例如，它会确保bufferSize不小于getMinBufferSize()返回的值。然后，它调用Native方法native_setup()，将参数打包传递给Native层。

JNI与Native层初始化在android_media_AudioTrack.cpp的android_media_AudioTrack_native_setup()JNI函数中，会创建Native的android::AudioTrack对象。这是关键的一步。NativeAudioTrack的构造函数会：

  1. 根据audioFormat计算帧大小（frameSize）。
  2. 根据bufferSizeInBytes和帧大小，计算内部缓冲区的帧容量。
  3. 初始化状态为STATE_INITIALIZED。

创建IAudioTrack：与AudioFlinger建立连接NativeAudioTrack并不会立即分配缓冲区。真正的资源分配发生在第一次启动播放（或对于MODE_STATIC，在第一次write）时，通过调用createTrack_l()函数。这个函数会通过Binder调用AudioFlinger的createTrack()方法。

AudioFlinger::createTrack()是系统服务端的核心入口。它会：

  1. 查找或创建PlaybackThread：根据请求的output（通常对应音频设备，如扬声器、耳机）找到对应的PlaybackThread（如MixerThread）。
  2. 创建Track对象：在该PlaybackThread中创建一个Track对象（实际是PlaybackThread::Track）。这个Track对象是服务端对客户端AudioTrack的表示。
  3. 分配共享内存：AudioFlinger会从它管理的匿名共享内存池（MemoryDealer）中分配一块内存。这块内存就是客户端和服务端数据交换的桥梁，其结构体为AudioTrackShared，里面包含了数据缓冲区、读写索引、控制命令（如循环、停止）等。
  4. 返回IAudioTrack接口：AudioFlinger将新创建的Track对象封装成一个IAudioTrackBinder接口对象，返回给客户端的NativeAudioTrack。

至此，客户端AudioTrack持有了IAudioTrack代理，双方通过共享内存建立了联系。客户端向共享内存写入数据，服务端从中读取数据并混音。

3.2 数据写入与缓冲区管理

对于MODE_STREAM模式，数据通过write(byte[]/short[]/float[], int, int)方法写入。

Java层写入Java层的write()方法是一个同步方法。它首先进行基本的边界检查（offset, size），然后调用对应的Native方法native_write_byte(...)等。

Native层写入与缓冲在Native层的write()函数中，核心逻辑如下：

  1. 获取缓冲区信息：通过IAudioTrack接口，从共享内存的AudioTrackShared头部获取当前的写指针位置和可用空间。
  2. 计算可写大小：根据服务端消费的速度（读指针）和缓冲区总大小，计算出当前客户端可以安全写入的数据量，避免覆盖未被消费的数据。
  3. 内存拷贝：将Java层传下来的数据（通过JNI已转换为C++数组），拷贝到共享内存中计算好的写指针位置。这是一个memcpy操作。
  4. 更新写指针：数据拷贝完成后，更新共享内存中的写指针（front）。这个更新操作本身是一个“发布”动作，意味着服务端的PlaybackThread在下一次循环中就能看到新数据。
  5. 阻塞与非阻塞：如果调用write()时可用空间为0（缓冲区满），在默认的阻塞模式下，调用线程会通过一个futex等待（ClientProxy::obtainBuffer()内），直到服务端消费了一些数据，腾出空间后被唤醒。你可以通过WRITE_NON_BLOCKING标志来让write()立即返回并告知写入的字节数（可能为0）。

注意事项：write()的线程安全与性能AudioTrack.write()方法本身是线程安全的，多个线程可以同时调用。但内部是通过锁来保证共享内存指针操作的原子性。频繁的锁竞争会成为性能瓶颈。最佳实践是：在单个高优先级线程（如专用的音频渲染线程）中进行所有的write()调用。避免在UI线程中进行大量的音频数据写入，这可能导致界面卡顿和音频写入不及时。

共享内存结构AudioTrackShared理解这个结构对调试复杂问题很有帮助。它主要包含：

  • mBuffer: 真正的PCM数据环形缓冲区。
  • mFront/mRear: 客户端写指针和服务端读指针（在Proxy中具体管理）。
  • mFlags: 控制标志位，如CBLK_UNDERRUN（欠载标志，当服务端没数据可读时设置）。
  • mServer: 服务端状态（如帧数、时间戳）。
  • mClient: 客户端命令（如循环开始/结束点）。

3.3 播放控制：play, pause, stop, flush

控制命令的流程相对直接，但内部状态机变化需要留意。

  • play(): Java层调用Native的native_start()。Native层检查状态，如果处于STATE_INITIALIZED或STATE_STOPPED，则通过IAudioTrack->start()发送Binder调用。AudioFlinger收到后，会将其对应Track的状态置为活跃，PlaybackThread会在下一次混音循环中开始从该Track的缓冲区读取数据。NativeAudioTrack的状态变为STATE_ACTIVE。关键点：对于MODE_STATIC，play()可以重复调用，每次都会从音频数据开头重新播放。
  • pause(): 发送IAudioTrack->pause()调用。服务端会暂停从该Track读取数据，但缓冲区内容保持不变。Native状态变为STATE_PAUSED。这对于需要精确定位恢复播放的场景有用。
  • stop(): 发送IAudioTrack->stop()调用。服务端会停止读取数据，并且重置读写指针。Native状态变为STATE_STOPPED。调用stop()后，缓冲区中未播放的数据会被丢弃。如果你想从停止的地方恢复，应该用pause()而不是stop()。
  • flush(): 这个操作只对MODE_STREAM有效。它通过IAudioTrack->flush()通知服务端丢弃缓冲区中所有尚未播放的数据，并将读指针重置到当前的写指针位置。调用flush()后，应立即准备写入新的数据。常用于在切换音频流或处理用户跳播时清空旧数据。

状态机流转AudioTrack有一个清晰的状态机：STATE_UNINITIALIZED->STATE_INITIALIZED-> (STATE_STOPPED) ->STATE_ACTIVE<->STATE_PAUSED->STATE_STOPPED。不正确的状态调用（如在STATE_INITIALIZED时调用pause()）会导致IllegalStateException。

3.4 释放与资源回收

当调用release()或AudioTrack对象被垃圾回收时（finalize()），会触发资源释放流程。

  1. Native层销毁：调用Native的native_release()。NativeAudioTrack的析构函数会执行以下关键操作：
    • 如果处于STATE_ACTIVE或STATE_PAUSED，先调用stop()。
    • 通过IAudioTrack->destroy()通知AudioFlinger销毁对应的服务端Track对象。
    • AudioFlinger会将该Track从PlaybackThread的活跃轨道列表中移除，并释放其占用的共享内存。
    • Native对象销毁，断开Binder连接。
  2. Java层清理：Java层对象引用被清除。

常见问题：内存泄漏与“僵尸”AudioTrack如果不显式调用release()，仅依赖finalize()，可能会因为对象回收不及时导致Native资源（特别是共享内存和Binder连接）延迟释放。在音频Activity或Fragment中，务必在onDestroy()或onPause()中主动调用release()。我曾遇到一个案例，一个后台服务不断创建短暂的AudioTrack播放提示音但未正确释放，最终导致AudioFlinger的共享内存池耗尽，系统内所有音频播放失败。

4. 核心线程模型与低延迟优化

AudioTrack的性能和延迟很大程度上由其线程模型决定。

4.1 客户端回调与播放线程

在MODE_STREAM模式下，AudioTrack在Native层内部维护了一个关键的线程：播放线程（Playback Thread），更准确地说，是一个基于回调的数据填充机制。

当你使用AudioTrack的构造函数，并传入一个AudioTrack.OnPlaybackPositionUpdateListener监听器来接收周期性的标记（Marker）或周期（Period）回调时，或者当你使用write()的阻塞模式时，Native层会创建一个线程（或使用调用write的线程）来管理数据推送。

这个线程的核心工作循环（简化）如下：

while (mActive) { // 1. 通过Proxy，计算共享内存中可写的空间 Buffer audioBuffer; status_t status = obtainBuffer(&audioBuffer, ...); if (status == NO_ERROR) { // 2. 如果有设置回调Listener，则在这里回调Java层的onPeriodicNotification // 通知应用层需要准备/写入数据了（这是一种“拉”模式）。 // 3. 在标准的write()模式下，这一步是空的，数据由应用主动write。 // 4. 更新缓冲区信息，如果数据就绪，内部会通知Proxy数据已写入。 releaseBuffer(&audioBuffer); } else if (status == WOULD_BLOCK) { // 缓冲区满，等待 usleep(kRetryWaitTimeUs); } else { break; // 出错 } }

实际上，在常见的主动write()模式下，这个循环并不由AudioTrack主动运行来“拉”数据，而是由应用线程驱动“推”数据。AudioTrack内部更重要的线程机制体现在与AudioFlinger的交互上。

4.2 服务端混音线程：AudioFlinger的PlaybackThread

真正的播放动力源在AudioFlinger端。以最常见的MixerThread为例，它运行在一个高优先级的线程中，以一个固定的周期（例如，每10ms或20ms，对应一个“周期”的帧数）进行循环：

  1. 收集待混音Track：遍历所有状态为ACTIVE的Track。
  2. 从Track读取数据：对于每个Track，通过其AudioBufferProvider接口（背后就是共享内存）读取PCM数据。如果某个Track的缓冲区没有足够的数据（读指针追上了写指针），就会发生欠载（Underrun）。该Track会被静音（输出0），并在其AudioTrackShared中设置CBLK_UNDERRUN标志。客户端可以通过getUnderrunCount()查询。
  3. 执行混音：将所有Track的数据（可能格式、采样率不同）进行重采样、格式转换，然后混合成一个单一的音频流。
  4. 应用音频效果：如果Track或输出设备上挂载了音频效果（如均衡器、重低音），则应用这些效果。
  5. 写入HAL：将最终混音后的数据通过Audio HAL（硬件抽象层）接口，写入到音频硬件（DMA缓冲区）中。

这个循环的稳定性和延迟直接决定了整个音频播放的体验。AudioTrack的bufferSize设置，本质上就是为了应对这个循环的消费速度和应用层生产速度之间的不匹配，提供一个“蓄水池”来平滑抖动。

4.3 低延迟音频实践与AAudio

标准的AudioTrack虽然功能完善，但为了通用性和兼容性，其路径较长（Java->JNI->Native Client->Binder->AudioFlinger->HAL），缓冲区也相对较大，这引入了不可忽视的延迟（通常超过50ms）。对于需要极低延迟的应用（如音乐制作、实时乐器、高响应游戏），Android提供了AAudio API（从Android O引入）。

AAudio 的设计哲学是“简单、高效、低延迟”：

  • 数据路径优化：AAudio 允许应用以“独占模式”直接访问音频设备，绕过AudioFlinger的混音器，路径大大缩短。
  • 回调驱动：AAudio 采用高性能的“回调模型”。应用注册一个数据回调函数，当音频设备需要新的数据时，AAudio 库会直接在一个高优先级的线程中调用这个回调函数，应用在其中填充数据。这减少了数据拷贝和线程同步的开销。
  • 更精细的控制：提供更稳定的时钟模型、精确的帧计数和更低的延迟查询。

如果你的应用目标API级别在26以上，并且对延迟有严苛要求（<20ms），AAudio 是比 AudioTrack 更优的选择。不过，AAudio 的兼容性需要测试，特别是在一些定制ROM或老旧设备上。对于大多数流媒体播放、语音消息等场景，AudioTrack的稳定性和功能完备性已经足够。

5. 典型问题排查与性能调优指南

理解了流程，排查问题就有了清晰的路线图。下面是一些常见问题的根因分析和解决方法。

5.1 音频播放卡顿、杂音（噼啪声）

这是最常见的问题，根本原因通常是缓冲区欠载（Underrun）。

  • 问题现象：播放不流畅，有中断，或伴随“噼啪”的噪音。
  • 根因分析：
    1. 应用层写入不及时：AudioTrack.write()调用间隔不稳定，或者单次写入的数据量不足以维持到下一次写入。这可能是由于应用主线程繁忙（如UI绘制、网络请求阻塞了音频写入线程），或者音频数据生产线程优先级太低。
    2. 缓冲区设置过小：bufferSizeInBytes设置的值太小，无法缓冲足够的数据来应对系统调度或GC导致的短暂延迟。
    3. 系统负载过高：AudioFlinger的混音线程或音频HAL层因系统整体负载过高而得不到及时调度。
  • 排查步骤：
    1. 检查欠载计数：在播放循环中定期调用AudioTrack.getUnderrunCount()。如果这个数字在增长，就确认了欠载的发生。
    2. 监控写入线程：确保你的音频写入线程运行在一个稳定的高优先级线程中。可以使用android.os.Process.setThreadPriority()设置THREAD_PRIORITY_AUDIO或THREAD_PRIORITY_URGENT_AUDIO。
    3. 调整缓冲区大小：使用AudioTrack.getMinBufferSize()获取最小值，然后将其乘以一个系数（如2、4）。可以通过实验找到一个平衡点：在可接受的延迟范围内（延迟 ≈ 缓冲区大小 / (采样率 × 通道数 × 每样本字节数)），尽可能使用大缓冲区。
    4. 优化数据准备：如果音频数据来自网络或解码，确保解码/网络读取线程与写入线程解耦，使用缓冲区队列（如LinkedBlockingQueue）进行通信，避免写入线程等待。

5.2 播放延迟过大

  • 根因分析：总延迟 = 应用准备延迟 +AudioTrack缓冲区延迟 +AudioFlinger处理延迟 + HAL/硬件延迟。其中AudioTrack缓冲区延迟是主要可控部分。
  • 优化方法：
    1. 减小缓冲区：在保证不欠载的前提下，逐步减小bufferSize。这对于交互式应用（如钢琴APP）至关重要。
    2. 使用MODE_STATIC：对于短音效，绝对应该使用此模式。
    3. 考虑AAudio：如前所述，切换到AAudio API是降低延迟最有效的手段。
    4. 关注硬件延迟：不同设备的硬件延迟（DMA缓冲区大小等）差异很大。可以通过AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER)等API查询硬件特性。

5.3 内存占用异常或OOM

  • 根因分析：
    1. 未释放AudioTrack：循环创建AudioTrack但未调用release()。
    2. MODE_STATIC内存未释放：静态模式加载的音频数据存储在AudioFlinger管理的共享内存中。即使Java对象被回收，如果Native对象未正确销毁，这块内存不会被释放。
    3. 过大的缓冲区：为MODE_STREAM设置了异常巨大的缓冲区。
  • 排查方法：
    1. 使用Android Profiler的Memory Profiler，查看Native内存部分。反复播放/停止音频，观察libaudioclient.so相关的内存是否持续增长。
    2. 确保在Activity/Fragment/Service的销毁生命周期中，有对应的release()调用。
    3. 对于静态音频，考虑使用SoundPool替代，它对短音效的内存管理和复用有更好的优化。

5.4 音量、声道或音效异常

  • 音量问题：检查AudioTrack.setVolume()的设置。注意音量是乘数关系（0.0到1.0）。同时检查系统音量设置和AudioManager的流音量。
  • 声道问题：确保channelConfig与你的PCM数据布局匹配。例如，如果你提供的是交错立体声数据（LRLRLR），却配置了CHANNEL_OUT_MONO，会导致播放异常。
  • 音效问题：如果使用了sessionId并附加了音频效果（如Equalizer），检查效果器的参数设置是否正确，以及效果器是否被正确启用/禁用。

5.5 实战调试技巧：使用Systrace

Systrace是分析音频问题（尤其是卡顿和延迟）的神器。

  1. 在代码中关键位置添加Trace.beginSection("AudioWrite")和Trace.endSection()。
  2. 录制一段包含音频操作的Systrace。
  3. 在audio标签下，你可以看到：
    • audiotrack：你的AudioTrack写入操作。
    • AudioFlinger：混音线程的活动。
    • audio_hw：HAL层的活动。
  4. 分析重点：观察audiotrack的写入间隔是否均匀，是否有长时间的空隙（表明写入线程被阻塞）。观察AudioFlinger的混音周期是否稳定。如果audiotrack写入很密集，但AudioFlinger消费很慢，可能是系统负载问题。

理解AudioTrack的流程，就像掌握了音频数据在Android系统中的旅行地图。从应用层的一个简单write()调用开始，数据穿越JNI、共享内存、Binder IPC，经过AudioFlinger的混音与处理，最终抵达硬件发出声音。每一个环节的设计选择（流模式 vs 静态模式、缓冲区大小、线程优先级）都会对最终的延迟、稳定性和功耗产生影响。当出现问题时，沿着这条路径逐段排查——是应用写入太慢？缓冲区太小？还是AudioFlinger负载太高？——就能快速定位症结。对于绝大多数应用，遵循最佳实践（正确释放资源、在主线程外操作、合理设置缓冲区）就能获得良好的音频体验。而对于追求极致性能的应用，将目光投向AAudio和更底层的调试工具，则是必然的选择。

编程学习 学习日记 实战经验
← 返回列表