本文作者:丁同舟,来自金蝶随手记技术团队。 1、前言 本文接上篇《金蝶随手记团队分享:还在用JSON? Protobuf让数据传输更省更快(原理篇)》,以iOS端的Objective-C代码为例,向您
接上篇《金蝶随手记团队的Protobuf应用实践(原理篇)》,本文将以iOS端的Objective-C代码为例,图文并茂地向您菔救绾卧趇OS工程中快速使用Protobuf,希望对你有帮助。
在当今移动网络时代,手机流量和电量是宝贵的资源,对于移动端最常见的即时通讯IM应用,由于实时通信基于Socket长连接,它对于流量和电量的需求较一般应用来说更高(详见《移动端IM实践:WhatsApp、Line、微信的心跳策略分析》)。
let-netty-easy 前言: 尚未完成,持续更新中...! 什么是Netty?能做什么? Netty是一个致力于创建高性能网络应用程序的成熟的IO框架 相比较与直接使用底层的Java I
Protobuf 作为一种跨平台、语言无关、可扩展的序列化结构数据通讯协议,已广泛应用于网络数据交换的场景中(比如IM通信、分布式RPC调用等)。
最近我负责的 LiveChat 客服聊天系统到了自研阶段,任务类似于做一个腾讯云IM这样的通信层SDK。在和后台进行技术选型讨论后,确定了数据传输层协议格式使用 Protobuf。
protobuf全称Google Protocol Buffers,是google开发的的一套用于数据存储,网络通信时用于协议编解码的工具库。protobuf是一种灵活高效的独立于语言平台的结构化数据表示方法。在通信协议和数据存储等领域中使用比较多。protobuf对于结构中的每个成员会提供set系列函数和get系列函数。与XML相比,protoBuf更小更快更简单。你可以用定义protobuf的数据结构。用protobuf编译器生成特定语言的源代码,如C++,Java,Python等。
本文要分享的是iOS版微信内部正在推广和使用的一个高性能通用key-value 组件的技术实践过程,该组件在微信内部被命名为MMKV(以下简称MMKV)。
跟移动端IM中追求数据传输效率、网络流量消耗等需求一样,随手记客户端与服务端交互的过程中,对部分数据的传输大小和效率也有较高的要求,普通的数据格式如 JSON 或者 XML 已经不能满足,因此决定采用 Google 推出的 Protocol Buffers 以达到数据高效传输。
Protobuf,全称 Protocol Buffers,是 Google 开发的一种数据序列化协议。相比于 JSON、XML 等数据格式,它更小、更快、更简单。下面是 Protobuf 的一些基本语法和使用方法。
Protobuf是Google开源的一种混合语言数据标准,已被各种互联网项目大量使用。
搞即时通讯IM方面开发的程序员,在谈到通讯层实现时,必然会提到网络编程。那么计算机网络编程中的一个非常基本的问题:到底该怎样组织Client与server之间交互的数据呢?
以现在主流的即时通讯应用形态来讲,一个完整的即时通讯IM应用其实是即时通信(英文简写:IM=Instant messaging)和实时通信(英文简写:RTC=Real-time communication)2种技术组合在一起的一整套网络通信系统。之所以以IM这个简写代称整个即时通讯软件,其实是历史原因了(因为早期的诸如ICQ这样的即时通讯工具,也就是文字聊天,并没有加入实时音视频这样的实时通信技术),对这个话题有兴趣的可以到网上查一查IM的发展历史。
本文将带你一起初步认识Thrift的序列化协议,包括Binary协议、Compact协议(类似于Protobuf)、JSON协议,希望能为你的通信协议格式选型带来参考。
Linux下protobuf的安装过程&简单使用。 protobuf是google开发的一个灵活的、高效的用于序列化数据的协议。相比较XML和JSON格式,protobuf更小、更快、更便捷。
众所周之,通常我们开发一个移动端应用,会直接调用系统提供的网络请求接口去服务端请求数据,再针对返回的数据进行一些处理,或者使用iOS中的开源AFNetworking/OKHttp这样的网络库(Android中可以用HttpURLConnection或者开源的okhttp库),管理好请求线程和队列,再自动做一些数据解析,就结束了。
一直想写一篇关于im即时通讯分享的文章,无奈工作太忙,很难抽出时间。今天终于从公司离职了,打算好好休息几天再重新找工作,趁时间空闲,决定静下心来写一篇文章,毕竟从前辈那里学到了很多东西。
本系列文章的前面几篇主要是从Electron技术本身进行了讨论(包括:第1篇初步了解Electron、第2篇进行了快速开始和技术体验、第3篇基于实际开发考虑的技术栈选型等),各位读者也应该对Electron的开发有了较为深入的了解。
本文主要分享的是如何从零设计开发一个中大型推送系统,因限于篇幅,文中有些键技术只能一笔带过,建议有这方面兴趣的读者可以深入研究相关知识点,从而形成横向知识体系。
在使用 Caffe 进行深度学习模型训练或推理时,有时可能会遇到 "initialization of _caffe raised unreported exception" 的错误。本篇文章将详细解释这个错误的原因,并提供解决方案。
本系列的前几篇主要是从各个角度讲解Protobuf的基本概念、技术原理这些内容,但回过头来看,对比JSON这种事实上的数据协议工业标准,Protobuf到底性能到底高多少?
自从2018年8月20日子弹短信在锤子发布会露面之后(详见《老罗最新发布了“子弹短信”这款IM,主打熟人社交能否对标微信?》),关于它的讨论不绝于耳,7 天融资 1.5 亿的传闻更是将它推到了风口浪尖(请见《[资讯] “子弹短信”发布一周即融得1.5亿资金》)。
前言:说到JSON可能大家很熟悉,是目前应用最广泛的一种序列化格式,它使用起来简单方便,而且拥有超高的可读性。但是在越来越多的应用场景里,JSON冗长的缺点导致它并不是一种最优的选择。
由于grpc是跨语言的所以这里用golang做为示范,golang客户端代码,小编这里也踩了许多坑,最主要的是两个proto文件一定要一致,golang 中使用必须安装protoc,windows将环境变量指向安装目录的bin下面:
京东的京麦商家后台2014年构建网关,从HTTP网关发展到TCP网关。在2016年重构完成基于Netty4.x+Protobuf3.x实现对接PC和App上下行通信的高可用、高性能、高稳定的TCP长连接网关。
本文原作者:liuyan731,原文地址:liuyan731.github.io/2017/12/05/How-To-Use-APNs-Pushy,内容有改动。
在企业IM客服场景中,客服发送一条消息的背后,需要考虑网络通信、前端展示、后端存储以及安全性等多个方面的技术支持。单从前端层面来说,就需要考虑到消息的显示、状态更新、稳定传输以及极限操作消息不卡顿等场景。随着IM系统的不断更新迭代,已经实现了从外采到自研再到一站式全场景工作台的搭建,我们能够很明显地感知到客服对于IM的体验要求越来越高了,因此客服发送一条消息背后所涉及的技术和思考也越来越重要。
做海外市场,特别目标是面向全球的用户,网络的重要性不言而喻。试想一个移动端应用,比如即时通讯IM,聊天消息的本质就是人跟人在说话,一条消息从发送到接受需要10秒的时间,这恐怕会让用户崩溃,随之就是被无情地卸载,开拓海外市场那就是做梦了。
前言:说到JSON可能大家很熟悉,是目前应用最广泛的一种序列化格式,它使用起来简单方便,而且拥有超高的可读性。但是在越来越多的应用场景里,JSON冗长的缺点导致它并不是一种最优的选择。 一、常用序列化格式介绍 目前JAVA常用的序列化有protobuf,json,xml,Serializable,hessian,kryo。他们的优缺点如下: JSON:不多说了,用途广泛,序列化方式还衍生了阿里的fastjson,美团的MSON,谷歌的GSON等更加优秀的转码工具。 优点:使用方便。 缺点:数据冗长,转码性
有过移动端开发经历的开发者都深有体会:移动端IM的开发,与传统PC端IM有很大的不同,尤其无线网络的不可靠性、移动端硬件设备资源的有限性等问题,导致一个完整的移动端IM架构设计和实现都充满着大量的挑战。本文将简述移动端IM最重要的架构设计和通信协议选择方面的坑点,希望为IM开发者同行带来些许启发。(本文同步发布于:http://www.52im.net/thread-289-1-1.html)
Protocol Buffer是google出品的一种对象序列化的方式,它的体积小传输快,深得大家的喜爱。protobuf是一种平台无关和语言无关的协议,通过protobuf的定义文件,可以轻松的将其转换成多种语言的实现,非常方便。
本篇文章主要介绍的是SpringBoot整合Netty以及使用Protobuf进行数据传输的相关内容。Protobuf会介绍下用法,至于Netty在netty 之 telnet HelloWorld 详解中已经介绍过了,这里就不再过多细说了。
在网络通信和通用数据交换等应用场景中经常使用的技术是 JSON 或 XML,在微服务架构中通常使用另外一个数据交换的协议的工具ProtoBuf。
通过将 结构化的数据 进行 串行化(序列化),从而实现 数据存储 / RPC 数据交换的功能
为了解决从 JavaScript 逐步迁移到 TypeScript 过程中遇到的痛点,FreeWheel 核心业务团队评估并提出了一套由 Protobuf 文件自动化生成 TypeScript 类型声明文件的流程,支持 Protobuf 文件的变化触发类型声明文件的自动更新。所有的 TypeScript 类型声明文件以微服务为单位储存,集中维护在公司级别的 TypeScript 中心化仓库里。
近几年的科技发展趋势十分有趣,关注科技圈的朋友应该都能有一种共识,那就是人类科技进化的“技能点”似乎都点在了 AI、VR、大数据、物联网与区块链上,相关技术在短时间内被广泛普及并大量应用。其速度之快,应用之广,令人惊叹。 而 Python 则与它们在技术上有着不可或缺的紧密关联,这使得各行业对 Python 技术服务的需求量越来越大,尤以爬虫技术服务为甚,现在早已供不应求。 由于需求明显大于供给,长此以往,不平衡的供需关系使爬虫技术服务的报酬变得极高。所以包括我在内的很多 Python 圈内人,都会在业余
MMKV的出现是为了替代SharedPreferences的轻量级存储解决方案。SharedPreferences需要被替换的原因主要是存在下述问题:
在上一篇中和大家分享了HTTPS协议的优化,这一篇我们先从一道被各厂面试官考烂的面试题“从浏览器输入地址到呈现页面中间发生了什么,结合通信协议”出发,开始谈谈HTTP1.1和HTTP/2,简单介绍编解码工具Protobuf并从多角度提供上述技术的优化思路。给你5分钟先思考下这道题,计时开始……
本文原题“搭建高性能的IM系统”,作者“刘莅”,内容有修订和改动。为了尊重原创,如需转载,请联系作者获得授权。
博客地址 : http://blog.csdn.net/shulianghan/article/details/42707293
作者:SG4YK,腾讯 PCG 后台开发工程师 近日简单学习了 Protobuf 中的编码实现,总结并整理成文。本文结构总体与 Protobuf 官方文档相似,不少内容也来自官方文档,并在官方文档的基础上添加作者理解的内容,如有出入请以官方文档为准。作者水平有限,难免有疏漏之处,欢迎指正并分享您的意见。 0x00 Before you start 简单来说,Protobuf 的编码是基于变种的 Base128。在学习 Protobuf 编码或是 Base128 之前,先来了解下 Base64 编码。
IM App 是我做过 App 类型里复杂度最高的一类,里面可供深究探讨的技术难点非常之多。这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制(因为我个人对移动客户端的经验积累的比较丰富嘛)。
京麦实时消息推送是京东的京麦商家开放平台的核心组成部分。从消息源到消息中心再到触达用户,以及最终根据消息协议呼起操作页面,京麦实时消息推送是一个完整且健康的生态闭环。下面我会详细的介绍下京麦实时消息推送是如何在演变中不断完善的。
因为只要大家技术和能力过关,八股文能帮助大家在面试时有很好的表现和稳定的发挥,让面试官预估到你能带来的价值,从而实现薪资高涨幅。
领取专属 10元无门槛券
手把手带您无忧上云