成也UNI，败也UNI

作者 obaby

2026年9月15日 15:06

在不久的以前，写代码还需要大量人力的时候，跨平台框架无疑是最好的选择。不管是uni还是flutter，都是为了这个而生的，当然这不是最早的跨平台框架，在这之前还有很多其他的框架，可能大家都不曾听说过，我简单介绍个我用过的两个：b4a（basic for andorid），我最开始并不怎么喜欢写（~~再问就是不会~~）安卓的java代码，想着偷懒，不要去弄安卓那一套，偷懒玩了下b4a，这也是最开始做findu的时候最朴素的想法；另外一个是delphi的firemonkey框架，这个东西体验的更早，刚来青岛的时候，为了查询公交基于这个东西做了个公交查询的app，最后跑在了ios上。

这些框架，不能说生不逢时，只能说基础功能还是稍微有些欠缺，生态不完整，例如地图、Im等组件的支撑缺失，这也是最终为什么直接采用原生oc和java开发了最早版本的findu。

然而，随着ai的发展，跨平台已经不再是一个主要的投入成本了。借助ai的能力可以快速复刻一个app到其他的平台，以前是点子不值钱，现在技术也不值钱了。跨平台唯一的好处仅剩下代码的可维护性，一套代码通吃各个平台，相对来说代码维护和bug修复的一致性会比多平台更加便捷。

可能这个发展偶尔也会有人会高喊暂停：

2026 年 8 月 11 日，美国参议员伯尼·桑德斯（Bernie Sanders）日前致信 OpenAI CEO Sam Altman、Anthropic CEO Dario Amodei 和 Meta CEO Mark Zuckerberg，要求三家公司暂停 AI 开发，并停止继续构建人类无法控制的 AI 系统。

至于暂停或者不暂停，现有的技术能力已经足够解决日常的技术问题和满足开发需求。也基于这种现有的技术能力，最近重新重构了findu，开发了新的portable claw。这里我想说的就是这个portable claw，借鉴之前的开发经验，想着一套代码解决所有问题，采用的架构依然是uniapp，不过不是uniappx。

按照uniapp 官方文档的说法，x其实是下一代，能达到原生的性能。我在开始的时候错误的评估了app在ios上对于性能的消耗，并且初期测试的时候主要也是基于ios模拟器测试，真机测试相对来说比较少，数据量也没有达到日常使用账号的数据量。导致对于app在ios真机上的性能过于乐观，数据量大了之后，会话窗口的绘制就成了一件痛苦的事情。

uni-app 在 iOS 真机上的瓶颈，不只是「聊天列表用了 WebView」。换成 nvue，只是把聊天 UI 从 WKWebView 换成 Weex 原生控件，业务、流式更新、页面栈、桥接仍在 JS 容器里。所以能减轻长列表掉帧，但到不了 Swift + UITableView 那种原生体验。

uni-app 在 iOS 真机上真正卡在哪

1. 双运行时一直同时活着

本项目 iOS 不是「整 App 都是 nvue」：

聊天：pages/chat/ios.nvue（Weex）
状态 / 设置 / 登录 / 订阅：仍是 Vue + WKWebView
业务宿主：stores/iosChatHost.js 挂在 App.vue 的 JS 服务层

chatRoutes.js 里写得很清楚：Vue 宿主和聊天 nvue 作为 subNVue 同时常驻，Tab 只挪 overlay。真机上等于：

一套 WKWebView（设置等）
一套 Weex（聊天）
一套 5+ Runtime / Pandora

内存、启动、Tab 切换都比单进程 UIKit 贵。Android 用 index.vue 还能凑合，iOS 对 WebView 和后台 WebContent 更狠，真机掉帧、杀进程都更明显。

2. 主路径仍是 JS：解析、裁剪、再塞回 UI

Gateway / Hermes 事件、历史、tool 卡、附件、TTS、权限，全部在 JS 里做。nvue 不能 import gatewayMedia、@noble/* 等，否则 Weex 白屏。于是每条流式更新都是：

JS 宿主算完 → cloneMessage 裁成短摘要 → uni.$emit 整份快照 → nvue 再 v-for 刷 <list>

原生工程则是：SSE 回调直接改 ChatMessage，UITableView 按行刷新。中间没有「整窗 JSON 快照」。

3. 聊天数据本身就重

长会话卡、空会话不卡，文档里已经定性：推给 nvue 的是「当前窗口」的完整 JSON，最后十几条常带着大段 tool 输出和 data: 图。你们被迫：

窗口大约 16 条，上限约 48
正文截断、不传 toolCards、不传 data: 预览
流式尽量 splice 一条，避免整表替换

这是在迁就 Weex 序列化 + 布局，不是产品想要的完整列表。原生 ChatTableView 可以按 cell 复用、按行测高，不必先把历史砍成摘要。

4. 5+ / Weex 桥是同步税

例如内购注释：不要和 StoreKit 弹窗同时触发 Weex 布局，否则会同步调 getSafeAreaInsets 卡住。真机上 plus.*、相册、文件、支付、安全区，都会在 JS 线程和主线程之间来回。原生是直接调系统 API。

5. Weex 不是 UIKit

<list> / <cell> 看起来像原生列表，实际是：

JS 虚拟 DOM → Weex 原生节点
能力子集（布局、富文本、手势冒泡都弱）
本页还用了 list-flip 倒序列表才能贴底，属于 Weex 滚动模型的绕路
Markdown、代码块、动态高度，Weex 测高和复用远不如 UITableView.automaticDimension

nvue 缓解了什么，为什么仍不够

nvue 确实缓解了「用 webview <scroll-view> 画几百条气泡」这一层：原生 view 绘制、有限回收、少一次 DOM/CSS。

它没有拿掉下面这些，所以仍然不是原生 App：

还在的成本	说明
双引擎	聊天 Weex + 其它页 WebView，Tab 常驻两套页面
快照协议	宿主和 nvue 用事件传 JSON，流式时反复 clone / emit / diff
瘦 UI	重逻辑不能进 Weex，热点路径仍在 JS
列表策略	必须截断、限窗，完整历史会把 `<list>` 打爆
容器	DCloud 基座、模块、plus、描述文件，启动和权限都比单 target Swift App 重
表达力	做不到原生那种 cell 精细复用、TextKit/AttributedString、键盘 inset、分屏

所以：nvue 是「聊天绘制层换引擎」，不是「App 换成原生」。瓶颈从「WebView 排版」变成「JS 宿主 + 跨运行时同步 + Weex 列表模型」。对 Agent 聊天这种高频流式、变高 cell、大 tool 输出的场景，第二套瓶颈一样会被打满。

和原生工程差在哪（同一产品）

原生 native_ios 是单一 Swift 进程：UITableView + 按条 merge、键盘按窗口算 inset、没有 uni.$emit 快照窗。uni-app 即使用 nvue，也还是「JS 算完再通知另一套 UI」。

一句话： nvue 能让短会话、轻气泡比纯 Vue 页跟手；真机长会话、流式、工具卡、多 Tab 同时在时，瓶颈在运行时架构，不在某一两个 CSS。要到原生手感，只能像现在这样离开 Weex/WebView，用 UIKit/SwiftUI 自己画列表。

以上内容是基于ai的总结，基本也就是这个情况，尤其是对于这种可变cell+列表的绘制，性能就更是问题了，哪怕独立出来nvue页面，js主进程还是会卡住其他的操作。

相反，在andorid设备上就不会存在这个性能瓶颈，虽然都是uniapp框架，在安卓设备上流畅度基本能达到原生的效果。

实际真机效果对比：

上面的视频是进入app之后，首先点了状态，后续其实又点了其他的tab页，但是此时已经卡死了。

上面的视频是基于swift的ios原生项目。

虽然页面功能一样，但是绘制的效果和性能却是天差地别。

当然，uni框架还有另外一个缺点就是，一些与系统打交道的东西还是需要原生插件支持，例如ios 的定位回调，ios的healthkit（闺蜜圈APP），安卓的各种系统设置等等，多数都是基于现有的uni插件来实现，所以，findu虽然是页面样式基础功能跨平台了，底层依然是基于原生的定位组件，系统操作组件，以及badge组件来堆起来了app的核心功能。

至于portable claw，则是需要tts引擎，很不幸baidu的tts引擎超过了200m，导致无法使用uni的云打包(打包也可以，交钱就行)。