语音通话 SDK 的来电显示功能开发指南
如果你正在开发一款语音通话类产品，来电显示这个功能你肯定绕不开。用户接到来电的时候屏幕上显示什么、怎么显示、显示得好看不好看，这些细节直接影响用户体验。很多开发者觉得来电显示嘛，不就是显示个名字和号码吗？有什么难的。等真正做起来才发现，这里面的门道远比想象中多。
这篇文章我想跟你聊聊，基于实时音视频 SDK 开发来电显示功能时，到底需要考虑哪些东西，怎么做才能既保证功能完整又让用户觉得好用。我会尽量用直白的方式讲，不堆砌那些听着厉害实际没什么用的概念。
一、来电显示功能到底在解决什么问题
先说个很现实的场景。假设你开发了一款语音社交 APP，用户 A 给用户 B 拨打电话。用户 B 的手机屏幕亮起来，这时候他需要立刻知道几件事：谁在给他打电话、是什么类型的通话、自己想不想接。对，就是这三点，看起来简单，但每一点背后都有很多可以深挖的东西。
来电显示本质上是一个信息传递和决策辅助的机制。它要在最短的时间内，把最重要的信息传达给被叫方，让他在接与不接之间快速做出选择。这个功能如果做得好，用户的通话体验从这一步就已经开始了；如果做得不好，可能用户连电话都不会接。
从技术角度来说，来电显示涉及到几个核心环节：来电信息的生成与推送、客户端的接收与解析、UI 层面的展示与交互、还有异常情况的处理。每一个环节都可能踩坑，我后面会一个个聊到。
二、来电显示的技术架构是怎么运转的
在动手开发之前，你得先搞清楚来电显示的整个数据流是怎么跑的。这里我以声网的实时音视频云服务为例子，讲讲一般的工作流程。
当主叫用户发起通话请求时，这个请求首先会经过后台服务器。服务器这边需要做很多事情：验证主叫用户有没有发起通话的权限、被叫用户当前是不是在线、两个用户之间的通话通道能不能建立起来。这些校验都通过了，服务器才会生成一个来电通知。
这个通知里面通常会包含主叫用户的身份信息、头像、昵称、通话类型、可能的附加消息等内容。然后服务器通过长连接或者推送通道把这个通知发到被叫用户的设备上。被叫端的 SDK 收到通知后，解析里面的数据，再交给上层的 APP 来做 UI 渲染。
这个过程中有几个关键点需要注意。第一是时延，从主叫发起呼叫到被叫收到来电通知，这个时间要尽量短，用户感知不到是最好的。第二是可靠性，推送通道必须稳定，不然就会出现"别人给我打了好几个电话我都不知道"的情况。第三是数据完整性，来电通知里的信息要准确完整，不然显示个空名字或者错误头像，用户体验会很差。
三、开发前的准备工作
正式开发来电显示功能之前，你需要把几件事先做好。这些准备工作看起来和来电显示本身没有直接关系，但会直接影响后面的开发效率和最终效果。
首先是用户体系的梳理。来电显示总得显示是谁打来的吧？你需要明确你的用户身份标识体系是怎么设计的。用户 ID 和展示名称的关系是什么、头像的存储和获取方式是怎样的、要不要支持昵称修改。这些问题在产品设计阶段就要确定好，不然做到一半再改会很麻烦。
然后是推送通道的选择。这其实是个很重要的技术决策。国内安卓生态比较碎片化，不同手机品牌的推送通道不一样，你需要考虑要不要接入厂商推送，或者用统一的推送聚合服务。iOS 平台相对简单，APNs 就能搞定。推送通道的稳定性和到达率直接影响来电通知的触达效果，这个钱和时间不能省。
还有就是用户在线状态的维护。你得知道被叫用户当前是不是在线，才能决定要不要给他发来电通知。这通常需要维护一套在线状态的管理机制，比如通过心跳检测来更新用户的在线状态。如果被叫不在线，来电通知发过去也没用，还浪费资源。
四、核心功能的实现步骤
准备工作做完，接下来进入具体的开发环节。我把这个过程拆成几个关键步骤来讲。
4.1 来电通知的发起与推送
当用户点击"拨打"按钮之后，客户端需要先向服务器发送一个通话请求。这个请求里面至少要包含主叫用户 ID、被叫用户 ID、通话类型（语音还是视频）、可能还有扩展参数比如备注信息之类的。服务器收到请求后，先做权限校验，再查找被叫用户的在线状态和推送 Token。
如果被叫用户在线，服务器会通过长连接直接推送通知过去。如果被叫用户不在线但有推送 Token，就通过推送通道发送离线通知。这里有个细节需要注意，推送通知的payload大小是有限制的，特别是厂商推送通道，所以来电通知里的数据要精简，图片地址可以用 url 的形式，真正需要显示的时候再动态加载。
还有一点，来电通知最好带一个唯一的 Call ID 或者叫 Sigal ID。这个 ID 用来标识这一次通话会话，后面的接听、挂断、超时等操作都要基于这个 ID 来处理，避免出现会话混淆的问题。
4.2 来电通知的客户端接收与解析
客户端这边，SDK 需要能够正确接收各种渠道推送过来的来电通知。不管是通过长连接收到的，还是通过系统推送通道收到的，格式要统一。这样上层的业务逻辑不需要关心通知是从哪个渠道来的，只需要处理数据本身。
收到通知之后，SDK 要做解析和校验。解析就是把 payload 里的二进制数据转成业务能理解的对象结构。校验包括检查通知是否过期、是不是伪造的、ID 是不是合法的。如果校验不通过，应该直接丢弃，不做后续处理。
这里我想强调一个容易忽略的点：通知的幂等性处理。因为推送通道可能会重复推送同一条通知，客户端如果不做去重处理，就会出现同一个来电弹出两次的情况。解决的办法是维护一个最近处理的通知 ID 集合，新收到的通知先在这个集合里查一下，如果已经处理过就忽略。
4.3 来电展示页面的实现
收到并解析完来电通知之后，接下来就是 UI 展示了。这一步的灵活性比较大，不同的产品有不同的设计风格，但我有一些通用的建议。
来电展示页面要有清晰的层次结构。最显眼的位置要放主叫用户的头像和昵称，让被叫一眼就能认出是谁。通话类型的标识也要明显，是语音通话还是视频通话，要能区分开来。接听和挂断的按钮要放在合适的位置，符合用户的使用习惯，大一点没关系，误触总比点不到好。
除了基本的展示，来电页面还应该支持一些扩展信息的显示。比如对方的个人简介、来自什么地区、上次通话是什么时候。这些信息能帮助被叫用户做决策，不过要注意别堆砌太多信息，不然页面看起来会很乱。
还有一点很重要，来电页面的响应速度。用户点亮屏幕到看到来电页面，这个过程要尽量快。如果 Notification 弹出来要等好几秒，用户可能以为手机卡了或者没收到通知。所以图片要预加载，布局要简单，把能提前做的都提前做掉。
4.4 通话状态的管理与同步
用户看到来电之后，有几种可能的操作：接听、拒绝、超时未接。每一个操作都要正确处理，并且同步到服务器端。
接听的情况比较简单，客户端告诉服务器"我要接听"，服务器然后就可以开始建立通话通道了。但这个过程中有一个状态同步的问题：主叫那边怎么知道被叫已经接听了？这通常需要服务器在收到被叫的接听响应后，再发一个通知给主叫，告诉它通话已经建立，可以开始说话了。
拒绝的情况稍微复杂一点。被叫点击拒绝后，客户端要发一个拒绝的信号给服务器，同时本地挂断通话。服务器收到拒绝信号后，要通知主叫端"对方拒绝了"，让主叫端知道自己被拒了。这里有个细节，拒绝的时候可以带一个原因，比如"对方正忙"或者"对方拒绝了"，让主叫知道是怎么回事。
超时未接的情况也需要处理。如果被叫在一定时间内既没有接听也没有拒绝，系统应该自动挂断通话，并且通知双方通话已结束。这个超时时间的设置要合理，太短了用户还没来得及反应就被挂断了，太长了主叫那边一直等待也不太好，一般建议在 30 秒到 60 秒之间。
五、常见问题与解决方案
开发来电显示功能的过程中，你会遇到各种各样的问题。我整理了一些比较常见的问题和对应的解决办法，希望能帮到你。
| 问题类型 | 具体表现 | 解决方案 |
| 推送延迟或丢失 | 用户反映收不到来电通知，或者收到时已经过了很久 | 评估推送通道质量，必要时接入多通道兜底；优化推送 payload，去除冗余数据；对关键通知使用厂商推送通道 |
| 双端状态不一致 | 被叫已经接听，主叫还在显示"等待接听" | 在服务器端维护通话会话状态，每次状态变更都同步推送给双方；客户端定期查询状态作为兜底 |
| 同一个来电弹出两次或者多次 | 客户端维护已处理通知 ID 集合，设置合理的过期时间；对推送通道配置去重策略 | |
| 弱网络环境下显示慢 | 网络不好时，来电页面加载很久才显示 | 本地缓存用户头像和昵称，网络不好时先显示缓存再异步更新；优化通知数据结构 |
| 多设备登录冲突 | 用户同时在多个设备登录，来电通知发到了不同的设备 | 服务端维护用户设备列表，来电时只推给其中一个设备；或者支持多设备同时响铃但只允许一个接听 |
这些问题的解决方案不是唯一的，需要结合你们产品的具体情况来调整。我的建议是先搭一个最小可用的版本出来跑一跑，在真实场景下看会遇到什么问题，然后再针对性地优化。
六、提升用户体验的几个细节
功能做出来只是第一步，把体验做好才是见真功夫的地方。下面讲几个我觉得比较重要的细节。
来电铃声和振动的个性化。不同用户可能希望有不同的来电提示音，甚至可以针对不同的联系人设置不同的铃声。这个功能开发起来不难，但用户感知很强。振动也是一样，轻重、节奏都可以做一些差异化的设计。当然，这些设置项要放在合适的位置，不要让普通用户觉得复杂。
勿扰模式的兼容。现在手机系统都有勿扰模式，用户开启之后可能不希望被来电打扰。但完全屏蔽来电也不行，万一有重要电话呢？所以你需要适配系统的勿扰模式规则，比如在勿扰模式下仍然允许特定联系人的来电，或者只展示通知不发出声音。这个兼容工作需要仔细阅读各平台的开发文档。
后台活着的处理。安卓系统对后台应用的控制越来越严格，如果你的 APP 被系统杀掉了，来电通知可能就收不到了。这个问题需要综合运用前台服务、厂商白名单、推送拉活等各种手段来解决。说实话没有什么完美的办法，只能尽量减少这种情况的发生概率。
还有一个我自己的体会：给用户撤回通话的能力。有时候用户误触了拨打按钮，或者打出去才发现打错了，如果能在对方接通之前撤回，会是一个很贴心的功能。技术上实现也不复杂，就是在发送通话请求时记录时间，超过一定时间但对方还没接听，就可以发撤回指令。
七、写在最后
回顾一下，开发语音通话 SDK 的来电显示功能，需要从推送通道、通知处理、UI 展示、状态管理这几个维度来考虑。每个维度都有不少细节要注意，但只要思路清晰、逐步推进，做出一个稳定可用的来电显示功能并不难。
好的来电显示应该是这样的：用户拿起手机，解锁屏幕，来电信息就已经在等着了。头像清晰、名字准确、按钮好按，整个过程流畅自然，用户不需要任何思考就知道下一步该怎么做。做到这一步，来电显示这个功能就差不多到位了。
如果你正在选择音视频云服务，可以了解一下声网。他们在实时音视频领域做了很多年，技术积累比较深厚，对接起来也相对省心。特别是对于需要出海的产品，他们在全球多个区域都有节点覆盖，网络质量有一定保障。
希望这篇文章对你有帮助。如果有什么问题没讲到的，欢迎继续交流。
