Unity3D游戏开发实战：从“水果忍者”源码解析2D物理与对象池优化-尧图网络科技

1. 项目概述：从“切水果”到游戏开发实战

“水果忍者”这款游戏，相信大家都不陌生，它曾经是智能手机触屏时代的一个标志性符号。手指划过屏幕，切开飞溅的水果，那种爽快的反馈感，至今仍让许多玩家津津乐道。但作为一名开发者，尤其是对Unity3D感兴趣的初学者或进阶者，你是否想过，这个看似简单的游戏背后，究竟藏着怎样的技术实现逻辑？今天，我们就来深度解析一份用Unity3D实现的“水果忍者”游戏源码，这不仅仅是一次代码阅读，更是一次从零到一理解2D物理游戏核心机制的绝佳实战。

这份源码的价值，远不止于让你能“复刻”一个游戏。通过拆解它，你将能透彻理解Unity中2D物理系统（Rigidbody 2D, Collider 2D）与输入系统（Touch, Mouse）的协同工作，掌握对象池（Object Pooling）这一优化性能的黄金法则，并学会如何构建一个清晰、可维护的游戏状态管理（Game State Management）框架。同时，我们还会探讨如何将粒子系统（Particle System）用于视觉反馈，以及UGUI如何驱动流畅的UI交互。无论你是刚学完Unity基础语法的新手，还是想深化游戏架构理解的中级开发者，这次源码之旅都将让你收获满满。

2. 核心模块设计与架构思路拆解

2.1 游戏循环与状态管理：一切有序运行的基础

一个游戏之所以能流畅运行，核心在于其严谨的“游戏循环”和清晰的“状态管理”。在“水果忍者”这类休闲游戏中，状态通常包括：开始界面、游戏进行中、暂停、结算（胜利/失败）等。一份优秀的源码，绝不会让这些状态混杂在Update()函数里用一堆if-else来判断。

常见的实现思路是使用“状态模式”或一个简单的枚举状态机。在解析的源码中，你可能会找到一个名为GameManager的单例类，它内部维护着一个GameState枚举（如Menu,Playing,Paused,GameOver）。这个管理器是整个游戏的大脑，它负责：

状态切换：响应“开始游戏”、“暂停”、“重新开始”等UI按钮事件，安全地切换当前游戏状态。
全局控制：根据当前状态，决定是否生成水果、是否检测输入、是否更新分数。
资源管理：在游戏开始时初始化对象池，在游戏结束时清理场景。

注意：很多新手会直接把生成水果、计分的逻辑挂在GameManager上，这会导致类职责过重，难以维护。更好的做法是，GameManager只负责协调，具体的生成逻辑交给FruitSpawner，计分逻辑交给ScoreManager。

2.2 对象生成与物理系统：让水果“飞”起来

“水果忍者”的核心玩法是水果从屏幕底部随机位置以随机的角度和速度被“抛射”出来。这涉及到两个关键技术点：动态生成和2D物理模拟。

1. 水果生成器（FruitSpawner）：这个组件负责定时（例如每隔1-3秒）在屏幕下方不可见区域随机选择一个生成点。它不会用Instantiate和Destroy来频繁创建销毁水果预制体，那样会产生大量GC（垃圾回收），导致游戏卡顿。这里必然要用到“对象池”技术。

对象池（ObjectPool）：游戏初始化时，预先创建一定数量（如20个）的每种水果预制体，并设置为非激活状态，存入一个队列或列表。
获取对象：当需要生成一个水果时，从池中取出一个未被使用的（非激活的）水果，设置其位置、旋转、速度，然后激活它。
回收对象：当水果被切开或飞出屏幕后，不是销毁它，而是将其失活，并放回池中等待下次使用。源码中的Fruit类上，很可能有一个OnBecameInvisible()方法或通过碰撞检测来触发回收。

2. 物理组件配置：每个水果预制体上，至少会挂载以下组件：

Rigidbody 2D：这是核心。Body Type通常设为Dynamic，使其受物理引擎控制。重力系数（Gravity Scale）会设置为一个正值，让水果有抛物线下落的感觉。为了模拟“抛射”，在生成时，会给它的Rigidbody2D.velocity赋予一个初始向上的速度，并可能叠加一个随机的水平速度分量。
Collider 2D：通常使用Circle Collider 2D或Polygon Collider 2D来匹配水果形状，用于检测是否被“切中”。
脚本组件（Fruit）：这个脚本负责水果自身的逻辑，比如被切开时的表现、得分等。

2.3 输入检测与切割判定：实现“刀光剑影”

这是游戏交互的灵魂。玩家手指/鼠标划过的轨迹，需要被实时检测并用于判断是否与水果发生“切割”。

1. 输入轨迹记录：在Update()或更好的FixedUpdate()中，持续检测输入。对于移动端，使用Input.touches；对于PC端，使用Input.GetMouseButton()。核心是记录每一帧的输入位置（屏幕坐标），并将其转换为世界坐标。

// 示例：记录鼠标/触摸轨迹点 if (Input.GetMouseButton(0)) { Vector3 currentPos = Camera.main.ScreenToWorldPoint(Input.mousePosition); currentPos.z = 0; // 确保在2D平面 // 将currentPos加入一个List<Vector3>轨迹点列表 }

轨迹点列表需要被管理，通常只保留最近一小段时间（比如0.2秒）内的点，用于构成一条短暂的“切割线”。

2. 切割判定原理（核心算法）：判定是否切中水果，并不是用轨迹线去和水果的Collider做复杂的物理检测（虽然Unity有Collider2D.OverlapPoint，但用于连续线效率不高）。更高效、更通用的方法是“帧间线段与碰撞体相交检测”。

将连续的轨迹点，每相邻两点连成一条线段。
遍历场景中所有“可切割”的水果。
对于每个水果，判断这条线段是否与其碰撞体（如Circle Collider）相交。这可以通过计算点到线段距离的数学方法来实现。
如果相交，则判定为“切中”，触发水果的切割效果。

3. 视觉反馈：刀光效果判定成功后，需要在切割发生的位置生成一个视觉上的“刀光”。这通常是一个细长的、半透明的Sprite，其位置和旋转根据切割线段的方向实时计算。更炫酷的效果会使用粒子系统来模拟火星溅射。

2.4 分数、连击与UI反馈：驱动玩家的成就感

一个游戏好不好玩，反馈系统至关重要。

分数管理（ScoreManager）：这是一个独立的单例或由GameManager管理的模块。不同水果有不同分值（如西瓜10分，香蕉5分）。当水果被成功切割，Fruit脚本会调用ScoreManager.Instance.AddScore(point)。
连击系统（Combo）：这是增加游戏爽快感的关键。实现原理是：在一个很短的时间窗口内（比如1秒），如果连续切割水果，连击数增加。每次切割都会刷新这个时间窗口。连击数越高，单次切割的分数加成越高（例如，连击x2时，得分翻倍）。源码中通常会有一个计时器来管理这个时间窗口。
UI更新：UGUI的Text或TextMeshPro组件会绑定到分数和连击数上。使用事件驱动的方式更新UI是更优解，例如，当分数改变时，触发一个OnScoreChanged事件，UI监听此事件并更新显示，这样解耦了逻辑和表现。

3. 关键代码模块深度解析

3.1 Fruit.cs：水果对象的完整生命周期管理

让我们深入一个典型的Fruit类，看看它如何管理从生成到被回收的整个生命周期。

public class Fruit : MonoBehaviour { public int scoreValue = 5; // 该水果的基础分值 public GameObject sliceEffectPrefab; // 被切开时的特效预制体 public AudioClip sliceSound; // 切开音效 private Rigidbody2D rb; private bool isSliced = false; // 标记是否已被切开，防止重复切割 void Start() { rb = GetComponent<Rigidbody2D>(); // 生成时给予一个随机的初始力，模拟抛射 Vector2 randomForce = new Vector2(Random.Range(-2f, 2f), Random.Range(8f, 12f)); rb.AddForce(randomForce, ForceMode2D.Impulse); // 给予一个随机旋转扭矩 rb.AddTorque(Random.Range(-5f, 5f)); } // 核心方法：被切割时调用 public void Slice(Vector2 sliceDirection) { if (isSliced) return; // 防止一帧内被多次切割 isSliced = true; // 1. 增加分数 GameManager.Instance.AddScore(scoreValue); // 2. 播放音效 AudioSource.PlayClipAtPoint(sliceSound, transform.position); // 3. 生成切割特效（如粒子、刀光） if (sliceEffectPrefab != null) { Instantiate(sliceEffectPrefab, transform.position, Quaternion.identity); } // 4. 禁用当前完整水果的渲染器和碰撞体 GetComponent<SpriteRenderer>().enabled = false; GetComponent<Collider2D>().enabled = false; // 5. 激活“被切开后”的两半水果（通常是两个子物体，已预先做好） foreach (Transform child in transform) { if (child.CompareTag("SlicedPart")) { child.gameObject.SetActive(true); Rigidbody2D partRb = child.GetComponent<Rigidbody2D>(); if (partRb != null) { // 给两半一个基于切割方向的力，使其飞散 partRb.AddForce(sliceDirection * Random.Range(3f, 6f), ForceMode2D.Impulse); partRb.AddTorque(Random.Range(-10f, 10f)); } } } // 6. 延迟回收（例如1秒后，等两半水果飞散动画完成） StartCoroutine(DeactivateAfterDelay(1f)); } IEnumerator DeactivateAfterDelay(float delay) { yield return new WaitForSeconds(delay); // 回收自身到对象池，而不是Destroy ObjectPool.Instance.ReturnToPool(gameObject); } // 当水果飞出屏幕时自动回收（利用OnBecameInvisible回调） void OnBecameInvisible() { if (!isSliced) // 没被切中就飞出屏幕，可能是失误，可以扣生命值 { GameManager.Instance.MissFruit(); } ObjectPool.Instance.ReturnToPool(gameObject); } }

代码解读与技巧：

状态标记isSliced：至关重要。因为切割检测可能在一帧内对同一个水果触发多次（轨迹线段可能与碰撞体有多个交点），这个标记能确保切割逻辑只执行一次。
子物体作为切割部分：这是一种非常高效的做法。预制体里包含一个完整的Sprite（父物体）和两个隐藏的“半片”Sprite（子物体）。切割时只需切换显示状态，避免了运行时动态生成网格的复杂性和性能开销。
协程用于延迟回收：使用StartCoroutine让对象在完成视觉效果（两半飞散）后再回收，体验更自然。
OnBecameInvisible：这是MonoBehaviour的一个内置回调，当渲染器离开任何摄像机视野时触发。注意：它只对带有Renderer组件的物体有效。这是一个非常方便的对象回收触发器。

3.2 ObjectPool.cs：高性能对象池的实现

对象池是避免GC卡顿的利器。下面是一个简化但功能完整的对象池实现。

using System.Collections.Generic; using UnityEngine; public class ObjectPool : MonoBehaviour { public static ObjectPool Instance; // 单例模式 [System.Serializable] public class Pool { public string tag; // 标识符，如"Apple", "Banana" public GameObject prefab; public int size; // 初始池大小 } public List<Pool> pools; // 在Inspector中配置 private Dictionary<string, Queue<GameObject>> poolDictionary; void Awake() { Instance = this; poolDictionary = new Dictionary<string, Queue<GameObject>>(); // 初始化所有对象池 foreach (Pool pool in pools) { Queue<GameObject> objectPool = new Queue<GameObject>(); for (int i = 0; i < pool.size; i++) { GameObject obj = Instantiate(pool.prefab); obj.SetActive(false); obj.transform.SetParent(this.transform); // 统一管理，保持场景整洁 objectPool.Enqueue(obj); } poolDictionary.Add(pool.tag, objectPool); } } // 从池中取出一个对象 public GameObject SpawnFromPool(string tag, Vector3 position, Quaternion rotation) { if (!poolDictionary.ContainsKey(tag)) { Debug.LogWarning("Pool with tag " + tag + " doesn't exist."); return null; } // 如果池空了，动态扩容（实例化一个新对象） if (poolDictionary[tag].Count == 0) { GameObject newObj = Instantiate(pools.Find(x => x.tag == tag).prefab); newObj.transform.SetParent(this.transform); // 注意：新创建的对象不在队列里，但逻辑上属于池。更严谨的做法是将其入队。 } GameObject objectToSpawn = poolDictionary[tag].Dequeue(); objectToSpawn.SetActive(true); objectToSpawn.transform.position = position; objectToSpawn.transform.rotation = rotation; // 调用对象上的OnSpawn方法（如果存在），进行初始化 IPooledObject pooledObj = objectToSpawn.GetComponent<IPooledObject>(); pooledObj?.OnObjectSpawn(); return objectToSpawn; } // 将对象放回池中 public void ReturnToPool(GameObject obj) { string tag = obj.name.Replace("(Clone)", "").Trim(); // 简单通过名字获取tag，有风险 // 更好的做法：在对象上挂一个脚本，存储其poolTag。 if (poolDictionary.ContainsKey(tag)) { obj.SetActive(false); poolDictionary[tag].Enqueue(obj); } else { Destroy(obj); // 不属于任何已知池，则销毁 } } } // 可选接口，用于对象被取出池时的初始化 public interface IPooledObject { void OnObjectSpawn(); }

实现要点与避坑指南：

单例模式：方便全局访问。但要注意在场景切换时如果存在多个ObjectPool可能会冲突，可以使用DontDestroyOnLoad或更稳健的资源管理方案。
字典+队列：使用Dictionary<string, Queue<GameObject>>来管理不同类型的对象池，存取效率高（O(1)）。
动态扩容：在SpawnFromPool中检查队列是否为空，为空则即时实例化一个新对象。这是一种惰性扩容策略，避免了初始化时创建过多可能用不到的对象。
对象标识问题：示例中通过obj.name反推tag的方法非常脆弱，因为物体名字可能被修改。更可靠的做法是：创建一个PooledObject组件挂在每个预制体上，里面有一个public string poolTag字段，在从池中取出时赋值，回收时读取。
初始化回调：通过IPooledObject接口提供OnObjectSpawn方法，这样当对象从池中取出时，可以自动重置其状态（如血量、速度、isSliced标志等），而无需在外部手动调用一堆GetComponent。

3.3 Blade.cs 或 SwipeDetector.cs：切割检测的实现精髓

这是游戏中最具技巧性的部分。一个高效的切割检测器需要平衡精度和性能。

public class Blade : MonoBehaviour { public float minSliceVelocity = 0.01f; // 最小切割速度，过滤误触 public TrailRenderer trailRenderer; // 拖尾渲染器，用于绘制刀光 public GameObject bladeTrailPrefab; // 或使用动态生成的Trail private Camera mainCamera; private Collider2D bladeCollider; // 用于碰撞检测的另一种方案 private Vector2 previousPosition; private bool isSlicing = false; private GameObject currentBladeTrail; void Awake() { mainCamera = Camera.main; bladeCollider = GetComponent<Collider2D>(); bladeCollider.enabled = false; // 初始关闭碰撞 } void Update() { // 检测输入开始 if (Input.GetMouseButtonDown(0)) { StartSlicing(); } // 检测输入持续 else if (Input.GetMouseButton(0)) { ContinueSlicing(); } // 检测输入结束 else if (Input.GetMouseButtonUp(0)) { StopSlicing(); } } void StartSlicing() { isSlicing = true; UpdateBladePosition(); // 初始化位置 previousPosition = transform.position; // 激活碰撞体 bladeCollider.enabled = true; // 生成刀光拖尾 currentBladeTrail = Instantiate(bladeTrailPrefab, transform); trailRenderer = currentBladeTrail.GetComponent<TrailRenderer>(); trailRenderer.Clear(); // 清除上一段拖尾 } void ContinueSlicing() { if (!isSlicing) return; UpdateBladePosition(); // 计算当前帧速度，用于判断是否为有效切割 float velocity = (transform.position - (Vector3)previousPosition).magnitude / Time.deltaTime; if (velocity > minSliceVelocity) { bladeCollider.enabled = true; // 方法A：使用物理碰撞检测（需在Fruit上添加OnTriggerEnter2D） // 方法B：使用帧间线段检测（见下文补充） } else { bladeCollider.enabled = false; // 移动太慢，不视为切割 } previousPosition = transform.position; } void StopSlicing() { isSlicing = false; bladeCollider.enabled = false; // 让刀光拖尾自然消失 if (currentBladeTrail != null) { currentBladeTrail.transform.SetParent(null); // 与刀身分离 Destroy(currentBladeTrail, trailRenderer.time); // 延迟销毁，等拖尾播放完 } } void UpdateBladePosition() { Vector3 newPosition = mainCamera.ScreenToWorldPoint(Input.mousePosition); newPosition.z = 0; // 锁定Z轴 transform.position = newPosition; } // 方法A：使用Trigger碰撞检测（需将Blade的Collider设为Trigger） // void OnTriggerEnter2D(Collider2D other) { // Fruit fruit = other.GetComponent<Fruit>(); // if (fruit != null) { // Vector2 sliceDirection = (transform.position - fruit.transform.position).normalized; // fruit.Slice(sliceDirection); // } // } }

方案对比与选择：

方案A（碰撞检测）：实现简单，直接利用Unity物理引擎。但需要将Blade的碰撞体设为Trigger，并且由于Blade移动很快，可能会发生“隧道效应”（即从物体一边穿到另一边而没有触发碰撞）。可以通过将Blade的碰撞体做成长条状，或在FixedUpdate中提高检测频率来缓解。
方案B（帧间线段检测）：这是更精确、更常用的方案。它不依赖Collider，而是在ContinueSlicing中，将上一帧和当前帧的Blade位置连成线段，然后遍历所有水果，用几何方法判断线段与水果碰撞体是否相交。性能开销稍大，但精度极高，是许多成熟“水果忍者”类项目的选择。

帧间线段检测的补充代码片段：

// 在ContinueSlicing中，在启用bladeCollider.enabled = true的位置替换为： Vector2 currentPos = transform.position; List<Fruit> fruitsToSlice = new List<Fruit>(); // 避免在遍历中修改集合 // 假设有一个全局可访问的所有活动水果列表，如 GameManager.Instance.activeFruits foreach (Fruit fruit in GameManager.Instance.activeFruits) { if (fruit == null || fruit.IsSliced) continue; if (IsLineIntersectingCircle(previousPosition, currentPos, fruit.transform.position, fruit.colliderRadius)) { fruitsToSlice.Add(fruit); } } foreach (Fruit fruit in fruitsToSlice) { Vector2 sliceDirection = (currentPos - previousPosition).normalized; fruit.Slice(sliceDirection); } // 需要实现 IsLineIntersectingCircle 函数（计算点到线段距离）

4. 性能优化与高级技巧

4.1 对象池的深度优化

基础的ObjectPool已经能解决大部分问题，但在大型或复杂的项目中，我们还可以进一步优化：

分层次与按需加载：不要把所有类型的对象都在游戏开始时初始化。可以根据游戏关卡进度，动态加载不同种类的水果池。例如，第一关只有苹果和香蕉，就只初始化这两个池。
池的收缩与扩容策略：上述示例是只扩不缩。在长时间游戏后，如果某一类对象需求暴增后又减少，池会变得很大，占用内存。可以增加一个机制：定期检查池中空闲对象的数量，如果超过某个阈值（比如初始大小的2倍）且持续一段时间，就销毁一部分，将池收缩到合理大小。
使用Stack代替Queue：对于取出和放回操作，Stack（栈）的Push和Pop也是O(1)复杂度，且逻辑上“后进先出”对对象池来说没有影响，有时性能略优于Queue。
预制体变体管理：如果同一种水果有多种皮肤（皮肤），不要在池里为每种皮肤创建不同的预制体。而是使用一个基础预制体，通过更换其SpriteRenderer的sprite属性来改变外观。这样池的复用率更高。

4.2 输入与物理更新的协调

在Update中处理输入并立即移动Blade，而在FixedUpdate中进行物理检测和响应，这是最佳实践。但要注意Update和FixedUpdate的频率可能不同，直接使用Update中的位置进行物理计算可能导致抖动或不精确。

解决方案：使用插值（Interpolation）

将Blade的Rigidbody 2D（如果使用物理方案）的插值模式设为Interpolate，这样物理引擎会在渲染帧之间平滑物体的运动。
对于自定义的线段检测，可以在FixedUpdate中执行检测逻辑，但使用从Update中获取并经过平滑处理的轨迹点列表。

4.3 视觉与音效的优化

粒子系统的合并绘制（Batching）：切割特效、果汁飞溅等会大量使用粒子系统。确保这些粒子系统的材质尽可能相同，并且勾选Enable GPU Instancing（如果支持），可以大幅提升渲染效率。
音频管理：每次切水果都播放音效，如果同时切多个，可能会创建多个AudioSource。最好使用一个集中的AudioManager，它管理一个AudioSource池，用于播放短促的音效，避免频繁的PlayClipAtPoint调用（它内部会创建临时GameObject）。
使用Sprite Atlas：将所有水果、UI元素的精灵图打包成一个图集（Sprite Atlas），可以减少Draw Call，显著提升2D游戏的渲染性能。这是Unity UGUI和2D项目的标准优化操作。

4.4 扩展玩法与代码设计模式

分析源码后，你可以思考如何扩展游戏，这能加深对架构的理解：

添加新水果类型：只需创建新的预制体，配置好Fruit脚本参数，并在FruitSpawner的生成列表中引用它。这体现了基于组件的设计优势。
添加炸弹等特殊物品：创建一个Bomb类，继承自一个共同的SliceableObject基类或实现ISliceable接口。在切割检测中，判断物体类型，如果是炸弹，则调用Bomb.Explode()方法，触发扣分或结束游戏。
实现多种刀光皮肤：使用策略模式或简单的配置方式。在Blade类中引用不同的TrailRenderer材质或颜色，玩家可以在设置中选择。
引入连击技能：当连击数达到一定数值（如10次），可以触发一个“时间减缓”或“全屏切割”的技能。这可以通过在GameManager中监听连击数变化事件来实现，很好地演示了观察者模式的应用。

5. 常见问题与调试技巧实录

在复现或学习此类源码时，你几乎一定会遇到下面这些问题。这里记录了我的排查过程和解决方案。

5.1 问题一：切割检测不灵敏，经常切不到水果

现象：手指划过了水果，但没有任何反应。排查步骤：

检查碰撞层（Layer）：这是最常见的原因。确保Blade和Fruit的GameObject所在的Layer没有被物理引擎忽略。在Edit -> Project Settings -> Physics 2D中查看Layer Collision Matrix，确保它们相互勾选。
检查碰撞体大小和形状：在Scene视图中，将Gizmos中的Collider显示打开，查看水果的Collider 2D是否与Sprite图像匹配。有时图片有透明边，但碰撞体太小。适当调整Collider的Offset和Size。
验证检测代码逻辑：如果使用自定义线段检测，在Debug.DrawLine(previousPosition, currentPos, Color.red);在Scene视图中绘制出检测线段，看它是否确实穿过了水果。检查IsLineIntersectingCircle函数中的距离计算阈值是否合理。
输入坐标转换：确认ScreenToWorldPoint转换是否正确。Camera.main是否指向了正确的2D正交摄像机？屏幕坐标的Z值传入是否正确？可以打印出转换后的世界坐标进行比对。

5.2 问题二：游戏运行一段时间后变得卡顿

现象：刚开始很流畅，玩几十秒后帧率明显下降。排查步骤：

首要怀疑：GC（垃圾回收）在Unity中，频繁的Instantiate和Destroy是导致GC卡顿的元凶。使用Unity Profiler (Window -> Analysis -> Profiler)，切换到CPU Usage模块，观察GC Alloc列。如果每一帧都有很高的分配（比如超过2KB），说明存在问题。
- 解决：确保所有动态生成的水果、特效都使用了对象池。即使是UI文本的频繁更新，也要考虑使用对象池来复用GameObject。
检查粒子系统：失控的粒子系统（如切割特效没有自动销毁）会产生大量粒子，耗尽性能。确保特效粒子系统的Duration、Start Lifetime设置合理，并且勾选了Stop Action为Destroy或Disable（配合对象池）。
查看Draw Call：在Profiler的Rendering区域或使用Stats面板，查看Draw Call数量是否异常高。如果每个水果都使用不同的材质，Draw Call会很高。解决：使用Sprite Atlas将所有水果精灵打包。

5.3 问题三：水果被切开后，两半不会飞散，或者飞散方向奇怪

现象：水果被切后，只是消失或分成两半静止不动。排查步骤：

检查“两半”预制体的物理组件：确保作为子物体的两半水果预制体自身也拥有Rigidbody 2D和Collider 2D。并且它们的Rigidbody 2D的Body Type是Dynamic。
检查力的施加：在Fruit.Slice()方法中，给两半施加的力sliceDirection是否正确打印或计算？sliceDirection应该是切割方向（刀光轨迹方向）的单位向量。可以先用一个固定的方向（如Vector2.up）测试，看两半是否会向上飞。
检查对象激活时机：确保在激活两半子物体（SetActive(true)）之后，再给它们施加力。如果先施加力再激活，力可能会被重置或忽略。
检查时间缩放（Time Scale）：如果游戏处于暂停状态（Time.timeScale = 0），物理模拟会停止，力不会产生效果。确保在施加力时游戏时间正常。

5.4 问题四：在移动设备上触摸不跟手，有延迟

现象：在手机上玩，刀光感觉滞后于手指。排查步骤：

目标帧率：确保应用设置了合理的帧率。在脚本的Awake或Start中，使用Application.targetFrameRate = 60;。对于移动设备，30或60是常见选择。
输入处理位置：触摸输入处理一定要放在Update()中，而不是FixedUpdate()中，因为FixedUpdate的频率是固定的（默认为0.02秒，50Hz），而Update与渲染帧率同步，更能即时响应触摸。
避免每帧创建Vector3：在记录轨迹点的代码中，如果每帧都new List<Vector3>()或频繁增删列表，会产生GC。应该复用同一个列表，使用List.Clear()来清空，或者使用Array和索引管理。
图形API与渲染设置：对于较老的移动设备，在Player Settings中，尝试使用OpenGL ES 2.0而不是Vulkan或Metal，兼容性更好。同时，关闭不必要的后期处理效果。

通过这份源码解析，我们不仅看到了一个经典游戏的实现骨架，更重要的，是学习了一套在Unity中构建2D物理互动游戏的标准方法论。从状态管理到对象池，从输入处理到性能优化，每一个环节都是你未来开发其他项目时可以复用的宝贵经验。最好的学习方式，就是打开Unity，亲手将这份源码（或根据本文思路重写一遍）运行起来，然后尝试去修改它、扩展它。当你成功添加了一个自己设计的“冰冻草莓”（切中后让时间变慢），或者一个“疯狂连击模式”时，你对游戏开发的理解，就真正地上了一个台阶。