简介面向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和中间变量omegaint 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就能自动接收到验证信息。这种场景对传输速率要求不高但对兼容性和容错性要求极高正是这套源码最擅长应对的领域。我建议想深入玩这个方向的开发者先不要急着写界面把发送端的状态机和接收端的同步逻辑吃透再在真机上跑通一条从发送到接收的完整链路之后所有上层应用都是水到渠成的事。声波通信是个非常低科技但又很有创造空间的方向值得耐心打磨。本文还有配套的精品资源点击获取