在前面11篇文章中，我们从调试、通信、性能优化、兼容性一路聊到了安全防护和离线包方案。这些都是在「已有WebView用法」基础上做优化。但有一个更底层的问题一直没正面回答：当你的App里WebView页面从十几个增长到上百个，当H5业务从简单展示演进到复杂交易流程，当初那种「一个Activity包一个WebView」的写法还能撑住吗？

答案显然是不能。我们团队在H5页面数突破50个的时候，就明显感受到了架构腐化的味道：JSBridge到处复制粘贴、WebView内存居高不下、页面跳转逻辑散落在各个Activity里、新接入一个H5页面要改四五个地方。最后不得不做了一次彻底的架构重构。

今天这篇文章，就来聊聊WebView混合开发的架构设计——从容器化到插件化，从单WebView到多WebView管理，从"能跑就行"到"可维护、可扩展、可演进"。

一、架构演进的四个阶段

先说结论：混合开发架构不是一步到位的，它是随着业务规模逐步演进的。我们经历过的路径大概是这样的：

阶段1: 简单嵌入（0-10个H5页面）
  └─ 每个页面一个Activity/VC + WebView，JSBridge直接写在页面里

阶段2: 容器化（10-50个H5页面）
  └─ 统一WebView容器，JSBridge标准化，URL路由统一管理

阶段3: 插件化（50-200个H5页面）
  └─ H5业务模块像插件一样动态注册，独立发布，按需加载

阶段4: 平台化（200+个H5页面）
  └─ 完整的H5运行平台，支持灰度、降级、A/B、多容器切换

大部分团队到阶段2就够用了，少数业务复杂的（比如电商、金融类App）需要走到阶段3。阶段4属于基建级别，本文不过度展开，重点放在阶段2和阶段3的落地。

二、容器化设计：统一WebView容器

2.1 为什么需要统一容器

在阶段1，每个H5页面对应一个Native页面，每个Native页面里都自己初始化WebView、注册JSBridge、处理生命周期。问题很快暴露：

• JSBridge重复注册：10个页面写了10遍addJavascriptInterface，改一个接口要改10个地方
• 配置不统一：有的页面开了缓存，有的没开；有的设置了UA，有的没设
• 生命周期管理混乱：WebView的onPause/onResume/onDestroy有的页面忘了调，内存泄漏频发
• 无法做全局拦截：想在所有H5页面加一个通用的登录态校验，没地方插手

2.2 容器核心设计

统一容器的核心思想是：所有H5页面共享同一个Native壳子，差异通过配置来描述。

┌──────────────────────────────────────────────┐
│              HybridActivity / VC              │
│  ┌──────────────────────────────────────────┐ │
│  │           WebViewContainer                │ │
│  │  ┌────────────┐  ┌────────────────────┐  │ │
│  │  │  WebView   │  │  BridgeManager     │  │ │
│  │  │  (复用池)   │  │  (标准化桥接)       │  │ │
│  │  └────────────┘  └────────────────────┘  │ │
│  │  ┌────────────┐  ┌────────────────────┐  │ │
│  │  │  NavManager│  │  ConfigManager     │  │ │
│  │  │  (导航控制) │  │  (页面配置)         │  │ │
│  │  └────────────┘  └────────────────────┘  │ │
│  └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────┘

容器配置化打开页面：

// 定义页面配置
data class WebPageConfig(
    val url: String,
    val title: String = "",
    val showNavBar: Boolean = true,
    val enableRefresh: Boolean = false,
    val bridgeModules: List<String> = listOf("common"),  // 按需注册桥接模块
    val interceptLogin: Boolean = true,  // 是否拦截登录态
    val webViewTag: String = ""  // WebView池中的标记
)

// 统一入口
object HybridNavigator {
    
    fun open(context: Context, config: WebPageConfig) {
        val intent = Intent(context, HybridActivity::class.java).apply {
            putExtra("config", config.toJson())
        }
        context.startActivity(intent)
    }
}

// 调用方只需关心URL和配置
HybridNavigator.open(this, WebPageConfig(
    url = "https://m.example.com/mall/detail?id=123",
    title = "商品详情",
    bridgeModules = listOf("common", "share", "pay"),
    interceptLogin = true
))

这样，打开H5页面不再是"写一个新Activity"，而是"写一个配置"。新增页面零成本，修改全局行为改容器一处即可。

2.3 JSBridge标准化

容器化之后最关键的一步是JSBridge的标准化。之前各页面各写各的桥接，现在要统一成一套规范。

我的做法是把Bridge按模块组织，每个模块是一个独立类，容器启动时按配置注册：

// Bridge模块接口
interface BridgeModule {
    val name: String  // 模块名，如 "share", "pay", "device"
    val handlers: Map<String, BridgeHandler>  // 该模块下的所有方法
}

interface BridgeHandler {
    fun handle(params: JSONObject, callback: BridgeCallback)
}

// 示例：分享模块
class ShareBridgeModule : BridgeModule {
    override val name = "share"
    override val handlers = mapOf(
        "shareToWechat" to ShareToWechatHandler(),
        "shareToQQ" to ShareToQQHandler()
    )
}

// Bridge管理器
class BridgeManager(private val webView: WebView) {
    
    private val modules = mutableMapOf<String, BridgeModule>()
    
    fun registerModule(module: BridgeModule) {
        modules[module.name] = module
        // 注入到WebView的JS环境
        injectModuleToJS(module)
    }
    
    fun registerModules(moduleNames: List<String>) {
        val availableModules = moduleRegistry.filter { it.name in moduleNames }
        availableModules.forEach { registerModule(it) }
    }
    
    // Native端接收JS调用的统一入口
    fun onJsCall(moduleName: String, methodName: String, params: String, callbackId: String) {
        val module = modules[moduleName] ?: run {
            callbackError(callbackId, "Module not found: $moduleName")
            return
        }
        val handler = module.handlers[methodName] ?: run {
            callbackError(callbackId, "Method not found: $methodName")
            return
        }
        handler.handle(JSONObject(params), BridgeCallback(webView, callbackId))
    }
}

H5端调用方式：

// H5端统一调用接口
const Bridge = {
    call(module, method, params = {}) {
        return new Promise((resolve, reject) => {
            const callbackId = `cb_${Date.now()}_${Math.random().toString(36).slice(2)}`
            window.__bridge_callbacks[callbackId] = { resolve, reject }
            
            // 标准化消息格式
            window.__nativeBridge?.postMessage(JSON.stringify({
                module,
                method,
                params,
                callbackId
            }))
        })
    }
}

// 使用
const result = await Bridge.call('share', 'shareToWechat', {
    title: '分享标题',
    url: 'https://example.com'
})

踩坑提醒：JSBridge的标准化一定要做版本协商。我们早期没做这个，结果Native端升级了接口参数，线上老版本的H5还在调旧参数，直接炸了。解决方案是Bridge初始化时交换版本号，Native端做向下兼容：

// Bridge初始化时注入版本信息
private fun injectBridgeVersion() {
    val versionInfo = JSONObject().apply {
        put("bridgeVersion", BRIDGE_VERSION)
        put("supportedModules", modules.keys.joinToString(","))
        put("features", JSONObject().apply {
            put("promiseBasedCall", true)  // 标记支持Promise回调
        })
    }
    webView.evaluateJavascript(
        "window.__bridge_info = $versionInfo", null
    )
}

三、路由与分发机制

容器化之后，所有H5页面走同一个Activity，那页面间的跳转怎么管理？URL路由就是答案。

3.1 URL路由设计

核心思路：所有H5页面的打开、关闭、跳转都通过URL路由中心调度。

┌─────────────┐    ┌──────────────┐    ┌──────────────┐
│  Native跳转  │───▶│              │───▶│  HybridAct   │
│  (Push消息等) │    │  URL Router  │    │  (打开H5页面)  │
└─────────────┘    │              │    └──────────────┘
┌─────────────┐    │  - 协议识别    │    ┌──────────────┐
│  H5跳转      │───▶│  - 参数解析    │───▶│  Native页面   │
│  (a标签/JS)  │    │  - 权限校验    │    │  (原生页面)    │
└─────────────┘    │  - 拦截器链    │    └──────────────┘
                   └──────────────┘    ┌──────────────┐
                                       │  外部浏览器    │
                                       │  (兜底方案)    │
                                       └──────────────┘

object HybridRouter {
    
    // 拦截器链
    private val interceptors = mutableListOf<RouteInterceptor>()
    
    fun navigate(context: Context, url: String) {
        val route = parseRoute(url) ?: return
        
        // 执行拦截器链
        for (interceptor in interceptors) {
            if (!interceptor.intercept(context, route)) {
                return  // 被拦截，不再继续
            }
        }
        
        // 分发路由
        when (route.scheme) {
            "native" -> navigateNative(context, route)
            "https", "http" -> navigateHybrid(context, route)
            else -> openBrowser(context, url)  // 兜底：外部浏览器
        }
    }
    
    private fun parseRoute(url: String): Route? {
        // 统一解析各种协议的URL
        // native://user/profile?id=123
        // https://m.example.com/mall/detail?id=123
        return RouteParser.parse(url)
    }
}

// 常用拦截器
class LoginInterceptor : RouteInterceptor {
    override fun intercept(context: Context, route: Route): Boolean {
        if (route.requireLogin && !UserManager.isLoggedIn()) {
            // 跳转登录，登录后回调继续
            LoginActivity.startWithCallback(context) {
                HybridRouter.navigate(context, route.originalUrl)
            }
            return false
        }
        return true
    }
}

class ABTestInterceptor : RouteInterceptor {
    override fun intercept(context: Context, route: Route): Boolean {
        // 根据AB实验决定路由到哪个页面
        route.url = ABTestManager.getVariantUrl(route.url)
        return true
    }
}

3.2 H5页面内跳转的拦截

H5页面内部的跳转（比如点击<a>标签）需要在Native端统一拦截，避免WebView自己处理导致页面在WebView内跳走：

override fun shouldOverrideUrlLoading(view: WebView, request: WebResourceRequest): Boolean {
    val url = request.url.toString()
    
    // 交给路由中心统一处理
    return HybridRouter.navigate(view.context, url)
}

踩坑提醒：这里有个容易忽略的点——H5页面中使用window.location跳转时，有些场景下shouldOverrideUrlLoading不会触发（比如通过JS的location.assign）。需要同时在JS层做拦截：

// H5端路由拦截 - 劫持location跳转
const originalAssign = window.location.assign.bind(window.location)
window.location.assign = function(url) {
    if (Bridge.isAvailable()) {
        Bridge.call('router', 'navigate', { url })
    } else {
        originalAssign(url)
    }
}

四、多WebView管理与内存控制

这是混合架构中最容易被低估的部分。单个WebView的内存占用在60-120MB，如果你每个页面都新建一个WebView，打开5个页面就是300-600MB，低端机直接OOM。

4.1 WebView池设计

核心思路：预先创建WebView，用完不销毁，回收到池中复用。

class WebViewPool(private val context: Context) {
    
    private val maxPoolSize = 3  // 池中最多保留3个
    private val available = ConcurrentLinkedQueue<WebView>()
    private val inUse = mutableSetOf<WebView>()
    
    @Synchronized
    fun obtain(): WebView {
        // 优先从池中取
        val webView = available.poll() ?: createNewWebView()
        inUse.add(webView)
        return webView
    }
    
    @Synchronized
    fun recycle(webView: WebView) {
        if (!inUse.remove(webView)) return
        
        // 清理WebView状态
        webView.loadUrl("about:blank")
        webView.clearHistory()
        webView.clearCache(false)
        
        // 注销所有JSBridge回调
        BridgeManager.detachFrom(webView)
        
        if (available.size < maxPoolSize) {
            available.offer(webView)
        } else {
            destroyWebView(webView)
        }
    }
    
    private fun createNewWebView(): WebView {
        return WebView(context.applicationContext).apply {
            // 统一初始化配置
            settings.javaScriptEnabled = true
            settings.domStorageEnabled = true
            settings.cacheMode = WebSettings.LOAD_DEFAULT
            // ... 其他统一配置
        }
    }
    
    private fun destroyWebView(webView: WebView) {
        webView.stopLoading()
        webView.settings.javaScriptEnabled = false
        webView.removeAllViews()
        // 关键：从ViewTree中移除，否则无法GC
        (webView.parent as? ViewGroup)?.removeView(webView)
        webView.destroy()
    }
}

4.2 页面栈与WebView复用策略

实际业务中，H5页面之间经常有跳转关系，比如「列表页→详情页→下单页」。这里有三种策略：

策略一：单WebView + 历史栈（推荐大多数场景）

• 只用一个WebView，利用浏览器自身的历史栈管理前进后退
• 优点：内存占用最小
• 缺点：无法同时保持多个页面的状态（比如列表页的滚动位置）

策略二：多WebView栈（需要保留页面状态的场景）

• 每个新页面创建一个WebView，回退时销毁
• 优点：每个页面状态独立保持
• 缺点：内存压力大，需要严格控制栈深度

策略三：混合模式（我们最终采用的方案）

• 主流程用单WebView，需要保持状态的页面单独开WebView
• 栈深度超过阈值时，自动回收最早的WebView

class WebViewStackManager {
    
    private val stack = mutableListOf<WebViewStackEntry>()
    private val maxStackSize = 4  // 最多同时存在4个WebView
    
    data class WebViewStackEntry(
        val webView: WebView,
        val url: String,
        val createdAt: Long,
        val shouldKeepAlive: Boolean  // 是否需要保持状态
    )
    
    fun push(entry: WebViewStackEntry) {
        stack.add(entry)
        
        // 超过阈值，回收不需要保活的
        if (stack.size > maxStackSize) {
            val recyclable = stack
                .filter { !it.shouldKeepAlive }
                .minByOrNull { it.createdAt }
            recyclable?.let {
                stack.remove(it)
                webViewPool.recycle(it.webView)
            }
        }
    }
    
    fun pop(): WebViewStackEntry? {
        return if (stack.isNotEmpty()) stack.removeAt(stack.lastIndex) else null
    }
}

4.3 内存泄漏的排查与修复

多WebView场景下的内存泄漏是个顽疾，常见的泄漏点：

1）WebView持有Activity Context

这是最经典的泄漏。WebView内部会持有Context引用，如果传的是Activity，Activity就泄漏了。

// ❌ 错误写法
val webView = WebView(activity)

// ✅ 正确写法：使用ApplicationContext + 动态补充Activity引用
val webView = WebView(activity.applicationContext)
// 需要Activity Context的场景（如弹窗），通过弱引用注入

2）JS回调持有WebView引用

// ❌ 错误写法：匿名内部类持有外部WebView引用
webView.evaluateJavascript("...", ValueCallback { result ->
    // 这个回调持有外部类的引用，可能阻止GC
    webView.loadData(result, "text/html", "utf-8")
})

// ✅ 正确写法：使用弱引用
class SafeValueCallback(webView: WebView) : ValueCallback<String> {
    private val weakWebView = WeakReference(webView)
    override fun onReceiveValue(value: String?) {
        weakWebView.get()?.loadData(value ?: "", "text/html", "utf-8")
    }
}

3）Bridge回调未清理

页面关闭时，如果有未完成的JSBridge调用，回调对象会持有WebView引用。必须在Activity的onDestroy中清理：

override fun onDestroy() {
    bridgeManager.clearAllPendingCallbacks()  // 清理所有待处理的回调
    webViewStackManager.pop()?.let {
        webViewPool.recycle(it.webView)
    }
    super.onDestroy()
}

五、插件化架构：H5业务模块动态管理

当H5页面多到一定规模，你会遇到新的问题：所有H5页面打包在一起，任何一个页面的改动都要跟着App发版。我们需要让H5业务模块独立注册、独立发布、按需加载。

5.1 插件注册表

// H5业务模块定义
data class H5Plugin(
    val id: String,                    // 模块唯一标识，如 "mall", "finance"
    val entryUrl: String,              // 入口URL
    val bridgeModules: List<String>,   // 需要的Bridge模块
    val offlinePackage: String?,       // 关联的离线包名（可选）
    val version: String,               // 模块版本
    val requireLogin: Boolean,         // 是否需要登录
    val interceptors: List<String>,    // 路由拦截器列表
    val keepAlive: Boolean = false     // 是否保持WebView状态
)

// 插件注册中心
object PluginRegistry {
    
    private val plugins = ConcurrentHashMap<String, H5Plugin>()
    
    // 从远程配置中心拉取插件列表
    fun syncFromServer() {
        val remoteConfig = ConfigService.getH5Plugins()
        remoteConfig.forEach { plugin ->
            plugins[plugin.id] = plugin
        }
    }
    
    // 动态注册插件（也可以本地硬编码兜底）
    fun register(plugin: H5Plugin) {
        plugins[plugin.id] = plugin
    }
    
    fun get(id: String): H5Plugin? = plugins[id]
    
    // 根据URL匹配插件
    fun matchByUrl(url: String): H5Plugin? {
        return plugins.values.find { url.contains(it.entryUrl) }
    }
}

5.2 插件化打开页面

// 打开H5页面时，自动匹配插件配置
fun openPluginPage(context: Context, pluginId: String, params: Map<String, Any> = emptyMap()) {
    val plugin = PluginRegistry.get(pluginId) ?: run {
        // 插件未注册，走兜底逻辑
        Toast.makeText(context, "页面暂未开放", Toast.LENGTH_SHORT).show()
        return
    }
    
    // 构建页面配置
    val config = WebPageConfig(
        url = plugin.entryUrl.appendParams(params),
        bridgeModules = plugin.bridgeModules,
        interceptLogin = plugin.requireLogin,
        webViewTag = plugin.id,
        showNavBar = true
    )
    
    // 如果有关联的离线包，预加载
    plugin.offlinePackage?.let {
        OfflinePackageManager.preload(it)
    }
    
    HybridNavigator.open(context, config)
}

插件化的关键收益：业务团队只需维护自己的H5Plugin配置和离线包，不关心Native容器怎么实现。新业务接入从"改4-5个文件"变成"提一个JSON配置"。

六、原生与H5的职责边界

架构设计中最容易纠结的问题：这个功能放Native做还是H5做？边界不清晰，就会出现"Native里嵌H5，H5里又调Native"的套娃情况。

我的原则很简单：

能力	归属	理由
导航栏	Native	性能、一致性、原生交互
登录态	Native	安全性、Token管理
网络请求	混合	H5处理业务请求，Native处理鉴权请求
文件操作	Native	权限控制、跨页面共享
页面路由	Native	统一调度、拦截器、降级
UI渲染	H5为主	灵活性、动态更新
支付	Native	安全性、合规要求
分享	Native	SDK集成、平台适配
数据存储	混合	H5用localStorage，Native提供跨页面共享存储
推送	Native	系统级能力

一个关键约定：H5页面不应该直接感知Native的页面栈。H5需要跳转时，统一通过Bridge通知Native，由Native的路由中心决定是开新WebView还是跳原生页面。这避免了H5页面"越权"管理Native导航的问题。

七、实战踩坑总结

7.1 多WebView内存失控

场景：电商App的商品详情页，用户可能连续点开5-6个商品，每个商品打开一个WebView，内存直接飙到800MB。

解决方案：

• 栈深度限制4个，超过后自动回收最早的WebView
• 回收前保存页面URL和关键状态（滚动位置、表单数据），用户回退时恢复
• 在onStop时对非活跃WebView执行webView.onPause()释放内核资源

// 非活跃WebView的内存优化
fun onWebViewInBackground(webView: WebView) {
    webView.onPause()
    // 释放WebView的JS执行上下文（谨慎使用，会导致定时器暂停）
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
        webView.webViewClient = object : WebViewClient() {
            override fun onPageFinished(view: WebView?, url: String?) {
                view?.evaluateJavascript(
                    "try { window.stop(); } catch(e) {}", null
                )
            }
        }
    }
}

7.2 JSBridge版本兼容

场景：Native 3.2版本新增了pay.fingerprintPay接口，但线上还有3.1的App在跑，H5调用这个接口直接报错。

解决方案：H5端调用前先检查能力是否存在：

// H5端安全调用
async function safeBridgeCall(module, method, params) {
    // 检查模块是否存在
    if (!window.__bridge_info?.supportedModules?.includes(module)) {
        throw new Error(`Module ${module} not available`)
    }
    
    // 检查方法是否存在（通过一次ping调用）
    const moduleInfo = await Bridge.call(module, '__ping__', {})
    if (!moduleInfo.methods?.includes(method)) {
        // 降级到备用方案
        return fallbackHandler(module, method, params)
    }
    
    return Bridge.call(module, method, params)
}

7.3 页面栈管理混乱

场景：H5页面A跳原生页面B，B又跳H5页面C，C点返回应该回B还是回A？不同开发者的理解不一样。

解决方案：统一页面栈模型，所有页面（Native和H5）都在同一个栈中管理：

// 统一页面栈
class AppPageStack {
    
    private val stack = mutableListOf<StackEntry>()
    
    data class StackEntry(
        val type: PageType,  // NATIVE or HYBRID
        val identifier: String,
        val data: Bundle?
    )
    
    fun push(entry: StackEntry) {
        stack.add(entry)
    }
    
    fun pop(): StackEntry? {
        return if (stack.isNotEmpty()) stack.removeAt(stack.lastIndex) else null
    }
    
    // 关键：处理H5返回键
    fun handleBackPress(activity: HybridActivity): Boolean {
        val webView = activity.getCurrentWebView()
        
        // WebView有历史记录，先回退Web历史
        if (webView.canGoBack()) {
            webView.goBack()
            return true
        }
        
        // Web历史回退完毕，回退Native栈
        pop()
        activity.finish()
        return true
    }
}

7.4 容器配置冲突

场景：不同H5页面需要不同的WebView设置（有的需要缩放，有的禁用；有的需要定位，有的不需要），但容器是共享的。

解决方案：在页面配置中声明Setting差异，容器打开页面时动态应用：

data class WebViewSettingOverride(
    val supportZoom: Boolean? = null,
    val geolocationEnabled: Boolean? = null,
    val userAgentSuffix: String? = null,
    val cacheMode: Int? = null
)

// 容器中应用配置
fun applySettings(webView: WebView, override: WebViewSettingOverride) {
    override.supportZoom?.let { webView.settings.setSupportZoom(it) }
    override.geolocationEnabled?.let { 
        webView.settings.setGeolocationEnabled(it) 
    }
    override.userAgentSuffix?.let { suffix ->
        webView.settings.userAgentString = webView.settings.userAgentString + " " + suffix
    }
    override.cacheMode?.let { webView.settings.cacheMode = it }
}

八、架构整体视图

把上面所有模块串起来，最终的混合开发架构长这样：

┌─────────────────────────────────────────────────────────────┐
│                        业务层                                │
│  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐         │
│  │ 商城  │  │ 金融  │  │ 社区  │  │ 活动  │  │ ...  │         │
│  │Plugin│  │Plugin│  │Plugin│  │Plugin│  │      │         │
│  └──┬───┘  └──┬───┘  └──┬───┘  └──┬───┘  └──────┘         │
├─────┼─────────┼─────────┼─────────┼───────────────────────┤
│     │    插件注册表 / 路由中心  │         │   框架层              │
│     └─────────┴─────┬─────┴─────────┘                      │
│                     ▼                                        │
│  ┌──────────────────────────────────────────────────────┐  │
│  │              HybridContainer (统一容器)                │  │
│  │  ┌───────────┐ ┌──────────┐ ┌──────────────────────┐ │  │
│  │  │WebViewPool│ │BridgeMgr │ │  NavManager          │ │  │
│  │  │(复用/回收) │ │(标准化)   │ │  (页面栈/返回键)      │ │  │
│  │  └───────────┘ └──────────┘ └──────────────────────┘ │  │
│  │  ┌───────────┐ ┌──────────┐ ┌──────────────────────┐ │  │
│  │  │SettingMgr │ │Interceptor│ │  OfflinePkgManager   │ │  │
│  │  │(动态配置)  │ │Chain(拦截) │ │  (离线包管理)         │ │  │
│  │  └───────────┘ └──────────┘ └──────────────────────┘ │  │
│  └──────────────────────────────────────────────────────┘  │
├────────────────────────────────────────────────────────────┤
│                     基础层                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │ 性能监控  │  │ 安全防护  │  │ 日志体系  │  │ 崩溃收集  │  │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
└────────────────────────────────────────────────────────────┘

九、给正在踩坑的同行几点建议

1. 别急着上插件化。如果你的H5页面不超过30个，容器化就够用了。插件化引入的复杂度（远程配置、版本管理、降级策略）不小，ROI不一定高。

2. WebView池要趁早做。我们是在线上OOM了3次之后才痛下决心做的，早点做能省很多事故复盘的时间。池的大小根据目标设备的内存上限来定，一般3-4个就够了。

3. JSBridge标准化是地基。无论你用哪种架构，Bridge标准化都是第一步。因为Bridge一旦散落各处，后续所有统一化改造都无从下手。建议第一版就定好模块化规范。

4. 页面栈模型要统一。Native页面和H5页面在同一个栈里管理，返回键的行为才能一致。这个如果一开始没想清楚，后面改动成本极高。

5. 留好降级通道。任何架构方案都要有降级方案——容器初始化失败时能直接用系统WebView打开URL，Bridge调用失败时H5有fallback逻辑，离线包加载失败时能走在线加载。没有降级方案的架构，上线后一定会翻车。

---

混合开发的架构设计本质上是用规范对抗复杂度。当你把容器、路由、Bridge、页面栈这些核心机制标准化之后，新增一个H5页面就从"改半天代码"变成了"提一个配置"。这不仅是开发效率的提升，更是整个团队协作方式的升级——H5团队专注业务逻辑，Native团队专注底层能力，双方通过标准化的Bridge协议协作，互不阻塞。

这个系列写到这里，WebView的核心技术话题基本覆盖了。从调试排查到架构设计，从性能优化到安全防护，每一篇都是实战中摸爬滚打出来的经验。希望这些内容能帮到正在做混合开发的同行们少踩一些坑。