Unity Native Toolkit实战：移动端原生功能集成与避坑指南

1. 项目概述：Unity Native Toolkit 是什么？

如果你在Unity里做过移动端开发，尤其是需要调用手机原生功能——比如打开相机拍照、访问相册、调起系统分享、获取GPS位置或者发个本地通知——那你大概率遇到过这个需求：Unity的C#脚本没法直接和Android的Java或iOS的Objective-C/Swift代码对话。这时候，一个叫Unity Native Toolkit的插件就派上用场了。它不是Unity官方出的，而是一个在GitHub上开源了多年的社区项目，核心目标就一个：帮你用最少的代码，在Unity里调用那些原本需要写一大堆平台特定代码才能实现的原生功能。

我最早接触它是在一个需要让用户从手机相册选头像的项目里。当时团队纠结是自己从头写一套Android和iOS的桥接，还是找个现成的轮子。自己写，意味着要维护两套甚至三套代码（Android Java, iOS Obj-C/Swift, 以及Unity C#的接口层），调试起来更是噩梦。而Unity Native Toolkit把所有这些脏活累活都封装好了，你只需要在C#里调用像NativeToolkit.PickImage()这样简单的方法，它就能在Android和iOS上分别调起系统的图片选择器，并把选中的图片以Texture2D或者文件路径的形式回传给Unity。这对于需要快速原型验证或者中小型团队来说，能省下大量的开发和联调时间。

不过，就像所有第三方插件一样，用起来爽，踩坑的时候也真让人头疼。尤其是在Unity版本快速迭代、移动操作系统API不断更新的背景下，这个基于社区维护的工具会遇到各种兼容性问题。从构建失败、运行时崩溃，到权限处理不当、回调丢失，每一个问题都可能让新手卡上半天。这篇文章，我就结合自己这几年在多个项目里实际使用Unity Native Toolkit的经验，把那些最常见、最棘手的问题的解决方案梳理出来，让你能避开我踩过的那些坑，更顺畅地把原生功能集成到你的Unity项目里。

2. 核心问题一：环境配置与构建失败

这是使用任何涉及原生代码的Unity插件时遇到的第一道坎。Unity Native Toolkit对构建环境有比较具体的要求，如果配置不对，轻则编译报错，重则打出来的包直接闪退。

2.1 Android构建配置要点

Android平台的问题通常集中在Gradle配置、权限和SDK版本上。

首先，根据插件的README，你需要确保Player Settings里的几个关键设置：

1. Scripting Backend：必须使用IL2CPP。Mono脚本后端在处理与原生Java代码的交互时，尤其是在涉及复杂对象传递和回调时，容易出问题。IL2CPP提供了更稳定和高效的原生互操作支持。
2. Target Architectures：通常勾选ARM64就够了。现在市面上几乎已经没有纯ARMv7（即armeabi-v7a）的Android设备了，而且Google Play从2019年就开始要求新应用必须支持64位。只勾选ARM64可以减小包体。如果你的项目还需要支持一些非常老的设备，可以同时勾选ARMv7，但要注意这会增加包大小和潜在的兼容性测试工作量。
3. Write Access：在Player Settings -> Other Settings -> Configuration 下，找到Write Access选项，必须设置为External (SDCard)。这是因为插件中保存截图、图片到相册的功能，需要向外部存储（即共享存储空间）写入文件。如果设置为Internal（仅限内部），这些写操作会因权限不足而失败。
4. Build System：推荐使用Gradle。Unity老版本的Internal构建系统（现在已废弃）或新的Gradle系统都可以，但Gradle是谷歌官方维护的，对依赖管理和构建过程的支持更好，也更容易与插件的原生代码模块集成。
5. Minimum API Level：插件测试时用的是API 16（Android 4.1），但我强烈建议你将最低API级别设置为至少22（Android 5.1）。原因有两个：一是Android 6.0（API 23）引入了运行时权限机制，插件中涉及相机、相册、位置的功能都需要处理这个；二是API 22以下的设备市场占有率已经极低，为了极少数用户去适配古老的系统，性价比不高。

注意：如果你在Unity 2022.3 LTS或更新版本中遇到构建错误，提示与JDK版本有关（比如搜索热词里的“2023.1.0f1c1需要jdk<11.0.14.1,下载不到怎么办unity”），这不是Native Toolkit特有的问题，而是Unity版本与JDK的兼容性问题。解决方案是去Unity Hub中，为该项目指定一个兼容的JDK版本（如JDK 8或JDK 11的某个特定子版本），或者在Unity的Preferences -> External Tools中，设置一个正确的JDK路径。

2.2 iOS构建配置与Xcode工程处理

iOS侧的问题往往在导出Xcode工程之后。

1. 架构与脚本后端：和Android一样，确保Scripting Backend为IL2CPP，Target SDK选择Device SDK，架构勾选ARM64。现在基本不需要支持32位的iOS设备了。

2. 权限描述（Info.plist）：这是iOS开发的重中之重。任何访问敏感数据的操作（相机、相册、位置、通讯录等）都必须在Info.plist文件中添加对应的用途描述（Usage Description），否则应用在请求权限时会直接崩溃，且控制台不会有明确的Unity错误日志，只能在Xcode的设备日志里看到模糊的终止信息。

   • 相机：NSCameraUsageDescription- “需要您的相机来拍摄照片。”
   • 相册（写入）：NSPhotoLibraryAddUsageDescription- “需要保存图片到您的相册。”
   • 相册（读取）：NSPhotoLibraryUsageDescription- “需要访问您的相册来选择图片。”
   • 位置：NSLocationWhenInUseUsageDescription- “需要您的位置来提供周边服务。”

   Unity Native Toolkit的iOS原生代码会去访问这些功能，所以即使你的C#代码还没调用相关功能，只要插件包含这些原生代码，就必须提前在Info.plist里配置好。我建议在项目初期就把所有可能用到的权限描述都加上，避免后续测试时忘记。

3. Xcode工程中的链接库（Frameworks）：Unity在导出Xcode工程时，通常会根据你项目中用到的API自动添加必要的系统框架（如Photos.framework,CoreLocation.framework等）。但有时自动添加会遗漏。一个检查方法是，打开导出的Xcode工程，在Build Phases->Link Binary With Libraries中，确认以下框架是否存在（根据你使用的功能）：

   • Photos.framework(用于相册访问)
   • MobileCoreServices.framework(用于UTI类型识别，老版本可能需要)
   • CoreLocation.framework(用于GPS)
   • Contacts.framework(用于通讯录，如果插件版本支持)
   • UserNotifications.framework(用于本地通知，iOS 10+)

   如果缺少，手动点击+号添加即可。

3. 核心问题二：运行时权限处理

从Android 6.0 (API 23) 和 iOS 开始，敏感权限都需要在运行时向用户申请。Unity Native Toolkit的某些版本可能没有内置完善的权限检查逻辑，这就需要我们在C#层做补丁。

3.1 Android运行时权限请求

在Android上，即使你在AndroidManifest.xml里声明了权限，在Android 6.0+的设备上，这些“危险权限”仍然需要在运行时再次申请。插件中的相机、相册、位置功能都涉及危险权限。

解决方案：在调用NativeToolkit的相关方法前，先进行权限检查。

由于Unity Native Toolkit本身没有提供权限检查的API，我们需要借助Unity的AndroidPermissions类（位于UnityEngine.Android命名空间下，注意不是所有Unity版本都直接有，可能需要通过UnityEngine.Android.Permission来访问）或者自己写一个简单的Android Java插件来请求权限。

这里给出一个在Unity C#中检查并请求Android权限的通用模式：

using UnityEngine; #if UNITY_ANDROID using UnityEngine.Android; // 适用于较新Unity版本 #endif public class PermissionManager : MonoBehaviour { public void CheckAndRequestCameraPermission(System.Action onGranted) { #if UNITY_ANDROID if (!Permission.HasUserAuthorizedPermission(Permission.Camera)) { var callbacks = new PermissionCallbacks(); callbacks.PermissionGranted += (permissionName) => { if (permissionName == Permission.Camera) { Debug.Log("相机权限已授予"); onGranted?.Invoke(); } }; callbacks.PermissionDenied += (permissionName) => Debug.LogWarning("相机权限被拒绝"); callbacks.PermissionDeniedAndDontAskAgain += (permissionName) => Debug.LogError("相机权限被永久拒绝，请去设置中手动开启"); Permission.RequestUserPermission(Permission.Camera, callbacks); } else { onGranted?.Invoke(); } #elif UNITY_IOS // iOS权限处理逻辑（通常通过原生插件触发，见下文） onGranted?.Invoke(); // 注意：这里只是示意，实际iOS需要在调用原生方法前触发系统弹窗 #endif } // 类似的方法可以用于写外部存储权限 Permission.ExternalStorageWrite (在旧API中) // 注意：Android 10+ 对外部存储权限有更严格限制（Scoped Storage），直接写文件到公共目录可能不行，需要考虑使用MediaStore API。 }

然后，在调用NativeToolkit.TakePicture()之前，先调用CheckAndRequestCameraPermission。

实操心得：对于写入相册（SaveImageToGallery）功能，在Android 10 (API 29) 及以上版本，由于作用域存储（Scoped Storage）的限制，传统的直接写文件到DCIM或Pictures目录的方式可能失效或需要特殊处理。Unity Native Toolkit的版本如果较老，可能没有适配这个变化。一个变通方案是，使用Android的MediaStoreAPI来插入图片。这可能需要你修改插件中的Android原生代码部分，或者寻找已经适配了Scoped Storage的社区分支版本。

3.2 iOS权限请求时机

iOS的权限请求通常是在第一次访问相关API时，由系统自动弹出对话框。但是，为了更好的用户体验，我们有时希望控制这个时机。

Unity Native Toolkit的iOS原生代码在调用[AVCaptureDevice requestAccessForMediaType:...]或[PHPhotoLibrary requestAuthorization:...]时，会触发系统弹窗。这个弹窗只会出现一次。如果用户点了“拒绝”，下次再调用相关功能，可能直接失败或者没有任何反应。

最佳实践：在合适的场景预请求权限。例如，在游戏内打开“拍照”功能界面时，可以先调用一个只负责请求权限的“空方法”。我们可以对插件进行小幅改造，在iOS原生侧暴露一个专门用于请求权限的方法（比如RequestCameraAuthorization），然后在C#中调用它。这样，用户可以在进入拍照界面时就看到权限弹窗，而不是在点击“拍照”按钮后才看到，体验更连贯。

如果不想修改插件代码，一个折中的办法是，在应用启动后、需要用到权限的功能入口处，尽早地、主动地调用一次插件的轻度功能。例如，在启动后调用一个获取相册权限的简单查询（但不要实际打开相册），来触发系统的权限弹窗。

4. 核心问题三：回调丢失与线程安全

这是Unity与原生代码交互中最经典、也最容易出错的问题之一。Unity Native Toolkit通过C#的Action回调将结果从原生层传回Unity层。如果处理不当，回调可能会丢失，或者引发线程冲突。

4.1 确保回调在Unity主线程执行

Android的JNI（Java Native Interface）调用和iOS的UnitySendMessage机制，其回调很可能不是在Unity的主线程（即游戏循环线程）上触发的。Unity的很多API（尤其是涉及GameObject、Transform、UI组件如Image、Text的修改）都要求必须在主线程执行。

问题现象：调用PickImage后，图片选择界面正常弹出，用户也选择了图片，但回到游戏后，接收图片的Texture2D为null，或者对Texture2D的赋值导致游戏崩溃。

解决方案：使用UnityEngine.Dispatcher或手动派发到主线程。

一个简单可靠的方法是利用UnityEngine.WSA.Application命名空间下的Dispatcher（虽然名字带WSA，但在其他平台也可用），或者更通用的，使用一个继承自MonoBehaviour的单例类来将回调任务排队，在Update()中执行。

以下是使用协程和主线程队列的一个示例模式：

using System.Collections.Generic; using UnityEngine; public class MainThreadDispatcher : MonoBehaviour { private static MainThreadDispatcher _instance; private static readonly Queue<System.Action> _executionQueue = new Queue<System.Action>(); public static MainThreadDispatcher Instance { get { if (_instance == null) { GameObject go = new GameObject("MainThreadDispatcher"); _instance = go.AddComponent<MainThreadDispatcher>(); DontDestroyOnLoad(go); } return _instance; } } void Update() { lock (_executionQueue) { while (_executionQueue.Count > 0) { _executionQueue.Dequeue().Invoke(); } } } public void Enqueue(System.Action action) { lock (_executionQueue) { _executionQueue.Enqueue(action); } } // 在插件回调中使用 public void InitializeNativeToolkitCallbacks() { // 假设插件允许设置一个全局回调（需要查看插件具体API） // NativeToolkit.SetImagePickedCallback(OnImagePicked); } private void OnImagePicked(string imagePath) { // 这个回调可能来自非主线程 Enqueue(() => { // 现在在主线程了，可以安全操作Unity对象 StartCoroutine(LoadImageCoroutine(imagePath)); }); } private System.Collections.IEnumerator LoadImageCoroutine(string path) { // 使用WWW或UnityWebRequest加载图片，这些操作可以在子线程，但最终赋值给Texture2D并应用到Material/Image上时，需要确保在主线程。 // 这里WWW已经过时，建议用UnityWebRequestTexture var www = new UnityEngine.Networking.UnityWebRequest(path); yield return www.SendWebRequest(); if (www.result == UnityEngine.Networking.UnityWebRequest.Result.Success) { var texture = DownloadHandlerTexture.GetContent(www); // 对texture的操作是安全的，因为协程的yield return后的代码默认在主线程执行（除非用了特殊的后台线程调度）。 // 将texture赋值给某个RawImage // myRawImage.texture = texture; } } }

然后，在你的游戏初始化场景中，确保MainThreadDispatcher.Instance被创建。在调用NativeToolkit方法时，将其回调包装到Enqueue方法中。

4.2 处理异步操作与生命周期

另一个常见问题是，在调用原生功能（如打开相机）后，用户可能切出应用，或者按了Home键，此时Unity应用可能进入后台甚至被系统回收。当用户再返回时，原生层的活动（Activity）或视图控制器（ViewController）可能已经销毁，但Unity层的回调还在等待。

解决方案：增加超时和状态检查。

1. 设置超时：在调用原生方法时，启动一个协程计时器。例如，调用TakePicture后，如果在15-30秒内没有收到成功或失败的回调，就认为操作超时，清理相关状态，并可能提示用户“操作超时，请重试”。
2. 监听应用焦点事件：在OnApplicationPause(bool pause)事件中处理。如果应用进入后台（pause=true），而一个原生操作（如拍照）正在进行，可以尝试取消该操作（如果插件支持），或者记录状态，在应用回到前台（pause=false）时检查操作是否已完成或需要重新初始化。
3. 保存状态：对于像“选择图片”这样的操作，可以将当前状态（如“正在等待图片选择结果”）保存到PlayerPrefs或一个静态变量中。在应用启动或场景加载时，检查这个状态，并进行相应的恢复或清理操作。这可以防止因为应用被杀死重启后，残留的回调状态导致逻辑错乱。

5. 核心问题四：平台特定功能与兼容性

Unity Native Toolkit提供的是跨平台API，但Android和iOS的原生实现细节不同，导致某些功能的行为或限制有差异。

5.1 图片处理与路径差异

• 图片格式与质量：Android和iOS的相机返回的图片数据格式、压缩率、EXIF信息（如旋转方向）可能不同。插件通常会处理基本的格式转换（如JPEG/PNG），但旋转问题需要特别注意。iOS设备拍摄的照片通常带有旋转标识（Orientation），如果直接加载为Texture2D可能会是横着的。插件内部可能做了旋转校正，但你需要测试验证。如果没有，你可能需要在C#端根据EXIF信息手动旋转Texture2D。
• 文件路径：PickImage或TakePicture成功后，插件可能会返回一个临时文件的路径。这个路径是平台特定的。在Android上，可能是/storage/emulated/0/Android/data/your.package.name/cache/xxx.jpg这样的应用私有缓存路径；在iOS上，可能是Application.temporaryCachePath下的一个文件。你需要清楚这个文件的生存周期：它可能在下一次调用时被覆盖，或者在应用退出后被系统清理。如果你需要永久保存这张图片，应该尽快将其复制到一个持久化目录（如Application.persistentDataPath），或者调用插件的SaveImageToGallery方法保存到系统相册。

5.2 功能可用性检查

不是所有设备都支持所有功能。例如，前置摄像头可能不存在，GPS可能被用户关闭，设备可能没有相册应用。

稳健的做法是：在使用前进行检查。

虽然Unity Native Toolkit可能没有直接提供所有功能的可用性检查API，但我们可以通过其他方式或小技巧来实现：

• 摄像头：可以尝试在调用TakePicture前，先检查WebCamTexture.devices的长度。如果大于0，说明有摄像头。但这不能区分前后置。更精确的检查需要修改原生代码。
• GPS：在调用GetGPSData前，可以先检查Input.location.status（Unity自带的LocationService）。如果状态不是Running，可能需要先启动它，或者提示用户打开设备的位置服务。
• 相册：在iOS上，可以通过[PHPhotoLibrary authorizationStatus]来检查相册访问权限状态。在Android上，可以通过Environment.getExternalStorageState()来检查外部存储是否可用（尽管在Scoped Storage下意义减弱）。这些检查通常需要写在原生侧，并暴露给C#。

一个简单的防御性编程策略是：用try-catch包裹对NativeToolkit方法的调用。因为如果底层原生功能因设备不支持或权限问题而失败，插件可能会抛出异常。捕获异常后，可以给用户一个友好的错误提示，而不是让应用崩溃。

public void SafePickImage() { try { NativeToolkit.PickImage(OnImagePickedSuccess, OnImagePickedError); } catch (System.Exception e) { Debug.LogError($"调用PickImage失败: {e.Message}"); // 在主线程上显示一个UI提示框，告知用户功能暂时不可用 MainThreadDispatcher.Instance.Enqueue(() => { // 显示错误提示UI }); } }

6. 调试与问题排查实战记录

当功能不工作时，系统性的排查能帮你快速定位问题。

6.1 Android日志查看

Android的日志（Logcat）是排查问题的金钥匙。

1. 连接设备：用USB线连接Android设备到电脑，并开启USB调试。
2. 打开终端/命令行：使用adb logcat命令查看所有日志。但信息太多，需要过滤。
3. 过滤Unity和你的应用：
   • adb logcat -s Unity：只看Unity引擎输出的日志。
   • adb logcat | grep -E "(Unity|你的包名)"：同时看Unity和你应用的日志。
   • adb logcat *:E：只看错误级别的日志，这能快速发现崩溃信息。
4. 查找崩溃堆栈：如果应用闪退，在日志中搜索“FATAL EXCEPTION”或“AndroidRuntime”。堆栈信息会明确指出是哪一行原生代码或Java代码导致了崩溃，这对于定位插件中的原生代码问题至关重要。
5. 查看插件日志：Unity Native Toolkit的原生代码（Java部分）通常会使用Log.d或Log.e输出调试信息，标签（Tag）可能是“NativeToolkit”或类似名称。在logcat中过滤这个标签，可以看到插件内部执行到了哪一步，参数是什么，错误是什么。

6.2 iOS控制台与设备日志

iOS的调试相对封闭，但Xcode提供了强大的控制台。

1. 通过Xcode运行：将Unity项目Build & Run到iOS设备上，Xcode会自动打开并附加调试器。
2. 查看控制台输出：在Xcode底部的调试区域（Debug Area），可以看到Unity的Debug.Log输出以及所有系统日志（NSLog）。这是查看插件中Objective-C代码NSLog输出的地方。
3. 查看崩溃报告：如果应用崩溃，Xcode会停在崩溃的代码行（如果是原生代码崩溃）。也可以在Xcode的“Devices and Simulators”窗口中，选择已连接设备，查看“View Device Logs”来获取崩溃报告（Crash Report）。
4. 符号化崩溃日志：如果拿到的是用户设备上的崩溃日志（.crash文件），需要对应的.dSYM文件才能符号化（即将内存地址还原成函数名和行号）。确保在Unity构建iOS版本时，勾选了“Symlink Unity Libraries”和“Create Xcode Project”，并且构建完成后保留了整个Xcode工程文件夹，其中包含.dSYM文件。

6.3 Unity编辑器下的模拟测试

很多原生功能在Unity编辑器中是无法工作的（比如真机相机、GPS）。插件可能会在编辑器模式下提供一些模拟行为，或者直接抛出警告。

• 阅读插件文档和代码：查看插件的Example场景或文档，看它是否提供了编辑器下的替代方案。例如，PickImage在编辑器下可能会打开一个系统文件对话框来选择本地图片文件。
• 构建空方法：如果插件在编辑器下调用原生方法会报错，你可以使用#if UNITY_EDITOR和#if UNITY_ANDROID || UNITY_IOS这样的编译指令，来为编辑器模式编写模拟逻辑。例如，在编辑器下，当调用“拍照”时，你可以直接从一个预设的测试图片路径加载纹理。
• 使用Mock对象：创建一个接口，比如INativeToolkitService，为其提供两个实现：一个EditorNativeToolkitService（用于模拟），一个RealNativeToolkitService（包装真正的NativeToolkit调用）。通过依赖注入，在编辑器模式下使用Mock实现，这样就不会因为调用不存在的原生方法而中断你的开发流程。

7. 进阶：自定义与扩展插件功能

Unity Native Toolkit提供的功能可能无法满足所有需求。这时，就需要对其进行扩展。

7.1 添加新的原生功能

假设你需要一个插件没有提供的功能，比如“获取手机电量”或“调用系统震动”。

步骤大致如下：

1. 定义C#接口：在Unity C#脚本中，定义你希望调用的方法，例如public static float GetBatteryLevel()。
2. 实现Android部分：
   • 在插件的Android原生代码目录（通常是Assets/Plugins/Android/下的某个jar或aar包，或者源代码目录）中，找到主要的Java类（比如叫NativeToolkitPlugin）。
   • 添加一个新的静态方法，用@UnityCall注解（如果插件使用Unity的AndroidJavaProxy机制）或者遵循现有的JNI调用约定。
   • 在这个Java方法里，编写获取电量的原生代码（使用BatteryManager）。
   • 通过UnityPlayer.UnitySendMessage或插件已有的回调机制，将结果传回Unity。
3. 实现iOS部分：
   • 在插件的iOS原生代码目录（Assets/Plugins/iOS/）中，找到主要的.mm或.h文件。
   • 添加一个C函数，并用extern "C"和__attribute__((visibility("default")))修饰，以便Unity的IL2CPP能识别。
   • 在这个C函数里，调用iOS的[UIDevice currentDevice].batteryLevel。
   • 同样，通过插件已有的方式（可能是全局函数指针或委托）将结果传回Unity。
4. 在C#中桥接：在你的C#接口实现中，使用[DllImport("__Internal")]（对于iOS）和AndroidJavaClass/AndroidJavaObject（对于Android）来调用你新添加的原生方法。通常，插件会有一个统一的入口类，你需要将你的新方法集成进去，或者创建一个新的管理类。

注意事项：修改第三方插件源码意味着你放弃了自动更新的便利。你需要妥善管理你的修改版本，或者考虑向原仓库提交Pull Request，如果改动是通用且有益的。

7.2 处理插件冲突

你的项目可能不止使用Unity Native Toolkit一个原生插件。当多个插件都包含自己的AndroidManifest.xml文件或iOS原生代码文件时，可能会发生冲突。

• Android清单合并冲突：Unity在构建Android APK时，会合并所有插件的AndroidManifest.xml文件。如果两个插件声明了相同的组件（如Activity）或权限，但属性不同，就会导致合并失败。解决方案是创建一个后处理脚本（Post-Process Build），在构建完成后修改合并后的清单文件，或者使用Gradle的清单合并规则（tools:replace,tools:ignore等属性）来指定以哪个为准。更直接的方法是，检查冲突的插件，看是否有不需要的权限或组件可以移除。
• iOS文件重复或符号冲突：如果两个插件都提供了名字相同的.a静态库或定义了相同名称的C函数，链接时会报错“Duplicate symbol”。你需要联系插件作者，或者自己修改其中一个插件的代码，重命名冲突的文件或函数。有时，插件会提供“源码”版本，这给了你修改的灵活性。

7.3 性能优化与内存管理

频繁调用原生方法会有一定的开销。特别是传递大量数据（如图片字节流）时。

• 减少跨语言调用：避免在每帧（Update中）调用原生方法获取数据（如GPS）。改为在原生侧启动一个服务或监听器，定期或有变化时，通过回调通知Unity。Unity Native Toolkit的GPS功能可能就是这样实现的。
• 及时释放原生资源：对于像拍照返回的临时图片文件，在使用完后，如果确认不再需要，应该调用System.IO.File.Delete删除它，或者确保插件在下次调用时会清理旧文件。对于在原生侧创建的对象（如Android的Bitmap，iOS的UIImage），要确保插件在回调完成后正确地释放了它们，避免内存泄漏。这需要检查插件的原生代码。
• 图片处理优化：PickImage或TakePicture返回的可能是高分辨率图片。直接加载到Texture2D可能会消耗大量内存。考虑根据实际显示需求（比如头像只需要256x256），在加载后立即对Texture2D进行缩放处理，或者让原生侧在返回前就先进行压缩和缩放（如果插件支持传递尺寸参数）。