前言：年總了，針對今年的一些工作進行總結，重新整理了發出來共享討論。
一、概述
1、背景
提高與tigase通信的穩定性，降低因為代碼混亂引起開發難度及開發出現的內測問題BUG等。
現有的xmpp框架使用第三方庫libjingle，使用時存崩潰風險；現有的xmpp框架的可維護性低，開發修改存在較大風險。
2、說明
本設計文檔作為模塊的設計文檔，為編碼的依據。
二、分析
1、Libjingle庫的分析
1）、分析libjingle的庫，得出如下類圖：
2）、分析相關使用：
l xmpp的所有操作都是放在一個獨立現場處理的。XmppThread的消息隊列、PresenceReceiveTask是線程安全的；除此之外對外暴露的接口都不是現場安全的。
l 分析發送方式
1、示例PresenceOutTask首先它不是現場安全的，如果使用需要自己加鎖。
2、通過XmppThread的消息隊列來達到發送的方式。
2、代碼中使用存在的問題：
1）、線程對象每次重新刪除，容易引起線程出錯：XmppThread
2）、線程對象刪除后，該對象為空，使用該對象發送消息會崩潰：buzz::XmppClient*
3）、任務不要要自己刪除，libjingle會自己刪除：buzz::XmppTask
4）、通信模塊和業務模塊混合在一起，結構不清晰、混亂。如連接模塊的連接邏輯、重連邏輯和真正的通信邏輯混雜在一起，已日趨復雜與不可讀。
三、設計
1、兩層模塊，分為通信層和通信相關業務邏輯層。
通信層作為通信的基礎框架，只做通信相關的處理。
xmpp的業務邏輯層，比如收到的狀態維護等。
2、通信層（Xmpp Net Module）；
通信層只關心與同向相關的內容，不涉及具體業務。
解決問題：
1、通信層的線程不刪除。
2、為保證注銷之后的發送數據等是正常的，重新創建了底層通信模塊。
3、接受任務不自己刪除，由底層通信模塊刪除。
4、發送任務通過線程的消息隊列投遞發送。
3、業務邏輯層處理（Xmpp Logic）
XmppApp：業務邏輯對象與通信層對象轉換模塊。
ConnManaager：連接管理，連接、斷線、重連等。
PresenceManager: 狀態管理，狀態的發送和其他用戶狀態變化管理。
MessageManager：消息管理，消息的發送和接受。
IQManager：IQ管理，包括IQACK的注冊和IQNOTICE的發送和接受。
