G6 Mobile 包体积优化
内容提要
本文讨论G6 Mobile包体积优化。初始包1.3M，gzip后330k，移动端过大。主要问题包括重复依赖（如g-base、gl-matrix）、无用模块（如@antv/g-webgpu、regl）及版本不一致。优化方案：发布g-mobile消除重复，拆分layout和tree graph为扩展包，同步依赖版本。预计核心包降至500k左右，释放约800k空间。
延伸解读
重复依赖是体积膨胀的主因
文章指出，初始包体积1.3M中，重复依赖贡献显著：g-base重复版本占80k，gl-matrix和algorithm版本不一致各占60k和10k，@antv/util重复占20k。这些重复源于开发期本地link和子包版本未同步，正式发包后部分问题可自然解决，但版本同步仍需主动处理。
按需引入是移动端优化的关键
优化方案将布局和tree graph拆为扩展包，按需引入，可释放约550k空间（layout相关520k，hierarchy 30k）。这体现了移动端包体积优化的核心思路：避免全量打包，将非核心功能模块化，用户按需加载，从而显著减小核心包体积。
优化后核心包体积预估
通过消除重复依赖、拆分扩展包和同步版本，预计核心包从1.3M降至约500k，释放约800k空间。其中g-mobile、g-base各100k，g6-mobile 50k，g6-core 150k，node_modules 100k。这一预估基于当前分析，实际效果需在发布后验证。
Q&A
G6 Mobile 初始包体积有多大？为什么移动端难以接受？
G6 Mobile 初始版本打包后 parse 大小为 1.3M，gzip 后为 330k，这个尺寸对于移动端来说过大，难以接受。
G6 Mobile 包体积大的主要原因有哪些？
主要原因包括：重复依赖（如 g-base、gl-matrix、@antv/util）、无用模块（如 @antv/g-webgpu、regl）、版本不一致（如 gl-matrix 和 algorithm）以及一些不必要的依赖（如 hierarchy、darge、inversify）。
G6 Mobile 中重复的 g-base 是如何产生的？正式发包后还会存在吗？
重复的 g-base 是因为 g-mobile 还在开发中，通过本地 link 方式引入，而 g6-mobile 本身也直接引用 g-base，同时通过 g6-core 间接引用，导致重复。正式发包后，g-mobile 会正常安装，重复问题会消失。
G6 Mobile 中 @antv/g-webgpu 相关依赖为什么是不需要的？如何优化？
@antv/g-webgpu 相关依赖（包括 @antv/g-webgpu-core、@antv/g-webgpu-engine）在移动端不需要，它们是通过 @antv/layout 内置布局引入的。优化方法是将 layout 从主包中拆出，不提供内置布局或只提供最简单的一种，将布局作为扩展包按需引入。
G6 Mobile 中 gl-matrix 版本不一致的问题是如何产生的？同步后能释放多少空间？
gl-matrix 版本不一致是因为 g-mobile 中引入了 3.0 版本的 g-math 和 @antv/matrix-util，而 g6-core 和 g6-mobile 中都是 2.0 版本。同步版本后可以释放约 60k 的空间。
G6 Mobile 包体积优化的总体方案是什么？预计优化后核心包多大？
总体方案包括：发布 g-mobile 消除重复依赖；将 layout 和 tree graph 拆分为扩展包；同步依赖版本。预计优化后核心包约 500k，包括 g-mobile 100k、g-base 100k、g6-mobile 50k、g6-core 150k、node_modules 100k。
