TeamTalk Android代碼分析（業務流程篇）
1.1 總體結構
1.總體結構有點類似MVC的感覺,模塊結構從上向下大體是：
UI層：Activity和Fragment構成，期間包括常用的一些開源控件如：imageloader，speedx，gifview等，和下層數據變更通知通過總線事件完成（EventBus）
管理層:Service（即：imservice，下文均采用此稱呼）和一些按照業務划分的Manager(loginmanager,contactmanager,sessionmanager,socketmanager 等)，該層負責業務的流轉和數據接口的提供，
數據和緩存層：才greendao實現，包括一系列業務相關的緩存，緩存的對象在各manager實體中處理。
網絡層：具體由netty實現，獲取或發送數據通過pb協議實現（protobuf）
2.1 登錄過程
1>請求登錄服務器（http），分配消息服務器及其他相關配置
2>鏈接請求消息服務器
3>其中如果網絡連接失敗，采用本地登錄過程，即：在登錄狀態的情況下，沒有網絡也可以查看本地歷史信息。
4>登錄消息服務器成功后，發送總線事件通知imservice
5>imservice初始化各manager，開啟本地和網絡數據請求，本地緩存及其他配置的數據填充。
3.1 ContactManager的初始化操作
3.1.1 本地數據的業務操作
1>數據庫load部門列表，並填充部門map（departmentmap）
2>數據庫load用戶列表，並填充用戶map（usermap）
3>發送總線事件，通知相關界面（聊天／通訊錄／my），並設置該manager數據狀態就緒
相關頁面動作如下：
1>聊天頁面動作：只有session，user，group 數據全部就緒，這個頁面才會更新，稍后再詳細分析
2>通訊錄頁面動作：
（1）設置用戶tab數據，更新ui
（2）設置部門tab數據，更新ui
（3）用戶和部門數據就緒，搜索狀態可操作
3>通過loginmanager獲取登錄信息，更新ui（這個位置的觸發，可以放置在登錄成功后及時事件通知）
3.1.2 網絡數據的業務操作
1>按照本地存儲的最后時間點作為參數，請求部門列表
2>按照本地存儲的最后時間點作為參數，請求用戶列表
3>獲取部門數據：
1）緩存map
2）存儲db
3）發送總線事件（userinfoevent事件，user_info_update）,通知頁面更新ui
涉及頁面有：通訊錄頁面：用戶列表ui／部門列表ui／用戶詳細信息（userinfofragment），如果頁面收到通知，則獲取緩存數據，更新ui
4>獲取用戶數據：
1）緩存usermap
2）存儲db
3）發送總線事件更新ui，頁面響應同部門數據。
注意事項:通知頁面更新的總線事件，考慮采用poststicky 形式。
3.2 GroupManager的初始化操作