标签:测试 统一 get 原则 断开连接 zha ack orm 管理
本文已经收录到我的Github个人博客,欢迎大佬们光临寒舍:
IPC
?IPC
是Inter-Process Communication
的缩写,含义是进程间通信,是指两个进程之间进行数据交换的过程。
有些读者可能疑惑: "那什么是进程呢?什么是线程呢?多进程和多线程有什么区别呢?"
两者关系:一个进程可包含多个线程,即一个应用程序上可以同时执行多个任务。
- 主线程(UI线程):UI操作
- 有限个子线程:耗时操作
注意:不可在主线程做大量耗时操作,会导致ANR(应用无响应)。解决办法:将耗时任务放在线程中。
IPC
不是Android所特有的,Android中最有特色的IPC
方式是Binder
。而日常开发中涉及到的知识:AIDL,插件化,组件化等等,都离不开Binder。由此可见,IPC
是挺重要的。
Android
中的多进程模式Q1:开启多线程的方式:
AndroidMenifest
中给四大组件指定属性android:process
precess的命名规则:
- 默认进程:没有指定该属性则运行在默认进程,其进程名就是包名。
- 以“:”为命名开头的进程:“:”的含义是在进程名前面加上包名,属于当前应用私有进程
- 完整命名的进程:属于全局进程,其他应用可以通过ShareUID方式和他跑在用一个进程中(需要ShareUID和签名相同)。
Q2:多进程模式的运行机制:
Andoird为每个进程分配了一个独立的虚拟机,不同虚拟机在内存分配上有不同的地址空间,这也导致了不同虚拟机中访问同一个对象会产生多份副本。
带来四个方面的问题:
- 静态变量和单例模式失效-->原因:不同虚拟机中访问同一个对象会产生多份副本。
- 线程同步机制失效-->原因:内存不同,线程无法同步。
- SharedPreference的可靠性下降-->原因:底层是通过读写XML文件实现的,发生并发问题。
- Application多次创建-->原因:Android系统会为新的进程分配独立虚拟机,相当于应用重新启动了一次。
IPC
基础概念这里主要介绍三方面内容:
- Serializable
- Parcelable
- Binder
只有熟悉这三方面的内容,才能更好理解
IPC
的各种方式
Java提供的序列化接口,使用方式比较简单:
- 实体类实现Serializable
- 手动设置/系统自动生成serialVersionUID
//Serializable Demo
public class Person implements Serializable{
private static final long serialVersionUID = 7382351359868556980L;
private String name;
private int age;
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
这里特别注意一下serialVersionUID:
- 含义:是Serializable接口中用来辅助序列化和反序列化过程。
- 注意:原则上序列化后的数据中的serialVersionUID要和当前类的serialVersionUID 相同才能正常的序列化。当类发生非常规性变化(修改了类名/修改了成员变量的类型)的时候,序列化失败。
是Android中的序列化接口,使用的时候,类中需要实现下面几点:
- 实现Parcelable接口
- 内容描述
- 序列化方法
- 反序列化方法
public class User implements Parcelable {
public int userId;
public String userName;
public boolean isMale;
public Book book;
public User() {
}
public User(int userId, String userName, boolean isMale) {
this.userId = userId;
this.userName = userName;
this.isMale = isMale;
}
//返回内容描述
public int describeContents() {
return 0;
}
//序列化
public void writeToParcel(Parcel out, int flags) {
out.writeInt(userId);
out.writeString(userName);
out.writeInt(isMale ? 1 : 0);
out.writeParcelable(book, 0);
}
//反序列化
public static final Parcelable.Creator<User> CREATOR = new Parcelable.Creator<User>() {
//从序列化的对象中创建原始对象
public User createFromParcel(Parcel in) {
return new User(in);
}
public User[] newArray(int size) {
return new User[size];
}
};
//从序列化的对象中创建原始对象
private User(Parcel in) {
userId = in.readInt();
userName = in.readString();
isMale = in.readInt() == 1;
book = in.readParcelable(Thread.currentThread().getContextClassLoader());
}
@Override
public String toString() {
return String.format("User:{userId:%s, userName:%s, isMale:%s}, with child:{%s}",
userId, userName, isMale, book);
}
}
Serializable接口 | Parcelable接口 | |
---|---|---|
平台 | Java | Andorid |
序列化原理 | 将一个对象转换成可存储或者可传输的状态 | 将对象进行分解,且分解后的每一部分都是传递可支持的数据类型 |
优缺点 | 优点:使用简单 缺点:开销大(因为需要进行大量的IO操作) | 优点:高效 缺点:使用麻烦 |
使用场景 | 将对象序列化到存储设备或者通过网络传输 | 主要用在内存序列化上 |
Q1:Binder是什么?
Q2:Android是基于Linux内核基础上设计的,却没有把管道/消息队列/共享内存/信号量/Socket等一些IPC通信手段作为Android的主要IPC方式,而是新增了Binder机制,其优点有:
A1:传输效率高、可操作性强
传输效率主要影响因素是内存拷贝的次数,拷贝次数越少,传输速率越高。几种数据传输方式比较
方式 | 拷贝次数 | 操作难度 |
---|---|---|
Binder | 1 | 简易 |
消息队列 | 2 | 简易 |
Socket | 2 | 简易 |
管道 | 2 | 简易 |
共享内存 | 0 | 复杂 |
从Android进程架构角度分析:对于消息队列、Socket和管道来说,数据先从发送方的缓存区拷贝到内核开辟的缓存区中,再从内核缓存区拷贝到接收方的缓存区,一共两次拷贝,如图:
对Binder来说:数据从发送方的缓存区拷贝到内核的缓存区,而接收方的缓存区与内核的缓存区是映射到同一块物理地址的,节省了一次数据拷贝的过程
A2:实现C/S架构方便
Linux的众IPC方式除了Socket以外都不是基于C/S架构,而Socket主要用于网络间的通信且传输效率较低。Binder基于C/S 架构 ,Server端与Client端相对独立,稳定性较好。
A3:安全性高
传统Linux IPC的接收方无法获得对方进程可靠的UID/PID,从而无法鉴别对方身份;而Binder机制为每个进程分配了UID/PID且在Binder通信时会根据UID/PID进行有效性检测。
Q3:Binder框架定义了四个角色呢?
A1:Server&Client
服务器&客户端。在Binder驱动和Service Manager提供的基础设施上,进行Client-Server之间的通信。
A2:ServiceManager:
服务的管理者,将Binder名字转换为Client中对该Binder的引用,使得Client可以通过Binder名字获得Server中Binder实体的引用。
A3:Binder驱动
ioctl(input/output control)是一个专用于设备输入输出操作的系统调用,该调用传入一个跟设备有关的请求码,系统调用的功能完全取决于请求码
Q4:Binder 工作原理是什么
当发出远程请求后客户端会挂起,直到返回数据才会唤醒Client
Q5:当服务端进程异常终止的话,造成Binder死亡的话,怎么办?
在客户端绑定远程服务成功后,给Binder设置死亡代理,当Binder死亡的时候,我们会收到通知,从而重新发起连接请求。
private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient(){
@Override
public void binderDied(){
if(mBookManager == null){
return;
}
mBookManager.asBinder().unlinkToDeath(mDeathRecipient,0);
mBookManager = null;
// TODO:这里重新绑定远程Service
}
}
mService = IBookManager.Stub.asInterface(binder);
binder.linkToDeath(mDeathRecipient,0);
IPC
方式Android中的
IPC
方式有很多种,但是都与Binder
有或多或少的关系
小课堂测试:在A进程进行计算后的结果不是Bundle所支持的数据类型,该如何传给B进程?
Answer: 将在A进程进行的计算过程转移到B进程中的一个Service里去做,这样可成功避免进程间的通信问题。
AIDL(Android Interface Definition Language,Android接口定义语言):如果在一个进程中要调用另一个进程中对象的方法,可使用AIDL生成可序列化的参数,AIDL会生成一个服务端对象的代理类,通过它客户端实现间接调用服务端对象的方法。
想了解String和CharSequence区别的读者,可以看下这篇文章:String和CharSequence的区别
注意:除了基本数据类型,其它类型的参数必须标上方向:in、out或inout,用于表示在跨进程通信中数据的流向。
注意:
- 自定义的Parcelable对象必须把java文件和自定义的AIDL文件显式的import进来,无论是否在同一包内。
- AIDL文件用到自定义Parcelable的对象,必须新建一个和它同名的AIDL文件,并在其中声明它为Parcelable类型。
a:本质是系统提供了一套可快速实现Binder的工具。
b:关键类和方法是什么?
Binder
的实现类,服务端通过这个类来提供服务。asInterface()
:客户端调用,将服务端的返回的Binder对象,转换成客户端所需要的AIDL接口类型对象。返回对象:
- 若客户端和服务端位于同一进程,则直接返回Stub对象本身;
- 否则,返回的是系统封装后的Stub.proxy对象。
asBinder()
:返回代理Proxy的Binder对象。onTransact()
:运行服务端的Binder线程池中,当客户端发起跨进程请求时,远程请求会通过系统底层封装后交由此方法来处理。transact()
:运行在客户端,当客户端发起远程请求的同时将当前线程挂起。之后调用服务端的onTransact()直到远程请求返回,当前线程才继续执行。如果感兴趣的读者想要了解具体的AIDL实现IPC的流程,笔者分享一篇文章:android跨进程通信(IPC):使用AIDL
A.服务端:
B.客户端:
总结:服务端里的某个Service给和它绑定的特定客户端进程提供Binder对象,客户端通过AIDL接口的静态方法asInterface() 将Binder对象转化成AIDL接口的代理对象,通过这个代理对象就可以发起远程调用请求。
A.客户端:
B.服务端:
解决客户端频繁调用服务器方法导致性能极大损耗的办法:实现观察者模式。
即当客户端关注的数据发生变化时,再让服务端通知客户端去做相应的业务处理。
需要用到RemoteCallBackList:Android系统专门提供的用于删除跨进程listener的接口。其内部自动实现了线程同步的功能。
Q1.什么是Messager?
A1:Messager是轻量级的IPC方案,通过它可在不同进程中传递Message对象。
Messenger.send(Message);
Q2:特点是什么?
Messenge可支持的数据类型:
- arg1、arg2、what字段:int型数据
- obj字段:Object对象,支持系统提供的Parcelable对象
- setData:Bundle对象
Q3:实现的方法:
读者如果对Messenger的具体使用感兴趣的话,可以看下这篇文章:IPC-Messenger使用实例
A1:服务端:
onBind()
中返回Messenger对应的Binder对象。A2:客户端:
通过bindService绑定服务端的Service;
通过绑定后返回的IBinder对象创建一个Messenger,进而可向服务器端进程发送Message数据。(至此只完成单向通信)
在客户端创建一个Handler并由此创建一个Messenger,并通过Message的replyTo字段传递给服务器端进程。服务端通过读取Message得到Messenger对象,进而向客户端进程传递数据。(完成双向通信)
Q4:缺点:
解决方式:使用AIDL的方式处理IPC以应对高并发的场景
ContentProvider是Android提供的专门用来进行不同应用间数据共享的方式,底层同样是通过Binder实现的。
Socket不仅可以跨进程,还可以跨设备通信
Q1:使用类型是什么?
Q2:实现方法是什么?
A1:服务端:
A2:客户端:
名称 | 优点 | 缺点 | 适用场景 |
---|---|---|---|
Bundle | 简单易用 | 只能传输Bundle支持的数据类型 | 四大组件间的进程间通信 |
文件共享 | 简单易用 | 不适合高并发场景,无法做到进程间的即时通信 | 无并发访问,交换简单数据且实时性不高 |
AIDL | 支持一对多并发和实时通信 | 使用稍复杂,需要处理线程同步 | 一对多且有RPC需求 |
Messenger | 支持一对多串行通信 | 不能很好处理高并发,不支持RPC,只能传输Bundle支持的数据类型 | 低并发的一对多 |
ContentProvider | 支持一对多并发数据共享 | 可理解为受约束的AIDL | 一对多进程间数据共享 |
Socket | 支持一对多并发数据共享 | 实现细节繁琐 | 网络数据交换 |
有多个业务模块都需要AIDL来进行IPC,此时需要为每个模块创建特定的aidl文件,那么相应的Service就会很多。必然会出现系统资源耗费严重、应用过度重量级的问题。因此需要Binder连接池,通过将每个业务模块的Binder请求统一转发到一个远程Service中去执行的方式,从而避免重复创建Service。
Q1:工作原理是什么?
每个业务模块创建自己的AIDL接口并实现此接口,然后向服务端提供自己的唯一标识和其对应的Binder对象。服务端只需要一个Service,服务器提供一个queryBinder接口,它会根据业务模块的特征来返回相应的Binder对像,不同的业务模块拿到所需的Binder对象后就可进行远程方法的调用了。
Q2:实现方式是什么?
读者如果对具体的实现方式感兴趣的话,可以看一下这篇文章:Android IPC机制(四):细说Binder连接池
恭喜你,已经完成了这次奇妙的
IPC
之旅了,如果你感到对概念还是有点模糊不清的话,没关系,很正常,不用太纠结于细节,你可以继续进行下面的旅程了,未来的你,再看这篇文章,也许会有更深的体会,到时候就会有茅舍顿开的感觉了。未来的你,一定会更优秀!!!路漫漫其修远兮,吾将上下而求索。《离骚》--屈原
如果文章对您有一点帮助的话,希望您能点一下赞,您的点赞,是我前进的动力
本文参考链接:
标签:测试 统一 get 原则 断开连接 zha ack orm 管理
原文地址:https://www.cnblogs.com/xcynice/p/qi_miao_de_ipc_zhi_lv.html