做 Unity 移动端开发的人迟早会碰上一个绕不过去的需求游戏里要拍照、要选图、要识别二维码结果发现Unity 自己没有一套能直接调起 iOS 系统相机和相册的官方接口。社区里是有现成插件但插件一多维护成本就上来了功能定制也放不开手脚。我这次接手的项目就是把 Unity 和 iOS 原生之间的通道彻底打通在 Unity 里调起系统相机拍照、打开系统相册选图再拿回 Unity 里做显示和处理。顺手写了一整套原生桥接方案从 Objective-C 插件到 C# 回调都理了一遍这篇文章就是把完整实现过程和踩过的坑记录下来给正在卡这一关的同学一份能直接照着抄的作业。适合 Unity 客户端工程师、做原生联调的开发者以及想了解 Unity 与 iOS 原生数据传递原理的团队参考。1. 交互方案选型为什么必须写原生桥接层1.1 Unity 没有“内置相机相册”接口Unity 在 Android 端其实提供了一部分运行时权限申请的能力也能通过CameraDevice或一些实验性 Package 访问摄像头画面但要“调起系统相机应用拍照并返回图片”Unity 本身没有统一封装。iOS 上更直接——苹果没有开放任何接口给 Unity 运行时直接弹起 UIImagePickerController 或者 PHPicker你必须在 Objective-C / Swift 层写一个原生插件由 Unity 调用原生方法原生层弹出系统页面拿到结果后再回传给 Unity。这中间绕不开的桥梁是 UnityEngine 的[DllImport(__Internal)]和 iOS 原生的UnitySendMessage。有些同学会问为什么不用 Unity 的NativeCamera这类第三方插件我的看法是第三方插件确实开箱即用但如果你需要在拍照后做定制裁剪、需要调整相册多选逻辑、或者要跟既有 Native SDK 共用回调通道插件反而会成为限制。自研桥接层虽然前期多花一点时间但后续所有 iOS 原生能力比如日历、通讯录、扫码都能沿着这套通道扩展性价比非常高。1.2 两种原生桥接架构插件式与宿主式先说清楚Unity 与 iOS 原生交互有两种主流架构不同项目选型不一样。第一种是做iOS Native Plugin把写好的 Objective-C 文件放到Assets/Plugins/iOS/目录Unity 打包 Xcode 工程时会自动编译并链接进 App。Unity 侧用[DllImport(__Internal)]声明外部方法运行时直接调用原生函数原生侧拿到数据后通过UnitySendMessage把结果广播回 Unity 场景里的某个 GameObject。这种做法实现简单适合 Unity 作为主导、原生只承担辅助能力的项目。第二种是Unity as a Library也就是把 Unity 打包成 Framework嵌入到原生 iOS App 工程里由原生 App 作为宿主来驱动 Unity 内容。这种架构适合原生 App 里某个模块是 Unity 渲染、或者需要原生层长期持有 Unity 生命周期控制的场景。它也能做双向交互但配置复杂度高很多Unity 生命周期、内存管理、场景切换都得更小心。本项目采用第一种原因很直接Unity 内容占主导原生只需要提供相机相册这种系统能力用插件式桥接最少代码、最快见效。1.3 UnitySendMessage 双向通信机制理清UnitySendMessage是理解整个方案的关键。它本质上是原生代码向 Unity 发送消息的 C 接口原型如下void UnitySendMessage(const char* obj, const char* method, const char* msg);参数分别是场景中接收消息的 GameObject 名称、该 GameObject 上挂载的脚本方法名、要传递的字符串消息。原生层拿到照片后把照片存到临时文件或者压缩成 Base64 字符串通过这个方法把数据或者路径传给 Unity 里的 C# 方法。这里有两个很容易踩的坑一是 GameObject 名称必须跟场景里实际对象名字完全一致大小写都不能错而且这个 GameObject 必须处于激活状态二是 C# 接收方法的访问权限建议写成public或者至少能被反射到方法名也要与原生端传入的字符串完全对应。我在第一次联调时就因为把脚本挂在了一个SetActive(false)的节点上结果回调一直没触发排查了半天。还有一点UnitySendMessage传递的是字符串。如果要传一张图片最稳妥的方案不是把图片整个 Base64 编码成超长字符串而是把图片写入临时目录把文件路径传给 Unity再由 C# 异步加载。这个选择会影响内存峰值后面会详细对比。2. 原生侧实现Objective-C 调用系统相机和相册2.1 插件工程结构与源码组织在 Unity 里新建Assets/Plugins/iOS目录把原生源码放进去。Unity 会把这个目录下的.h、.m、.mm文件全部自动加入生成的 Xcode 工程不需要再手动拖文件。我通常在这个目录下建三个文件NativeBridge.h公共头文件暴露给 Unity 调用的 C 接口。NativeBridge.mm实现文件。注意这里我用.mm后缀而不是.m是因为后续可能需要混合 C 代码或引用其他 C 库Objective-C后缀兼容面更宽。NativeBridgeDelegate可选如果要处理更复杂的回调可以单独抽出协议类但当前项目规模不大我直接在.mm里实现了 delegate。核心 C 接口命名遵循 Unity 的 DllImport 规则必须是 C 风格函数。比如// NativeBridge.h #ifndef NativeBridge_h #define NativeBridge_h #ifdef __cplusplus extern C { #endif void _UnityCallCamera(const char* gameObjectName, const char* callbackMethod); void _UnityCallPhotoLibrary(const char* gameObjectName, const char* callbackMethod); void _UnitySaveImageToAlbum(const char* imagePath); #ifdef __cplusplus } #endif #endif /* NativeBridge_h */extern C很重要因为.mm是 Objective-C 编译环境不包一层的话链接阶段会找不到符号Unity 侧[DllImport]会直接报EntryPointNotFoundException。2.2 相机权限与 Info.plist 配置iOS 调起系统相机前必须先在 Info.plist 里声明相机用途描述否则 App 会直接崩溃。用 Unity 打包时你可以在 Unity 的 Player Settings 里打开Other Settings Configuration Camera Usage Description直接填描述文本它会自动写入最终生成的 Info.plist。相册相关的描述同样在这里配置字段对应关系如下功能Info.plist Key是否必需用途说明调起系统相机NSCameraUsageDescription必需说明 App 为什么需要使用相机读取系统相册老 APINSPhotoLibraryUsageDescription必需UIImagePickerController 读相册时的权限保存图片到相册NSPhotoLibraryAddUsageDescriptioniOS 11 必需添加图片到相册的权限声明使用 PHPicker 选图无需权限可选iOS 14 新相册选择器默认无需授权配置文案要写得真实具体比如“需要拍摄照片用于上传头像”“需要保存图片到你的相册”这样审核和用户弹窗都能过。如果只配置了相机权限却没配相册权限用户点“相册”按钮时会出现无权限或崩溃的诡异现象排查步骤我会放在第 4 章。2.3 用 UIImagePickerController 实现相机功能相机功能的传统实现方式是用UIImagePickerController。这类控制器是系统原生页面我们只需要设置sourceType为相机设置代理然后从当前 Unity 的根控制器 present 出来。// NativeBridge.mm 中的相机调用逻辑 static NSString *g_callbackObjectName; static NSString *g_callbackMethodName; void _UnityCallCamera(const char* gameObjectName, const char* callbackMethod) { g_callbackObjectName [NSString stringWithUTF8String:gameObjectName]; g_callbackMethodName [NSString stringWithUTF8String:callbackMethod]; dispatch_async(dispatch_get_main_queue(), ^{ if (![UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera]) { [self sendErrorToUnity:Camera source type not available]; return; } UIImagePickerController *picker [[UIImagePickerController alloc] init]; picker.sourceType UIImagePickerControllerSourceTypeCamera; picker.delegate self; picker.allowsEditing NO; UIViewController *rootVC UnityGetGLViewController(); [rootVC presentViewController:picker animated:YES completion:nil]; }); }注意两点。第一dispatch_async(dispatch_get_main_queue(), ...)是必须的因为从 Unity 侧通过 DllImport 调过来时可能不在主线程UI 操作必须回主线程执行。第二UnityGetGLViewController()是 Unity 在 iOS 上暴露的全局接口返回当前 Unity 视图控制器用它来 present 系统页面才能保证层级正确。相机代理回调里拍摄完成后系统会返回UIImage对象。在didFinishPickingMediaWithInfo方法里拿到原始图片后我一般先压缩再落盘然后传路径给 Unity- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionaryUIImagePickerControllerInfoKey,id *)info { UIImage *image info[UIImagePickerControllerOriginalImage]; [picker dismissViewControllerAnimated:YES completion:^{ NSString *path [self saveImageToTemporary:image]; [self notifyUnity:path]; }]; // 相册逻辑用 PHPicker 处理见下文 }这里有个细节必须在dismissViewControllerAnimated:completion:的 completion 回调里执行后续发送动作不要直接 dismiss 完就发消息否则 Unity 侧可能因为视图切换动画还没结束而出现界面卡顿。2.4 相册功能老 API 与新 API 的选择相册选图有两种实现方案选择直接影响权限配置和用户体验。老方案同样用UIImagePickerController把sourceType设为UIImagePickerControllerSourceTypePhotoLibrary。这个方案兼容 iOS 8 到 iOS 13但也受相册权限约束如果用户拒绝权限选择器无法正常显示。新方案是 iOS 14 引入的PHPickerViewController苹果专门针对隐私做了一版新相册选择器它的最大好处是不需要 App 申请相册权限——系统会为这个选择器单独提供一份隔离的相册视图App 拿到的只是用户明确选择出来的资源。这意味着即使用户在设置里关闭了相册权限PHPicker 依然能用。我强烈建议新项目直接用 PHPicker。除了权限优势它还原生支持多选、搜索、按相册分类并且是在独立进程渲染的即使 App 自身内存吃紧选图过程也不会因为加载原图而撑爆内存。实现代码相对简洁void _UnityCallPhotoLibrary(const char* gameObjectName, const char* callbackMethod) { g_callbackObjectName [NSString stringWithUTF8String:gameObjectName]; g_callbackMethodName [NSString stringWithUTF8String:callbackMethod]; dispatch_async(dispatch_get_main_queue(), ^{ PHPickerConfiguration *config [[PHPickerConfiguration alloc] init]; config.filter [PHPickerFilter imagesFilter]; // 只显示图片也可以配 videosFilter config.selectionLimit 1; // 多选时设置更大比如 9 PHPickerViewController *picker [[PHPickerViewController alloc] initWithConfiguration:config]; picker.delegate self; UIViewController *rootVC UnityGetGLViewController(); [rootVC presentViewController:picker animated:YES completion:nil]; }); }PHPicker 的代理回调拿到的是NSItemProvider需要用异步方式加载图片数据- (void)picker:(PHPickerViewController *)picker didFinishPicking:(NSArrayPHPickerResult * *)results { [picker dismissViewControllerAnimated:YES completion:nil]; NSItemProvider *provider results.firstObject.itemProvider; if ([provider canLoadObjectOfClass:[UIImage class]]) { [provider loadObjectOfClass:[UIImage class] completion:^(idNSItemProviderReading object, NSError *error) { UIImage *image (UIImage *)object; NSString *path [self saveImageToTemporary:image]; [self notifyUnity:path]; }]; } }注意这里 loadObjectOfClass 的回调线程不固定而UnitySendMessage虽然可以在任意线程调用但 Unity 侧回调接收时可能涉及 Unity 主线程的操作稳妥做法是在回调里强制切回主线程或者让 C# 侧用一个队列缓冲处理。我习惯在原生层直接做一次dispatch_async(dispatch_get_main_queue())保证发到 Unity 的数据一定在主线程上下文触发。2.5 数据传递策略文件路径优于 Base64拿到UIImage之后有两个回传方案。方案一是将图片转成 PNG/JPEG 数据再 Base64 编码成字符串通过UnitySendMessage直接传给 Unity。方案二是把图片压缩后写入临时目录回传文件路径C# 侧再异步读取。一次拍照的 JPEG 数据可能在 2MB ~ 7MB 之间Base64 编码会再膨胀约 33%这个超长字符串如果通过UnitySendMessage传输内存分配和字符串复制都非常浪费。更关键的是 C# 侧拿到 Base64 要先Convert.FromBase64String转成字节数组字符串驻留期间整个流程的峰值内存会很难看。我选文件路径方案原生层把图片压缩到宽边不超过 2048、JPEG 压缩质量 0.8再写到NSTemporaryDirectory()下带 UUID 的文件。这样传给 Unity 的只是几十个字符的路径Unity 侧用File.ReadAllBytes或者UnityWebRequest的file://协议读取内存易控还能方便后续扩展上传、缓存等逻辑。唯一的缺点是临时目录需要定期清理这个在 C# 侧每次读取完删除即可。3. C# 侧对接DllImport、回调与图片显示3.1 用 DllImport 声明原生入口C# 侧首先要声明原生函数入口。这里必须用__Internal作为库名这是 Unity 在 iOS 上的特殊约定表示从当前可执行文件里查找符号public class NativeBridge { #if UNITY_IPHONE !UNITY_EDITOR [DllImport(__Internal)] private static extern void _UnityCallCamera(string gameObjectName, string callbackMethod); [DllImport(__Internal)] private static extern void _UnityCallPhotoLibrary(string gameObjectName, string callbackMethod); #endif public static void OpenCamera(string callbackObjectName, string callbackMethod) { #if UNITY_IPHONE !UNITY_EDITOR _UnityCallCamera(callbackObjectName, callbackMethod); #else Debug.LogError(iOS Native Camera only works on real iOS device.); #endif } public static void OpenPhotoLibrary(string callbackObjectName, string callbackMethod) { #if UNITY_IPHONE !UNITY_EDITOR _UnityCallPhotoLibrary(callbackObjectName, callbackMethod); #else Debug.LogError(iOS Native Photo Library only works on real iOS device.); #endif } }强烈建议把 DllImport 的方法用#if UNITY_IPHONE !UNITY_EDITOR包起来因为编辑器环境下__Internal符号不存在一旦调用就会抛EntryPointNotFoundException。封装成静态方法后再做一次平台判断这样业务层代码不用到处写编译宏。Unity 打包 iOS 时如果勾选了IL2CPP后端还需要留意Managed Stripping Level。如果开到 High 或 MediumC# 回调方法可能会被裁剪掉导致UnitySendMessage找不到对应方法。解决办法是在接收回调的方法上标记[UnityEngine.Scripting.Preserve]特性或者把剥离级别调低。3.2 设计统一回调入口原生层只需要知道两个信息发给哪个 GameObject、调用哪个方法。所以我设计了一个全局的单例作为回调分发器把“接收原生消息”和“业务处理”解耦开。public class NativeBridgeCallback : MonoBehaviour { public static NativeBridgeCallback Instance { get; private set; } private void Awake() { Instance this; } // 相册/相机回调统一入口 public void OnNativeImagePath(string path) { if (string.IsNullOrEmpty(path)) { Debug.LogError(Native returned empty image path.); return; } StartCoroutine(LoadImageAndNotify(path)); } private IEnumerator LoadImageAndNotify(string path) { byte[] bytes File.ReadAllBytes(path); Texture2D tex new Texture2D(2, 2, TextureFormat.RGBA32, false); if (!tex.LoadImage(bytes)) { Debug.LogError(Failed to load image from path: path); yield break; } NativeImageEvent?.Invoke(tex); // 清理临时文件 if (File.Exists(path)) File.Delete(path); } public event System.ActionTexture2D NativeImageEvent; }这里有几个设计点值得说明。一是用MonoBehaviour的协程加载图片避免大图片在主线程同步解码造成卡顿。二是Texture2D.LoadImage是 Unity 内置方法能自动处理 PNG/JPEG 解码不需要额外引入第三方库。三是如果业务层需要背景透明图要在创建 Texture2D 时指定TextureFormat.RGBA32不要用默认格式否则 PNG 的 Alpha 通道可能丢失。场景里必须保证有一个激活的 GameObject 挂着NativeBridgeCallback脚本并且它的名字跟原生层传入的gameObjectName完全一致。我通常在启动场景创建这个对象并调用DontDestroyOnLoad这样即使后续场景切换回调入口也不会丢。3.3 摄像头权限申请与运行时状态处理iOS 上应用只有在用户点击某个 UI 时才应该触发相机或相册调用因为系统弹窗必须附着在可见视图层级上。千万不要在Awake或Start里直接调OpenCamera这会导致弹窗时机不对系统在弹出权限询问框之前视图层级还没准备好原生层调用presentViewController会失败。另外当原生相机页面弹出时Unity 正在渲染的图形上下文会被系统打断。iOS 会自动处理这个生命周期回调OnApplicationPause(true)等用户拍完照或选完图关闭选择器后再回调OnApplicationPause(false)。这时候注意不要在暂停期间做繁重的资源加载或网络请求恢复时做一次必要的界面刷新即可。private void OnApplicationPause(bool pause) { if (!pause) { // 从系统页面返回 Unity此时可以重启摄像头预览或刷新 UI Debug.Log(Back to Unity from native page.); } }这个暂停事件在某些 iPad 多任务场景下也会触发比如用户把 App 切到 Slide Over 模式系统页面并未完全关闭。建议在这类场景下做一个页面前进状态的标记避免用户多次触发相机导致原生页面重复弹出。3.4 Texture2D 与 UI 显示的内存管理拿到Texture2D后把它赋给 RawImage 显示只是第一步真正的坑在于内存释放。iOS 上每张 iPhone 拍的 JPEG 原图可能接近 4000×3000 像素解码成 Texture2D 后占内存接近 48MB。如果用户连续拍三五张每张都创建新纹理内存瞬间爆掉App 会被系统杀掉。我在实际项目里做了两件事控制内存。第一原生侧落盘前先做尺寸压缩统一收缩到 2048 宽以下这样传到 Unity 的图片最多占 16MB 左右。第二C# 侧在替换旧图时主动Destroy旧纹理不要把引用一直挂在对象上。RawImage 的 texture 赋值前先记下旧的赋值后再销毁顺序不能反。private void SetDisplayImage(Texture2D newTexture) { if (_displayImage ! null) { Destroy(_displayImage); } _displayImage newTexture; _displayRawImage.texture _displayImage; }如果是头像类业务还可以考虑直接生成缩略图再显示大图则用于上传。缩略图通常控制在 256×256用Texture2D内部方法缩放显示效果完全足够内存开销可以忽略不计。4. 常见问题与排查实录4.1 相机唤起后黑屏或直接崩溃真机调试时最容易遇到的现象是相机启动后黑屏或者直接闪退。黑屏多数是因为 Info.plist 缺少相机权限描述系统在弹权限框之前就中止了相机页面渲染。崩溃则可能发生在模拟器上因为UIImagePickerControllerSourceTypeCamera在模拟器里并不可用。建议先检查三个点确认运行在真机确认 Player Settings 里 Camera Usage Description 有实际内容确认原生代码里调用了isSourceTypeAvailable做了前置判断。如果前三点都没问题再看 Unity 和 Xcode 的日志里有没有This app has crashed because it attempted to access privacy-sensitive data without a usage description这类字样有的话就是权限描述缺失。4.2 拍照后回调不触发我遇到的最耗时的排查问题就是拍照完成、图片正常显示在系统预览里但 Unity 界面始终没收到回调。排查下来原因基本都是这三个之一UnitySendMessage传的 GameObject 名称和场景里实际对象名称不一致。接收方法的访问权限不是 public或者方法签名不匹配。接收消息的 GameObject 在某次流程里被SetActive(false)了。最快的排查办法是在原生端UnitySendMessage调用前加一句NSLog把目标对象名和方法名打出来再在 C# 方法里加Debug.Log对照两边日志。如果原生日志显示发送成功但 C# 没打印问题在 C# 侧如果原生日志都打不出来问题在原生调用前就已经出错了。4.3 iOS 14 相册权限弹窗设计变化如果你的 App 用的是老式UIImagePickerController访问相册iOS 14 之后权限行为有变化系统会弹出“选择照片”权限框用户可以选择“允许访问所有照片”或“仅允许部分照片”。如果项目里同时声明了NSPhotoLibraryUsageDescription但用户选择了“部分照片”你所访问到的照片集可能不包含用户刚刚拍摄的照片极容易产生“图片找不到”的 bug。解决办法就是切换到 PHPicker。它不需要读取整个相册也不需要权限声明用户看到的始终是系统自己提供的完整相册视图App 只接收用户选中的那一张。这也是苹果在 WWDC 2020 上多次强调的推荐做法。4.4 Unity 侧内存持续上涨处理大批量图片时内存上涨会变得非常明显。我在一次真机测试循环选图 20 次后发现内存从 200MB 升到 2GB几乎到了被系统强杀的边缘。排查后确认两个元凶一是临时目录的图片文件只写不删导致磁盘压力和内存缓存同时上升二是每次创建的Texture2D没有及时复用或销毁。优化方案是原生侧落盘前做压缩C# 侧读完文件立刻删除临时文件旧纹理在执行新的LoadImage前先Destroy如果用RawImage循环展示多张图建议对象池化避免频繁创建销毁。4.5 模拟器、开发者模式与签名问题联调阶段不可避免要在模拟器上验证 UI 流程。但模拟器不支持调起相机也没有真实相册资源所以业务逻辑可以跑通拍照流程只能真机验证。Xcode 14 之后真机调试默认要求开启开发者模式在设备设置中手动打开“开发者模式”开关否则 Xcode 会报Could not launch because the device is not in Developer Mode的错误。GitHub Actions 远程打包 iOS 也是现在团队里常用的流水线方案这套原生插件代码在 CI 环境同样能正常编译前提是 Xcode 版本与 Unity 打包要求的版本匹配。插件代码本身没有特殊的签名依赖权限描述会透传到最终 Info.plist只要 Xcode 签名配置正确远程打出来的包行为跟本地一致。我在实际项目中体会最深的是Unity 与 iOS 交互这套方案一定要趁早建立“原生回调协议”的意识。刚开始只做拍照和相册时可能直接在 MonoBehaviour 里写死回调方法就够了但一旦后面加入扫码、通讯录、系统设置页跳转等需求回调入口会变得非常混乱。建议所有原生回调统一经过一个静态分发器用事件或委托的方式派发到业务层这样每增加一个新能力只需要扩展原生实现和对应的事件类型C# 侧不会膨胀。最后再分享一个小技巧调试原生插件时不一定要每次都重新打 Xcode 工程可以在 Unity 生成 Xcode 工程后直接用 Xcode 打开并修改原生代码改完用 Xcode 重新 Run 到设备即可不需要回 Unity 重打包。这样原生层的调试迭代速度快很多等整体稳定后再回 Unity 侧做最终打包验证。这套流程用顺了Unity 和 iOS 的交互开发效率能提升一大截。
做 Unity 移动端开发的人迟早会碰上一个绕不过去的需求游戏里要拍照、要选图、要识别二维码结果发现Unity 自己没有一套能直接调起 iOS 系统相机和相册的官方接口。社区里是有现成插件但插件一多维护成本就上来了功能定制也放不开手脚。我这次接手的项目就是把 Unity 和 iOS 原生之间的通道彻底打通在 Unity 里调起系统相机拍照、打开系统相册选图再拿回 Unity 里做显示和处理。顺手写了一整套原生桥接方案从 Objective-C 插件到 C# 回调都理了一遍这篇文章就是把完整实现过程和踩过的坑记录下来给正在卡这一关的同学一份能直接照着抄的作业。适合 Unity 客户端工程师、做原生联调的开发者以及想了解 Unity 与 iOS 原生数据传递原理的团队参考。1. 交互方案选型为什么必须写原生桥接层1.1 Unity 没有“内置相机相册”接口Unity 在 Android 端其实提供了一部分运行时权限申请的能力也能通过CameraDevice或一些实验性 Package 访问摄像头画面但要“调起系统相机应用拍照并返回图片”Unity 本身没有统一封装。iOS 上更直接——苹果没有开放任何接口给 Unity 运行时直接弹起 UIImagePickerController 或者 PHPicker你必须在 Objective-C / Swift 层写一个原生插件由 Unity 调用原生方法原生层弹出系统页面拿到结果后再回传给 Unity。这中间绕不开的桥梁是 UnityEngine 的[DllImport(__Internal)]和 iOS 原生的UnitySendMessage。有些同学会问为什么不用 Unity 的NativeCamera这类第三方插件我的看法是第三方插件确实开箱即用但如果你需要在拍照后做定制裁剪、需要调整相册多选逻辑、或者要跟既有 Native SDK 共用回调通道插件反而会成为限制。自研桥接层虽然前期多花一点时间但后续所有 iOS 原生能力比如日历、通讯录、扫码都能沿着这套通道扩展性价比非常高。1.2 两种原生桥接架构插件式与宿主式先说清楚Unity 与 iOS 原生交互有两种主流架构不同项目选型不一样。第一种是做iOS Native Plugin把写好的 Objective-C 文件放到Assets/Plugins/iOS/目录Unity 打包 Xcode 工程时会自动编译并链接进 App。Unity 侧用[DllImport(__Internal)]声明外部方法运行时直接调用原生函数原生侧拿到数据后通过UnitySendMessage把结果广播回 Unity 场景里的某个 GameObject。这种做法实现简单适合 Unity 作为主导、原生只承担辅助能力的项目。第二种是Unity as a Library也就是把 Unity 打包成 Framework嵌入到原生 iOS App 工程里由原生 App 作为宿主来驱动 Unity 内容。这种架构适合原生 App 里某个模块是 Unity 渲染、或者需要原生层长期持有 Unity 生命周期控制的场景。它也能做双向交互但配置复杂度高很多Unity 生命周期、内存管理、场景切换都得更小心。本项目采用第一种原因很直接Unity 内容占主导原生只需要提供相机相册这种系统能力用插件式桥接最少代码、最快见效。1.3 UnitySendMessage 双向通信机制理清UnitySendMessage是理解整个方案的关键。它本质上是原生代码向 Unity 发送消息的 C 接口原型如下void UnitySendMessage(const char* obj, const char* method, const char* msg);参数分别是场景中接收消息的 GameObject 名称、该 GameObject 上挂载的脚本方法名、要传递的字符串消息。原生层拿到照片后把照片存到临时文件或者压缩成 Base64 字符串通过这个方法把数据或者路径传给 Unity 里的 C# 方法。这里有两个很容易踩的坑一是 GameObject 名称必须跟场景里实际对象名字完全一致大小写都不能错而且这个 GameObject 必须处于激活状态二是 C# 接收方法的访问权限建议写成public或者至少能被反射到方法名也要与原生端传入的字符串完全对应。我在第一次联调时就因为把脚本挂在了一个SetActive(false)的节点上结果回调一直没触发排查了半天。还有一点UnitySendMessage传递的是字符串。如果要传一张图片最稳妥的方案不是把图片整个 Base64 编码成超长字符串而是把图片写入临时目录把文件路径传给 Unity再由 C# 异步加载。这个选择会影响内存峰值后面会详细对比。2. 原生侧实现Objective-C 调用系统相机和相册2.1 插件工程结构与源码组织在 Unity 里新建Assets/Plugins/iOS目录把原生源码放进去。Unity 会把这个目录下的.h、.m、.mm文件全部自动加入生成的 Xcode 工程不需要再手动拖文件。我通常在这个目录下建三个文件NativeBridge.h公共头文件暴露给 Unity 调用的 C 接口。NativeBridge.mm实现文件。注意这里我用.mm后缀而不是.m是因为后续可能需要混合 C 代码或引用其他 C 库Objective-C后缀兼容面更宽。NativeBridgeDelegate可选如果要处理更复杂的回调可以单独抽出协议类但当前项目规模不大我直接在.mm里实现了 delegate。核心 C 接口命名遵循 Unity 的 DllImport 规则必须是 C 风格函数。比如// NativeBridge.h #ifndef NativeBridge_h #define NativeBridge_h #ifdef __cplusplus extern C { #endif void _UnityCallCamera(const char* gameObjectName, const char* callbackMethod); void _UnityCallPhotoLibrary(const char* gameObjectName, const char* callbackMethod); void _UnitySaveImageToAlbum(const char* imagePath); #ifdef __cplusplus } #endif #endif /* NativeBridge_h */extern C很重要因为.mm是 Objective-C 编译环境不包一层的话链接阶段会找不到符号Unity 侧[DllImport]会直接报EntryPointNotFoundException。2.2 相机权限与 Info.plist 配置iOS 调起系统相机前必须先在 Info.plist 里声明相机用途描述否则 App 会直接崩溃。用 Unity 打包时你可以在 Unity 的 Player Settings 里打开Other Settings Configuration Camera Usage Description直接填描述文本它会自动写入最终生成的 Info.plist。相册相关的描述同样在这里配置字段对应关系如下功能Info.plist Key是否必需用途说明调起系统相机NSCameraUsageDescription必需说明 App 为什么需要使用相机读取系统相册老 APINSPhotoLibraryUsageDescription必需UIImagePickerController 读相册时的权限保存图片到相册NSPhotoLibraryAddUsageDescriptioniOS 11 必需添加图片到相册的权限声明使用 PHPicker 选图无需权限可选iOS 14 新相册选择器默认无需授权配置文案要写得真实具体比如“需要拍摄照片用于上传头像”“需要保存图片到你的相册”这样审核和用户弹窗都能过。如果只配置了相机权限却没配相册权限用户点“相册”按钮时会出现无权限或崩溃的诡异现象排查步骤我会放在第 4 章。2.3 用 UIImagePickerController 实现相机功能相机功能的传统实现方式是用UIImagePickerController。这类控制器是系统原生页面我们只需要设置sourceType为相机设置代理然后从当前 Unity 的根控制器 present 出来。// NativeBridge.mm 中的相机调用逻辑 static NSString *g_callbackObjectName; static NSString *g_callbackMethodName; void _UnityCallCamera(const char* gameObjectName, const char* callbackMethod) { g_callbackObjectName [NSString stringWithUTF8String:gameObjectName]; g_callbackMethodName [NSString stringWithUTF8String:callbackMethod]; dispatch_async(dispatch_get_main_queue(), ^{ if (![UIImagePickerController isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera]) { [self sendErrorToUnity:Camera source type not available]; return; } UIImagePickerController *picker [[UIImagePickerController alloc] init]; picker.sourceType UIImagePickerControllerSourceTypeCamera; picker.delegate self; picker.allowsEditing NO; UIViewController *rootVC UnityGetGLViewController(); [rootVC presentViewController:picker animated:YES completion:nil]; }); }注意两点。第一dispatch_async(dispatch_get_main_queue(), ...)是必须的因为从 Unity 侧通过 DllImport 调过来时可能不在主线程UI 操作必须回主线程执行。第二UnityGetGLViewController()是 Unity 在 iOS 上暴露的全局接口返回当前 Unity 视图控制器用它来 present 系统页面才能保证层级正确。相机代理回调里拍摄完成后系统会返回UIImage对象。在didFinishPickingMediaWithInfo方法里拿到原始图片后我一般先压缩再落盘然后传路径给 Unity- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionaryUIImagePickerControllerInfoKey,id *)info { UIImage *image info[UIImagePickerControllerOriginalImage]; [picker dismissViewControllerAnimated:YES completion:^{ NSString *path [self saveImageToTemporary:image]; [self notifyUnity:path]; }]; // 相册逻辑用 PHPicker 处理见下文 }这里有个细节必须在dismissViewControllerAnimated:completion:的 completion 回调里执行后续发送动作不要直接 dismiss 完就发消息否则 Unity 侧可能因为视图切换动画还没结束而出现界面卡顿。2.4 相册功能老 API 与新 API 的选择相册选图有两种实现方案选择直接影响权限配置和用户体验。老方案同样用UIImagePickerController把sourceType设为UIImagePickerControllerSourceTypePhotoLibrary。这个方案兼容 iOS 8 到 iOS 13但也受相册权限约束如果用户拒绝权限选择器无法正常显示。新方案是 iOS 14 引入的PHPickerViewController苹果专门针对隐私做了一版新相册选择器它的最大好处是不需要 App 申请相册权限——系统会为这个选择器单独提供一份隔离的相册视图App 拿到的只是用户明确选择出来的资源。这意味着即使用户在设置里关闭了相册权限PHPicker 依然能用。我强烈建议新项目直接用 PHPicker。除了权限优势它还原生支持多选、搜索、按相册分类并且是在独立进程渲染的即使 App 自身内存吃紧选图过程也不会因为加载原图而撑爆内存。实现代码相对简洁void _UnityCallPhotoLibrary(const char* gameObjectName, const char* callbackMethod) { g_callbackObjectName [NSString stringWithUTF8String:gameObjectName]; g_callbackMethodName [NSString stringWithUTF8String:callbackMethod]; dispatch_async(dispatch_get_main_queue(), ^{ PHPickerConfiguration *config [[PHPickerConfiguration alloc] init]; config.filter [PHPickerFilter imagesFilter]; // 只显示图片也可以配 videosFilter config.selectionLimit 1; // 多选时设置更大比如 9 PHPickerViewController *picker [[PHPickerViewController alloc] initWithConfiguration:config]; picker.delegate self; UIViewController *rootVC UnityGetGLViewController(); [rootVC presentViewController:picker animated:YES completion:nil]; }); }PHPicker 的代理回调拿到的是NSItemProvider需要用异步方式加载图片数据- (void)picker:(PHPickerViewController *)picker didFinishPicking:(NSArrayPHPickerResult * *)results { [picker dismissViewControllerAnimated:YES completion:nil]; NSItemProvider *provider results.firstObject.itemProvider; if ([provider canLoadObjectOfClass:[UIImage class]]) { [provider loadObjectOfClass:[UIImage class] completion:^(idNSItemProviderReading object, NSError *error) { UIImage *image (UIImage *)object; NSString *path [self saveImageToTemporary:image]; [self notifyUnity:path]; }]; } }注意这里 loadObjectOfClass 的回调线程不固定而UnitySendMessage虽然可以在任意线程调用但 Unity 侧回调接收时可能涉及 Unity 主线程的操作稳妥做法是在回调里强制切回主线程或者让 C# 侧用一个队列缓冲处理。我习惯在原生层直接做一次dispatch_async(dispatch_get_main_queue())保证发到 Unity 的数据一定在主线程上下文触发。2.5 数据传递策略文件路径优于 Base64拿到UIImage之后有两个回传方案。方案一是将图片转成 PNG/JPEG 数据再 Base64 编码成字符串通过UnitySendMessage直接传给 Unity。方案二是把图片压缩后写入临时目录回传文件路径C# 侧再异步读取。一次拍照的 JPEG 数据可能在 2MB ~ 7MB 之间Base64 编码会再膨胀约 33%这个超长字符串如果通过UnitySendMessage传输内存分配和字符串复制都非常浪费。更关键的是 C# 侧拿到 Base64 要先Convert.FromBase64String转成字节数组字符串驻留期间整个流程的峰值内存会很难看。我选文件路径方案原生层把图片压缩到宽边不超过 2048、JPEG 压缩质量 0.8再写到NSTemporaryDirectory()下带 UUID 的文件。这样传给 Unity 的只是几十个字符的路径Unity 侧用File.ReadAllBytes或者UnityWebRequest的file://协议读取内存易控还能方便后续扩展上传、缓存等逻辑。唯一的缺点是临时目录需要定期清理这个在 C# 侧每次读取完删除即可。3. C# 侧对接DllImport、回调与图片显示3.1 用 DllImport 声明原生入口C# 侧首先要声明原生函数入口。这里必须用__Internal作为库名这是 Unity 在 iOS 上的特殊约定表示从当前可执行文件里查找符号public class NativeBridge { #if UNITY_IPHONE !UNITY_EDITOR [DllImport(__Internal)] private static extern void _UnityCallCamera(string gameObjectName, string callbackMethod); [DllImport(__Internal)] private static extern void _UnityCallPhotoLibrary(string gameObjectName, string callbackMethod); #endif public static void OpenCamera(string callbackObjectName, string callbackMethod) { #if UNITY_IPHONE !UNITY_EDITOR _UnityCallCamera(callbackObjectName, callbackMethod); #else Debug.LogError(iOS Native Camera only works on real iOS device.); #endif } public static void OpenPhotoLibrary(string callbackObjectName, string callbackMethod) { #if UNITY_IPHONE !UNITY_EDITOR _UnityCallPhotoLibrary(callbackObjectName, callbackMethod); #else Debug.LogError(iOS Native Photo Library only works on real iOS device.); #endif } }强烈建议把 DllImport 的方法用#if UNITY_IPHONE !UNITY_EDITOR包起来因为编辑器环境下__Internal符号不存在一旦调用就会抛EntryPointNotFoundException。封装成静态方法后再做一次平台判断这样业务层代码不用到处写编译宏。Unity 打包 iOS 时如果勾选了IL2CPP后端还需要留意Managed Stripping Level。如果开到 High 或 MediumC# 回调方法可能会被裁剪掉导致UnitySendMessage找不到对应方法。解决办法是在接收回调的方法上标记[UnityEngine.Scripting.Preserve]特性或者把剥离级别调低。3.2 设计统一回调入口原生层只需要知道两个信息发给哪个 GameObject、调用哪个方法。所以我设计了一个全局的单例作为回调分发器把“接收原生消息”和“业务处理”解耦开。public class NativeBridgeCallback : MonoBehaviour { public static NativeBridgeCallback Instance { get; private set; } private void Awake() { Instance this; } // 相册/相机回调统一入口 public void OnNativeImagePath(string path) { if (string.IsNullOrEmpty(path)) { Debug.LogError(Native returned empty image path.); return; } StartCoroutine(LoadImageAndNotify(path)); } private IEnumerator LoadImageAndNotify(string path) { byte[] bytes File.ReadAllBytes(path); Texture2D tex new Texture2D(2, 2, TextureFormat.RGBA32, false); if (!tex.LoadImage(bytes)) { Debug.LogError(Failed to load image from path: path); yield break; } NativeImageEvent?.Invoke(tex); // 清理临时文件 if (File.Exists(path)) File.Delete(path); } public event System.ActionTexture2D NativeImageEvent; }这里有几个设计点值得说明。一是用MonoBehaviour的协程加载图片避免大图片在主线程同步解码造成卡顿。二是Texture2D.LoadImage是 Unity 内置方法能自动处理 PNG/JPEG 解码不需要额外引入第三方库。三是如果业务层需要背景透明图要在创建 Texture2D 时指定TextureFormat.RGBA32不要用默认格式否则 PNG 的 Alpha 通道可能丢失。场景里必须保证有一个激活的 GameObject 挂着NativeBridgeCallback脚本并且它的名字跟原生层传入的gameObjectName完全一致。我通常在启动场景创建这个对象并调用DontDestroyOnLoad这样即使后续场景切换回调入口也不会丢。3.3 摄像头权限申请与运行时状态处理iOS 上应用只有在用户点击某个 UI 时才应该触发相机或相册调用因为系统弹窗必须附着在可见视图层级上。千万不要在Awake或Start里直接调OpenCamera这会导致弹窗时机不对系统在弹出权限询问框之前视图层级还没准备好原生层调用presentViewController会失败。另外当原生相机页面弹出时Unity 正在渲染的图形上下文会被系统打断。iOS 会自动处理这个生命周期回调OnApplicationPause(true)等用户拍完照或选完图关闭选择器后再回调OnApplicationPause(false)。这时候注意不要在暂停期间做繁重的资源加载或网络请求恢复时做一次必要的界面刷新即可。private void OnApplicationPause(bool pause) { if (!pause) { // 从系统页面返回 Unity此时可以重启摄像头预览或刷新 UI Debug.Log(Back to Unity from native page.); } }这个暂停事件在某些 iPad 多任务场景下也会触发比如用户把 App 切到 Slide Over 模式系统页面并未完全关闭。建议在这类场景下做一个页面前进状态的标记避免用户多次触发相机导致原生页面重复弹出。3.4 Texture2D 与 UI 显示的内存管理拿到Texture2D后把它赋给 RawImage 显示只是第一步真正的坑在于内存释放。iOS 上每张 iPhone 拍的 JPEG 原图可能接近 4000×3000 像素解码成 Texture2D 后占内存接近 48MB。如果用户连续拍三五张每张都创建新纹理内存瞬间爆掉App 会被系统杀掉。我在实际项目里做了两件事控制内存。第一原生侧落盘前先做尺寸压缩统一收缩到 2048 宽以下这样传到 Unity 的图片最多占 16MB 左右。第二C# 侧在替换旧图时主动Destroy旧纹理不要把引用一直挂在对象上。RawImage 的 texture 赋值前先记下旧的赋值后再销毁顺序不能反。private void SetDisplayImage(Texture2D newTexture) { if (_displayImage ! null) { Destroy(_displayImage); } _displayImage newTexture; _displayRawImage.texture _displayImage; }如果是头像类业务还可以考虑直接生成缩略图再显示大图则用于上传。缩略图通常控制在 256×256用Texture2D内部方法缩放显示效果完全足够内存开销可以忽略不计。4. 常见问题与排查实录4.1 相机唤起后黑屏或直接崩溃真机调试时最容易遇到的现象是相机启动后黑屏或者直接闪退。黑屏多数是因为 Info.plist 缺少相机权限描述系统在弹权限框之前就中止了相机页面渲染。崩溃则可能发生在模拟器上因为UIImagePickerControllerSourceTypeCamera在模拟器里并不可用。建议先检查三个点确认运行在真机确认 Player Settings 里 Camera Usage Description 有实际内容确认原生代码里调用了isSourceTypeAvailable做了前置判断。如果前三点都没问题再看 Unity 和 Xcode 的日志里有没有This app has crashed because it attempted to access privacy-sensitive data without a usage description这类字样有的话就是权限描述缺失。4.2 拍照后回调不触发我遇到的最耗时的排查问题就是拍照完成、图片正常显示在系统预览里但 Unity 界面始终没收到回调。排查下来原因基本都是这三个之一UnitySendMessage传的 GameObject 名称和场景里实际对象名称不一致。接收方法的访问权限不是 public或者方法签名不匹配。接收消息的 GameObject 在某次流程里被SetActive(false)了。最快的排查办法是在原生端UnitySendMessage调用前加一句NSLog把目标对象名和方法名打出来再在 C# 方法里加Debug.Log对照两边日志。如果原生日志显示发送成功但 C# 没打印问题在 C# 侧如果原生日志都打不出来问题在原生调用前就已经出错了。4.3 iOS 14 相册权限弹窗设计变化如果你的 App 用的是老式UIImagePickerController访问相册iOS 14 之后权限行为有变化系统会弹出“选择照片”权限框用户可以选择“允许访问所有照片”或“仅允许部分照片”。如果项目里同时声明了NSPhotoLibraryUsageDescription但用户选择了“部分照片”你所访问到的照片集可能不包含用户刚刚拍摄的照片极容易产生“图片找不到”的 bug。解决办法就是切换到 PHPicker。它不需要读取整个相册也不需要权限声明用户看到的始终是系统自己提供的完整相册视图App 只接收用户选中的那一张。这也是苹果在 WWDC 2020 上多次强调的推荐做法。4.4 Unity 侧内存持续上涨处理大批量图片时内存上涨会变得非常明显。我在一次真机测试循环选图 20 次后发现内存从 200MB 升到 2GB几乎到了被系统强杀的边缘。排查后确认两个元凶一是临时目录的图片文件只写不删导致磁盘压力和内存缓存同时上升二是每次创建的Texture2D没有及时复用或销毁。优化方案是原生侧落盘前做压缩C# 侧读完文件立刻删除临时文件旧纹理在执行新的LoadImage前先Destroy如果用RawImage循环展示多张图建议对象池化避免频繁创建销毁。4.5 模拟器、开发者模式与签名问题联调阶段不可避免要在模拟器上验证 UI 流程。但模拟器不支持调起相机也没有真实相册资源所以业务逻辑可以跑通拍照流程只能真机验证。Xcode 14 之后真机调试默认要求开启开发者模式在设备设置中手动打开“开发者模式”开关否则 Xcode 会报Could not launch because the device is not in Developer Mode的错误。GitHub Actions 远程打包 iOS 也是现在团队里常用的流水线方案这套原生插件代码在 CI 环境同样能正常编译前提是 Xcode 版本与 Unity 打包要求的版本匹配。插件代码本身没有特殊的签名依赖权限描述会透传到最终 Info.plist只要 Xcode 签名配置正确远程打出来的包行为跟本地一致。我在实际项目中体会最深的是Unity 与 iOS 交互这套方案一定要趁早建立“原生回调协议”的意识。刚开始只做拍照和相册时可能直接在 MonoBehaviour 里写死回调方法就够了但一旦后面加入扫码、通讯录、系统设置页跳转等需求回调入口会变得非常混乱。建议所有原生回调统一经过一个静态分发器用事件或委托的方式派发到业务层这样每增加一个新能力只需要扩展原生实现和对应的事件类型C# 侧不会膨胀。最后再分享一个小技巧调试原生插件时不一定要每次都重新打 Xcode 工程可以在 Unity 生成 Xcode 工程后直接用 Xcode 打开并修改原生代码改完用 Xcode 重新 Run 到设备即可不需要回 Unity 重打包。这样原生层的调试迭代速度快很多等整体稳定后再回 Unity 侧做最终打包验证。这套流程用顺了Unity 和 iOS 的交互开发效率能提升一大截。
