首先是看到其他一篇博客上的一段直接摘錄過來：
一般而言長連接已經(jīng)是App的標(biāo)配了，推送功能的實(shí)現(xiàn)基礎(chǔ)就是長連接，當(dāng)然了我們也可以通過輪訓(xùn)操作實(shí)現(xiàn)推送功能，但是輪訓(xùn)一般及時(shí)性比較差，而且網(wǎng)絡(luò)消耗與電量銷毀比較多，因此一般推送功能都是通過長連接實(shí)現(xiàn)的。
那么如何實(shí)現(xiàn)長連接呢？現(xiàn)在一般有這么幾種實(shí)現(xiàn)方式：
使用第三方的長連接服務(wù)；
通過NIO等方案實(shí)現(xiàn)長連接服務(wù)；
通過MINA等第三方框架實(shí)現(xiàn)長連接；
幾種長連接服務(wù)的具體實(shí)現(xiàn)，以及各自的優(yōu)缺點(diǎn)。
1. 使用第三方的長連接服務(wù)
介紹：這是最簡單的方式，我們可以通過接入極光推送，百度推送，友盟等第三方服務(wù)實(shí)現(xiàn)長連接，通過接入第三方的API我們可以很方便的接入第三方的長連接，推送服務(wù)，但是這種方式定制化程度不太好，如果對長連接服務(wù)不是要求特別高，對定制化要求不是很高的話基本可以考慮這種方式（目前主流的App都是使用第三方的長連接服務(wù)）
優(yōu)勢：簡單，方便
劣勢：定制化程度不高
2. 使用NIO等方案實(shí)現(xiàn)長連接服務(wù)
介紹：通過NIO的方式實(shí)現(xiàn)長連接，這種方式對技術(shù)要求程度比較高，基本都是通過java API實(shí)現(xiàn)長連接，實(shí)現(xiàn)心跳包，實(shí)現(xiàn)異常情況的容錯等操作，可以說通過NIO實(shí)現(xiàn)長連接對技術(shù)要求很高，一般如果沒有成行的技術(shù)方案比建議這么做，就算實(shí)現(xiàn)了長連接，后期連接的維護(hù)，對電量，流量的損耗等都需要持續(xù)的優(yōu)化。
優(yōu)勢：定制化比較高
劣勢：技術(shù)要求高，需要持續(xù)的維護(hù)
3. 使用MINA等第三方框架實(shí)現(xiàn)長連接
介紹：MINA是一個(gè)第三方的NIO框架，該框架實(shí)現(xiàn)了一整套的長連接機(jī)制，包括長連接的建立，心跳包的實(shí)現(xiàn)，異常機(jī)制的容錯等。使用MINA實(shí)現(xiàn)長連接可以定制化的實(shí)現(xiàn)一些特有的功能，并且比NIO方案較為簡單，因?yàn)槠湟呀?jīng)封裝了一些長連接的特有機(jī)制，比如心跳包，容錯等。
優(yōu)勢：可定制，較NIO方法簡單
劣勢：也需要一定的技術(shù)儲備
長連接具體實(shí)現(xiàn)
在我們的Android客戶端中長連接的實(shí)現(xiàn)機(jī)制采用–MINA方式。這里多說一句，一開始的長連接采用的是NIO方案，但是采用這種方案之后踩了很多坑，包括心跳，容錯等機(jī)制都是自己寫的，所以耗費(fèi)了大量的時(shí)間，而且對手機(jī)電量的消耗很大，最后決定使用MINA NIO框架重新實(shí)現(xiàn)一遍長連接，后來經(jīng)過實(shí)測，長連接的穩(wěn)定性還有耗電量，流量的消耗等指標(biāo)方面有了很大的提高。
下面我將簡單的介紹一下通過NIO實(shí)現(xiàn)長連接的具體流程：
引入MINA jar包，在App啟動頁面，登錄頁面啟動長連接；
創(chuàng)建后臺服務(wù)，在服務(wù)中創(chuàng)建MINA長連接；
實(shí)現(xiàn)心跳包，重寫一些容錯機(jī)制；
實(shí)現(xiàn)長連接斷了之后的重連機(jī)制，并且重連次數(shù)有限制不能一直重連；
長連接斷了之后實(shí)現(xiàn)輪訓(xùn)操作，這里的輪訓(xùn)服務(wù)只有在長連接斷了之后才啟動，在長連接恢復(fù)之后關(guān)閉；
在剛開始接觸Mina的時(shí)候呢，看到了郭神在imooc上的andorid推送的教學(xué)視頻，也是采用了Mina框架。
簡單說下Mina的優(yōu)勢：
1、非常適合C/S架構(gòu)的通信項(xiàng)目
2、Apache出品的開源項(xiàng)目，值得信賴
3、官網(wǎng)上有詳細(xì)的資料供開發(fā)者學(xué)習(xí)
4、使用起來非常簡單，降低學(xué)習(xí)成本。
