首页
/ 零内存分配的 JSON 路径查询库：深入解析 lazygit 依赖树中的 jsonparser（从源码到基准测试）

零内存分配的 JSON 路径查询库：深入解析 lazygit 依赖树中的 jsonparser（从源码到基准测试）

2026-09-04 16:48:34作者：沈韬淼Beryl
lazygit
simple terminal UI for git commands
项目地址：https://gitcode.com/GitHub_Trending/la/lazygit

本文以 lazygit 仓库中 vendor 目录下的第三方库 buger/jsonparser 的 README 为主体，完整梳理其“按路径查询 JSON、零内存分配”的设计思路与全部公开 API（Get、EachKey、ArrayEach、Set 等），并结合仓库内 vendor 的实际源码（parser.go、bytes.go、escape.go）验证关键实现细节，最后给出 README 中报告的三组基准测试数据与选型建议。

一、jsonparser 的定位：它在 lazygit 中的位置

jsonparser 是一个独立于 encoding/json 的 JSON 解析库，其设计目标是：不需要预先定义结构体，直接通过键路径访问 JSON 字段，且不进行任何内存分配。在 lazygit 仓库中，它作为间接依赖被 vendor 进来：

  • 版本声明：go.mod 第 52 行 github.com/buger/jsonparser v1.1.2 // indirect，// indirect 说明 lazygit 主模块并未直接 import 它；
  • vendor 目录内的直接引用方是有序映射库 wk8/go-ordered-map/v2：其 OrderedMap.UnmarshalJSON 方法（json.go 第 109 行）调用 jsonparser.ObjectEach 逐对遍历 JSON 顶层键值，再分发给 encoding/json 做类型解码——这正是 README 中 ObjectEach API 在真实生产依赖中的典型用法；
  • vendor 目录下除 README.md 外，还有上游项目的 LICENSE、Makefile、Dockerfile 以及源码文件 parser.go、bytes.go、bytes_safe.go、bytes_unsafe.go、escape.go、fuzz.go。

二、核心思想：不建结构体，按路径直接取字节

作者（README “Rationale” 一节）说明，该项目最初源于一个需要对接大量不可预测第三方 API 的项目：encoding/json 要么要求你精确知道数据结构，要么退化为缓慢且难管理的 map[string]interface{}；而市面上多数库只是 encoding/json 的封装。jsonparser 的路线是把 JSON 载荷当作 []byte 做字节级扫描，只解析你指定的键路径，返回指向原始数据内部子区间的切片，因此不产生数据拷贝。

下面的完整示例继承自 README（示例中的头像 URL 已替换为占位地址），目标是从嵌套 JSON 中提取全名、followers 数量和头像数组：

import "github.com/buger/jsonparser"

...

data := []byte(`{
  "person": {
    "name": {
      "first": "Leonid",
      "last": "Bugaev",
      "fullName": "Leonid Bugaev"
    },
    "github": {
      "handle": "buger",
      "followers": 109
    },
    "avatars": [
      { "url": "https://example.com/avatars/14009", "type": "thumbnail" }
    ]
  },
  "company": {
    "name": "Acme"
  }
}`)

// You can specify key path by providing arguments to Get function
jsonparser.Get(data, "person", "name", "fullName")

// There is `GetInt` and `GetBoolean` helpers if you exactly know key data type
jsonparser.GetInt(data, "person", "github", "followers")

// When you try to get object, it will return you []byte slice pointer to data containing it
// In `company` it will be `{"name": "Acme"}`
jsonparser.Get(data, "company")

// If the key doesn't exist it will throw an error
var size int64
if value, err := jsonparser.GetInt(data, "company", "size"); err == nil {
  size = value
}

// You can use `ArrayEach` helper to iterate items [item1, item2 .... itemN]
jsonparser.ArrayEach(data, func(value []byte, dataType jsonparser.ValueType, offset int, err error) {
	fmt.Println(jsonparser.Get(value, "url"))
}, "person", "avatars")

// Or use can access fields by index!
jsonparser.GetString(data, "person", "avatars", "[0]", "url")

// You can use `ObjectEach` helper to iterate objects { "key1":object1, "key2":object2, .... "keyN":objectN }
jsonparser.ObjectEach(data, func(key []byte, value []byte, dataType jsonparser.ValueType, offset int) error {
        fmt.Printf("Key: '%s'\n Value: '%s'\n Type: %s\n", string(key), string(value), dataType)
	return nil
}, "person", "name")

// The most efficient way to extract multiple keys is `EachKey`

paths := [][]string{
  []string{"person", "name", "fullName"},
  []string{"person", "avatars", "[0]", "url"},
  []string{"company", "url"},
}
jsonparser.EachKey(data, func(idx int, value []byte, vt jsonparser.ValueType, err error){
  switch idx {
  case 0: // []string{"person", "name", "fullName"}
    ...
  case 1: // []string{"person", "avatars", "[0]", "url"}
    ...
  case 2: // []string{"company", "url"},
    ...
  }
}, paths...)

两个值得注意的能力，源码均可证实：

  1. 数组下标作为路径段：jsonparser.GetString(data, "person", "avatars", "[0]", "url") 是合法的。在 parser.go 的 searchKeys 中，当路径段以 [ 开头时会解析下标（strconv.Atoi），再用 ArrayEach 逐元素定位到目标索引，然后对取出的元素递归 searchKeys；
  2. 键的转义处理：searchKeys 与 findKeyStart 在比较键名时都会先对键做 Unescape（parser.go），因此带转义序列的键名也能正确匹配。

三、完整 API 参考

README “Reference” 一节指出：库 API 的核心只有一个 Get，其余都是它的辅助函数。以下逐一给出签名（已对照 vendor 源码核实），并补充源码层面的返回语义。

Get

func Get(data []byte, keys ...string) (value []byte, dataType jsonparser.ValueType, offset int, err error)

接收数据结构与键路径，返回四元组：

  • value：指向原始数据结构中该键值内容的指针（子切片）；未找到或出错时为空切片。源码实现在 parser.go：先由 searchKeys 定位到值起始位置，再由 getType 判定类型并切出区间；字符串值会去掉两端引号后返回；
  • dataType：取值 NotExist、String、Number、Object、Array、Boolean 或 Null（源码枚举中还定义了 Unknown，见 parser.go）；
  • offset：值在提供数据结构中的结束偏移，主要用于 ArrayEach 等内部推进；
  • err：键未找到或其他解析问题时返回错误，键未找到时同时把 dataType 置为 NotExist。

多个键依次给出嵌套路径；不传任何键时，Get 会尝试提取当前位置最近的完整 JSON 值（简单值或整个对象/数组），这对流式读取数组很有用（ArrayEach 的实现正是这样循环调用的，见 parser.go）。

GetString

func GetString(data []byte, keys ...string) (val string, err error)

返回字符串时正确处理转义与 Unicode 字符（内部调用 ParseString → Unescape，见 parser.go）。注意这会产生额外的内存分配。类型不匹配时返回错误；值为 null 时返回 NullValueError。

GetUnsafeString

func GetUnsafeString(data []byte, keys ...string) (val string, err error)

如果只需要把值当字符串用、且可以放弃对转义符号的支持，GetUnsafeString 会把底层字节切片直接映射为 string，零分配（parser.go）。README 示例：

s, _, := jsonparser.GetUnsafeString(data, "person", "name", "title")
switch s {
  case "CEO":
    ...
  case "Engineer":
    ...
}

这里的 “unsafe” 指：该 string 的生命周期依附于底层字节切片，GC 释放原切片前才有效。README 明确建议只在当前上下文内使用，不要通过 channel 或其他途径传递出去。非 App Engine 平台下，bytesToString 由 unsafe 实现（bytes_unsafe.go）；在 App Engine 环境则走安全实现（bytes_safe.go 的 string(*b)，通过构建标签 appengine appenginevm 选择），两者函数签名保持一致。

GetBoolean / GetInt / GetFloat

func GetBoolean(data []byte, keys ...string) (val bool, err error)
func GetFloat(data []byte, keys ...string) (val float64, err error)
func GetInt(data []byte, keys ...string) (val int64, err error)

当你确切知道键的数据类型时，用这些辅助函数更简洁。三者都是对 Get 的类型断言包装：类型不是 Number/Boolean 就返回错误，null 则返回 NullValueError（parser.go）。GetInt 走的是库自研的 parseInt，GetFloat 走 strconv.ParseFloat（unsafe 版本）或安全版本（见下文第五节）。

ArrayEach

func ArrayEach(data []byte, cb func(value []byte, dataType jsonparser.ValueType, offset int, err error), keys ...string)

用于迭代数组，回调参数与 Get 的返回值一致。实现见 parser.go：先定位到 [，然后循环调用无键的 Get 提取每个数组元素，遇到 ] 或元素 offset 为 0 时结束，元素间以逗号分隔、遇到其他符号则报 MalformedArrayError。空数组（[ ]）会正常返回成功且不调用回调。

ObjectEach

func ObjectEach(data []byte, callback func(key []byte, value []byte, dataType ValueType, offset int) error, keys ...string) (err error)

用于迭代对象，README 示例：

var handler func([]byte, []byte, jsonparser.ValueType, int) error
handler = func(key []byte, value []byte, dataType jsonparser.ValueType, offset int) error {
	//do stuff here
}
jsonparser.ObjectEach(myJson, handler)

实现（parser.go）按“找键 → 跳过冒号 → Get 取值并回调 → 跳过逗号”四步推进；回调返回非 nil 错误可提前中断遍历；对带转义的键同样做栈缓冲 Unescape。这是该库在 lazygit 依赖树中的真实使用点：OrderedMap.UnmarshalJSON 用它保留 JSON 对象键的原始顺序（见第一节）。

EachKey

func EachKey(data []byte, cb func(idx int, value []byte, dataType jsonparser.ValueType, err error), paths ...[]string)

需要一次读取多个键时的最佳选择：README 指出，多次调用 Get 意味着多次扫描载荷，而 EachKey 只读一遍数据，每命中一条路径就回调一次，因此可以比多次 Get 快数倍。路径同样支持嵌套键。README 示例：

paths := [][]string{
	[]string{"uuid"},
	[]string{"tz"},
	[]string{"ua"},
	[]string{"st"},
}
var data SmallPayload

jsonparser.EachKey(smallFixture, func(idx int, value []byte, vt jsonparser.ValueType, err error){
	switch idx {
	case 0:
		data.Uuid, _ = value
	case 1:
		v, _ := jsonparser.ParseInt(value)
		data.Tz = int(v)
	case 2:
		data.Ua, _ = value
	case 3:
		v, _ := jsonparser.ParseInt(value)
		data.St = int(v)
	}
}, paths...)

从源码实现看（parser.go），EachKey 单次扫描中维护 pathsMatched 计数与 pathFlags 位数组，全部路径命中后立即提前退出，而不是扫完整个载荷；路径中的数组下标段同样受支持（通过 arrIdxFlags + ArrayEach 定位）。pathFlags/pathsBuf 采用 128 容量的栈上数组起步，路径数超出时才扩容分配，这也是零分配策略的一部分。

Set

func Set(data []byte, setValue []byte, keys ...string) (value []byte, err error)

接收现有数据结构、键路径与新值，返回更新（或新增）后的完整结构。README 标注该功能为实验性（experimental）。路径支持数组下标：jsonparser.Set(data, []byte("http://example.com"), "person", "avatars", "[0]", "url")。源码实现（parser.go）分两支：键已存在时直接按偏移量拼接替换（前缀 + 新值 + 后缀）；键不存在时逐级探测存在的子路径，再用 createInsertComponent 生成插入片段（自动补逗号、大括号/方括号、引号化的键名）拼接到正确位置。注意它会返回新分配的切片，与读路径的零拷贝语义不同。

Delete

func Delete(data []byte, keys ...string) []byte

接收数据结构与待删除的键路径，返回删除后的结构；键路径不存在时，整个数据结构被删除（README 原文语义，源码在路径未命中时返回 data[:0]，见 parser.go）。同样支持数组下标：jsonparser.Delete(data, "person", "avatars", "[0]", "url")，同样标注为实验性。实现上是算出待删区间的起止偏移（并处理尾随逗号），再拷贝拼接——同样会分配新切片。

错误定义

vendor 源码 parser.go 定义了完整的哨兵错误集合，可供 errors.Is 精确判断：

错误变量 含义
KeyPathNotFoundError 键路径未找到
UnknownValueTypeError 遇到无法识别的标量值
MalformedJsonError 整体 JSON 畸形
MalformedStringError 字符串找不到收尾引号
MalformedArrayError 数组找不到 ]
MalformedObjectError 对象找不到 }
MalformedValueError 数字/布尔/null 找不到结束边界
MalformedStringEscapeError 非法转义序列
OverflowIntegerError 数字超出 int64 范围
NullValueError 值是 null，无法转换为目标类型

四、实现要点：零分配是怎么做到的

键路径搜索与块跳过的配合

searchKeys（parser.go）是全部读 API 的引擎：逐字节扫描，遇到 {/} 维护深度 level，遇到字符串键时比较“当前深度第 level 个键是否等于路径的第 level 段”，命中且层级吻合才推进 keyLevel。关键优化是块跳过：当某个对象块的父键并未命中时，直接调用 blockEnd（按括号配对计数，parser.go）跳到该块末尾，而不是逐字符深入——这是“只解析你指定的键”的具体体现。

64 字节栈缓冲：短字符串免分配反转义

源码用常量 unescapeStackBufSize = 64（parser.go）声明了一个栈上数组，供 findKeyStart/searchKeys/ObjectEach 在对键名做 Unescape 时复用：长度不超过 64 字节的转义键名完全在栈上完成反转义、零堆分配，超长才退化为堆分配。Unescape 本身（escape.go）采用“拷贝未转义段 + 逐转义序列处理”的策略，且当传入缓冲区容量足够时不再分配。转义处理覆盖 RFC 7159 的两字符转义（查表法）与 \uXXXX，并且能正确合成 UTF-16 代理对（decodeUnicodeEscape，escape.go）。

自研 parseInt：只支持十进制，带溢出检测

bytes.go 中的 parseInt 注释自述比 strconv.ParseInt 快约 2 倍，原因是它只处理 JSON 必需的十进制：先处理负号，再逐字符校验并乘十累加；在 n > maxUint64/10 或加法回绕时置溢出标志，最终超 int64 边界（含 -2^63 边界特判）则返回 OverflowIntegerError。这解释了 GetInt 面对超大数字时为何得到确定性的溢出错误而非静默截断。

unsafe 与 safe 双实现

bytes_unsafe.go（默认构建）用 unsafe.Pointer 在 []byte 与 string 之间零拷贝互转；bytes_safe.go 携带 // +build appengine appenginevm 构建标签，为受限环境提供等价的纯安全实现（bytesToString 退化为 string(*b)，parseFloat 退化为 strconv.ParseFloat）。对使用者来说这层差异是透明的，但理解它有助于解释为什么 README 反复强调 “no memory allocation” 与 “unsafe” 的边界。

五、README 总结的性能设计点

README “What makes it so fast?” 列出四点，均能对应到源码：

  1. 不依赖 encoding/json、反射或 interface{}，真正的包级依赖只有 bytes——对照 parser.go 的 import 列表（bytes、errors、fmt、strconv）属实；
  2. 字节级操作，直接返回原始数据的指针，不分配内存——Get 返回 data[offset:endOffset] 子切片（parser.go）；
  3. 不做自动类型转换，默认一切皆 []byte，只告诉你 ValueType，由你按需转换（提供了 ParseInt/ParseFloat/ParseString/ParseBoolean 辅助）；
  4. 不解析完整记录，只解析你指定的键——即第四节的 searchKeys + blockEnd 块跳过机制。

六、基准测试数据（README 报告）

README 报告了三组基准：模拟小（190 字节 HTTP 日志）、中（2.4KB，基于 Clearbit API 风格）、大（24KB，基于 Discourse API 风格）三种真实载荷，指标为 time/op（纳秒，越低越好）、bytes/op 与 allocs/op。以下数据原样转录自 README（当时在 Linode 1024 机型上运行），供横向参考，不构成对当前硬件环境的承诺。

结论速览（TLDR）

README 给出的两点结论：jsonparser 比 encoding/json 快至多 10 倍（取决于载荷规模与用法），内存消耗几乎无限占优（字节级操作 + 直接切片指针）；easyjson 在中载 CPU 上表现惊人，是几乎可直接替换 encoding/json 的强候选。两者的本质区别在于：easyjson/ffjson 是完整解析器、整条记录只解析一次之后可任意多次取用；jsonparser 按需解析指定键，调用次数越多相对代价越高——README 原话：“With great power comes great responsibility!”

小载荷（190 字节，读取多个字段）

库 time/op bytes/op allocs/op
encoding/json struct 7879 880 18
encoding/json interface{} 8946 1521 38
Jeffail/gabs 10053 1649 46
bitly/go-simplejson 10128 2241 36
antonholmquist/jason 27152 7237 101
ugorji/go/codec 8806 2176 31
mreiferson/go-ujson 7008 1409 37
a8m/djson 3862 1249 30
pquerna/ffjson 3769 624 15
mailru/easyjson 2002 192 9
buger/jsonparser 1367 0 0
buger/jsonparser (EachKey API) 809 0 0

jsonparser 比 encoding/json 快至多 9.8 倍、比 ffjson 快 4.6 倍，且 bytes/op 与 allocs/op 均为 0，无出其右；EachKey 比逐个 Get 再快约一倍。

中载荷（2.4KB，读多个嵌套字段 + 1 个数组）

库 time/op bytes/op allocs/op
encoding/json struct 57749 1336 29
encoding/json interface{} 79297 10627 215
Jeffail/gabs 83807 11202 235
bitly/go-simplejson 88187 17187 220
antonholmquist/jason 94099 19013 247
ugorji/go/codec 114719 6712 152
mreiferson/go-ujson 56972 11547 270
a8m/djson 28525 10196 198
pquerna/ffjson 20298 856 20
mailru/easyjson 10512 336 12
buger/jsonparser 15955 0 0
buger/jsonparser (EachKey API) 8916 0 0

载荷增大后 ffjson 与 jsonparser 的 CPU 差距缩小，但内存差距持续扩大；基于 encoding/json + map[string]interface{} 的 gabs、go-simplejson、jason 性能与 interface{} 路径相当，README 将其排除出对比。

大载荷（24KB，读 2 个数组并逐元素取字段，近似全量处理）

库 time/op bytes/op allocs/op
encoding/json struct 748336 8272 307
encoding/json interface{} 1224271 215425 3395
a8m/djson 510082 213682 2845
pquerna/ffjson 312271 7792 298
mailru/easyjson 154186 6992 288
buger/jsonparser 85308 0 0

此时 jsonparser 胜出，因为该场景需要读取的键非常多，按需解析的代价被摊薄到全量扫描的同一趟遍历中；README 说明该组未测 EachKey，因为大量数组元素场景下 ArrayEach 更高效。

七、选型与使用建议

结合 README 的结论与 lazygit vendor 中的实际源码，可以提炼出以下使用准则：

  • 少量键、大载荷、内存受限：jsonparser 是最优解，Get/GetUnsafeString 零拷贝直取；
  • 同一条记录取多个键：优先 EachKey，把多次扫描合并为一次，全部命中后源码还会提前终止扫描；
  • 遍历数组/对象：分别用 ArrayEach/ObjectEach，两者都直接构建在 Get 之上，回调中拿到的仍是原始数据子切片；
  • 需要安全 string（跨 goroutine、跨 channel 传递）：用 GetString，接受其分配成本；仅在局部上下文内使用时才用 GetUnsafeString；
  • 修改 JSON：Set/Delete 目前是实验性功能且必然分配新切片，生产路径上使用需自行验证边界（例如删除不存在路径会清空整个结构）；
  • 完整记录只解析一次、之后反复取用：README 明确这类场景更适合 easyjson/ffjson 等全量解析器，不要误用 jsonparser 的按需解析特性。

八、相关文件索引

内容 相对路径
本库 README（本文主体文档） vendor/github.com/buger/jsonparser/README.md
核心解析实现（Get/EachKey/Set/Delete/ObjectEach 等） vendor/github.com/buger/jsonparser/parser.go
十进制整数快速解析与溢出检测 vendor/github.com/buger/jsonparser/bytes.go
转义解码与 Unicode 代理对处理 vendor/github.com/buger/jsonparser/escape.go
unsafe / App Engine 安全双实现 bytes_unsafe.go、bytes_safe.go
lazygit 依赖版本声明（v1.1.2, indirect） go.mod
库在依赖树中的真实调用方（ObjectEach 反序列化有序映射） vendor/github.com/wk8/go-ordered-map/v2/json.go

jsonparser 的价值在于把“从一段动态 JSON 里取几个字段”这件事压缩成一次字节扫描、零内存分配：它以放弃“完整解析”为代价换取了按需解析的极致效率，而 EachKey、栈缓冲反转义与块跳过这些源码细节，正是其 README 性能承诺的直接支撑。

lazygit
simple terminal UI for git commands
项目地址：https://gitcode.com/GitHub_Trending/la/lazygit
登录后查看全文

相关内容推荐

1 如何在CI/CD流水线中集成测试buger/jsonparser：提升Go应用性能的终极指南 🚀2 模糊测试基准测试实战指南：从零构建fuzzer-test-suite自定义测试用例3 lazygit 依赖解析：uax29/graphemes —— 基于 UAX 29 的 Unicode 图群边界实现4 Jibber Jabber 语言检测库解析：lazygit 国际化自动识别 UI 语言的底层机制5 深入 lazygit 依赖的 displaywidth：终端等宽显示宽度计算的 API、选项与实现原理6 3步打造模糊测试框架自定义用例：从环境搭建到测试验证全流程7 轻量级Git效率工具：零基础掌握Lazygit终端交互8 Lazygit：终端Git操作的终极效率神器9 Mergo 深入指南：Go 结构体与 Map 合并库的原理、配置与在 Lazygit 中的实际应用10 lazygit 的日志美化依赖 humanlog：结构化日志格式化器的原理与实战
热门项目推荐
相关项目推荐

热门内容推荐

1 编程实践项目探索指南：从零构建技术能力体系2 技术解构式学习：从0到1构建你的编程知识体系3 构建自己的技术世界：build-your-own-x项目的实践探索指南4 解锁编程技能的实践之旅：从零构建你的技术世界5 技术实践探索：从零开始构建核心系统的实践指南6 亲手锻造技术引擎：从0到1构建核心系统的实践指南

最新内容推荐

Ladybird 构建性能剖析：从 .ninja_log 火焰图到编译器内部 Pass 耗时的三级分析方法Astro + Svelte 实战：在 Astro 7 中集成 Svelte 5 组件的配置要点与渲染原理scrcpy 在 Linux 上的安装与运行:官方发行包、包管理器、脚本编译与运行实践Redux 基础教程实战：用中间件与 Redux Thunk 实现异步逻辑和数据获取annotated_deep_learning_paper_implementations 中的 MLP-Mixer：用序列混合 MLP 替换自注意力，训练 Masked Language ModelFlask 集成 Celery：后台任务队列的官方配置模式与实战示例Flutter android_hardware_smoke_test:参考黄金图目录与本地基线、Skia Gold 双轨管理模型Chart.js 性能优化全解：从数据解析、抽稀算法到 Web Worker 并行渲染mem0 插件 Memory Reviewer：对 AI Agent 记忆库做质量审计的完整方法论cs-self-learning 必学工具篇：用 Scoop 统一安装与管理 Windows 开发环境

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库，实现网络在NPU上加速计算。
C++
1.12 K
2.72 K
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库，实现网络在NPU上加速计算。
C++
903
1.82 K
docsdocs
暂无描述
Markdown
888
5.78 K
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件，TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件，使 PyTorch 框架能够直接调用昇腾 NPU，为开发者提供昇腾 AI 处理器的超强算力。
Python
854
1.34 K
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
527
590
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent，它能够将大语言模型的强大能力，通过你日常使用的各类通讯应用，直接延伸至你的指尖。
Python
3.51 K
1.01 K
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
1.33 K
1.45 K
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR（Multi-Level Intermediate Representation）构建的，面向昇腾亲和算子编译时使用的中间表示，提供昇腾完备表达能力，通过编译优化提升昇腾AI处理器计算效率，支持通过生态框架使能昇腾AI处理器与深度调优
C++
540
384
flutter_flutterflutter_flutter
本仓库是 Flutter SDK 与 Flutter Engine 的 OpenHarmony 适配版本，由 CPF-Flutter 团队维护。开发者可使用熟悉的 Flutter 技术栈开发 OpenHarmony 应用，3.35.7 及以后的适配版本可基于本仓库源码构建支持 OpenHarmony 的 Flutter Engine。
Dart
1.17 K
341