分类：科技 标签：客户端开发、AI时代、技术选型、跨端开发

在 AI 深度赋能代码编写的今天，客户端开发的技术边界正在被重新定义。如何在一贯的“不可能三角”——研发效率、体验与性能之间找到平衡？又该如何在多端开发中巧妙借力 AI 与多语言特性？本文将结合实际项目的多端落地经验，探讨 AI 时代下的客户端选型思考与架构实践。

一、 Web、跨端还是原生：无法避开的不可能三角

做客户端开发多年，我们常在三条技术路径中权衡：

  1. Web 技术栈：开发最直观，塞进浏览器或套个 WebView 就能跑。优点是效率极高，缺点是性能与底层调用受限。
  2. 跨端开发：包括主打移动端一码多端的 React Native、Flutter，以及桌面端的 Electron、Tauri 等。它取了研发效率与性能的折中，但往往也容易陷入两头不讨好的尴尬境地。
  3. 原生开发：如 Swift + SwiftUI、Kotlin + Jetpack Compose 以及 C# + WinUI 3。前期投入大、学习成本高，但能带来极致的性能和深度调用系统底层能力的用户体验。

在 AI 介入之前，原生开发常常因为人力和时间成本被大打折扣。但现在，随着 AI 能够高效辅助双端原生代码的编写，“研发效率”这一短板被大幅补齐，原生开发的综合性价比正在重新回归。

二、 Windows 版实战：为什么选择 C# 与 WinUI 3？

在开发跨平台软件时，为了追求极致体验，Mac 端坚持使用了原生的 Swift + SwiftUI，而 Windows 端则选择了 C# 加 WinUI 3（跑在 .NET 10 上）。

1. 架构设计与多端对齐

为了提高效率，开发者往往希望最大化代码复用。但经过 AI 分析发现，不同操作系统的底层路径规则与系统框架差异巨大，盲目复用只会适得其反。因此，更好的做法是底层逻辑各写各的，通过设计 Token、多语言文件与严格的同步机制保持外观和交互高度一致。

例如，在 Windows 应用的架构设计上可以分为四层：

  • Core 层：只依赖 .NET，不碰 Windows 接口，处理核心逻辑与规则。
  • Platform 层：封装注册表、文件系统等真正的系统接口（通过 EnableWindowsTargeting 让其在 Mac 上也能编译）。
  • ViewModel 层：处理界面状态，与 Mac 版本一一对应。
  • WinUI 界面层：负责最上层的界面渲染与编译。

通过这种巧妙的架构分层，绝大部分代码和测试都可以在习惯的 Mac 环境中完成，真正做到“代码在 Mac 上写，验证在虚拟机与真机上跑”。

2. 证书与分发的痛点

相比 macOS，Windows 的证书签名机制繁琐不少。从私钥必须存放在硬件或云端 HSM，到 SmartScreen 信誉机制的漫长积累，整个分发流程需要花费大量精力去适配与调试。

三、 多语言混搭：用特性互补打破技术壁垒

在一个成熟的客户端应用中，没有必要局限于单一语言。通过跨语言通信与中间层，我们可以完美融合不同生态的优势：

  • Swift 与 JS 结合：在开发 Markdown 笔记应用时，通过 JavaScriptCore 在 Swift 中调用 JS 的文本处理能力，极大地简化了复杂格式化引擎的实现。
  • Rust 与 Web 结合：在打包工具 Pake 中，通过 Rust 调用 JS 动态生成 UI 组件，兼顾了性能与视觉美观。
  • C、JS 与 Swift 协同：在实现分栏同步滚动时，底层利用高性能的 C 语言库解析，再通过消息通道与 WebView 实时交互。

这种“各取所长”的混搭能力，在前 AI 时代需要极高的心智负担，而现在，开发者可以更加专注于场景本身，选择最合适的工具。

四、 总结：技术服务于业务

技术选型与 AI 辅助说到底只是锦上添花。正如抢演唱会门票一样，用户永远只关心核心需求有没有被满足。

随着 AI 的进一步演进，纯粹的编码本身或许会逐渐退居其次，但架构设计、规则抽象以及对真实场景的测试验证，依然是工程师无可替代的核心价值。AI 时代的客户端开发，正在向着更高效、更纯粹的体验回归。