简介面向iOS开发与逆向工程人员的虚拟摄像头插件源码包聚焦通过MobileSubstrate注入系统相机进程并Hook AVCaptureSession相关方法实现视频流替换与自定义视频源接入。资源共5个文件压缩包仅15KB含2个HTML说明文档、1个JavaScript脚本及工程配置文件结构精简便于快速查看核心实现思路。核心代码基于AVCaptureVideoDataOutputSampleBufferDelegate协议完成视频帧替换并演示SwiftUI摄像头应用中的摄像头切换、滤镜选择与视频源配置视频选择部分使用PHPickerViewController选取本地视频结合UISlider实现时长控制与裁剪导出。目前已有245人学习下载适合具备一定iOS基础和逆向经验的开发者作为技术参考。 上周有个做直播工具的朋友跑来问我iOS上能不能像电脑一样装个虚拟摄像头插件把合成画面喂给微信视频或抖音直播我第一反应是“想都别想”但仔细捋了一遍iOS的摄像头采集链路和插件化机制后发现这事得拆成三四个层级来看。被追问多了索性把整个思路和能落地的代码方向整理成这篇东西给同样在做iOS虚拟摄像头相关需求的人做个参考。说清楚一点这篇文章讲的不是“破解系统”那种黑魔法而是基于iOS现有公开能力把“虚拟摄像头”这个概念落到可运行的方案上。你会看到为什么iOS不像macOS那样有现成的DAL驱动机制也会看到在不越狱、半越狱、App内自采集三种路径下各自的代码写法和工程取舍。适合正在做iOS直播辅助、自动化测试、视频源模拟的开发者也适合想搞清楚“iOS虚拟摄像头到底能不能做”的产品经理。1. iOS摄像头服务链路与“虚拟”的三个层级1.1 一条正常采集链路是怎么走的要理解“虚拟摄像头”在iOS上意味着什么先得看原生采集链路。iOS的摄像头采集大致分四层硬件层物理摄像头传感器通过ISP图像信号处理器输出RAW或YUV数据。系统服务层mediaserverd、runningboardd等进程管理采集会话摄像头权限由TCCTransparency, Consent, and Control框架管控。框架层AVFoundation对上层提供AVCaptureDevice、AVCaptureSession等APIApp在这里拿到视频流。应用层微信、抖音、直播SDK最终通过AVCaptureVideoDataOutput或AVCaptureMovieFileOutput拿帧做编码和推流。注意一个关键点iOS的摄像头服务是系统级单例任何一个App请求摄像头时系统会弹TCC授权框授权后由mediaserverd分路输出。整个过程没有像Windows那样暴露“虚拟驱动”接口也没有macOS的CoreMediaIO DAL插件机制。所以想在iOS上搞一个“系统全局都能看到的虚拟摄像头”本质上是在挑战系统架构而不是写一个普通插件。1.2 “虚拟摄像头”的三个层级基于上面的链路我通常把“iOS虚拟摄像头”拆成三个层级App内虚拟源在你自己App的AVCaptureSession里用AVCaptureDeviceInput之外的source替换成合成画面。直播SDK、录制SDK、美颜SDK都能拿到这个“虚拟画面”。这是最干净、可控性最高、完全合规的做法。系统级插件通过越狱Tweak注入到SpringBoard或mediaserverdhook摄像头创建流程把某个App的摄像头请求重定向到我们的虚拟内容。这个层级最接近“虚拟摄像头插件”这个标题但门槛高、稳定性差、审核风险大。远端/网络摄像头模拟把另一台设备或PC上的视频流通过网络输送到iOS端在App内解码后作为采集源。典型如Camo、EpocCam这类把iPhone当Mac摄像头的应用反向来做也能实现iOS端接收虚拟流。这篇博文主推第1层因为第2层涉及越狱环境第3层更多是网络传输方案。第2层我会讲清楚原理和hook点但不会给你一份可以直接放在Cydia里跑的完整插件——那个东西调试起来很痛苦而且不同iOS版本的偏移量和签名要求完全不同。1.3 为什么iOS不能像桌面系统一样直接装驱动桌面系统能虚拟摄像头靠的是操作系统提供了驱动抽象层Windows有DirectShow/Kernel StreamingmacOS有CoreMediaIO DAL。驱动开发者只要实现一套设备接口系统就把它当成一个真实摄像头暴露给所有App。iOS把这个口子焊死了。App Store审核规则不允许第三方安装系统级驱动摄像头硬件的独占策略也是系统统一调度的。苹果这么做是从隐私和稳定性出发一个App拿到的摄像头画面理论上不应当被另一个App截获或篡改。所以“iOS虚拟摄像头插件”这个需求第一关不是技术而是系统机制。2. 代码实操用AVFoundation搭一个App内虚拟采集源2.1 为什么这条路最值得先做如果你是想在直播、视频会议、自动化测试场景里使用虚拟摄像头App内自采集是性价比最高的方案。原因有三不需要越狱工程链路上只有Xcode签名帧数据完全掌握在自己手里可以叠加水印、更换背景、插入动画代码量可控核心逻辑大约两三百行就能跑通。它的局限也很明确只有你的App能看见这个虚拟画面。你不能让微信视频通话直接显示你的合成画面因为微信跑在独立进程里不会加载你写的采集代码。如果你确实需要“全局生效”那就得跳到第3章的越狱方案。先把App内方案吃透再谈系统级这是我个人强烈建议的顺序。2.2 核心代码骨架自定义帧源替换摄像头输入AVFoundation虽然不直接支持“虚拟设备”但它有个很大的容忍度你可以在AVCaptureVideoDataOutput的代理回调里拿到CMSampleBuffer然后自由修改像素内容再交给编码器。换句话说你把摄像头帧拦截下来做任意合成再输出出去。这其实已经是事实上的“虚拟摄像头”了。先看一个最基础的帧合成代码import AVFoundation import CoreVideo final class VirtualFrameFactory { private var pixelBufferPool: CVPixelBufferPool? func makeFrame(width: Int 1280, height: Int 720) - CVPixelBuffer? { let attrs: [String: Any] [ kCVPixelBufferPixelFormatTypeKey as String: kCVPixelFormatType_32BGRA, kCVPixelBufferWidthKey as String: width, kCVPixelBufferHeightKey as String: height, kCVPixelBufferPoolAllocationThresholdKey as String: 6 ] CVPixelBufferPoolCreate(nil, nil, attrs as CFDictionary, pixelBufferPool) guard let pool pixelBufferPool else { return nil } var pixelBuffer: CVPixelBuffer? CVPixelBufferPoolCreatePixelBuffer(nil, pool, pixelBuffer) return pixelBuffer } func drawSolidColor(on buffer: CVPixelBuffer, color: (CGFloat, CGFloat, CGFloat)) { CVPixelBufferLockBaseAddress(buffer, []) defer { CVPixelBufferUnlockBaseAddress(buffer, []) } guard let baseAddress CVPixelBufferGetBaseAddress(buffer) else { return } let bytesPerRow CVPixelBufferGetBytesPerRow(buffer) let width CVPixelBufferGetWidth(buffer) let height CVPixelBufferGetHeight(buffer) // 这里用CoreGraphics/CoreImage绘制到你想要的内容 let context CGContext( data: baseAddress, width: width, height: height, bitsPerComponent: 8, bytesPerRow: bytesPerRow, space: CGColorSpaceCreateDeviceRGB(), bitmapInfo: CGImageAlphaInfo.premultipliedFirst.rawValue | CGBitmapInfo.byteOrder32Little.rawValue ) context?.setFillColor(red: color.0, green: color.1, blue: color.2, alpha: 1.0) context?.fill(CGRect(x: 0, y: 0, width: width, height: height)) } }这段代码做了三件事创建CVPixelBufferPool复用缓冲区从池里取一块像素缓冲用CGContext往缓冲里画纯色。实际项目中你在这里画的不只是纯色可以是用CoreImage叠加的实时摄像头特效也可以是从视频文件AVAssetReader读出的帧或者是网络流解码后的画面。关键点在于CVPixelBufferPoolCreate。我见过很多新手直接CVPixelBufferCreate一帧帧分配结果内存暴涨、掉帧严重。用池化复用能显著降低性能损耗这个在帧率要求高的场景是必须的。2.3 把合成帧输送给上层录制或直播SDK帧工厂准备好之后下一步是替换摄像头采集输出。方法有两类第一类是直接在采集回调里改帧func captureOutput(_ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection) { // 拿到原始帧 guard let pixelBuffer CMSampleBufferGetImageBuffer(sampleBuffer) else { return } // 用第2.2节的工具做合成 // 注意如果只是加滤镜可以直接用CoreImage处理pixelBuffer // 如果是完全替换画面可以直接丢弃原始帧用自定义pixelBuffer }第二类是不启动摄像头完全用虚拟帧源。这适用于“视频源根本就不是摄像头”的场景比如播放一段MP4当成摄像头画面。做法是不加AVCaptureDeviceInput只加AVCaptureVideoDataOutput然后通过AVAssetWriter或直播SDK的customVideoSource接口主动投递帧。第二类方案有个适配问题AVCaptureSession没有输入设备时startRunning()会报错或不产生回调。所以工程上通常做法是设备输入用前置/后置摄像头占位同时在回调里用虚拟帧完全替换或者直接用直播SDK的定制采集接口不走AVCaptureSession。我用过的腾讯TRTC、声网Agora都支持customVideoSource直接设一个视频源回调把帧塞进去就行。如果你的项目是接微信小程序或系统原生相机那么只能用第一类必须有一个真实摄像头在跑否则系统不会给App激活采集链路。这在iOS模拟器上尤其明显模拟器本身没有摄像头时AVCaptureSession经常处于不可用状态。3. 系统级路线模拟器与越狱Tweak注入的真实边界3.1 iOS模拟器上的摄像头模拟Xcode的iOS模拟器其实有自己的一套“虚拟摄像头”机制只不过它模拟的是“摄像头不可用”或“使用Mac摄像头”。模拟器不会给你一个配置界面去添加虚拟视频源但你可以通过修改模拟器的AVCaptureDevice状态来调试部分逻辑。实操中如果模拟器代码里有AVCaptureDevice.authorizationStatus(for: .video)判断模拟器通常会返回.authorized但设备列表为空。所以测试时要先处理“没有摄像头”的分支否则模拟器一启动就崩。更进阶的做法是用simctl的io命令给模拟器注入图片作为摄像头画面实测不可行至少主流Xcode版本里没有公开的这个能力。有团队通过改模拟器运行时SimulatorKit来实现但那属于深度逆向模拟器框架投入产出比极低不推荐。3.2 越狱Tweak注入的工作原理与Hook点要实现“微信也能看到虚拟摄像头”必须走越狱Tweak注入。核心思路不是去写一个摄像头驱动而是hook掉App请求摄像头时的关键方法把返回的AVCaptureDevice替换成我们的虚拟数据源。原理上分三步用Theos或其他工具链写一个dylib插件注入到目标App进程。hookAVCaptureDevice的defaultDevice(forDeviceType:mediaType:position:)或devices()类方法让它返回一个我们自定义的“虚拟设备”。这个虚拟设备通常不是真的AVCaptureDevice子类而是通过AVCaptureDeviceInput的init方法做替换或者直接hookAVCaptureSession的startRunning在采集回调里替换帧。真实写起来会发现一堆问题签名校验、偏移量适配、进程注入时机、App的越狱检测、get-task-allow权限等等。我个人的态度是如果只是为了自己调试或学习可以试如果想商用发布不要碰。苹果对越狱环境的App审核是零容忍而且iOS每个大版本的系统服务内部实现都变你维护一套Tweak插件跨版本兼容的成本远超它带来的收益。3.3 给“系统级路线”的底线建议如果你确实需要“全局虚拟摄像头”效果又不愿意碰越狱更现实的路线是走硬件采集卡或外部设备比如用支持UVC协议的HDMI采集棒接iOS设备再通过lightning转接头导入。这条路依赖硬件但稳定、合规、不需要越狱只是iOS对UVC外置摄像头的支持一直比较挑设备不是所有采集卡都能被识别。所以“iOS虚拟摄像头插件”这个标题答案从来不是“能不能”而是“你愿意接受哪层限制”。App内自采集是最推荐的正路越狱Tweak是极客的游乐场硬件方案是合规妥协。4. 调试链路与签名配置我踩过的四个坑4.1 坑一NSCameraUsageDescription缺失导致崩溃这个问题看起来基础但我在换新工程时经常忘。iOS 10之后只要App调用AVCaptureDevice请求摄像头权限Info.plist里必须有NSCameraUsageDescription否则系统直接崩溃连弹窗都不给你。keyNSCameraUsageDescription/key string需要使用摄像头来提供虚拟视频源/string注意模拟器上请求摄像头权限时某些系统版本不会弹窗而是直接返回restricted这是正常现象不用怀疑代码写错了。4.2 坑二帧率与像素格式不匹配导致黑屏如果你往AVCaptureVideoDataOutput里丢的像素缓冲格式和预期的videoSettings不一致经常会出现“看起来在采集但输出黑屏”的诡异问题。我遇到过最典型的是后台把像素格式设为kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange而我投递的是BGRA缓冲导致部分编码器兼容性差。统一做法是主动设置videoSettings为[kCVPixelBufferPixelFormatTypeKey as String: kCVPixelFormatType_32BGRA]虚拟帧全部用BGRA生成最后让编码器转换。色域和编码兼容性会好很多。4.3 坑三CVPixelBufferPool阻塞和过度分配CVPixelBufferPoolCreatePixelBuffer在池满时会阻塞线程这个坑在低端机型上特别明显。如果回调里同步生成帧很容易拖垮采集线程。解决办法有两个一是把CVPixelBufferPoolAllocationThresholdKey调大预分配更多缓冲二是生成帧的操作放到串行队列异步执行采集线程只做IO不做合成。实测下来用第二种方式帧率稳定性提升明显。4.4 坑四模拟器与真机的采集链差异同一个App在模拟器和真机上的采集状态完全不一致。模拟器上AVCaptureSession的isRunning经常是false但不会走错误回调真机上则正常。调试虚拟帧时我建议直接真机调试别在模拟器上浪费时间。真机调试还需要注意签名方式开发签名用get-task-allow可以正常挂载Xcode调试器分发签名则不行。你如果做Tweak插件调试签名要求更复杂这里不展开但记住一点Xcode的Debug包和Release包在虚拟帧调试时行为完全不同一定要用Release配置多测一遍。5. 项目回顾与适用边界5.1 这套方案能做什么用第二章节的App内虚拟采集源你可以做出这些实际功能直播前预览合成画面叠加品牌水印和滚动字幕。视频会议App内自定义背景图替代系统绿幕抠像。自动化UI测试时用固定测试图卡替代真实摄像头保证测试可重复。远程运维场景把监控视频流接入直播SDK当作摄像头源输出。以上这些场景核心都是“视频帧的生产和消费都在App的采集管线里”这也是我认为iOS虚拟摄像头插件最健康、最可维护的形态。5.2 这类插件不该拿去做什么务必提一个红线不要用它来做身份认证欺骗比如替换人脸识别帧、伪造身份证拍照画面。这类做法既违反App审核规则也可能触犯法律。技术本身是中性的但虚拟摄像头天然带有伪造属性使用场景必须局限在合成、测试、娱乐向的内容生产。5.3 我的真实体会踩过一轮坑之后我对iOS虚拟摄像头的看法是它的价值不在“欺骗摄像头”而在“扩展摄像头”。当你把视频帧当成数据流而不是硬件信号时可供发挥的空间其实非常大。用AVFoundationCoreImage已经能搞定大部分特效、合成、推流需求真要系统级全局生效先考虑硬件采集再评估越狱成本。如果你正在规划类似项目我的建议是先花两天把App内自采集管线跑通再问自己“到底需不需要全局生效”。大多数时候答案是不需要。本文还有配套的精品资源点击获取 iOS虚拟摄像头实现全解析：从AVFoundation到越狱Tweak注入
简介面向iOS开发与逆向工程人员的虚拟摄像头插件源码包聚焦通过MobileSubstrate注入系统相机进程并Hook AVCaptureSession相关方法实现视频流替换与自定义视频源接入。资源共5个文件压缩包仅15KB含2个HTML说明文档、1个JavaScript脚本及工程配置文件结构精简便于快速查看核心实现思路。核心代码基于AVCaptureVideoDataOutputSampleBufferDelegate协议完成视频帧替换并演示SwiftUI摄像头应用中的摄像头切换、滤镜选择与视频源配置视频选择部分使用PHPickerViewController选取本地视频结合UISlider实现时长控制与裁剪导出。目前已有245人学习下载适合具备一定iOS基础和逆向经验的开发者作为技术参考。 上周有个做直播工具的朋友跑来问我iOS上能不能像电脑一样装个虚拟摄像头插件把合成画面喂给微信视频或抖音直播我第一反应是“想都别想”但仔细捋了一遍iOS的摄像头采集链路和插件化机制后发现这事得拆成三四个层级来看。被追问多了索性把整个思路和能落地的代码方向整理成这篇东西给同样在做iOS虚拟摄像头相关需求的人做个参考。说清楚一点这篇文章讲的不是“破解系统”那种黑魔法而是基于iOS现有公开能力把“虚拟摄像头”这个概念落到可运行的方案上。你会看到为什么iOS不像macOS那样有现成的DAL驱动机制也会看到在不越狱、半越狱、App内自采集三种路径下各自的代码写法和工程取舍。适合正在做iOS直播辅助、自动化测试、视频源模拟的开发者也适合想搞清楚“iOS虚拟摄像头到底能不能做”的产品经理。1. iOS摄像头服务链路与“虚拟”的三个层级1.1 一条正常采集链路是怎么走的要理解“虚拟摄像头”在iOS上意味着什么先得看原生采集链路。iOS的摄像头采集大致分四层硬件层物理摄像头传感器通过ISP图像信号处理器输出RAW或YUV数据。系统服务层mediaserverd、runningboardd等进程管理采集会话摄像头权限由TCCTransparency, Consent, and Control框架管控。框架层AVFoundation对上层提供AVCaptureDevice、AVCaptureSession等APIApp在这里拿到视频流。应用层微信、抖音、直播SDK最终通过AVCaptureVideoDataOutput或AVCaptureMovieFileOutput拿帧做编码和推流。注意一个关键点iOS的摄像头服务是系统级单例任何一个App请求摄像头时系统会弹TCC授权框授权后由mediaserverd分路输出。整个过程没有像Windows那样暴露“虚拟驱动”接口也没有macOS的CoreMediaIO DAL插件机制。所以想在iOS上搞一个“系统全局都能看到的虚拟摄像头”本质上是在挑战系统架构而不是写一个普通插件。1.2 “虚拟摄像头”的三个层级基于上面的链路我通常把“iOS虚拟摄像头”拆成三个层级App内虚拟源在你自己App的AVCaptureSession里用AVCaptureDeviceInput之外的source替换成合成画面。直播SDK、录制SDK、美颜SDK都能拿到这个“虚拟画面”。这是最干净、可控性最高、完全合规的做法。系统级插件通过越狱Tweak注入到SpringBoard或mediaserverdhook摄像头创建流程把某个App的摄像头请求重定向到我们的虚拟内容。这个层级最接近“虚拟摄像头插件”这个标题但门槛高、稳定性差、审核风险大。远端/网络摄像头模拟把另一台设备或PC上的视频流通过网络输送到iOS端在App内解码后作为采集源。典型如Camo、EpocCam这类把iPhone当Mac摄像头的应用反向来做也能实现iOS端接收虚拟流。这篇博文主推第1层因为第2层涉及越狱环境第3层更多是网络传输方案。第2层我会讲清楚原理和hook点但不会给你一份可以直接放在Cydia里跑的完整插件——那个东西调试起来很痛苦而且不同iOS版本的偏移量和签名要求完全不同。1.3 为什么iOS不能像桌面系统一样直接装驱动桌面系统能虚拟摄像头靠的是操作系统提供了驱动抽象层Windows有DirectShow/Kernel StreamingmacOS有CoreMediaIO DAL。驱动开发者只要实现一套设备接口系统就把它当成一个真实摄像头暴露给所有App。iOS把这个口子焊死了。App Store审核规则不允许第三方安装系统级驱动摄像头硬件的独占策略也是系统统一调度的。苹果这么做是从隐私和稳定性出发一个App拿到的摄像头画面理论上不应当被另一个App截获或篡改。所以“iOS虚拟摄像头插件”这个需求第一关不是技术而是系统机制。2. 代码实操用AVFoundation搭一个App内虚拟采集源2.1 为什么这条路最值得先做如果你是想在直播、视频会议、自动化测试场景里使用虚拟摄像头App内自采集是性价比最高的方案。原因有三不需要越狱工程链路上只有Xcode签名帧数据完全掌握在自己手里可以叠加水印、更换背景、插入动画代码量可控核心逻辑大约两三百行就能跑通。它的局限也很明确只有你的App能看见这个虚拟画面。你不能让微信视频通话直接显示你的合成画面因为微信跑在独立进程里不会加载你写的采集代码。如果你确实需要“全局生效”那就得跳到第3章的越狱方案。先把App内方案吃透再谈系统级这是我个人强烈建议的顺序。2.2 核心代码骨架自定义帧源替换摄像头输入AVFoundation虽然不直接支持“虚拟设备”但它有个很大的容忍度你可以在AVCaptureVideoDataOutput的代理回调里拿到CMSampleBuffer然后自由修改像素内容再交给编码器。换句话说你把摄像头帧拦截下来做任意合成再输出出去。这其实已经是事实上的“虚拟摄像头”了。先看一个最基础的帧合成代码import AVFoundation import CoreVideo final class VirtualFrameFactory { private var pixelBufferPool: CVPixelBufferPool? func makeFrame(width: Int 1280, height: Int 720) - CVPixelBuffer? { let attrs: [String: Any] [ kCVPixelBufferPixelFormatTypeKey as String: kCVPixelFormatType_32BGRA, kCVPixelBufferWidthKey as String: width, kCVPixelBufferHeightKey as String: height, kCVPixelBufferPoolAllocationThresholdKey as String: 6 ] CVPixelBufferPoolCreate(nil, nil, attrs as CFDictionary, pixelBufferPool) guard let pool pixelBufferPool else { return nil } var pixelBuffer: CVPixelBuffer? CVPixelBufferPoolCreatePixelBuffer(nil, pool, pixelBuffer) return pixelBuffer } func drawSolidColor(on buffer: CVPixelBuffer, color: (CGFloat, CGFloat, CGFloat)) { CVPixelBufferLockBaseAddress(buffer, []) defer { CVPixelBufferUnlockBaseAddress(buffer, []) } guard let baseAddress CVPixelBufferGetBaseAddress(buffer) else { return } let bytesPerRow CVPixelBufferGetBytesPerRow(buffer) let width CVPixelBufferGetWidth(buffer) let height CVPixelBufferGetHeight(buffer) // 这里用CoreGraphics/CoreImage绘制到你想要的内容 let context CGContext( data: baseAddress, width: width, height: height, bitsPerComponent: 8, bytesPerRow: bytesPerRow, space: CGColorSpaceCreateDeviceRGB(), bitmapInfo: CGImageAlphaInfo.premultipliedFirst.rawValue | CGBitmapInfo.byteOrder32Little.rawValue ) context?.setFillColor(red: color.0, green: color.1, blue: color.2, alpha: 1.0) context?.fill(CGRect(x: 0, y: 0, width: width, height: height)) } }这段代码做了三件事创建CVPixelBufferPool复用缓冲区从池里取一块像素缓冲用CGContext往缓冲里画纯色。实际项目中你在这里画的不只是纯色可以是用CoreImage叠加的实时摄像头特效也可以是从视频文件AVAssetReader读出的帧或者是网络流解码后的画面。关键点在于CVPixelBufferPoolCreate。我见过很多新手直接CVPixelBufferCreate一帧帧分配结果内存暴涨、掉帧严重。用池化复用能显著降低性能损耗这个在帧率要求高的场景是必须的。2.3 把合成帧输送给上层录制或直播SDK帧工厂准备好之后下一步是替换摄像头采集输出。方法有两类第一类是直接在采集回调里改帧func captureOutput(_ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection) { // 拿到原始帧 guard let pixelBuffer CMSampleBufferGetImageBuffer(sampleBuffer) else { return } // 用第2.2节的工具做合成 // 注意如果只是加滤镜可以直接用CoreImage处理pixelBuffer // 如果是完全替换画面可以直接丢弃原始帧用自定义pixelBuffer }第二类是不启动摄像头完全用虚拟帧源。这适用于“视频源根本就不是摄像头”的场景比如播放一段MP4当成摄像头画面。做法是不加AVCaptureDeviceInput只加AVCaptureVideoDataOutput然后通过AVAssetWriter或直播SDK的customVideoSource接口主动投递帧。第二类方案有个适配问题AVCaptureSession没有输入设备时startRunning()会报错或不产生回调。所以工程上通常做法是设备输入用前置/后置摄像头占位同时在回调里用虚拟帧完全替换或者直接用直播SDK的定制采集接口不走AVCaptureSession。我用过的腾讯TRTC、声网Agora都支持customVideoSource直接设一个视频源回调把帧塞进去就行。如果你的项目是接微信小程序或系统原生相机那么只能用第一类必须有一个真实摄像头在跑否则系统不会给App激活采集链路。这在iOS模拟器上尤其明显模拟器本身没有摄像头时AVCaptureSession经常处于不可用状态。3. 系统级路线模拟器与越狱Tweak注入的真实边界3.1 iOS模拟器上的摄像头模拟Xcode的iOS模拟器其实有自己的一套“虚拟摄像头”机制只不过它模拟的是“摄像头不可用”或“使用Mac摄像头”。模拟器不会给你一个配置界面去添加虚拟视频源但你可以通过修改模拟器的AVCaptureDevice状态来调试部分逻辑。实操中如果模拟器代码里有AVCaptureDevice.authorizationStatus(for: .video)判断模拟器通常会返回.authorized但设备列表为空。所以测试时要先处理“没有摄像头”的分支否则模拟器一启动就崩。更进阶的做法是用simctl的io命令给模拟器注入图片作为摄像头画面实测不可行至少主流Xcode版本里没有公开的这个能力。有团队通过改模拟器运行时SimulatorKit来实现但那属于深度逆向模拟器框架投入产出比极低不推荐。3.2 越狱Tweak注入的工作原理与Hook点要实现“微信也能看到虚拟摄像头”必须走越狱Tweak注入。核心思路不是去写一个摄像头驱动而是hook掉App请求摄像头时的关键方法把返回的AVCaptureDevice替换成我们的虚拟数据源。原理上分三步用Theos或其他工具链写一个dylib插件注入到目标App进程。hookAVCaptureDevice的defaultDevice(forDeviceType:mediaType:position:)或devices()类方法让它返回一个我们自定义的“虚拟设备”。这个虚拟设备通常不是真的AVCaptureDevice子类而是通过AVCaptureDeviceInput的init方法做替换或者直接hookAVCaptureSession的startRunning在采集回调里替换帧。真实写起来会发现一堆问题签名校验、偏移量适配、进程注入时机、App的越狱检测、get-task-allow权限等等。我个人的态度是如果只是为了自己调试或学习可以试如果想商用发布不要碰。苹果对越狱环境的App审核是零容忍而且iOS每个大版本的系统服务内部实现都变你维护一套Tweak插件跨版本兼容的成本远超它带来的收益。3.3 给“系统级路线”的底线建议如果你确实需要“全局虚拟摄像头”效果又不愿意碰越狱更现实的路线是走硬件采集卡或外部设备比如用支持UVC协议的HDMI采集棒接iOS设备再通过lightning转接头导入。这条路依赖硬件但稳定、合规、不需要越狱只是iOS对UVC外置摄像头的支持一直比较挑设备不是所有采集卡都能被识别。所以“iOS虚拟摄像头插件”这个标题答案从来不是“能不能”而是“你愿意接受哪层限制”。App内自采集是最推荐的正路越狱Tweak是极客的游乐场硬件方案是合规妥协。4. 调试链路与签名配置我踩过的四个坑4.1 坑一NSCameraUsageDescription缺失导致崩溃这个问题看起来基础但我在换新工程时经常忘。iOS 10之后只要App调用AVCaptureDevice请求摄像头权限Info.plist里必须有NSCameraUsageDescription否则系统直接崩溃连弹窗都不给你。keyNSCameraUsageDescription/key string需要使用摄像头来提供虚拟视频源/string注意模拟器上请求摄像头权限时某些系统版本不会弹窗而是直接返回restricted这是正常现象不用怀疑代码写错了。4.2 坑二帧率与像素格式不匹配导致黑屏如果你往AVCaptureVideoDataOutput里丢的像素缓冲格式和预期的videoSettings不一致经常会出现“看起来在采集但输出黑屏”的诡异问题。我遇到过最典型的是后台把像素格式设为kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange而我投递的是BGRA缓冲导致部分编码器兼容性差。统一做法是主动设置videoSettings为[kCVPixelBufferPixelFormatTypeKey as String: kCVPixelFormatType_32BGRA]虚拟帧全部用BGRA生成最后让编码器转换。色域和编码兼容性会好很多。4.3 坑三CVPixelBufferPool阻塞和过度分配CVPixelBufferPoolCreatePixelBuffer在池满时会阻塞线程这个坑在低端机型上特别明显。如果回调里同步生成帧很容易拖垮采集线程。解决办法有两个一是把CVPixelBufferPoolAllocationThresholdKey调大预分配更多缓冲二是生成帧的操作放到串行队列异步执行采集线程只做IO不做合成。实测下来用第二种方式帧率稳定性提升明显。4.4 坑四模拟器与真机的采集链差异同一个App在模拟器和真机上的采集状态完全不一致。模拟器上AVCaptureSession的isRunning经常是false但不会走错误回调真机上则正常。调试虚拟帧时我建议直接真机调试别在模拟器上浪费时间。真机调试还需要注意签名方式开发签名用get-task-allow可以正常挂载Xcode调试器分发签名则不行。你如果做Tweak插件调试签名要求更复杂这里不展开但记住一点Xcode的Debug包和Release包在虚拟帧调试时行为完全不同一定要用Release配置多测一遍。5. 项目回顾与适用边界5.1 这套方案能做什么用第二章节的App内虚拟采集源你可以做出这些实际功能直播前预览合成画面叠加品牌水印和滚动字幕。视频会议App内自定义背景图替代系统绿幕抠像。自动化UI测试时用固定测试图卡替代真实摄像头保证测试可重复。远程运维场景把监控视频流接入直播SDK当作摄像头源输出。以上这些场景核心都是“视频帧的生产和消费都在App的采集管线里”这也是我认为iOS虚拟摄像头插件最健康、最可维护的形态。5.2 这类插件不该拿去做什么务必提一个红线不要用它来做身份认证欺骗比如替换人脸识别帧、伪造身份证拍照画面。这类做法既违反App审核规则也可能触犯法律。技术本身是中性的但虚拟摄像头天然带有伪造属性使用场景必须局限在合成、测试、娱乐向的内容生产。5.3 我的真实体会踩过一轮坑之后我对iOS虚拟摄像头的看法是它的价值不在“欺骗摄像头”而在“扩展摄像头”。当你把视频帧当成数据流而不是硬件信号时可供发挥的空间其实非常大。用AVFoundationCoreImage已经能搞定大部分特效、合成、推流需求真要系统级全局生效先考虑硬件采集再评估越狱成本。如果你正在规划类似项目我的建议是先花两天把App内自采集管线跑通再问自己“到底需不需要全局生效”。大多数时候答案是不需要。本文还有配套的精品资源点击获取