Android IM SDK開發設計大綱

IM SDK開發

數據協議

數據編解碼與數據加解密

• TLV編解碼的JAVA實現與優化
• 數據加解密

SDK架構設計

公共部分

• TLV編解碼
• 數據存儲與共享
• 跨進程通信管理
• 配置管理
• 自定義異常
• 大數據埋點統計

APP進程

• 協議請求管理
• 協議響應管理
• 消息分發管理
• 第三方推送集成

PUSH進程

• push進程的狀態管理
• TCP連接管理
• TCP連接重連策略
• 智能心跳策略與心跳的狀態管理
• Alarm與WakeLock
• 數據的加密與解密
• 數據的發送與讀取
• 數據的監聽與分發

長連接保活

• Android Service進程保活
• TCP長連接保活

SDK功耗優化

• 重連策略（動態調整重連間隔）
• 智能心跳策略
• 協議請求超時（動態調整協議請求超時時間）
• 夜間模式（Doze原理）
• http請求跟心跳對齊
• http請求採用長連接進行轉發

SDK穩定性監控

• 崩潰監控
• 異常邏輯監控
• 連接穩定性監控
• 心跳信息監控
• 流量消耗監控

網絡問題分析

• TCP協議
• 網絡劫持
• 網絡延遲
• 移動數據網絡的NAT問題，WIFI網絡的NAT過小問題，，DHCP問題

IM SDK的核心

• 數據協議的設計
• SDK代碼架構設計
• 數據編解碼（TLV）的實現和數據加解密
• 進程保活
• 長連接保活（智能心跳，斷線重連）
• 功耗優化（智能心跳，斷線重連）
• TCP協議和網絡問題的分析（網絡延遲，網絡劫持）

Android消息通信

不同進程間的通信

• 有的手機可能會在某些條件下攔截跨進程廣播，跨進程Service等

Binder通信

• Activity
• Broadcast（廣播接收延遲問題）
• Service（包含aidl，aidl的綁定關係被系統回收導致DeadObjectException）
• Provider（Provider的client端和server綁定崩潰問題）
• Messenger（aidl實現）
• 本地TCP
• 本地UDP

相同進程間的通信

• Handler
• CallBack
• 本地廣播（LocalBroadcast）
• 面向接口編程與反射機制（Eventbus）

Android push進程保活

• 單獨的push進程，降低單進程的內存佔用，提升進程oom_adj優先級
• 前臺service
• 後臺播放無聲的短音頻（音頻焦點獲取與失去的問題，可能會影響到通話過程中的音頻焦點）

TCP連接保活

智能心跳（考慮設備休眠問題）

• 二分法智能心跳探測
• 遞增智能心跳探測（微信智能心跳策略）

重連策略

• 斷線重連，連接失敗重連，數據格式解析失敗斷線重連，亮屏觸發重連
• 靜態重連策略：簡單的遞增試重連（採用計算公式計算出的指數型結果固定重連間隔）
• 動態重連策略：經過累計計算的自適應重連（根據不同的網絡環境，連接穩定情況等計算出一個權值，再根據這個權值去計算出合理的重連間隔）
• 靜態協議超時時長：20秒
• 動態協議超時時長：根據歷史協議請求響應的時長，再根據公式合理的計算出協議超時時長
• 以上的動態計算方式的策略方式類似於TCP協議的RTT和RTO的計算方式，TCP協議都是動態的去不斷的調整這些值的

數據格式編解碼和加解密

數據包協議（自定製）

• 公鑰請求包（publicKeyRequest）
• 公鑰響應包（publicKeyResponse）
• 加密請求包（encryptRequest）
• 加密響應包（encryptResponse）
• 設備註冊請求包（registerRequest）
• 設備註冊響應包（registerResponse）
• 設備登錄請求包（loginRequest）
• 設備登錄響應包（loginResponse）
• 賬戶上下線請求包（accountRequest）
• 賬戶上下線響應包（accountResponse）
• 同步通知包（syncForm）
• 同步請求包（syncRequest）
• 同步響應包（syncResponse）
• 同步響應結束幀包（syncFin）
• 直推包（pushResponse）
• 同步觸發包（syncTrigger）
• 消息請求包（messageRequest）
• 消息響應包（messageResponse）
• Http轉發請求包（transpondRequest）
• Http轉發響應包（transpondResponse）
• 心跳請求包（heartbeatRequest）
• 心跳響應包（heartbeatResponse）

數據格式編解碼

• 解決TCP的粘包問題
• 保證數據的安全性，驗證一致性

字符串編解碼

JSON（適合格式相對簡單的數據）

• Jackson
• Gson
• probuffer

XML（適合大型數據格式，數據格式相對複雜）

• xmpp

二進制編碼協議（速度快，帶寬小，內容安全）

• mqtt
• tlv（反射優化）

數據加解密

• 二進制協議編解碼一定程度上保證了數據的安全性，即使是抓包也無法直接查看明文，只能看到2進制或者16進制的數據
• 每次建立的socket連接後本地都會新生成一個key，然後用從服務器獲取到的公鑰對本地的Key進行RSA加密後上傳到服務器，每次在數據發送出去的時候都把數據和Key進行異或操作，在收到數據的時候也對加密數據和本地的Key進行異或操作，因爲對同一個數據進行連續的兩次異或操作會把結果不變，例如：source_data^ key = encrypt_data，encrypt_data ^ key = source_data
• 我們採用Socket而不採用SSLSocket的原因是SSLSocket採用加密增大了傳輸數據，降低了2G網絡環境下的傳輸效率，也不利於弱網環境下的網絡數據傳輸，可能會造成更高的延遲，我們通常在http加密中應用RSA加密是針對一個des的key進行加密，而實際的http body數據體的加密採用的是des對稱加密

網絡通信協議（https://blog.csdn.net/lhd201006/article/details/79044552）

TCP協議

• 三次握手，四次揮手
• 網絡擁塞策略：Nagle算法，滑動窗口，慢啓動，擁塞避免，快速重傳
• TCP連接的全雙工通道
• TCP數據傳輸的粘包問題

長連接

• IM（即時通訊）
• 推送

短連接

• http，https（SSL）

UDP協議

• DNS（域名解析協議）
• DHCP（局域網動態主機配置協議）

抓包分析（wireshark + tcpdump）

網絡問題

• 域名劫持（DNS劫持，local dns沒有及時更新或者域名對應的ip被重定向）
• 長連接的端口劫持（常用端口劫持，例如http的80端口）
• Http內容劫持（運營商的重定向，運營商的網絡緩存）
• Socket異常（UnknownHostException，SocketTimeoutException，NoRouteToHostException等）
• 移動4G的NAT心跳探測問題
• 網絡延遲問題

IM SDK細節實現

Socket編程

• 域名解析時長
• 連接時長
• IO實現阻塞read數據，NIO實現非阻塞select數據
• 數據結束符EOF（read返回-1）

協議包超時機制的實現

• 隊列掃描
• 線程等待

消息分發實現

• 多進程採用廣播
• 單進程採用反射回調

同步通知處理實現

• 針對同一個賬戶的同步通知要按順序處理，等上一個同步通知的響應完成之後才能進行下一個同步通知的處理
• 多線程與隊列管理

AIDL跨進程通信

• 死亡代理
• DeadObjectException異常處理需要unbind後再重新bind才能成功

消息響應處理

• 策略模式實現

IM SDK功耗優化

耗電檢測

• Battery Historian2.0

程序策略優化

• 重連策略
• 智能心跳策略
• 夜間模式（Doze原理）
• 補發心跳（在協議包超時的情況下補發一個心跳，如果心跳正常響應則連接不斷線重連，如果補發心跳超時連接才斷線重連，可以降低連接斷線重連的次數）
• Http請求對齊
• Http轉發
• WakeLock使用

IM SDK穩定性優化

• 崩潰日誌蒐集
• 大數據埋點監控
• 流量監控
• 數據格式編解碼的效率問題（速度和容量大小）

數據存儲與數據共享

• 數據存儲採用SharedPreferences，sqlite數據庫，SD卡文件存儲
• 數據共享採用SD卡文件存儲，contentprovider

多線程編程

• 原子性（java中long類型數據是64位的，在32位的操作系統上進行運算操作是非原子性，可能線程1剛更新完其中的4個字節，線程二就去讀取另外4個字節）
• 可見性（volatile，基礎數據類型的可見性）
• 有序性（JVM指令重排序）

線程池

• ThreadPoolExecutor實現原理
• 隊列實現原理

線程之間的通信

• wait，notify，notifyAll與await，signal，signalAll（https://blog.csdn.net/codingtu/article/details/78431066）
• 線程interrupt
• 線程yield
• 線程sleep

鎖機制

• 可重入鎖與不可重入鎖
• lock與unlock（https://blog.csdn.net/lhd201006/article/details/50986016）
• synchronized

設計模式

• 工廠模式（創建entity）
• 狀態模式（心跳，推送）
• 責任鏈模式（攔截器）
• 單例模式
• 策略模式（消息響應處理）
• 觀察者模式（消息分發給應用）

ANR，OOM問題分析

• 瞭解ANR原理
• OOM問題可以用MAT分析dump出來的hrof文件，查看內存佔用情況
• 看崩潰日誌，看Framework源碼

興趣篇

• Android插件化
• Android熱修復
• Android組件化
• AI與Android日常技術開發的結合
• 大數據與日常業務開發的結合

總結

• 想想兩年前能做出這麼一套IM客戶端體系也是不容易，耗時3年的打磨，策略不斷的優化，包括過程中遇到各種網絡問題的分析，確實很不容易，這的確是一個很有含金量的項目，改變了我自己，也同時改變了一個業務線，基礎性的東西並不是每一個公司都能花時間和經歷去做，努力固然重要，平臺和機會更加重要，即便現在再回顧下，也覺得現在的我都在做些什麼鬼。。。