一、背景

網絡管理層是各上層業務都要用到的層級，為提供更高效率、更高質量的服務，需對網絡服務層進行重構。

二、重構目標

1、提供連接管理

在App整個運行過程中，始終向上層業務提供兩條有效的長連接（雲端連接和路由器連接），並支持在網絡斷開、心跳失敗後的重連機制.

2、自動登陸(已實現)

在長連接重建後, 自動登陸服務器.

3、自動同步(已實現)

在長連接重建後、並自動登陸服務器後, 自動同步本地信息到雲平臺/路由器.

4、網絡服務代理層RemoteProxy

RemoteProxy作為對上層業務的唯一網絡接口,

5、獨立出同步功能

將同步功能從ControlPad和logincenter中抽取出來，作為獨立的公共庫hdsync。

三、重構方案

3.1 網絡整體框架構思

圖1為《智能家居APP架構說明》中描述的網絡整體框架構思圖，本方案基於此架構構思進行設計。

圖1網絡整體框架

3.2 網絡框架工作流程

圖2描述了網絡庫重構方案的原理主流程。

本次網絡庫重構，重點在於網絡連接管理，網絡連接管理主要處理兩種場景：網絡發生變化和心跳包異常。

在網絡狀態監聽器發現網絡發生變化時，如果網絡斷開，此時網絡庫會重置同雲平臺和路由器長連接的狀態；如果網絡恢復連接，則網絡庫會嘗試重新與雲平臺和路由器建立新的長連接，在同雲平臺和路由器建立新的長連接後，網絡庫將調用logincenter庫的登陸邏輯，以自動登陸雲平臺和路由器，待登陸成功後，便將本地信息同步到雲平臺和路由器。

圖2 網絡庫重構方案主流程

圖3描述了心跳檢測機制，網絡庫每隔60s發送一次心跳檢測包，然後將heartBeatFlag減1, heartBeatFlag初值為3, 當收到雲平臺/路由器的心跳響應時，網絡庫將 heartBeatFlag重新設置為3。如果網絡庫連發三個心跳包都沒有收到雲平臺/路由器的心跳響應，那麽網絡庫在準備發第四個心跳檢測包前，會重置雲平臺/路由器的長連接狀態（斷開連接並發出長連接斷開通知）。

圖3心跳檢測機制

3.3 網絡庫框架

圖3描述了網絡庫框架的架構設計。

圖3中粉色背景部分為本次網絡庫重構的新增（修改）部分，構建RemoteProxy（遠程服務代理）類，

RemoteProxy類的功能如下：

• 作為網絡庫與上層業務唯一的通信接口；管理TCP連接的建立、連接、維護、關閉；
• 自動接入Sec、LB、Biz服務器；
• 可自動路由業務TCP命令走雲平臺或路由器；
• 監聽網絡狀態；
• 維持有效的同雲平臺、路由器的長連接。

圖3中黃色背景部分為工程代碼間的相互移動部分，HdNetworkService原來位於主工程ControlPad中，由於其功能邏輯與網絡庫（心跳發送）密切相關，故本次重構會將其移動至網絡庫hdnetworklib中。

圖3網絡庫框架

圖4描述了網絡庫框架同其他庫的關系。

圖4中的粉色部分為本次重構新增的部分，除前面介紹的網絡庫新增、修改、移動的代碼部分，還包括將原網絡庫中DeviceManager、FamilyManager、RoomManager、UpgradeManager等與具體業務強相關的管理類移到ControlPad主工程。

此外，將信息同步的代碼邏輯從logincenter中抽取出來，形成獨立的信息同步模塊hdsync。

從圖4中可看出，重構後的網絡庫，可面向除XXXHome外不同的App。

圖4網絡庫框架同其他庫的關系

圖5描述了重構前的網絡庫類結構及與其他庫的關系。

圖5中用紅色標示的類為歸類存放不合理的類，在本次重構時需要調整其存放位置，以SyncTaskService和LoginStatusReceiver為例子，其原來的設計目的是為了監聽用戶登陸成功的消息後，便通知同步任務服務去做同步信息相關的事情，但現在SyncTaskService和LoginStatusReceiver存放在主工程ControlPad中，考慮到同步功能應獨立出來作為一個模塊，也便於今後對同步模塊的需求做進一步擴展，故本次需對分散在ControlPad和hdlogincenter同步代碼進行抽取，然後歸集在hdsync模塊。

圖5 重構前網絡庫類結構及與其他庫的關系

圖6 描述了重構後的網絡庫類結構及與其他庫的關系。

圖6 黃色背景標識的類為本次重構新增的類，RemoteProxy為網絡訪問的唯一入口，RouteStrategy為選擇雲平臺還是路由器通道的路由功能類，CloudRemote維護了一條雲平臺長連接和經由該長連接與雲平臺通信的邏輯、RouteRemote維護了一條路由器長連接和經由該長連接與路由器通信的邏輯。

圖6重構後網絡庫類結構及與其他庫的關系

圖7為圖6的詳細類圖，描述了重構後網絡庫詳細類圖及與其他庫的關系。

圖7重構後網絡庫詳細類圖及與其他庫的關系

圖8描述了在網絡良好情況下，重構後的網絡庫發送Tcp請求的時序圖。

圖9描述了在網絡不好情況下，重構後的網絡庫發送Tcp請求的時序圖。

圖8重構後發送Tcp請求的時序圖（網絡良好）

圖9重構後發送Tcp請求的時序圖（網絡不好）

3.4 後臺服務接入流程改造（建議）

目前網絡庫連接Sec、LB、BIZ服務器需要建立3次TCP連接，有以下缺點：

• 不安全

將Sec服務器、LB服務器地址暴露在網絡上，易遭到黑客攻擊。

• 降低效率
• 影響用戶體驗

使用戶的等待時間加長，並產生更多的流量。

• 不利於後期運營維護

Sec服務器、LB服務器域名發生變更，App必須重新發包。

建議和雲服務溝通，將模式修改為建立一個代理服務器，由代理服務器完成與Sec、LB服務器的通信，App只需訪問代理服務器以獲取BIZ地址並建立與BIZ的長連接，參見圖10後臺服務接入模式新舊方案對比。

圖10 後臺服務接入模式新舊方案對比

四、總結

網絡框架重構設計