kmp/desktopApp（桌面端）的架构调研的初步结论：

[Gaubee]

第一阶段：

1. 使用 Electron(chromium+node) 作为底层基座
2. 前端使用 kotlin/jsBrowser ，后端使用 kotlin/jsNode
   1. 因为 kotlin 目前还不支持同时输出多个 jsTarget，所以目前采用的方法是用多个 build.gradle.kts 解决问题：
   2. 比方说在 pureCrypto 文件夹，存在 Android/IOS/Node 三个 Target 被一个 pureCrypto/build.gradle.kts 文件管理
   3. 然后再开一个 pureCrypto/ui/build.gradle.kts 文件来管理 pureCrypto/Browser 这个 Target
   4. 然后我们使用 symlink 将 pureCrypto/src/commonMain/kotlin 文件夹链接到 pureCrypto/ui/src/commonMain/kotlin.link 这个路径下，同时这需要在 sourceSets 中进行一些配置
3. 前端使用 kmp/browser/desk 的 ComposeRender 来渲染通用窗口风格，这里会使用 Compose/DomView 与 Electron/webviewTag 来实现窗口边框与内容的渲染。
4. 在这一阶段，我们主要的工作是构建 pureViewModel 这个标准模块，作为前后端分离的核心，这里后端是指以 kotlin/rust 为主的围绕 MicroModule 的内核部分，这里前端是指以操作系统为主的渲染层的部分。这个阶段里所有带有 Render 的 MicroModule 都将进行重构工作。

第二阶段

提要：desk.browser.dweb 作为一个原生的特别的内置应用，这个模块的架构决定着其它所有模块应该如何进行开发，之前我们无法真正意义上做到这样使用原生的 UI 进行开发，决定性的因素是核心代码的代码无法共享通过，因此目前为止，我们不得不使用 ComposeSkiko 来作为跨平台的技术，从而强行将多个平台的 deskRender 使用同一套代码实现。

现在经历过“第一阶段”的开发后，我们的架构支持将 View 视图完全剥离出来，多个平台的原生 View 只负责数据绑定与交互，底层是共享的，这能最大程度保证每个平台底层的正确性。以之前 SwiftUI 开发的 WebBrowser 为例，它与 Android 平台的开发完全是独立的，两个人各做各的，很多逻辑层的工作重复发生、或者只发生在一个平台，比如用户数据的存储。

现在我们的后端统一在 kotlin/rust 中开发，然后前端自己去适配后端所提供的功能。同时当某一个平台前端向后端添加功能的时候，其它平台的前端也能快速跟进。

最重要的是，我们终于能尊重各个前端平台的最佳实践去做出我们的开发了。

然而，这对于我们团队的协作管理也提出了新的需求，我们既然为各个平台开发原生视图，那么等于多一个平台就多一份代码，这需要大家互相协同，进行标准化作业。此时自动化测试的工作尤为重要。

1. 使用 tauri+deno 作为底层基座
2. 不再使用 kmp/browser/desk 的 ComposeRender 渲染窗口，而是使用平台标准的窗口。这个改进需要 kmp 的架构上作出支持，也就意味着，我们真正做出了各个平台使用各个平台的标准来开发渲染内容。以 window.std.dweb 为例：
   1. Android 平台：使用 Activity+JetpackCompose 进行渲染（注意，是 JetpackCompose 而不是 MultiplatformCompose）
   2. IOS 平台：使用 SwiftUI 进行渲染，这意味着原本使用 MultiplatformCompose/Skiko 实现的窗口化不再 IOS 上使用，而是用原生的 SwiftUI 的 View 替代
   3. desktop 平台：使用 TauriWindow 进行渲染。与 SwiftUI 的开发模式也不同，SwiftUI 需要在一个 ApplicationWindowRootView 中模拟出多个 WindowView，而在桌面端，我们使用各个桌面平台标准的 Window 视图，菜单栏也使用平台标准风格
   4. HarmonyOS 平台：使用 ArkUI 进行渲染，与 IOS 平台类似，需要模仿原版 JetpackCompose 的多窗口风格实现代码与交互
3. window.std.dweb 是特别的，它是其它模块渲染层的底座，它决策着 WindowRenderProvider 的实现，将不再仅仅是@composable，而是可针对所属平台扩展的多模式适配器。
   1. Android 平台的基座 JetpackCompose，因此可以使用：
      1. JetpackCompose
      2. MultiplatformCompose/Skiko
      3. AndroidView
   2. IOS 平台的基座是 SwiftUI，因此可以使用：
      1. SwiftUI
      2. UIKit
      3. MultiplatformCompose/Skiko
   3. desktop 平台的基座是 TauriWindow，因此可以使用：
      1. ComposeForWeb
      2. MultiplatformCompose/Skiko
      3. Html
   4. HarmonyOS 平台的基座是 ArkUI，因此可以使用：
      1. ArkUI
      2. MultiplatformCompose/Skiko

可以看到 WindowRenderProvider 中，MultiplatformCompose/Skiko 仍然可以运作在多个平台中，这也是某一个内置模块快速进行快速开发的通用办法，我们也会做好在各个平台上 DWebView 与 MultiplatformCompose/Skiko 的混合渲染的工作。

然后也可以看到我们可以无痛地使用各个平台原生的技术进行内容渲染的开发，这也是我们一开始就强调的愿景，我们希望发挥各个平台优化得最好的标准能力，而不是被 Kotlin 的能力瓶颈所限制。