移动端 EDA 应用架构决策文档
文档版本: v1.0
创建日期: 2026-03-07
作者: 移动端架构师
状态: 待评审
📋 执行摘要
推荐方案: Flutter + 原生插件混合架构
核心理由:
- ✅ 性能满足 1000+ 元件流畅渲染需求（Skia 引擎 + 自定义 RenderObject）
- ✅ 跨平台开发效率高（单代码库，iOS+Android 同时支持）
- ✅ 手势交互支持完善（GestureDetector + 自定义手势识别）
- ✅ EDA 核心算法可原生实现，通过 FFI/Platform Channel 集成
🎯 技术选型对比分析
评估维度权重
| 维度 |
权重 |
说明 |
| 性能（大电路渲染） |
40% |
1000+ 元件流畅编辑是核心需求 |
| 开发效率 |
25% |
影响迭代速度和人力成本 |
| EDA 库兼容性 |
20% |
现有算法库的集成难度 |
| 手势交互 |
15% |
双指缩放、拖拽、长按菜单 |
方案一：Flutter（推荐 ⭐）
优势
| 维度 |
评分 |
详细说明 |
| 性能 |
9/10 |
Skia 图形引擎直接渲染，支持自定义 RenderObject，可轻松处理 1000+ 图形元素。60fps 渲染有保障 |
| 开发效率 |
9/10 |
单代码库，热重载 (Hot Reload) 极大提升开发体验。UI 组件丰富 |
| EDA 兼容性 |
8/10 |
通过 FFI 可调用 C/C++ 算法库，Platform Channel 可集成现有 Java/Swift 代码 |
| 手势交互 |
9/10 |
GestureDetector 内置支持缩放、旋转、拖拽。可自定义手势识别器 |
劣势
- Dart 语言学习曲线（团队需适应）
- 部分原生功能需写 Platform Channel
- 包体积相对较大（约 20-30MB 起步）
关键技术方案
// 原理图渲染核心架构
class SchematicCanvas extends CustomPainter {
// 使用 Skia 直接绘制，性能最优
@override
void paint(Canvas canvas, Size size) {
// 批量绘制 1000+ 元件
for (var component in components) {
component.draw(canvas);
}
}
}
// 手势处理
class SchematicGestureDetector extends StatefulWidget {
// 支持双指缩放、拖拽、长按
// 使用 GestureScaleDetector + GestureDetector 组合
}
性能预估
- 1000 元件场景: 55-60 fps（Release 模式）
- 5000 元件场景: 40-50 fps（需优化）
- 内存占用: ~150-200MB（中等复杂度电路）
方案二：React Native
优势
| 维度 |
评分 |
详细说明 |
| 性能 |
6/10 |
JavaScript 桥接有性能损耗。复杂图形需依赖 react-native-skia 或原生模块 |
| 开发效率 |
9/10 |
JavaScript/TypeScript 生态成熟，团队上手快 |
| EDA 兼容性 |
7/10 |
原生模块集成较成熟，但 C++ 库需额外封装 |
| 手势交互 |
8/10 |
react-native-gesture-handler 库支持完善 |
劣势
- 性能瓶颈: JS 桥接在高频渲染场景（如实时拖拽）有明显延迟
- 复杂图形: 需要 react-native-skia 等第三方库，增加依赖风险
- 调试复杂度: 性能问题定位困难（JS + 原生双层）
性能预估
- 1000 元件场景: 40-50 fps（优化后）
- 5000 元件场景: 25-35 fps（可能出现卡顿）
方案三：原生开发（Swift + Kotlin）
优势
| 维度 |
评分 |
详细说明 |
| 性能 |
10/10 |
直接使用 Metal (iOS) / Vulkan (Android)，性能最优 |
| 开发效率 |
5/10 |
两套代码库，人力成本翻倍。UI 组件需分别实现 |
| EDA 兼容性 |
10/10 |
可直接集成 C/C++ 库，无中间层损耗 |
| 手势交互 |
10/10 |
原生手势识别器，响应最快 |
劣势
- 开发成本: 需要两支团队（iOS + Android），成本增加 80-100%
- 维护成本: 功能需实现两次，bug 修复也需两次
- 迭代速度: 新功能上线周期长
性能预估
- 1000 元件场景: 60 fps（稳定）
- 5000 元件场景: 50-55 fps（最优）
📊 综合评分
| 方案 |
性能 (40%) |
效率 (25%) |
兼容性 (20%) |
手势 (15%) |
总分 |
| Flutter |
9×0.4=3.6 |
9×0.25=2.25 |
8×0.2=1.6 |
9×0.15=1.35 |
8.8 ⭐ |
| React Native |
6×0.4=2.4 |
9×0.25=2.25 |
7×0.2=1.4 |
8×0.15=1.2 |
7.25 |
| 原生开发 |
10×0.4=4.0 |
5×0.25=1.25 |
10×0.2=2.0 |
10×0.15=1.5 |
8.75 |
🏗️ 推荐架构设计
整体架构
┌─────────────────────────────────────────────────────────┐
│ Flutter UI Layer │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ 原理图编辑器 │ │ 元件库管理 │ │ 项目管理模块 │ │
│ └─────────────┘ └─────────────┘ └─────────────────┘ │
├─────────────────────────────────────────────────────────┤
│ Flutter Engine (Skia Rendering) │
├─────────────────────────────────────────────────────────┤
│ Platform Channel / FFI Bridge │
├─────────────────────────────────────────────────────────┤
│ Native Layer │
│ ┌─────────────────────┐ ┌──────────────────────┐ │
│ │ C++ EDA 核心库 │ │ 原生功能插件 │ │
│ │ (电路规则检查/网表) │ │ (文件/相机/分享) │ │
│ └─────────────────────┘ └──────────────────────┘ │
└─────────────────────────────────────────────────────────┘
核心模块划分
| 模块 |
技术选型 |
说明 |
| UI 渲染层 |
Flutter CustomPainter |
原理图绘制、元件渲染 |
| 手势处理 |
Flutter GestureDetector |
缩放、拖拽、长按菜单 |
| 状态管理 |
Riverpod / Bloc |
应用状态管理 |
| 本地存储 |
Hive / Isar |
离线项目存储 |
| EDA 核心算法 |
C++ (通过 FFI) |
DRC、网表生成、ERC |
| 文件操作 |
Platform Channel |
导入导出、云同步 |
⚠️ 风险评估
| 风险 |
等级 |
缓解措施 |
| Flutter 性能不达预期 |
中 |
提前做 POC 验证 1000+ 元件场景 |
| C++ 库集成复杂度 |
中 |
预留 2 周集成时间，分阶段验证 |
| 团队 Dart 学习成本 |
低 |
安排 1 周培训 + 代码规范文档 |
| 手势冲突处理 |
低 |
使用 GestureArena 统一管理 |
📅 实施计划（Week 1-2）
Week 1: 技术验证
Week 2: 项目脚手架
✅ 决策结论
选择 Flutter 作为主要技术栈，理由：
- 性能足够: Skia 引擎可满足 1000+ 元件流畅渲染
- 成本最优: 单代码库，开发效率是原生的 2 倍
- 风险可控: 技术成熟，社区活跃，问题可解决
- 扩展性好: 后续可平滑升级到 Flutter 3.x+
下一步: 开始搭建项目脚手架（任务 2）
📎 附录
参考资源
评审记录
