uni-app组成和跨端原理

uniapp项目中的两套渲染引擎使用

• vue页面：基于WebView渲染，依赖浏览器引擎，性能受WebView限制。
• nvue页面：使用原生渲染（weex），直接调用原生组件，性能更接近原生应用。

uniapp在app端运行是 靠 “webview”帮助，但是原生app中他们大多不用webview这个技术

uni-app的编译器

uni-app的运行时（runtime）

runtime不是运行在电脑开发环境，而是运行在真正的终端上。

uni-app在每个平台（Web、Android App、iOS App、各家小程序）都有各自的runtime。这是一个比较庞大的工程。

• 在小程序端，uni-app的runtime，主要是一个小程序版的vue runtime，页面路由、组件、api等方面基本都是转义。
• 在web端，uni-app的runtime相比普通的vue项目，多了一套ui库、页面路由框架、和uni对象（即常见API封装）
• 在App端，uni-app的runtime更复杂，可以先简单理解为DCloud也有一套小程序引擎，打包app时将开发者的代码和DCloud的
• 程序打包成了apk或ipa。当然，事实上DCloud确实有小程序引擎产品，供原生应用实现小程序化，详见

uni-app runtime包括3部分：基础框架、组件、API。

1. 基础框架：

• 包括语法、数据驱动、全局文件、应用管理、页面管理、js引擎、渲染和排版引擎等
• 在web和小程序上，不需要uni-app提供js引擎和排版引擎，直接使用浏览器和小程序的即可。但app上需要uni-app提供
• App的js引擎：App-Android上，uni-app的js引擎是v8，App-iOS是jscore
• App的渲染引擎：同时提供了2套渲染引擎，.vue页面文件由webview渲染，原理与小程序相同；.nvue页面文件由原生渲染，理与react native相同。开发者可以根据需要自主选择渲染引擎。

2. 组件：

• runtime中包括的组件只有基础组件，如<view>、<button>等。扩展组件不包含在uni-app的runtime中，而是下载到用户的项目代码中。（这些组件都是vue组件）
• 为了降低开发者的学习成本，uni-app的内置基础组件命名规范与小程序基本相同。
• 这几十个组件不管在哪个平台，已被处理为均有一致表现。
• 在小程序端，uni-app基础组件会直接转义为小程序自己的内置组件。在小程序的runtime中不占体积。
• 在web和android、iOS端，这几十个组件都在uni-app的runtime中，会占用一定体积，相当于内置了一套ui库。
• 组件的扩展：
  • 有了几十个基础组件，大多数扩展组件也都是基于这些基础组件封装的。比如官方提供的扩展ui库uni ui。
  • 在web平台，for web的各种ui库（如elementUI）也可以使用，但这些库由于操作了dom，无法跨端在app和小程序中使用。
  • 在App平台，uni-app也支持使用原生编程语言来自行扩展原生组件，比如原生的地图、ar等。
  • uni-app同时支持将微信自定义组件运行到微信小程序、web、app这3个平台。注意微信自定义组件不是vue组件。

3. API：

• uni-app runtime内置了大量常见的、跨端的 API，比如联网(uni.request)、读取存储(uni.getStorage)
• 同时uni-app不限制各端原生平台的API调用。开发者可以在uni-app框架中无限制的调用该平台所有能使用的API。即，在小程序平台，小程序的所有API都可以使用；在web平台，浏览器的所有API都可使用；在iOS和Android平台，os的所有API都可以使用。
• 也就是说，使用uni-app的标准API，可以跨端使用。但对于不跨端的部分，仍可以调用该端的专有API。由于常见的API都已经被封装内置，所以日常开发时，开发者只需关注uni标准API，当需要调用特色端能力时在条件编译里编写特色API调用代码。
• ext API：web和app的runtime体积不小，如果把小程序的所有API等内置进去会让开发者的最终应用体积变大。所以有部分不常用的API被剥离为ext API。虽然仍然是uni.开头，但需要单独下载插件到项目下
• 小程序平台：uni对象会转为小程序的自有对象，比如在微信小程序平台，编写uni.request等同于wx.request。那么所有wx.的API都可以这样使用。
• web平台：window、dom等浏览器专用API仍可以使用
• app平台：除了uni.的API，还可以使用plus.的API、Native.js，以及通过uts编写原生插件，或者使用java和objectC编写原生插件。这些原生插件调用os的API并封装给js使用。
• 由于历史沿革，DCloud在开发app时有：5+App、wap2app、uni-app等3种模式。这3种方式的runtime在底层能力上是公用的，所有uni-app可以调用5+（也就是plus.xxx）的API。虽然都可以使用5+的系统能力，但uni-app的逻辑层运行在js层，渲染层是webview和原生nvue双选。而5+不区分逻辑层和渲染层，全部运行在webview里，在性能上5+不及uni-app。

上述刻制 uniappApp的渲染引擎：同时提供了2套渲染引擎，.vue页面文件由webview渲染，原理与小程序相同；.nvue页面文件由weex(原生渲染)，原理与react native相同。开发者可以根据需要自主选择渲染引擎。

uniapp的 发送请求的 responseType是没有 blob这个类型的， responseType: 'arraybuffer'

uniapp 标准js和浏览器js的区别

uniappx

nvue 是 UniApp 中用于提升性能的 Native Vue 页面，基于原生渲染，主要用于 App 端。它无法直接转换为小程序代码，

uvue是一套基于uts的、兼容vue语法的、跨平台的、原生渲染引擎。

uview组件在2.0版本支持了nvue文件，但是还不在uniappx项目中支持

uts

UTS（Uni-TypeScript）会被编译为真正的原生代码（非解释执行或跨容器运行）

和RN的关系

如果 React Native 和 Weex 是运行时将 js view 转为 native view 去渲染，那么 uts + uvue 就是编译时把 uts 转化为 kotlin view 和 swift view 去打包。

无论是uniapp、还是rn，工程开发的时候虽然是js，但最终还是会打包成一个原生包，也就是native，程序会通过jsbridge搭建起一个js与native之间的桥梁，js做什么操作，返回反馈给native对应的命令，当然这也解释为什么明明在浏览器端有些js语法支持，到了RN和uniapp中就不行的原因，因为不存在对应的native和js的命令映射关系呀！所以有的公司会专门请一个工程师去解决native和jsbridge的问题（例如阿里的1688就是基于weex的hybird开发）。

RN、Flutter、Uni-app APP框架对比

1. React Native (RN)：混合编译 + JavaScript 解释执行

核心机制

• JavaScript 代码：运行在 JavaScript Core（iOS）/ Hermes（Android）引擎 中，动态解释执行（类似浏览器运行 JS）。
• 原生组件：JS 代码通过 Bridge 或 Turbo Module/JSI（新架构） 与原生模块通信，渲染为原生 UI（如 View/TextView）。

关键点

环节	RN 的实现方式
代码执行	JS 解释执行（Hermes 可预编译字节码）
UI 渲染	原生组件直接渲染（非 WebView）
通信机制	Bridge（旧） → JSI（新，零拷贝）
热更新	支持动态加载 JS Bundle

性能影响

• 优点：比 WebView 方案（如 Cordova）更快，因为 UI 是原生的。
• 缺点：JS ↔ Native 通信有序列化开销（旧 Bridge 架构更明显）。

---

2. Flutter：AOT 编译 + Skia 自绘引擎

核心机制

• Dart 代码：AOT（Ahead-of-Time）编译为原生机器码（Release 模式），非解释执行。
• UI 渲染：通过 Skia 图形引擎 直接绘制像素，不依赖原生组件（但可嵌入原生视图）。

关键点

环节	Flutter 的实现方式
代码执行	Dart → 原生机器码（AOT 编译）
UI 渲染	Skia 自绘（跨平台一致性高）
通信机制	Platform Channel（较 RN Bridge 快）
热更新	仅支持 Debug 模式（JIT），Release 需重编译

性能影响

• 优点：
  • 接近原生性能（无 JS 解释开销）。
  • 120fps 流畅动画（Skia 直接控制渲染）。
• 缺点：
  • 包体积较大（需内置 Skia 引擎和 Dart VM）。
  • 无法动态更新代码（AOT 限制）。

---

3. 三者在编译/执行上的对比

框架	代码执行方式	UI 渲染方式	通信机制	热更新支持	性能定位
React Native	JS 解释执行（Hermes 可选 AOT）	原生组件	Bridge/JSI	✅ JS Bundle	接近原生，但依赖通信优化
Flutter	Dart AOT 编译	Skia 自绘	Platform Channel	❌（仅 Debug）	原生级性能
原生开发	直接编译（Kotlin/Swift）	原生组件	无跨语言通信	❌	最优性能

---

4. 如何选择？

选 RN 当

✅ 需要热更新能力（动态修复 Bug）
✅ 已有 React 技术栈团队
✅ 对性能要求不极致，但希望比 WebView 快

选 Flutter 当

✅ 需要高性能 UI（如游戏、复杂动画）
✅ 追求跨平台一致性（Skia 自绘减少适配成本）
✅ 能接受较大包体积和缺少动态代码更新

选原生当

✅ 需要 100% 发挥平台特性（如 ARKit、低延迟蓝牙）
✅ 对包体积和启动时间极度敏感

---

5. 常见误解澄清

❌ “Flutter 是解释执行的”
→ 错误！Flutter Release 模式是 AOT 编译，直接跑机器码。

❌ “RN 新架构（Fabric）能完全消除 Bridge 开销”
→ 部分正确！JSI 减少序列化，但 JS 仍需要解释执行（除非 Hermes 预编译）。

❌ “Flutter 不能调用原生代码”
→ 错误！通过 PlatformChannel 或 FFI 可直接交互，只是默认不依赖原生组件。

技术学习成本和难度

RN， 要求开发者学习React，要求精通Flex布局，要求原生开发协作。
Flutter，要求开发者学习Dart，了解Dart和Flutter的API、要求精通Flex布局，要求原生开发协作。
Weex，已经内嵌到uni-app中，就不单独提了。
uni-app，要求开发者学习Vue，了解小程序。
很明显uni-app的学习成本太低了，它没有附加专有技术，全部使用公共技术。

性能分析和写法的对比

flutter作为界面库（注意它只是界面库，dart语言是另一个项目），它唯一要干的事情就是渲染界面。不像HTML5，flutter界面库连视频、定位等都没有，就是一个纯排版引擎，绘制文字、按钮、图片等常用界面控件。

这个排版引擎的特点是简单、高性能。

3大引擎的性能排名：flutter > react native/weex > webview
3大引擎的编码复杂程度排名：flutter > react native/weex > webview

（uni-app是双渲染引擎，webview和weex都内置了，随便开发者使用切换）

性能好，有个度，客观地讲，rn/weex调用原生渲染的性能，和flutter的渲染性能，在用户体验上并没有明显区别，甚至在很多场景下，和webview渲染的小程序也没有明显区别。

ui库比较

RN和 flutter 在IOS和Android上需要使用2套ui库，
uni-app默认也是这种通用ui风格。uni-app的开发者只需要写一套界面ui，就可以适应不同手机的用户，真正的 write once，run anywhere。

动态性(热更新)
除了flutter，rn/weex/uni-app都可以动态热更新。
标准的flutter 不支持热更新，有团队改造了flutter，使其支持热更新，当然也相对的降低了性能。

由于政策等限制，uni-app x 官方在打包后不提供热更新支持，这个也可以理解，可执行二进制文件的热更新不符合规范，官方如果内置就会导致上架问题，你可以自己二次开发，但是官方绝不能内置。

原因如下：

UniApp 官方推荐的热更新工具（如 wgt 包更新）仅适用于 vue 页面和 JS 逻辑，不涵盖 nvue 和 UTS 的原生部分。

wgt 更新无法修改原生代码（如 uts 编译后的部分）、nvue 的 UI 结构。

如果 React Native 和 Weex 是运行时将 js view 转为 native view 去渲染，那么 uts + uvue 就是编译时把 uts 转化为 kotlin view 和 swift view 去打包。

生态

任何开发引擎，都离不开生态。

对于国外的开发者，rn、flutter的生态肯定比uni-app好，比如facebook登陆分享、Google地图等。

但对于国内的开发者，那是反过来的，中国开发者需要的全端推送（UniPush集成了iOS、华为、小米、OPPO等众多原厂推送）、各种国内登陆、支付、分享SDK、各种国内地图、各种ui库、以及Echart图表等，都是在uni-app体系里，这方面生态可比rn、flutter丰富多了。uni-app的插件市场有数千款插件，不能说应有尽有，但确实是最丰富的跨端开发框架生态了。

另外，uni-app的生态还比其他竞品强在如下方面：

App和H5提供了renderjs技术，使得浏览器专用的库也可以在App和H5里使用，比如echart、threejs等参考
兼容微信小程序 JS SDK，丰富的小程序生态内容可直接引入uni-app，并且在App侧通用，参考
兼容微信小程序自定义组件，并且App、H5侧通用，参考
这些丰富的生态兼容，是rn和flutter无法享受的。

打包配置

• uniapp项目中spaceID才是每个独立项目使用单独的 SpaceID, AppID 是标识前端应用，用于区分不同客户端
• uniapp项目中 打包时appid不一致会导致后来新打的包安装替换不了旧的包
• 不同证书的安装包，同一spaceID，在包安装更新时候会安装不上

实际rpx的值

实际rpx值 = (min(设备宽度, rpxCalcMaxDeviceWidth) / rpxCalcBaseDeviceWidth) × (rpx值 / 2)

所以我们的即使rpxCalcBaseDeviceWidth写的为375rpx，但是实际设计图包括css代码里里仍是750rpx，因为除以2了

总结

在 uniapp 环境中无法直接使用 SignaturePad 库主要有以下几个原因：

1. DOM API 差异

• SignaturePad 依赖浏览器的 DOM API（如 document.querySelector , canvas.getContext() ）
• uniapp 使用的是小程序/原生应用的渲染引擎，不是完整的浏览器环境
• uniapp 的 canvas 是通过原生组件实现的，不是标准的 HTML5 Canvas

2. 事件系统不同

• SignaturePad 使用标准的鼠标/触摸事件（ mousedown , mousemove , touchstart 等）
• uniapp 使用自定义的事件系统（ @touchstart , @touchmove , @touchend ）

3. Canvas 上下文获取方式不同

• 浏览器环境 ： canvas.getContext(‘2d’)
• uniapp 环境 ： uni.createCanvasContext(‘canvasId’)

定位 app-service.js 运行时

在 HBuilderX 输出栈对应的运行目录里找 app-service.js：
App：unpackage/dist/dev/app-plus/app-service.js
微信小程序：unpackage/dist/dev/mp-weixin/app-service.js
H5：开发态由 vite 内存编译，build 后在 unpackage/dist/build/h5/