大到一個經濟時代，小到一個行業周期，生產工具的每次創新升級，勢必帶來生產力的顯著提升。
在 WICC 廣州的“社交分論壇”上，融云場景化研發負責人臧其龍帶來《融云社交場景化 SDK 探索》主題演講，分享融云在通信云服務方面的創新探索。融云第三代場景化 SDK 的服務模式創新將給開發者提供全新的生產工具，帶來生產效率的極大提升，也必將重塑產業格局。
但是，隨著時間的推進，市場需求不斷演變。我們會發現，單一場景需求越來越少，更多的時候，我們要面對的是場景的融合。
以語聊房這個時下語音社交熱門場景為例來說，這類產品主要有兩部分組成：一是麥位管理部分，用戶上麥后角色發生變化，從觀眾切換成主播，可以發布音頻流被觀眾和其他主播聽到。二是聊天室部分，也就是公屏消息的部分，房間內所有成員都可以發送文字在公屏區域溝通。
實現這兩個部分，就要同時接入 RTC 和 IM，也就是融合場景。這種融合需求也出現在直播等等場景中。隨之而來，棘手的問題出現了。
問題并非出于服務能力不足，反而是大部分行業供給都已經非常強大造成的。一個 SDK，基本上有 200+ 甚至 300+個 API。當開發者接觸到一個功能強大的 SDK，首先面對的難題是學習成本特別高，其次是它的學習曲線也比較陡峭。
比如 RTC 會涉及到很多非常專業的音視頻領域知識，要了解流的定義與發布，學習一些編碼知識，掌握了基礎知識后，才能讓 SDK 發揮應有的作用。
以語聊房場景為例，我們可以更加直觀地感受三代服務模式的升級核心。
語聊房產品的核心是麥位管理，語聊房解決方案，就是通過上麥、下麥等一系列麥位管理來對用戶和流進行同步管理的 SDK。
第一代解決方案，使用業務服務器管理每個房間的麥位。前端只負責調用后端的接口，后端管理麥位，不單要更改麥位，還要負責整個狀態的刷新和發布，非常復雜。
第二代解決方案，也就是目前其他廠商普遍使用的方式。把管理麥位的能力放在 IM SDK 里，通常是聊天室屬性，擁有麥位的增、刪、改、查同步能力。服務模式是，開發者下載 Demo，自行研究實現邏輯，再利用開源代碼二開實現。也就是說，開發者還是需要理解廠商提供的開源代碼，上手難度比較高。
第三代解決方案，也就是融云行業首推的 SDK。開發者無需研究代碼，也不需要單獨集成 IM 和 RTC，只需要對這個產品有了解，就可以調用接口實現應用。而且這個接口數量只有不超過 20 個。
第二代解決方案，只需要關注前端開源代碼，但是也要面臨殘酷的現實問題。首先，原封不動上架產品面對很大的審核被拒風險；其次，新增功能需要學習底層機制再改代碼，難度大，易出 Bug。
融云的第三代 SDK 解決方案，學習難度非常低，只需要對基礎的上麥、下麥、鎖麥等有了解，甚至根據 20 個 API 的注釋就能成功調用。無需理解底層代碼，無需研究實現邏輯，無需管理流的訂閱，極大提升開發速度，7 天就能上線一個語聊房。
以最常見的三個功能為例，enterSeat(index: Int) 接口，index 設置為麥的序號，就完成了這一麥位上角色轉換、流的訂閱、UI 的同步和刷新等一系列操作。muteSeat(index: Int) 接口，Mute 是靜音，Seat 是某個麥位，后面會帶一個麥位的序號，可以關閉某個麥位上的聲音；kickUserFromSeat(userId: String) 接口就可以把某個用戶踢下麥。都說細節是魔鬼，第三代 SDK 可以說是已經把魔鬼封在黑盒中了，開發者可以無憂開發。
可擴展性：語聊覆蓋的場景非常多，比如非常火的狼人殺業務，需要麥位體現特殊身份——平民、法官、狼人，接口設計得足夠可拓展，就可以覆蓋所有熱門場景，也方便開發者去做不同業務的嘗試。
簡潔易用：語聊房 SDK 核心接口只有 20 個，大部分場景只需要其中 10 個基本上就可以實現業務。核心功能回調只有 23 個，對于不太關注性能或不需要兼容低端手機的業務，開發者只需關心麥位信息和房間信息的變更兩個回調就可以。
直播場景通常用戶感知最強烈的就是兩個步驟，喚起攝像頭做直播前美顏等準備 ? 開始直播。
融云直播 SDK 把這兩步封裝成 API，第一步是 Prepare，封裝了融云開源的 BeautyKit 美顏等能力；第二步是 Live Video，把所有直播流程實現邏輯隱藏掉，開發者只需要調用接口就可以實現業務。
接下來，融云還會把會議、教育等場景進行完整封裝提供給開發者，幫開發者一一攻克場景難關。
同時，在 SDK 組成的“骨骼”、“肌肉”之外，融云還將開源一系列含 UI 體系的 Kit，作為配套使用的“皮膚”。比如，ChatKit、GiftKit、BeautyKit、MusicControlKit 等等。搭配開發者可在后臺一鍵配置的“內容審核”能力，真正為開發者提供一站式的完整解決方案服務。
