背景 Electron 的优势在于 UI 开发效率高，但在实现 RTC、视频前处理、美颜和虚拟背景等能力时，往往会触及 Web SDK 的边界。 TRTC 是腾讯云实时音视频 SDK，适合做采集、推流、拉流、前处理和视频渲染这条主链路。它和浏览器里的 Web SDK 不是一回事：Web SDK 更轻，TRTC Native SDK 则给了更完整的原生能力。 SwiftPM 是 Swift Package Manager，也就是 Swift 的包管理和构建工具。它不只是“装依赖”，还负责描述 target、平台条件、二进制产物和构建关系，所以很适合拿来组织 Swift、C、C++ 和 Objective-C++ 混合工程。 以 TRTC 为例，如果 Web SDK 不支持发送前的视频处理，主链路就无法只依靠 <video>、Canvas、WebGL 或 WebGPU，而需要接入 TRTC Native SDK。 本文整理了一套可落地的方案：用 SwiftPM 管理混合代码，构建 Node Addon；Electron 负责 UI 和布局，TRTC Native SDK 负责采集、前处理、编解码和视频渲染。 目标不是强行让所有平台共用完全相同的原生代码，而是统一 JS API 和包管理结构，并在平台适配层分别接入 macOS 与 Windows SDK。 为什么 addon 用 Swift 这篇方案里，addon 选择 Swift 不是为了绕开 C++，而是因为它刚好处在一个很合适的中间层：上面要接 Electron 和 Node-API，下面要接平台 SDK、窗口句柄和 TRTC。 ...
Cocos 引擎 iOS 渲染管线深度解析：从 CADisplayLink 到屏幕呈现
Cocos 引擎 iOS 渲染管线深度解析：从 CADisplayLink 到屏幕呈现 引言 在移动端图形开发中，理解渲染管线的底层实现是走向高级工程师的必经之路。Cocos Creator 作为主流的跨平台游戏引擎，其 iOS Metal 后端的渲染实现采用了现代化的 FrameGraph 架构，结合脏状态追踪、资源池化等优化手段，是一份极佳的学习样本。 本文基于对 Cocos 引擎 gfx-metal 模块的源码分析，梳理从 CADisplayLink 帧回调触发到最终 GPU 呈现的完整渲染链路，并深入解读各阶段的关键实现细节。 整体架构概览 在深入时序之前,先理清核心模块的职责分工： 模块 文件 职责 IOSPlatform IOSPlatform.mm iOS 平台入口，持有 CADisplayLink 驱动渲染循环 RenderPipeline RenderPipeline.cpp 管线编排器，遍历相机并调度 Flow/Stage ForwardFlow ForwardFlow.cpp 前向渲染流程，决定渲染策略 ForwardStage ForwardStage.cpp 前向渲染阶段，收集渲染对象并填充 UBO RenderQueue RenderQueue.cpp 渲染队列，对可渲染对象排序 FrameGraph FrameGraph.cpp 帧图调度器，负责 Pass 编译、排序、合并和执行 CCMTLDevice MTLDevice.mm Metal 设备抽象，管理 Swapchain 和 Queue CCMTLSwapchain MTLSwapchain.mm 交换链，管理 CAMetalLayer 和 drawable CCMTLCommandBuffer MTLCommandBuffer.mm 命令缓冲区封装，核心渲染编码入口 CCMTLRenderCommandEncoder MTLRenderCommandEncoder.h 渲染编码器，含脏状态追踪优化 完整渲染时序图 以下 Mermaid 时序图展示了从屏幕刷新信号到最终呈现的五个阶段： ...
面试专题
系统化的iOS和AI面试知识库，涵盖基础到进阶的完整知识体系！ iOS 相关面试题 App 启动与优化 Q: APP启动的详细流程是什么？ iOS 应用启动分为冷启动、热启动和预热启动三种类型。冷启动是最完整的流程，分为 Pre-main 阶段 和 main 阶段。 Pre-main 阶段： Pre-main 阶段由 dyld（动态链接器）负责，从用户点击 App 图标到 main() 执行之前。主线程在内核 fork() 创建进程时同时创建，后续所有 Pre-main 工作都在主线程上执行。 加载可执行文件：内核创建进程，使用 mmap() 将 Mach-O 文件映射到虚拟内存（惰性加载，只有实际访问的页才加载到物理内存）。解析 Mach-O Header（验证 Magic Number、CPU 架构匹配、文件类型识别）和 Load Commands（LC_SEGMENT_64 映射内存并设置权限、LC_LOAD_DYLIB 记录动态库依赖、LC_MAIN 计算入口地址等），最后验证代码签名。 加载动态库（dyld）：dyld 从主程序 Mach-O 的 LC_LOAD_DYLIB 中读取依赖的动态库路径，按搜索规则查找动态库实际位置（优先从共享缓存中查找），使用 mmap() 映射到进程虚拟地址空间，验证代码签名，然后使用深度优先搜索递归加载每个动态库的依赖（每个库只加载一次）。最终按依赖关系构建初始化顺序——被依赖的库先于依赖方（如 Foundation 在 UIKit 之前）。如果 App 使用 Swift，此阶段还会加载 Swift 标准库（iOS 12.2+ 位于系统共享缓存，无需嵌入 App）。 Rebase & Bind：由于 ASLR（地址空间布局随机化），App 每次启动的加载地址不同，需要修正指针。Rebase（重定位）修正指向 Mach-O 内部的指针，将编译时地址加上 ASLR 偏移量（slide）；Bind（绑定）修正指向 Mach-O 外部的指针，查找符号表绑定到正确的外部符号地址（如 _objc_msgSend）。 ...
跨平台
跨平台开发面试题
设计模式与原则
设计模式与原则合集
设计模式
设计模式面试题
设计原则
设计原则面试题
编译工程
iOS 编译优化面试题
源码分析
iOS 第三方库源码分析
架构设计
iOS 架构设计面试题