---
url: https://native-shell.com/zh-CN/docs/comparison
description: "手机客户端显示发布之后才到来的界面有哪些做法——WebView、服务端驱动 UI、小程序容器、跨平台框架的热更新——以及它们与 nsh 的比较。"
---

# 方案对比

手机客户端想要显示安装包里没有的界面——由模型生成的回答、来自合作方或其他团队的功能、无需发版就能变化的页面——已有几种成熟的做法。它们的区别在于：界面由什么绘制，下发的代码能做什么，以及宿主应用要为承载它们做多大的改动。本页把它们与 nsh 放在一起比较。

## 几种做法

| | 由什么绘制 | 能表达什么 | 约束方式 | 适合生成式界面吗 | 宿主应用的代价 |
|---|---|---|---|---|---|
| **WebView（H5）** | 浏览器引擎 | HTML、CSS、JS 能做的一切 | 同源策略；原生能力通过手写的桥接暴露 | 模型擅长写 HTML；但结果看起来、用起来都是网页 | 每个视图一个浏览器引擎；还要维护桥接 |
| **服务端驱动 UI** | 应用自己的原生视图 | 只能组合应用内置的组件和动作，用 JSON 描述 | 完全受限：协议就是边界 | 容易生成，但能表达的很少：协议之外没有本地状态和逻辑 | 每个应用都要为每个组件及其版本实现渲染器 |
| **小程序容器** | 通常是 Web 引擎加一层私有封装 | 平台特有的框架和 API | 容器自己的权限模型 | 私有方言，模型不熟悉 | 体积很大的容器 SDK |
| **跨平台应用的热更新**（例如 React Native 搭配代码推送服务） | 该框架的渲染器 | 整个框架的能力 | 没有约束：更新就是受信任的应用代码 | 这类更新并不是为按请求生成的代码设计的 | 整个应用都得用该框架编写 |
| **nsh** | UIKit 和 Android 视图 | 带状态、逻辑、动画和布局的组件；宿主注册的原生视图 | 签名包；每个视图一个虚拟机，限制由宿主设定；能力按视图授予 | 为此而设计：一个 TSX 模块、类型化的 API、无界面验证 | 在现有原生应用里放一个视图、加一个库 |

## nsh 的不同之处

- **是原生界面，不是网页。** 模块由平台的视图组成，文本选区及其菜单、输入法、无障碍和滚动都是系统自己的——这也是 nsh 在 [GPUI Shell](https://native-shell.com/zh-CN/docs.md) 之外存在的原因。
- **不止一套协议。** 服务端驱动 UI 只能重新组合应用已有的东西；nsh 模块有自己的状态、逻辑、动画和布局，模型可以生成应用开发者事先没有预料到的界面。
- **由宿主约束。** 下发的代码是不可信的。nsh 在运行任何代码之前检查签名和吊销列表，为每个视图分配独立的虚拟机并设定内存、调用时长和节点数限制，由宿主决定模块能访问哪些网络主机、网页和系统设置（[沙箱与能力](https://native-shell.com/zh-CN/docs/sandbox-and-capabilities.md)）。
- **嵌入，而不是迁移。** 应用仍然是原生应用，沿用原来的工具链；nsh 只是放在需要显示模块的地方的一个视图（[iOS](https://native-shell.com/zh-CN/docs/embedding-ios.md)、[Android](https://native-shell.com/zh-CN/docs/embedding-android.md)）。

## 什么时候其他做法更合适

- 界面本身就是文档或现成的网页：WebView 可以原样显示。
- 页面集合固定且很少，变化的只是内容和顺序：服务端驱动 UI 完全不需要运行时。
- 整个应用本来就是用某个跨平台框架编写的：用它自己的更新机制下发代码即可。

## 另请参阅

- [简介](https://native-shell.com/zh-CN/docs.md)：nsh 为什么存在、为什么而设计。
- [架构](https://native-shell.com/zh-CN/docs/architecture.md)：nsh 内部各部分在哪里运行。