分类：科技 标签：客户端开发、AI辅助编程、跨端技术、架构设计

在客户端开发领域，开发者们常常会面临一个经典的“不可能三角”：研发效率、体验与性能。随着人工智能的深度介入，这一平衡正在被悄然打破。本文将结合实际项目的开发经验，探讨在 AI 时代下，如何重新审视多端技术选型、原生与跨端的取舍，以及多语言混用带来的架构巧思。

Web、跨端还是原生：经典三选一的现状

回顾客户端发展的历史，主流技术路径大致可以归纳为三条：

  1. Web 技术栈：直接编写网页并通过壳子封装。如早期的 PhoneGap，或是桌面端的 Electron。它的最大优势是研发效率高、多端一致性好，但代价是安装包庞大、内存占用高。
  2. 跨端开发栈：包括早期的 React Native、Weex，以及后来的 Flutter、基于 Rust 的 Tauri 和 Go 的 Wails。这类技术旨在折中效率与性能，实现一份代码多端运行。
  3. 原生开发栈：如 Swift + SwiftUI、Kotlin + Jetpack Compose 以及 C# + WinUI 3。前期学习投入大、生态依赖官方推动，但它能带来极致的性能与系统深度集成体验。

在 AI 出现之前，由于原生开发成本高昂，国内市场大面积倾向于跨端方案。然而，当 AI 能够高效辅助编写代码后，原生开发的门槛被大幅拉低——一个人编写多套原生的成本不再遥不可及。

为什么 Windows 版依然选择 C# 与 WinUI 3

在打造跨平台软件的体验时，不将就的原则往往促使开发者走向原生。以开发一款多端同步的清理工具为例，Mac 端采用了 Swift + SwiftUI，而 Windows 端则选择了原生的 C# 与 WinUI 3（运行于 .NET 10）。

  • 拥抱现代系统风格：相较于陈旧的 WPF 或被沙盒绑定的 UWP，WinUI 3 作为 Windows App SDK 的一部分，不仅原生支持 Windows 11 的 Fluent 风格，在高分屏缩放和 ARM64 架构上也表现优异。
  • 分层架构设计：为了实现 Windows 与 Mac 端核心逻辑的高效复用，项目采用了清晰的四层架构：
    • Core 层：只依赖 .NET，处理清理规则与路径安全，不碰任何系统接口，甚至能在内存文件系统中进行跨平台测试。
    • Platform 层：封装注册表、文件系统等真正的系统接口。
    • ViewModel 层：处理界面状态，与 Mac 版本一一对应。
    • WinUI 界面层：负责具体的原生视觉呈现。

通过这种架构，大部分编译与测试工作可以在 Mac 上的虚拟机中高效完成，真正需要真机验证的系统特性则交由实体设备回归。

语言无界：如何在一个应用里混用多种语言

优秀的软件开发往往不拘泥于单一语言。通过构建良好的通信中间层，开发者可以跨越语言边界，充分吸收不同生态的特长：

  • Swift 与 JS 融合：在早期的 Markdown 笔记应用“妙言”中，利用 JavaScriptCore 在 Swift 中直接运行 JS 的 Markdown 格式化能力，省去了手写复杂解析引擎的繁琐。
  • Rust 与 Web 协同：在打包工具 Pake 中，通过 Rust 调用 JS 渲染出轻量美观的 Toast 提示组件，兼顾了底层性能与前端灵活性。
  • 多语言协同滚动与终端增强：通过消息通道，让底层的 C 语言库、JS 预览层与 Swift 编辑区无缝联动；或利用终端转义序列，让 Lua、Rust 与 zsh 协同，实现自然语言到命令行指令的优雅转换。

这些实践表明，把各种语言当作纯粹的工具，根据场景选择最合适的解法，往往能碰撞出极具创意的技术火花。

结语

技术永远是为业务服务的。无论客户端架构写得多么优雅、选型多么前沿，最终的核心依然是解决用户的真实需求。

在 AI 辅助编程普及的今天，工程师的核心价值正从“手写每一行代码”向“架构设计与测试验证”转变。面对未来，保持开放与乐观的心态去探索更多未知，或许正是数字创作最迷人的地方。