grpc简介
gRPC是由Google主导开发的RPC(Remote Procedure Call:远程过程调用协议)框架,使用HTTP/2协议并用ProtoBuf作为序列化工具。其客户端提供Objective-C、Java接口,服务器侧则有Java、Golang、C++等接口,从而为移动端(iOS/Androi)到服务器端通讯提供了一种解决方案。
最好提前了解RPC原理, 可参考如下文章:RPC原理及RPC实例分析
grpc的集成
- app的gradle文件中
最顶部添加
apply plugin: 'com.google.protobuf'
添加protobuf编译器
protobuf {
protoc {
artifact = "com.google.protobuf:protoc:3.4.0"
}
plugins {
javalite {
artifact = "com.google.protobuf:protoc-gen-javalite:3.0.0"
}
grpc {
artifact = 'io.grpc:protoc-gen-grpc-java:1.7.0'
}
}
generateProtoTasks {
all().each { task ->
task.plugins {
javalite {}
grpc {
// Options added to --grpc_out
option 'lite'
}
}
}
}
configurations.all {
resolutionStrategy.force 'com.google.code.findbugs:jsr305:1.3.9'
}
}
添加依赖库文件
compile 'io.grpc:grpc-okhttp:1.7.0'
compile 'io.grpc:grpc-protobuf-lite:1.7.0'
compile 'io.grpc:grpc-stub:1.7.0'
compile 'javax.annotation:javax.annotation-api:1.2'
- project的gradle文件
project配置文件如下:
apply plugin: 'java'
buildscript {
repositories {
maven { url 'https://maven.google.com' }
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:2.3.3'
classpath 'com.google.protobuf:protobuf-gradle-plugin:0.8.1'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
maven { url 'https://maven.google.com' }
jcenter()
}
}
- 添加权限
<uses-permission android:name="android.permission.INTERNET"/>
- proto生成Java文件
(1) 把自己的proto文件复制粘贴到main/proto目录下,点击Android Studio中的Build菜单下的Rebuild Project即可
(2) Java文件生成位置:app/build/generated/source/proto/……
(3) 将Java文件复制出来即可使用
protobuf语法
- 指定proto语法版本
在proto文件第一行添加:
syntax = "proto3"
- 定义message
(1)定义: 一个message相当于java中的实体类,里面定义了不同数据类型的数据,并且在结尾处标上标签序号
(2)嵌套:一个message内部也可以定义message类型的数据
(3)字段格式:修饰符 参数类型 参数名称=字段编码值 [字段默认值]
(4)proto3字段格式特性:不允许加修饰符,不允许加字段默认值
例子:
message Reply{
// 修饰符 参数类型 参数名称=标识符 [字段默认值]
bool Result = 1;
string UUID = 2;
string Token = 3;
string extra = 4;
//这里定义了一个Info message格式的数据
Info info = 5;
}
message Info{
string id = 1;
string name = 2;
int32 age = 3;
}
- service 定义
(1)定义访问服务端的函数名称,传递的参数,返回的参数
(2)一个service可以定义多个待调用的函数
例子:
service TestService {
//格式: rpc 调用函数名 (传递请求的参数) returns (返回的参数) {}
rpc sayHello (Request) returns (Reply) {}
//这是另一个sayHello2函数
rpc sayHello2 (Request) returns (Reply) {}
}
- 保留标识符(reserved)
message中每一个字段都对应有一个标识符(1,2,3,4,5,6…), 当版本更新的时候,删除或者注释掉某一个字段的时候,保留标识符可以让这个标识号不会被新的字段名称使用,这样避免了bug等等
例如:在上面的Info这个message中,age这个字段的标识符是3,如果在下一个版本V2中,我们将age删除了,不要了,添加了一个叫sex的字段
(1)如果我们对3这个标识符做保留操作, sex这个字段标识符不能是3,否则编译不通过,这样是正确的,合理的;
(2)如果我们对3这个标识符不做保留操作,sex这个字段标识符或者其它新的字段使用3这个标识符,会导致前后V1和V2两个版本3这个标识符代表的字段不一致,出现其它Bug
例子:
message Persion{
string id = 1;
string name = 2;
//保留3,15,9,10,11这几个标识符不能被使用
reserved 3, 15, 9 to 11;
}
- 数据格式和Java语言格式对应表
proto | java | 备注 |
---|---|---|
double | double | |
float | float | |
int32 | int | 使用变长编码,对于负值的效率很低,如果你的域有可能有负值,请使用sint64替代 |
uint32 | int | 使用变长编码 |
uint64 | long | 使用变长编码 |
sint32 | int | 使用变长编码,这些编码在负值时比int32高效的多 |
sint64 | long | 使用变长编码,有符号的整型值。编码时比通常的int64高效。 |
sfixed32 | int | 总是4个字节 |
sfixed64 | long | 总是8个字节 |
fixed32 | int | 总是4个字节,如果数值总是比总是比228大的话,这个类型会比uint32高效。 |
fixed64 | long | 总是8个字节,如果数值总是比总是比256大的话,这个类型会比uint64高效。 |
bool | boolean | |
string | String | 一个字符串必须是UTF-8编码或者7-bit ASCII编码的文本。 |
bytes | ByteString | 可能包含任意顺序的字节数据。 |
还支持了枚举类型
数据格式默认值
(1)对于strings,默认是一个空string
(2)对于bytes,默认是一个空的bytes
(3)对于bools,默认是false
(4)对于数值类型,默认是0
(5)对于枚举,默认是第一个定义的枚举值,必须为0;
(6)对于消息类型(message),域没有被设置,确切的消息是根据语言确定的option可选项
//是否运行生成多个java文件
option java_multiple_files = false;
//这个选项表明生成java类所在的包。如果在.proto文件中没有明确的声明java_package,就采用默认的包名
option java_package = “com.example.administrator.grpctest.proto”;
//生成的java类名字
option java_outer_classname = “TestProto”;
//生成方式:可以被设置为 SPEED, CODE_SIZE,or LITE_RUNTIME。这些值将通过如下的方式影响C++及java代码的生成:
option optimize_for = SPEED;
(1)SPEED (default): protocol buffer编译器将通过在消息类型上执行序列化、语法分析及其他通用的操作。这种代码是最优的。
(2)CODE_SIZE: protocol buffer编译器将会产生最少量的类,通过共享或基于反射的代码来实现序列化、语法分析及各种其它操作。采用该方式产生的代码将比SPEED要少得多, 但是操作要相对慢些。当然实现的类及其对外的API与SPEED模式都是一样的。这种方式经常用在一些包含大量的.proto文件而且并不盲目追求速度的 应用中。
(3)LITE_RUNTIME: protocol buffer编译器依赖于运行时核心类库来生成代码(即采用libprotobuf-lite 替代libprotobuf)。这种核心类库由于忽略了一 些描述符及反射,要比全类库小得多。这种模式经常在移动手机平台应用多一些。编译器采用该模式产生的方法实现与SPEED模式不相上下,产生的类通过实现 MessageLite接口,但它仅仅是Messager接口的一个子集
- 导包使用
场景:test.proto中调用test2.proto文件中的DeviceInfo这个message,test2.proto的包名是 test2package
(1)import “test2.proto”; 添加你需要调用哪一个proto文件
(2)在test.proto中调用: test2package.DeviceInfo deviceInfo = 3;
例子:
syntax = "proto3";
package testpackge;
//导包
import "test2.proto"
message Info{
string id = 1;
//调用Message
test2package.DeviceInfo deviceInfo = 2;
}
- proto使用例子
调用服务器sayHello函数为例:
syntax = "proto3";
option java_multiple_files = false;
option java_package = "com.example.administrator.grpctest.proto";
option java_outer_classname = "HelloWorldProto";
option optimize_for = CODE_SIZE;
//service package name
package proto;
//服务端中的HelloWorld这个接口,这个接口中可以包含多个方法
service HelloWorld {
rpc sayHello (RequestP) returns (ReplyP) {}
}
message ReplyP{
bool Result = 1;
string UUID = 2;
string Token = 3;
string extra = 4;
}
message RequestP{
string UUID = 1;
string Token = 2;
PersionInfo persionInfo = 3;
reserved 15, 9 to 11;
}
message PersionInfo{
string id = 1;
string name = 2;
int32 age = 3;
enmu Sex{
int32 m = 0;
int32 w = 1;
}
Sex sex = 4;
}
grpc源码分析
以调用登录接口为例
1. 阻塞调用
HelloWorldProto.LoginReply reply = platformStub.login(loginRequest)
-> blockingUnaryCall(getChannel(), METHOD_LOGIN, getCallOptions(), request)
-> ListenableFuture<RespT> responseFuture = futureUnaryCall(call, param); //然后线程一直在这里阻塞线程
-> asyncUnaryRequestCall(call, param, new UnaryStreamToFuture<RespT>(responseFuture), false); //在这里等待数据返回到responseFuture中
-> startCall(call, responseListener, streamingResponse); //开始调用
call.sendMessage(param); //并且调用sendMessage将数据发送出去
-> call.start(responseListener, new Metadata()); //调用服务端
-> public abstract void start(Listener<RespT> responseListener, Metadata headers); //服务端
2.非阻塞调用
sPlatformLoginStub.login(loginRequest, new StreamObserver<HelloWorldProto.LoginReply>() {
@Override
public void onNext(HelloWorldProto.LoginReply value) {
Log.e("wnw", "next:" + System.currentTimeMillis());
}
@Override
public void onError(Throwable t) {
Log.e("wnw", "error");
}
@Override
public void onCompleted() {
Log.e("wnw", "complete:" + System.currentTimeMillis());
}
});
-> asyncUnaryCall(getChannel().newCall(METHOD_LOGIN, getCallOptions()), request, responseObserver);
-> asyncUnaryRequestCall(call, param, observer, false);
-> asyncUnaryRequestCall(call,param,new StreamObserverToCallListenerAdapter<ReqT, RespT>(responseObserver,
new CallToStreamObserverAdapter<ReqT>(call),streamingResponse),streamingResponse); //在这里将responseObserver传递进去
-> startCall(call, responseListener, streamingResponse); //开始调用ClientCall的startCall
call.sendMessage(param); //并且调用sendMessage将数据发送出去
-> call.start(responseListener, new Metadata()); //调用服务端,
-> public abstract void start(Listener<RespT> responseListener, Metadata headers); //服务端
从上面跟踪的代码逻辑看,后面调用的逻辑是一致的,主要的区别在:
- 阻塞方式传递的是:UnaryStreamToFuture 变量,其继承了ClientCall.Listener
- 非阻塞方式传递的是:StreamObserverToCallListenerAdapter, 它也是继承了ClientCall.Listener
- ClientCall.Listener是服务端返回数据调用的回调接口,将数据传递回来
下面研究UnaryStreamToFuture和StreamObserverToCallListenerAdapter的区别之处:
1. 先看 ClientCall.Listener文件中定义了什么
public abstract class ClientCall<ReqT, RespT> {
public abstract static class Listener<T> {
//服务器相应数据返回的头部信息
public void onHeaders(Metadata headers) {}
//服务器返回的message
public void onMessage(T message) {}
//ClientCall close,status == 0, 代表OK
public void onClose(Status status, Metadata trailers) {}
//ClientCall现在能够发送额外的消息
public void onReady() {}
}
........
}
2.再看StreamObserverToCallListenerAdapter, 在这里面,重写了ClientCall.Listener的这几个函数
(1)在 onMessage()函数中:调用了observer.onNext(message); //这里直接将数据交给了观察者
(2)在 onClose()函数中:
if (status.isOk()) {
observer.onCompleted(); //调用观察者结束
} else {
observer.onError(status.asRuntimeException(trailers)); //调用观察者错误
}
3.在看UnaryStreamToFuture函数,在这里面,也重写了ClientCall.Listener的这几个函数
(1)在onMessage()函数中:this.value = value; 在这里把服务器返回的value存下来
(2)在onClose()函数中:
if (status.isOk()) {
if (value == null) {
// No value received so mark the future as an error
responseFuture.setException(
Status.INTERNAL.withDescription("No value received for unary call")
.asRuntimeException(trailers));
}
responseFuture.set(value); //在这里将数据设置responseFuture返回
} else {
responseFuture.setException(status.asRuntimeException(trailers));
}
}
原来同步和异步的回调的差别就在这里,二者都是监听服务器返回的函数onMessage(), onClose()函数,如果是异步,就调用观察者将数据通过onNext()函数返回,如果是同步,就将数据直接返回。