長連接android
⑴ android怎麼實現HTTP長連接
轉載 這種功能實際上就是數據同步，同時要考慮手機本身、電量、網路流量等等限制因素，所以通常在移動端上有一下兩個解決方案: 1.一種是定時去server查詢數據，通常是使用HTTP協議來訪問web伺服器，稱Polling（輪詢）； 2.還有一種是移動端和伺服器建立長連接，使用XMPP長連接，稱Push（推送）。 從耗費的電量、流量和數據延遲性各方面來說，Push有明顯的優勢。但是使用Push的缺點是： 對於客戶端：實現和維護相對成本高，在移動無線網路下維護長連接，相對有一些技術上的開發難度。 對於伺服器：如何實現多核並發，cpu作業調度，數量龐大的長連接並發維護等技術，仍存在開發難點。 在講述Push方案的原理前，我們先了解一下移動無線網路的特點。 移動無線網路的特點： 因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網路地址轉換（Network Address Translation，NAT）。簡單的說運營商的網關需要維護一個外網 IP、埠到內網 IP、埠的對應關系，以確保內網的手機可以跟 Internet 的伺服器通訊 GGSN（Gateway GPRS Support Node 網關GPRS支持結點）模塊就實現了NAT功能。 因為大部分移動無線網路運營商都是為了減少網關的NAT映射表的負荷，所以如果發現鏈路中有一段時間沒有數據通訊時，會刪除其對應表，造成鏈路中斷。（關於NAT的作用及其原理可以查看我的另一篇博文：關於使用UDP(TCP)跨區域網，NAT穿透的心得） Push在Android平台上長連接的實現： 既然我們知道我們移動端要和Internet進行通信，必須通過運營商的網關，所以，為了不讓NAT映射表失效，我們需要定時向Internet發送數據，因為只是為了不然NAT映射表失效，所以只需發送長度為0的數據即可。 這時候就要用到定時器，在android系統上，定時器通常有一下兩種： 1.java.util.Timer 2.android.app.AlarmManager 分析： Timer:可以按照計劃或者時間周期來執行相關的任務。但是Timer需要用WakeLock來讓CPU保持喚醒狀態，才能保證任務的執行，這樣子會消耗大量流量；當CPU處於休眠的時候，就不能喚醒執行任務，所以應用於移動端明顯是不合適。 AlarmManager：AlarmManager類是屬於android系統封裝好來管理RTC模塊的管理類。這里就涉及到RTC模塊，要更好地了解兩者的區別，就要明白兩者真正的區別。 RTC（Real- Time Clock）實時鬧鍾在一個嵌入式系統中，通常採用RTC 來提供可靠的系統時間，包括時分秒和年月日等;而且要求在系統處於關機狀態下它也能夠正常工作（通常採用後備電池供電），它的外圍也不需要太多的輔助電路，典型的就是只需要一個高精度的32.768KHz 晶體和電阻電容等。（如果對這方面感興趣，可以自己查閱相關資料，這里就說個大概） 好了，回來正題。所以，AlarmManager又稱全局定時鬧鍾。這意味著，當我用使用AlarmManager來定時執行任務，CPU可以正常地休眠，只有在執行任務是，才喚醒CPU，這個過程是很短時間的。 下面簡單來說明其使用： 1.類似於Timer功能： //獲得鬧鍾管理器 AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE); //設置任務執行計劃 am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000, sender);//從firstTime才開始執行，每隔5秒再執行 2.實現全局定時功能： //獲得鬧鍾管理器 AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE); //設置任務執行計劃 am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 5*1000, sender);//從firstTime才開始執行，每隔5秒再執行 總結：在android客戶端使用Push推送時，應該使用AlarmManager來實現心跳功能，使其真正實現長連接。
⑵ 如何實現android和伺服器的長連接
轉載 這種功能實際上就是數據同步，同時要考慮手機本身、電量、網路流量等等限制因素，所以通常在移動端上有一下兩個解決方案:
1.一種是定時去server查詢數據，通常是使用HTTP協議來訪問web伺服器，稱Polling（輪詢）；
2.還有一種是移動端和伺服器建立長連接，使用XMPP長連接，稱Push（推送）。
從耗費的電量、流量和數據延遲性各方面來說，Push有明顯的優勢。但是使用Push的缺點是：
對於客戶端：實現和維護相對成本高，在移動無線網路下維護長連接，相對有一些技術上的開發難度。
對於伺服器：如何實現多核並發，cpu作業調度，數量龐大的長連接並發維護等技術，仍存在開發難點。
在講述Push方案的原理前，我們先了解一下移動無線網路的特點。
移動無線網路的特點：
因為 IP v4 的 IP 量有限，運營商分配給手機凳褲終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網路地址轉換（Network Address Translation，NAT）。簡單的說運營商的網關需要維護一個外網 IP、埠到內網 IP、埠的對應關系，以確保內網的手機可以跟 Internet 的伺服器通訊
GGSN（Gateway GPRS
Support Node 網關GPRS支持結點）模塊就實現了NAT功能。
因為大部分移動無線網路運營商都是為了減少網關的NAT映射表的負荷，所以如果發現鏈路中有一段時間沒有數據通訊時，會刪除其對應表，造成鏈路中斷。（關於NAT的作用及其原理可以查看我的另一篇博文：關於使用UDP(TCP)跨區域網，NAT穿透的心得）
Push在Android平台上長連接的實現：
既然我們知道我們移動端要和Internet進行通信，必須通過運營商的網關，所以，為了不讓NAT映射表失效，我們需要定時向Internet發送數據，因為只是為了不然NAT映射表失效，所以只需發送長度為0的數據即可。
這時候就要用到定時器，在android系統上，定時器通常有一下兩種：
1.java.util.Timer
2.android.app.AlarmManager
分析：
Timer:可以按照計劃或者時間周期來執行相關的任務。但是Timer需要用WakeLock來讓CPU保持喚醒狀態，才能保證任務的執行，這樣子會消耗大量流量；當CPU處於休眠的時候，就不能喚醒執行任務，所以應用於移動端明顯是不合適。
AlarmManager：AlarmManager類是屬於android系統封裝好來管理RTC模塊的管理類。悔粗銷這里就涉及到RTC模塊，要更好地了解兩者的區別，就要明白兩者真正的區別。
RTC（Real- Time Clock）實時鬧鍾在一個嵌入式系統中，通常採用RTC
來提供可靠的系統時間，包括時分秒和年月日等;而且要求在系統處於關碧游機狀態下它也能夠正常工作（通常採用後備電池供電），它的外圍也不需要太多的輔助電路，典型的就是只需要一個高精度的32.768KHz
晶體和電阻電容等。（如果對這方面感興趣，可以自己查閱相關資料，這里就說個大概）
好了，回來正題。所以，AlarmManager又稱全局定時鬧鍾。這意味著，當我用使用AlarmManager來定時執行任務，CPU可以正常地休眠，只有在執行任務是，才喚醒CPU，這個過程是很短時間的。
下面簡單來說明其使用：
1.類似於Timer功能：
//獲得鬧鍾管理器
AlarmManager
am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000,
sender);//從firstTime才開始執行，每隔5秒再執行
2.實現全局定時功能：
//獲得鬧鍾管理器
AlarmManager
am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime,
5*1000, sender);//從firstTime才開始執行，每隔5秒再執行
總結：在android客戶端使用Push推送時，應該使用AlarmManager來實現心跳功能，使其真正實現長連接。
⑶ android 長連接怎麼省電
1）滅屏待機最省電：
a)任何App包括後台Service應該盡可能減少喚醒CPU的次數，比如IM類業務的長連接心跳、QQ提醒待機鬧鍾類業務的alarm硬時鍾喚醒要嚴格控制；
b)每次喚醒CPU執行的代碼應該盡可能少，從而讓CPU迅速恢復休眠，比如申請wake lock的數量和持有時間要好好斟酌；
2）Wi-Fi比蜂窩數據，包括2G（GPRS）、3G更省電：
a)盡量在Wi-Fi下傳輸數據，當然這是廢話，不過可以考慮在有Wi-Fi的時候做預載入，比如應用中心的zip包、手Q web類應用的離線資源等；
b)非Wi-Fi下，盡量減少網路訪問，每一次後台交互都要考慮是否必須。雖然WiFi接入方式已經佔到移動互聯網用戶的50%，但是是有些手機設置為待機關閉WiFi連接，即便有Wi-Fi信號也只能切換到蜂窩數據；
測試分析：
1）滅屏的情況：
a)滅屏待機，CPU處於休眠狀態，最省電（7mA）；
b)滅屏傳輸，CPU被激活，耗電顯著增加，即便是處理1K的心跳包，電量消耗也會是待機的6倍左右（45mA）；
c)滅屏傳輸，高負載download的時候WiFi最省電（70mA），3G（270mA）和2G（280mA）相當，是WiFi的4倍左右；
1
Android手機耗電深度解析！
2）亮屏的情況：
a)亮屏待機，CPU處於激活狀態，加上屏幕耗電，整機電量消耗不小（140mA）；
b)亮屏傳輸，如果只是處理1K的心跳包，耗電增加不多（150mA），即便是很大的心跳包（64K），消耗增加也不明顯（160mA）；
c)亮屏傳輸，高負載download的時候WiFi最省電（280mA），3G（360mA）和2G（370mA）相當，是WiFi的1.3倍左右；
1
Android手機耗電深度解析！
3）Alarm喚醒頻繁會導致待機耗電增加：
手機滅屏後會進入待機狀態，這時CPU會進入休眠狀態。Android的休眠機制介紹的文章很多，這里引用一段網路文章：
Early suspend是android引進的一種機制,這種機制在上游備受爭議,這里 不做評論。這個機製作用在關閉顯示的時候,在這個時候,一些和顯示有關的 設備,比如LCD背光,比如重力感應器,觸摸屏,這些設備都會關掉,但是系統可能還是在運行狀態(這時候還有wake lock)進行任務的處理,例如在掃描SD卡上的文件等.在嵌入式設備中,背光是一個很大的電源消耗,所以android會加入這樣一種機制.
Late Resume是和suspend配套的一種機制,是在內核喚醒完畢開始執行的.主要就是喚醒在Early Suspend的時候休眠的設備.
Wake Lock在Android的電源管理系統中扮演一個核心的角色. Wake Lock是一種鎖的機制,只要有人拿著這個鎖,系統就無法進入休眠,可以被用戶態程序和內核獲得.這個鎖可以是有超時的或者是沒有超時的,超時的鎖會在時間過去以後自動解鎖.如果沒有鎖了或者超時了,內核就會啟動休眠的那套機制來進入休眠.
當用戶寫入mem或者standby到/sys/power/state中的時候, state_store()會被調用,然後Android會在這里調用request_suspend_state()而標準的Linux會在這里進入enter_state()這個函數.如果請求的是休眠,那麼early_suspend這個workqueue就會被調用,並且進入early_suspend
簡單的說，當用戶按power鍵，使得手機進入滅屏休眠狀態，Android系統其實是做了前面說的一些工作：關閉屏幕、觸摸屏、感測器、mp當前用戶態和內核態程序運行上下文到內存或者硬碟、關閉CPU供電，當然為了支持語音通訊，modern等蜂窩信令還是工作的。
這種情況下，應用要喚醒CPU，只有兩種可能：
a)通過伺服器主動PUSH數據，通過網路設備激活CPU；
b)設置alarm硬體鬧鍾喚醒CPU；
這里我們重點分析第二種情況。首先來看看什麼是alarm硬體鬧鍾。Google官方提供的解釋是：Android提供的alarm services可以幫助應用開發者能夠在將來某一指定的時刻去執行任務。當時間到達的時候，Android系統會通過一個Intent廣播通知應用去完成這一指定任務。即便CPU休眠，也不影響alarm services的服務，這種情況下可以選擇喚醒CPU。
顯然喚醒CPU是有電量消耗的，CPU被喚醒的次數越多，耗電量會越大。現在很多應用為了維持心跳、拉取數據、主動PUSH會不同程度地注冊alarm服務，導致Android系統被頻繁喚醒。這就是為什麼雷軍說Android手機在安裝了TOP100的應用後，待機時間會大大縮短的重要原因。
比較簡單評測CPU喚醒次數的方法是看mpsys alarm，這里會詳細記錄從開機到當前的各個進程和服務喚醒CPU的次數和時間。通過對比喚醒次數和喚醒時間可以幫助我們分析後台進程和服務的耗電情況。Dumpsys alarm的輸出看起來像這樣：
其中544代表喚醒次數，38684ms代表喚醒時間 [保存到相冊]
4）Wake locks持有時間過長會導致耗電增加：
Wake locks是一種鎖機制，有些文獻翻譯成喚醒鎖。簡單說，前面講的滅屏CPU休眠還需要做一個判斷，就是看是否還有任何應用持有wake locks。如果有，CPU將不會休眠。有些應用不合理地申請wake locks，或者申請了忘記釋放，都會導致手機無法休眠，耗電增加。
原始數據：
測試方法：硬體設備提供穩壓電源替代手機電池供電，在不同場景下記錄手機平均電流。
測試設備：Monsoon公司的Power Monitor TRMT000141
測試機型：Nexus One
1
滅屏benchmark（CPU進入休眠狀態）：7mA [保存到相冊] 0
滅屏WiFi：70 mA [保存到相冊]
0
滅屏3G net：270 mA [保存到相冊]
http://digi.it.sohu.com/20131116/n390249625.shtml
⑷ android、ios客戶端和伺服器通信一般使用什麼方式，各有什麼優缺點
1、從網路協議上來看，就http方式和socket方式。
2、http方式開發起來效率想對要高一點，但是對於推送這種來說，想對要難做點，因為http是短連接。socket這種方式開發要長，調試略微麻煩，但是做推送想對簡單，可以建立一個長連接。
3、Web Service服務其實也是基於HTTP協議（它基於SOAP協議，而SOAP又是基於HTTP協議）。
最大缺點我覺得是Web Service實在是太厚重了，特別對於移動端來說，WSDL是基於XML，XML已經夠厚重了，WSDL還有一些頭信息，更加厚重。
而且JSON + HTTP的方式，相對來說就非常輕量級了，JSON格式數據本生就是Javascript中的數據或者對象，所以在網路傳輸中具有非常明顯優勢，可以說本來就是網路傳輸用的，毫無違和感嘛：）
還有一個不能算缺點的缺點：目前移動端HTTP網路庫多的要死，Web Service我所知道就是ksoap2，而且非常的難用。。。
⑸ 如何在android客戶端實時監控websocket長連接時伺服器實時推送的
使用Socket類中的Poll方法，就可以。 Socket client //假如已經創建好了，連接到伺服器端得Socket的客戶端對象。 我們只要client.Poll(10,SelectMode.SelectRead)判斷就行了。只要返回True是。就可以認為客戶端已經斷開了。 Poll 方法將會檢查 Socket 的狀態。指定 selectMode 參數的 SelectMode..::.SelectRead，可確定 Socket 是否為可讀。指定 SelectMode..::.SelectWrite，可確定 Socket 是否為可寫。使用 SelectMode..::.SelectError 檢測錯誤條件。Poll 將在指定的時段（以 microseconds 為單位）內阻止執行。如果希望無限期的等待響應，則將 microSeconds 設置為一個負整數。如果要檢查多個套接字的狀態，則不妨使用 Select 方法。