這幾天一直在準備考試，總算有個半天時間可以休息下，寫寫部落格。
如何讓service keep alive是乙個很常見的問題。
但是android並沒***service有這樣功能，畢竟乙個系統面對的是使用者，必然以對使用者友好為先。
這兩個方案有些地方需要說明和改進，然後還會有其他方案補充進來。
方案一的做法有點「偷懶」。因為相當於把這個難題轉移給推送服務提供者來處理，或者說，只需要依靠推送，就不需要自己去考慮存活問題。
推送一直是移動客戶端開發的熱門話題（實際上也是傳統軟體開發的熱門話題）。
一般情況下，c/s結構（b/s是特殊的c/s結構）中的業務流程是這樣的：客戶端主動向伺服器端發出請求，伺服器端響應請求，建立二者之間的連線。通過建立的鏈結，雙方可以傳送/接收資料。最後客戶端和伺服器端斷開連線。也就是說，客戶端是主動方，是請求連線的發起者；伺服器端保持對某個埠的監聽（0-1023是系統埠號，比如80埠被指派給http），而被動地等待客戶端的連線請求。
那麼推送指的是，伺服器端在沒有收到請求的情況下主動向客戶端傳送資訊，比如伺服器端收到一封郵件後主動發往郵件的客戶端。
推送是如何實現的呢？首先，伺服器端的功能還是不變，監聽某個埠等待請求。然後我們可以看到，伺服器端能主動傳送資訊的唯一時間段就是在建立了伺服器端到客戶端的連線之後、二者斷開連線之前。因此，推送的實現就是基於保持伺服器端和客戶端的連線一直存在，方式可以是持續連線或者輪詢。
當然，這個方案有個缺點是，當某些手機助手無腦式結束掉全部的非系統程序時，service無法存活。
當返回值為該值時，service被kill之後會被系統自動重啟。
同時，在service的ondestroy（）中重啟service，可以給service的重啟做雙重保證。
即除了你需要存活的service外，專門寫乙個service，並使該service執行在另乙個程序中。
當兩個service中有乙個service被kill，就在另乙個service中去重啟該service。
從手機中qq被手動kill後系統出現的對話方塊判斷，手機qq正是使用的這一方案。
可以用broadcastreceiver去接收系統的廣播，比如時間變化的廣播、電量變化的廣播等。
這樣基本上service就無法被kill了。
能保證service完全不會被殺死的方案是方案一和方案六。
比較輕量的方案是方案二和方案三。
我個人認為比較好的方案是方案四和方案五——那些大廠選擇這樣的方案是有道理的。具體使用哪個得看自己的需求。
android中儲存路徑
string dir environment.getexternalstoragedirectory getabsolutepath tencent micromsg weixin 注意 environment.getexternalstoragedirectory 返回的路徑中最後乙個字元不是 如...
iOS開發中保持使用者登入狀態
一 利用儲存cookie值實現 1 第一次登入成功後保持cookie 儲存登入的cookie 之後每一次登入成功也一樣。nsarray cookies02 nskeyedunarchiver unarchiveobjectwithdata nsuserdefaults standarduserdef...
IIS中保持HTTP連線的設定方法
大多數 web 瀏覽器要求伺服器在多個請求中保持連線開啟。這被稱為保持 http 連線。保持連線是乙個 http 規範，它能夠顯著增強伺服器效能。如果沒有它，瀏覽器將必須為包含多個元素 如圖形 的頁進行大量的連線請求。可能需要為每個元素進行單獨連線。這些額外的請求和連線要求額外的伺服器活動和資源，這...