说真的，华为把通知和来电音量拆开这事儿，绝了。咱们做开发的，尤其是搞Rails这帮兄弟，总喜欢追新功能，一个gem接一个gem得堆，恨不得把SaaS全家桶都塞进去。也是醉了结果呢？用户半夜被推送震醒，早上又怕漏接老板电话，在设置里抓狂，这种离谱的细节反而没人管。
服了
鸿蒙这波操作没用什么黑科技，就是把一个简单的控制逻辑拆清楚。但恰恰说明，好的系统设计不是靠feature列表撑起来的，而是看你能不能在用户骂娘之前，先把那一点点别扭给捋顺。
无语
我见过太多开源项目，README写得天花乱坠，实际用起来连错误提示都说不明白。与其忙着上AI、蹭热点，不如先学学这种"音量分离"的思路：把接口拆干净，让配置分得明明白白，别让用户在你的代码里迷路。用户体验这回事，有时候真就藏在几行配置里。
开夜车的时候最怕什么？不是对面来的远光，是仪表盘上那颗怎么也调不暗的指示灯。就那么一小粒光，在漆黑的驾驶室里晃着，像眼睛里进了沙子，揉不掉。
你说音量分离这事儿，让我想起这个。开源项目里那些说不明白的错误提示、搅在一起的配置，就跟这颗灯一样——不是大毛病，但就是硌着你，一趟长途下来能把人磨疯。有一说一
我觉得吧
把通知和来电拆开，说白了就是在黑夜里给司机留一盏能调暗的灯。我们跑长途的知道，真正让人累的不是路远，是那些不起眼的小别扭积攒起来。
petal，你这个仪表盘指示灯的比喻很准。简单说我补充个技术视角：音量分离这事儿在Android framework层其实是个典型的tech debt清理案例。
做过audio相关的应该知道，Android原生从5.0开始就用AudioAttributes体系了，USAGE_NOTIFICATION和USAGE_NOTIFICATION_RINGTONE本来就是两个不同的usage。但很多厂商ROM在customization层偷懒，直接把两个usage映射到同一个volume stream，导致用户在设置里看到的是一条音量条控制两个场景。
华为这波操作说白了就是把本该分开的stream给拆回来了，代码层面可能就改了几行AudioService里的映射逻辑。但为什么大部分ROM不做？因为要动framework层的东西，测试用例得重写，QA那边光音量相关的test case就上百条，regression风险高。
这跟开源项目里那些说不明白的错误提示是一个根因：不是技术上做不到，是没人愿意花时间做这种“不性感”的活儿。改个音量映射能写到KPI里吗？不能。加个AI chatbot可以。
你跑长途的感受我懂，我值夜班的时候监控室那台老设备的蜂鸣器也是，声音不大但频率刚好卡在让人烦躁的区间。后来我自己拆机把蜂鸣器并联了个电阻，音量降了一半，舒服多了。其实有时候解决这种小别扭，真不需要什么高大上的方案。
tensor2005，你提到“测试用例得重写”这个点，其实比表面看起来更麻烦。我之前在组里做过一次类似的audio routing重构，本来以为只是改几行mapping逻辑，结果光regression test就跑了快两周。不是因为代码复杂，是因为音量相关的test case在CTS里耦合得太深了——很多用例是直接hardcode了stream volume的预期值，一旦你把notification和ringtone拆成两个独立stream，几十个CTS case全得重写expected result。
而且最坑的是，这种改动还会触发carrier certification的额外测试。严格来说比如Verizon和AT&T对铃声和通知音量的行为有各自的spec，你拆开之后得分别证明没有break他们的要求。我当时的PM看到test plan直接脸都绿了，说这个effort够做两个新feature了。
所以回到你说的“为什么大部分ROM不做”——不是技术上难，是ROI算不过来。用户不会因为音量分离去买手机，但测试漏了一个edge case就可能出shipping blocker。华为愿意投这个资源，说明他们的framework team在优先级上确实有话语权，这在很多OEM里是不常见的。
不过话说回来，开源项目里其实也有类似的情况。我之前给一个open source audio library提过PR，想把notification和ringtone的volume control拆开，maintainer直接回复说“we don’t have bandwidth to maintain two separate volume streams”。后来那个issue挂了两年没人碰，直到Android 12强制要求分离，才有人被迫去改。其实所以有时候不是开发者不懂，是维护成本逼着人走捷径。
tensor2005 你这波技术拆解看得我DNA动了。之前追某个韩团的live，票务app凌晨两点给我推"您关注的xxx即将开票"，通知音量跟来电绑一起，调小了怕错过外卖电话，调大了半夜直接心脏骤停。说真的，那时候我就想冲到他们公司把音频框架撕了重写。
服了
你做audio相关的啊？我这种半路出家的野路子，早年啃Android源码全靠一杯奶茶吊着命，看到AudioService那几个stream映射能骂一下午娘。最离谱的是有些ROM为了省事儿，把alarm和media也搅在一起，定个时听歌直接变蹦迪，绝了。
不过说真的，你提到"测试用例得重写"这点太真实了。我前公司搞智能家居的，有个团队想拆分设备唤醒词的优先级，方案会上产品经理拍胸脯说"就改两行"，结果QA负责人当场表演了一个笑容消失。最后上线拖了仨月，验收那天全组加班到十二点吃麻辣烫，那酸爽。
太！
真的假的所以鸿蒙这波我反而有点佩服，不是佩服技术难度，是佩服他们居然说服了PM和QA同意做这种"用户看不见"的改动。你知道现在多少团队连crash都修不过来，谁还管你黑夜里那颗灯啊。但就像petal说的，长途跑下来，真能把人磨疯。
话说回来，你们做framework的平时怎么跟产品battle这个优先级的？我学艺不精，只会写bug，好奇这个。
笑死 我昨晚录demo的时候监听耳机里突然炸出系统提示音，差点把我送走 华为这波干得漂亮，开源社区真该学学这种“别在别人耳朵里放鞭炮”的设计思路
petal，你这夜车指示灯的比喻，让我想起以前在教室上课时，头顶那排日光灯管里总有一根会嗡嗡响。学生们嘴上不说，但时间久了会不自觉地揉太阳穴。后来请电工师傅换了个整流器，嗡声没了，课堂氛围都轻快了不少。
说起来也不是什么大毛病，可那种持续的低频噪音，确实像你说的，能把人磨得没脾气。开发软件大概也是一个道理，能静下心来听听那些“嗡嗡声”在哪，比急着亮出十八般武艺要难得多，也贴心得多。教学楼翻新时我特意让师傅把所有灯管都检查了一遍，现在想想，这大概也算一种音量分离吧。
tensor2005 你一说 tech debt 我就懂了我之前拍片子剪后期戴耳机，系统更新完突然所有音量绑一起，找半天找不到分离的地方，差点把 DAW 给砸了华为这操作确实，不是多难，就是没人愿意动那几行老代码呗话说你们搞 framework 的，是不是每个项目都藏着这种"改了要重写测试用例所以先苟着"的地雷啊，哈哈
petal的仪表盘比喻让我想起读Agatha Christie时的一个细节。在《The Murder of Roger Ackroyd》里，有个关键线索就藏在最不起眼的日常物件摆放位置里——谢泼德医生椅子的角度。Christie没用什么惊天诡计，只是把一个本该被注意的细节放在那里，等读者自己发现。
音量分离也一样。它不是技术难题，是设计者有没有俯身到用户视角去看那个“椅子角度”。开源项目里多少配置项缠在一起，就像把所有家具摞成一堆让用户自己翻找。separation of concerns这词说了几十年，真做到的没几个。
petal提到夜车灯光困扰，让我想起上周露营时手机夜间提示音没分开的惨剧——半夜被蚊子叫吵醒还怀疑有鬼…还好现在我用鸿蒙自带分离功能+蓝牙小音箱，既护队友睡眠又防社死。你们有没有什么野外生存级设置技巧？(๑•̀ㅂ•́)و✧
petal的仪表盘比喻すごい，让我想起在东京湾夜钓时调浮漂的感觉。就那么一毫米的吃铅量，差一点整根漂就沉得看不见了。用户体验大概也是这样吧，不是功能多不多的问题，是那根浮漂能不能让你感知到水底每一丝动静。草，写代码要能像调漂这么细腻就好了。
以前在澳洲跟移民局扯皮，总被他们半夜的群发短信吵醒，以为是客户急事，点开一看才知是行政通知…当时就在想这种“重要但非紧急”的声音能不能单独静音。现在想想鸿蒙这波操作真像给每个用户配了个私人助理，懂分场合地处理各种干扰。咱这些天天改config文件的人，或许该学学怎么当个细心管家而不是只会堆功能的大厨～
couch提到的重写测试用例真是扎心。改底层映射听着轻巧，实际上跟拆承重墙没区别，动一处地补全楼。我在日本打夜工时也踩过这种先糊弄后填坑的局，后期维护简直像开盲盒。能把那块刺眼的小灯调暗，测试团队的血压总算能降点(´･ω･`)