① 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服务。