深入解析 Chrome 渲染进程合并优化策略：以 desktop_view 为例

一、引言：为什么要优化渲染进程？

在 Chromium 浏览器中，每个渲染进程都占用相当可观的内存资源（通常 50-200MB）。对于功能丰富的浏览器如 xxx浏览器，打开多个标签页或特殊 WebUI 页面时，进程数量可能迅速膨胀，导致内存占用过高、系统响应变慢。

本文将以 chrome://desktop_view 这个特殊 WebUI 页面的优化为例，深入探讨如何通过渲染进程合并策略来显著降低内存占用，同时保持功能完整性。

二、Chrome 多进程架构回顾

在深入优化策略前，我们需要理解 Chrome 的进程模型：

复制代码

┌─────────────────────────────────────────────┐
│           Browser Process (1个)              │
│  - UI 线程、网络线程、存储线程等              │
└─────────────────────────────────────────────┘
         │              │              │
         ↓              ↓              ↓
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Renderer    │ │ Renderer    │ │ Renderer    │
│ Process 1   │ │ Process 2   │ │ Process 3   │
│ (tab A)     │ │ (tab B)     │ │ (tab C)     │
└─────────────┘ └─────────────┘ └─────────────┘

2.1 进程隔离机制

Chrome 的 Site Isolation 特性会将不同站点的页面隔离到不同进程：

复制代码

// 默认行为：不同站点使用不同进程
https://google.com  → Process A
https://facebook.com → Process B
chrome://settings   → Process C

这种设计带来安全性提升，但也增加了进程数量。

2.2 备用渲染进程（Spare Renderer）

Chrome 会预创建备用渲染进程来加速页面加载：

复制代码

// Chrome 源码：预先创建空闲进程
void SpareRenderProcessHostManager::MaybeStartSpare() {
  if (!spare_process_ && ShouldHaveSpare()) {
    spare_process_ = RenderProcessHost::CreateSpareProcess();
  }
}

三、优化目标：desktop_view 的特殊性

chrome://desktop_view 是 xxx 浏览器扩展的 WebUI 页面，具有以下特点：

用户可能同时打开多个实例
页面间有频繁的通信需求
对启动速度要求不高，但对内存占用敏感
包含大量 iframe 子页面

优化目标 ：将多个 desktop_view 页面合并到同一渲染进程，减少 50% 以上的内存占用。

四、核心优化策略详解

4.1 策略一：禁用备用渲染进程

问题：Chrome 会为 desktop_view 预创建备用进程，但该页面有特殊配置要求，不适合使用预创建进程。

解决方案 ：在 ShouldUseSpareRenderProcessHost 函数中拦截。

复制代码

// chrome/browser/chrome_content_browser_client.cc

bool ChromeContentBrowserClient::ShouldUseSpareRenderProcessHost(
    Profile* profile,
    const GURL& site_url) {
  
#ifdef USE_HACK
  // 禁用 desktop_view 的备用渲染进程
  // 原因：desktop_view 需要特殊进程配置，预创建的进程不符合要求
  if (IsDesktopViewWebUIURL(site_url)) {
    return SpareProcessRefusedByEmbedderReason::DefaultDisabled;
  }

  // 同样处理 xxx 内嵌扩展
  if (extensions::util::IsxxxOwnerInlineExtensions(site_url.host())) {
    return SpareProcessRefusedByEmbedderReason::DefaultDisabled;
  }
#endif

  // ... 其他逻辑
}

效果：

避免为 desktop_view 浪费内存创建不必要的进程
减少约 50-100MB 的内存占用

4.2 策略二：打破进程锁定（Site Isolation）

问题：Chrome 默认会将每个站点锁定到特定进程，导致不同 desktop_view 实例无法共享进程。

解决方案 ：在 DoesOriginRequireDedicatedProcess 中返回 false。

复制代码

// chrome/browser/chrome_content_browser_client.cc

bool ChromeContentBrowserClient::DoesOriginRequireDedicatedProcess(
    const GURL& effective_url) {
  
#ifdef USE_HACK
  // desktop_view 不需要专用进程，允许与其他站点共享
  if (IsDesktopViewWebUIURL(effective_url)) {
    return false;  // 关键：禁用进程锁定
  }
#endif

  // ... 其他逻辑
  return true;  // 默认其他站点需要锁定
}

原理：

复制代码

优化前：
desktop_view_1 → Process A (锁定)
desktop_view_2 → Process B (锁定，即使同源)

优化后：
desktop_view_1 → Process A
desktop_view_2 → Process A (复用！)

4.3 策略三：跨源进程共享

问题：即使禁用了锁定，Chrome 的其他安全检查仍可能阻止跨源共享。

解决方案 ：在 ShouldAllowCrossOriginProcessSharing 中明确允许。

复制代码

// chrome/browser/chrome_content_browser_client.cc

bool ChromeContentBrowserClient::ShouldAllowCrossOriginProcessSharing(
    const GURL& url) {
  
#if defined(USE_HACK)
  // 明确允许 desktop_view 与跨源页面共享进程
  if (IsDesktopViewWebUIURL(url)) {
    return true;
  }
#endif

  // ... 其他逻辑
  return false;
}

实际效果：

复制代码

// 现在可以安全地共享进程
Process A:
  - chrome://desktop_view/page1  (chrome scheme)
  - https://example.com          (https scheme) 
  - chrome://desktop_view/page2  (另一个实例)

4.4 策略四：核心复用逻辑

这是最关键的改动，直接在进程决策的核心函数 ShouldSwapProcessesForNavigation 中注入复用逻辑。

复制代码

// content/browser/site_instance_impl.cc

bool SiteInstanceImpl::ShouldSwapProcessesForNavigation(
    const GURL& last_successful_url,
    const GURL& dest_url,
    bool for_outermost_main_frame) {
  
#ifdef USE_HACK
  // 判断源页面和目标页面是否都是 desktop_view
  bool src_is_desktop_view = 
      last_successful_url.host() == "desktop_view" || 
      last_committed_origin.host() == "desktop_view";
  
  bool dest_is_desktop_view = dest_url.host() == "desktop_view";

  // 核心复用条件
  if (src_is_desktop_view && dest_is_desktop_view ||
      src_is_desktop_view && !for_outermost_main_frame) {
    return true;  // 不切换进程，直接复用
  }
#endif

  // ... 原始判断逻辑
}

逻辑解析：

条件	说明	是否复用
`src_is_desktop_view && dest_is_desktop_view`	在 desktop_view 页面间跳转	✅ 复用
`src_is_desktop_view && !for_outermost_main_frame`	desktop_view 中的 iframe 导航	✅ 复用
其他情况	按原始逻辑判断	视情况

关键细节：

for_outermost_main_frame：标识是否为主框架（最外层）
iframe 复用父进程：避免子页面创建额外进程

4.5 策略五：延迟进程创建

问题：提前创建进程可能浪费资源，特别是对于不常用的页面。

解决方案：延长渲染进程的延迟创建时间。

复制代码

// chrome/browser/chrome_content_browser_client.cc

base::TimeDelta ChromeContentBrowserClient::GetRendererProcessDelay(
    Profile* profile,
    const GURL& site_url) {
  
#if defined(USE_HACK)
  // desktop_view 使用 350 秒的超长延迟
  if (IsDesktopViewWebUIURL(site_url)) {
    return base::Seconds(350);  // 接近 6 分钟
  }

  if (extensions::util::IsxxxOwnerInlineExtensions(site_url.host())) {
    return base::Seconds(350);
  }
#endif

  // 默认延迟仅 2 秒
  return base::Seconds(2);
}

优化效果：

延迟 350 秒意味着即使用户打开了页面，渲染进程也不会立即创建
适合低频访问的页面
配合其他策略，进一步减少进程占用

4.6 辅助函数：统一识别 desktop_view

复制代码

// chrome/browser/ui/webui/top_chrome/webui_url_utils.h
#if defined(USE_HACK)
bool IsDesktopViewWebUIURL(const GURL& url);
#endif

// chrome/browser/ui/webui/top_chrome/webui_url_utils.cc
#if defined(USE_HACK)
bool IsDesktopViewWebUIURL(const GURL& url) {
  return url.SchemeIs(content::kChromeUIScheme) &&
         url.DomainIs("desktop_view");
}
#endif

这个函数提供了统一的判断标准，方便其他模块调用。

五、优化效果分析

5.1 进程数量对比

场景	优化前进程数	优化后进程数	节省
1 个 desktop_view	1	1	0%
3 个 desktop_view	3	1	66.7%
5 个 desktop_view + 2 个普通页面	7	3	57.1%
包含 iframe 的 desktop_view	2-3	1	50-66%

5.2 内存占用估算

复制代码

假设单个渲染进程内存占用：80MB

优化前（5个 desktop_view）：
5 × 80MB = 400MB

优化后（5个共享1个进程）：
1 × 80MB = 80MB

节省内存：320MB

5.3 代码改动总结

复制代码

修改文件：
1. chrome/browser/chrome_content_browser_client.cc  (5处改动)
2. content/browser/site_instance_impl.cc            (1处核心改动)
3. chrome/browser/ui/webui/top_chrome/webui_url_utils.{h,cc} (新增函数)

核心逻辑：
- 禁用备用进程：避免浪费
- 打破进程锁定：允许共享
- 强制复用进程：核心策略
- 延迟创建：减少空闲进程

六、技术风险与权衡

6.1 安全性降低

风险：禁用 Site Isolation 可能增加侧信道攻击（如 Spectre）的风险。

缓解措施：

仅对特定可信的 WebUI 页面禁用
保持其他所有站点的隔离保护
使用宏 USE_HACK 控制，不影响主线代码

6.2 稳定性风险

风险：一个页面崩溃会影响所有共享进程的页面。

实际场景：

复制代码

// 如果 Process A 崩溃
Process A (包含 5 个 desktop_view 页面) 崩溃
→ 所有 5 个页面同时消失，用户体验下降

权衡：

接受此风险，因为 desktop_view 页面本身比较稳定
减少进程数带来的内存收益大于稳定性损失

6.3 调试复杂度增加

问题：多个页面共享进程时，调试变得更复杂。

解决方案：

添加详细日志，记录进程分配决策
在 Chrome 的 about://process-internals 页面查看进程分配

七、最佳实践总结

基于这个优化案例，总结出渲染进程合并的通用策略：

7.1 适合合并的场景

同源或同站点的页面
对安全性要求不高的内部页面
用户可能同时打开多个实例的页面
包含大量 iframe 的页面

7.2 不适合合并的场景

敏感页面（银行、支付等）
不同来源的第三方页面
稳定性要求极高的页面
可能存在内存泄漏的页面

7.3 优化优先级

text

复制代码

1. 禁用备用进程（最简单，收益直接）
2. 同源页面复用（安全风险小）
3. iframe 复用父进程（减少子框架进程）
4. 跨源共享（需要仔细评估安全性）

八、总结

通过这套优化策略，我们成功地将多个 chrome://desktop_view 页面合并到单个渲染进程，在保持功能完整的前提下，减少了 50-70% 的进程数 ，节省了数百 MB 的内存。

核心经验：

理解 Chrome 的进程模型是优化的基础
精确识别优化目标，避免影响其他页面
在正确的决策点注入逻辑 （如 ShouldSwapProcessesForNavigation）
权衡安全与性能，谨慎禁用保护机制
充分的测试验证，确保不会引入稳定性问题

这个案例展示了如何深入 Chromium 源码进行性能优化，希望能为读者提供有价值的参考。对于其他浏览器的优化，也可以借鉴类似的思路：识别特殊页面 → 打破隔离限制 → 强制进程复用 → 延迟资源创建。