最近在搞即時訊息推送。瞭解了推送服務實現的基本原理。通過長連線去實現及時的推送，或者通過輪詢的方式去實現偽及時的推送。當然，通常我們選擇前者。如果實現長連線就要用到socket，所以簡單瞭解了下socket程式設計。又因為伺服器端需要考慮大併發、效能方面的問題。直接使用socket在效能上無法保證，需要使用java提供的非阻塞式的高伸縮性的網路I/O：nio;因為nio程式設計比較複雜，開發過程中都是使用現有的框架：MINA或者Netty。我們開發的推送服務是基於AndroidPN這個開源專案實現的。AndroidPn伺服器端使用的就是MINA框架。然後又去了解了一下MINA伺服器。有了上面的一些理論基礎後，就去開開心心的看AndroidPn的原始碼，修改裡面的BUG，去實現自己需要的功能。這裡並不去過多的介紹AndroidPn。從上週的工作內容講起。

          推送服務基本實現後，開始著重考慮客戶端一直存在的問題。我們都知道要想實現即時的通訊。就必須在客戶端和伺服器端之間建立一個長連線。而在Android客戶端要想維持這個長連線，就要在後臺開個單獨的程序去維護這個長連線。我的噩夢開始了，使用者可以選擇隨時清空系統記憶體。或者動不動就按下一鍵加速什麼的。那麼我們執行在後臺的為了保證及時通訊的長連線的服務就會隨時被殺掉。大家最常用的辦法就是在JNI裡面fork出子程序,然後監視 service程序狀態,被系統殺死了就重啟它。這個辦法在5.0之後已經不起作用了。為什麼5.0上面就不行了呢,咱們看一下activitymanagerservice,LBE的清理記憶體應該呼叫的killBackgroundProcesses,看看他們有什麼區別

   5.0的程式碼：

 Process.killProcessQuiet(app.pid);
 Process.killProcessGroup(app.info.uid, app.pid);

   Process.killProcessQuiet(app.pid);

 5.0中增加了Group的概念，對同一應用的程序進行統一管理了。當然我們還可以通過一些其他的方式來保證我們的服務長期執行，比如監聽系統廣播，使用者一開機，或者使用者手機網路發生變化的時候就去啟動我們的服務等等這些“見不得人的”辦法。作為有良知的程式設計師，我們深知這種流氓做法並不可取，但是在需求面前，程式設計師是沒有自己的。不過這種方式效果不盡人意。監聽的各種廣播在某些ROM比如小米的MIUI，預設是關閉的，需要使用者手動開啟，哎，至少到目前為止，我還沒開發出來能讓使用者欣喜若狂的選擇開機啟動、監聽各種各樣的系統廣播的APP ╮(╯▽╰)╭。然後我就想是不是其他開發人員是不是也跟我有同樣的煩惱，他們是不是也在想盡辦法來讓自己的服務能夠儘可能長的在後臺執行。去網上查了下，這方面的內容很多，提供了各種各樣的解決辦法，目的也多半都是為了保證伺服器可以即時的與客戶端進行通訊。為什麼Android的手機這麼卡，為什麼電池會用的那麼快。其中一個原因，每個程式都後在後臺建立一個長連線，並不斷髮送心跳包去保證自己的APP可以收到訊息。如果你的APP很不巧的集成了不同廠商提供的推送服務。或者連結的自己搭建的推送伺服器。那麼你要及時清理你的後臺應用了，不然會有N多個長連線去不斷的傳送心跳包，去強姦你的記憶體、電量、流量，並且沒人為此負責。這也是Android手機效能如此強悍，電池容量如此之大，仍然不敵iPhone的原因之一。

     那麼蘋果的是怎麼去管理推送的呢。Iphone在系統層建立了一個長連線，去連線你的手機裝置和蘋果自家的推送伺服器APNS(Apple Push NotificaitonService)；這個長連線是全域性的、獨立於每一個APP之外的。應用提供商把訊息推送給APNS，APNS藉助於系統級的長連線把訊息推送給客戶端。這樣應用本身就不用常駐的後臺程序去管理長連線（當然蘋果也不允許你這麼做）。當蘋果把大量的資源開銷放在了雲端，而非裝置上，手機系統開銷小了，手機更流暢，電量更耐用。

這是APNS的邏輯所在：IOS系統自己做個長連線。所有應用都必須申請、並且允許才能通過雲端伺服器把訊息通過系統級的長連線傳送過來。

這樣帶來的好處是實實在在的：

                ①  安全：只有登陸過的開發者可以通過蘋果的伺服器推送訊息。

                ②  快速、穩定、可靠：蘋果自己掌控長連線和推送伺服器。

                ③  更省電、省記憶體、省流量

                ④  整個系統的體驗更加一致和簡單。不用考慮殺記憶體這種腦殘事，更不會出現殺記憶體收不到推送的蛋疼                           事。

         為什麼Android不自己搞個類似的功能呢。其實Android也有，叫GCM(Google Clond Message)。而且在國外很多應用也是用這個服務進行推送的。比如WhatsApp、推特等。但是在國內使用的GCM去推自己訊息應該沒幾家吧。原因：

              ① GCM作為谷歌的服務經常被牆；

              ② GCM設定的心跳間隔過長，並不適合國內比較坑的網路環境；

              ③ 國內的第三方ROM會把GCM閹割掉；

              ④ 需要繫結Google賬號（此要求在Android4.0.4版本後解除）……

總之GCM在國內水土不服。所以Google把GCM做成了可選項。而不是像蘋果那樣去讓第三方開發商強制接入APNS。這個除了因為Android更開放之外，更多的可能是Google的無奈。他們的決策層肯定也清楚的知道讓程式設計師們自己去實現一個服務維護各自應用與推送伺服器的長連線會把系統資源搞得亂七八糟的，是各種坑爹的。但是市場環境如此。Google的服務何時能夠王者歸來，何時不再放縱手機廠商任意閹割google服務，還是個未知數。（借用網友的一張圖）

        基於以上事實，我們會發現國內各種推送平臺應運而生。百度推送、極光推送、友盟推送、信鴿推送、個推…..這些都是GCM的替代品。如果這些推送能夠互相殘殺，並最終實現一家獨大，原理上我們就可以實現APNS那樣的效果。因為上面這些推送有些是單通道的。意思就是如果你的手機上的所有應用都使用的百度的推送，實際上這些應用使用的是同一條通道，同一個長連線。跟APNS的原理一致。但事實上是推送市場列國混戰，每個廠商身後都有個網際網路巨頭，每個廠商都用免費去吸引更多的APP接入到自家平臺。目的很簡單，當用戶量足夠大的時候就變成了一種隱形的標準。大家都在我這玩。你不來我這，就沒法和大家一起玩耍。所以每個廠家都去搶佔APP的流量入口。以期在將來的網際網路大戰中佔得先機。所有在想Android端去體驗iPhone那樣穩定、快速、可靠的推送服務，還遙遙無期。使用第三方推送有些人擔心一件事情：他們免費給我們用是為了獲取我們的資料，去做資料分析，去搞見不到人的事。我只能說，就你那app的使用者量，就你推送的那點資料，你自己都不想做資料分析，也好意思！雖然我不能排除雲服務廠商會那樣去做。但是因為這個原因去否定雲服務，只能說有些頑固不化了。

       除了使用第三方的推送服務，也可行自己搞一個出來，正如我們公司現在做的那樣，為什麼自己要開發一套推送服務呢。主要有幾個方面的考慮：

                    ①  我們的資料的的確確不能讓外部知道，是絕對的保密的。

                    ②  出於工作環境的考慮，我們的客戶端和伺服器端都無法與外部連結，是執行在區域網內的。

                    ③  我們不想受制於人，把權力掌握在自己手裡，哪怕能力原因我們受制於自己。

                    ④  出於工作成果的考慮，相比於花幾個小時整合第三方的推送服務，自己搭建一套推送服務，要顯                                  得牛逼的多O(∩_∩)O~。

           寫在最後：Android的推送服務還是比較坑的，不管是整合第三方還是自己搭建一套推送伺服器，都無法實現像APNS那樣優雅的推送。使用第三方的推送服務，尤其是使用了市場佔有率比較高的推送服務，那麼我們推送的到達率相對而言要高些。使用自己搭建的伺服器或者使用了比較小眾的第三方推送平臺，我們在後臺維護的那個長連線相比於百度或者騰訊的長連線更容易被殺掉。我們可能同時有幾個應用程式都集成了百度的推送，那麼集成了百度推送的APP在前臺執行的概率就會大一些，維持著長連線的程序更容易存活。我們的APP可以與推送伺服器保持更好的連線，正如我們前面提到的，他是單通道的。而自己開發維護的長連線可能並沒那麼幸運。如果應用程式沒有開啟，基本是接收不到訊息的，除非我們的APP足夠流氓，怎麼都殺不死。永遠在後臺執行。搭建一套推送伺服器的開發成本，和維護成本對於小企業是很難接受的。對於開發人員：如果有機會自己搭建一套推送伺服器，還是很難得的，畢竟很少有企業願意花大量時間讓你研究這個東西。相比於整合第三方的推送服務，自己開發，能讓我們對推送的原理、機制有比較深刻的認識，甚至對Android的執行機制有一些新的認識。另外，在一定程度上，也有利於我們去比較和衡量不同推送服務提供商的產品的優劣，做出更合理的選擇。

           （第一次發文章，好激動，可能有理解不對的地方，求吐槽）