1. 内置声音永远不够用我决定让白噪音App支持自定义音频先说个很实际的场景我做了个白噪音软件最初版本内置了雨声、海浪、篝火、风扇声这些常见音源。测试阶段用着还行可一旦真把App丢给家人朋友用问题立刻就来了。有人嫌雨声不够真实有人说海浪声太单调还有一个朋友直接问我“能不能把我自己录的鸟叫声加进去”我当时愣了。对啊白噪音这件事本质上是非常主观的。你觉得雨声助眠别人可能更喜欢风扇转动的低频轰鸣你爱听咖啡馆里的人声嘈杂有人却只对自家阳台上的风声有感觉。内置音源做得再多也只能覆盖大众场景没法照顾每个人的听觉偏好和生活记忆。所以这版更新我做了个决定让软件支持用户自己添加音频文件。最开始以为这是个特别简单的功能无非就是开放一个文件选择入口把选中的音频加进列表播放。真动手做起来才发现牵扯到格式兼容、文件导入权限、播放引擎的无缝循环处理、甚至后台播放和系统音频焦点冲突一个比一个磨人。这篇东西就当作一个完整的开发记录和经验分享。内容覆盖自定义音频从“选择文件”到“稳定播放”这条完整链路涉及Android和iOS通用的逻辑思路也包含具体格式参数、循环播放的技术实现以及在实测中我踩过的几个大坑。正在做音频类应用、或者想给现有的播放器增加自定义音源功能的朋友这篇文章应该能帮你省下不少试错时间。2. 格式选型与导入链路先把“文件能不能进来”这件事想清楚2.1 支持哪几种格式为什么不是越多越好第一版我直接贪多把系统解码器支持的几乎所有格式都放开了MP3、WAV、FLAC、AAC、M4A、OGG甚至MIDI都试过。实测下来发现贪多真的不是好事。格式越多边界情况越难处理有些编码格式在部分机型上解码不稳定听一半突然卡住体验非常糟糕。最终我收敛到了四种核心格式格式编码方式适用场景说明MP3有损压缩大多数用户下载的音频兼容性最好缺点是高码率下体积偏大WAV无压缩用户自己录音的首选质量最高体积大适合短片段FLAC无损压缩追求音质的用户体积比WAV小解码要求稍高M4A/AAC有损压缩iPhone/iPad用户常见格式苹果生态兼容性好码率效率高为什么把OGG砍掉因为它在Android端的兼容性远好于iOS端iOS原生支持有限用了反而容易出问题。MIDI更不用提它是指令序列不是真正的音频流播放逻辑完全不一样硬要支持的话整个播放引擎都得单独做一套不值当。这里要特别提醒一点WAV格式也不是全都一样的。WAV只是一个容器里面的编码可能是PCM也可能是ADPCM甚至可能是MP3。我的做法是只认PCM编码的WAV文件判断方式也简单解析文件头里的音频编码标识字段不是PCM就直接提示用户转格式。如果你正在做类似功能建议在导入阶段就做好这层校验别等到播放的时候才报错用户根本看不懂什么解码错误之类的东西。2.2 本地文件的导入流程从选择器到权限处理格式定下来了接下来是导入链路。这里分两端说。Android端现代的推荐做法是用系统自带的文件选择器ACTION_OPEN_DOCUMENT而不是直接拿存储权限去扫全盘。这个区别非常重要。直接用存储权限意味着你要申请READ_EXTERNAL_STORAGE或MANAGE_EXTERNAL_STORAGE权限前者在Android 13以后基本不管用了后者在应用商店审核时会被重点询问用途很麻烦。ACTION_OPEN_DOCUMENT的好处是用户自己在系统文件管理器里挑文件你的App只拿到一个文件访问URI不需要申请全局存储权限。代码上核心就几行逻辑// Android端使用OpenDocument方式选择音频文件 Intent intent new Intent(Intent.ACTION_OPEN_DOCUMENT); intent.addCategory(Intent.CATEGORY_OPENABLE); intent.setType(audio/*); intent.putExtra(Intent.EXTRA_MIME_TYPES, new String[]{audio/mpeg, audio/wav, audio/flac, audio/mp4}); // 允许用户多选 intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true); startActivityForResult(intent, REQUEST_CODE_PICK_AUDIO);选完之后别忘了最重要的一步持久化URI权限。因为ACTION_OPEN_DOCUMENT拿到的URI是一次性的不执行takePersistableUriPermissionApp下次重启就访问不到这个文件了。这个坑我第一版没注意用户重启软件之后发现添加的音频全部消失排查了好久才想起来是权限没持久化。iOS端用的是UIDocumentPickerViewController选择之后需要把文件拷贝到App的Documents或Library目录下。因为iOS的沙盒机制不允许直接访问系统文件管理器的原文件只能做拷贝。这里要注意在app支持“文件”App之后用户体验通常没问题但大文件拷贝耗时较长。我实测一个50MB的FLAC文件在手机上拷贝要将近两秒所以最好在UI上给一个进度反馈不然用户会以为卡死了。2.3 文件元数据读取与列表展示文件导入成功只是第一步列表展示是用户直接感知的部分。很多开发新手会忽视一个细节音频文件本身自带元数据比如标题、艺术家、专辑、封面图。如果你的白噪音列表里显示的是“audio_20240101_2330.m4a”这种裸文件名用户根本分不清哪个是哪个。我用的方案是读取ID3标签。Android和iOS都有对应的媒体库API可以解析文件头信息。如果解析不到有效标题就回退到文件主名再把扩展名去掉展示。对于封面图能拿到就用拿不到就用一个默认的音频图标代替不要让UI因为这事情出空白。排序逻辑上也做了点优化。默认按最近导入时间倒序排列用户新加的文件永远出现在最上面。同时支持用户手动拖拽排序和重命名毕竟有人喜欢把自己的录音叫“雨夜”而不是“录音_20240520_213000”。3. 无缝循环与淡入淡出自定义音频能稳定播放的核心3.1 为什么白噪音必须做无缝循环白噪音的使用场景大家都懂睡觉、学习、冥想一听就是几个小时。但这世上没几个音频文件的时长能撑一整晚所以循环播放就成了刚需。而且这个循环有一点特殊要求不能有停顿。普通音乐播放器在单曲循环时结尾到开头之间会有几十毫秒到几百毫秒的间隙听歌时不觉得怎样白噪音一停下就会特别突兀睡到一半雷雨声戛然而止人直接就醒了。要解决这个间隙第一版我想得比较简单直接把MediaPlayer的looping属性设为true让它自己循环。实测被现实狠狠教育了。MediaPlayer循环时底层解码器重新seek到音频开头大部分设备上这个seek过程会带来几十到几百毫秒的静音或者“咔哒”爆音。对于人声歌曲勉强能接受对白噪音来说完全不行。3.2 交叉淡入淡出不完美的循环也可以很丝滑最后我采用的方案不是去追求底层“零间隔”而是用交叉淡入淡出来掩盖这个问题。原理说白了很实在在音频快结束时提前200~300毫秒开始衰减音量同时把音频开头的同一段时间音量从零拉升起来让“结尾”和“开头”叠在一起混音输出。这样即使存在微小间隔也被音量变化特征掩盖了。技术实现上有两条路一条是用音频引擎层处理比如Android的SoundPool它比较适合短音频循环对长音频支持有限而且对FLAC这类格式兼容性一般更适合轻量应用。另一条是我最终采用的用ExoPlayer或Media3的自定义渲染器做处理。做法是维护一个环形缓冲区解码线程持续解码数据写入播放线程按固定时间间隔从缓冲区读取。在预判到即将到达文件末尾时提前解码文件头部的数据到缓冲区这样从尾部过渡到头部时底层数据流其实一直是连续的。音频文件能不能实现真正的无缝循环关键就在“缓冲区里有没有提前塞入头部数据”这件事上。实际处理时你可以这样简化处理把音频文件的前500毫秒数据预加载到内存里在距结尾500毫秒的位置准备切换。注意要做音量渐变我实测下来交叉淡入淡出的重叠区间在300毫秒左右最舒服。太短了藤刚度不够依然能听到“咔哒”太长了能感觉到音量起伏反而不自然。3.3 多轨道混音自定义音频和内置音频同时播放还有一个需求在开发中被反复提起用户想把自己录的雨声和App内置的雷声叠加在一起组合出“雷雨交加的夜晚”效果。这就涉及多轨道混音了。这里我犯过一个错误最初想着同时创建多个播放器实例各播各的谁料它们各自的时钟漂移导致拍子对不上雷声和雨声节律错位听着极其难受。正确做法是把所有音轨扔进同一个混音进程让它们共享同一个播放时钟。技术上我用的是Media3的AudioProcessor管道把每条音轨的解码输出喂给混音处理器在PCM层面做加法混合然后统一交给AudioTrack输出。每条音轨独立控制音量、静音开关和循环开关。这样不仅时钟统一音量控制也更精确。如果你用的是iOS平台对应的方案是AVAudioEngine同样是多条AVAudioPlayerNode接入同一个主混音器节点mainMixerNode通过它统一输出。这个思路是一致的客户端混音必须共用一个时钟源。4. 从“能放出来”到“放得舒服”实测中踩过的几个实质性坑4.1 音频焦点冲突一打开别的App白噪音就停了这是试玩版用户反馈最多的一个问题。很多人习惯开着白噪音软件再切到微信刷朋友圈或者看短视频结果白噪音马上就停了。原因是新启动的App会向系统申请音频焦点把原有的播放会话给“抢走”了。处理方式分两层。第一层把App的播放属性设置为长音频播放类别向系统声明这个App适合持续混音播放。Android上用AudioAttributes的CONTENT_TYPE_MUSIC配USAGE_MEDIA同时给Media3的PlaybackParameters设置handleAudioBecomingNoisy(false)意思是不要因为音频焦点丢失就直接暂停整个播放。在iOS端则是配置AVAudioSession的category为.playback并且把options设为.mixWithOthers这样自己的声音就能和其他App共存了。第二层是焦点处理回调。当检测到其他App请求音频焦点时我们可以选择主动降低白噪音音量而不是直接暂停。这在实际体验中会好很多用户只是切换了一下看个信息声音压低一点但没断回来之后自动恢复。4.2 大文件解析启动慢进度条卡了几秒有用户导入了三个小时长度的航班飞行录音app在点击播放之后界面卡住好几秒没反应。问题出在解码器初始化时要扫描整个文件的索引结构文件越大时间越长。优化方向有两个。一是在导入阶段就在后台完成媒体信息提取存进数据库而不是每次进播放页才现解析二是播放前做一次轻量seek测试把需要的关键帧位置缓存下来下次播放直接跳过解析。另外对大文件建议在代码里添加文件大小入参判断超过一定阈值比如300MB就不允许导入。白噪音源文件不需要那么长真要长时间播放靠循环就够了。3.5小时无损文件放在手机里纯属浪费空间没必要硬抗。4.3 循环接缝处“咔哒”声不是调接口能解决的前面说的交叉淡入淡出方案在绝大多数音频文件上表现良好但我遇到一类文件无论如何都能听到固定的咔哒声最终定位到文件本身的原因源文件头部一开头就有音量突变的爆音。这类文件在循环到开头的时候即使做了淡入从所谓“无声”掩盖到真实音频的爆音本质并不会真正消失。解法是在导入时做一次音频分析扫描开头和结尾各几毫秒的波形如果首尾波形相位差很大就把尾部最后几毫秒裁掉或者用极短的时间包络做一次强制归零。这部分我用的是开源库ffmpeg的silenceremove过滤器思路但实际代码里自己写了简单的PCM采样处理逻辑只对首尾操作不影响中间完整内容。4.4 文件被用户移动或删除后播放器直接崩溃还有一个很常遇到但容易被忽略的问题用户添加文件后又在系统文件管理器里把原文件删了App再次尝试播放时直接抛异常。虽然Android的ACTION_OPEN_DOCUMENT在文件被删除后一般会拿到一个不存在的URI但iOS上拷贝到App沙盒内的副本不会受影响——Android这边还是要做异常兜底。现在的做法是播放统一经过一个中间层每次播放前先判断URI是否可用不可用就自动从列表中移除并提示用户文件失效。这种“先判断再播放”的机制用不了多少代码但对体验的提升非常大。5. 录音质量与文件准备建议用户怎么录效果才最接近白噪音5.1 录制自己的“专属白噪音”讲究哪些条件功能上线后我收到几个录音文件有些效果很好有些完全没法用。后来总结了一下好的录音和不好的录音之间差距都出在基础设备条件上。想录一段能当白噪音用的雨声或风声不需要专业麦克风但环境和稳定性是关键。建议找一个安静的房间打开窗户让环境声均匀地传进来手机固定在一个位置不要手持。手持录音最大的问题不是拾音质量而是移动时引起的摩擦声和音量起伏这些细微的不稳定在长时间播放时会变成明显的“情绪波动”。保证录音连续30分钟以上中间不要停断。白噪音应用侧会循环播放所以其实一分钟的音频也能循环但30分钟的录音在“内容丰富度”上要自然很多每一阵风和每一阵雨都有自己的变化。5.2 文件长度、码率和声道选择直接影响耳朵舒服度给用户的准备建议里我通常会包含一条简单的规格清单参数推荐值原因时长10分钟以上太短会导致循环频率过高容易察觉采样率44.1kHz及以上低于这个值高频明显缺失码率192kbps以上MP3低于这个值压缩痕迹明显声音发闷文件格式WAVPCM或FLAC优先无损格式用于白噪音理论上更稳声道立体声营造空间感听感更好声道这里多啰嗦一句有些用户会拿手机默认的“单声道录音”去录雨声回放时声音“贴”在脑门中间空间感全无。如果手机录音设置里有立体声选项建议优先开启如果已经录成了单声道还有一个解决办法是在App播放器内部做伪立体声扩展把单声道信号做一点延迟和滤波后分到左右声道效果比纯单声道好一点但说实话不如原始立体声自然。5.3 用户换机或清理缓存后自定音频该怎么保住自定义音频最怕的就是换机迁移或者手机清理App缓存的时候把文件全清了。这部分我在产品上做了个导出能力用户的自定义音频列表支持生成导出记录记录里包含所有文件的引用信息。换新手机后先把原始音频文件传到新手机再从记录里重新导入就行。当然这个方案需要用户有意识地手动操作在解释成本上相对较高。如果你在做同类功能一个更省心考虑是在云盘服务里做自动备份白噪音文件的体积都不大一个月备份一次也没多大成本。6. 给功能收尾的几点总结以及我对“添加自己的声音”这件事的重新理解这版功能做完之后我自己养成了一个新的习惯出门旅行的时候遇到好的自然声环境会掏出手机安静地录十分钟。以前都觉得白噪音是App里那些现成的声音现在反倒觉得由自己记录下来的环境声才是真正让这个功能发挥价值的场景——白噪音的核心意义在于自由定义环境而不是按开发者预设的模板运行。在文件管理设计上我建议把自定义列表和内置列表做得界限分明。我的处理方法是内置列表用圆圆的悠闲风格图标展示自定义列表直接显示文件名和格式标签。这样用户在混搭使用时能一眼看出哪些是自带的哪些是自己的层级关系清晰返工成本也低。再想到开发过程中的几个具体教训简单留个备忘录在这里也在前面各节里展开过文件权限持久化不能省音频焦点要处理好“共存”而不是“抢占”大文件导入必须异步处理循环播放的核心是缓冲区预加载和交叉淡化一起用。代码量不大但每一个坑都是拿用户的真实反馈换出来的。如果你也正在做类似的自定义音源功能或者只是在自己的项目里想加一个“导入自己的声音”的能力可以多留意上面提到的这些点。它们决定的不只是“功能能不能跑起来”而是“用户愿不愿意每天都打开这个App”。 白噪音App自定义音频功能开发：从文件导入到无缝循环的完整实践
1. 内置声音永远不够用我决定让白噪音App支持自定义音频先说个很实际的场景我做了个白噪音软件最初版本内置了雨声、海浪、篝火、风扇声这些常见音源。测试阶段用着还行可一旦真把App丢给家人朋友用问题立刻就来了。有人嫌雨声不够真实有人说海浪声太单调还有一个朋友直接问我“能不能把我自己录的鸟叫声加进去”我当时愣了。对啊白噪音这件事本质上是非常主观的。你觉得雨声助眠别人可能更喜欢风扇转动的低频轰鸣你爱听咖啡馆里的人声嘈杂有人却只对自家阳台上的风声有感觉。内置音源做得再多也只能覆盖大众场景没法照顾每个人的听觉偏好和生活记忆。所以这版更新我做了个决定让软件支持用户自己添加音频文件。最开始以为这是个特别简单的功能无非就是开放一个文件选择入口把选中的音频加进列表播放。真动手做起来才发现牵扯到格式兼容、文件导入权限、播放引擎的无缝循环处理、甚至后台播放和系统音频焦点冲突一个比一个磨人。这篇东西就当作一个完整的开发记录和经验分享。内容覆盖自定义音频从“选择文件”到“稳定播放”这条完整链路涉及Android和iOS通用的逻辑思路也包含具体格式参数、循环播放的技术实现以及在实测中我踩过的几个大坑。正在做音频类应用、或者想给现有的播放器增加自定义音源功能的朋友这篇文章应该能帮你省下不少试错时间。2. 格式选型与导入链路先把“文件能不能进来”这件事想清楚2.1 支持哪几种格式为什么不是越多越好第一版我直接贪多把系统解码器支持的几乎所有格式都放开了MP3、WAV、FLAC、AAC、M4A、OGG甚至MIDI都试过。实测下来发现贪多真的不是好事。格式越多边界情况越难处理有些编码格式在部分机型上解码不稳定听一半突然卡住体验非常糟糕。最终我收敛到了四种核心格式格式编码方式适用场景说明MP3有损压缩大多数用户下载的音频兼容性最好缺点是高码率下体积偏大WAV无压缩用户自己录音的首选质量最高体积大适合短片段FLAC无损压缩追求音质的用户体积比WAV小解码要求稍高M4A/AAC有损压缩iPhone/iPad用户常见格式苹果生态兼容性好码率效率高为什么把OGG砍掉因为它在Android端的兼容性远好于iOS端iOS原生支持有限用了反而容易出问题。MIDI更不用提它是指令序列不是真正的音频流播放逻辑完全不一样硬要支持的话整个播放引擎都得单独做一套不值当。这里要特别提醒一点WAV格式也不是全都一样的。WAV只是一个容器里面的编码可能是PCM也可能是ADPCM甚至可能是MP3。我的做法是只认PCM编码的WAV文件判断方式也简单解析文件头里的音频编码标识字段不是PCM就直接提示用户转格式。如果你正在做类似功能建议在导入阶段就做好这层校验别等到播放的时候才报错用户根本看不懂什么解码错误之类的东西。2.2 本地文件的导入流程从选择器到权限处理格式定下来了接下来是导入链路。这里分两端说。Android端现代的推荐做法是用系统自带的文件选择器ACTION_OPEN_DOCUMENT而不是直接拿存储权限去扫全盘。这个区别非常重要。直接用存储权限意味着你要申请READ_EXTERNAL_STORAGE或MANAGE_EXTERNAL_STORAGE权限前者在Android 13以后基本不管用了后者在应用商店审核时会被重点询问用途很麻烦。ACTION_OPEN_DOCUMENT的好处是用户自己在系统文件管理器里挑文件你的App只拿到一个文件访问URI不需要申请全局存储权限。代码上核心就几行逻辑// Android端使用OpenDocument方式选择音频文件 Intent intent new Intent(Intent.ACTION_OPEN_DOCUMENT); intent.addCategory(Intent.CATEGORY_OPENABLE); intent.setType(audio/*); intent.putExtra(Intent.EXTRA_MIME_TYPES, new String[]{audio/mpeg, audio/wav, audio/flac, audio/mp4}); // 允许用户多选 intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true); startActivityForResult(intent, REQUEST_CODE_PICK_AUDIO);选完之后别忘了最重要的一步持久化URI权限。因为ACTION_OPEN_DOCUMENT拿到的URI是一次性的不执行takePersistableUriPermissionApp下次重启就访问不到这个文件了。这个坑我第一版没注意用户重启软件之后发现添加的音频全部消失排查了好久才想起来是权限没持久化。iOS端用的是UIDocumentPickerViewController选择之后需要把文件拷贝到App的Documents或Library目录下。因为iOS的沙盒机制不允许直接访问系统文件管理器的原文件只能做拷贝。这里要注意在app支持“文件”App之后用户体验通常没问题但大文件拷贝耗时较长。我实测一个50MB的FLAC文件在手机上拷贝要将近两秒所以最好在UI上给一个进度反馈不然用户会以为卡死了。2.3 文件元数据读取与列表展示文件导入成功只是第一步列表展示是用户直接感知的部分。很多开发新手会忽视一个细节音频文件本身自带元数据比如标题、艺术家、专辑、封面图。如果你的白噪音列表里显示的是“audio_20240101_2330.m4a”这种裸文件名用户根本分不清哪个是哪个。我用的方案是读取ID3标签。Android和iOS都有对应的媒体库API可以解析文件头信息。如果解析不到有效标题就回退到文件主名再把扩展名去掉展示。对于封面图能拿到就用拿不到就用一个默认的音频图标代替不要让UI因为这事情出空白。排序逻辑上也做了点优化。默认按最近导入时间倒序排列用户新加的文件永远出现在最上面。同时支持用户手动拖拽排序和重命名毕竟有人喜欢把自己的录音叫“雨夜”而不是“录音_20240520_213000”。3. 无缝循环与淡入淡出自定义音频能稳定播放的核心3.1 为什么白噪音必须做无缝循环白噪音的使用场景大家都懂睡觉、学习、冥想一听就是几个小时。但这世上没几个音频文件的时长能撑一整晚所以循环播放就成了刚需。而且这个循环有一点特殊要求不能有停顿。普通音乐播放器在单曲循环时结尾到开头之间会有几十毫秒到几百毫秒的间隙听歌时不觉得怎样白噪音一停下就会特别突兀睡到一半雷雨声戛然而止人直接就醒了。要解决这个间隙第一版我想得比较简单直接把MediaPlayer的looping属性设为true让它自己循环。实测被现实狠狠教育了。MediaPlayer循环时底层解码器重新seek到音频开头大部分设备上这个seek过程会带来几十到几百毫秒的静音或者“咔哒”爆音。对于人声歌曲勉强能接受对白噪音来说完全不行。3.2 交叉淡入淡出不完美的循环也可以很丝滑最后我采用的方案不是去追求底层“零间隔”而是用交叉淡入淡出来掩盖这个问题。原理说白了很实在在音频快结束时提前200~300毫秒开始衰减音量同时把音频开头的同一段时间音量从零拉升起来让“结尾”和“开头”叠在一起混音输出。这样即使存在微小间隔也被音量变化特征掩盖了。技术实现上有两条路一条是用音频引擎层处理比如Android的SoundPool它比较适合短音频循环对长音频支持有限而且对FLAC这类格式兼容性一般更适合轻量应用。另一条是我最终采用的用ExoPlayer或Media3的自定义渲染器做处理。做法是维护一个环形缓冲区解码线程持续解码数据写入播放线程按固定时间间隔从缓冲区读取。在预判到即将到达文件末尾时提前解码文件头部的数据到缓冲区这样从尾部过渡到头部时底层数据流其实一直是连续的。音频文件能不能实现真正的无缝循环关键就在“缓冲区里有没有提前塞入头部数据”这件事上。实际处理时你可以这样简化处理把音频文件的前500毫秒数据预加载到内存里在距结尾500毫秒的位置准备切换。注意要做音量渐变我实测下来交叉淡入淡出的重叠区间在300毫秒左右最舒服。太短了藤刚度不够依然能听到“咔哒”太长了能感觉到音量起伏反而不自然。3.3 多轨道混音自定义音频和内置音频同时播放还有一个需求在开发中被反复提起用户想把自己录的雨声和App内置的雷声叠加在一起组合出“雷雨交加的夜晚”效果。这就涉及多轨道混音了。这里我犯过一个错误最初想着同时创建多个播放器实例各播各的谁料它们各自的时钟漂移导致拍子对不上雷声和雨声节律错位听着极其难受。正确做法是把所有音轨扔进同一个混音进程让它们共享同一个播放时钟。技术上我用的是Media3的AudioProcessor管道把每条音轨的解码输出喂给混音处理器在PCM层面做加法混合然后统一交给AudioTrack输出。每条音轨独立控制音量、静音开关和循环开关。这样不仅时钟统一音量控制也更精确。如果你用的是iOS平台对应的方案是AVAudioEngine同样是多条AVAudioPlayerNode接入同一个主混音器节点mainMixerNode通过它统一输出。这个思路是一致的客户端混音必须共用一个时钟源。4. 从“能放出来”到“放得舒服”实测中踩过的几个实质性坑4.1 音频焦点冲突一打开别的App白噪音就停了这是试玩版用户反馈最多的一个问题。很多人习惯开着白噪音软件再切到微信刷朋友圈或者看短视频结果白噪音马上就停了。原因是新启动的App会向系统申请音频焦点把原有的播放会话给“抢走”了。处理方式分两层。第一层把App的播放属性设置为长音频播放类别向系统声明这个App适合持续混音播放。Android上用AudioAttributes的CONTENT_TYPE_MUSIC配USAGE_MEDIA同时给Media3的PlaybackParameters设置handleAudioBecomingNoisy(false)意思是不要因为音频焦点丢失就直接暂停整个播放。在iOS端则是配置AVAudioSession的category为.playback并且把options设为.mixWithOthers这样自己的声音就能和其他App共存了。第二层是焦点处理回调。当检测到其他App请求音频焦点时我们可以选择主动降低白噪音音量而不是直接暂停。这在实际体验中会好很多用户只是切换了一下看个信息声音压低一点但没断回来之后自动恢复。4.2 大文件解析启动慢进度条卡了几秒有用户导入了三个小时长度的航班飞行录音app在点击播放之后界面卡住好几秒没反应。问题出在解码器初始化时要扫描整个文件的索引结构文件越大时间越长。优化方向有两个。一是在导入阶段就在后台完成媒体信息提取存进数据库而不是每次进播放页才现解析二是播放前做一次轻量seek测试把需要的关键帧位置缓存下来下次播放直接跳过解析。另外对大文件建议在代码里添加文件大小入参判断超过一定阈值比如300MB就不允许导入。白噪音源文件不需要那么长真要长时间播放靠循环就够了。3.5小时无损文件放在手机里纯属浪费空间没必要硬抗。4.3 循环接缝处“咔哒”声不是调接口能解决的前面说的交叉淡入淡出方案在绝大多数音频文件上表现良好但我遇到一类文件无论如何都能听到固定的咔哒声最终定位到文件本身的原因源文件头部一开头就有音量突变的爆音。这类文件在循环到开头的时候即使做了淡入从所谓“无声”掩盖到真实音频的爆音本质并不会真正消失。解法是在导入时做一次音频分析扫描开头和结尾各几毫秒的波形如果首尾波形相位差很大就把尾部最后几毫秒裁掉或者用极短的时间包络做一次强制归零。这部分我用的是开源库ffmpeg的silenceremove过滤器思路但实际代码里自己写了简单的PCM采样处理逻辑只对首尾操作不影响中间完整内容。4.4 文件被用户移动或删除后播放器直接崩溃还有一个很常遇到但容易被忽略的问题用户添加文件后又在系统文件管理器里把原文件删了App再次尝试播放时直接抛异常。虽然Android的ACTION_OPEN_DOCUMENT在文件被删除后一般会拿到一个不存在的URI但iOS上拷贝到App沙盒内的副本不会受影响——Android这边还是要做异常兜底。现在的做法是播放统一经过一个中间层每次播放前先判断URI是否可用不可用就自动从列表中移除并提示用户文件失效。这种“先判断再播放”的机制用不了多少代码但对体验的提升非常大。5. 录音质量与文件准备建议用户怎么录效果才最接近白噪音5.1 录制自己的“专属白噪音”讲究哪些条件功能上线后我收到几个录音文件有些效果很好有些完全没法用。后来总结了一下好的录音和不好的录音之间差距都出在基础设备条件上。想录一段能当白噪音用的雨声或风声不需要专业麦克风但环境和稳定性是关键。建议找一个安静的房间打开窗户让环境声均匀地传进来手机固定在一个位置不要手持。手持录音最大的问题不是拾音质量而是移动时引起的摩擦声和音量起伏这些细微的不稳定在长时间播放时会变成明显的“情绪波动”。保证录音连续30分钟以上中间不要停断。白噪音应用侧会循环播放所以其实一分钟的音频也能循环但30分钟的录音在“内容丰富度”上要自然很多每一阵风和每一阵雨都有自己的变化。5.2 文件长度、码率和声道选择直接影响耳朵舒服度给用户的准备建议里我通常会包含一条简单的规格清单参数推荐值原因时长10分钟以上太短会导致循环频率过高容易察觉采样率44.1kHz及以上低于这个值高频明显缺失码率192kbps以上MP3低于这个值压缩痕迹明显声音发闷文件格式WAVPCM或FLAC优先无损格式用于白噪音理论上更稳声道立体声营造空间感听感更好声道这里多啰嗦一句有些用户会拿手机默认的“单声道录音”去录雨声回放时声音“贴”在脑门中间空间感全无。如果手机录音设置里有立体声选项建议优先开启如果已经录成了单声道还有一个解决办法是在App播放器内部做伪立体声扩展把单声道信号做一点延迟和滤波后分到左右声道效果比纯单声道好一点但说实话不如原始立体声自然。5.3 用户换机或清理缓存后自定音频该怎么保住自定义音频最怕的就是换机迁移或者手机清理App缓存的时候把文件全清了。这部分我在产品上做了个导出能力用户的自定义音频列表支持生成导出记录记录里包含所有文件的引用信息。换新手机后先把原始音频文件传到新手机再从记录里重新导入就行。当然这个方案需要用户有意识地手动操作在解释成本上相对较高。如果你在做同类功能一个更省心考虑是在云盘服务里做自动备份白噪音文件的体积都不大一个月备份一次也没多大成本。6. 给功能收尾的几点总结以及我对“添加自己的声音”这件事的重新理解这版功能做完之后我自己养成了一个新的习惯出门旅行的时候遇到好的自然声环境会掏出手机安静地录十分钟。以前都觉得白噪音是App里那些现成的声音现在反倒觉得由自己记录下来的环境声才是真正让这个功能发挥价值的场景——白噪音的核心意义在于自由定义环境而不是按开发者预设的模板运行。在文件管理设计上我建议把自定义列表和内置列表做得界限分明。我的处理方法是内置列表用圆圆的悠闲风格图标展示自定义列表直接显示文件名和格式标签。这样用户在混搭使用时能一眼看出哪些是自带的哪些是自己的层级关系清晰返工成本也低。再想到开发过程中的几个具体教训简单留个备忘录在这里也在前面各节里展开过文件权限持久化不能省音频焦点要处理好“共存”而不是“抢占”大文件导入必须异步处理循环播放的核心是缓冲区预加载和交叉淡化一起用。代码量不大但每一个坑都是拿用户的真实反馈换出来的。如果你也正在做类似的自定义音源功能或者只是在自己的项目里想加一个“导入自己的声音”的能力可以多留意上面提到的这些点。它们决定的不只是“功能能不能跑起来”而是“用户愿不愿意每天都打开这个App”。