androidsocket接收
⑴ Android - Socket簡單使用
ServerSocket類提供如下構造器：
當ServerSocket使用完畢，應使用 close() 方法來關閉此ServerSocket。通常情況下，伺服器不應該只接收一個客戶端請求，而應該不斷接收來自客戶端的請求，所以程序可以通過循環，不斷調用ServerSocket的accept方法：
Socket 常用構造器
註：上面兩個構造器指定遠程主機時既可以使用InetAddress來指定，也可以直接使用String對象來指定遠程IP。本地主機只有一個IP地址時，使用第一個方法更簡單。
在與伺服器進行通訊的時候，無法判斷遠程的伺服器是否斷開連接。如果使用 OutputStream 發送數據則會影響正常的數據發送（無法區分）。所以就引入了一個心跳機制。
心跳機制實現，使用 Socket.sendUrgentData() 方法發送一個位元組流數據（緊急數據）。可以通過判斷服務端的 OOBINLINE 屬性是否打開，來確定是否斷開連接；
setSoTimeout()理解 ：設置超時時間；例如：設置為2s，如果阻塞的時間>2s ，那麼就會報錯。
⑵ 如何用socket實現android手機與手機之間的通信
參考一般的java的socket編程，如果通過手機網路，就不要使用UDP即可。
⑶ Android 基於UDP的Socket通信
1、連接DatagramSocket的服務端（ip和port）：開啟非同步線程和socket
2、發送數據（DatagramPacket）：非同步
3、接收數據（DatagramPacket）：注意連接狀態，非同步讀取
4、關閉連接：關閉DatagramSocket和對應線程
1、異常：android.os.NetworkOnMainThreadException。 socket需要在線程中使用
2、前後端統一傳輸或者接收協議 [requestcode size d1 d2 d3 ... ]，在解析時候用得到
3、實施監控socket的連接狀態，還是用心跳包發過去，然後返回數據，一段時間沒有的話則代表socket連接失敗。
4、注意receive接收數據後的有效長度（一個是預存的buffer，一個是有效結果buffer）
5、客戶端連上去後不知道為何一定要先發送一次，才能接收？
6、UDP不安全，有長度限制64K
2019 (*￣(oo)￣) 諸事順利！
⑷ android socket接收事件為什麼沒有監聽事件,要用死循環呢
socket是Java API（編程文檔介面），為了直接使用Socekt服務，谷歌直接把Java的Socket模塊照搬過來的
Android 的 onClikcListener onTouchEvent 等是Android API（編程文檔介面）
2.設計目的
編程介面全都是根據需求設定的，比如Google事先考慮開發者有使用監聽事件的需求，才預定義了onClickListener onItemListener這些介面，並且將這些底層實現，封裝到了c和C++層，開發者只需要直接使用Google事先為我們准備好的介面即可。
Socket ，首先Socket並不是Google事先設計好的，Socke中文名稱作套接字，你網路搜套接字編程，可以認識到Socket開發是專門的編程技術，而Socket本身又是網路通信協議的基礎設施，Socket的誕生歷史，高於Android，甚至高於Java，Socekt是計算機提供進程通信能力的編程介面，確切的說，它甚至可以提供不同主機間不同進程的通信能力，（包括同一主機里不同進程的通信能力）
主機？端系統？網路協議？運輸層？傳輸層？套接字？埠？
我說的這些專業名詞，也許你一時半會並不能理解
值得慶幸的是，當你了解到這里，你起碼能想明白，為什麼有的人說，Android 程序，也可以做伺服器了，因為Socket 提供了其他端系統訪問Android程序的能力，能被請求訪問的程序，可以稱作服務端。
想深入了解Socket的設計原理、設計本意，需要深厚的計算機網路知識，在這里我建議你閱讀《計算機網路-自頂向下方法》閱讀前三章，也許你對網路編程會有更深的理解。
總結來說：
Android的Listener系列監聽事件，其實只是響應用戶I/O操作而已，是人與硬體設備的通信，安卓系統提供維持監聽事件的能力，所以你能根據某些事件作出響應
Socket的功能，是提供進程通信的能力，安卓系統並不能直接控制Socket的生命周期，它第一層設計是Java代碼，並不是Google自己研發的，第二層、第三層已經直接深入到運輸層協議、計算機系統層原理了，Google為了省事，直接照搬Java API ，無可厚非。
⑸ Android手機端通過socket接收藍牙模塊串口發來的字元串，出現字元串被截斷現象，求解決辦法，萬分感謝！
在while循環外部的上方申明：
String sda="";
將while循環裡面的 String sda = new String(byte_data);
改為：sda+=new String(byte);
最後將while循環裡面的 System.out.println("收到的數據sda為："+sda);
移到while循環外部的下方。
⑹ android的socket問題，一直接收不到數據，幫忙看看
while(true){}死循環了，不知道你的本意是不是想一直讀數據，然後去更新顯示？
提出建議：
把內容全部讀出來，可以使用StringBuffer或StringBuild，然後再刷新顯示
Socket使用以後要記得close
⑺ Android socket源碼解析(三)socket的connect源碼解析
上一篇文章著重的聊了socket服務端的bind，listen，accpet的邏輯。本文來著重聊聊connect都做了什麼？
如果遇到什麼問題，可以來本文 https://www.jianshu.com/p/da6089fdcfe1 下討論
當服務端一切都准備好了。客戶端就會嘗試的通過 connect 系統調用，嘗試的和服務端建立遠程連接。
首先校驗當前socket中是否有正確的目標地址。然後獲取IP地址和埠調用 connectToAddress 。
在這個方法中，能看到有一個 NetHooks 跟蹤socket的調用，也能看到 BlockGuard 跟蹤了socket的connect調用。因此可以hook這兩個地方跟蹤socket，不過很少用就是了。
核心方法是 socketConnect 方法，這個方法就是調用 IoBridge.connect 方法。同理也會調用到jni中。
能看到也是調用了 connect 系統調用。
文件：/ net / ipv4 / af_inet.c
在這個方法中做的事情如下：
注意 sk_prot 所指向的方法是， tcp_prot 中 connect 所指向的方法，也就是指 tcp_v4_connect .
文件：/ net / ipv4 / tcp_ipv4.c
本質上核心任務有三件:
想要能夠理解下文內容，先要明白什麼是路由表。
路由表分為兩大類：
每個路由器都有一個路由表(RIB)和轉發表 (fib表)，路由表用於決策路由，轉發表決策轉發分組。下文會接觸到這兩種表。
這兩個表有什麼區別呢？
網上雖然給了如下的定義：
但實際上在Linux 3.8.1中並沒有明確的區分。整個路由相關的邏輯都是使用了fib轉發表承擔的。
先來看看幾個和FIB轉發表相關的核心結構體：
熟悉Linux命令朋友一定就能認出這裡面大部分的欄位都可以通過route命令查找到。
命令執行結果如下：
在這route命令結果的欄位實際上都對應上了結構體中的欄位含義：
知道路由表的的內容後。再來FIB轉發表的內容。實際上從下面的源碼其實可以得知，路由表的獲取，實際上是先從fib轉發表的路由字典樹獲取到後在同感加工獲得路由表對象。
轉發表的內容就更加簡單
還記得在之前總結的ip地址的結構嗎？
需要進行一次tcp的通信，意味著需要把ip報文准備好。因此需要決定源ip地址和目標IP地址。目標ip地址在之前通過netd查詢到了，此時需要得到本地發送的源ip地址。
然而在實際情況下，往往是面對如下這么情況：公網一個對外的ip地址，而內網會被映射成多個不同內網的ip地址。而這個過程就是通過DDNS動態的在內存中進行更新。
因此 ip_route_connect 實際上就是選擇一個緩存好的，通過DDNS設置好的內網ip地址並找到作為結果返回，將會在之後發送包的時候填入這些存在結果信息。而查詢內網ip地址的過程，可以成為RTNetLink。
在Linux中有一個常用的命令 ifconfig 也可以實現類似增加一個內網ip地址的功能：
比如說為網卡eth0增加一個IPV6的地址。而這個過程實際上就是調用了devinet內核模塊設定好的添加新ip地址方式，並在回調中把該ip地址刷新到內存中。
注意 devinet 和 RTNetLink 嚴格來說不是一個存在同一個模塊。雖然都是使用 rtnl_register 注冊方法到rtnl模塊中：
文件：/ net / ipv4 / devinet.c
文件：/ net / ipv4 / route.c
實際上整個route模塊，是跟著ipv4 內核模塊一起初始化好的。能看到其中就根據不同的rtnl操作符號注冊了對應不同的方法。
整個DDNS的工作流程大體如下：
當然，在tcp三次握手執行之前，需要得到當前的源地址，那麼就需要通過rtnl進行查詢內存中分配的ip。
文件：/ include / net / route.h
這個方法核心就是 __ip_route_output_key .當目的地址或者源地址有其一為空，則會調用 __ip_route_output_key 填充ip地址。目的地址為空說明可能是在回環鏈路中通信，如果源地址為空，那個說明可能往目的地址通信需要填充本地被DDNS分配好的內網地址。
在這個方法中核心還是調用了 flowi4_init_output 進行flowi4結構體的初始化。
文件：/ include / net / flow.h
能看到這個過程把數據中的源地址，目的地址，源地址埠和目的地址埠，協議類型等數據給記錄下來，之後內網ip地址的查詢與更新就會頻繁的和這個結構體進行交互。
能看到實際上 flowi4 是一個用於承載數據的臨時結構體，包含了本次路由操作需要的數據。
執行的事務如下：
想要弄清楚ip路由表的核心邏輯，必須明白路由表的幾個核心的數據結構。當然網上搜索到的和本文很可能大為不同。本文是基於LInux 內核3.1.8.之後的設計幾乎都沿用這一套。
而內核將路由表進行大規模的重新設計，很大一部分的原因是網路環境日益龐大且復雜。需要全新的方式進行優化管理系統中的路由表。
下面是fib_table 路由表所涉及的數據結構：
依次從最外層的結構體介紹：
能看到路由表的存儲實際上通過字典樹的數據結構壓縮實現的。但是和常見的字典樹有點區別，這種特殊的字典樹稱為LC-trie 快速路由查找演算法。
這一篇文章對於快速路由查找演算法的理解寫的很不錯: https://blog.csdn.net/dog250/article/details/6596046
首先理解字典樹：字典樹簡單的來說，就是把一串數據化為二進制格式，根據左0，右1的方式構成的。
如圖下所示：
這個過程用圖來展示，就是沿著字典樹路徑不斷向下讀，比如依次讀取abd節點就能得到00這個數字。依次讀取abeh就能得到010這個數字。
說到底這種方式只是存儲數據的一種方式。而使用數的好處就能很輕易的找到公共前綴，在字典樹中找到公共最大子樹，也就找到了公共前綴。
而LC-trie 則是在這之上做了壓縮優化處理，想要理解這個演算法，必須要明白在 tnode 中存在兩個十分核心的數據：
這負責什麼事情呢？下面就簡單說說整個lc-trie的演算法就能明白了。
當然先來看看方法 __ip_dev_find 是如何查找
文件：/ net / ipv4 / fib_trie.c
整個方法就是通過 tkey_extract_bits 生成tnode中對應的葉子節點所在index，從而通過 tnode_get_child_rcu 拿到tnode節點中index所對應的數組中獲取葉下一級別的tnode或者葉子結點。
其中查找index最為核心方法如上，這個過程，先通過key左移動pos個位，再向右邊移動（32 - bits）演算法找到對應index。
在這里能對路由壓縮演算法有一定的理解即可，本文重點不在這里。當從路由樹中找到了結果就返回 fib_result 結構體。
查詢的結果最為核心的就是 fib_table 路由表，存儲了真正的路由轉發信息
文件：/ net / ipv4 / route.c
這個方法做的事情很簡單，本質上就是想要找到這個路由的下一跳是哪裡？
在這裡面有一個核心的結構體名為 fib_nh_exception 。這個是指fib表中去往目的地址情況下最理想的下一跳的地址。
而這個結構體在上一個方法通過 find_exception 獲得.遍歷從 fib_result 獲取到 fib_nh 結構體中的 nh_exceptions 鏈表。從這鏈表中找到一模一樣的目的地址並返回得到的。
文件：/ net / ipv4 / tcp_output.c
⑻ Android socket通信能發數據但不能接收到數據
我C#項目中做過同樣的Android移動Socket通信。
Android客戶端：
SocketClient對象receive函數就調用讀取函數，當然之前是打開了Socket連接。
publicStringreceive()throwsIOException{
BufferedReaderreader=newBufferedReader(
newInputStreamReader(client.getInputStream()));
Stringtxt=reader.readLine();
returntxt;
}Activity頁面使用任務不間斷監聽接收。
<Void,Void,Void>{
@Override
protectedVoiddoInBackground(Void...arg0){
SocketClientclient=SocketClient.getInstance();
while(true)
{
try{
Thread.sleep(5000);
Stringre=client.receive();
if(re==null||(re!=null&&re.equals(""))){
continue;
}
if(isCancelled())
returnnull;
//TODO:處理接收到消息
}catch(SocketExceptione){
//服務端斷開，啟動重連任務
if(e.getMessage().contains("ECONNRESET")){
reconnectTask=newReconnectServerTask();
reconnectTask.execute((Void)null);
}
returnnull;
}catch(IOExceptione){
e.printStackTrace();
}catch(InterruptedExceptione){
e.printStackTrace();
}catch(Exceptione){
e.printStackTrace();
}
}
}
}