数据可视化数据分析桌面应用【免费下载链接】gephiGephi - The Open Graph Viz Platform项目地址https://gitcode.com/gh_mirrors/ge/gephi点击查看免费下载本文基于仓库根目录的 ARCHITECTURE.md 展开结合源码根 pom.xml、modules/下各模块深入讲解 Gephi 的层次化架构、模块化设计原则、API/SPI 机制、Lookup 服务发现模式以及 Controller–Model 协作模型。读完本文你将理解 Gephi 为什么可以只依赖非 UI 模块构建命令行工具明白一个插件本质上就是多一个模块并掌握在 Gephi 中新增扩展布局、过滤器、导入器等的标准两步流程。一、高层架构四层堆叠与核心/UI 分离Gephi 基于 Java 语言构建当前使用JDK 17根 pom.xml 中版本为0.11.4-SNAPSHOT。软件的层次结构可以用下面的示意图概括Plugins Plugins │ │ └──────────► Gephi UI ◄─┘ │ Plugin ───────► Core Gephi │ NetBeans Platform │ Java最底层是 Java为一切提供运行时基础。NetBeans Platform是 Gephi 的地基也是 NetBeans IDE 的地基因此 NetBeans API 遍布 Gephi 代码库。修改 Gephi 时熟悉 NetBeans Platform 会很有帮助。Core Gephi承载核心功能Gephi UI承载用户界面插件Plugins既可以基于核心模块也可以基于 UI 模块构建。Gephi 的扩展架构并不把插件视为一种特殊组件——插件就是另一个模块只是模块系统中的一员。核心模块与 UI 模块的分离是刻意的架构决策它使得只使用非 UI 模块就能构建命令行工具或库成为可能无需引入不必要的 UI 依赖——Gephi 的 toolkit 正是采用这种方式。二、设计原则模块化66 个模块组成的可扩展代码库Gephi 为可扩展性而设计代码库被拆分为66 个模块不含application模块本身这一数字对应根 pom.xml 中modules列表的条目数例如modules/GraphAPI、modules/ImportAPI、modules/ImportPlugin、modules/ImportPluginUI、modules/DesktopImport等。模块之间通过依赖关系相互关联API 与契约将模块彼此隔离。开发者可以定位到负责某一功能的模块在其内部工作而不必理解整个代码库。插件无非就是模块添加一个插件等效于向软件中再加入一个模块——比如在第 66 个模块旁边增加第 67 个。多线程围绕非阻塞 UI 设计Gephi 围绕非阻塞的用户界面设计长任务可以在后台执行算法运行时用户仍可继续探索图。图结构通过加锁保护保证一致性。UI 会对数据变化作出反应。例如删除一个节点同时必须删除它的关联边。如果一条线程删除节点、另一条线程仍在读取该节点的边就会出现不一致。加锁机制避免了这种情况——内存中的图结构行为类似于带一致性控制的数据库调用方可以依赖图在任何时间点保持一致。多线程设计同样延伸到 UI软件假定某个模块或插件可能在任何时刻修改图其他模块会自行对这些变化作出反应。修改图的代码无需显式刷新每个受影响的 UI 组件这些组件会自动更新——这让模块保持独立也避免并发大量变更时界面卡顿。三、技术栈一览层面技术选型运行时与平台JavaJDK 17、NetBeans Platform模块系统、可移动窗口的停靠框架、自动更新、UI 组件界面与渲染Swing用户界面、OpenGL可视化、Java2DPreview 标签页渲染构建、测试与自动化Maven、JUnit、GitHub ActionsNetBeans Platform 是开源软件拥有自己的社区也被其他桌面软件用作基础。Maven 构建的版本与依赖配置集中在根 pom.xml例如netbeans.version属性指向RELEASE290graphstore.version指向0.8.8。四、主 API 一览功能以模块对应的 API 形式暴露Gephi 的功能通过与模块对应的 API 暴露API职责Project API项目管理与工作区WorkspacesGraph API图结构与图数据访问底层数据结构实现在独立的 graphstore 仓库见下文Import API导入文件与数据库包括 File Open 工作流Layout API布局算法Filters API过滤器Statistics API社区发现、PageRank 等算法Export API导出文件Preview API渲染预览图像Appearance API对节点和边进行分区Partitioning、排名Ranking与颜色/尺寸变换Tools API与可视化关联的工具如最短路径Data Laboratory API属性操作与数据实验室功能Visualization APIOpenGL 引擎提供的功能API 之间可以互相依赖。例如 Graph API 依赖 Project API因为图与工作区相关联。依赖关系以标准 Maven 依赖形式声明在每个模块的pom.xml中新增模块依赖时只需在对应模块的 POM 中添加即可。以 modules/ImportAPI/pom.xml 为例它声明了对graph-api、project-api、utils等内部模块以及多个org.netbeans.api依赖的引用。Graph API 与独立的 graphstore 仓库核心图结构位于独立的仓库中。本仓库中的 modules/GraphAPI 只是把graphstore库通过 Maven 依赖引入见根 pom.xml 的graphstore.version属性值为0.8.8包装成 NetBeans 模块并对外暴露org.gephi.graph.api/org.gephi.graph.impl两个包。Gephi 操作的核心——图/节点/边的数据结构存储、索引、节点/边/列的实现——实现在gephi/graphstore 这个独立仓库中。任何对核心图数据结构本身的改动存储、索引、节点/边/列实现都应在那边进行而不是这里本仓库的改动应仅限于 NetBeans 集成层如GraphControllerImpl、GraphPersistenceProvider与 API 的使用方。从源码可以印证这一点modules/GraphAPI 目录下只有api/GraphController.java、GraphControllerImpl.java、GraphPersistenceProvider.java三个文件是一个瘦NetBeans 包装层。五、API 的性质纯 Java 接口 NetBeans 公共包机制Gephi 的 API 是纯 Java 接口并借助 NetBeans 模块系统的公共包public package机制实现封装一个模块在其pom.xml中把选定的包标记为 public只有这些包对其他模块可见公共包列表也可以为空。以 Import API 模块为例它包含公共 API 包org.gephi.io.importer.api、实现包org.gephi.io.importer.impl以及其他模块内部代码。API 与其实现可以共存于同一模块但只有 API 包是公开的。依赖 Import API 的模块无法访问其实现从而隐藏实现细节、把 API 作为契约固化下来也允许将来替换实现而无需让使用者依赖其内部。这一公共包机制早于 Java 9 引入的模块系统但通过 NetBeans Platform 提供了类似的封装效果。从 modules/ImportAPI/pom.xml 的nbm-maven-plugin配置可以清楚看到只有org.gephi.io.importer.api、org.gephi.io.importer.spi、org.gephi.io.processor.spi三个包被声明为publicPackage。大多数 API 已经达到以向后兼容为目标的稳定程度部分 API 在入口点和契约打磨期间会被标记为开发中under development目标是最终稳定到插件可以长期依赖的程度。主 API 通过 Javadoc 文档化。API 与 SPI 的变更记录在 src/main/javadoc/overview.html主 Javadoc 概览页它为迁移模块或插件的开发者提供变更日志新增方法等。该文件同时也是发布说明release notes的编译来源因此条目需要遵循既有格式约定——具体结构见 CONTRIBUTING.md。架构深受《Practical API Design: Confessions of a Java Framework Architect》NetBeans Platform 架构师所著一书影响该书被推荐作为 API 设计的入门读物。六、API 与 SPI谁提供功能谁被扩展SPI 意为Service Provider Interface服务提供者接口。API 与 SPI 共享实现层面的属性都是 Java 接口、都使用公共包、都以向后兼容为目标、都应清晰文档化。但二者的角色不同API 与 SPI 永不混用API向其他模块提供功能SPI供其他模块扩展插件总是扩展某个 SPI。以 Import API 模块为例其内部结构为Import API module ├── API: org.gephi.io.importer.api ├── implementation: org.gephi.io.importer.impl └── SPI: org.gephi.io.importer.spi └── Importer ├── ImporterGEXF ├── ImporterGML ├── ImporterXXX └── implementation supplied by a pluginImporter SPI 定义了导入器必须提供的操作如执行导入。核心模块和插件都可以为其实现 GEXF、GML 等格式。可用 SPI 一览SPI扩展点Import SPI文件、数据库与向导导入器Layout SPI布局算法Statistics SPI其他算法Tools SPI菜单栏中的工具Project SPI持久化提供者persistence providersExport SPI图与图形的文件导出器Filters SPI过滤器Preview SPIPreview 构建器与渲染器Generator SPI生成器类似于导入器Data Laboratory SPIManipulators操作器Appearance SPI排名与分区的变换器TransformersVisualization SPI新VisualizationEngine模块的渲染器开发中Project SPI 的持久化提供者让.gephi项目文件可扩展任何模块都可以通过实现一个持久化提供者把自己的数据写入.gephi文件。可视化引擎重构正在进行中新的VisualizationEngine模块与旧版VisualizationImpl模块并存应用当前同时依赖两者前者拥有自己的org.gephi.viz.engine.spi.RendererSPI。从源码看modules/VisualizationEngine/src/main/java/org/gephi/viz/engine/spi 下已包含Renderer.java、WorldUpdater.java、RenderingTarget.java等 SPI 接口Visualization SPI 的功能会随迁移推进持续扩充。可用的 SPI 集合决定了可以创建的插件种类只要实现了一个 SPI插件就存在了。七、Lookup贯穿代码库的核心服务发现机制Lookup 是 Gephi 架构中最重要的 NetBeans Platform 工具。它贯穿整个代码库支撑着 API/实现分离与 SPI/实现分离。1. 查找单例服务控制器无需直接访问其实现即可获取ProjectController pc Lookup.getDefault().lookup(ProjectController.class);例如需要创建、保存或以其他方式操作项目的代码通过 Lookup 获取ProjectController服务。这类似于依赖注入服务是单例的通过 Lookup 获取它保持了公共 API 与其实现之间的分离。这一模式在源码中随处可见例如 modules/GraphAPI/src/main/java/org/gephi/graph/GraphControllerImpl.java 内部正是通过Lookup.getDefault().lookup(ProjectController.class).getCurrentWorkspace()取得当前工作区来定位GraphModel的。搜索仓库可以发现Lookup.getDefault().lookup(...)在 Data Laboratory、Appearance、DBDrivers 等大量模块中反复出现。2. 查找某个 SPI 的所有实现Lookup 可以返回某个 SPI 的全部可用实现for (Renderer renderer : Lookup.getDefault().lookupAll(Renderer.class)) { }返回的集合可以包含来自核心模块和插件的实现。只要实现被加入运行时 classpath就会被包含进来调用方无需知道它们的包名。这一机制支撑了界面中的扩展列表与树例如布局选择器通过lookupAll发现每一个布局算法导出器、渲染器、过滤器等其他扩展列表也使用相同模式。3. 注册一个实现SPI 实现必须用服务提供者注解注册ServiceProvider(service Renderer.class) public class NodeRenderer implements Renderer { }该注解声明这个类提供了RendererSPI 的一个实现。Lookup 会在 classpath 中搜索这些注册。只实现接口而不加注解lookupAll就不会发现该实现。源码印证例如 modules/AppearanceAPI/src/main/java/org/gephi/appearance/AppearanceControllerImpl.java 使用ServiceProvider(service AppearanceController.class)注册控制器modules/ImportPlugin/src/main/java/org/gephi/io/importer/plugin/file/ImporterBuilderGEXF.java 等文件则用ServiceProvider(service FileImporterBuilder.class)注册各格式的导入器。因此新增一个布局、过滤器、渲染器或其他扩展的步骤是实现相关的 SPI加上服务提供者注解。八、API 方向与兼容性架构力图保持以下性质每个功能都有干净、稳定、有文档的 API开发者无需深入阅读实现就能通过 Javadoc 发现扩展点实现可以在 API 不变或基本不变的前提下被替换新功能可以通过插件加入核心功能可以被命令行工具在没有 UI 模块的情况下使用模块可以在其他项目中复用Gephi 模块发布在 Maven Central 上可以被单独选用——例如只使用图结构或在另一个库、云端应用或第三方应用中使用图与布局模块核心模块与 UI 模块保持分离即使某个功能需要用户输入和 UI 组件。Gephi 曾在保持 API 不变或仅做最小改动的前提下多次从内部重写模块——这依然是架构目标。NetBeans Platform 还允许替换默认实现插件可以提供新的实现例如替代的ProjectController并赋予更高优先级使 Lookup 选择它而不是默认实现。这种做法在实践中不常见但它证明了平台同时支持替换与扩展功能。语义化版本Semantic VersioningGephi 用语义化版本传达 API 变化Patch0.11.xAPI 变更最小可能新增一个方法但其他改动受限。Minor0.x.xAPI 新增必要时会有兼容性破坏尤其针对标记为开发中的 API。Majorx.x.xAPI 可能从头重写、发生重大变化例如1.0与2.0之间。九、模块解剖Maven 风格的标准结构所有模块遵循 Maven 风格结构ModuleName/ ├── src/ │ ├── main/ │ │ ├── java/ # 源码 │ │ ├── nbm/ │ │ └── resources/ # Bundles、本地化文件、其他文件、图标与图片 │ └── test/ │ └── java/ # 测试源码 └── pom.xml # 依赖、公共包与额外配置模块的pom.xml尤其重要它包含依赖、公共包等配置。创建新的 Gephi 模块时就会生成这种 Maven 约定的结构。仓库中每个模块都符合该布局例如 modules/ImportPlugin 的src/main/java、src/main/nbm/manifest.mf、src/test/java与pom.xml。十、模块与包命名约定四角色命名模式大多数模块遵循四种命名角色。以 import 为例模块模式角色66 个模块中的数量ImportAPI定义 API 与 SPI并实现 API17ImportPluginSPI 实现11ImportPluginUI仅 UI 的 SPI 实现6DesktopImport其余 UI 代码17合计 66 个模块中有51 个遵循此约定。API 模块包含 API、其 SPI 以及 API 实现。有一两个例外例如 Filters 的实现仍位于独立的 filters implementation 模块中但意图是把 API 与实现都放进 API 模块。插件模块包含 SPI 实现。对于 importGEXF 导入器等实现就在这里。API 模块与插件模块是核心 Gephi 模块不含任何 UI 代码——它们正是命令行应用导入 Gephi 支持的文件格式所需的模块。插件 UI 模块某些 SPI 包含 UI 组件。例如导入/导出实现可能需要一个让用户配置的面板这些 SPI 的 UI 实现放在插件 UI 模块中以保证核心与 UI 模块分离。大多数图格式导入时不需要配置面板但表格Spreadsheet导入是例外它使用完整的 CSV 导入向导、需要内容检测并要求实现 Importer UI SPI 的 Swing UI 代码这部分代码就属于 import 插件 UI 模块。桌面模块包含其余 UI 代码。例如导入后显示的报告面板展示节点数、错误数与警告数属于 desktop import 模块。同样的约定横跨各个领域例如Layout API 与 Layout PluginPreview API 与 Preview PluginStatistics API、Statistics Plugin、Statistics Plugin UI 与 Desktop Statistics。不遵循四角色约定的模块覆盖其他功能例如欢迎界面WelcomeScreen和版本间设置迁移SettingsUpgrader。包名约定角色包名约定APIorg.gephi.NAME.apiAPI 实现org.gephi.NAMESPIorg.gephi.NAME.spiSPI 实现org.gephi.NAME.pluginSPI 实现仅 UIorg.gephi.ui.NAME.pluginUIorg.gephi.desktop.NAME创建模块或修改实现时应遵循这些约定以保持代码库组织有序。十一、控制器与模型简化的 Model–Controller 模式Gephi 使用简化的 Model–Controller 模式而非完整的 MVC——架构上没有 View 组件。控制器Controllers控制器包括ProjectController、ImportController、GraphController等。控制器是通过 Lookup 找到的单例服务它是交互与执行模块功能的入口它是任何模型变更的入口包含 setter它负责获取模型。从源码看modules/GraphAPI/src/main/java/org/gephi/graph/api/GraphController.java 接口本身注释就写着This controller is a service and can therefore be found in Lookup并给出了Lookup.getDefault().lookup(GraphController.class)的用法示例其实现类则通过ServiceProvider注册并被 Lookup 发现。模型Models模型包含所有状态与数据暴露 getter每个工作区有一份各类模型中的一份模型是持久化提供者的数据来源。一个项目可以包含多个相互独立的工作区。每个工作区都有自己的 Layout Model、Filter Model 等模型。在工作区 1 中设置的配置切换到工作区 2 时不会带入切换回来时工作区 1 的配置会恢复。Project ├── Workspace 1 │ ├── Layout Model │ ├── Filter Model │ └── ... └── Workspace 2 ├── Layout Model ├── Filter Model └── ...模型还提供了序列化进.gephi项目文件的状态。保存时Gephi 发现所有持久化提供者实现例如布局持久化提供者会把布局状态写入文件并在读取文件时恢复它。总结模型提供 getter包含数据控制器提供 setter变更状态与数据当前架构模式中没有 View。十二、仓库结构仓库组织如下.github/ └── workflows/ # GitHub Actions 工作流 modules/ ├── application/ # Gephi application 模块最后构建依赖所有其他模块 └── ... # 其他 66 个模块的源码 src/ # 额外文件包括 macOS 启动器 pom.xml # 包含共享配置的父 POMApplication 模块application模块与其他模块不同。按 NetBeans Platform 的术语仓库同时包含模块与应用Gephi 有一个 application 模块即 Gephi 应用本身它依赖所有其他模块并在最后构建。该模块modules/application主要包含配置而非代码包括品牌启动画面配置、版本、安装程序相关配置如src/main/app-resources下的图标、安装脚本等。另一个只使用 Gephi 模块子集的应用会使用一个只包含那些依赖的独立 application 模块。根文件根src目录src包含 macOS 启动器等额外文件日常开发一般不会涉及。根 pom.xml 是多模块 Maven 仓库的父 POM共享配置依赖版本、构建配置等尽量集中在这里每个模块都将此 POM 声明为父 POM 并继承其配置。模块专属配置可以放在模块自己的 POM 中但这并不常见。延伸阅读建议若想动手实践可参考仓库的 CONTRIBUTING.md模块开发与 API 变更记录约定与 README.md构建与运行方式。API 变更日志以 src/main/javadoc/overview.html 为权威来源迁移插件或模块时可先查阅它。理解模块命名四角色后浏览 modules 目录时会事半功倍*API是契约、*Plugin是核心实现、*PluginUI是 UI 实现、Desktop*是桌面端剩余 UI 代码。赞分享数据可视化数据分析桌面应用【免费下载链接】gephiGephi - The Open Graph Viz Platform项目地址https://gitcode.com/gh_mirrors/ge/gephi点击查看免费下载相关推荐Gephi模块化架构深度解析从API设计到插件系统的完整指南Gephi模块化架构深度解析从API设计到插件系统的完整指南 Gephi作为开源的图可视化平台其强大的模块化架构设计是其成功的关键因素。通过精心设计的API数据可视化数据分析桌面应用UI-TARS桌面应用让电脑拥有视觉智能的AI助手指南UI TARS桌面应用让电脑拥有视觉智能的AI助手指南 你是否厌倦了重复点击鼠标、手动操作各种软件想不想让你的电脑真正理解你在说什么然后自动帮你完成任务人工智能大模型AI Agent桌面应用GUI 自动化浏览器控制MCP 服务MCP Clients如何快速部署Qwen2.5-7B-Instruct到AMD NPU5步完整教程如何快速部署Qwen2.5 7B Instruct到AMD NPU5步完整教程 Qwen2.5 7B Instruct_rai_1.7.1_npu_16K是一上一篇喜马拉雅音频本地化收藏全攻略掌握离线收听新技能下一篇终极AI图像增强工具使用完整指南智能画质修复与高清放大创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考