【提案】 将内核独立，提供编译单独应用包

[waterbang]

当前 Dweb Browser 提供的架构还缺少独立应用的能力，以下是一些实施过程。

启动屏 splash-screen.nativeui.browser.dweb

为了适配单独的应用包，启动屏必不可少，并且也能适配HTML页面首页渲染的白屏。或者适配一些营销需求。

模块整合

模块整合有三类 核心模块,按需导入，必须移除。

核心模块

核心模块不可移除，包含:

• dns.sys.dweb: 路由关键模块。
• jmm.browser.dweb: 提供页面渲染服务。
• js.browser.dweb: 提供可编程后端服务。
• boot.sys.dweb: 模块启动服务。
• file.std.dweb: 文件服务。
• http.std.dweb: 网络服务模块。
• permission.sys.dweb: 应用权限管理模块。

按需导入

针对用户引用的包如果能做到按需导入，移除不需要的模块，将大大减少应用体积。

plaoc 所包含的插件都可以按需移除，比如:geolocation.sys.dweb。

必须移除

desk.browser.dweb: 桌面模块。
web.browser.dweb: 浏览器模块。
以及桌面上所有的模块，比如快捷指令，智能扫码，关于等模块。

[Gaubee]

这篇我要求你来写，是要你先用你的方法做一遍，然后我再教你一遍我的方法。这样你会有一个对比。参考我的方法，一定程度上能辅助加速你的思维迭代速度。

这篇文章开始写之前， 首先需要明确你的愿景。就是为什么需要做这个事情，它有什么意义，尽可能多方位地考虑各种有直接关联的角色，思考他们能得到什么切实的好处。（这就是“以人为本”）
但因为是短篇，所以不用写得太复杂，抓住一些关键的重点来写就行。比方说：
“
我们将 Dweb Browser 的跨平台的内核提取出来，为开源社区提供一种新的跨平台开发的选择。
让 Dweb Browser 有更加广泛的应用场景，于我们团队而言，收获更加广泛范围的社区建议，也能更好地打磨架构和内核。
”
我这边的关注点主要是社区和我们自己团队，针对的是跨平台开发这个需求点。
如果要写长篇，同理可以考虑更多的相关角色，比方说企业的综合影响力，比方说产品经理，比方说测试人员 、用户等等。
这些你可以不写，但要有这个考虑的过程，考虑的越多越远，你的知识储备就会被你翻出来，从而这些知识储备就会在这次思考中交织在一起，会给你新的启发和角度。同时你会对你的开发越清晰、接着混乱、接着清晰、这是一个螺旋上升的过程。
这个过程的本质，就是“选择”，也就是说你要开始做决策，也意味着你要舍得放弃一些东西。

[Gaubee]

紧接着，在这些愿景上，可以进一步细化一些专业性的东西。这里我考虑的是“跨平台”这个点，所以相对应的优势也是围绕开发者和产品能获得的 “优势” 来展开，这个过程中，你可以对比同类竞品，来强调优势，比方说：
“
它的主要优势在于：

1. 既可以开发 Web 应用，也可以开发基于 CMP/KMP 的原生应用。当然也意味着可以混合 CMP/KMP/Web 技术来做混合开发。从而既可以快速迭代，又可以满足高性能的体验。
2. 基于 Web 开发
   1. 默认使用前后端分离的架构，即便是 Web 应用中，复杂的应用程序逻辑也默认不会阻塞渲染进程，给用户良好的使用体验。
   2. 可以使用本地部署的 SSR 技术，从而多方位提升 WebView 渲染的性能，相比 cordova、capacitor 等 webapp 开发框架，可以有效减少内存使用，提升加载速度
   3. 可以使用 Multi-WebView（多个 WebView）来做混合图层，相比其它 webapp 开发框架使用单个 WebView，可以获得更加灵活的渲染，比如预加载预渲染预处理、比如原生的导航
3. 基于 CMP/KMP 开发
   1. 会有比 Flutter、ReactNative 更好的渲染性能
   2. 可以享受 KMP 优秀的跨平台开发的使用体验
   3. 可以使用 rust-uniffi 进一步提供高性能的共享库
      ”

对比的过程也是强化自己愿景和信心的过程

[Gaubee]

做完这些思考，你基本对你要做的事情已经比较清晰，接下来就是对任务的细化。此时需要的是两步走，第一步是 “想象”，第二步是 “时间” 。

关于想象力，正如你做的，想象作为用户，看到的应用的启动、使用的过程；想象作为开发者，开发应用的过程。
结合“优势”篇提到的特点展开想象：

1. 比如 Web 开发相关的，那么是关于 【提案】🎉✨ mwebview.browser.sys = window.std.dweb + webview.sys.dweb #40 。
2. 比如关于 CMP/KMP 开发相关的，这里相对缺乏经验，可能需要一些可行性调研，需要考虑别人如何在 KMP 项目中导入我们的库来做开发。
3. 最终我们还得想象开发者如何做编译打包。如果是 web 开发者，他们的打包体验应该尽可能简单；如果是 cmp/kmp 开发者，他们可能需要做一些定制化的编译打包。
4. 此外，我们还得融合考虑更多复杂的场景和角色。比方说测试怎么做，比方说自动化怎么做。我们可以给出一些基本的建议，如果发现有针对性的差异，需要重点强调，比方说作为 web 开发者，开发原生多平台，测试的流程和工具可能会不一样，那么就需要重点强调。
5. 罗列出各个角色领域所需要用到的工具链，尽可能多地考虑不同种类的知识体系。这会逼迫你回归“朴实”，这里的朴实并不代表“易用”，要做到易用，就是寻找工具链、开发工具链的目的。此时需要充分利用面向过程的思维，使用管道的思维去做出一个个工具。

完成“想象”后，接下来就是要面对现实，此时就是关于“时间”，你需要规划出“最小里程碑”。第一步很重要，需要你自己以最小的代价完成一个可用版本。比如我们可以针对 ssg 的 webapp 开发者，提供最小里程碑版本。
然后是在这个里程碑上逐步扩展：

1. 扩展出它有 ssr 的开发需求（也就是现在的 plaoc/server 需要往前演进的）

   1. 考虑它有后端开发的经验，所以可以尝试融合社区中已经有的一些后端开发的框架，这里大多是 nodejs，所以还得寻找 nodejs 在浏览器端的垫片实现，如果此路不通，我们就得提供一个 nodejs 开发者比较熟悉的开发框架
   2. 还有一些新兴的框架是从前端开发者入手去做 ssr、比如 qwik、 nextjs 这两个是天生的 ssr，还有 vue、svelte，这两个是逐步演化出 ssr 的前端框架，这些我们也应该尽可能地去考虑适配，通常我们可以交给社区，但是前提是我们得自己先打样尝试做出一个 demo 来，证明其可行性。（这也是 【提议】开发 @plaoc/sveltejs-adapter ，从而为在dweb平台上使用ssr做一个标杆 #218 提到的需求）

2. 扩展出它有一些原生接口开发的需求（比方说要使用微信支付宝的 android/ios-sdk）等等

   1. 需要考虑它以最小的成本开发一个 nmm，并且对接到项目中
      1. 可以考虑如何最小化地去定义一个基于 kmp 开发的模块，我们可以考虑使用官方正在做的 Amper 工具，这里需要一些可行性验证
   2. 进一步，需要考虑它如何使用社区中别人写好的 nmm，我们可能得有一个模块上传、模块安装的标准。
      1. 通常是要兼容 maven 的，但并不意味着我们得用 maven 的标准去做模块，正如 dnt 就是将 deno 的模块编译成 nodejs 模块一样，我们需要指定标准和工具。
      2. 可以使用 golang 的哲学，不去做所谓的仓库，我们只需要提供一个模块安装器，将 https://xxx/dwebmod.yaml 链接下载。
         1. 如果是 git 仓库链接，那么就要考虑使用 commit-hash 来稳定版本；同时也需要有不同的机制去检查更新
         2. 下载下来后，可以将代码插入本地，转换成本地模块。
         3. 如果有上传 maven 的需求，既可以做到如果有上传 maven 的需求，那就编译成标准的模块，开发者自己去配置 maven 包发布的相关工作。
   3. 再进一步，需要考虑要使用 cmp 来开发原生的界面，或者是混合 web 的原生界面。
      1. cmp+web 混合渲染存在的坑：
         1. 得告知开发者 wkwebview 这类 UIView 的图层混合的原理是镂空，多个 UIView 图层混合会出问题
         2. 得告知开发着 desktop 上使用的是 java 而不是 native，那么就得面对 java-swing 技术体系的学习，以及和 UIView 相反，是置顶渲染的。
      2. 我们得提供更加复杂的原生多图层的接口，目前的 PureViewController 还不够，还得提供比如窗口无边框、无焦点等属性
         1. 原生平台上窗口的生命周期也是不一样的，modal 图层会阻塞其它图层的生命周期，所以如果把 modal 的一些逻辑写在父级图层那里，那么这部分逻辑会随着 modal 图层显示后而再也无法执行。
      3. 我们需要比 cmp 更进一步抽象，因为 cmp 考虑的是一个图层窗口里头的工作，而我们要考虑多窗口的标准化工作。

3. 启动屏幕如何做到多平台统一，这是一个比较复杂的问题，比方说广告的需求、可交互的需求、动画的需求、共享元素的需求等等

4. jxbrowser 是商业化的，我们如果去考虑 webview2，那么工作量实在不小（因为要支持离屏渲染）

以上只是列举了部分内容，需要根据时间逐步拆分。
第一里程碑非常重要，因为想象力所能触达的是理想情况下的需求。真正实践起来会遇到很多问题，有些问题甚至是无法绕过的。因此快速做出第一里程碑，并且确保接下来能快速迭代，才能尽早发现问题，有时候甚至需要推翻重来，重新制定开发路径。

cmp 代表的是最朴素的原生 GUI 开发，绝大多数问题其其它框架也无法避免的，甚至可以说并不能做的比 cmp 好。可以说其它框架能做好的 cmp 也能做好，其它框架做不好的 cmp 也有办法能做到。

目前 kmp 最大的问题其实在于它要涵盖的工作内容太多了，导致鸿蒙的支持一直没上线，也很难上线，目前只能等到 2025 年下半年国内一些其它厂商向上游提交解决方案。

[waterbang]

落地步骤

• 实现启动屏提案，详见【讨论】 🎉 dweb+protocol://splashscreen.window.std.dweb/ #51。
• 提供生成android文件夹的能力。
• 提供生成ios文件夹的能力。
• 提供 plaoc bundle --android --ios 打包出 android和ios应用。

由于dweb 优势，应用开发的时候将动态调试，不需要每次编译到手机，所见即所得。

• 提供 vscode 插件，用于快速编译android/ios项目。