㈠ android中網路通信的幾種方式
主要有六種方式：
（1）針對TCP/IP的Socket、ServerSocket
（2）針對UDP的DatagramSocket、DatagramPackage。這里需要注意的是，考慮到Android設備通常是手持終端,IP都是隨著上網進行分配的。不是固定的。因此開發也是有一點與普通互聯網應用有所差異的。
（3）針對直接URL的HttpURLConnection。
（4）Google集成了Apache HTTP客戶端，可使用HTTP進行網路編程。
（5）使用WebService。Android可以通過開源包如jackson去支持Xmlrpc和Jsonrpc,另外也可以用Ksoap2去實現Webservice。
（6）直接使用WebView視圖組件顯示網頁。基於WebView 進行開發，Google已經提供了一個基於chrome-lite的Web瀏覽器，直接就可以進行上網瀏覽網頁。
㈡ Android伺服器通信的幾種方式詳解
大 學學習網路基礎的時候老師講過，網路由下往上分為物理層、數據鏈路層、網路層、傳輸層、會話層、表示層和應用層。通過初步的了解，我知道IP協議對應於網 絡層，TCP協議對應於傳輸層，而HTTP協議對應於應用層，三者從本質上來說沒有可比性，socket則是對TCP/IP協議的封裝和應用（程序員層面 上）。也可以說，TPC/IP協議是傳輸層協議，主要解決數據如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。關於TCP/IP和 HTTP協議的關系，網路有一段比較容易理解的介紹： 「我們在傳輸數據時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使 用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。WEB使用HTTP協議作應用層協議，以封裝 HTTP文本信息，然後使用TCP/IP做傳輸層協議將它發到網路上。」
而我們平時說的最多的socket是什麼呢，實際上socket是對TCP/IP協議的封裝，Socket本身並不是協議，而是一個調用介面（API）， 通過Socket，我們才能使用TCP/IP協議。實際上，Socket跟TCP/IP協議沒有必然的聯系。Socket編程介面在設計的時候，就希望也 能適應其他的網路協議。所以說，Socket的出現只是使得程序員更方便地使用TCP/IP協議棧而已，是對TCP/IP協議的抽象，從而形成了我們知道 的一些最基本的函數介面，比如create、listen、connect、accept、send、read和write等等。網路有一段關於 socket和TCP/IP協議關系的說法比較容易理解：「TCP/IP只是一個協議棧，就像操作系統的運行機制一樣，必須要具體實現，同時還要提供對外 的操作介面。這個就像操作系統會提供標準的編程介面，比如win32編程介面一樣，TCP/IP也要提供可供程序員做網路開發所用的介面，這就是 Socket編程介面。」
關於TCP/IP協議的相關只是，用博大精深來講我想也不為過，單單查一下網上關於此類只是的資料和書籍文獻的數量就知道，這個我打算會買一些經典的書籍 （比如《TCP/IP詳解：卷一、卷二、卷三》）進行學習，今天就先總結一些基於基於TCP/IP協議的應用和編程介面的知識，也就是剛才說了很多的 HTTP和Socket。
CSDN上有個比較形象的描述：HTTP是轎車，提供了封裝或者顯示數據的具體形式；Socket是發動機，提供了網路通信的能力。
實際上，傳輸層的TCP是基於網路層的IP協議的，而應用層的HTTP協議又是基於傳輸層的TCP協議的，而Socket本身不算是協議，就像上面所說，它只是提供了一個針對TCP或者UDP編程的介面。
下面是一些經常在筆試或者面試中碰到的重要的概念，特在此做摘抄和總結。
一。什麼是TCP連接的三次握手
第一次握手：客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢後，客戶端與伺服器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉 連接之前，TCP 連接都將被一直保持下去。斷開連接時伺服器和客戶端均可以主動發起斷開TCP連接的請求，斷開過程需要經過「四次握手」（過程就不細寫了，就是伺服器和客 戶端交互，最終確定斷開）
二。利用Socket建立網路連接的步驟
建立Socket連接至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket ，另一個運行於伺服器端，稱為ServerSocket 。
套接字之間的連接過程分為三個步驟：伺服器監聽，客戶端請求，連接確認。
1。伺服器監聽：伺服器端套接字並不定位具體的客戶端套接字，而是處於等待連接的狀態，實時監控網路狀態，等待客戶端的連接請求。
2。客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是伺服器端的套接字。為此，客戶端的套接字必須首先描述它要連接的伺服器的套接字，指出伺服器端套接字的地址和埠號，然後就向伺服器端套接字提出連接請求。
3。 連接確認：當伺服器端套接字監聽到或者說接收到客戶端套接字的連接請求時，就響應客戶端套接字的請求，建立一個新的線程，把伺服器端套接字的描述發給客戶 端，一旦客戶端確認了此描述，雙方就正式建立連接。而伺服器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連接請求。
三。HTTP鏈接的特點
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱為「一次連接」。
四。TCP和UDP的區別（考得最多。。快被考爛了我覺得- -\\）
1。 TCP是面向鏈接的，雖然說網路的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上（實際上也很大程度上保證 了）保證了連接的可靠性；而UDP不是面向連接的，UDP傳送數據前並不與對方建立連接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接 收，當然也不用重發，所以說UDP是無連接的、不可靠的一種數據傳輸協議。
2。也正由於1所說的特點，使得UDP的開銷更小數據傳輸速率更高，因為不必進行收發數據的確認，所以UDP的實時性更好。
知 道了TCP和UDP的區別，就不難理解為何採用TCP傳輸協議的MSN比採用UDP的QQ傳輸文件慢了，但並不能說QQ的通信是不安全的，因為程序員可以 手動對UDP的數據收發進行驗證，比如發送方對每個數據包進行編號然後由接收方進行驗證啊什麼的，即使是這樣，UDP因為在底層協議的封裝上沒有採用類似 TCP的「三次握手」而實現了TCP所無法達到的傳輸效率。
㈢ android怎麼和websocket連接
Android與伺服器通信通常採用HTTP通信方式和Socket通信方式，而HTTP通信方式又分get和post兩種方式。至於Socket通信會在以後的博文中介紹。HTTP協議簡介：HTTP(HypertextTransferProtocol)，是Web聯網的基礎，也是手機聯網常用的協議之一
㈣ android 即時通信。。如何實現
Android現在即時通訊（或者消息推送）有好幾個開源項目框架可以實現，可以使用XMPP來實現即時通信。
XMPP（Extensible Messageing and Presence Protocol：可擴展消息與存在協議）是目前主流的四種IM（IM：instant messaging,即時消息）協議之一，其他三種分別為：即時信息和空間協議(IMPP)、空間和即時信息協議(PRIM)、針對即時通訊和空間平衡擴充的進程開始協議SIP(SIMPLE)。
1. XMPP的前身是Jabber，一個開源形式組織產生的網路即時通信協議。XMPP目前被IETF國際標准組織完成了標准化工作。標准化的核心結果分為兩部分； 核心的XML流傳輸協議 基於XML流傳輸的即時通訊擴展應用 XMPP的核心XML流傳輸協議的定義使得XMPP能夠在一個比以往網路通信協議更規范的平台上。藉助於XML易於解析和閱讀的特性，使得XMPP的協議能夠非常漂亮。 XMPP的即時通訊擴展應用部分是根據IETF在這之前對即時通訊的一個抽象定義的，與其他業已得到廣泛使用的即時通訊協議，諸如AIM，QQ等有功能完整，完善等先進性。
2.XMPP中定義了三個角色，客戶端，伺服器，網關。通信能夠在這三者的任意兩個之間雙向發生。伺服器同時承擔了客戶端信息記錄，連接管理和信息的路由功能。網關承擔著與異構即時通信系統的互聯互通，異構系統可以包括SMS（簡訊），MSN，ICQ等。基本的網路形式是單客戶端通過TCP/IP連接到單伺服器，然後在之上傳輸XML。
3.傳輸的是與即時通訊相關的指令。在以前這些命令要麼用2進制的形式發送，要麼用純文本指令加空格加參數加換行苻的方式發送（比如MSN）。而XMPP傳輸的即時通訊指令的邏輯與以往相仿，只是協議的形式變成了XML格式的純文本。這不但使得解析容易了，人也容易閱讀了，方便了開發和查錯。而XMPP的核心部分就是一個在網路上分片斷發送XML的流協議。這個流協議是XMPP的即時通訊指令的傳遞基礎，也是一個非常重要的可以被進一步利用的網路基礎協議。
㈤ 如何實現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映射表的負荷，所以如果發現鏈路中有一段時間沒有數據通訊時，會刪除其對應表，造成鏈路中斷。 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 怎麼與websocket 通訊
Android與伺服器通信通常採用HTTP通信方式和Socket通信方式，而HTTP通信方式又分get和post兩種方式。至於Socket通信會在以後的博文中介紹。 HTTP協議簡介： HTTP (Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種協議。 HTTP連接最顯著的特點是客戶端發送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求後，就自動釋放連接。在HTTP 1.1中則可以在一次連接中處理多個請求，並且多個請求可以重疊進行，不需要等待一個請求結束後再發送下一個請求。 由於HTTP在每次請求結束後都會主動釋放連接，因此HTTP連接是一種“短連接”、“無狀態”，要保持客戶端程序的在線狀態，需要不斷地向伺服器發起連接請求。通常的做法是即使不需要獲得任何數據，客戶端也保持每隔一段固定的時間向伺服器發送一次“保持連接”的請求，伺服器在收到該請求後對客戶端進行回復，表明知道客戶端“在線”。若伺服器長時間無法收到客戶端的請求，則認為客戶端“下線”，若客戶端長時間無法收到伺服器的回復，則認為網路已經斷開。 基於HTTP1.0協議的客戶端在每次向伺服器發出請求後，伺服器就會向客戶端返回響應消息，在確認客戶端已經收到響應消息後，服務端就會關閉網路連接。在這個數據傳輸過程中，並不保存任何歷史信息和狀態信息，因此，HTTP協議也被認為是無狀態的協議。 HTTP1.1和HTTP1.0相比較而言，最大的區別就是增加了持久連接支持。當客戶端使用HTTP1.1協議連接到伺服器後，伺服器就將關閉客戶端連接的主動權交還給客戶端;也就是說，只要不調用Socket類的close方法關閉網路連接，就可以繼續向伺服器發送HTTP請求。 HTTP連接使用的是“請求—響應”的方式(2次握手)，不僅在請求時需要先建立連接，而且需要客戶端向伺服器發出請求後，伺服器端才能回復數據。而Socket連接在雙方建立起連接後就可以直接進行數據的傳輸 HTTP協議的特點： 支持B/S及C/S模式; 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。 靈活：HTTP 允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type 加以標記; 無狀態：HTTP 協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。 HTTP協議請求方法： 請求行中包括了請求方法，解釋如下： GET 請求獲取Request-URI 所標識的資源; POST 在Request-URI 所標識的資源後附加新的數據; HEAD 請求獲取由Request-URI 所標識的資源的響應消息報頭 PUT 請求伺服器存儲一個資源，並用Request-URI 作為其標識 DELETE 請求伺服器刪除Request-URI 所標識的資源; TRACE 請求伺服器回送收到的請求信息，主要用於測試或診斷 CONNECT 保留將來使用 OPTIONS 請求查詢伺服器的性能，或者查詢與資源相關的選項和需求 Get與Post請求區別： Post請求可以向伺服器傳送數據，而且數據放在HTML HEADER內一起傳送到服務端URL地址，數據對用戶不可見。而get是把參數數據隊列加到提交的URL中，值和表單內各個欄位一一對應， 例如(/s?w=%C4&inputT=2710) get 傳送的數據量較小，不能大於2KB。post傳送的數據量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。 get安全性非常低，post安全性較高。 項目結構圖： get方式： get機制用的是在URL地址裡面通過?號間隔，然後以name=value的形式給客戶端傳遞參數。所以首先要在Android工程下的AndroidGetTest.java中onCreate方法定義好其URL地址以及要傳遞的參數，然後通過URL打開一個HttpURLConnection鏈接，此鏈接可以獲得InputStream位元組流對象，也是往服務端輸出和從服務端返回數據的重要過程，而若服務端response.getInputStream.write()往andorid返回信息時候，就可以通過InputStreamReader作轉換，將返回來的數據用BufferReader顯示出來。 具體代碼如下： Servlet端接收數據並返回通知： Android端發送消息並接收Servlet返回的消息： post方式： post傳輸方式不在URL里傳遞，也正好解決了get傳輸量小、容易篡改及不安全等一系列不足。主要是通 過對HttpURLConnection的設置，讓其支持post傳輸方式，然後在通過相關屬性傳遞參數(若需要傳遞中文字元，則可以通過URLEncoder編碼，而在獲取端採用URLDecoder解碼即可)
㈦ 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 即時通信。 是如何實現
我之前做過，簡單的，就是把即時通訊廠商提供的sdk導入到自己的項目，然後調用相應的API就行。這里以環信即時通訊雲為例：他的SDK 下載下來有4個文件夾，doc 文件夾：SDK 相關 API 文檔,examples 文件夾：ChatDemoUI3.0（Demo,依賴 EaseUI 庫）、EaseUI, libs 文件夾：包含IM和實時音視頻功能所需要的 jar 和 so 文件, libs.without.audio 文件夾：無實時語音、實時視頻功能的 SDK 包，如果項目中只用到聊天功能，可把項目里的 jar 和 so 文件替換成此文件夾里的,導入 SDK,在自行開發的應用中，集成環信聊天需要把 libs 文件夾下的 jar 及 so 文件復制到你的項目的 libs 文件夾相應位置，如果不需要語音和視頻通話功能，導入libs.without.audio 下的文件即可。 環信提供的文檔詳細的，還有參考視頻。
,
㈨ 安卓手機客戶端可以通過哪些方式與PC伺服器端通信
有如下的方法供選擇：
1. 利用USB口和USB連接線：
電腦可以將手機客戶端作為一個終端訪問，此時需要一款第三方軟體，比如金山手機、豌豆莢、360等等。
也可以將手機作為一個外部存儲器直接訪問手機的存儲位置來傳遞文件。
2.利用手機和電腦的藍牙，採用藍牙進行通訊。藍牙通訊的距離一般小於10米。藍牙建立連接之後，一般藍牙的協議之中帶有終端訪問功能，可以直接傳輸文件。
3.利用wifi，兩者都連接本地或公共wifi【手機通常有wifi，如果電腦沒有無線，用有線連接網路也可以】：
通過共享文件夾的方式，互相訪問傳輸文件。
也可以安裝第三方FTP服務端和客戶端軟體，實現FTP文件傳輸。
或者利用郵箱，自己發給自己，自己在另一個設備上接收下載完成文件傳輸。
4.還有一種方法，就是兩者都安裝微信，同時開通他們，在微信中傳輸文件，另一台機器上將文件下載下來就可以了。
可能還有其他方法，取決於你對這些機器的理解程度。因為他們實際上都是網路上的一個節點。