protobuf

vs2015编译protobuf 下载protobuf 下载最新Cmake cmake进行配置 使用vs进行编译即可 下载protobuf 由于使用vs2015 编译protobuf 由于vs2015 不支持最新的c++标准所以需要下载老版本的进行编译，我这边使用的3.6.1.3进行编译 下载地址 下载最新Cmake cmake进行配置 选择vs版本为vs2015 然后选择位数为32或者64即可 使用vs进行编译即可 在cmake配置好的安装路径即可找到编译好的文件 来源： https://blog.csdn.net/suibiandewo93/article/details/102364815

一.简介 gRPC 是一个由Google开源的，跨语言的，高性能的远程过程调用（RPC）框架。 gRPC使客户端和服务端应用程序可以透明地进行通信，并简化了连接系统的构建。它使用HTTP/2作为通信协议，使用 Protocol Buffers 作为序列化协议。 它的主要优点： 现代高性能轻量级 RPC 框架。 约定优先的 API 开发，默认使用 Protocol Buffers 作为描述语言，允许与语言无关的实现。 可用于多种语言的工具，以生成强类型的服务器和客户端。 支持客户端，服务器和双向调用。 通过Protocol Buffers二进制序列化减少网络使用。 使用 HTTP/2 进行传输 这些优点使gRPC非常适合： 高性能轻量级微服务。 需要多种编程语言同时使用的项目。 需要处理流式请求或响应的点对点实时服务。 摘自 微软官方文档 支持的语言如下： 二.gRPC on .NET Core gRPC 现在可以非常简单的在 .NET Core 和 ASP.NET Core 中使用，在 .NET Core 上的实现的开源地址： https://github.com/grpc/grpc-dotnet ，它目前由微软官方 ASP.NET 项目的人员进行维护，良好的接入 .NET Core 生态。 .NET Core 的 gRPC 功能如下： Grpc.AspNetCore

protocol buffers[1]是google提供的一种将结构化数据进行序列化和反序列化的方法，其优点是语言中立，平台中立，可扩展性好，目前在google内部大量用于数据存储，通讯协议等方面。PB在功能上类似XML，但是序列化后的数据更小，解析更快，使用上更简单。用户只要按照proto语法在.proto文件中定义好数据的结构，就可以使用PB提供的工具（protoc）自动生成处理数据的代码，使用这些代码就能在程序中方便的通过各种数据流读写数据。PB目前支持Java, C++和Python3种语言。另外，PB还提供了很好的向后兼容，即旧版本的程序可以正常处理新版本的数据，新版本的程序也能正常处理旧版本的数据。 笔者在项目的测试过程中，遇到了一个protocal buffer使用不当倒是的模块内存不断上涨的问题。这里和大家分享一下问题的定位、分析以及解决过程。 1. 问题现象 5月，出现问题的模块（以下成为模块）内存有泄露的嫌疑，表现为程序在启动后内存一直在缓慢的上涨。由于该模块每天都存在重启的操作，因此没有带来较大的影响。 8月，发现线上模块的内存上涨速度加快。 9月，模块线上出现内存报警。内存使用量从启动时的40G，在70小时左右上涨到50G，由于会出现OOM的风险，模块不得不频繁重启。 9月底，模块的某个版本上线后，由于内存使用量稍有增加

参考链接： 最常用的两种C++序列化方案的使用心得（protobuf和boost serialization） [c++] Google Protobuf库 1. 什么是序列化？ 程序员在编写应用程序的时候往往需要将程序的某些数据存储在内存中，然后将其写入某个文件或是将它传输到网络中的另一台计算机上以实现通讯。这个将 程序数据转化成能被存储并传输的格式的过程被称为“序列化”（Serialization），而它的逆过程则可被称为“反序列化” （Deserialization）。 简单来说，序列化就是将对象实例的状态转换为可保持或传输的格式的过程。与序列化相对的是反序列化，它根据流重构对象。这两个过程结合起来，可以轻 松地存储和传输数据。例如，可以序列化一个对象，然后使用 HTTP 通过 Internet 在客户端和服务器之间传输该对象。 总结：序列化：将对象变成字节流的形式传出去。 反序列化：从字节流恢复成原来的对象。 2. 为什么要序列化？好处在哪里？ 简单来说，对象序列化通常用于两个目的： （1） 将对象存储于硬盘上 ，便于以后反序列化使用 （2）在网络上传送对象的字节序列 对象序列化的好处在哪里？网络传输方面的便捷性、灵活性就不说了，这里举个我们经常可能发生的需求：你 有一个数据结构，里面存储的数据是经过很多其它数据通过非常复杂的算法生成的，由于数据量很大，算法又复杂

背景 上一篇 我们介绍了Kafka Streams中的消息转换操作map，今天我们给出另一个经典的转换操作filter的用法。依然是结合一个具体的实例展开介绍。 演示功能说明 本篇演示filter用法，即根据给定的过滤条件或逻辑实时对每条消息进行过滤处理。今天使用的输入topic消息格式如下： {"name": "George R. R. Martin", "title": "A Song of Ice and Fire"} {"name": "C.S. Lewis", "title": "The Silver Chair"} 我们打算过滤出name是“George R. R. Martin”的所有消息并发送到输出topic上。 初始化项目 创建项目目录： mkdir filter-streams cd filter-streams/ 配置项目 在filter-streams目录下创建build.gradle文件，内容如下： buildscript { repositories { jcenter() } dependencies { classpath 'com.github.jengelman.gradle.plugins:shadow:4.0.2' } } plugins { id 'java' id "com.google.protob" version "0.8.10"

背景 最近发现Confluent公司在官网上发布了 Kafka Streams教程 ，共有10节课，每节课给出了Kafka Streams的一个功能介绍。这个系列教程对于我们了解Kafka Streams还是很有帮助的。为什么要了解Kafka Streams？其实我一直觉得国内对于Flink有点过于迷恋了。大厂使用Flink尚自合理，毕竟数据量大且需要整套的集群管理调度监控功能。但一般的中小公司业务简单体量小，何必要费时费力地搭建一整套Flink集群。有很多简单的流处理业务场景使用Kafka Streams绰绰有余了，更何况Kafka Streams在设计上特别是在消息精确处理语义上一点都不必Flink差，只是它的定位不同罢了。如果你对Kafka Streams感兴趣，不妨关注一下这个系列。不过有点令人不爽的是，该教程使用Confluent Kafka作为开发环境进行演示，而且大量用到了Avro进行消息的序列化/反序列化。Confluent Kafka默认提供Schema Regstry、avro-console-producer和avro-console-consumer工具可以很方便地把消息转换成Avro格式并进行测试，但是如果你使用原生的Kafka（也就是社区版的Apache Kafka），这些功能要自行开发，非常地不方便。 鉴于此，我打算对照着这系列教程中的例子

protobuf oneof MyDataInfo.proto syntax = "proto2"; package com.fjh.netty.protobuf.oneof; option optimize_for = SPEED; option java_package = "com.fjh.netty.protobuf.oneof"; option java_outer_classname = "MyDataInfo"; message Person{ enum DataType{ StudentType =1; TeacherType = 2; } required DataType data_type = 1; oneof dataBody{ Student sutdent = 2; Teacher teacher = 3; } } message Teacher{ optional string name = 1; optional string work = 2; } message Student{ optional string name = 1; optional int32 age = 2; optional string address = 3; } 服务端 public class ProtobufOneOfServer { public static

文章大纲 引言 一、Protocol Buffer的使用步骤 二、在Android Studio使用Protobuf 1、在Android Studio项目中引入protobuf-gradle-plugin Gradle插件 2、在需要使用Protobuf 的Module下的build.gradle使用插件并进行对应的配置 3、创建proto文件 4、使用protobuf 进行序列化和反序列化 引言 前一篇文章 Android进阶——性能优化之一种更高效更轻量的序列化方案Protocol Buffer完全攻略（十） 总结了Protobuf的一些基础知识以及内部底层的编解码特点和原理，这一篇就好好的总结下Protobuf的应用。以下是性能优化系列的链接地址列表（持续更新）： Android进阶——性能优化之APP启动时黑白屏的根源解析及对应的优化措施小结（一） Android进阶——性能优化之APP启动过程相关源码解析(二) Android进阶——性能优化之APP启动速度优化实战总结（三） Android进阶——性能优化之布局渲染原理和底层机制详解（四） Android进阶——性能优化之布局优化实战经验小结（五） Android进阶——性能优化之内存管理机制和垃圾采集回收机制（六） Android进阶——性能优化之内存泄漏和内存抖动的检测及优化措施总结（七） Android进阶—

背景 thrift最早由facebook开发，后来贡献给了apache。thrift主要解决跨语言调用的问题。 thrift和protobuf有啥区别？ thrift和protobuf，都解决了一个问题就是夸语言数据结构的定义，json也解决了跨语言的数据结构定义，只不过json都是字符串的，传输的开销和解析的开销可能有些大。那么想传输二进制的话怎么办呢，可以自己定义数据结构，比如大家熟知的网络协议就是这么定出来的，前1个字节代表啥啥啥，第二个字节代表啥啥啥，然后客户端和服务端都遵守这个协议。在没有thrift或者profobuf之前好多cs程序就是这么干的。但是这么干很累啊，还得写文档，而且开发时候也不好记，不好交流。后来人们想出了个办法，就是用一个类似json格式的文件定义数据结构，然后自动生成代码去处理二进制的转换，这样人们既可以用好读的格式定义数据结构，又可以高效的使用，于是就诞生了protobuf和thrift这类东西。protobuf到此为止了，thrift又把服务端程序和客户端程序也顺手加进去可以自动生成了，这样程序员就只负责写业务逻辑，其他的传输啊神马的都自动生成了，这就是protobuf和thrift的区别。这样thrift就有了全套的RPC机制， 为什么要跨语言调用？ 有人认为是团队需要，不同的人擅长不同的语言，我认为从架构的角度想，有2点好处

1)笔记 1)req(请求)和res(回应)是对称的,但是消息上如果没body,不一定定义; 2)即使没有定义protobuf结构,但是这个命令是存在的,消息号依然要保留出来; 3)protobuf协议命名规范 (1)Req<-->Res: 请求与回应 (2)Onxxx: 广播 4)导入图片: 选择Sprite 2D 5)Resources与res目录 (1)Resources里面的只放代码加载的 (2)res的放编辑器的,没有用到就不会打包进来 6)Canvas屏幕适配 (1)top:背景用适配方式搞定, 里面具体小元素用绝对位置 (2)bg (3)bottom 来源： https://blog.csdn.net/themagickeyjianan/article/details/100809275