跨端性能与架构

• Taro Next 对 Webpack5 的兼容与迁移
• Rspack 作为高性能打包器的适配价值
• 跨端产物体积与分包治理

Taro Next（3.6+ 起）在构建侧持续对齐现代打包生态：完整支持 Webpack5，利用其持久化缓存、模块联邦与更优的 tree-shaking 能力，替换 Webpack4 时代的插件实现（如按需注入小程序运行时模块）；同时官方提供 Rspack 支持，Rust 实现的打包器在大型项目上显著缩短构建时间（可达数倍提升），并保持 loader/plugin 生态兼容。跨端产物治理的核心是"同一依赖树、按端裁剪"：通过 alias 与条件导出区分平台实现，用 splitChunks 抽离公共 chunk 并按页面分包；借助编译插件统计各端产物明细（体积、依赖图），建立体积预算与 CI 门禁，防止某端产物因误引入平台代码而膨胀；多端产物使用相同源版本构建后做端到端回归，保证行为一致。

回答分两块：构建链路的现代化（Webpack5/Rspack 迁移的价值），产物治理（按端裁剪、分包、体积预算与门禁）。把"适配"理解为可持续的工程治理而非一次性升级，是得分关键。

• 主包/分包结构与首包体积约束
• 分包预下载与独立分包机制
• 骨架屏降低感知白屏

小程序优化首屏的三板斧：分包加载——把首屏无关页面与依赖放入分包，主包只保留启动必需代码与资源，控制首包下载体积；预加载——通过 preloadRule 或 wx.preloadSubpackage 在用户可能进入分包前（如启动后空闲时）预下载分包，做到"用时已在本地"；骨架屏——在真实数据渲染前用与最终布局一致的占位 UI 填充，降低白屏的感知时长。体积治理方法：依赖按需引入（组件库按组件打包）、图片压缩与 CDN 化、公共代码抽入分包共用依赖（subpackage 的独立分包不可共享则评估是否合并）、构建产物分析（可视化依赖体积）并设立体积预算门禁。三者组合的本质是"下载时间隐藏 + 渲染时间占位"，让用户感知不到网络与解析耗时。

回答先讲三种手段各自的机制（分包减首包、预加载隐藏等待、骨架屏占位），再讲体积治理的具体手段，最后点出组合思路，体现系统性优化思维。

• setData 的全量 diff 与序列化传输
• 减小传输数据量与更新频率
• 长列表的虚拟渲染与节点复用

setData 的瓶颈在于每次调用都要把数据序列化后跨线程（逻辑层到渲染层）传输并执行 diff，数据量大、频率高时通信与渲染开销剧增，表现为页面卡顿。优化手段：数据瘦身——只 set 变化字段而非整棵对象，用路径式 setData（this.setData({'list[3].name': x})）；控制频率——高频数据（滚动位置、进度）节流合并，避免同步风暴；分离静态与动态数据——不变内容不参与更新；大数据对象（如整个列表）拆分字段。长列表性能：优先用虚拟列表（如 recycle-view）只渲染可视区域节点；避免列表项内复杂表达式与高成本组件；setData 按可视窗口增量更新；使用 pureDataPattern 声明纯数据字段减少 diff 开销；必要时用 WXS 在渲染层处理部分逻辑，减少跨线程通信。

回答先解释 setData 瓶颈本质（序列化 + 跨线程 + diff），再给数据层优化（路径更新、节流、瘦身），最后落到长列表专项（虚拟渲染、增量更新），层层递进。

• Lynx 原生渲染免去 WebView 初始化
• 逻辑线程与渲染线程的并行
• 与 Web 重叠渲染的成本对比

Lynx 以原生渲染（自研渲染引擎而非 WebView）驱动 UI，首屏收益来自三方面：免去 WebView 初始化与 HTML/CSS 解析耗时；UI 线程直接构建视图树并提交渲染，JS 逻辑在独立线程执行不阻塞绘制，首帧可在逻辑就绪前部分呈现；预构建/缓存进一步缩短资源加载。工程价值：首屏与滚动性能接近原生，同时保留前端 DSL（React/Vue 心智）的开发效率，适合信息流等重首屏场景。限制：能力集是 Web 子集，复杂布局与部分 CSS 特性需适配；双端（原生渲染端与 Web 重叠渲染端）的行为一致性需要能力矩阵治理；生态与调试工具仍在建设期。

回答抓住"原生渲染 + 线程并行"两个性能来源，再对比 Web 重叠渲染的成本，最后落到能力子集与一致性治理的限制，避免只讲收益。

• 预下载效果的量化指标（命中率、进入时长）
• setData 耗时与数据传输量的测量
• 通信瓶颈的定位方法

量化是优化的前提：分包预下载用"预下载完成率、分包命中率、进入分包页面到可交互时长"衡量，配合埋点对比"预下载开启前后"的进入耗时差；setData 开销可用 wx.getPerformance 相关能力（或 DevTools Performance 面板）测量每次 setData 的耗时、传输数据字节数与调用频率，按页面聚合出"高耗时 setData 调用 Top N"。定位通信瓶颈的方法：在逻辑层记录 setData 参数序列化后大小（JSON.stringify 长度近似）、调用时间戳，与渲染层帧时间对比，确认瓶颈在传输还是渲染；通过移除字段、拆分调用做 A/B 验证耗时变化。实践中建立性能预算：单次 setData 数据量上限、单页 setData 频率上限，纳入 CI 与告警，防止回归。

回答体现"先测量后优化"的方法论：每类优化都要有对应的量化指标与测量手段，最后把指标固化为性能预算与门禁，展现工程闭环。

• sandbox 默认开启对渲染进程的约束
• contextIsolation 与 nodeIntegration 的默认值
• BrowserWindow 安全配置清单

Electron 28+ 将 renderer sandbox 设为默认开启：渲染进程运行在受限沙箱中，无法直接访问 Node.js 与系统资源，即使渲染层被 XSS 攻破也无法提权，显著缩小攻击面。与之配套的安全默认值：contextIsolation 默认 true（preload 与页面脚本隔离）、nodeIntegration 默认 false。BrowserWindow 安全策略要点：加载本地可信内容为主，禁止或严格限制加载远程内容；preload 只暴露白名单 API（通过 contextBridge）；设置 CSP（Content-Security-Policy）与禁用的 webPreferences（webviewTag、allowRunningInsecureContent、enableRemoteModule）；对 webContents 事件（will-navigate、setWindowOpenHandler）做导航白名单校验。工程价值在于"默认安全 + 显式收紧"：升级即获得基线防护，再按业务声明最小能力。

回答先讲 sandbox 默认开启的威胁模型收益，再讲 BrowserWindow 的配置清单（contextIsolation、CSP、导航校验、最小权限），体现"默认安全"的纵深防御思想。

• 三进程的角色与生命周期
• IPC 通道（ipcMain/ipcRenderer）与消息模型
• sandbox 下 preload 的受限能力

Electron 三进程分工：主进程（main）负责应用生命周期、窗口创建与系统能力（菜单、托盘、原生对话框），运行 Node 全量环境；渲染进程（renderer）承载页面 UI，默认沙箱化、无 Node 能力；预加载脚本（preload）运行在渲染进程上下文创建前，通过 contextBridge 向页面暴露受限 API，是渲染层与主进程通信的"桥梁"。IPC 用 ipcMain.handle/ipcRenderer.invoke（请求-响应）与 ipcMain.on/ipcRenderer.send（单向/事件）两类模式，数据经结构化克隆传输。sandbox 开启后 preload 只能使用有限的 Node 子集（require 受限），必须依赖主进程代理执行敏感操作。工程价值：职责边界清晰、最小权限落地、渲染层被攻破时无法直达系统，IPC 消息统一走主进程便于审计与权限校验。

回答按"进程分工 → 通信模式 → sandbox 约束"组织，突出"preload 只做桥、敏感操作主进程代理"的安全架构。

• contextBridge 的 API 暴露机制
• 三件套的默认值与安全意义
• 错误配置组合的典型风险

contextBridge 在隔离的"主世界"（页面脚本）与"隔离世界"（preload 环境）之间提供受控桥接：preload 用 contextBridge.exposeInMainWorld 暴露白名单 API，值按需浅拷贝/冻结传递，防止页面直接触达 Node 内部对象。三件套的配合：nodeIntegration=false 关闭渲染进程直接 require Node；contextIsolation=true 让 preload 与页面脚本运行在不同 context，即使页面被 XSS 注入也拿不到 preload 作用域；sandbox=true 进一步限制渲染进程内核能力（无 Node、受限 require）。正确组合是三者同时开启；典型风险组合：nodeIntegration=true 且无 contextIsolation（XSS 直接 RCE）、contextIsolation=false 配合远程内容（preload 被污染）、sandbox=false 放大单点攻破影响。工程实践：默认保持官方安全默认值，preload 只暴露最小 API 并做参数校验。

回答先讲 contextBridge 的桥接机制，再讲三件套各自阻断的攻击路径与正确组合，最后列举错误组合的风险，体现"纵深防御"理解。

• 原生组件（同层渲染）的能力与限制
• 自定义组件的渲染成本
• 滚动场景下的性能取舍

原生组件（map、video、canvas、camera 等）由系统原生层渲染，不受 WebView 渲染线程瓶颈约束，交互与绘制性能高，但历史上存在覆盖层问题（原生层在 WebView 之上，普通视图无法覆盖），通过同层渲染（同层渲染使原生组件与 WXML 节点同层合成）基本解决；其样式定制与数据驱动能力弱于普通组件，事件与通信走原生通道。自定义组件由 WXML/WXSS 在渲染层合成渲染，灵活可控但受渲染线程与 setData 更新成本约束，复杂结构高频更新时易卡顿。选择原则：交互密集、绘制量大且原生能力够用（视频、地图、画布）选原生组件；UI 逻辑复杂、需深度定制与动画编排选自定义组件；列表滚动场景避免在自定义组件内做高频全量 setData，优先虚拟列表与局部更新。

回答以"渲染层归属"划分边界：原生组件走原生渲染线程、自定义组件走 WebView 渲染线程，再按场景给出选择原则与高频更新注意事项。

• 版本号管理与包/热更双层发布
• 灰度放量与规则（设备、比例、地区）
• 回滚机制与兼容性策略

跨端发布采用"安装包 + 热更新"双层：安装包（含 JS bundle 或字节码）走应用商店审核，热更新（RN CodePush/Metro、Taro 小程序按版本上传、uni-app 云端资源）绕过商店快速修复与迭代。版本管理要点：语义化版本与构建号唯一绑定，服务端记录每个版本对应的 bundle 指纹与兼容声明；热更新灰度按设备比例/账号/地区分阶段放量，配合可观测性（崩溃率、关键指标）决定全量或暂停。回滚机制：热更新层可秒级回退到上一 bundle（版本记录 + 客户端本地回滚兜底）；包级问题只能引导升级或紧急发布；跨版本兼容需遵循"新客户端兼容旧 bundle、新 bundle 兼容旧客户端"的双向兼容策略，服务端按客户端版本下发匹配资源。事故复盘流程：封板、暂停灰度、回滚、根因定位、补丁发布。

回答按"发布体系 → 灰度 → 回滚 → 兼容策略"组织，重点强调双向兼容矩阵与热更新/安装包两个回滚平面的配合。

• JSI 同步调用与免序列化
• TurboModules 按需加载与启动收益
• Fabric 渲染提交与帧率稳定性

JSI 让 JS 直接持有 C++ 宿主对象，调用原生方法无需 JSON 序列化与异步排队，同步路径的开销接近普通函数调用；这使高频调用（如手势、传感器、逐帧逻辑）不再受 Bridge 队列延迟影响，但同步调用在主线程执行时仍会阻塞 JS 与 UI，需注意调用耗时与线程选择。TurboModules 懒加载：模块按首次调用才初始化，启动时不再全量注册，减少冷启动开销；强类型接口经 codegen 生成，调用路径更确定。Fabric 渲染：UI 更新由 C++ 渲染器统一提交，支持同步布局（减少首帧等待）与优先级调度，React 并发特性可在低优先级更新中保持高优先级动画帧率，配合 JSI 的同步能力使动画帧率更稳定；代价是渲染协调逻辑更复杂，调试需新工具链。

回答按"调用层（JSI 免序列化）→ 模块层（懒加载）→ 渲染层（Fabric 调度）"分层讲性能特征，并指出同步调用的线程风险，体现辩证视角。

• Hermes 字节码的压缩收益与边界
• ICU（国际化）裁剪的取舍
• 依赖按需引入与资源优化

包体积治理三板斧：Hermes 字节码——把 JS 编译为 Hermes Bytecode 而非直接打包源码，字节码更紧凑且无需运行时解析，配合 Hermes 运行时减少依赖体积，注意部分特性（eval 等）不可用；ICU 裁剪——RN 默认携带完整 ICU 数据（大量语言时区数据），若应用只支持少量语言，可用 hermes-icu 裁剪或启用 Intl 子集，可省数百 KB 至数 MB，代价是缺失语言环境的格式化回退需自测；按需引入——组件库与工具库用 tree-shaking 与按需导入（babel-plugin-import 等）只打包使用部分，业务模块用懒加载与分包（React.lazy/metro 的 split）。此外配合资源优化：图片 WebP/压缩、字体子集化、Native 库裁剪（abi 过滤）。实践中用构建产物分析工具定位体积 Top 依赖，建立体积预算门禁防止回归。

回答按"引擎层（字节码）→ 系统层（ICU）→ 依赖层（按需引入）"分层治理，并强调每项的收益与代价平衡，最后落到产物分析与预算门禁。

• 调试链路（JS 调试、原生调试、网络与存储面板）
• DevTools 协议在各端的实现差异
• 真机调试与远程调试

跨端调试的核心是"统一调试协议 + 各端适配"：RN 用 Chrome DevTools 或 React Native DevTools（基于 Chrome DevTools Protocol），支持 JS 断点、React 组件树（React DevTools）与原生调试（Xcode/Android Studio）；Flutter 提供 Dart DevTools，包含 widget 检查器、性能时间线、内存剖析与网络面板；小程序用微信开发者工具，集成了逻辑层调试、渲染层 DOM 面板、网络与存储面板，真机通过远程调试通道同步。工程要点：开发期区分 JS 调试与原生调试两层，bundle 加载方式（远程 bundle 便于热更新调试）；发布期保留可关闭的调试开关与日志通道，避免调试代码进生产；跨端问题定位需联动"框架层日志 + 原生层日志 + 网络抓包"，用统一 traceId 串联。DevTools 集成价值在于把框架抽象层"透明化"，让开发者按熟悉的 Web 心智调试多端问题。

回答先讲各框架的 DevTools 形态（协议 + 面板），再讲开发/真机/发布三阶段的调试链路建设，最后落到用 traceId 串联多层日志的排障方法论。

• invoke/handle 与 send/on 两种模式
• 消息的序列化与错误处理
• 通道命名与安全校验

Electron IPC 提供两类模式：请求-响应用 ipcRenderer.invoke + ipcMain.handle（返回 Promise，天然支持异步与异常传递）；单向/事件用 ipcRenderer.send + ipcMain.on（或反向 ipcMain 向指定窗口 webContents.send）。数据经结构化克隆算法传输，函数与原型不可传递。注意点：invoke 的 handler 抛错会以 rejected promise 形式回传，前端需 try/catch；频繁大对象传输会拖慢主进程事件循环，应合并或只传必要字段；通道名约定统一（如 'app:open-file'）避免冲突；安全上所有来自渲染进程的消息都应校验 sender（event.senderFrame 的来源 URL）与参数，不信任渲染层传入的路径等参数；监听器在窗口销毁时清理，防止泄漏。工程上可封装 typed IPC 层（TS 类型化请求/响应映射），避免散落的魔法字符串。

回答按"两种模式 → 序列化与异常 → 安全与资源 → 工程封装"组织，突出 sender 校验与结构化克隆两个关键点。

• 主进程与渲染进程的职责边界
• 预加载脚本的执行时机与能力
• 进程间的资源与生命周期关系

Electron 继承 Chromium 多进程模型：主进程是应用入口（Node 全量环境），管理应用生命周期、创建窗口、注册全局快捷键与托盘，是唯一能直接操作系统资源（文件、原生模块）的进程；渲染进程每窗口一个，负责页面渲染，默认无 Node 能力、被沙箱限制，崩溃互不影响；预加载脚本在渲染进程初始化时、页面脚本执行前运行，可访问受限 Node API，通过 contextBridge 向页面暴露接口。生命周期关系：主进程退出则应用退出；窗口关闭不等于应用退出（macOS 惯例保留应用）；渲染进程崩溃可由主进程监听 'render-process-gone' 恢复或提示。职责划分原则：UI 逻辑归渲染层，系统能力与跨窗口协调归主进程，preload 只做桥接，避免在渲染层直接处理敏感操作。

回答按"三个角色 → 生命周期关系 → 职责原则"展开，突出"渲染层不碰系统能力、preload 只做桥"的架构纪律。

• remote 模块的安全问题与移除
• invoke/handle 替代 remote 的改造模式
• 主进程集中管理窗口注册表与共享状态

remote 模块允许渲染进程直接调用主进程对象，破坏了进程边界与安全模型（远程对象引用、死锁风险、放大攻击面），已被移除/禁用。替代设计：渲染进程通过 ipcRenderer.invoke('window:create', config) 请求主进程创建窗口，主进程 ipcMain.handle 集中处理并返回结果；所有需要共享的状态（用户信息、配置、窗口列表）由主进程持有，渲染层通过"请求-响应 + 事件广播"读写。主进程维护窗口注册表（窗口 id 与 BrowserWindow 映射），统一管理创建、聚焦、关闭、最小化等操作，并作为状态中枢：状态变更用 webContents.send 向相关窗口广播或查询。收益：权限校验集中在一处、状态单一来源、渲染层被攻破时无法直接操纵其他窗口。

回答先说明 remote 被禁的原因（进程边界与安全），再给出"invoke/handle 请求化 + 主进程状态中枢 + 事件广播"的替代模式，体现架构思想。

• app 生命周期事件（ready、window-all-closed、activate）
• BrowserWindow 创建与窗口配置
• 窗口状态持久化与多窗口协调

app 生命周期事件驱动应用状态机：ready 后创建窗口；window-all-closed 时除 macOS 外默认退出（macOS 保留应用与 Dock 图标，点击 activate 再建窗口）；before-quit/will-quit 做清理（保存状态、释放资源）；第二实例启动（second-instance）时聚焦已有窗口。BrowserWindow 管理要点：窗口参数（width/height、minWidth、frame、webPreferences 安全项）集中配置；维护窗口列表统一管理多窗口（创建、关闭、销毁引用防泄漏）；窗口状态（位置、大小、是否最大化）持久化到本地并在创建时恢复；模态窗口、父子窗口关系按业务建模；监听 close 与 closed 区分"可取消关闭"与"已销毁"。工程上常封装 WindowManager 模块：注册表 + 事件 + 序列化恢复，避免散落创建逻辑。

回答分两层：app 生命周期状态机（含 macOS 惯例）与窗口管理工程化（注册表、持久化、防泄漏），体现对桌面应用生命周期细节的掌握。

• sandbox 下渲染进程的能力限制
• preload 白名单暴露的边界
• 主进程代理执行的模式与权限校验

sandbox 开启后渲染进程没有 Node 完整环境：无法 require 任意模块、无法直接访问 fs/child_process 等系统能力、无 process 全量对象，网络与文件操作受限。替代方案分两层：preload 白名单——preload 在受限环境中仍可 require 少量 Electron/Node 内置模块（如 electron 的 ipcRenderer、contextBridge），把需要的能力封装为白名单 API 通过 contextBridge 暴露给页面；主进程代理——文件读写、子进程、系统对话框等敏感操作一律由渲染层发 IPC 请求，主进程校验来源与参数后执行并返回结果。要点：preload 不内置业务逻辑（只做桥接）；主进程按能力维度做权限校验（哪些窗口可调用哪些命令）；敏感参数（路径、命令）在服务端侧（主进程）再做一次合法性校验，不信任渲染层。

回答按"sandbox 损失了什么 → preload 暴露什么 → 主进程代理什么"三层组织，突出最小权限与二次校验原则。

• 各方案的同步机制与适用范围
• 状态一致性、复杂度与容错
• 按场景的组合选型

三种方案各有取舍：BroadcastChannel——渲染进程间同源页面直接广播，轻量、无需主进程中转，适合高频低风险的通知（如主题切换、刷新命令），但仅同源页面可用、无持久化与鉴权；共享 store——在主进程维护单一数据源（如内存 store + 持久化），各窗口经 IPC 读写并订阅变更，状态一致性强、单一事实来源，适合全局配置、会话等核心状态，代价是 IPC 往返与序列化；主进程中枢广播——主进程作为消息路由器，监听各窗口消息并定向转发/广播，可控性强（可鉴权、可记录），适合需要协调的复杂流程（如窗口间联动、任务分发）。工程实践常组合使用：核心状态进共享 store，事件通知用中枢广播，临时同步用 BroadcastChannel，并定义统一消息协议版本化演进。

回答按"机制 → 取舍维度（一致性、复杂度、鉴权）→ 组合选型"展开，强调没有银弹，按状态重要性分层使用。

• 密钥与敏感信息不落前端
• 请求域名白名单与 HTTPS
• 数据加密、脱敏与合规

小程序安全的核心原则是"敏感能力后移"：加密密钥、业务密钥、token 签名一律不放前端代码与本地存储，必须放在服务端或云函数中；登录态用 code 换 session_key 的流程（wx.login → 服务端 code2Session）保证凭证不落地；用户敏感数据（手机号、身份证）通过服务端解密接口获取，前端只展示脱敏结果。网络请求安全：请求域名必须在后台配置白名单（合法域名校验），强制 HTTPS 并校验证书；参数签名防篡改（时间戳 + 随机数 + 服务端验签）；敏感字段传输加密（如 AES）与防重放；本地存储（storage）不存敏感明文，重要数据用加密存储与访问指纹。合规层面：用户隐私协议、最小必要采集、权限申请说明，符合《个人信息保护法》与平台审核规范。

回答按"密钥与凭证管理 → 传输安全 → 数据脱敏与合规"三层组织，突出"前端不持有秘密"与"服务端验签"两个核心原则。

• UI 线程执行动画的工作线程模型
• 与 React 渲染更新的解耦
• 手势与动画联动的性能收益

Reanimated 的核心是"工作线程（Worklet）"机制：动画逻辑以 worklet 形式运行在 UI 线程（而非 JS 线程），跳过 React 的 JS 执行与渲染协调，直接驱动原生动画值，避免 JS 线程卡顿导致掉帧。它与 React 渲染解耦：共享值（SharedValue）变更不会触发 React 重渲染，动画帧在 UI 线程逐帧执行，只有动画完成或状态落定时才同步回 JS/React；手势（Gesture Handler）回调也可声明为 worklet，在手势线程直接计算，实现丝滑的跟手动画。工程价值：复杂交互动画（拖动、缩放、列表进出场）帧率稳定，长列表不因动画重渲染；代价是 worklet 有语法限制（闭包捕获需序列化、不可用部分 JS API），调试需专项工具，且需遵循"UI 线程能力边界"设计动画逻辑。

回答抓住"动画逻辑上 UI 线程、与 React 渲染解耦"的本质，再讲共享值与手势联动，最后提 worklet 的语法边界，体现对机制与代价的双重理解。

• 自绘引擎的跨端一致性原理
• Impeller 着色器一致的绘制结果
• 平台纹理与字体差异的兜底

Flutter 自绘引擎天然追求跨端一致：同一绘制指令在 iOS/Android 由同一渲染管线执行，布局与矢量绘制结果高度一致，与系统控件渲染无关。Impeller 相比 Skia 的一致性更进一步：Skia 在不同平台采用不同后端（GL/Metal/Vulkan）且着色器运行时编译，驱动差异可能产生不一致的绘制结果与 jank；Impeller 预编译统一着色器，光栅化结果与行为跨平台更可预测，抗锯齿与混合模式一致。剩余差异来自平台层：字体渲染（系统字体回退）、文本输入法、平台纹理（图片解码）等仍需按平台适配。工程取舍：追求像素级一致与帧率稳定优先启用 Impeller（按平台版本核查）；对特定平台特性（如某些 GL 特性、字体）做平台条件实现，用 golden test 建立跨端视觉回归基线。

回答先讲自绘引擎一致性来源，再对比 Skia 运行时编译 vs Impeller 预编译对一致性的影响，最后落到字体纹理等平台差异与 golden test 治理。

• nativeImage 的创建与多尺寸图标
• 系统托盘与 Dock Badge 的更新
• 平台差异与资源管理

nativeImage 是 Electron 处理图标的模块：可从路径、buffer 或 dataURL 创建图像，支持多分辨率表示（setTemplateImage 适配 macOS 深浅色模板图标），用于窗口图标、系统托盘（Tray）与 Dock 图标；应用图标与 Dock Badge（角标）更新通过 app.dock.setBadge、app.setBadgeCount（macOS/Linux/Windows 支持度不同）实现，配合主进程定时或事件驱动更新。工程价值：统一 API 抹平三平台图标处理差异（Windows 托盘单色/多色、macOS 模板图标、Linux 指示器）；nativeImage 从 buffer 创建可支持动态生成角标（如未读数渲染后转 buffer）。注意点：图标资源按平台提供多尺寸与主题版本；badge 更新频率与性能（避免高频重建图像）；平台能力检测（setBadgeCount 在部分 Linux 环境不可用需降级）。

回答按"模块能力 → 平台差异 → 工程注意点"组织，突出模板图标与 badge 的平台差异检测，体现桌面端细节经验。

• 自定义协议注册的时机与方式
• 特权协议（standard/secure）的声明
• 协议处理器的实现与安全边界

自定义协议让应用以 app:// 等形式加载内容：须在 app ready 之前调用 protocol.registerSchemesAsPrivileged 声明协议属性（standard、secure、supportFetchAPI、stream 等），再在 ready 后用 protocol.handle（新版）或 registerFileProtocol/registerBufferProtocol 注册处理器，把请求映射到文件、内存或动态内容。声明 privileged 的意义：standard 使协议遵循标准 URL 解析（可作相对路径与 history 路由），secure 使内容按安全源处理（可调用 fetch 等安全 API、不触发混合内容警告）。使用要点：协议注册必须在 ready 前（否则不生效）；处理器需处理 favicon、子资源等全部请求并返回正确 MIME；自定义协议内容视同远程内容，仍需遵循最小权限与 CSP；协议名避免与系统/常见 scheme 冲突，路径参数需校验防目录穿越。

回答按"注册时机 → privileged 属性含义 → 处理器实现 → 安全边界"组织，突出 standard/secure 声明的必要性，体现对 Electron 加载机制的理解。

• offscreen 渲染的帧捕获与使用边界
• BrowserView 的嵌入与布局管理
• 与 WebContentsView 的演进关系

Offscreen Rendering 让 BrowserWindow 在不可见状态下仍渲染，通过 'paint' 事件把帧作为图像（bitmap）输出到主进程，适合屏幕共享、录屏、缩略图生成与虚拟显示等场景；代价是失去系统合成与硬件加速的部分优化，帧捕获需自行处理节奏与性能。BrowserView 是把独立 webContents 嵌入主窗口指定区域的组件（可叠加、可定位），适合"浏览器内核"类应用（多标签、内嵌第三方页面）；需手动管理尺寸、层级与销毁，且 BrowserView 已被官方标记 deprecated，推荐用 WebContentsView（更现代的窗口内嵌视图 API）。工程注意点：offscreen 渲染在 GPU 环境需验证帧率与内存；BrowserView/WebContentsView 的生命周期与安全配置（webPreferences）与 BrowserWindow 一致，内嵌第三方内容需走安全默认值。

回答按"机制 → 场景 → 演进"组织：offscreen 讲帧输出与适用场景，BrowserView 讲嵌入模型与 WebContentsView 的演进，并强调安全默认值。