简介：面向Android开发者的声波通信实现源码包，聚焦声波编解码、信号调制与收发链路，适合具备基础Android开发经验、希望探索近场声波数据传输技术的读者，也可作为课程设计或毕业设计的参考。包内自带可运行演示，界面与布局资源齐全，导入工程后即可体验实际通信效果。压缩包共三十三个文件，核心逻辑由十一个Java源文件承担，九张PNG图片和五份XML布局负责界面呈现，另有vsd设计图、属性配置文件、依赖库及工程描述文件辅助理解项目结构，整体仅684KB，轻量紧凑。目前已有190人学习下载。通过阅读源码可掌握声波信号从生成、编码到识别解码的完整思路，结合设计文档能快速定位模块关系，为二次开发或功能扩展提供良好起点。 这是一篇关于Android声波通信源码的深度实践博文，直接分享技术原理、核心代码设计和实战踩坑经验。注意理解：这篇文章只讲声波通信的合法技术实现与应用（如室内定位、设备近场配对、离线数据传输等），不涉及任何网络代理、传输加密或越界使用，完全符合安全合规要求。
1. 为什么我选了声波通信这条路：应用场景与选型逻辑
在接触Android声波通信之前，我一直在做蓝牙和Wi-Fi Direct的近场数据传输方案。蓝牙配对流程繁琐，Wi-Fi Direct在部分机型上的兼容性让人头疼，而且两者都需要系统权限申请，在某些定制ROM上甚至会遇到莫名其妙的掉线问题。后来一个做线下活动交互的朋友找到我，说想实现一种"手机碰一碰就能拿到优惠券"的方案，不装App、不连蓝牙、不扫二维码，我当时第一反应就是声波通信——让手机扬声器发出人耳听不见的高频声波，另一台手机的麦克风接收并解出数据。
声波通信的核心价值在于它对硬件零要求。任何一部带扬声器和麦克风的Android手机天生就具备收发条件，不依赖蓝牙芯片的版本、不依赖NFC硬件的存在、不依赖系统的开放权限，只需要申请录音权限即可。这在面对大量杂牌机型、老系统版本时，优势非常明显。实测下来，在10到30厘米的距离内，声波通信的传输成功率能达到95%以上，虽然速率远不如蓝牙（我的实现里有效数据速率大约只有100bps左右），但在传输几十字节的短数据场景下完全够用。
选型的时候我还对比过Light Communication（闪光灯通信）和二维码。闪光灯通信的问题在于需要手机背对背，操作姿势太反人类；二维码的问题在于必须依赖摄像头和屏幕显示，在暗光环境下体验很差。声波通信则没有这些限制，手机放兜里也能收，锁屏状态下麦克风依然可以采集数据，这为后台静默接收创造了条件。
另一个选型理由是技术门槛的友好度。声波通信的物理层本质是调制解调问题，用Android自带的AudioTrack和AudioRecord就能完成信号的发射与采集，不需要额外的硬件依赖。你在源码里不会看到任何第三方SDK，纯Java加上Android框架自带API就能跑通，这意味着一套代码可以长期维护，不受厂商SDK升级的影响。
还有一个很容易被忽略的优势是安全性。Wi-Fi和蓝牙的信号会穿透墙壁，存在被隔壁房间设备截获的风险；而声波走的是空气介质，墙体对高频声波的衰减非常明显，信号天然被限制在一个房间内。虽然这算不上严格意义的加密，但已经提供了很好的物理层隔离效果。
2. 声波通信的底层原理：从频段选择到调制解调
2.1 为什么选择16kHz到20kHz这个频段
人耳的理论听觉范围是20Hz到20kHz，但实际上随着年龄增长、长期戴耳机听歌，大多数人对15kHz以上的声音已经很不敏感了。声波通信要保证"人耳听不见"，最稳妥的选择是让信号尽量避开人耳最敏感的2kHz到6kHz区间，往高频方向走。但是频段不能无限向上推，因为Android手机的扬声器和麦克风的频响曲线在高频段会剧烈衰减，尤其是麦克风，很多机型的有效采集上限就在20kHz出头，再高上去信号幅度会跌到无法识别的程度。
我最终把工作频段定在16kHz到20kHz之间，具体使用了四个频点：16.5kHz、17.5kHz、18.5kHz、19.5kHz。这种四频点方案对应4FSK（四进制频移键控）调制，每个符号携带2比特信息，比用两个频点表示0和1的2FSK方案速率高一倍。
频段选择上踩过最大的坑是扬声器的谐波失真。手机扬声器在播放18kHz信号时，受限于振膜的物理特性，会产生明显的非线性失真，在低频段出现谐波分量。比如播放18.5kHz的正弦波，可能在9.25kHz处产生二次谐波泄漏，这个分量虽然人耳也不敏感，但会和某些环境噪声混淆，干扰接收端的判决。解决办法是在Android的AudioTrack播放链路中不做任何均衡处理，直接播放纯净的PCM正弦波，尽量减少中间处理对波形的影响。
2.2 调制方式对比：为什么不用FFT而用Goertzel
选调制方式时，我最初的想法是模仿无线电通信中的QPSK（正交相移键控），在声波频段内同时调制幅度和相位，把速率做到更高。但实际测试发现空气声信道远比无线电信道恶劣——声波在空气中的传播速度只有每秒340米左右，手机之间的距离一旦超过半米，反射波和直达波之间的时延差就会造成严重的码间干扰，相位判决的稳定性非常差，误码率会飙升到无法接受的程度。
最终方案还是回到频率调制这条路上来。4FSK的好处是它只依赖频率这一个维度，对幅度衰减不敏感，对相位畸变也免疫，这在接收端信号强度忽高忽低的实测环境中特别占优势。室内环境下，墙体反射、桌面反射、甚至人手遮挡都会导致声波幅度剧烈波动，但只要频率特征还在，FSK解调就能正常工作。
接收端的解调算法，我用的是Goertzel算法而非FFT。很多初学者写声波通信第一反应就是抓一段音频数据丢给FFT，看频谱峰值在哪。这个方法在实验室没问题，但放到真机上就露馅了：FFT需要足够多的采样点才能获得频率分辨率，这在实时流处理中意味着更大的延迟和更高的计算量；而且FFT是宽带的，它会把全频段的能量都算一遍，大部分计算浪费在没用的频段上。Goertzel算法则针对性地计算特定频点的能量，每路频点只需要一个二阶递归滤波器就能搞定，计算量只有FFT的几分之一，非常适合Android实时音频流里逐帧检测频点能量。
Goertzel算法的核心思想是，对一串离散采样点，计算它在目标频率处的频谱分量。给定采样率Fs和目标频率f，先算系数k和中间变量omega：
int k = (int) (0.5 + (frameSize * f) / sampleRate); double omega = (2.0 * Math.PI * k) / frameSize; double coeff = 2.0 * Math.cos(omega);然后对每个采样点做递归运算，这就是网上各种"Goertzel源码"里最常见的三段式迭代：
double s0 = 0; double s1 = 0; double s2 = 0; for (int i = 0; i < frameSize; i++) { s0 = pcm[i] + coeff * s1 - s2; s2 = s1; s1 = s0; } double power = s1 * s1 + s2 * s2 - coeff * s1 * s2;这个power就是该频点的能量强度。四个频点各跑一遍Goertzel，比较四个power值，取最大者对应的频点作为当前符号，就完成了4FSK解调。
2.3 符号时长与帧结构的设计权衡
符号时长（每个频点持续的时间）是整个系统里最关键的一个参数。它直接决定了信噪比、传输速率和抗干扰能力。我一开始图快，把符号时长设成5毫秒，对应每秒200符号、400比特的理论速率，但实测误码率惨不忍睹。原因是5毫秒的窗口内，16.5kHz的信号只有82.5个完整周期，Goertzel算法的频率分辨率不足以把相邻频点（间隔1kHz）明显区分开，能量判决经常出错。
后来我把符号时长拉长到20毫秒，对应每秒50符号、100比特的理论速率。20毫秒的窗口内，16.5kHz的信号有330个周期，1kHz的频率间隔在频域上可以清晰分离，实测误码率从5毫秒方案的12%骤降到0.5%以下。这个"速率换可靠性"的取舍是值得的——毕竟声波通信的应用场景都是传输几十到几百字节的短消息，100bps的速率已经能在3秒内传完30个字节。
帧结构的设计同样经历了多次迭代。最初我参考串口通信的帧格式：前导码加数据载荷加CRC校验。后来发现声波信道里最危险的不是随机误码，而是"突发性丢失"——比如接收端突然被一个环境噪声干扰，导致连续几十毫秒的解调输出全是错的。针对这个问题，我在帧层面加入了符号级交织：
| 前导码(4符号) | 帧头(0x7E, 4符号) | 长度字节(4符号) | 数据载荷(若干符号) | CRC16(8符号) | 帧尾(0x81, 4符号) |前导码用固定的频率序列（19.5kHz、18.5kHz、17.5kHz、16.5kHz）让接收端完成频率基准校准和AGC增益对齐。帧头和数据都做了符号映射：一个字节拆成高4位和低4位，分别映射到一个4FSK符号，这样每个字节需要两个符号、40毫秒，加上额外开销，一帧30字节的数据大概需要1.8秒传输时间。
3. 发送端实现：用AudioTrack把数据变成声波
3.1 PCM波形生成与播放参数配置
发送端的核心工作是把二进制的数据流变成一串正弦波的PCM采样值，然后塞给AudioTrack播放。生成正弦波本身很简单，就是标准的sin函数采样。关键在AudioTrack的参数配置上，这里藏着一个最常见的坑：直接用AudioTrack的静态模式（MODE_STATIC）一次性写入所有音频数据，在数据量小的时候没问题，但要发送的内容一旦超过几百毫秒，静态模式就会因为缓冲区分配不足而播放异常甚至直接崩溃。
我的实现里用的是流式模式（MODE_STREAM），配合一个专门的处理线程，边生成PCM数据边往AudioTrack的缓冲区里写。这样无论要发送多长的数据都没问题，内存占用也稳定。
AudioTrack的初始化参数如下：
int sampleRate = 44100; int channelConfig = AudioFormat.CHANNEL_OUT_MONO; int encoding = AudioFormat.ENCODING_PCM_16BIT; int bufferSize = AudioTrack.getMinBufferSize(sampleRate, channelConfig, encoding) * 4; AudioTrack audioTrack = new AudioTrack.Builder() .setAudioSource(MediaRecorder.AudioSource.REMOTE_SUBMIX) .setAudioFormat(new AudioFormat.Builder() .setSampleRate(sampleRate) .setEncoding(encoding) .setChannelMask(channelConfig) .build()) .setBufferSizeInBytes(bufferSize) .setTransferMode(AudioTrack.MODE_STREAM) .build(); audioTrack.play();有一个细节必须强调：AudioTrack的声道配置要用单声道（CHANNEL_OUT_MONO），不要用双声道立体声。原因是立体声会占用双倍的数据量，但对解调没有任何帮助，接收端麦克风采到的是单声道信号，带宽全部浪费了。采样率方面，44.1kHz是Android生态兼容性最好的采样率，几乎所有手机的麦克风和扬声器都原生支持，48kHz虽然更好，但在部分老机型上会触发重采样，反而引入额外噪声。
播放音量上，实测发现音量开到最大（setVolume(1.0f)）反而有时会引入扬声器削波失真，因为某些手机的扬声器在高音量下功率放大器饱和，输出波形被削顶，高频谐波急剧增加。我最终把播放音量设定在0.8左右，配合前导码里的AGC校准，接收端信噪比反而比满音量时更高。
3.2 正弦波生成的平滑过渡防爆音
正弦波生成里有一个非常容易被忽视的细节——符号切换处的波形不连续会产生爆音。如果前一个符号的相位是0度，后一个符号的相位是180度，两个正弦波在切换点直接拼接，波形会出现一个陡峭的跳变，这个跳变在频域上会扩展出很宽的能量分布，不仅人耳能听到咔哒声，还会污染目标频段附近的频谱，干扰接收端的频点能量判决。
解决办法是在每个符号的生成过程中维护一个连续的相位累加器。我维护一个全局phase变量，每生成一个采样点就做一次累加，符号切换的时候phase直接从上一个符号的结束相位继续，而不是从0重新开始：
double phase = 0.0; double phaseIncrement = 2.0 * Math.PI * freq / sampleRate; for (int i = 0; i < samplesPerSymbol; i++) { pcm[i] = (short) (Math.sin(phase) * amplitude); phase += phaseIncrement; if (phase > 2.0 * Math.PI) { phase -= 2.0 * Math.PI; } }这样每个符号的起始相位和上一个符号的结束相位保持连续，波形不存在突变，爆音问题从根源上消除。实际听感对比非常明显：用相位连续方案后，即使把耳朵贴近扬声器，也很难察觉到高频信号的存在。
生成PCM数据时还有一个优化点：预先计算好四个频点的相位增量，每次发送时根据当前符号对应的频点直接取用对应的增量，避免每次重复计算三角函数。Android设备的CPU性能参差不齐，这类微优化在低端机上能明显降低音频欠载（underrun）的概率。
3.3 发送状态机与数据分包
发送端的整体逻辑可以抽象成一个小型状态机：空闲、发送前导码、发送帧头、发送长度、发送数据、发送CRC、发送帧尾、等待完成。每个状态负责处理自己对应的符号序列，状态机的驱动由AudioTrack的播放进度回调来控制。
这里我建议用AudioTrack的setPlaybackPositionUpdateListener来做进度回调，这样能保证发送节奏和实际播放进度同步，避免发太快导致缓冲区溢出、发太慢导致播放中断。实测中，由于我用了MODE_STREAM且bufferSize是minBufferSize的四倍，回调频率足以支撑每秒50符号的发送速度。
对长数据的处理上，我坚持单帧不超过64字节的设计。超过64字节的应用层数据必须先分包，逐帧发送，帧与帧之间间隔100毫秒给接收端腾出处理时间。这个设计的出发点是音频信道不稳定的特性——一帧传太久，中途遇到瞬时噪声的概率越大，整帧报废的概率也越大。64字节一帧、1.8秒一帧的粒度，配合接收端的帧重传机制，实际链路已经足够可靠。
4. 接收端实现：从麦克风采集到协议解析
4.1 AudioRecord采集参数与噪声抑制的取舍
接收端使用AudioRecord从麦克风采集音频流。与发送端不同，这里的配置有几个必须注意的地方。音频源必须用MediaRecorder.AudioSource.MIC而不是VOICE_RECOGNITION，虽然VOICE_RECOGNITION在部分手机上会启用降噪处理，但不同厂商对VOICE_RECOGNITION的实现差异巨大，有的机型会对20kHz以上的信号做硬切，直接废掉我用的高频段。MIC源反而是最"原始"的，不做多余处理。
采样率方面，接收端同样使用44.1kHz，但读取缓冲区不能设得太小。我实测发现，读取缓冲区设成2048个采样点（约46.4毫秒）是个比较合适的值，既能保证足够低的处理延迟，又不会因为缓冲区过小导致频繁的线程调度开销。
Android的音频采集有个鲜为人知的坑——麦克风自动增益控制（AGC）。在部分机型上，当环境声音较大时，AGC会自动压低整体增益；当环境安静时，AGC又会过度放大底噪。对于声波通信这种远距离传输、接收信号本身就很微弱的场景，AGC的波动会严重干扰频点能量判决。虽然从API层面无法直接关闭AGC，但可以通过设计上的手段规避：在接收端统计前导码中四个频点的整体能量水平，动态调整Goertzel判决的阈值，相当于在软件层面做一次AGC补偿，抵消硬件AGC带来的影响。
4.2 实时Goertzel扫描与滑动窗同步
接收端的核心循环是一个死循环线程：从AudioRecord读取PCM数据块，对每块数据跑四路Goertzel，得到四个能量值，比较大小得出符号，滑动窗口移动一位继续。这个"滑动"操作在实现上有两种选择：一是每次读完一个完整块（2048个采样点）就跑一次Goertzel，相当于每隔46.4毫秒解调出一个符号，但这种做法和20毫秒的符号时长对不上，会出现符号边界对不齐的问题；二是维护一个更大的环形缓冲区，每次只滑动10毫秒的数据量，在缓冲区上跑Goertzel。
我采用的是滑动窗方案，窗口大小为20毫秒（对应882个采样点），滑动步长为10毫秒（对应441个采样点）。每个窗口与上一个窗口有50%的重叠，这样既能保证符号边界必定落在某个窗口内，又能通过前后两个窗口的判决结果做"双判一致"的增强——如果连续两个窗口解调出同一个符号，才认为这个符号可靠。双判机制让误码率又下降了一个数量级。
窗口滑动带来的计算量是Goertzel算法相比FFT的优势得以充分发挥的地方。四路频点、每路窗口882个采样点、每秒执行100次扫描，总计算量大约只有每秒35万次乘加运算，在任意一台Android设备上都是微不足道的负载，实时性完全有保障。
4.3 帧同步与CRC校验的容错设计
帧同步是一开始让我最头疼的问题。直接做法是接收端持续解调符号流，然后在符号流里寻找帧头（0x7E）对应的符号模式。但声波信道的不稳定性会导致符号错位、插入、丢失，一旦发生插入或丢失错误，后面所有的符号都会错位，帧头永远对不上。
我的方案是在符号流上同时维护三个尺度的检测：符号级检测（匹配4个连续的前导码符号）、字节级检测（把相邻符号拼成字节后匹配0x7E和0x81）、帧级检测（用长度字段推算出帧结尾位置，校验CRC16）。三个尺度同时判断，只有当三者的预期位置互相吻合时，才判定为同步成功。这套机制虽然实现起来多写了不少代码，但在实测中扛住了大部分环境干扰。
CRC16的生成多项式我用了0x1021（标准CRC-CCITT），在Java里手写了一个查表法实现。查表法的执行效率远高于逐位计算，对每帧数据的校验耗时几乎可以忽略。帧校验失败时不立即丢弃整帧，而是保留数据内容并标记为"可疑帧"，如果后续100毫秒内收到包含相同数据内容的重传帧，就以重传帧为准。这个"宽进严出"的策略显著提升了弱信号场景下的吞吐量。
5. 源码调试与真机适配：那些不跑真机根本发现不了的坑
5.1 不同机型扬声器/麦克风的高频响应差异
这个坑直接决定了你的声波通信方案能不能在真实环境中商用。我手头有一批测试机，从高通骁龙旗舰到联发科低端芯片都有。实测中发现，旗舰机的高频响应普遍较好，16kHz到19.5kHz的信号衰减在可接受范围内；但低端机上出现了一个诡异的现象：某些机型在播放18.5kHz和19.5kHz信号时，麦克风采集到的能量非常弱，而播放16.5kHz和17.5kHz却正常。进一步分析后确认，是低端机的麦克风振膜尺寸大、惯性大，对高频的响应本来就差，再加上部分机型的外壳密封不严，高频声波在空气中传播就衰减得厉害。
应对策略是做"频点自适应"。发送端在发送前导码时，会依次发送四个频点各50毫秒的测试音，接收端统计四个频点的接收能量，然后回传给发送端。发送端根据回传信息动态调整有效频点集合：如果19.5kHz频点的接收能量过低，就动态降级为3FSK，只用前三路频点，每个符号仍然携带log2(3)约1.58比特信息，虽然速率略降，但保证了链路的可用性。
5.2 环境噪声干扰与误码率的实测数据对比
我在不同环境下做了一组对比测试，数据最能说明问题：
| 测试环境 | 符号时长20ms误码率 | 符号时长10ms误码率 | 备注 |
|---|---|---|---|
| 安静办公室 | 0.08% | 0.9% | 距离15cm |
| 商场环境 | 1.2% | 6.8% | 背景音乐+人声 |
| 室外街道 | 3.5% | 15.2% | 车流噪声为主 |
| 地铁车厢 | 8.7% | 27.4% | 高频噪声密集 |
地铁车厢的数据让我印象极深。原本以为低频的轨道噪声、电机噪声对16kHz以上频段影响不大，实际测试才发现，地铁车厢里的高频噪声成分非常丰富，可能是金属轮轨摩擦、刹车盘振动等产生的高频泛音，正好落在我的工作频段里。这种情况下，仅靠频点能量大小判决已经不够了，我再加上了一道"信噪比门限"——当四个频点的总能量低于某个绝对门限时，判定当前符号不可靠，直接标记为擦除符号而不是强行判决。擦除符号在后续的帧校验环节可以通过CRC发现错误，配合重传机制来兜底。
5.3 系统音频路由和免提模式的特殊处理
这个坑来自一个很隐蔽的Android系统行为。在使用AudioTrack播放时，如果系统当前的音频路由走到了"听筒"（earpiece）而不是"扬声器"（speaker），声波信号会从听筒方向发出，而听筒的指向性很强，面对面手持时信号才能被正常接收，手机平放在桌面上时信号就几乎传不出去。必须在播放前强制设置音频路由，在源码里通过AudioManager的setSpeakerphoneOn(true)把声音强制切到扬声器：
AudioManager audioManager = (AudioManager) context.getSystemService(Context.AUDIO_SERVICE); audioManager.setSpeakerphoneOn(true); audioManager.setMode(AudioManager.MODE_NORMAL);另一个坑是部分手机在通话状态下会强制走通话音频通道，这个通道默认启用降噪和回声消除，会把高频信号当作噪声滤除。发送端在开始播放前应该检测当前的通话状态，如果处于通话中，应该提示用户挂断通话再进行声波传输。接收端同理，在采集前也要检查是否处于通话状态，避免采到的是降噪处理后的音频流。
5.4 调试工具的取舍：日志驱动问题定位
调声波通信这种既涉及信号处理又牵涉Android系统的项目，调试手段和普通App开发完全不同。你不能只在Android Studio的Logcat里看Log，因为Logcat无法反映音频波形和频谱的细节。我个人的标配调试工具箱是：首先在接收端把解调过程中的频点能量数组以定点数形式打到Logcat里，然后用一个PC端的Python脚本监听Logcat，把能量值实时画成曲线图，这样能直观看到符号判决的每一步变化。
对于更底层的波形细节，我会在接收端加一个"录音导出"开关，把采集到的PCM数据直接写入文件，拉到PC上用Audacity打开分析。这个方法帮我定位了大量疑难杂症，最有价值的一次是发现某台测试机的麦克风在16kHz到17kHz之间存在一个明显的窄带凹陷，如果不是看到原始频谱，光靠能量日志根本猜不到是麦克风的物理特性问题。
信号质量好坏的快速判断，我的经验是通过Logcat观察前导码阶段的AGC增益值。如果前导码阶段算出的增益值长期处于上限或下限，说明当前环境的声波信号或者太强导致限幅，或者太弱导致底噪淹没信号，无论哪种情况，后面解调出正确数据的概率都极低。
6. 性能优化与可靠性增强：从能跑到能用的关键打磨
6.1 发送前长度协商与自适应重传
声波通信的带宽极其宝贵，在协议设计上不能有丝毫浪费。我在帧结构里加入了"长度协商"字段，发送端在正式发送数据前，先发一个很小的信令帧，告诉接收端即将发送的数据块长度、需要确认的帧数。接收端根据当前信噪比估算出一个建议的符号时长（20ms、25ms或30ms），通过反向声波（用接收端自己的扬声器发一个短音）回传给发送端。发送端在接下来的一整块数据传输中使用协商好的符号时长。
这个协商机制听起来增加了一轮往返时间，但对于传输多个帧的场景，节省下来的重传时间远超协商开销。弱信号环境下，符号时长从20ms切换到30ms，误码率可以降低10倍以上，代价只是速率下降三分之一，这笔账怎么算都划算。
重传策略上，我用的是最简单也最有效的"整体重传"而非"选择性重传"。因为声波信道错误多是突发性的，一帧出错往往意味着连续几帧都错，选择性重传的反馈开销反而比整体重传更大。实测中，整体重传配合接收端的去重缓存，在弱信号环境下的有效吞吐甚至高于理论速率一半的传输方案。
6.2 省电策略：间歇性监听与唤醒机制
声波通信的接收端可能需要长时间开启麦克风监听，这对电量是个不小的考验。我的方案是引入"间歇性监听"：接收端每500毫秒醒来一次，用30毫秒时间采集一帧音频，快速检测是否有前导码特征。如果检测不到前导码，立即进入休眠；一旦检测到前导码，就切换到连续监听模式，直到一帧完整接收完毕。这套机制让接收端的平均功耗降低了大约七成。
前导码检测本身也是经过优化的。我没有用完整的四路Goertzel做全频段扫描，而是只检测19.5kHz这一路频点的能量是否超过环境底噪的某个倍数。前导码的第一个符号固定用19.5kHz，这一路能量出现异常抬升，就是"可能是前导码"的强信号特征。确认后再切换到四路完整解调，精确匹配前导码序列。这招把这个边缘场景的功耗压到了很低。
6.3 自适应音量与频谱整形
发送端的自适应音量控制是个很容易弄巧成拙的功能。最初我天真地认为音量越高越好，实测打脸后发现，部分手机的功放在高音量时会触发DSP的限幅保护，反而让高频部分的输出功率不升反降。后来改成了"多级音量回退"策略：以0.8音量开始发送，如果接收端反馈的信噪比低于阈值，就尝试0.9音量，再不行就1.0音量，同时接收端动态调整判决门限来适配。这个策略在几十台真机上测试下来，成功率比固定音量方案提升了约15%。
频谱整形方面，我做过一个实验性的尝试——对发射信号施加一个与扬声器频响相反的高频预加重，相当于把扬声器衰减最严重的频段额外放大。这个思路理论上完美，实际实现上却碰到一个难题：不同机型的频响曲线差异太大，同一份预加重参数在这个机型上有效，在另一个机型上反而会过载失真。最终还是回到自适应的路子上，让接收端在协商阶段顺带测量四个频点的响应差异，把这个差异量化成4个调整系数回传给发送端，发送端按系数对四个频点的幅度做归一化。这一招把高端机和低端机的接收成功率差距缩短了一半。
7. 后续还能怎么玩：声波通信的扩展方向
声波通信这套源码打磨到现在，已经在我自己的几个项目里稳定跑了大半年。除了最基础的设备间短消息传输，我还实验了三个有意思的方向。第一个是室内定位，利用多个手机扬声器在不同位置同时发出正交频分的声波信号，接收端根据各路信号的到达时间和能量比，可以粗略推算自己在这个房间里的相对位置。实测精度大约在50厘米左右，虽然比不上UWB，但在完全不需要额外硬件的条件下，这个精度已经很有吸引力了。
第二个方向是声波配网。智能硬件设备通常没有屏幕和键盘，传统配网要靠手机蓝牙或热点中转，步骤繁琐。用声波通信，手机把Wi-Fi SSID和密码编码成声波，智能硬件自带的麦克风直接接收并解出配网信息，整个过程两三秒完成。这个方向在物联网领域有很强的实用价值，不过需要硬件端也集成这套调制解调算法。
第三个方向是声波签到和门票验证。在演唱会、展会等场景中，把签到码或票据验证信息编码进一段几秒钟的声波里，在入口处循环播放，参与者打开App就能自动接收到验证信息。这种场景对传输速率要求不高，但对兼容性和容错性要求极高，正是这套源码最擅长应对的领域。
我建议想深入玩这个方向的开发者，先不要急着写界面，把发送端的状态机和接收端的同步逻辑吃透，再在真机上跑通一条从发送到接收的完整链路，之后所有上层应用都是水到渠成的事。声波通信是个非常"低科技"但又很有创造空间的方向，值得耐心打磨。
本文还有配套的精品资源，点击获取
