一個擁有1-2 年經驗的開發者，從0 到1 上線應用只要7 天。一個剛起步的程序員，可以30 分鐘內完成一個 Demo。
這不是天方夜譚，而是融云場景化 SDK 帶給行業的創變。
商業社會兵貴神速，特別是以 Z 世代人群為目標用戶的語音社交類應用。國家統計局的數據顯示，1995 年到2009 年出生的Z 世代人口接近2.6 億。而相比“前輩”，他們的偏好更加個性、悅己、多變，社交上更講究圈子、同好。
語音社交因沉浸式的情感交互而被 Z 世代 pick，但應用要不斷圍繞主流模式嘗試突破，依靠玩法創新搶占先機，否則產品也就是“類卿”爾。
今天，我們就來詳細了解一下，融云語聊房 SDK，是如何實現全面覆蓋語聊房業務場景，支持開發者快速出活的。
01 語聊房了解一下
帶大家拆解這款“行業利器”之前，咱們先重新認識一下語聊房。
語聊房，從字面上看就是語音聊天房，核心是多人實時語音交互。疫情之下，隨著 Clubhouse 的大火，語聊房業務迎來爆發期，語音社交成功出圈。
（融云語聊房 Demo）
從上圖看，語聊房 APP 的界面基本上由兩部分組成。
上半部分主要是用戶和麥位，對比生活中的場景，像一個有一位主持人和八位發言者的講座，臺下有若干聽眾；聽眾若有興趣發言，走上講臺，拿起麥克風就可以變成發言人。
下半部分則是一些常規的聊天室模式，承擔發送信息、發送禮物等功能。
開發這樣一款產品，一般會面對什么問題呢？
首先是麥位信息同步。一個語聊房可能會有幾千人在線，任何一個人上麥都需要在極短時間內把麥位信息同步給房間內所有人，這是第一個挑戰。
其次是麥位管理。
上麥，意味著用戶擁有了發布音頻流的能力，角色從觀眾切換為主播。
下麥則意味著主播變成普通用戶，失去了發布音頻流的能力。
鎖麥，就是鎖定麥位，任何人都不可以上麥。
閉麥，顧名思義，該麥位上的用戶無法發言。
邀請上麥，由房主邀請聽眾上麥互動。
還有一些音頻類的常規操作，比如靜音、混音、播放音樂等。
語聊房產品的核心是麥位管理，融云的語聊房解決方案，就是通過上麥、下麥等一系列麥位管理來對用戶和流進行同步管理的 SDK。
02 語聊房業務流程
經過多年發展，融云的 IM 和 RTC 已經是行業基建。開發者使用 PaaS 服務商的這些能力，可以很方便地實現即時通訊和實時音視頻的業務應用。
但是，把 RTC、IM 能力和場景玩法相結合的復雜業務，實現起來依然面臨不小的困難。基于對行業的深厚積累和前瞻判斷，融云推出下一代場景化 SDK 解決方案，首發場景聚焦與 Z 世代深度黏合的語聊房業務，滿足開發者快速實現業務的需求。
那么在語聊房業務上，為開發者提供類似行業基建的 SDK，要處理哪些業務邏輯呢？
（房主端流程）
房主端流程：如圖，單主播情況下，房主需要調用接口加入一個房間，然后邀請觀眾上麥或者處理觀眾的上麥請求。同時，房主還擁有閉麥、鎖麥等麥位管理權限。
多主播情況下，首先要處理麥上人員的語音互動，這意味著主播需要互相訂閱流來聽到彼此的聲音；房主可以調用接口關閉連麥者麥克風，或讓連麥者下麥；通過聊天室屬性，所有人都可以監聽到房間內狀態的變化，然后做出響應處理。
（觀眾端流程）
觀眾端流程：如圖，觀眾瀏覽直播間列表，選擇感興趣的加入。加入后，語聊房自動訂閱直播流；監聽語聊房狀態，更新房間 UI 和麥位 UI；收到直播結束消息，調用語聊房接口退出房間。
03 語聊房場景三大難題，融云如何通關
語聊房應用實現面臨三大技術難關：
1）、麥位狀態如何進行云端存儲與通知
2）、如何實現邀請上麥和排麥請求機制
3）、如何設計 API
首先，麥位狀態的云端存儲與通知。
答案是——利用融云的聊天室屬性管理能力。
每個聊天室提供100 個 key-value 的鍵值對，特殊需求也可以申請擴容。
聊天室用戶新增，更新，刪除某個鍵值對，其他用戶都會毫秒級速度收到 update 回調，保持一定的持續性，不會造成亂序等問題。
穩定、可靠，同時更改多個鍵值對也能保證每個更新都觸發聊天室所有用戶回調。
這樣，語聊房的麥位狀態存儲和同步就可以比較順暢地實現了。
（加入房間邏輯）
以加入房間這一動作為例：
用戶加入房間只需傳遞一個 RoomId，語聊房 SDK 自動幫用戶加入 IM Room 和 RTC Room，獲得收發消息和音視頻傳輸的能力。在加入這些房間后，用戶就會收到一個回調，以回調的方式獲得當下最新的房間信息和麥位信息。
如圖所示，融云語聊房 SDK隱藏加入房間需要的多個操作，融合成傳遞 RoomId 一個步驟，為開發者節省大量的研發工作。
在這個環節，用基礎類 IM 和 RTC 能力開發需要2 到3 天，使用融云語聊房 SDK 只需10 分鐘。
其次，如何實現邀請機制和申請機制。
要實現順暢的邀請和申請機制，有兩點基礎。第一，邀請的發送和接收信令必須是有序、準確的。第二，信令不能丟失。基于融云 IM 通訊服務安全、可靠、高效的信令通道，在這方面有天然優勢。
（上麥邏輯）
以申請上麥為例，開發者自己實現需要先設計和實現一套自己的信令服務。使用融云語聊房 SDK，只需要一句 RequestSeat（請求麥位），房主端或有管理權限的成員，會收到一個回調，選擇 accept 或 reject，觀眾端隨即收到相應回調。
這一業務邏輯上，融云語聊房 SDK 為開發者簡化了百分之八十的操作。
最后，如何設計 API。
這是整個 SDK 中最復雜的部分，也直接決定了它的實用性。功能做得再強大，如果無法以簡單易懂的方式呈現，也會因為學習成本太大而讓人望而卻步。
在這方面，融云希望降低開發者的學習成本，讓他們只通過文件的注釋和命名就基本了解使用辦法。
為了達到這個目標，融云的語聊房 SDK 在設計 API 時，首要原則是貼近業務。與傳統的依賴倒置原則正好相反，特定場景的 API 設計，不能特別依賴于抽象接口，而要特別貼近具體的場景。
在語聊房 SDK 的使用中，開發者只要了解語聊房的基本模式，就能通過接口的命名，了解接口的功能，幾乎可以零學習成本掌握。
比如，enterSeat(index: Int)接口，index 設置為麥的序號，就完成了這一麥位上角色轉換、流的訂閱等一系列操作。muteSeat(index: Int)接口則可以關閉某個麥位上的聲音；kickUserFromSeat(userId: String)接口就可以把某個用戶踢下麥。
其次要可擴展，無論是房間的屬性，還是麥位的屬性，SDK 都提供強大的可擴展性，自定義程度高，覆蓋所有語聊房的場景，即便是語聊房中形式和內容最復雜的狼人殺場景也可以滿足。
最后是簡潔易用，語聊房 SDK核心接口只有20 個，大部分場景只需要其中10 個基本上就可以實現業務。核心功能回調只有23 個，對于不太關注性能或不需要兼容低端手機的業務，開發者只需關心麥位信息和房間信息的變更兩個回調就可以。
而且，融云提供結構清晰的文檔指南，緊貼語聊房場景，每部分都包含簡潔易懂的視頻示例，并提供一個全功能的線上開源 Demo，接入時有充足的參考資源。
此外，在內容安全要求趨嚴的背景下，融云還提供安全審查等關乎語聊房業務生死的通信周邊能力。開發者只需在后臺設置中一鍵開啟安全審查，即可接入數美等在線業務風控解決方案提供商提供的安全審查服務，為開發者的業務開展保駕護航。
結合 IM + RTC + X“全”通信解決方案和對具體場景的業務邏輯抽取，融云的場景化 SDK 解決方案，將為開發者提供快速切入新賽道和發展多元業務的下一代服務新范式。
