移动端三技术栈优劣对比（理论推演）
本文是纯理论推演 / 脑测 ，不依赖实测数据，从技术原理层面分析三种方案的优劣。
实测结论见
05文档（APK 体积与内存）。
三个方案
| 方案 | 本质 | 代表作 |
|---|---|---|
| 纯 WebView 壳 | 原生 WebView 加载网页应用 | mybilibili-wap + 安卓壳 |
| Flutter | Dart AOT 编译，Skia/C++ 自绘引擎渲染 | mybilibili-app-flutter |
| NativeScript-Vue | JS 桥接原生控件，页面逻辑用 Vue 写 | mybilibili-ns |
一、从渲染原理看
WebView：页面是一棵浏览器的 DOM 树，由 Chromium（WebView）引擎解析 HTML/CSS/JS 渲染。所有 UI 都是"网页"，跑在完整的浏览器运行时上（Chromium 沙箱进程独立）。
Flutter ：不画原生控件，而是用一个 Skia 图形引擎自己把像素画到屏幕上。控件 = Dart 对象，布局/绘制全在自家引擎里。这导致 UI 与系统无关（所有平台长一样），但也意味着它"不认识"任何系统组件。
NativeScript ：JS 代码通过桥调用真实系统控件 （Android 就是 android.widget.*），Vue 模板负责声明式组织，控件本体全是系统的。
一句话：WebView 是"浏览器里的网页"，Flutter 是"自绘引擎画的画"，NS 是"JS 指挥原生态系统控件"。
二、开发效率
| 维度 | WebView | Flutter | NativeScript |
|---|---|---|---|
| 技术栈 | HTML/CSS/JS + Vue。前后端统一，几乎零学习成本 | 需学 Dart。布局/写法特殊，坑多 | 复用 Vue 经验，模板开发 |
| 热更新 | 纯网页，网页改完刷新即生效，最快 | 有 hot reload 但重布局常失效 | 有热重载，但经常要重编译 |
| UI 编写速度 | 网页 CSS 反馈即所得，最快 | Widget 树啰嗦，嵌套深 | 模板 + 样式，接近网页 |
| 调试 | 浏览器 DevTools 全家桶碾压 | Dart DevTools 一般 | 需连原生日志，最麻烦 |
| 团队门槛 | 任何前端都能写 | 要专门学 Flutter | 前端 + 懂点原生 |
结论：WebView 开发效率最高（纯前端），NS 次之（复用 Vue），Flutter 最低（新语言新范式）。
二点五、实测数据备注
本节之后所有表格均基于理论推演；本次 Waydroid 容器内的实测参考数据（详情见
05）如下：
| 指标 | WebView | Flutter | NativeScript |
|---|---|---|---|
| APK 体积（实测） | 5.7 MB | 37 MB | 101 MB |
| 运行时内存 PSS（实测） | 主进程 137MB + Chromium 沙箱 95MB = 232 MB | 81 MB（单进程） | 134 MB（单进程） |
对照结论（理论 vs 实测）：
- 包体积趋势与理论完全一致：壳最小、NS 最大，且实际差距比想象更极端（4.5MB vs 101MB）。
- 内存趋势与理论基本一致：Flutter 最低、NS 居中、WebView 最高------WebView 的高内存完全来自独立的 Chromium 渲染进程。
- 注意：以上为 Waydroid (x86_64) 上的 debug/Debug 构建参考值。NS 的 101MB 是 debug 包含完整 JS 引擎 + 全部平台库，release + 混淆后体积会有不同；Flutter 37MB 也非最终 release 优化值。真实发布体积需按产品环境重新构建后复测。
三、最终安装包与冷启动
| WebView | Flutter | NativeScript | |
|---|---|---|---|
| APK 体积 | 极小（壳 + WebView 引用，实测 5.7MB） | 中（引擎 + 库，实测 37MB） | 大（完整 JS 引擎 + 编译产物，实测 101MB） |
| 冷启动 | 快（壳立即起）但首屏要等网页加载 | 中（先起 Dart VM） | 中（先起 V8 桥） |
| 依赖分发 | 逻辑全在服务端/远程，本地几乎无依赖 | 全部打进 APK | 全部打进 APK |
关键讽刺点：WebView 壳本地最小，但真正干活的是系统里那个巨大的 Chromium（WebView），APK 小不代表运行时小。
四、运行时内存与流畅度
| WebView | Flutter | NativeScript | |
|---|---|---|---|
| 运行时开销 | Chromium 独立沙箱进程，天然内存大户（实测 232MB） | 引擎 + 自绘纹理，可控（实测 81MB） | 原生控件 + V8 桥，居中（实测 134MB） |
| 滚动/列表 | 依赖浏览器渲染，WebView 版本差异大 | 自绘列表虚拟化好（ListView.builder） | 原生 RecyclerView，拖列表最稳 |
| 长列表万级数据 | DOM 节点多，会卡 | 虚拟化，稳 | 虚拟化，最稳 |
| 视频播放 | hls.js 软解，发热 | 原生播放器硬解最省电 | 需接原生播放器或用 WebView 嵌入 |
| 弹幕/复杂动画 | Canvas，帧率依赖 JS | 自绘动画强 | 生态少，要手写 |
五、UI 准确度 / 与系统的契合度
| WebView | Flutter | NativeScript | |
|---|---|---|---|
| 控件一致性 | 网页仿控件，和系统不一致 | 全部自绘，各平台表现一致 | 直接用系统控件，100% 一致 |
| 输入法/键盘 | 网页 input，键盘弹出常有布局错位 | 自绘 TextField，偶有光标问题 | 原生控件，与系统输入法无缝 |
| 深色模式 | CSS 媒体查询手动适配 | 需手动监听 | 原生自动跟随 |
| 无障碍 | 依赖网页语义，支持弱 | 需自实现，易漏 | 原生自带，开箱即用 |
| 系统字体/通知栏 | 无控制权 | 可控制但边缘案例多 | 全系统级 |
| 沉浸式/炫酷自定义 UI | 网页动画无上限，最自由 | 自绘可玩出花，自由度第二 | 受限于系统控件，自由最低 |
六、跨平台潜力
| WebView | Flutter | NativeScript | |
|---|---|---|---|
| iOS | 同一个站点直接跑（WKWebView） | 一套代码几乎零改 | 需要 iOS 原生桥，改动大 |
| 桌面/小程序 | 网页天生通吃 | Flutter 桌面已成熟 | 基本不做桌面 |
| 一套代码通用性 | 最强（本来就是网页） | 强 | 弱（偏 Android） |
若未来要出 iOS，WebView 最省事（同一站点），Flutter 次之（同一套 Dart），NS 最吃力。
七、长期维护与生态
| WebView | Flutter | NativeScript | |
|---|---|---|---|
| 生态成熟度 | 极大（web 全生态） | 大（Google 亲儿子，官方活跃） | 弱（社区小，已停止激进迭代，转 Capacitor） |
| 风险 | WebView 版本碎片化 | 稳 | 官方已转向 Capacitor/ArkUI，Vue 版维护停滞 |
| 第三方库 | 前端任何库都能用，最全 | 有 pub.dev，够用 | 少，常要自己写原生桥 |
八、结论（按场景选）
- 要快、要低成本、团队全是前端、不追求极致系统体验 → 纯 WebView 壳。开发最快、维护最省、站还能复用给 iOS/PC。
- 要性能、要炫丽自定义 UI、要跨平台一致 → Flutter。自绘引擎上限高，官方长期维护。
- 要大列表极流畅、要 100% 原生系统交互、且只做 Android → NativeScript。原生控件最强，但要接受其生态已趋于停滞的现实风险和较大的包体积。
综合建议 ：本项目（B 站类视频信息流）若重来一次，理想折中其实是 WebView 做壳 + 原生 WebView 替换为纯网页内核的 TWA ，或 Flutter 一步到位------前者稳、后者上限高。NS 处于"性能有优势但生态悬空"的尴尬位。