1. 项目概述当调试不再需要“暂停”如果你是一名Unity开发者那么下面这个场景你一定不陌生游戏在运行时某个UI按钮的点击事件没触发或者一个角色的移动速度参数看起来不对劲。你眉头一皱暂停游戏打开Inspector面板在一堆折叠的组件里翻找那个可疑的变量修改保存再点击运行。然后你发现刚才的修改没生效或者更糟引发了新的问题于是你不得不再次暂停、查找、修改、运行……这个循环不仅打断了你的创作心流更严重的是它让你无法在游戏“活着”的时候直观地看到修改带来的即时反馈。这就是传统Unity编辑器调试流程的痛点调试与运行是割裂的。你无法在游戏运行的同时像操作编辑器一样去操作游戏对象、修改组件属性、甚至调用方法。而“Runtime Unity Editor”RUE的出现正是为了解决这个核心痛点。它本质上是一个可以集成到你的游戏构建版本无论是开发版、测试版还是最终发布版中的运行时编辑器。它允许你在游戏实际运行的过程中实时地查看和修改场景中的任何对象、组件和变量就像在Unity编辑器的Scene和Inspector视图中操作一样但这一切都发生在游戏进程内部。想象一下你的测试人员或策划在体验游戏时发现某个关卡的难度过高。传统流程下他需要向你描述问题你复现、修改、重新打包、再让他测试沟通成本和迭代周期都很长。而如果游戏集成了RUE测试人员可以直接在游戏内呼出一个调试面板将敌人的血量从100调低到80然后立刻就能感受到难度变化是否合适。这种“所见即所得所改即所得”的能力将调试和平衡工作从开发者的独有技能变成了整个团队可以参与的实时协作。我最初接触RUE是为了解决一个棘手的网络同步问题。在联机游戏中一个角色的状态在客户端和服务端不一致导致其位置“鬼畜”抖动。如果按照老办法我需要加日志、断点、反复启动客户端和服务端来对比数据效率极低。而将RUE集成到客户端后我可以在游戏运行时直接查看并对比该角色在本地和网络层缓存的两个位置向量并实时修改同步频率等参数问题在几分钟内就被定位并验证了解决方案。这种效率的提升是颠覆性的。2. 核心需求与场景深度解析2.1 谁需要Runtime Unity EditorRUE并非一个面向所有Unity项目的“万金油”工具。它的价值在特定场景和特定角色的工作流中会被无限放大。对于程序开发者快速原型与迭代当你需要快速验证一个游戏机制时比如调整一个物理弹道的重力系数或发射速度。传统方式需要反复修改代码、编译、运行。使用RUE你可以直接在运行的游戏里拖拽一个滑块观察弹道轨迹的实时变化找到最合适的数值。复杂Bug现场诊断有些Bug难以复现或者只在特定运行状态下出现。例如一个内存泄漏可能只在游戏运行半小时后发生。集成RUE后你可以在游戏运行的同时实时查看对象实例数量、监视特定组件的生命周期甚至手动触发垃圾回收来辅助判断而无需依赖冗长的日志输出或专业的性能分析工具如Profiler的事后分析。远程调试与现场支持对于发布到测试设备如真机、VR设备或分发给远程测试员的版本你无法直接连接Unity编辑器进行调试。RUE可以提供一个WebSocket或简单的网络接口允许你从另一台电脑连接到运行中的游戏进行远程的观察和调试极大方便了对外部测试版本的支持。对于策划与设计师实时数值平衡这是策划最核心的诉求之一。角色的攻击力、技能的冷却时间、道具的价格、关卡的刷怪频率……这些数值不再需要策划提需求、程序修改、打包、测试反馈的漫长循环。策划可以在试玩版本中直接通过RUE界面调整这些暴露出来的数值变量并立即体验调整后的效果实现真正意义上的“数据驱动”和快速迭代。内容配置验证设计师放置了一个新的怪物或道具在场景中但不确定其表现是否符合预期。通过RUE他可以实时启用/禁用这个物体调整其大小、颜色甚至修改其关联的脚本参数快速验证设计意图。对于测试人员精准问题报告测试人员不再需要模糊地描述“这个技能好像伤害不对”他可以截图RUE面板上显示的具体伤害计算公式和变量值甚至附上他尝试修改某个参数后问题是否消失的步骤让问题报告的信息量和准确性大幅提升。复杂状态复现与验证为了复现一个偶现的Bug测试人员可能需要执行一系列复杂操作。利用RUE他可以在疑似触发Bug前保存当前游戏状态通过RUE的序列化功能或者直接修改游戏状态到某个临界点加速Bug的复现过程。2.2 典型应用场景实战场景一移动平台真机性能调优在PC上运行流畅的游戏打包到手机后却出现卡顿。你怀疑是某个特效的粒子数量过多或是某个AI的更新频率太高。在真机上运行带有RUE的开发包你可以直接找到对应的ParticleSystem组件在游戏运行时将maxParticles从1000调低到500观察帧率是否立即提升。同样你可以找到AI的更新脚本将Update方法中的计算频率从每帧改为每5帧。这种实时调整并观察性能曲线如果RUE集成了简易性能显示的能力让性能优化从“盲人摸象”变成了“精准手术”。场景二UI/UX的即时微调UI元素的布局、颜色、字体大小、动画速度等往往需要反复调整才能达到最佳体验。美术或策划在试玩时觉得某个按钮反馈不够明显。通过RUE可以直接找到该按钮的Image组件实时调整其颜色比如从浅蓝调到亮蓝色或者修改点击动画的时长参数直到获得满意的视觉效果整个过程无需程序介入或重启游戏。场景三游戏逻辑的“热修补”假设游戏上线后发现一个商城道具的价格计算公式有误多了一个零。紧急情况下如果游戏集成了RUE并预留了管理接口运营人员可以通过后台向所有在线玩家的游戏实例发送一个指令动态修改内存中这个计算公式所引用的系数变量实现“热修复”避免强制玩家更新客户端。当然这需要非常谨慎的设计和安全校验。注意将RUE集成到正式发布版本中存在巨大安全风险。恶意玩家可能利用它修改游戏数据、解锁付费内容或开发外挂。因此务必通过编译指令如#if DEVELOPMENT_BUILD或#if UNITY_EDITOR或自定义的启动参数来严格控制RUE的启用条件确保它只出现在开发、测试和内部体验包中。3. 核心架构与实现原理拆解Runtime Unity Editor不是一个魔法黑盒它的实现建立在Unity引擎一系列强大的运行时反射和序列化机制之上。理解其核心原理能帮助你更好地使用它甚至在其基础上进行二次开发。3.1 基石Unity的运行时反射系统RUE最核心的能力来自于C#的System.Reflection和Unity封装的SerializedObject/SerializedProperty系统。对象发现与遍历RUE启动时会通过UnityEngine.Object.FindObjectsOfTypeGameObject()或更高效的UnityEngine.Object.FindObjectsByType获取场景中所有活跃的GameObject。然后对每个GameObject通过GetComponentsComponent()获取其挂载的所有组件。成员信息提取对于每个组件一个C#对象RUE使用Type.GetFields()和Type.GetProperties()获取其所有公共字段和属性。同时为了能显示私有变量这在调试时非常有用它可能会使用BindingFlags.NonPublic标志位。获取到的每个FieldInfo或PropertyInfo对象都包含了该成员的类型、名称和获取/设置其值的能力。值读写与UI绑定当你在RUE的界面上看到一个输入框或滑块时背后是RUE创建了一个对应的UI控件如InputField、Slider并将这个控件与一个FieldInfo对象绑定。当你修改UI控件时RUE会调用fieldInfo.SetValue(componentInstance, newValue)将新值写回目标对象。反之为了在值被其他代码改变时更新UIRUE可能需要定期轮询Polling或通过事件机制监听变化。为什么不用简单的public变量暴露直接使用反射意味着你无需为了调试而将每个需要观察的变量都设为public。你可以保持代码的封装性将大多数字段设为private或[SerializeField] privateRUE依然能够访问它们。这符合良好的编码实践。3.2 动态UI生成与布局RUE的另一个技术难点是动态生成一个与Unity Editor的Inspector面板类似的、结构复杂的UI。这通常通过Unity的UI系统UGUI动态创建实现。递归式布局UI的生成是一个递归过程。对于一个GameObject先创建其折叠标题栏。展开后为每个Component创建子标题。每个Component下再为每个字段/属性创建对应的UI行。字段的类型如果是基本类型int, float, string, bool则生成简单的输入框、滑块或复选框。复杂类型的处理如果字段类型是Vector3、Color、Enum枚举或某个自定义ClassRUE需要生成更复杂的UI组。例如Vector3需要三个浮点数输入框。对于自定义类可能需要展开一个新的折叠区域递归显示其内部的字段。对于UnityEngine.Object引用类型如拖拽一个材质球则需要生成一个对象选择器字段。性能考量动态生成成百上千个UI元素是昂贵的。优秀的RUE实现会采用对象池来复用UI元素并实现虚拟化列表只生成和渲染当前视口内的UI行对于大型场景或拥有大量组件的对象这是保证流畅度的关键。3.3 场景图Scene Graph与层次结构除了Inspector功能一个完整的RUE通常还包含一个类似Editor中Hierarchy的场景图。实现方式通过遍历SceneManager.GetActiveScene().GetRootGameObjects()获取所有根物体然后递归遍历每个根物体的transform子节点构建一个树形数据结构。交互功能在这个动态生成的树状UI中你可以点击选择物体通过UnityEngine.EventSystems模拟选择事件并可能高亮显示被选中的物体激活/禁用物体SetActive甚至动态创建新物体Instantiate或销毁物体Destroy。这需要RUE能够将UI操作映射回对场景对象的实际调用。3.4 命令执行与组件操作高级RUE还允许你直接执行C#代码片段或调用特定方法。C#交互式解释器集成一个像Roslyn或Mono.CSharp这样的轻量级C#编译器允许你在运行时输入一行或一段代码并立即执行。例如输入GameObject.Find(Player).GetComponentHealth().Heal(50);就能立刻给玩家回血。这功能极其强大但也会带来安全性和性能开销通常只在开发版本中启用。方法调用UI对于标记了特定属性如[ContextMenu]或自定义[RuntimeMethod]的公共方法RUE可以生成一个按钮点击即可调用该方法并传入参数。这为策划和测试提供了安全的、预定义的操作入口。4. 主流方案选型与集成实战市面上并没有Unity官方发布的“Runtime Unity Editor”但社区和第三方提供了多个优秀的选择。我将对比三个最主流的方案并详细讲解其中一种的集成步骤。4.1 方案对比社区版 vs. 资产商店版特性Runtime Unity Editor (GitHub社区版)Runtime Inspector Hierarchy (资产商店)自研实现核心来源GitHub开源项目由社区维护Unity Asset Store 上的付费插件完全自主开发成本免费一次性付费约几十美元人力成本高周期长功能完整性极高。包含完整的Inspector、Hierarchy、对象创建、组件操作、C# REPL交互等。高。专注于Inspector和Hierarchy的显示与修改功能纯粹稳定。完全自定义可按需裁剪UI美观度中等风格接近原生Unity旧版但功能强大优秀。通常有更现代、可定制化的UI皮肤。取决于UI设计投入集成复杂度中等偏高。需要处理依赖、编译指令并可能需自行解决一些版本兼容问题。低。通过Package Manager或直接导入通常开箱即用。最高需从零搭建维护与支持依赖社区更新可能滞后于Unity新版本由插件作者维护更新较及时有客服支持完全自主灵活但需持续投入适合场景追求极致功能、需要深度定制、预算有限的团队或个人开发者希望快速获得稳定、美观的运行时调试能力且愿意付费的团队有特殊安全需求、功能极其定制化的大型项目选型建议对于大多数中小型团队和个人开发者从资产商店购买一个成熟插件是性价比最高的选择。它节省了大量开发和调试时间稳定性有保障。如果你是一个喜欢钻研、项目有特殊需求或者纯粹想学习其实现原理那么研究并集成GitHub上的开源版本是非常有价值的经历。4.2 实战集成以GitHub开源版为例下面我将以集成最著名的开源项目RuntimeUnityEditor通常指ManlyMarco/RuntimeUnityEditor这一版本或其分支为例展示核心步骤和避坑点。步骤1获取与导入访问GitHub仓库下载最新Release的.unitypackage或克隆源码。在Unity项目中通过Assets - Import Package - Custom Package导入下载的包。如果克隆源码直接将RuntimeUnityEditor文件夹拖入项目的Assets目录下。步骤2基础配置与启动这个版本的RUE通常通过一个单例管理器来启动。你需要在游戏启动的早期例如在首个场景的初始化脚本中实例化它。using RuntimeUnityEditor.Core; // ... 在你的初始化代码中 void Start() { // 确保只在开发版本或特定条件下启用 #if DEVELOPMENT_BUILD || UNITY_EDITOR if (RuntimeUnityEditorCore.Instance null) { // 创建RUE实例它会自动将自己设为DontDestroyOnLoad var instance new GameObject(RuntimeUnityEditor); instance.AddComponentRuntimeUnityEditorCore(); // 你可以在这里进行一些初始配置比如设置初始窗口位置、大小 // RuntimeUnityEditorCore.Instance.InitSettings(...); } #endif }步骤3设置激活热键RUE默认通常有一个激活热键如F12。你需要在代码中检查这个输入或者提供一个UI按钮来切换RUE的显示/隐藏。void Update() { #if DEVELOPMENT_BUILD || UNITY_EDITOR if (Input.GetKeyDown(KeyCode.F12)) { var rueCore RuntimeUnityEditorCore.Instance; if (rueCore ! null) { // 切换主窗口的显示状态 rueCore.ToggleWindow(); } } #endif }步骤4处理依赖与编译错误开源项目可能依赖其他库如BepInEx一个Unity游戏模组框架或IllusionAPI。如果你不是制作模组可能需要移除或替换这些依赖。常见问题导入后出现大量编译错误提示找不到命名空间BepInEx。解决方案查看项目中的RuntimeUnityEditorCore.cs文件开头找到类似#if BEPINEX的编译指令。你可以尝试定义这个编译符号在Player Settings - Scripting Define Symbols中添加BEPINEX但更通用的方法是修改源码将这些条件编译块内依赖于BepInEx的代码注释掉或替换为Unity原生的实现如用UnityEngine.Debug.Log代替BepInEx的日志接口。这是一个需要耐心和一点点C#功底的过程。步骤5UI适配与移动端支持默认的RUE UI是为PC的鼠标键盘操作设计的。在移动设备上运行你需要触控支持确保RUE的UI Canvas使用了Graphic Raycaster并且EventSystem存在。可能需要调整按钮和输入框的大小使其更容易触摸。输入法问题在iOS和Android上当激活输入框时系统键盘会弹出可能会遮挡UI。需要考虑调整UI布局或监听输入框焦点事件来动态移动窗口。性能优化移动设备性能有限。要严格控制RUE窗口同时显示的项数考虑禁用一些重型功能如实时更新的性能图表、复杂的对象预览图。实操心得集成开源RUE最大的挑战是版本兼容性。某个版本的RUE可能只兼容Unity 2019.4而在Unity 2022.3上就会因API变化而报错。在集成前务必查看项目的README和Issues页面确认其支持的Unity版本。如果版本不匹配做好手动修改部分API调用的准备。5. 高级功能应用与性能调优成功集成RUE只是第一步如何高效、安全地利用其高级功能并确保其对项目性能的影响可控才是真正体现价值的环节。5.1 暴露自定义调试接口你不应该让策划或测试人员在海量的组件列表中寻找他们需要的变量。更好的做法是利用RUE的API主动创建自定义的调试面板。以开源RUE为例它可能提供了向指定窗口添加自定义标签页Tab或控件的能力。你需要查阅其文档或源码找到类似RegisterWindow或AddTab的接口。// 伪代码示意如何注册一个自定义调试窗口 void RegisterCustomDebugPanel() { var customWindow RuntimeUnityEditorCore.Instance.CreateNewWindow(游戏平衡调试); // 添加一个滑块控制玩家速度 customWindow.AddSlider(玩家移动速度, () Player.Instance.moveSpeed, // 获取当前值 (newVal) Player.Instance.moveSpeed newVal, // 设置新值 min: 1.0f, max: 20.0f); // 添加一个按钮触发某个功能 customWindow.AddButton(重置关卡, () GameManager.Instance.ReloadLevel()); // 添加一个文本显示只读信息 customWindow.AddLabel($当前分数: {ScoreManager.Instance.TotalScore}); }这样你就可以为不同模块战斗、经济、任务创建专属的调试面板将最常用的参数和操作集中展示极大提升调试效率。5.2 对象检索与过滤技巧当场景中有成千上万个物体时在Hierarchy中滚动查找无异于大海捞针。高效的RUE会提供搜索过滤功能。按名称搜索最基本的功能。输入“Enemy”可以找到所有名字包含该字符的物体。按组件类型过滤更强大的功能。例如过滤出所有带有Rigidbody组件的物体用于检查物理表现或过滤出所有带有Health脚本的物体用于批量调整生命值。使用标签Tag或层级Layer在你的游戏代码中规范地使用Tag和Layer。在RUE的过滤器中可以按Tag或Layer快速筛选对象组。例如筛选所有Tag为“Pickup”的物体检查其生成位置是否正确。5.3 性能影响分析与优化RUE在带来便利的同时也引入了额外的CPU和内存开销必须加以管理。CPU开销主要来自UI更新如果Inspector面板上绑定了大量频繁变化的变量如每帧更新的位置、速度RUE的UI也需要每帧去读取并刷新显示这会带来可观的性能消耗。对象遍历与反射每次打开Hierarchy或刷新对象列表都需要遍历场景中的所有对象并获取其组件信息反射操作本身比直接代码调用慢。优化策略按需刷新修改RUE的源码或配置将变量显示的刷新频率从每帧Update降低到每秒几次CoroutineWaitForSeconds。对于变化不频繁的变量甚至可以改为仅在值发生实际变化时刷新这需要更复杂的值监听机制。限制扫描范围提供选项让用户可以限制Hierarchy只显示特定层Layer或特定类型的对象减少不必要的遍历。禁用预览功能关闭材质预览、网格预览等重型UI元素的实时生成。使用编译指令严格隔离这是最重要的优化。确保所有RUE相关的代码和对象在非开发版本中完全不被编译和包含。#if !DEVELOPMENT_BUILD !UNITY_EDITOR // 在发布版本中这段代码根本不存在 public class RuntimeDebugHelper { } // 一个空类 #else // 在开发版本中这是完整的RUE集成类 public class RuntimeDebugHelper { private RuntimeUnityEditorCore _rue; // ... 完整的初始化和管理代码 } #endif在Player Settings的Scripting Define Symbols中为开发包添加DEVELOPMENT_BUILD符号而在发布版本中不添加。这样发布出去的包体积更小且没有任何调试代码残留杜绝了安全风险。6. 常见问题排查与安全实践即使成功集成在实际使用中你仍会遇到各种问题。以下是一些典型问题的排查思路和必须遵守的安全准则。6.1 集成与运行常见问题问题现象可能原因排查与解决步骤导入后编译错误1. 缺少依赖库 (如BepInEx)。2. Unity API版本不兼容。3. 代码语法错误。1. 检查错误信息确认缺失的命名空间或类。2. 对比RUE项目声明的Unity版本与你当前使用的版本。修改过时的API调用如FindObjectsOfType改为FindObjectsByType。3. 检查是否有明显的代码错误可能是下载的包不完整。运行时按热键无反应1. 编译指令未生效RUE代码未编译。2. 初始化代码未执行或执行顺序有误。3. 热键被其他输入系统如新Input System拦截。1. 确认DEVELOPMENT_BUILD或UNITY_EDITOR编译符号已正确定义。2. 在初始化代码处加日志确认其被执行。确保初始化在场景加载早期完成。3. 尝试更换一个不常用的热键如BackQuote即键或检查新Input System的Action Map是否覆盖了该按键。RUE窗口显示但内容为空或无法操作1. EventSystem缺失或被禁用。2. UI Canvas的渲染模式或层设置有问题。3. 对象遍历逻辑出错未找到任何物体。1. 在场景中检查是否存在EventSystem游戏对象。2. 检查RUE使用的Canvas其Render Mode应为Screen Space - Overlay或Screen Space - Camera并正确赋值。确保其Sorting Order较高。3. 查看RUE的日志输出如果有确认其初始化过程是否报错。修改数值后游戏行为异常或崩溃1. 修改了不应在运行时修改的静态变量或配置资产。2. 线程安全问题在非主线程修改了Unity对象。3. 值类型不匹配或超出范围。1.谨慎修改。避免修改ScriptableObject资产、静态类成员这可能导致不可预知的状态污染。2. 确保所有通过RUE的修改都在主线程进行。如果RUE在异步回调中修改变量需用MainThreadDispatcher派发到主线程。3. RUE应做好输入验证例如为数值字段提供合理的范围限制。在移动设备上UI错位或无法点击1. UI未适配不同屏幕分辨率和宽高比。2. 触控输入未正确处理。3. 系统键盘弹出导致布局挤压。1. 使用Unity的Canvas Scaler组件设置为Scale With Screen Size。2. 确保RUE的按钮等交互元素有足够的触控区域并检查Graphic Raycaster。3. 监听TouchScreenKeyboard的打开事件动态调整RUE窗口的位置。6.2 安全开发准则将如此强大的工具集成到游戏中安全是重中之重。一旦泄露给终端用户后果可能是灾难性的。编译指令是生命线重申一遍必须使用#if DEVELOPMENT_BUILD等编译指令将RUE的核心代码包裹起来。发布正式版本时确保构建设置中移除了开发编译符号。你可以创建一个独立的“开发”构建配置自动包含这些符号。启动参数二次验证即使编译进去了也可以通过启动参数来控制。在游戏启动的入口处检查命令行参数或一个特定的配置文件。void Awake() { bool enableDebugTools false; #if DEVELOPMENT_BUILD // 检查是否有启动参数例如 -enableDebug string[] args System.Environment.GetCommandLineArgs(); enableDebugTools args.Contains(-enableDebug); // 或者检查一个只有内部人员知道的配置文件 #endif if (enableDebugTools) { InitRuntimeEditor(); } }功能分级与权限控制不是所有调试功能都对所有人开放。可以为RUE设计一个简单的权限系统。例如通过密码或服务器验证来解锁“执行代码”、“修改资产”等危险功能而只读查看对象树等基础功能可以默认开放给测试人员。网络传输加密如果使用远程调试功能RUE作为服务器外部工具连接所有通信数据必须加密如使用WebSocket over TLS防止中间人攻击窃取或篡改游戏内存数据。彻底移除残留字符串使用反编译工具如ILSpy检查你的发布包确保没有留下任何与RUE相关的类名、方法名、字符串常量如菜单名、日志信息这些都可能成为黑客寻找入口的线索。7. 超越调试RUE在完整工作流中的角色RUE的价值远不止于“调试”。当它被深度整合到团队的工作流中时能催化出更高效的开发模式。与自动化测试结合你可以编写一个测试脚本在游戏运行时通过RUE提供的API如果支持或模拟UI操作来设置特定的游戏状态如将玩家血量设为1将Boss召唤到身边然后触发自动化测试用例。这使得创建复杂的集成测试场景变得更容易。作为游戏内控制台Cheat Console的基础许多单机游戏都有内置的控制台输入“godmode”开启无敌“addgold 1000”增加金币。RUE的C# REPL功能本身就是一个超级控制台。你可以基于它封装一些更安全的、预定义的命令提供给玩家在单机模式下游玩或作为开发者的后门命令。辅助内容生产与验证对于开放世界或内容密集型游戏策划和关卡设计师可以利用RUE在运行的游戏版本中微调NPC的巡逻路径点、动态物体的生成概率、环境音效的触发范围等。他们可以在真实的游戏环境中进行“所见即所得”的编辑然后将调整后的参数导出为配置文件再由程序导入到正式的资源管理中。这比在Excel表里改数字然后打包测试要直观和高效得多。在我参与的一个大型项目中我们将RUE与一个自定义的“场景快照”系统结合。测试人员发现一个Bug时可以一键保存当前游戏世界的完整状态所有物体的位置、属性、组件数据到文件。开发者拿到这个文件后可以在编辑器或开发版本中直接加载这个快照精确复现Bug现场省去了大量描述和复现操作的时间。这个系统的底层就依赖了RUE强大的对象序列化与反射能力。最终Runtime Unity Editor代表的是一种理念将调试和修改的能力从编辑器的“上帝视角”下放到运行时的“参与者视角”。它模糊了开发、测试和设计之间的界限让整个团队都能以一种更直接、更互动的方式参与到游戏的塑造过程中。虽然它的集成需要一些功夫对性能和安全性的考量也必须贯穿始终但对于任何追求迭代速度和质量的中大型Unity项目来说投资这样一套实时调试体系所带来的长期收益无疑是巨大的。它让解决问题从一种被动的、延迟的响应变成了一种主动的、即时的探索。