Pages: 7/282 First page Previous page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Next page Final page [ View by Articles | List ]
Feb 29

要通信,必须有协议,否则双方无法理解对方的码流。在protobuf中,协议是由一系列的消息组成的。因此最重要的就是定义通信时使用到的消息格式。

Protobuf消息定义

消息由至少一个字段组合而成,类似于C语言中的结构。每个字段都有一定的格式。

字段格式:限定修饰符① | 数据类型② | 字段名称③ | = | 字段编码值④ | [字段默认值⑤]

①.限定修饰符包含 required\optional\repeated

Required: 表示是一个必须字段,必须相对于发送方,在发送消息之前必须设置该字段的值,对于接收方,必须能够识别该字段的意思。发送之前没有设置required字段或者无法识别required字段都会引发编解码异常,导致消息被丢弃。

Optional:表示是一个可选字段,可选对于发送方,在发送消息时,可以有选择性的设置或者不设置该字段的值。对于接收方,如果能够识别可选字段就进行相应的处理,如果无法识别,则忽略该字段,消息中的其它字段正常处理。---因为optional字段的特性,很多接口在升级版本中都把后来添加的字段都统一的设置为optional字段,这样老的版本无需升级程序也可以正常的与新的软件进行通信,只不过新的字段无法识别而已,因为并不是每个节点都需要新的功能,因此可以做到按需升级和平滑过渡。

Repeated:表示该字段可以包含0~N个元素。其特性和optional一样,但是每一次可以包含多个值。可以看作是在传递一个数组的值。

②.数据类型

Protobuf定义了一套基本数据类型。几乎都可以映射到C++\Java等语言的基础数据类型.

      

protobuf 数据类型

描述

打包

C++语言映射

bool

布尔类型

1字节

bool

double

64位浮点数

N

double

float

32为浮点数

N

float

int32

32位整数、

N

int

uin32

无符号32位整数

N

unsigned int

int64

64位整数

N

__int64

uint64

64为无符号整

N

unsigned __int64

sint32

32位整数,处理负数效率更高

N

int32

sing64

64位整数 处理负数效率更高

N

__int64

fixed32

32位无符号整数

4

unsigned int32

fixed64

64位无符号整数

8

unsigned __int64

sfixed32

32位整数、能以更高的效率处理负数

4

unsigned int32

sfixed64

64为整数

8

unsigned __int64

string

只能处理 ASCII字符

N

std::string

bytes

用于处理多字节的语言字符、如中文

N

std::string

enum

可以包含一个用户自定义的枚举类型uint32

N(uint32)

enum

message

可以包含一个用户自定义的消息类型

N

object of class

N 表示打包的字节并不是固定。而是根据数据的大小或者长度。

例如int32,如果数值比较小,在0~127时,使用一个字节打包。

关于枚举的打包方式和uint32相同。

关于message,类似于C语言中的结构包含另外一个结构作为数据成员一样。

关于 fixed32 和int32的区别。fixed32的打包效率比int32的效率高,但是使用的空间一般比int32多。因此一个属于时间效率高,一个属于空间效率高。根据项目的实际情况,一般选择fixed32,如果遇到对传输数据量要求比较苛刻的环境,可以选择int32.

③.字段名称

字段名称的命名与C、C++、Java等语言的变量命名方式几乎是相同的。

protobuf建议字段的命名采用以下划线分割的驼峰式。例如 first_name 而不是firstName.

④.字段编码值

有了该值,通信双方才能互相识别对方的字段。当然相同的编码值,其限定修饰符和数据类型必须相同。

编码值的取值范围为 1~2^32(4294967296)。

其中 1~15的编码时间和空间效率都是最高的,编码值越大,其编码的时间和空间效率就越低(相对于1-15),当然一般情况下相邻的2个值编码效率的是相同的,除非2个值恰好实在4字节,12字节,20字节等的临界区。比如15和16.

1900~2000编码值为Google protobuf 系统内部保留值,建议不要在自己的项目中使用。

protobuf 还建议把经常要传递的值把其字段编码设置为1-15之间的值。

消息中的字段的编码值无需连续,只要是合法的,并且不能在同一个消息中有字段包含相同的编码值。

建议:项目投入运营以后涉及到版本升级时的新增消息字段全部使用optional或者repeated,尽量不实用required。如果使用了required,需要全网统一升级,如果使用optional或者repeated可以平滑升级。

⑤.默认值。当在传递数据时,对于required数据类型,如果用户没有设置值,则使用默认值传递到对端。当接受数据是,对于optional字段,如果没有接收到optional字段,则设置为默认值。

关于import

protobuf 接口文件可以像C语言的h文件一个,分离为多个,在需要的时候通过 import导入需要对文件。其行为和C语言的#include或者java的import的行为大致相同。

关于package

避免名称冲突,可以给每个文件指定一个package名称,对于java解析为java中的包。对于C++则解析为名称空间。

关于message

支持嵌套消息,消息可以包含另一个消息作为其字段。也可以在消息内定义一个新的消息。

关于enum

枚举的定义和C++相同,但是有一些限制。

枚举值必须大于等于0的整数。

使用分号(;)分隔枚举变量而不是C++语言中的逗号(,)

eg.

enum VoipProtocol

{

    H323 = 1;

    SIP  = 2;

    MGCP = 3;

    H248 = 4;

}

Feb 19
http://siberiawolf.com/free_programming/index.html
Feb 18
2016、至关重要的一年,开始新的征程,愿一切顺利!
Jan 20
在angularjs的sap项目中使用了requirejs做模块管理,rjs参与压缩,在配置了很多次path之后压缩没有问题,发现压缩后的文件一直报错,最后取消了uglify的混淆解决问题,参考了以下文档,感谢作者分享

我在项目使用了AngularJS框架,用RequireJS做异步模块加载(AMD),在做文件合并压缩时,遇到了一些坑,有些只是解决了,但不明白原因。

那些坑
1. build.js里面的paths必须跟main.js里面的保持一致。

这个build.js就是r.js使用的配置文件,而main.js就是RequireJS的main文件。在合并压缩时候,build.js文件里面也需要写paths,而且还是跟main.js一样,我很奇怪为什么就不能识别main里面的require.config的paths,省得合并的时候还要将paths拷贝过来(我试过build.js里面没有paths,是不能合并的)。(-_-!!!)

2. 某些依赖库需要写整个相对路径才能做合并。

在项目里, 我使用一个叫layer的第三方库(库是以requireJS define写的),一开始只做开发时候,在paths配置了路径后,使用此库只需要用个简称(define依赖时候)。 但在做合并时候,竟然提示文件不存在(因为直接拿简称去拼文件地址了),无奈之下只能修改这个库的使用办法,全部使用到这个库的都写整个相对路径,这个时候开发和做合并才没有错。

3. 合并之后可以运行,加上压缩就不可以。

这个是最严重问题,最严重问题,最严重问题。在文件合并压缩后,使用文件时候,AngularJS运行就不正常了,总是报模块初始化失败,Failed to instantiate module common due to: Error: [$injector:unpr] Unknown provider: e,如下图。
Highslide JS


很关键的一个点就是,不压缩可以用,一旦压缩了(用了默认的压缩),使用就会报错。所以思考必定某些东西被“压坏”了,网上某些文章都说是需要下面这样写AngularJS cntroller、directive等,使用的服务用字符串定义。

commonModule.controller( "broswerCtrl" ,["$scope" ,"$sce" , function ($scope,$sce){
可是我的整个应用就是这样定义,并没有给它注入错误的机会。[b]最后在无奈之下,就只能配置mangle: false,不混淆变量名,这样做后,合并压缩的文件就能正确使用了!!!配置文件如下


[/b]PS:简单说法就是,合并压缩可以,变量名不能混淆(总觉得怪怪的),感觉问题暂时无解。

4. 第二层的require,做合并的时候,是合并不出来。

例如在mian.js里面这样加载模块,在合并时候会发现第二层的require并没有被合并到。

这时需要在build.js加findNestedDependencies: true, 这时才会合并第二层。

合并准备

安装nodejs

文件合并压缩基于nodejs,所以先安装nodejs,下载地址: http://blog.nodejs.org/2013/07/25/node-v0-10-15-stable/

下载r.js

r.js配合requirejs模块写法对文件进行合并,压缩,下载地址: https://github.com/jrburke/r.js

简单配置

配置文件最好写一个build.js,如下:

这里就讲几个关键属性:

baseUrl:所有的模块(般就是js)都相对于这个路径存在。

optimize:优化脚本文件的方式,有下面5种取值方式。

uglify:(默认) 用UglifyJS压缩。
uglify2: 用UglifyJS2( 2.1.2+)压缩。
closure: 使用Google's Closure Compiler 简单优化模式压缩文件, 仅在优化工具使用Java有效。
closure.keepLines:跟closure参数一样, 只不过保留换行符。
none: 不做压缩。
findNestedDependencies:寻找require()里面的require或define调用的依赖。

PS:配置属性还有很多,就不一细细说了,有篇文章写得很详尽,地址:http://segmentfault.com/a/1190000002403806#articleHeader37

当文件配置好后,就执行命令合并压缩

node r.js -o build.js
总结

RequireJS模块的合并压缩还是比较简单的,但是遇到AngularJS,在压缩方面就有些问题了,目前没找到什么更好办法。
Jan 13

写的很好的一篇文章,原文来自淘宝前端的“小胡子哥哥”,前端发展瞬息万变,伴随新硬件、新技术的出现,更多好的技术将会如雨后春笋般出现!

Web 发展了几十个春秋,风起云涌,千变万化。我很庆幸自己没有完整地经历过这些年头,而是站在前人的肩膀上行走。Web 技术发展的速度让人感觉那几乎不是继承式的迭代,而是一次又一次的变革,一次又一次的创造。这几年的前端,更为之甚!

我要说话

我从 12 年底开始接触前端,12 年之前的前端发展情况只能从上一辈的笔触中领会。本文会盘点从 09 年开始到 15 年间前端技术的革新,同时也会从多个角度,解读近几年前端技术发展的潜在因素,其中穿插了若干对前端演进的拙见,难免会有错误和疏漏,望读者可以补充和斧正。

Pages: 7/282 First page Previous page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Next page Final page [ View by Articles | List ]