小程序

原生开发

微信小程序为例：

优势：

• 性能佳/包体积小
• 兼容性强
• 功能支持全面
• 调试和错误定位更直接

劣势：

• 无法跨端
• 开发效率低
• 新语法 wxml wxcs json js
• 缺少状态管理，路由
• 无组件化复用机制
• 需要专门组件库
• 工程化能力弱
  • ts, less

采用框架开发

性能比对：

https://github.com/yangmingshan/mp-framework-benchmark

https://github.com/hiyuki/mp-framework-benchmark

原理

compile-time framework

Code --(parse)--> AST --(transform)--> AST --(generate)--> Code

Taro 2

![[Pasted image 20250924164338.png]]

uniapp

// uni-app 源码（类Vue语法）
<template>
  <view class="container">
    <text>{{message}}</text>
  </view>
</template>

// 编译后的微信小程序代码
<view class="container">
  <text>{{message}}</text>
</view>

缺点：被动，复杂

优点：性能最近接原生开发，包体积小

runtime framework

Taro 3 / Remax / kbone / Rax

uniapp

// uni-app
export default {
  onLoad() {
    // 页面加载
  },
  onShow() {
    // 页面显示
  }
}

// 微信小程序
Page({
  onLoad() {},
  onShow() {}
})

// 支付宝小程序
Page({
  onLoad() {},
  onShow() {}
})

// uni-app统一API
uni.request({
  url: 'https://api.example.com',
  success: (res) => {}
})

// 编译后调用对应平台API
// 微信：wx.request()
// 支付宝：my.request()
// 百度：swan.request()

taro 3 抽象为 VDOM 以适用不同平台

// React虚拟DOM
const vdom = {
  type: 'view',
  props: {
    className: 'container',
    children: [
      {
        type: 'text',
        props: { children: 'Hello Taro' }
      }
    ]
  }
};

// 转换为小程序data
const miniappData = {
  root: {
    cn: [{
      nn: 'view',
      cl: 'container',
      cn: [{
        nn: 'text',
        v: 'Hello Taro'
      }]
    }]
  }
};

DOM/BOM 模拟

// Taro Runtime核心
class TaroElement {
  constructor(nodeType, nodeName) {
    this.nodeType = nodeType;
    this.nodeName = nodeName;
    this.childNodes = [];
    this.parentNode = null;
  }
  
  appendChild(child) {
    this.childNodes.push(child);
    child.parentNode = this;
    // 触发小程序更新
    this.enqueueUpdate();
  }
  
  removeChild(child) {
    const index = this.childNodes.indexOf(child);
    this.childNodes.splice(index, 1);
    this.enqueueUpdate();
  }
}

渲染流程

graph TD
    A[React组件更新] --> B[Virtual DOM Diff]
    B --> C[Taro Runtime处理]
    C --> D[生成小程序数据结构]
    D --> E[调用setData更新]
    E --> F[小程序重新渲染]

// Taro的更新机制
class TaroReconciler {
  updateContainer(element, container) {
    // React Fiber调度
    this.scheduleUpdate(container, element);
  }
  
  commitUpdate(instance, updatePayload) {
    // 将DOM操作转换为小程序数据
    const data = this.transformToMiniappData(instance);
    
    // 调用小程序setData
    getCurrentPage().setData(data);
  }
}

还有事件机制等

运行时增强

mpx vue-mini

![[Pasted image 20250924163453.png]]

uniapp

![[Pasted image 20250924163152.png]]

比较：

条件编译

uniapp

// #ifdef MP-WEIXIN
// 微信小程序特定代码
wx.showModal({
  title: '提示',
  content: '这是微信小程序'
})
// #endif

// #ifdef MP-ALIPAY
// 支付宝小程序特定代码  
my.alert({
  title: '提示',
  content: '这是支付宝小程序'
})
// #endif

动态渲染

WebView

<view wx:if="{{type === 'text'}}">{{content}}</view>
<image wx:elif="{{type === 'img'}}" src="{{content}}" />
<button wx:elif="{{type === 'btn'}}">{{content}}</button>

结论

• 不做编译器，不做运行时，
• 有多端需求，uniapp, taro 二选一，基于 uniapp, taro 再做上层建设

UI 库

微信小程序

问题：单个库只适配微信小程序

uniapp

其它资源：

https://github.com/codercup/unibest

https://github.com/uni-helper/awesome-uni-app

taro

https://docs.taro.zone/docs/treasures#%E6%A0%B7%E5%BC%8F%E5%BA%93

问题：2.x 3.x 4.x，不兼容，兼容 4.x 的少，活跃的少

选一套组件库，还是重新开始？

主 AI 生成方向

初步

设计稿 > ai > 代码 > 调试修改 > 编译/构建 > 发布/上传

• 缺少组件库 (第三方 + 自己维护)
• 浅色/深色模式
• 主题定制
• 多平台兼容性
• …

下一步

无论是自研组件库，还是用的开源项目组件库，封装修改再所难免，等一定程度稳定后，比如完成了 2-3 个项目。需要约束 ai 生成代码的规则，方式等，此时路线与 web 端的 ai 方向一致。这个过程与组件库，开发范式的沉淀是同步的

总结： 这条路线意味着：小程序与现有 web 端的低代码基本没有关联，各自独立，互不依赖。优势是没有啥包袱，不用考虑 web 端的兼容，天然支持二次开发。劣势是 ai 的不稳定性，产出不稳定，前期 ui 库，工具库需要积累沉淀。

低代码形式

Web 与小程序之间的核心差异：

1. 运行环境不同：Web 运行在浏览器中，有标准的 DOM/BOM API。小程序运行在各大 App（微信、支付宝、抖音等）提供的封闭 Runtime 中，没有 DOM，API 由平台方提供。
2. UI 语言不同：Web 使用 HTML/CSS。小程序使用自家的类 XML（如微信的 WXML、支付宝的 AXML）和类 CSS（WXSS/ACSS）方言。
3. API 能力不同：小程序拥有更深度的原生能力，如微信登录、支付、扫码、蓝牙、文件系统等，这些是 Web 难以企及的。
4. 多端碎片化：微信、支付宝、百度、抖音、QQ 等小程序，虽然大同小异，但在组件、API、配置上均有差异。

以上问题，绝大部分 uniapp，taro 已处理

设计原则

• 抽象与统一 ：将不同小程序平台的差异进行抽象，为低代码使用者提供一个统一的、平台无关的开发体验。用户拖拽的是一个“按钮”，而不是一个“微信按钮”或“支付宝按钮”。
• 最大化复用：尽可能复用已有的 Web 低代码平台的逻辑编排、数据模型、后端服务集成等能力，只针对渲染层和 API 调用层进行适配。
• 渐进式增强与兼容 ：在提供统一能力的基础上，也要允许开发者使用特定小程序平台独有的高级功能（如微信的视频号直播组件），避免能力被“拉平”到最低水平。

技术架构方案选型

DSL + 多端编译器（uniapp taro）

• 核心思想：

  1. 定义一套平台无关的页面描述语言（DSL）：低代码平台拖拽生成的产物，不再是 HTML，而是一个中间形态的 JSON Schema 或自定义 DSL。这个 DSL 描述了页面的结构、组件、样式、数据绑定和事件。
  2. 生成 uniapp taro 代码
  3. 利用 uniapp taro 跨端

• 具体实施：

  1. 画布（低代码编辑器）改造：
     • 是否统一组件库：设计一套标准的“元组件”（如 Button, Input, Image, List）。
     • 画布是否统一
  2. 代码生成
  3. 自定义，二次开发 优势：

1. 所见即所得，设计图不在是必须项
2. 产出稳定

劣势：

1. 工作量大，复杂度高
2. 维护不容易，上手难（代码）

方案二：Webview 渲染方案

• 核心思想：在小程序中内嵌一个 <web-view> 组件，直接加载你现有低代码平台生成的 H5 页面。
• 具体实施：
  1. 为小程序创建一个“壳”，这个壳只有一个页面，页面里只有一个铺满全屏的 <web-view>。
  2. <web-view> 的 src 指向你的 H5 页面地址。
  3. 通过 wx.miniProgram.postMessage 和 <web-view> 的 bindmessage 事件，实现 H5 和小程序之间的通信，从而间接调用小程序 API（如支付、登录）。
• 优势：
  • 改造成本极低，几乎可以无缝复用现有 Web 低代码能力。
• 劣势：
  • 体验极差：页面切换有白屏，手势返回不流畅，和小程序原生页面体验有天壤之别。
  • 功能受限：无法使用绝大部分小程序原生组件（如 <map>, <live-player>），API 调用链路长、不稳定。
  • 性能瓶颈：Webview 性能远不如小程序原生渲染。
  • 审核风险：很多平台对纯 Webview 的小程序审核非常严格，可能被拒。

类 React-Native 渲染方案 (技术复杂)

将低代码 DSL 渲染成原生组件。这在技术上类似 React Native，但对于小程序环境来说过于复杂，且与 Web 技术栈差异过大

功能设计调整

对应实施步骤的画布改造：

1. 目标平台选择器：
   • 在项目创建或编辑器顶部，增加一个“目标平台”的切换开关（如 Web / 微信小程序 / 支付宝小程序）。
2. 组件库差异化展示：
   • 当切换到“微信小程序”时，组件库中可以出现微信独有的组件（如 <official-account>、<open-data>）。
   • 通用组件的属性面板也需要动态调整，显示目标平台支持的属性。
3. 画布预览：
   • 编辑器的预览画布最好能模拟小程序的导航栏、胶囊按钮等 UI 特征，让用户所见即所得。
4. 逻辑编排：
   • 在逻辑流或事件绑定中，增加小程序专有的 API 节点（如“获取用户信息”、“发起支付”），这些节点底层会调用我们封装好的 API 适配器。

建议步骤

1. 技术预研与选型

   • 深入研究 Taro、uni-app 等框架的原理，评估将其编译能力集成到你平台的可行性。这比自研编译器要快得多。

2. 核心改造 - DSL 与编译器集成 (1-3 个月)

   • 设计或调整你现有的页面描述 DSL，使其能表达小程序的结构和能力。
   • 改造你的低代码编辑器，使其生成的 DSL 能够被 Taro/uni-app 的编译器所理解（例如，生成 Vue Component-like 的 JSON 结构）。
   • 打通“编辑器 -> 生成 DSL -> 调用编译器 -> 生成小程序代码”的核心链路。

3. 第三步：产品功能完善 (并行)

   • 开发上文提到的“目标平台选择器”、“组件库差异化”等产品功能。
   • 封装小程序常用 API，形成统一的 API 库，并在逻辑编排器中提供节点。

4. 第四步：发布与预览流程打通 (1 个月)

   • 实现二维码预览功能。
   • 实现代码包下载功能。

ai 生成方向 与 低代码方向对比：