简介：这是一份面向 Android 开发者的声波曲线自定义控件完整工程，适用于录音、语音对讲、音乐可视化等场景，通过绘制正余弦波形将声音强弱动态呈现，为用户提供直观的音频反馈。压缩包共 51 个文件、约 1.68MB，其中 Java 源码承担曲线计算、Canvas 绘制与动画控制，XML 文件用于布局和资源配置，Gradle 脚本支撑工程构建，PNG/GIF 图片可快速预览控件效果，整体目录结构整洁，便于导入 Android Studio 后直接运行调试。已有 867 人学习此工程，内容覆盖自定义 View 从基础绘制到性能优化的关键路径：在 onDraw 中计算坐标并连接波形，将录音数据映射为振幅，利用 ValueAnimator 驱动曲线动态变化，处理录音事件监听，并通过离屏渲染等方式优化性能。开发者通过分析 VoiceLine-master 源码，可系统掌握声波控件的实现原理，同时自定义颜色、线宽等样式，快速集成到实际项目里，有效提升录音界面的反馈体验与视觉表现力。 做安卓开发这些年，自定义View始终是我觉得技术含金量最高、也最能体现一个开发者基本功的模块。这段时间正好在做一个语音类应用，需要在录音界面上实时显示音量变化和声波曲线，虽然网上能找到一堆现成的波形库，但要么样式对不上需求，要么耦合太重没法定制，干脆从零写了一个android 声波曲线自定义控件。这篇文章就把这个控件的完整思路、关键代码和踩坑过程整理出来，项目代码基于 Kotlin + Android Studio，覆盖从麦克风数据采集到 Canvas 绘制上屏的全链路，适合正在做音频类 App、或者想系统提升自定义 View 能力的开发者参考。
1. 动手之前：声波曲线控件的思路拆解
1.1 为什么选自定义 View 而不是现成开源库
很多人第一反应是去 GitHub 找现成的波形库，我也试过。像 MPAndroidChart、GraphView、VU Meter 这类库在某些场景确实够用，但实际使用起来有几个绕不开的痛点：第一是样式定制困难，产品要的效果可能是渐变色柱状图、圆角波形、甚至带峰值连线的款式，改库里的源码比自己写还要费劲；第二是坐标系和缩放逻辑是别人定义的，当需要和 RecyclerView 联动、或者动态调整显示窗口时，改起来非常痛苦；第三是最致命的内存问题，很多库为了支持大量静态数据点，内部缓存了庞大的数据集，但实时录音场景下数据是无限增长的，直接用会出现内存抖动。
自定义 View 的核心优势在于两点：一是彻底掌控绘制逻辑，所有坐标计算、颜色、动画都自己说了算，产品要什么效果就改成什么效果；二是可以针对实时数据流做优化，用固定长度的环形缓冲区存振幅数据，内存消耗恒定，不会因为录音时长增加而膨胀。从性能角度讲，纯 Canvas 原生绘制在高帧率下完全能胜任声波这种简单几何图形的刷新，并不需要用到 OpenGL 或 RenderScript 这类重型工具。
1.2 需求定位：你要的其实是哪种“波形”
声波曲线这个词在不同场景里指的东西不太一样，写代码之前必须把需求形态确定下来，否则后面容易返工。常见的有三种形态：
- 实时柱状频谱：仿录音 App 那种一根根垂直跳动的彩条，实时反映当前音量大小，实现最简单。
- 时间轴长波形：仿微信语音消息里的绿条，显示一段完整录音的波形包络，横轴是时间，纵轴是振幅，关键点是历史数据的存储与滚动。
- 平滑贝塞尔曲线：仿音乐播放器里的动态频谱线，用连续曲线展示频率能量分布，视觉上最炫，但需要做 FFT 或平滑算法支撑。
我这次做的控件把前两种都集成进去了，通过一个枚举类型切换。核心数据结构是一个环形缓冲的振幅数组，负责解决“无限数据流 + 固定内存”的矛盾。后面所有绘制和状态控制都围绕这个数组展开。
2. 数据采集：让控件“听得见”声音
2.1 麦克风读数的两种路径
声波控件要显示的是音量数据，音量从哪来？两种主流路径，本质区别在底层 API 的抽象层级。
第一种是MediaRecorder.getMaxAmplitude()，用起来非常简单：MediaRecorder启动后周期性地调用这个静态方法，返回最近一段时间的最大振幅值，范围 0 到 32767。优点是代码量极少，不需要处理 PCM 数据；缺点也很明显：返回的只有峰值没有原始数据，无法做频域分析、无法自定义采样率，而且不同机型上刷新频率不稳定。适合原型验证或者对精度要求不高的应用。
第二种是AudioRecord，直接读取麦克风采集到的 PCM 数据，自己算振幅。以 16 位单声道为例，PCM 数据是一串 short 类型的采样点，取一段窗口内所有采样点的绝对值平均（RMS），就能得到等效音量级别。这种方式虽然代码多一些，但优势是可控性强：采样率、声道数、数据窗口都能自己定，后续还可以基于同一份数据做 FFT 得到频谱信息。如果产品后续要加“波形缩放”“倍速预览”功能，走这条路就不用推翻重写。
我的实现里用了AudioRecord配合固定大小的ShortArray缓冲区。缓冲区大小设置为最小缓冲区的两倍，尽量避免底层数据覆盖导致的丢帧。每读取一次缓冲区，就遍历一遍数据计算 RMS，然后归一化到 0~1 的浮点区间，交给 UI 层去绘制。
2.2 振幅数据的平滑与归一化
原始 RMS 数据的跳动幅度非常大，尤其是安静环境下偶尔冒出的噪声尖峰，直接画到控件上会非常突兀，体验很差。解决办法是加一层平滑滤波。
滤波器有很多种，从最简单的滑动平均到卡尔曼滤波。我用的是指数加权移动平均（EWMA），公式不复杂：
smoothedValue = alpha * newValue + (1 - alpha) * smoothedValuealpha一般取 0.2 到 0.4，取大了跟手但跳动明显，取小了平稳但反应迟钝。实测下来 0.3 左右比较均衡，兼顾了跟随速度和视觉稳定性。
归一化这一步看似简单，但有个容易被忽略的点：不同麦克风的灵敏度差异很大，同一音量下不同机型返回的 RMS 可能差好几倍。如果直接映射到 0~1，有的机器会一直顶满，有的机器几乎看不到波形。我加了一个动态范围校准：记录过去若干秒的最大值，用这个动态最大值做归一化分母，同时限制最小分母避免安静时被放大成噪声。这样一来，无论什么机型，波形都能在屏幕上呈现合理的视觉幅值。
3. 绘制核心：从 Canvas 到动态曲线
3.1 自定义 View 的骨架搭建
整个控件本质是个View的子类，Kotlin 代码结构大致如下：
class WaveformView @JvmOverloads constructor( context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0 ) : View(context, attrs, defStyleAttr) { enum class Mode { BAR, LINE } var mode: Mode = Mode.BAR var barColor: Int = Color.parseColor("#12C2A8") set(value) { field = value; invalidate() } var lineColor: Int = Color.parseColor("#12C2A8") set(value) { field = value; invalidate() } private val amplitudes = ArrayDeque<Float>() private val maxCount = 72 fun addAmplitude(value: Float) { val clamped = value.coerceIn(0f, 1f) if (amplitudes.size >= maxCount) amplitudes.removeFirst() amplitudes.addLast(clamped) invalidate() } override fun onDraw(canvas: Canvas) { super.onDraw(canvas) when (mode) { Mode.BAR -> drawBarWave(canvas) Mode.LINE -> drawLineWave(canvas) } } }addAmplitude是外部调用的入口，录音线程每计算出一次 RMS 就调用一次，内部自动维护数据量不超过maxCount。这个maxCount决定了波形在屏幕上的疏密程度：72 个数据点分布在 1080p 屏幕上，每根柱子大约占 14 像素，视觉密度刚好。
onDraw里根据模式分发绘制逻辑，不同模式用不同的算法。这里我在onDraw里直接分发模式而不是在代码里到处写 if，后面加新模式时只需要新增一个方法，不容易把案情搅乱。
3.2 柱状波形的绘制细节
柱状波形的核心逻辑是把振幅数据映射成等宽矩形。每一根柱子宽度barWidth，间距barSpacing，振幅amplitude对应柱子的高度。需要注意的是 Canvas 的坐标系原点在左上角，y 轴向下，所以柱子顶部坐标要用height - amplitude * maxBarHeight计算。
private fun drawBarWave(canvas: Canvas) { if (amplitudes.isEmpty()) return val width = width.toFloat() val height = height.toFloat() val baseY = height * 0.8f val maxHeight = height * 0.6f val barCount = amplitudes.size val totalSpace = width / barCount val barWidth = totalSpace * 0.6f val paint = Paint().apply { color = barColor isAntiAlias = true style = Paint.Style.FILL } for (i in 0 until barCount) { val left = i * totalSpace + (totalSpace - barWidth) / 2 val amplitude = amplitudes[i] val barHeight = amplitude * maxHeight val right = left + barWidth val top = baseY - barHeight canvas.drawRoundRect(left, top, right, baseY, barWidth / 2, barWidth / 2, paint) } }这里我故意让所有柱子底部对齐在同一个baseY而不是控件底部，主要是为了视觉上更干净。顶部留出 20% 的空间给峰值跳动，底部留出 20% 避免柱子太长显得压迫。drawRoundRect里的圆角半径取柱宽的一半，这样柱子两端呈现半圆效果，比尖锐的直角矩形耐看。
注意我每次onDraw都新建了 Paint 对象，这在 60fps 刷新下会产生大量垃圾对象。实际项目里应该把 Paint 提升为成员变量，只在初始化时配置一次。这是后面要讲到的性能优化点。
3.3 平滑曲线模式的贝塞尔处理
LINE 模式下要画一条通过所有数据点的平滑曲线。如果直接把数据点用Path.moveTo+lineTo连起来，画出来的是一条折线，锯齿感很强。我改用三阶贝塞尔曲线连接相邻数据点，需要为每对相邻点计算控制点。
计算控制点的方法不唯一，我用的思路是先计算相邻两点的斜率，控制点在水平方向上偏离端点一定距离，垂直方向上与端点齐平，这样曲线在端点处切线与斜率一致，整体视觉会很舒展。代码实现如下：
private fun drawLineWave(canvas: Canvas) { if (amplitudes.size < 2) return val path = Path() val step = width.toFloat() / (amplitudes.size - 1) val points = amplitudes.mapIndexed { i, value -> PointF(i * step, height - value * height * 0.8f) } path.moveTo(points[0].x, points[0].y) for (i in 1 until points.size - 1) { val prev = points[i - 1] val curr = points[i] val next = points[i + 1] val cp1x = prev.x + step * 0.5f val cp1y = prev.y val cp2x = curr.x - step * 0.5f val cp2y = curr.y path.cubicTo(cp1x, cp1y, cp2x, cp2y, curr.x, curr.y) } canvas.drawPath(path, linePaint) }这里step是横向间距，根据数据点数量动态计算。控制点 x 方向偏移step * 0.5f，取值太大曲线会过度扭曲，太小又接近折线。实际调参过程中我发现 0.5 倍间距的效果最自然。
如果想让曲线带渐变效果，可以给 Paint 设置LinearGradient着色器，从底部透明到顶部实色，视觉上会有一种从深到浅的呼吸感。这个细节在暗色背景的录音界面上非常出效果。
3.4 刷新机制与性能平衡
数据采集和绘制之间需要一条稳定的刷新链路。录音线程不断的调用addAmplitude，每次调用都会触发invalidate()，而invalidate()只能在主线程调用——这需要确认线程安全。
第一个坑就是线程问题：录音线程是后台线程，不能直接调用invalidate()，必须用postInvalidate()或者把数据更新投递到主线程 Handler。我在实现里统一使用postInvalidate()，它在任意线程调用都是安全的，系统会安排下一次 UI 刷新时执行onDraw。
第二个坑是刷新频率过载。录音线程每次读取缓冲区的速度大约是每秒 50 帧左右，再加上屏幕本身的刷新率 60Hz 或 120Hz，如果每收到一个数据点就刷新一次，会造成无谓的绘制浪费。我做了节流处理：在主线程 Handler 里每 33 毫秒（约 30fps）取一次当前数据快照并触发重绘，人眼在这个帧率下看到的就是流畅动画，却能省下一半的绘制开销。
4. 生命周期与权限：别在细节上翻车
4.1 录音权限的运行时处理
Android 6.0 以上录音权限是危险权限，需要在运行时申请。很多人在这里犯的错误是在onCreate里申请权限之后立刻启动录音线程，但权限弹窗是异步的，用户还没点“允许”，录音就已经启动了，然后抛出异常。
正确的流程应该是：先检查权限，如果没授权就发起申请，然后在onRequestPermissionsResult回调里根据结果启动或提示。这里我封装了一个简单的权限回调接口，避免在 Activity 里堆一堆权限判断逻辑。另外别忘了在 Manifest 里声明<uses-permission android:name="android.permission.RECORD_AUDIO" />，不然运行时申请根本不会弹窗。
4.2 Activity 生命周期与资源释放
音频设备是独占资源，不释放会带来两个后果：一是其他应用无法录音，二是你自己的进程可能被系统直接杀死。我的做法是把录音控制封装在单独的AudioRecorderManager里，在 Activity 的onResume里启动、onPause里停止。这样用户切后台、来电、锁屏时都不会漏掉释放。
录制线程的停止也有讲究，直接调用AudioRecord.stop()之后线程可能还在 read 阻塞中，直接.join()会导致 ANR。我采用标志位加read方法返回异常双保险：设置isRecording = false后调用audioRecord.stop()，阻塞中的read会立即返回异常或 -1，线程循环退出。具体代码片段：
@Volatile private var isRecording = false fun stop() { isRecording = false audioRecord?.stop() thread?.join(500) audioRecord?.release() audioRecord = null }数据消费者那边也要做生命周期处理。WaveformView 在 Activity 销毁时要把 Handler 的回调移除掉，避免消息队列里残留匿名 Handler 引用导致内存泄漏。用onDetachedFromWindow清理是最稳妥的。
5. 踩坑实录：几个我反复遇到的问题
5.1 波形跳变太剧烈，视觉上“炸耳朵”
最开始数据平滑只做了简单的 RMS 计算，结果安静环境下波形频繁跳动到 20% 高度，音量大一点又瞬间顶满。后来发现除了平滑滤波，还需要一个瞬态检测：如果新数据与上一帧值的差值超过某个阈值，就认为是环境噪声或突发音，用较小的权重参与平滑，否则用较大的权重。这套自适应滤波逻辑写完之后，波形肉眼可见地稳定了许多，而且瞬时冲击音（比如拍手）来临时的响应依然很快。
5.2 刷新逻辑影响列表滑动流畅度
当我第一次把控件嵌到 RecyclerView 里的时候，整个列表滑动掉帧严重。分析之后有两个原因：一是每帧都调用了onDraw，而且绘制内容里有较多的对象分配；二是录音线程的postInvalidate会导致 item 在滑动时反复 invalidate。
解决办法是双管齐下：绘制相关的 Paint、Path 全部提到成员变量，避免在onDraw里创建对象；同时加了setWillNotDraw(false)避免 View 在某些场景被判定为不需要绘制而不走onDraw。另外，在 RecyclerView 滚动时我会暂时降低刷新频率到 15fps，滚动结束后恢复 30fps，这个策略在列表复杂时很有效。
5.3 模拟器上没有麦克风输入，怎么调试
Android Studio 模拟器默认不提供虚拟麦克风输入，AudioRecord拿到的全是静音数据，波形一动不动。解决办法有两条路：一是给模拟器插入虚拟音频设备（Android Studio 的 Virtual sensors 面板可以模拟），但实测这条路时灵时不灵；二是在代码里留一个 Mock 数据源，检测到设备是模拟器时自动用正弦波叠加随机噪声生成假振幅数据。这样至少能验证绘制的逻辑正确性，真机联调时再走真实录音。
这个 Mock 数据源还有一个意想不到的用途：UI 预览和演示 Demo 时不需要真机也能展示完整动画效果，给产品看效果非常方便。我建议所有做音频控件的项目都内置这个开关，调试效率能提升一大截。
5.4 波形绘制时的硬件加速问题
Android 默认开启硬件加速，但个别绘制操作在硬件加速下行为会变化。比如在自定义 View 里使用canvas.drawText且字体是自定义 Typeface 时，某些机型上字体会渲染异常。我这个声波控件本身不涉及文字，但在组合进一些带文字的界面时遇到过文本闪烁，排查到最后是因为我在onDraw里频繁创建Paint并修改了字体大小。后来把字体相关的 Paint 提取成常量并提前配置，问题就消失了。
如果遇到硬件加速导致的怪异渲染，可以在 View 或 Activity 上调用setLayerType(View.LAYER_TYPE_SOFTWARE, null)关掉硬件加速排查，但不要全局关闭，会损失性能。这个排查思路对于所有自定义 View 开发者都适用。
做一个这样的声波曲线控件，技术含量并不在某个单独的知识点上，而是把音频采集、数据处理、UI 绘制加上线程调度串起来。哪怕不做成完整库，这套思路也可以直接迁移到各种实时可视化需求上：音频频谱、传感器数据曲线、股票分时图原理都是相通的。我用它给项目省下了一个第三方库的集成成本，产品后续提的“给波形加主题皮肤”“长按波形缩放”这些需求，也都能在当前架构上快速扩展。
本文还有配套的精品资源，点击获取
