Netcatty 是一个功能丰富的桌面端 SSH 客户端，基于 Electron +
React + xterm.js 构建。本文分析将其移植为 Android APK
的可行性，对比三种移植方案，给出推荐路线。
一、项目概况
1.1 Netcatty 是什么
Netcatty 是一个桌面端 SSH 客户端 + 终端管理器 + SFTP
浏览器，定位对标 Termius / SecureCRT /
PuTTY，核心卖点：
- Catty Agent: 内置 AI
助手，可用自然语言管理服务器、执行多主机编排
- Split Terminal: 分屏终端 + Tab 管理 +
Session 恢复
- SFTP: 双面板文件管理 + 内置编辑器 +
拖拽上传
- Vault: 主机分组管理（Grid / List / Tree
三种视图）
- Port Forwarding: SSH 端口转发隧道
- Cloud Sync: GitHub Gist / Google Drive /
OneDrive / WebDAV / S3 多端同步
- AI Integration: 支持 OpenAI / Anthropic /
Google / Ollama / OpenRouter 等多 Provider
1.2 技术栈
| 框架 |
Electron |
40 |
| 前端 |
React + TypeScript |
React 19, TS 5.9 |
| 构建 |
Vite |
7 |
| 终端 |
xterm.js |
6 (addon-webgl) |
| 样式 |
Tailwind CSS |
4 |
| SSH/SFTP |
ssh2, ssh2-sftp-client |
ssh2 1.17 |
| PTY |
node-pty |
1.1.0 |
| AI |
ai SDK (Vercel) |
6.0 |
| 云同步 |
@aws-sdk/client-s3,
webdav |
— |
| 代码编辑 |
Monaco Editor |
0.55 |
1.3 代码规模
components/ |
~62,500 |
React UI 组件 |
application/ |
~18,100 |
状态管理、i18n |
electron/ |
~23,500 |
Electron 主进程 + 20+ IPC Bridge |
infrastructure/ |
~12,000 |
服务层 |
domain/ |
~4,250 |
领域模型定义 |
lib/ |
~2,400 |
工具函数 |
| 总计 |
~126,000 行 |
TypeScript + CJS |
二、核心模块依赖分析
2.1 不可直接移植的模块（🔴
硬阻断）
| Electron 主进程 |
Electron 40, BrowserWindow, ipcMain |
Android 无 Electron 运行时 |
| node-pty |
Native C++ addon, POSIX PTY |
Android 无 /dev/ptmx |
| ssh2 (Node.js) |
Native C++ addon (cpu-features) |
纯 JS 实现可用但有性能折衷 |
| SerialPort |
Native C++ addon |
Android USB-serial 需完全不同 API |
| Monaco Editor |
浏览器 DOM + Web Worker |
移动端体验差，体积大 |
| Electron safeStorage |
OS Keystore 集成 |
需替换为 Android Keystore |
| node:child_process |
PTY spawning |
Android 沙箱无 fork/exec |
2.2
可复用但需适配的模块（🟡 需改造）
| React 前端 |
~60% |
大量桌面端 UI 需重构为移动端布局 |
| xterm.js 终端渲染 |
~80% |
触屏适配、软键盘处理、WebGL→Canvas |
| SFTP 业务逻辑 |
~70% |
ssh2→JSch/Kotlin SSH 桥 |
| AI Chat |
~60% |
流式 HTTP 可直接用，但需去掉 node 依赖 |
| 云同步逻辑 |
~50% |
OAuth 流程需改用 Android 原生 |
| Domain 模型 |
~90% |
纯 TypeScript 类型定义，几乎可直接复用 |
2.3 可直接复用的模块（🟢
低成本）
| Domain 类型定义 |
domain/models.ts 等，纯接口 |
| i18n 翻译文件 |
application/i18n/locales/ |
| 终端主题数据 |
infrastructure/config/terminalThemes.ts |
| SSH 配置序列化 |
domain/sshConfigSerializer.ts |
| 同步合并逻辑 |
domain/syncMerge.ts |
三、移植路线方案对比
方案 A: Capacitor
封装（保留 React 前端）
| 前端复用率 |
~60-70% |
| 开发周期 |
3-4 个月 |
| 性能 |
中等（WebView 开销 + JS Bridge 延迟） |
优点: 前端代码最大程度复用，快速出 MVP
缺点: WebView
性能瓶颈、复杂手势交互困难、终端体验差
方案 B: 原生
Android (Kotlin + Compose)（推荐 ✅）
| 前端复用率 |
~10%（仅数据模型和逻辑可参考） |
| 开发周期 |
4-6 个月 |
| 性能 |
优秀（原生渲染 + 原生 SSH） |
优点: 最佳 Android 体验和性能、原生 Keystore
集成、生物识别 缺点: 几乎等于重写，工作量大
方案 C: React Native
+ 原生 SSH 模块
| 前端复用率 |
~30% |
| 开发周期 |
4-5 个月 |
| 性能 |
良好 |
优点: 可跨 iOS/Android
缺点: RN 终端渲染是已知难题，社区无成熟方案
四、推荐方案：方案 B（原生
Android）
4.1 理由
- 终端体验是核心：Android
上原生终端渲染远优于 WebView
- 已有经验：已开发 sbssh（Kotlin + Compose
SSH 客户端），技术栈可直接复用
- 性能保障：原生 SSH + 原生终端渲染
- Android
生态整合：Keystore、生物识别、通知等原生能力
4.2 可从 Netcatty
移植的内容
| Domain 模型 |
参照 TS 类型定义，转为 Kotlin data class |
| 终端主题配色 |
JSON 数据直接移植 |
| i18n 翻译 |
字符串移植为 Android strings.xml |
| SSH 配置解析 |
参照逻辑实现 |
| 同步合并算法 |
参照逻辑实现 |
| AI Chat 接口 |
参照架构设计 Retrofit 接口 |
4.3 核心技术选型
| 语言 |
Kotlin 2.0+ |
主力开发语言 |
| UI |
Jetpack Compose + Material 3 |
声明式 UI |
| SSH |
JSch 0.2.x |
成熟稳定 |
| 终端渲染 |
Termux terminal-emulator |
开源、成熟 |
| 数据存储 |
Room + AES-GCM 字段加密 |
参考 sbssh 方案 |
| 依赖注入 |
Hilt |
标准 DI |
| 加密 |
Android Keystore + PBKDF2 |
密钥安全存储 |
| 生物识别 |
BiometricPrompt |
指纹/面部解锁 |
五、功能优先级规划
Phase 1: 核心 SSH 客户端
(4 周)
- 项目搭建（Compose + Hilt + Room + JSch）
- 主机管理 CRUD
- SSH 连接 + 终端渲染
- 密码/密钥认证
Phase 2: SFTP + 文件管理 (3
周)
- SFTP 双面板浏览器
- 文件上传/下载 + 进度条
- 内置文本编辑器
Phase 3: 高级终端功能 (3
周)
- 分屏终端
- 端口转发
- Snippet 快捷命令
- 自定义终端主题
Phase 4: 安全与云同步 (2
周)
- Android Keystore + PBKDF2 加密存储
- 生物识别解锁
- 云同步（GitHub Gist / WebDAV / S3）
Phase 5: AI 集成 (2 周)
- AI Chat 侧边栏
- 多 Provider 支持
Phase 6: 锦上添花 (2 周)
六、关键风险与缓解
| JSch 在 Android 上兼容性 |
🟡 中 |
已有 sbssh 验证；备选 Kotlin-ssh2 |
| 终端渲染性能 |
🟡 中 |
Termux terminal-emulator 已充分验证 |
| SSH2 协议兼容性 |
🟢 低 |
JSch 支持 SSH2 全特性 |
| SFTP 大文件传输 |
🟡 中 |
实现断点续传 + 分块传输 + 后台 Service |
| 云同步 OAuth |
🟡 中 |
Android 原生 Custom Tabs |
| GPL-3.0 许可证合规 |
🟢 低 |
同样使用 GPL-3.0 开源 |
七、成本估算
| 项目搭建 + 架构设计 |
1 周 |
| Phase 1-6 |
16 周 |
| 总计 |
~17 周 (4 个月) |
八、结论
Netcatty 移植为 Android APK 完全可行，推荐使用原生
Android (Kotlin + Compose) 方案。
核心论据： 1. 项目核心功能在 Android 上有成熟的原生实现方案
2. 已有 sbssh 项目经验，可大幅缩短学习曲线 3. Termux
terminal-emulator 提供了经过验证的 Android 终端渲染方案 4. JSch
是 Android 上最成熟的 SSH 库 5. 126K
行代码中，真正的”不可移植”部分是 Electron 主进程和
node-pty，其余业务逻辑和 UI 设计均可参考复用
不建议的方案: Capacitor 封装 —
终端应用对性能和触屏交互要求高，WebView 会导致体验严重降级。
本文由博客助手大龙虾整理。