關於android長連線及休眠喚醒的幾篇文章
移動網際網路應用現狀
因為手機平臺本身、電量、網路流量的限制，移動網際網路應用在設計上跟傳統 PC 上的應用很大不一樣，需要根據手機本身的特點，儘量的節省電量和流量，同時又要儘可能的保證資料能及時到達客戶端。
為了解決資料同步的問題，在手機平臺上，常用的方法有2種。一種是定時去伺服器上查詢資料，也叫Polling，還有一種手機跟伺服器之間維護一個 TCP 長連線，當伺服器有資料時，實時推送到客戶端，也就是我們說的 Push。
從耗費的電量、流量和資料送達的及時性來說，Push 都會有明顯的優勢，但 Push 的實現和維護成本相對較高。在移動無線網路下維護長連線，相對也有一些技術上的難度。本文試圖給大家介紹一下我們極光推送在 Android 平臺上是如何維護長連線。
移動無線網路的特點
因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連線 Internet，就需要通過運營商的閘道器做一個網路地址轉換（Network Address Translation，NAT）。簡單的說運營商的閘道器需要維護一個外網 IP、埠到內網 IP、埠的對應關係，以確保內網的手機可以跟 Internet 的伺服器通訊。
圖片源自 cisco.com.
NAT 功能由圖中的 GGSN 模組實現。
大部分移動無線網路運營商都在鏈路一段時間沒有資料通訊時，會淘汰 NAT 表中的對應項，造成鏈路中斷。
Android 平臺上長連線的實現
為了不讓 NAT 表失效，我們需要定時的發心跳，以重新整理 NAT 表項，避免被淘汰。
Android 上定時執行任務常用的方法有2種，一種方法用 Timer，另一種是AlarmManager。
Timer
Android 的 Timer 類可以用來計劃需要迴圈執行的任務，Timer 的問題是它需要用 WakeLock 讓 CPU 保持喚醒狀態，這樣會大量消耗手機電量，大大減短手機待機時間。這種方式不能滿足我們的需求。
AlarmManager
AlarmManager 是 Android 系統封裝的用於管理 RTC 的模組，RTC (Real Time Clock) 是一個獨立的硬體時鐘，可以在 CPU 休眠時正常執行，在預設的時間到達時，通過中斷喚醒 CPU。
這意味著，如果我們用 AlarmManager 來定時執行任務，CPU 可以正常的休眠，只有在需要執行任務時醒來一段很短的時間。極光推送的 Android SDK 就是基於這種技術實現的。
伺服器設計
當有大量的手機終端需要與伺服器維持長連線時，對伺服器的設計會是一個很大的挑戰。
假設一臺伺服器維護10萬個長連線，當有1000萬用戶量時，需要有多達100臺的伺服器來維護這些使用者的長連線，這裡還不算用於做備份的伺服器，這將會是一個巨大的成本問題。那就需要我們儘可能提高單臺伺服器接入使用者的量，也就是業界已經討論很久了的 C10K 問題。
C2000K
針對這個問題，我們專門成立了一個專案，命名為C2000K，顧名思義，我們的目標是單機維持200萬個長連線。最終我們採用了多訊息迴圈、非同步非阻塞的模型，在一臺雙核、24G記憶體的伺服器上，實現峰值維持超過300萬個長連線。
http://docs.jpush.cn/pages/viewpage.action?pageId=3309821
後記
穩定維護長連線是推送平臺的一個基礎，極光推送團隊將會在這方面長期投入，以保證使用者能有效的節省電量、流量，同時資料能實時送達。
以上是極光推送官方的文章，但是看了之後不免有幾個疑問。
1）他們號稱最高峰值可以達到300W的長連線，但是活躍連結的處理最高是多少呢？
2）訊息的平均長度和限制各是多少？
3）訊息的及時性怎麼樣，延時是多少？
4）不知道現在，極光推送的使用者大概有多少，所以這個峰值是在生產環境，還是測試環境的數值？
5）我想不通的是為什麼，客戶端要用AlarmManager來做推送訊息的獲取？這個訊息獲取還及時嗎？鄙人結識android也有N載。
6）我感興趣的是，不是極光方案一個月推送了幾百萬條資料，而是幾秒鐘或者一分鐘可以處理多少。
===========================================================================================================
Android 訊息推送方案
當我們開發需要與伺服器互動的應用程式時，基本上都需要獲取伺服器端的資料。要獲取伺服器上不定時更新的資訊，一般來說有兩種方法：第一種是客戶端使用pull（拉）的方式，隔一段時間就去伺服器上獲取一下資訊，看是否有更新的資訊出現；第二種就是伺服器使用push（推送）的方式，當伺服器端有更新，則將最新的資訊push到客戶端上，如此以來，客戶端就能自動地接收到訊息。
雖然pull和push兩種方式都能實現獲取伺服器端資料更新的功能，但pull方式的弊端很明顯：費流量、費電，需要我們的程式不停地去監測伺服器端的更新。
首先可以來了解一下iOS和Android平臺的推送機制：
iOS 系統的推送（APNS，即 Apple Push Notification Service）依託一個或幾個系統常駐程序運作，是全域性的（接管所有應用的訊息推送），所以可看作是獨立於應用之外，而且是裝置和蘋果伺服器之間的通訊，而非應用的提供商伺服器。比如騰訊 QQ 的伺服器（Provider）會給蘋果公司對應的伺服器（APNs）發出通知，然後再中轉傳送到你的裝置（Devices）之上。當你接收到通知，開啟應用，才開始從騰訊伺服器接收資料，跟你之前看到通知裡內容一樣，但卻是經由兩個不同的通道而來。
Android的推送有兩種形式，一種是後臺Service，一種是GCM。
不過這裡要指出的是，Android的這種形式和傳統電腦還是有區別的，電腦的後臺是保持程式程序在後臺執行，而Android是在程式後臺Service區域新增一個新的程式專門接收資料。
要說的話，Android的後臺推送機制更加複雜，但是因為可操控部分更多，加上GCM是在2.X之後才加上的而且有可能在系統中並不存在，所以很多軟體都是使用Service這種形式。
本質上，APNs 與 GCM 是類似的技術實現原理：即系統層有一個常駐的 TCP 長連線，一直保持的長連線，即使手機休眠的時候也在保持的長連線。這裡對於大部分人來說，最不理解的就是，休眠時候都保持在那裡的 TCP 長連線，不會耗電很厲害麼？
答案是：不會。這是手機的設計來做到的。TCP長連線有個心跳的時間，在國外可以很長比如30分鐘，在國內則因為網路環境複雜一般10分鐘。客戶端發起的心跳，會短暫地消耗手機電能，但在這個心跳間隔期間，則消耗電能是很少的。當在心跳期間伺服器端有推送資訊過來時，客戶端可以收到並做處理。
這裡有篇文章以 Android 為例做原理解釋：極光推送技術原理：無線網路長連線。
再說 APNs 的設計成功處。
iOS 為了真正地為使用者體驗負責，不允許應用在後臺活動。有了這個限制，但是對於終端裝置，應用又是有必要“通知”到達使用者的，隨時與使用者主動溝通起來的（典型的如聊天應用）。
這就是 APNs 的邏輯所在：iOS 自己做個長駐後臺保持連線。所有應用，有必要（申請）並且被允許（使用者可以改設定）的話，可以通過 APNs 中轉到達使用者。
Android 因為後臺可以長駐，尤其是國內的 Android 的手機上 Google自家的推送服務 GCM 處於基本不可用的狀態。所以，各App各顯神通。聊天類應用的話，大多數直接借用 XMPP 規範裡的一些成果。少量如微信有IM底子的，自己開發協議。這些在實現原理上與 APNs / GCM 沒有本質的區別，但有一定的技術門檻。而大多數普遍應用，要使用推送的話，則使用輪詢的方式簡單實現。
其實，國外如 Urban Airship 自己實現了 Android 上的第三方提供的推送平臺。國內如極光推送也實現了第三方的推送平臺（技術與微信、GCM、APNs類似）。理論上，如果一個 Android 裝置上多款應用都使用極光推送這種第三方推送平臺的話，也可以如 APNs 一樣達到節省電量、流量消耗的效果。
另可參考Android實現推送方式解決方案。
在開發Android的過程中，我們經常用到的WIFI在休眠情況下預設是會不連線的，這個時候當我們需要保持連線時，該如何解決？
不少人說可以在系統設定的WIFI高階選項中將連線設為休眠保持連線，這個辦法的確可行，對於開發者來說很容易辦到，但是對於使用者來說他們一般不會知道這麼設定，這個時候該怎麼辦呢？可以使用如下程式碼解決：
[java]
public void WifiNeverDormancy(Context mContext)
{
ContentResolver resolver = mContext.getContentResolver();
int value = Settings.System.getInt(resolver, Settings.System.WIFI_SLEEP_POLICY, Settings.System.WIFI_SLEEP_POLICY_DEFAULT);
final SharedPreferences prefs=PreferenceManager.getDefaultSharedPreferences(mContext);
Editor editor = prefs.edit();
editor.putInt(mContext.getString(R.string.wifi_sleep_policy_default), value);
editor.commit();
if(Settings.System.WIFI_SLEEP_POLICY_NEVER != value)
{
Settings.System.putInt(resolver, Settings.System.WIFI_SLEEP_POLICY, Settings.System.WIFI_SLEEP_POLICY_NEVER);
}
System.out.println("wifi value:"+value);
}
public void WifiNeverDormancy(Context mContext)
{
ContentResolver resolver = mContext.getContentResolver();
int value = Settings.System.getInt(resolver, Settings.System.WIFI_SLEEP_POLICY, Settings.System.WIFI_SLEEP_POLICY_DEFAULT);
final SharedPreferences prefs=PreferenceManager.getDefaultSharedPreferences(mContext);
Editor editor = prefs.edit();
editor.putInt(mContext.getString(R.string.wifi_sleep_policy_default), value);
editor.commit();
if(Settings.System.WIFI_SLEEP_POLICY_NEVER != value)
{
Settings.System.putInt(resolver, Settings.System.WIFI_SLEEP_POLICY, Settings.System.WIFI_SLEEP_POLICY_NEVER);
}
System.out.println("wifi value:"+value);
}上面這個函式，會自動修改我們WIFI設定中的高階選項，將其設定為一直保持連線。不用使用其他控制元件就可以解決。
需要注意的是此函式在呼叫時必須現在AndroidManifest.xml中宣告許可權
<uses-permission android:name="android.permission.WRITE_SETTINGS"/>
===========================================================================================================
Android設定手機WIFI休眠策略
在開發Android應用中，有很大一部分app是要求手機一直處於網路環境中的。在Android 設定--> WLAN -->點選選單鍵 選擇 高階 -->休眠狀態下保持WLAN連線的下拉列表{始終、僅限充電時、從不(會增加資料流量)}這個設定項中，很多使用者並不知道這個選項的存在，如果設定不為始終，那麼我們鎖屏休眠後，程式將會處於無網路狀態，相應的app使用者會一直處於離線模式，那麼帶來的效果可想而知。
那麼我們開發中，應對這種情況，我們可以在程式首先開啟時，讀取這個值，儲存起來，待程式退出時，將原先儲存的值還原，這樣可以很好的解決上述這個問題。
在Android API中這樣描述：
public static final String WIFI_SLEEP_POLICY Since: API Level 3The policy for deciding when Wi-Fi should go to sleep (which will in turn switch to using the mobile data as an Internet connection).
Set to one of WIFI_SLEEP_POLICY_DEFAULT, WIFI_SLEEP_POLICY_NEVER_WHILE_PLUGGED, or WIFI_SLEEP_POLICY_NEVER.
Constant Value:"wifi_sleep_policy" 那麼我們在開啟應用時，首先取出這個值，上程式碼： private void setWifiDormancy(){ int value = Settings.System.getInt(getContentResolver(), Settings.System.WIFI_SLEEP_POLICY, Settings.System.WIFI_SLEEP_POLICY_DEFAULT);
final SharedPreferences prefs = getSharedPreferences(getString(R.string.wifi_sleep_policy), Context.MODE_PRIVATE);
Editor editor = prefs.edit();
editor.putInt(getString(R.string.wifi_sleep_policy_default), value);
editor.commit();
if(Settings.System.WIFI_SLEEP_POLICY_NEVER != value)
{
Settings.System.putInt(getContentResolver(), Settings.System.WIFI_SLEEP_POLICY, WIFI_SLEEP_POLICY_NEVER);
} } 在應用退出我們需將這個設定的值還原： private void restoreWifiDormancy()
{
final SharedPreferences prefs = getSharedPreferences(getString(R.string.wifi_sleep_policy), Context.MODE_PRIVATE);
int defaultPolicy = prefs.getInt(getString(R.string.wifi_sleep_policy_default), Settings.System.WIFI_SLEEP_POLICY_DEFAULT);
Settings.System.putInt(getContentResolver(), Settings.System.WIFI_SLEEP_POLICY, defaultPolicy);
} 這樣初始設定，退出還原我們可以讓應用一直處於wifi模式下（不過前提是有wifi網路哦）。
from： http://blog.sina.com.cn/s/blog_a85b30ff0101ahzd.html
===========================================================================================================Android 關於休眠的幾個坑點
首先看一下Android Powermanager Class Overview，對Android的幾種不同的休眠模式有個大致瞭解。
如果不進行特別的設定，Android會在一定時間後螢幕變暗，在螢幕變暗後一定時間內，約幾分鐘，CPU也會休眠，大多數的程式都會停止執行，從而節省電量。但你可以在程式碼中通過對Powmanager API的呼叫來設定不同的休眠模式。
Flag Value CPU Screen Keyboard
PARTIAL_WAKE_LOCK On* Off Off
SCREEN_DIM_WAKE_LOCK On Dim Off
SCREEN_BRIGHT_WAKE_LOCK On Bright Off
FULL_WAKE_LOCK On Bright Bright
如上表，最高等級的休眠是螢幕，鍵盤等，cpu都全部休眠。可以設定不同的模式，讓其產生不同的休眠，比如讓cpu保持執行。
設定程式碼如下：
-
PowerManagerpm =(PowerManager)getSystemService(Context.POWER_SERVICE);
-
PowerManager.WakeLockwl =pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK,"My Tag");
-
wl.acquire();
-
..screen will stay on during thissection..
-
wl.release();
我曾經遇到的幾個坑點及解決：
1.向伺服器輪詢的程式碼不執行。
曾經做一個應用，利用Timer和TimerTask，來設定對伺服器進行定時的輪詢，但是發現機器在某段時間後，輪詢就不再進行了。查了很久才發 現是休眠造成的。後來解決的辦法是，利用系統的AlarmService來執行輪詢。因為雖然系統讓機器休眠，節省電量，但並不是完全的關機，系統有一部 分優先順序很高的程式還是在執行的，比如鬧鐘，利用AlarmService可以定時啟動自己的程式，讓cpu啟動，執行完畢再休眠。
2.後臺長連線斷開。
最近遇到的問題。利用Socket長連線實現QQ類似的聊天功能，發現在螢幕熄滅一段時間後，Socket就被斷開。螢幕開啟的時候需進行重連，但 每次看Log的時候又發現網路是連結的，後來才發現是cpu休眠導致連結被斷開，當你插上資料線看log的時候，網路cpu恢復，一看網路確實是連結的， 坑。最後使用了PARTIAL_WAKE_LOCK，保持CPU不休眠。
3.除錯時是不會休眠的。
讓我非常鬱悶的是，在除錯2的時候，就發現，有時Socket會斷開，有時不會斷開，後來才搞明白，因為我有時是插著資料線進行除錯，有時拔掉資料線，這 時Android的休眠狀態是不一樣的。而且不同的機器也有不同的表現，比如有的機器，插著資料線就會充電，有的不會，有的機器的設定的充電時螢幕不變暗 等等，把自己都搞暈了。其實搞明白這個休眠機制，一切都好說了。