Unity打造Android桌面宠物：从悬浮窗嵌入到交互实现全解析

1. 为什么用Unity做桌面宠物：方案对比与选型

1.1 原生Android方案到底卡在哪

先聊一个很现实的问题：桌面宠物这个需求，用原生Android真的做不了吗？其实能做，但大多数团队做一半就会想骂人。

最早我接到这个需求时，第一反应也是用原生做。一个ImageView加帧动画就能跑起来，为什么非要上Unity？后来深入拆解才发现，原生方案有三个绕不过去的坎：

第一，动画表现力天花板太低。桌面宠物核心是“活物感”，它需要连续不断的待机动画、走路动画、点击反馈、情绪变化。帧动画确实能实现，但每帧就是一张PNG，一个高品质宠物光待机动作可能就要几十上百帧，包体直接爆炸。如果改成Spine骨骼动画，原生接入Spine运行时倒是可行，但Spine在原生侧做动态换装、颜色变换、局部骨骼控制时，API相当原始，写起来非常痛苦。

第二，复杂交互全部要手写。拖拽时的物理回弹、点击时的高亮扩散、长按弹出菜单的动画过渡，这些在原生里每一项都要单独写自定义View、写动画协调器、处理触摸冲突。一个宠物做下来，光交互代码就要两三千行，而且全是和业务无关的底层工作，维护成本很高。

第三，3D宠物根本没法做。Lottie再强也只能做2D矢量动画，想要带光影、带物理布料模拟的3D宠物，原生Android基本没有成熟的落地路径。

所以如果你是奔着做一个有灵魂、有表现力、有一定游戏性的桌面宠物去的，Unity几乎是当前最合理的选择，没有之一。

1.2 Unity方案能解决什么问题

Unity做桌面宠物，本质是“用游戏引擎的能力重新定义桌面宠物的体验上限”。

Unity带来的第一层价值是动画系统。Animator + AnimationClip这套状态机方案天生就是给“角色”设计的，待机、走路、睡觉、说话，每个状态之间可以配置切换过渡时间，加Blend Tree还能实现方向平滑混合。宠物动起来再也不是“切图”，而是像游戏角色一样自然过渡。

第二层价值是跨平台复用。Unity项目本身可以导出Android、iOS、Windows、macOS。也就是说你辛辛苦苦做的宠物模型、动画、交互逻辑，换个平台几乎不用重写，只需要重新适配一下每端的悬浮窗接口。如果公司之后想顺手做一个PC端桌面宠物，这份Unity代码就是现成的资产。

第三层价值是资源生态。Unity Asset Store上有大量现成的卡通角色、动画控制器、粒子特效。做宠物最常见的小鸟、猫咪、吉祥物模型，基本可以直接买到高质量的现成资源，省掉一整个3D建模周期。这是原生开发完全不具备的生态优势。

当然，选择Unity也要付出代价。引擎包体起步就多出十几MB，运行内存峰值比原生方案高出几十MB，功耗也会相应增加。所以这个方案适合的是“游戏向、内容向”的桌面宠物，而不是“轻量工具向”的悬浮球。

1.3 选型清单：不同需求走不同路线

我建议你先拿一张纸写清楚产品需求，再决定技术路线。这里给一个参考方案矩阵：

我个人的建议是：如果宠物只是App内的一个小彩蛋，原生足够；如果宠物是产品的核心卖点，Unity的投入完全值得。接下来我就以Unity方案为主线，把从Android悬浮窗嵌入到Unity侧动画控制的完整链路拆给你看。

2. Android全局悬浮窗原理与Unity嵌入方式

2.1 悬浮窗的底层机制和权限要点

Android本身没有“桌面”这个概念，所谓全局桌面宠物，本质是通过WindowsManager把一个View悬浮在所有应用之上。只要是全局悬浮，就必须用到系统WindowManager，核心代码如下：

WindowManager windowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE); WindowManager.LayoutParams params = new WindowManager.LayoutParams(); params.width = dp2px(context, 200); params.height = dp2px(context, 200); params.type = WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY; params.flags = LayoutParams.FLAG_NOT_FOCUSABLE; params.gravity = Gravity.TOP | Gravity.START;

这里的type是最关键的一个点。Android 8.0之前用TYPE_PHONE，但8.0以后系统强制要求悬浮窗必须用TYPE_APPLICATION_OVERLAY，否则直接抛异常。这个类型下的窗口层级在所有应用内容之上、状态栏之下，正好适合做常驻宠物。

权限方面，使用悬浮窗必须动态申请SYSTEM_ALERT_WINDOW权限。注意它属于特殊权限，不能用普通的requestPermissions弹窗申请，只能跳系统设置页让用户手动开启：

if (!Settings.canDrawOverlays(context)) { Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse("package:" + context.getPackageName())); intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(intent); }

这里有一个国产ROM的坑：MIUI、EMUI、ColorOS等厂商在ACTION_MANAGE_OVERLAY_PERMISSION之外还会加一层“自启动管理”和“后台弹出界面”的拦截。你明明在系统设置里开了悬浮窗权限，重启手机后依然可能被清理掉。稳妥的做法是在应用内专门做一个“权限检测页”，把Settings.canDrawOverlays和“应用是否在前台运行”一起展示给用户，引导他同时开启厂商自启动权限。

2.2 Unity导出Android工程后的嵌入路径

Unity工程开发完成后，要嵌入Android宿主工程，有两条常规路径。

默认路径是Build出APK让Unity自己跑，但桌面宠物需要宿主App负责权限引导、服务启动、数据统计等原生逻辑，所以一般走“导出Android Studio工程”的路线。在Unity Build Settings里勾选Export Project，就能生成一个包含unityLibrary模块的完整Android工程。

Unity导出工程里的核心是一个叫UnityPlayer的类，它负责加载Unity引擎和玩家的Native库。UnityPlayerActivity就是一个带有unityPlayer实例的Activity。但因为我们需要把Unity渲染画面挂到悬浮窗上，不能直接启动Activity，必须手动创建UnityPlayer实例并把它渲染出来的View添加到WindowManager里。

核心做法是这样：

public class PetOverlayService extends Service { private UnityPlayer unityPlayer; @Override public void onCreate() { super.onCreate(); unityPlayer = new UnityPlayer(this); WindowManager windowManager = (WindowManager) getSystemService(WINDOW_SERVICE); WindowManager.LayoutParams params = new WindowManager.LayoutParams( 480, 480, WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY, WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE, PixelFormat.TRANSLUCENT); params.gravity = Gravity.TOP | Gravity.START; windowManager.addView(unityPlayer, params); } }

new UnityPlayer(context)会启动Unity引擎并在内部创建一个渲染视图（UnityPlayerView），这个View内部通常是SurfaceView或TextureView的封装。直接把它塞进WindowManager，Unity的画面就能悬浮在全局窗口上。这个方案我实测下来是目前最干净的做法，比用Activity再取SurfaceView的方式省掉了很多生命周期转场问题。

2.3 Unity端透明背景配置指南

桌面宠物一定是异形的，宠物以外的区域需要完全透明，否则一个黑底白块浮在屏幕上那是灾难。Unity侧要做两件事，缺一不可。

第一件事是设置相机清空颜色为透明。在任意用来渲染宠物的Camera上挂一个脚本，初始化时执行：

Camera cam = GetComponent<Camera>(); cam.clearFlags = CameraClearFlags.SolidColor; cam.backgroundColor = new Color(0, 0, 0, 0);

clearFlags如果用默认的Skybox，背景会用天空盒填充，Alpha通道是黑的；用SolidColor并把颜色的Alpha设为0，才能输出全透明背景。这一步很多人知道，但可能会漏掉下面的关键设置。

第二件事是切换Graphics API。Unity导出的Android工程默认Graphics API列表通常是Vulkan优先、OpenGLES 3.0其次。Vulkan模式下，某些机型对SurfaceView的透明通道支持有问题，会出现“该透明的地方变黑但不透”的情况。我的经验是：桌面宠物项目建议在Player Settings里把Graphics APIs勾成OpenGL ES 3.0，并移除Vulkan。透明通道用OpenGLES 3.0最稳，兼容性也最好。

Edit > Project Settings > Player > Other Settings > Graphics APIs 取消勾选 Auto Graphics API 移除 Vulkan，确保 OpenGLES3 在列表中

还有一个小细节：Unity里的Canvas屏幕上有时会默认带一个不透明的UI相机背景，如果宠物界面用了多个Camera，需要检查每个用到UI的Camera是否也都设了透明背景。我就遇到过主Camera透明了，但UI Overlay相机还带着蓝色背景，调试了半天才发现是另一个相机导致的。

3. Unity侧核心实现：状态机、拖拽与交互菜单

3.1 宠物状态机的架构与切换逻辑

桌面宠物本质上是一个“永远在运行的角色”，所以状态机设计会直接决定代码质量和后续可扩展性。我常用的状态划分方式如下：

在代码层面，我用Animator来承载这些状态，状态转换通过SetBool、SetTrigger驱动。这里有一个值得注意的经验：Idle状态一定不要只配一个长循环动画，至少要给出3到5个不同的待机动画片段（比如左右张望、舔爪子、伸懒腰），用RandomRange随机切换，宠物才“活”。单一待机动画会让用户30秒就腻掉。

Animator的切换脚本我一般这样写：

private void Update() { if (_isDragging) return; if (Time.time - _lastTouchTime > 120f) { _animator.SetBool("Sleep", true); return; } float idleTime = Time.time - _stateChangedTime; if (_currentState == PlayerState.Idle && idleTime > Random.Range(3f, 8f)) { int index = Random.Range(0, _randomIdleClips.Length); _animator.SetTrigger("RandomIdle"); _animator.SetInteger("RandomIdleIndex", index); _stateChangedTime = Time.time; } }

_lastTouchTime是一个全局交互时间戳，每次触摸、拖拽、点击都更新它。整个状态机以它为锚点判断“太久没理它了”，这个设计简单但很有效，可以保证宠物从任何一个状态都能优雅回到睡眠状态。

3.2 拖拽实现：坐标换算与防抖防跳

桌宠最核心的交互是拖拽。很多第一次做的人直接把Unity的屏幕坐标当成屏幕坐标用，拖起来发现宠物要么飞出去，要么鼠标和宠物差一大截。原因在于Unity的坐标原点和Android WindowManager的坐标原点不一致。

Unity的Input.mousePosition原点在屏幕左下角，而WindowManager更新悬浮窗位置时用的坐标原点在屏幕左上角，y方向正好相反。所以正确的换算要做一次坐标系翻转，然后再叠加宠物View自身的宽高偏移：

private void OnDrag(Vector2 touchPosition) { RectTransform rect = (RectTransform)transform; float petWidth = rect.sizeDelta.x * rect.lossyScale.x; float petHeight = rect.sizeDelta.y * rect.lossyScale.y; float screenX = touchPosition.x; float screenY = Screen.height - touchPosition.y; // 让宠物中心对准手指 float finalX = screenX - petWidth / 2f; float finalY = screenY - petHeight / 2f; AndroidBridge.UpdateOverlayPosition(finalX, finalY); }

AndroidBridge.UpdateOverlayPosition是桥接层方法，对应Android侧更新LayoutParams坐标的操作。注意悬浮窗坐标是相对整个屏幕的绝对坐标，不能用相对父容器的子坐标。

第二个高频坑是“点击变拖拽”。用户明明只是点了一下宠物，结果因为手抖位移了3像素，就被误判成拖拽，体验很糟。解决办法是加一个位移阈值判断，一般超过15像素才算真正进入拖拽状态，之前都当作点击等待：

private void UpdateTouch() { bool isTouching = Input.touchCount > 0 || Input.GetMouseButton(0); if (!isTouching) return; Vector2 currentPos = Input.touchCount > 0 ? Input.GetTouch(0).position : (Vector2)Input.mousePosition; if (!_pressedDown) { _pressDownPos = currentPos; _pressDownTime = Time.time; _pressedDown = true; return; } bool isDrag = Vector2.Distance(currentPos, _pressDownPos) > 15f; if (isDrag) { _isDragging = true; _animator.SetBool("Dragging", true); OnDrag(currentPos); } }

注意_pressedDown标记一定要在抬起时重置，并且拖拽结束时要恢复Animator状态回待机。

3.3 长按菜单与UGUI界面设计

长按宠物弹出操作菜单，是桌面宠物必不可少的功能。菜单里通常会放：更换皮肤、喂食、关闭宠物、打开设置等入口。

菜单本身用Unity UGUI Canvas实现，核心是设置手机的触屏操作触发长按事件。我用计时器实现，吃“位移阈值”和“长按时间阈值”的双重判断：

private void CheckLongPress(float deltaTime) { if (!_pressedDown) return; // 位移过大则取消长按 if (Vector2.Distance(_currentPos, _pressDownPos) > 10f) return; _longPressTime += deltaTime; if (_longPressTime >= 0.6f && !_menuOpened) { OpenMenu(); } }

菜单弹出后，需要处理一个问题：Unity的UI默认是全屏交互的，如果菜单只占宠物旁边的一块区域，但Unity的Canvas还是全屏的，会导致菜单外的区域点击全部被Unity捕获，悬浮窗下方原本要点的App按钮反而点不了。

解决方法是动态调整Unity悬浮窗大小。平时WindowManager窗口只有宠物尺寸，打开菜单时把窗口尺寸扩展为菜单区域大小，这样Unity内部就能正确捕获菜单区域的点击，菜单外部区域因为窗口透明区域自带touchable穿透，可以正常点击下方App。这也是为什么我在Android侧用FLAG_NOT_TOUCHABLE和FLAG_NOT_FOCUSABLE组合而不是直接给整个窗口全屏的原因。

3.4 动画素材导入与性能调优

资源这块，3D宠物模型我建议优先从Asset Store找Poly-style或Toon风格的角色，这类模型面数低、贴图小，在手机上跑很稳。如果是2D宠物，Animator配Spine也行，Unity官方有Spine Runtime插件，支持直接在Animator里切换骨骼动作。

需要注意的一个性能细节是Application.targetFrameRate。桌面宠物不需要60帧，它只是悬浮在桌面的一个小角色，30帧就足够流畅。把帧率限制在30能把GPU负载显著降下来，手机整体功耗也会降低不少：

void Awake() { Application.targetFrameRate = 30; QualitySettings.vSyncCount = 0; Screen.sleepTimeout = SleepTimeout.NeverSleep; }

SleepTimeout.NeverSleep有必要设置，否则屏幕自动休眠后Unity渲染会被系统强制暂停，导致宠物在熄屏锁屏后状态出问题。但注意这个设置只影响UnityApplication持有的窗口，在悬浮窗模式下，系统窗口层面的screen timeout仍是独立的，实际测试中加上这一句保险一些。

4. Android原生桥接层与生命周期管理

4.1 Unity与Android的双向通信实现

桌面宠物不是纯Unity独角戏，原生侧的悬浮窗管理、权限判断、开机自启、省电策略都需要Unity能拿到Android的运行状态。Unity调用Android方法非常简单：

public static class AndroidBridge { static readonly AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"); static readonly AndroidJavaObject currentActivity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity"); public static void UpdateOverlayPosition(float x, float y) { currentActivity.Call("updateOverlayPosition", x, y); } public static void ClosePet() { currentActivity.Call("stopInUnity"); } }

Android侧收到调用后，持有Service引用并更新LayoutParams。注意这里我直接传了String和float这些基础类型，Unity会自动做类型转换，不需要额外处理。

Android调用Unity侧方法，常规做法是UnitySendMessage。Unity官方在Java侧封了一个UnityPlayer.UnitySendMessage(gameObjectName, methodName, message)，可以直接调：

public class PetOverlayService extends Service { public static PetOverlayService instance; private void sendToUnity(String gameObject, String method, String message) { if (instance != null) { UnityPlayer.UnitySendMessage(gameObject, method, message); } } }

Unity侧接收端只需要在目标GameObject上挂对应方法：

public class PetEventReceiver : MonoBehaviour { public void OnReceiveUnityMessage(string message) { Debug.Log("收到Android消息: " + message); // 根据消息内容切换宠物状态 } }

这套双向通道是桌面宠物项目的中枢神经。权限变化、网络状态、亮屏熄屏、用户点原生端设置项，全都走这套通道，保持Unity侧逻辑干净，试图在Unity里做所有事情就会陷入混乱。

4.2 让宠物尽量“全局存活”

桌面宠物最怕的就是用了几分钟后进程被系统杀了。Android杀后台进程有一套复杂的优先级机制，悬浮窗Service并不属于天然高优先级，所以要主动做一些处理。

第一步，把悬浮窗挂在Service里，而不是Activity里。Activity销毁时Service还在，宠物就能继续运行。这是最基础的一步。

第二步，使用前台服务提高进程优先级。前台服务会常驻系统通知栏，用户能看到“桌面宠物正在运行”的提示，系统杀掉它的概率会大大降低。Android 14（API 34）要求创建前台服务时必须指定foregroundServiceType，桌面宠物这类场景使用specialUse类型比较合理，Manifest里要声明：

<service android:name=".PetOverlayService" android:enabled="true" android:exported="false" android:foregroundServiceType="specialUse"> <property android:name="android.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE" android:value="desktop_pet_overlay" /> </service>

第三步，开机自启。在Manifest里注册静态广播接收器监听BOOT_COMPLETED，开机后拉起Service：

<receiver android:name=".BootReceiver" android:exported="true"> <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> </intent-filter> </receiver>

public class BootReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) { Intent serviceIntent = new Intent(context, PetOverlayService.class); context.startForegroundService(serviceIntent); } } }

开机自启这里有一个需要注意的合规点：不建议做任何形式的“防杀掉后台自启”的黑科技，比如双进程守护、互相拉起、定时检查自启。现代Android系统对这些行为限制很严格，强行实现反而容易上应用商店的违规名单。老老实实引导用户把App加入厂商的“后台运行保护白名单”，效果比任何黑科技都稳。

4.3 权限引导与厂商ROM适配

国产ROM的悬浮窗权限与其说是技术问题，不如说是产品体验问题。不同厂商对Settings.canDrawOverlays的判断结果一致，但用户手动开启悬浮窗权限的入口路径完全不同：

开发时不可能记住每一家的路径，产品设计上做一套完整的“引导页”即可。首次启动时弹权限检测页，检测到没有悬浮窗权限就把检测状态展示出来，每次跳转系统设置都带package参数，用户找到开关后在引导页点“我已开启，立即开始”。

这里分享一个实测经验：有些Android定制的返回逻辑会把用户从系统设置带回App后重新创建Activity，导致权限引导页判断状态时闪退。建议在静态变量里保存“是否从权限页返回”的标记，在onResume里判断权限状态而不是依赖Activity的返回键回调。

4.4 生命周期管理与内存释放

Unity引擎是一个庞然大物，它持有的内存通常包含native层和托管层。桌面宠物常驻后台，不及时释放会导致手机越来越卡。核心是做到三点。

第一点是退到后台时暂停渲染。监听系统亮屏锁屏广播，锁屏后调用UnityPlayer.pause()，亮屏后调用UnityPlayer.resume()。这个简单的暂停能在宠物不显示时把CPU占用降掉一大半。

第二点是清空不用的资源。桌面宠物会有多个皮肤、多套动画，切换宠物造型时一定要把旧资源先Resources.UnloadUnusedAssets()再加载新资源，否则内存峰值会一次比一次高：

public void ChangePetVisual(GameObject newPetPrefab) { Destroy(currentPetInstance); Resources.UnloadUnusedAssets(); currentPetInstance = Instantiate(newPetPrefab); }

第三点是退出时的彻底销毁。用户关闭宠物，不仅仅是Unity侧隐藏窗口，Android侧要调用：

@Override public void onDestroy() { if (unityPlayer != null) { unityPlayer.quit(); unityPlayer = null; } super.onDestroy(); }

unityPlayer.quit()会终止Unity的Native线程，如果不调用这个方法而直接移除View，Unity引擎线程会继续在后台空转，导致内存和CPU持续占用。

5. 落地过程中的高频坑与排查速查表

5.1 透明背景失效与黑底问题

这是桌面宠物方案最常遇到的问题。现象是窗口正常添加了，Unity内容也渲染出来了，但整个窗口底色是黑色，无法透明。

按顺序排查三个点：第一检查Camera的clearFlags是否为SolidColor且背景色Alpha为0；第二检查Player Settings里的Graphics API是不是Vulkan在先，如果是就改成OpenGLES3；第三检查有没有挂多个Camera，UI Overlay相机判断透明配置是否一致。

还有一个隐蔽点：如果导出的Android工程在Manifest里给Activity或Application设置了android:theme，部分Theme资源（比如某些Material主题）会强制窗口不透明。UnityPlayerView挂在Service上时不受Activity Theme影响，但如果有人把UnityPlayerView塞回Activity里头，就会踩到这个坑。

5.2 触摸穿透问题

桌面宠物窗口占200x200像素，但站在系统的角度，这200x200的区域全都被Unity捕获。如果宠物实际只占窗口左下角一小块，窗口其他区域是透明的，但点击这些透明区域时会全部落进Unity手里，下方的App按钮点不到，体验极其奇怪。

解决方式有两条路。一条是动态管理窗口大小，宠物缩小占多少区域，窗口就设多大，尽量贴近宠物本体。另一条是利用Android的FLAG_NOT_TOUCHABLE和FLAG_NOT_FOCUSABLE。当宠物处于全屏菜单打开状态时，把窗口的FLAG_NOT_TOUCHABLE移除让Unity能接收事件；菜单关闭后重新加回这个flag，让事件穿透下去。实际开发中两者结合使用效果最好。

5.3 拖拽卡顿与坐标偏移

拖拽卡顿主要不是Unity渲染慢，而是WindowManager更新坐标的频率太高。Unity每帧都在调用Android侧更新LayoutParams，会触发频繁的View重绘和重排。优化办法是降低坐标上报频率，Unity侧做一次间隔限制：

private float _lastSendTime; private void OnDrag(Vector2 touchPosition) { if (Time.time - _lastSendTime < 0.03f) return; // 约30Hz上报 _lastSendTime = Time.time; // 更新坐标逻辑 }

坐标偏移问题通常是系统通知栏和导航栏高度没算进去。WindowManager坐标是相对整个屏幕的，但Unity的Screen.height拿到的分辨率可能比系统实际显示区域小。建议在Android侧直接读取resources.getDisplayMetrics()拿实际像素值，并通过通信通道传给Unity，让Unity使用这份显示参数做坐标换算。

5.4 打包崩溃与So库冲突

Unity导出Android工程再集成宿主App时，最容易碰到的是unityLibrary和宿主工程引用的第三方库存在libunity.so或libil2cpp.so的冲突。排查方式很简单：检查宿主工程build.gradle里是否显式添加了exclude规则排除Unity模块里不含的abi目录，或者宿主自己的So库是否打进了完整abi列表。

还有一个常见崩溃是ClassNotFoundException: com.unity3d.player.UnityPlayer。这通常是因为宿主工程用了混淆（ProGuard/R8），把UnityPlayer类名给改了。在proguard-rules.pro里加一行：

-keep class com.unity3d.player.** { *; }

5.5 常见问题速查表

聊点我个人做这个项目的真实感受

如果你决定走Unity方案，最后的成品质感会明显比原生方案高出几个档次，但开发周期的预算也要按一个中型游戏模块去算，不是两三天能糊出来的小工具。

我个人实测下来有几个体会想分享。第一，别一上来就想着把系统级的复杂功能（托盘菜单、全局快捷键、跨屏幕交互）全部做进第一个版本。先把Unity宠物在悬浮窗上显示出来、能拖、能换几个表情、能吃个食物，这四条跑通了，主架构就已经稳了，后面的功能在这个骨架上加就是。第二，务必提前准备一套完整的“宠物调试工具”，比如在Unity Editor里模拟悬浮窗尺寸、模拟手机触摸模式，否则每测一次拖拽都要真机装APK，节奏会非常痛苦。

这个方案的扩展空间其实很大，加语音交互、加宠物成长数值、加网络同步玩法，Unity都接得住。核心思路就是我今天写的这套：Unity负责表现，Android负责窗口和系统能力，两者通过轻量桥接层保持边界清晰。只要这个边界不破，后续迭代怎么玩都不会翻车。