ProtoBuf

Thu, 28 Dec 2023 19:57:18 +0000

初次听闻 ProtoBuf，以为他是只是一种“二进制编码的 JSON 平替”。但事实与之相去甚远

基本理解

在此节中我会将 JSON 与 ProtoBuf 进行横向对比。

ProtoBuf 在设计上以“机器快速解析”为终极目标，并尽力减少不必要的数据（但不包括压缩）。为此它舍弃了 JSON 的以下优秀特性：

自解释性：单个 JSON 字符串就可以解析出一个完整的以键值对为基础的对象；然而，ProtoBuf 将格式定义与数据分离，protobuf 数据必须依赖某个目标语言中预定义的类似 struct 的东西、配合 protobuf 的数据编码解码算法才能够解析。
可读性：很明显，作为一种二进制编码，它是不可读的。
简单性/易手搓：JSON 如此流行不可不归功于其语法的简洁明了，这也意味着对于一个新语言而言支持非常简单。而 ProtoBuf 定义了一个新的数据结构，有点点复杂，不太好实现。

当然肯定有不少的优秀特性：

高速解析：由于格式定义和数据的分离，格式定义被预编译进了代码内部，且以二进制编码数据，从而减少了解析时键名解析、类型判断、数值解析等开销，实现了 3-100 倍的解析性能提升。
节省空间¹：ProtoBuf 通过应用编号(Field Numbers)代替了键名，节省了寻键的开销和键的内存占用；ProtoBuf 用 Varint 和 ZigZag 减少了整数这种数据类型的内存占用。最重要的是，ProtoBuf 中所有部分都是可选的，实际传输中可以只传输要传输的那一部分，从而减少传输数据量；而不必像固定 struct 一样不论数据需不需要都会占固定内存。
可变长度²：ProtoBuf LEB128 表示变长数据的长度，实现了非标记（例如 JSON的 {}）变长度。

个人感觉，ProtoBuf 是 Golang 开发者们为了 Golang 这样的静态语言而设计出的高效、扩展性强的结构化可选数据表示方式。如果把静态考虑在内，ProtoBuf 的确是最好的结构化可选数据表示方式。

打开方式

使用 ProtoBuf 需要三步：

安装工具链，详见官网
在 .proto 文件中编写你的 protobuf 格式
用 protoc 把 .proto 文件编译成目标语言的代码
在目标语言中引用编译出来的代码，引用 Google ProtoBuf 官方库，解析编码你的 ProtoBuf 数据

ProtoBuf 语法³

最基础的 protobuf 文件定义示例如下：

微信小程序光速入门

Sun, 17 Dec 2023 19:28:52 +0000

最小程序组成¹

在官网下载开发者工具安装好。

新建一个目录。一个最小程序组成如下：

//app.js
App({});

{
  "pages": [
    "pages/home"
  ]
}

//pages/home.js
Page({});

<!--pages/home.wxml-->
<view>
  <text>hello world</text>
</view>

调用逻辑：首先运行 app.js。App() 检查了 app.json。在此例中，将其中 pages/home.js 加以处理，其 Page() 编译 pages/home.wxml。

项目配置 `app.json`

app.json 文件配置了小程序的全局参数，包括 pages 列表和 window 字典，和其他。pages 存储了所有待编译的页面，window 包括了这堆页面的全局设定；常用 navigationBarBackgroundColor 与 navigationBarTitleText 两个参数。一个示例如下：

{
  "pages": [
    "pages/home"
  ],
  "window":{
    "navigationBarBackgroundColor": "#fff",
    "navigationBarTitleText": "标题",
    "navigationBarTextStyle":"black"
  }
}

既然有“全局设定”，也就有局部设定。对于一个页面 ${NAME}.js，其 window 设定存储在该目录下 ${NAME}.json 中，会覆盖全局的 window 设定。例如

{
  "navigationBarBackgroundColor": "#000",
  "navigationBarTitleText": "Title"
}

程序启动

App() 必须在 app.js 中调用，必须调用且只能调用一次。不然会出现无法预期的后果。

尝鲜 on wsmの随记