① android之Binder通信篇
Binder跨進程通信的本質是依賴內核驅動將屬於不同Binder進程的數據，從原始進程復制到目標進程，這樣就完成了跨進程通信了。
Binder通過獨特的內存映射機制，在跨進程通信時，可以做到一次拷貝，兩個空間同時使用！如下圖：
Binder跨進程通信是要傳遞數據的，既然有數據必然要佔用內存空間，Android系統規定每一個進程都有一塊Binder內存區，也就是圖1中的 共享內存 ，系統最多隻能給該區域分配4M的物理內存，由於申請這塊內存是通過系統的mmap函數完成的，所以整個映射機制又被稱為mmap機制
為了把這部分說明白，就再盜圖一張，命名圖2吧！
對於Binder驅動，通過 binder_procs 鏈表記錄所有創建的 binder_proc 結構體，binder 驅動層的每一個 binder_proc 結構體都與用戶空間的一個用於 binder 通信的進程一一對應，且每個進程有且只有一個 ProcessState 對象，這是通過單例模式來保證的。在每個進程中可以有很多個線程，每個線程對應一個 IPCThreadState 對象，IPCThreadState 對象也是單例模式，即一個線程對應一個 IPCThreadState 對象，在 Binder 驅動層也有與之相對應的結構，那就是 Binder_thread 結構體。在 binder_proc 結構體中通過成員變數 rb_root threads，來記錄當前進程內所有的 binder_thread。
Binder 線程池：每個 Server 進程在啟動時創建一個 binder 線程池，並向其中注冊一個 Binder 線程；之後 Server 進程也可以向 binder 線程池注冊新的線程，或者 Binder 驅動在探測到沒有空閑 binder 線程時主動向 Server 進程注冊新的的 binder 線程。對於一個 Server 進程有一個最大 Binder 線程數限制，默認為16個 binder 線程，例如 Android 的 system_server 進程就存在16個線程。對於所有 Client 端進程的 binder 請求都是交由 Server 端進程的 binder 線程來處理的。
② android集成Grpc，使用grpc進行數據交互網路通信
集成
1、首先在project的gradle文件中的dependencies里進行如下配置
2、在app的gradle文件中操作
在最頂部添加
添加protobuf編譯器
添加grpc的相關引用
ok好了至此已經集成完畢了，接下來就是使用了
proto生成Java文件
(1) 把自己的proto文件復制粘貼到main/proto目錄下，點擊Android Studio中的Build菜單下的Rebuild Project即可
(2) Java文件生成位置：app/build/generated/source/proto/……
(3) 將Java文件復制出來即可使用
③ Android：AIDL進程間通信基本框架
在某些業務場景下，我們需要在應用中單獨開啟一個進程進行一些操作。比如性能監控，如果讓原始業務和性能監控本身的業務跑在同一個進程下，那麼就會導致性能統計的數據的失真。
而進程間通信，一般採用AIDL機制的客戶端與服務端通信。
AIDL只能傳遞如下幾類數據：
當傳遞自定義 Parcelable 時，有三處地方需要注意：
當傳遞其他 aidl 介面時，同樣必須要 import 這個 aidl 文件
編寫完 aidl 文件後，make一下工程，會在 build 下的 generated 下的 source 下的 aidl 目錄生成對應的介面類文件。aidl 介面其實就是 API 介面，通過實現對應介面類的 Stub 子類來實現具體的 API 邏輯；通過對應介面類的 Stub 子類的 asInterface 方法得到具體的實現類，調用具體的 API 方法。
一個基本的客戶端服務端的通信結構一般包括如下功能
客戶端的功能
服務端的功能
客戶端的相關功能實現比較簡單，麻煩的是服務端的功能。因為 AIDL 介面定義的都是服務端的介面，是由客戶端來調用的。而想要實現服務端反向調用客戶端則需要通過其他手段實現。
想要實現服務端主動連接客戶端，最好的辦法就是 服務端發送廣播，客戶端收到廣播後再主動連接服務端 ，通過這種方式變相地實現服務端主動連接客戶端的功能
想要實現服務端主動斷開客戶端，除了上面 發送廣播是一種實現方式外，還可以通過 android 的系統API RemoteCallbackList，用包名作為key值來注冊遠程回調介面的方式，讓服務端持有客戶端的回調介面，服務端調用回調介面，客戶端在回調介面中實現主動斷開服務端 ，通過這種方式變數地實現服務端主動斷開客戶端的功能。而採用後者會顯得更加優雅
既然所有的操作歸根結底都是由客戶端來完成的，那麼客戶端必須得有如下的功能模塊：
服務端必須得有的功能模塊：
那麼，整體的通信流程就是如下的步驟：
首先是通信的 aidl 介面定義
然後是客戶端的連接操作與斷開連接操作，包括廣播接收者的注冊以及回調介面的實現
然後是客戶端的拉取數據和推送數據操作
接著是服務端的 iBinder 介面的實現，完成回調介面的注冊、業務子線程的開啟和關閉、數據的推送和數據的拉取操作
然後是服務端的主動連接和主動斷開連接操作
最後是服務端的 onUnbind 方法的實現，對回調介面進行反注冊
服務端模仿 FloatViewPlugin 自定義插件，實現 IServicePlugin 介面，定製個性化的懸浮窗插件
客戶端在 Appliaction 的 onCreate方法中初始化
在 MainActivity 上實現連接、斷開、數據通信
④ android平台的app 手機客戶端和後台伺服器怎麼進行數據交互的
首先不要管安卓端還是蘋果端，現在一般都是響應式的app，你放到安卓或者蘋果或者pc或者平板都是沒有問題的。一般採用的是http介面通訊，或者socket連接。具體你要去查資料找Demo了。而且現在主流是採用html5開發或者混合開發了。所以最好是伺服器提供appAPI介面，通過http訪問伺服器，獲取數據，數據一般是json，或者xml，拿到後解析數據就可以了，然後再用UI框架或者其他框架或者自定義的UI封裝下格式很漂亮了，至於cookie和session等，看你的習慣，網路驗證和簽名那些也自己看習慣，如果涉及到大數據，還需要引入第三方框架的，直接引入就可以了，不過推薦自己寫，防止侵權。都是很通用的。
⑤ Android開發之串口通信:AndroidSerialPort
Android 串口通信，基於 谷歌官方android-serialport-api 編譯
項目github地址： https://github.com/AIlll/AndroidSerialPort
讀取數據時很可能會遇到分包的情況，即不能一次性讀取正確的完整的數據
解決辦法：可以在讀取到數據時，讓讀取數據的線程sleep一段時間，等待數據全部接收完，再一次性讀取出來。這樣應該可以避免大部分的分包情況
只接收一條數據的情況下，以上方法可以應對數據分包，數據量多的情況下需要考慮是否會因為sleep導致接收多條數據，可以根據通信協議核對包頭包尾等參數。
打開串口時，會檢測讀寫許可權，當沒有許可權時，會嘗試對其進行提權
⑥ Android ParcelFileDescriptor實現進程間通信
一個通信通道，實現跨進程的的Socket網路通信。
具體的通信通道的圖如下。
android進程間通信是使用Binder來傳數據，而Binder傳輸的數據，有一個最為基本的要求，就是要實現Parcelable介面。
ParcelFileDescriptor是android提供的一個數據結構。
ParcelFileDescriptor是可以用於進程間Binder通信的FileDescriptor。支持stream 寫入和stream 讀出
我們可以使用
來將PacecelFileDescriptor 與File對應起來，以實現進程間的文件共享。
我們也可以使用
來建立一個pipe通信通道，ParcelFileDescriptor數組第一個元素是read端，第二個元素是write端，通過write端的AutoCloseOutputStream和read端的AutoCloseInputStream，我們就可以實現進程見的數據流傳輸了。
發送端：
1. 業務層調用getOutputStream向通信層發起請求
2. 通信層通過creatPipe 建立一個ParcelFileDescriptor數組，並將write端的pipe[1]返回給業務層
3. 業務層得到pipe[1]（ParcelFileDescriptor）後，可以通過AutoCloseOutputStream寫入數據
4. 從通信層的pipe[0]的AutoCloseInputStream中讀出數據通過socket發送出去
接收端：
1. 業務層調用getInputStream向通信層發起請求
2. 通信層通過creatPipe 建立一個ParcelFileDescriptor數組，並將read端的pipe[0]返回給業務層
3. 業務層得到pipe 0 後，可以通過AutoCloseInputStream讀取數據。（如沒有數據，則阻塞，一直等到有數據為止）
4. socket中讀取數據，寫入到通信層的pipe[1]的AutoCloseOutputStream。（pipe[1]一旦寫入，第三步中pipe[2]就可以讀取出數據）
⑦ Android通信方式篇（七）-Binder機制（Native層（下））
本篇文章針對向ServiceManager注冊服務 和 獲取服務兩個流程來做總結。在這兩個過程中，ServiceManager都扮演的是服務端，與客戶端之間的通信也是通過Binder IPC。
在此之前先了解下Binder的進程與線程的關系：
用戶空間 :ProcessState描述一個進程，IPCThreadState對應一個進程中的一個線程。
內核空間 ：binder_proc描述一個進程，統一由binder_procs全局鏈表保存，binder_thread對應進程的一個線程。
ProcessState與binder_proc是一一對應的。
Binder線程池 ：每個Server進程在啟動時會創建一個binder線程池，並向其中注冊一個Binder線程；之後Server進程也可以向binder線程池注冊新的線程，或者Binder驅動在探測到沒有空閑binder線程時會主動向Server進程注冊新的的binder線程。對於一個Server進程有一個最大Binder線程數限制15，(#define DEFAULT_MAX_BINDER_THREADS 15)。對於所有Client端進程的binder請求都是交由Server端進程的binder線程來處理的。我的理解是：binder線程是進程進行binder ipc時的一條數據處理路徑。
MediaPlayerService向ServiceManager注冊過程如下：
相關類：
整個過程總結如下：
1 獲取BpServiceManager 與 BpBinder
由defaultServiceManager()返回的是BpServiceManager，同時會創建ProcessState對象和BpBinder對象。然後通過BpBinder執行transact，把真正工作交給IPCThreadState來處理。
2 BpBinder transact
Binder代理類調用transact()方法，真正工作還是交給IPCThreadState來進行transact工作。
3 通過IPCThreadState 包裝並轉換數據並進行transact事務處理
每個線程都有一個IPCThreadState，每個IPCThreadState中都有一對Parcel變數：mIn、mOut。相當於兩根數據管道：
最後執行talkWithDriver。
writeTransactionData：將BC Protocol + binder_transaction_data結構體 寫入mOut， 然後執行waitForResponse：
由talkWithDriver將數據進一步封裝到binder_write_read結構體，通過ioctl（BINDER_WRITE_READ）與驅動通信。同時等待驅動返回的接收BR命令，從mIn取出返回的數據。
mIn包裝的數據結構(注冊服務handle = 0 ，code 為ADD_SERVICE_TRANSACTION)：
4 Binder Driver
把binder_write_read結構體write_buffer里數據取出來，分別得到BC命令和封裝好數據的事務binder_transaction_data, 然後根據handler，在當前binder_proc中，找到相應的binder_ref，由binder_ref再找到目標binder_node實體，由目標binder_node再找到目標進程binder_proc。然後就是插入數據：當binder驅動可以找到合適的線程，就會把binder_transaction節點插入到servciemanager的線程的todo隊列中，如果找不到合適的線程，就把節點之間插入servciemanager的binder_proc的todo隊列。
5 ServiceManager
經過Binder Driver的處理，數據已經到了ServiceManager進程，在BR_TRANSACTION的引導下，在binder_loop（）中執行binder_parser（）取出數據，執行do_add_service（）操作，最終向 svcinfo 列表中添加已經注冊的服務（沒有數據的返回）。最後發送 BR_REPLY 命令喚醒等待的線程，通知注冊成功。結束MediaPlayerService進程 waitForResponse()的狀態，整個注冊過程結束。
獲取服務的過程與注冊類似，首先 ServiceManager 向 Binder 驅動發送 BC_TRANSACTION 命令攜帶 CHECK_SERVICE_TRANSACTION 命令，同時獲取服務的線程進入等待狀態 waitForResponse()。Binder 驅動收到請求命令向 ServiceManager 的發送 BC_TRANSACTION 查詢已注冊的服務，會區分請求服務所屬進程情況。
查詢到直接響應 BR_REPLY 喚醒等待的線程。若查詢不到將與 binder_procs 鏈表中的服務進行一次通訊再響應。
以startService為例來簡單總結下執行流程：
3.1 從方法執行流程來看：
Client ：
1 AMP.startService 標記方法以及通過Parcel包裝數據；
2 BinderProxy.transact 實際調用native的 android_os_BinderProxy_transact 傳遞數據；
3 獲取BpServiceManager 與 BpBinder 同時會創建ProcessState。然後通過BpBinder執行transact，把真正工作交給IPCThreadState來處理；
4 IPC.transact 主要執行writeTransactionData，將上層傳來的數據重新包裝成binder_transaction_data，並將BC Protocol + binder_transaction_data結構體 寫入mOut；
5 IPC waitForResponse talkWithDriver + 等待返回數據；
6 talkWithDriver 將數據進一步封裝成binder_write_read，通過ioctl（BINDER_WRITE_READ）與驅動通信；
Kernel :
7 binder ioctl 接收BINDER_WRITE_READ ioctl命令；
8 binder_ioctl_write_read 把用戶空間數據ubuf拷貝到內核空間bwr；
9 binder_thread_write 當bwr寫緩存有數據，則執行binder_thread_write；當寫失敗則將bwr數據寫回用戶空間並退出；
10 binder_transaction 找到目標進程binder_proc並插入數據到目標進程的線程todo隊列，最終執行到它
時，將發起端數據拷貝到接收端進程的buffer結構體；
11 binder_thread_read 根據binder_transaction結構體和binder_buffer結構體數據生成新的binder_transaction_data結構體，寫入bwr的read_buffer，當bwr讀緩存有數據，則執行binder_thread_read；當讀失敗則再將bwr數據寫回用戶空間並退出；最後，把內核數據bwr拷貝到用戶空間ubuf。
12 binder_thread_write + binder_ioctl BR命令和數據傳遞
Server:
13 IPC.executeCommand 解析kernel傳過來的binder_transaction_data數據，找到目標BBinder並調用其transact()方法;
14 IPC.joinThreadPool 採用循環不斷地執行getAndExecuteCommand()方法, 處理事務。當bwr的讀寫buffer都沒有數據時,則阻塞在binder_thread_read的wait_event過程. 另外,正常情況下binder線程一旦創建則不會退出.
15 BBinder.transact 到Binder.exeTransact 調用 AMN.onTransact
16 AMN.onTransact 把數據傳遞到AMS.starService去執行
17 AMS.starService Server處理了Client的請求了
然後原路replay回去，talkWithDriver 到Kernel ，然後找到Client進程，把數據拷貝到read_buffer里，最終喚醒IPC，把反饋傳遞回AMP.startService。完成啟動服務。
3.2 從通信協議流程來看：
非oneWay:
oneway:
oneway與非oneway區別: 都是需要等待Binder Driver的回應消息BR_TRANSACTION_COMPLETE. 主要區別在於oneway的通信收到BR_TRANSACTION_COMPLETE則返回,而不會再等待BR_REPLY消息的到來. 另外，oneway的binder IPC則接收端無法獲取對方的pid.
3.3 從數據流來看
從用戶空間開始：
進入驅動後：
回到用戶空間：
參考：
http://gityuan.com/2016/09/04/binder-start-service/
http://gityuan.com/2015/11/28/binder-summary/
http://gityuan.com/2015/11/14/binder-add-service/
http://gityuan.com/2015/11/15/binder-get-service/
⑧ android手機如何和單片機通信
首先手機要下載一個電腦模擬系統然後再通過專用數據線就可以和單片機通信了。
⑨ Flutter與Android通信的三種方式
一、 MethodChannel
主要是flutter端調用android方法。flutter調取android方法,也可以android主動跟flutter通信，但是這個只能是傳遞數據，不是調方法。MethodChannel的flutter調取android方法，我之前寫過，可以查看如下鏈接， https://www.jianshu.com/p/6b677ff3350e
Android主動跟flutter通信，如下
二、 BasicMessageChannel
它是可以雙端通信的，flutter端可以給Android發送消息，Android也可以給Flutter發送消息。
三、EventChannel
只能是原生發送消息給Flutter端，例如監聽手機電量變化，網路變化，感測器等。
列印結果如下：
總結一下：
MethodChannel 用於傳遞方法調用（method invocation），是flutter調取原生方法的,也可以原生主動傳遞數據給Flutter。
BasicMessageChannel 用於傳遞字元串和半結構化的信息。是兩個端相互發送數據，接收數據的。
EventChannel 用於數據流（event streams）的通信。通長用於Nativie向flutter的通信，如：手機電量變化，網路連接變化，陀螺儀，感測器等;
tip：多種類型的通道混用可能會出現報錯問題。
⑩ 了解Android進程間通信的四種方式
由於應用程序之間不能共享內存。在不同應用程序之間交互數據（跨進程通訊），在android
SDK中提供了4種用於跨進程通訊的方式。這4種方式正好對應於android系統中4種應用程序組
件：Activity、Content Provider、Broadcast和Service。其中Activity可以跨進程調用其他應
用程序的Activity；Content Provider可以跨進程訪問其他應用程序中的數據（以Cursor對象形
式返回），當然，也可以對其他應用程序的數據進行增、刪、改操 作；Broadcast可以向
android系統中所有應用程序發送廣播，而需要跨進程通訊的應用程序可以監聽這些廣播；
Service和Content Provider類似，也可以訪問其他應用程序中的數據，但不同的是，Content
Provider返回的是Cursor對象，而Service返回的是Java對象，這種可以跨進程通訊的服務叫
AIDL服務。