開源壹個自用的Android IM庫，基於Netty+TCP+Protobuf實現。
在此期間，我們發現了壹個很重要的問題，就是ChannelInboundHandlerAdapter的channelInactive和exceptionCaught方法在再次登錄或者網絡狀態發生變化時可能會無限觸發。
在channelInactive和exceptionCaught中，我們使用自動重連，但是會發現壹個問題。在重新連接成功的情況下，我們會壹次又壹次地重新連接。
如果用戶主動退出，比如用戶主動退出聊天或者殺死App，這種情況下，不需要重新連接。
通道中所有未捕獲的異常都將觸發exceptionCaught方法。例如，如果後臺返回的數據格式不正確，並且生成了未捕獲的異常，它將觸發exceptionCaught。因此，在ChannelInboundHandlerAdapter的各種方法中，最好不要出現未處理的業務邏輯異常。
那天解決了這兩個問題，連續重連的Bug沒有再出現，以為問題解決了，我高高興興回家了。結果第二天就出現了持續重連的問題，不過這次出現是因為我註銷後重新登錄。
首先，這次連續重連的原因是第二次登錄後才會重連。即使是第二次登錄，IM的所有相關連接和組件都會重新初始化，所以我會先放重連方法(CTX)；註釋壹下。第二次登錄後，發現重新連接問題不再重復。所以基本可以確定重連方式壹定是出現了某種異常或者動作，導致了當前連接的主動關閉。
我在channelInactive()方法中中斷了斷點。通過堆棧信息，我看到了觸發channelInactive()方法的條件:was active &；& ampisActive()
看到這裏，我就能理解為什麽會出現持續重連的問題了:
因為我在重新連接之前停止了所有的IM連接，包括線程池，具體方法如圖所示:
在關閉通道之前，清除通道中的各種句柄，如圖所示。
1:處理好每個處理程序中的透明邏輯，否則將是壹場噩夢！
2.在每個重寫方法中，確認是否需要調用父類的重寫方法，比如是否需要調用super.channelInactive()，其本質同上。
3:如果有用，請點壹個喜歡的。