Hybrid & 跨端 · 八股文高频版

1 Hybrid 架构总览

什么是 Hybrid App？和 Native、Web App 有什么区别？

三种模式的核心区别在于渲染引擎和系统能力访问方式：

Native App：原生语言开发（Swift/Kotlin），系统 API 直接调用，性能最优，但双端各写一套
Web App：浏览器中运行的 H5 页面，跨平台但无法调用系统能力（相机、推送等），受限于浏览器沙箱
Hybrid App：Native 壳 + WebView 承载 H5 页面，通过 JSBridge 调用系统能力。一套 H5 代码 + 两端薄壳，兼顾效率和体验

┌─────────────────────────────────────────────────┐
│              Native App Shell                    │
│  ┌───────────────────────────────────────────┐  │
│  │           WebView (H5 页面)                │  │
│  │                                           │  │
│  │   JS ←──── JSBridge ────→ Native API     │  │
│  │           (相机/推送/定位/存储)             │  │
│  └───────────────────────────────────────────┘  │
└─────────────────────────────────────────────────┘

适用场景：内容展示类页面（活动页、文章详情、设置页）用 H5；核心交互（首页 Feed、支付、拍照）用 Native。

Hybrid 开发的优缺点？

优点：跨平台一套代码、热更新不走应用商店审核、Web 生态丰富（UI 库 / 工具链）、开发效率高
缺点：WebView 性能不及 Native（长列表、复杂动画）、Bridge 通信有延迟、白屏问题（需首屏优化）、调试复杂（多层排查）
优化方向：离线包（预下载 H5 资源到本地）、预渲染 WebView（App 启动时预创建）、骨架屏、资源内联

2 WebView 通信机制

JSBridge 的原理是什么？有哪些实现方式？

JSBridge 是 H5 与 Native 双向通信的桥梁。核心问题：JS 运行在 WebView 沙箱中，无法直接调用系统 API。

JS → Native（H5 调用原生）

URL Scheme 拦截：H5 发起自定义协议请求（如 myapp://camera?callback=onPhoto），Native 的 WebView 拦截 shouldOverrideUrlLoading，解析协议执行对应逻辑
注入全局对象（主流方案）：Native 向 WebView 注入 JS 对象（Android addJavascriptInterface，iOS WKScriptMessageHandler），H5 直接调用 window.NativeBridge.method()
postMessage（iOS WKWebView）：window.webkit.messageHandlers.bridge.postMessage(data)

Native → JS（原生调用 H5）

直接执行 JS 代码：Android webView.evaluateJavascript("callback(data)")，iOS evaluateJavaScript
回调机制：H5 发请求时传 callbackId，Native 处理完后通过 evaluateJavascript 调用对应回调

// H5 端典型 JSBridge 封装
const callNative = (method, params) => {
  return new Promise((resolve) => {
    const callbackId = `cb_${Date.now()}_${Math.random()}`;
    window.__callbacks[callbackId] = (result) => {
      resolve(result);
      delete window.__callbacks[callbackId];
    };
    window.NativeBridge.invoke(
      JSON.stringify({ method, params, callbackId })
    );
  });
};

// 使用
const photo = await callNative('takePhoto', { quality: 0.8 });

WebView 性能优化有哪些手段？

WebView 预创建：App 启动时在后台初始化 WebView 实例，用户打开 H5 页面时直接复用，省去 WebView 初始化耗时（~300ms）
离线包：将 H5 静态资源（HTML/CSS/JS/图片）打包下发到客户端本地，WebView 拦截请求从本地读取，避免网络请求
预加载数据：Native 在创建 WebView 的同时并行请求 API 数据，通过 Bridge 传给 H5，减少白屏时间
公共资源包：Vue/React 运行时、公共 CSS 等抽成公共离线包，多个 H5 页面共享，减少包体积
增量更新：离线包只下发 diff 补丁（bsdiff），而非全量替换

3 跨端方案对比

主流跨端方案的技术选型对比？

方案            渲染方式          语言        性能    生态    场景
─────────────────────────────────────────────────────────────────
WebView/H5     浏览器渲染         HTML/JS     ★★     ★★★★★  内容页、活动页
React Native   原生组件桥接       JS/TS       ★★★★   ★★★★   中等复杂度 App
Flutter        自绘引擎(Skia)     Dart        ★★★★★  ★★★    高定制 UI、动画
Weex           原生组件桥接       Vue         ★★★    ★★     已停止维护
Uni-app        多端编译           Vue         ★★★    ★★★    小程序为主
Taro           多端编译           React       ★★★    ★★★    小程序为主
Electron       Chromium+Node      JS/TS       ★★     ★★★★★  桌面端

选型原则：团队技术栈（React → RN，Vue → Uni-app）、性能要求（动画密集 → Flutter）、平台覆盖（小程序 → Taro/Uni-app）、维护成本
没有银弹，大厂通常多方案混合：核心页面 Native、业务页面 RN/Flutter、营销页面 H5

React Native vs Flutter 如何选？

RN 优势：JS/TS 生态、热更新（CodePush）、前端团队零成本上手、npm 生态直接复用
RN 劣势：Bridge 通信瓶颈（新架构 JSI 已改善）、原生组件依赖多、长列表性能一般
Flutter 优势：自绘引擎不依赖原生组件，UI 一致性好、动画性能强、AOT 编译性能接近原生
Flutter 劣势：Dart 生态小、包体积大、热更新困难（不支持原生级热更新）、Web 端支持尚不成熟
选型建议：前端团队主导 → RN；追求极致 UI 一致性和性能 → Flutter；需要热更新 → RN

4 React Native 要点

RN 的渲染原理？新架构（Fabric + JSI）解决了什么？

旧架构（Bridge）

JS 线程 → JSON 序列化 → Bridge → 反序列化 → Native 线程。所有通信经过 Bridge 异步传输，高频交互（手势/动画）有明显延迟

新架构（2022+）

JSI（JavaScript Interface）：JS 直接持有 Native 对象的引用，不经过序列化，同步调用
Fabric：新的渲染系统，支持并发渲染（对齐 React 18）、同步布局测量
Turbo Modules：Native 模块按需懒加载，减少启动时间
Codegen：编译时生成类型安全的 JS↔Native 接口代码

RN 性能优化关键点？

长列表：FlatList / SectionList 替代 ScrollView，设置 getItemLayout 避免动态测量，windowSize 控制渲染窗口
减少重渲染：React.memo + useCallback；避免在 render 中创建新对象/函数
动画：Animated API 使用 useNativeDriver: true 将动画计算放到 Native 线程；复杂手势动画用 react-native-reanimated
图片：FastImage（缓存）、合理尺寸、WebP 格式
启动优化：减少 Bundle 体积（按需 import）、Hermes 引擎（字节码预编译，启动快 50%+）

5 Flutter 要点

Flutter 的渲染原理？为什么性能好？

Flutter 不使用平台原生组件，而是自己用 Skia/Impeller 引擎直接在 Canvas 上绘制 UI
三棵树：Widget Tree（配置描述）→ Element Tree（生命周期管理）→ RenderObject Tree（布局绘制）
Widget 是 immutable 的，rebuild 只是创建新的配置，Element 层做 diff 决定是否更新 RenderObject
AOT 编译为原生机器码（ARM），没有 JIT 或 Bridge 开销

Flutter 和 Native 怎么混合开发？

Platform Channel：Flutter ↔ Native 双向通信（MethodChannel / EventChannel / BasicMessageChannel）
Add-to-App：在现有 Native App 中嵌入 Flutter 页面（FlutterFragment / FlutterViewController），渐进式迁移
PlatformView：在 Flutter 中嵌入原生 View（如地图 SDK、WebView），有性能代价
大厂实践：闲鱼全面 Flutter；字节用 Flutter 做中台业务页面；美团用 Flutter + Native 混合栈

6 小程序架构

微信小程序的双线程架构是什么？

小程序将逻辑层（JS）和渲染层（WebView）分开在两个线程中运行，通过 Native 层中转通信。

┌──────────────┐     Native 层     ┌──────────────┐
│   渲染层       │  ←───────────→   │   逻辑层       │
│  WebView      │   setData 通信   │  JSCore       │
│  WXML + WXSS  │                  │  JS 逻辑      │
└──────────────┘                   └──────────────┘

为什么双线程？安全（JS 无法直接操作 DOM，防止恶意脚本）+ 性能（渲染不被 JS 阻塞）
代价：setData 是跨线程通信，数据需要序列化传输，频繁 setData 大数据量会卡顿
优化：减少 setData 频率和数据量、合并多次 setData、只传变化的字段路径（this.setData({ 'list[0].name': 'new' })）

Taro / Uni-app 这类跨端框架的原理？