首页/资讯中心/详情

UE5蓝图驱动动态材质系统：从原理到实战优化指南

UE5蓝图驱动动态材质系统：从原理到实战优化指南
📅 发布时间：2026/7/9 22:42:21

1. 项目概述：为什么我们需要一个蓝图驱动的动态材质系统？

在Unreal Engine 5的项目开发中，尤其是涉及到需要实时交互、环境变化或角色状态反馈的场景，材质系统往往不能是静态的。想象一下，一个角色的盔甲需要根据生命值从崭新变为破损，或者一片森林的植被需要随着季节从翠绿过渡到枯黄。如果为每一种状态都制作一个独立的材质实例，不仅资产管理工作量会爆炸，运行时内存占用也会成为噩梦。这时，一个由蓝图灵活控制的动态材质系统就成了必需品。

这个系统的核心目标，就是通过蓝图这一可视化脚本工具，将材质的各种属性（如颜色、纹理、数值参数）暴露出来，并允许游戏逻辑在运行时动态地修改它们。它解决的不仅仅是“能不能变”的问题，更是“如何高效、可控、高性能地变”的问题。无论是独立开发者还是团队协作，掌握这套方法都能让你从繁琐的静态材质切换中解放出来，专注于创造更生动、更具响应性的游戏世界。接下来，我将结合一个从零搭建的实战案例，拆解其设计思路、实现细节，并分享那些在官方文档里不会写的性能优化“黑话”和避坑指南。

2. 系统核心架构与蓝图设计思路拆解

2.1 动态材质系统的两种核心模式：实例化与动态参数

在UE5中，实现材质动态化主要有两种路径，理解它们的区别是设计系统的第一步。

第一种是“材质实例动态化”。我们首先创建一个父材质，将需要动态控制的属性（例如一个标量参数Roughness，一个向量参数BaseColor）暴露为参数。然后，在蓝图中，我们可以通过Create Dynamic Material Instance节点，基于某个静态网格体组件上原有的材质，创建一个动态材质实例（Dynamic Material Instance）。这个实例独立于原始材质，我们可以随时通过Set Scalar/Vector Parameter Value等节点修改其参数。这种模式的优势在于，它修改的是附加在特定网格体组件上的一个具体实例，不影响其他使用相同材质的物体，非常灵活。

第二种是“材质参数集合驱动”。这是处理全局或批量对象变化的大杀器。我们创建一个Material Parameter Collection资源，在里面定义全局参数（如GlobalTime,WindDirection）。然后，在材质蓝图中，我们可以直接引用这个集合中的参数。在游戏运行时，通过蓝图修改这个Material Parameter Collection资源中的参数值，所有引用了该参数的材质都会实时更新。这特别适合管理全局环境变量，比如昼夜循环的整体亮度、全局的风力强度等。

在实际项目中，我通常会混合使用这两种模式。对于角色专属的、个性化的变化（如血量护盾光效、武器充能状态），使用动态材质实例。对于场景级别的、影响大量对象的变化（如全场景的湿润度、雾气浓度），则使用材质参数集合。这样的架构清晰，且性能可控。

2.2 蓝图交互层的模块化设计

蓝图不仅仅是调用几个设置参数的节点那么简单。一个健壮的系统需要良好的架构设计。我建议将材质控制逻辑封装成独立的蓝图函数库或组件。

例如，可以创建一个名为MaterialController的蓝图函数库。在里面封装诸如Apply Damage Effect (Target Mesh, Hit Location, Intensity)、Fade Object In/Out (Target Mesh, Duration)这样的函数。这样，在角色蓝图、武器蓝图或任何交互逻辑蓝图中，你只需要调用这些封装好的函数，而不必每次都重新编写创建动态实例、设置参数、管理生命周期的重复代码。

更进一步，可以为需要复杂材质交互的物体（如一个可破坏的油桶）创建一个MaterialInteractionComponent。该组件在初始化时自动创建所需的动态材质实例，并暴露一些简单的变量（如Health,Burning）给父蓝图。组件内部监听这些变量的变化，并自动驱动材质参数的改变。这种组件化的思想极大地提升了代码的复用性和可维护性。

3. 核心细节解析与关键节点实操要点

3.1 材质蓝图中的参数定义与暴露技巧

在材质编辑器中定义参数是第一步，但如何定义大有讲究。

标量参数常用于控制强度、程度、状态进度。比如Metallic、Specular、Opacity、DamageAmount。命名时务必清晰，如Damage_Progress比简单的Param1要好一万倍。一个高级技巧是使用“参数默认值”和“滑块范围”。例如，将Burn_Amount的默认值设为0，滑块范围设为0到1。这样不仅在材质编辑器中调试方便，在蓝图中设置时也能对有效范围心中有数。

向量参数主要用于颜色和方向。对于颜色，直接使用RGB通道。但有时也可以“一参多用”，比如用向量的R通道存储腐蚀强度，G通道存储污渍强度，B通道存储湿润度，A通道保留备用。这能减少参数总数，对性能优化有帮助（后续会详谈）。对于纹理坐标变换（平移、旋转、缩放），我强烈建议使用TextureCoordinate节点配合Panner、Rotator、TexCoord Scale节点，并将它们的输入转换为参数，而不是直接操作UV。这样逻辑更清晰，蓝图控制也更直观。

纹理参数允许动态切换纹理。这里有一个关键点：在材质中引用纹理参数时，记得连接其RGB和Alpha输出，而不仅仅是RGB。否则，如果换上一张带透明通道的纹理，透明信息会丢失。另一个注意事项是纹理尺寸。动态切换的纹理应尽量保持尺寸一致（如都是1024x1024），避免因纹理流送造成的性能波动或视觉瑕疵。

3.2 蓝图中创建与控制动态材质实例的完整流程

在蓝图中操作动态材质，正确的流程和节点选择至关重要。

创建时机：通常是在BeginPlay事件或组件的OnRegister事件中创建动态材质实例。避免在每帧（Tick）中创建，这是严重的性能浪费。对于可能频繁显示/隐藏的物体（如可拾取物品），可以在首次显示时创建并缓存，隐藏时保留实例，再次显示时复用，而不是销毁再创建。

核心节点链：

  1. 获取目标网格体：使用Get Component by Class或直接引用StaticMeshComponent。
  2. 创建动态实例：使用Create Dynamic Material Instance节点。其输入Element Index指的是材质槽位索引（通常为0）。输出是一个Dynamic Material Instance对象，必须将其存储在一个变量中（如My_DMI），否则后续无法控制。
  3. 设置参数：使用Set Scalar Parameter Value on Material Instance或Set Vector Parameter Value节点。Parameter Name必须与材质中定义的参数名完全一致，包括大小写。这里最容易出错，建议将参数名复制粘贴，而不是手动输入。
  4. 应用至网格体：创建实例后，通常会自动应用到网格体。但如果你需要将同一个实例应用到多个网格体或多个材质槽位，可以使用Set Material节点，并将动态实例对象传入。

注意：Create Dynamic Material Instance会返回一个新的材质实例对象。如果你需要修改一个已经存在的动态实例的参数，直接使用Set Scalar/Vector Parameter Value节点，并传入之前保存的My_DMI变量即可，无需再次创建。

3.3 材质参数集合的全局管理与同步

对于材质参数集合，操作更为集中。

首先在内容浏览器中创建Material Parameter Collection，比如命名为MPC_GlobalEnvironment。打开后，添加两个标量参数：TimeOfDay(0-1代表0点到24点) 和RainIntensity(0-1)。

在材质蓝图中，使用Collection Parameter节点，选择你创建的集合和对应的参数名，就能获取其值，并连接到你的材质逻辑中。

在蓝图中，你需要获取这个集合资源的引用。可以在关卡蓝图的BeginPlay中，使用Get Collection Parameter节点（注意，这个节点是用于获取参数值），但更常见的做法是，先将Material Parameter Collection资源拖拽到蓝图图表中，生成一个对象引用。然后，使用Set Scalar Parameter Value节点（这个节点是针对集合的），选择该集合引用和参数名，即可修改全局值。

同步技巧：对于多人游戏或需要严格同步的场景，修改材质参数集合的逻辑应该放在服务器端，然后通过RPC（远程过程调用）同步到所有客户端。避免每个客户端独立计算环境参数导致的不同步。

4. 实战：构建一个角色受击与状态反馈系统

让我们通过一个具体案例，将上述理论串联起来：实现一个角色，在受击时受伤部位闪烁红光，随着生命值降低，全身材质逐渐变得破损和暗淡。

4.1 材质端准备：创建父材质与参数定义

  1. 创建父材质M_Character_Base。使用Default Lit着色模型。
  2. 暴露参数：
    • Scalar：Health(默认1.0，范围0-1)，用于控制整体破损度和颜色饱和度。
    • Scalar：HitFlash_Intensity(默认0.0，范围0-1)，用于控制受击闪烁的强度。
    • Vector：HitFlash_Color(默认红色)，用于控制闪烁颜色。
    • TextureSample：DamageMask，一张灰度贴图，白色区域代表易破损部位。
  3. 材质逻辑搭建：
    • 基础颜色：将Base Color纹理采样与Health参数相乘，模拟生命值降低时颜色变灰。Health越低，乘法结果越暗。
    • 粗糙度：使用Lerp节点，在原始粗糙度和一个较高值（如0.8）之间混合，混合因子由(1 - Health)控制，让角色看起来更陈旧。
    • 受击效果：使用HitFlash_Intensity驱动一个Fresnel或Pixel Depth效果，模拟边缘发光。将HitFlash_Color乘以强度参数，然后通过Add节点叠加到最终的自发光通道上。为了效果更佳，可以连接一个Sine或Cosine节点乘以时间到强度上，实现脉冲闪烁效果，但注意这个时间计算最好放在蓝图中驱动，而非材质内每帧计算（性能考量）。
    • 蒙版破损：使用DamageMask纹理采样，将其R通道与(1 - Health)相乘，结果用于控制一个“破损”材质层的混合权重。这个破损层可以使用额外的法线贴图和粗糙度贴图来模拟刮痕。

4.2 蓝图端实现：角色蓝图中的动态控制逻辑

  1. 角色蓝图事件图表：
    • 在Event BeginPlay中，获取角色的网格体组件（如Mesh），对其主材质槽位（0）执行Create Dynamic Material Instance。将返回的动态实例保存到变量Char_DMI中。
    • 设置初始参数：Set Scalar Parameter Value (Char_DMI, ‘Health’, 1.0)。
  2. 受击事件处理：
    • 假设有一个自定义事件OnTakeDamage。
    • 首先，更新Health变量（例如减去伤害值）。
    • 调用Set Scalar Parameter Value (Char_DMI, ‘Health’, UpdatedHealth)。
    • 然后，触发闪烁效果：设置HitFlash_Intensity为1.0。接着，启动一个时间轴或自定义延时循环，在0.2秒内，将HitFlash_Intensity从1.0线性插值回0.0。这比单纯设置一个值然后等待再重置要平滑得多。
  3. 局部受击反馈（进阶）：
    • 如果希望打击点局部闪烁，上述方法就不够了。我们需要用到Hit Result提供的Bone Name或Physics Material。
    • 更高级的做法是：在角色材质中，使用世界位置或骨骼权重信息。在蓝图中，当受击时，将击中点的世界位置（来自Hit Result）通过一个向量参数Hit_Location传递给材质。在材质中，计算像素世界位置与Hit_Location的距离，距离越近，HitFlash_Intensity越高。这能实现精确的局部高亮效果，但对材质复杂度和性能有更高要求。

4.3 性能优化关键：实例管理与参数更新策略

动态材质虽好，但滥用会严重拖累性能。以下是核心优化守则：

1. 实例数量最小化：绝对不要为场景中每一个静态物体都创建动态材质实例。对于大量重复的静态物体（如草地、石子），应使用材质参数集合或静态的材质实例变体。动态实例只留给真正需要独立、实时交互的少数对象（如主角、关键NPC、可交互物品）。

2. 更新频率与批处理：避免在Tick事件中连续调用Set Parameter节点。即使值没有变化，这个调用本身也有开销。正确的做法是： *条件更新：只在参数值实际发生改变时才调用设置节点。 *事件驱动：用事件（如生命值变化、状态切换）来驱动更新，而非每帧查询。 *批量更新：如果需要同时设置多个参数，尽量在一次蓝图执行链中完成所有Set Parameter调用，而不是分散在不同帧或事件中。

3. 材质复杂度与指令数：动态材质本身的复杂度是根本。在材质编辑器中，按下Ctrl+Shift+.可以预览材质指令数。指令数越高，GPU负担越重。优化技巧包括： * 减少不必要的纹理采样，特别是高分辨率纹理。 * 简化数学运算，用Lerp代替复杂的If分支。 * 谨慎使用Custom Node和复杂的函数。 * 利用材质属性中的Shading Model和Blend Mode，有时比用网络模拟效果更高效。

4. 移动端特别注意事项：在移动平台上，动态材质实例的开销更大。 * 尽可能使用材质参数集合代替大量的独立动态实例。 * 限制同时活动的、需要每帧更新的动态材质数量。 * 简化移动端专用材质的网络，关闭不必要的特性（如复杂法线、高光反射）。 * 使用Mobile着色质量等级进行预览和测试。

5. 常见问题排查与高级调试技巧

即使按照最佳实践操作，动态材质系统也难免遇到问题。这里记录几个我踩过的坑和解决方法。

5.1 参数设置无效的排查流程

这是最常见的问题：蓝图里调了Set Parameter，但屏幕上没反应。

  1. 检查参数名：99%的问题源于此。确保蓝图节点中的Parameter Name字符串与材质中定义的参数名一字不差，包括大小写和空格。最稳妥的方法是，在材质编辑器中右键点击参数节点，选择“复制参数名”，然后粘贴到蓝图中。
  2. 确认动态实例引用：你是否成功创建了动态实例并保存到了变量中？后续修改参数时，是否使用的是同一个变量？可以在设置参数后，添加一个Print String节点，打印出动态实例的名称或参数值，确认逻辑已执行。
  3. 检查材质槽位：Create Dynamic Material Instance节点的Element Index是否正确？通常0是第一个材质槽位。如果你的网格体有多个材质，需要确认修改的是哪一个。
  4. 材质自身逻辑：在材质编辑器中，手动滑动参数的默认值滑块，看效果是否正常。如果材质内部逻辑有误，蓝图怎么调也没用。可以临时将参数直接连接到一个纯色输出，测试通道是否畅通。
  5. 蓝图执行顺序：确保创建动态实例和设置参数的逻辑在材质被应用到网格体之后执行。通常放在BeginPlay中是安全的。

5.2 性能瓶颈分析与优化工具使用

当游戏出现卡顿，怀疑是动态材质导致时，可以使用UE5内置的工具进行诊断。

  1. Stat GPU 和 Stat Unit：在游戏运行时按~键打开控制台，输入stat gpu和stat unit。观察Game、Draw、GPU的时间。如果GPU时间异常高，可能是材质过于复杂。
  2. 材质复杂度视图：在编辑器视口中，选择优化视图模式->着色器复杂度或材质纹理密度。动态材质实例覆盖的区域会以特定颜色显示（红色代表高复杂度/高开销）。这是定位“性能热点”区域的直观方法。
  3. ProfileGPU：这是一个更强大的工具。在编辑器中运行游戏，然后点击窗口->开发者工具->GPU Visualizer。捕获一帧进行分析，可以看到每个绘制调用的耗时，精确找到是哪个网格体、哪个材质的哪个Pass消耗了大量时间。
  4. 动态实例计数：可以通过控制台命令DumpDynamicMaterialInstances来输出当前所有动态材质实例的信息，帮助判断是否创建了过多实例。

5.3 高级技巧：蓝图与材质函数的协同

对于更复杂的动态效果，可以结合材质函数来提升效率和可维护性。

例如，将上述角色受击闪烁的完整网络（Fresnel计算、颜色混合、时间脉冲）打包成一个材质函数，命名为MF_HitFlash。该函数输入HitIntensity、FlashColor、WorldPosition等，输出最终的自发光颜色增量。

在父材质M_Character_Base中，只需调用这个函数，传入对应的参数即可。这样，材质图变得非常简洁。

更重要的是，在蓝图中，如果你需要修改闪烁的算法（比如从Fresnel改为基于深度的边缘光），你只需要更新MF_HitFlash这个函数，所有使用了该函数的材质都会自动更新，无需逐个修改父材质。这对于维护大型项目的材质一致性至关重要。

另一个技巧是使用蓝图动态控制材质函数的输入。虽然不能直接动态切换材质函数本身，但可以通过蓝图控制传入函数的参数，间接实现复杂的动态逻辑组合。这要求在设计材质函数时，就预留好足够灵活的输入接口。

6. 移动端与复杂场景下的专项优化策略

当项目需要部署到移动设备，或者场景中存在成百上千个需要动态交互的物体时，通用优化手段可能还不够，需要一些更激进的策略。

6.1 针对移动端的材质简化与LOD策略

移动平台的GPU和带宽资源非常有限，必须做减法。

材质简化：

  • 降低纹理尺寸：将1024x1024的纹理降级为512x512甚至256x256。使用UE5的纹理流送和Mipmap功能，但基础尺寸要小。
  • 禁用昂贵特性：在移动端材质中，关闭或简化Clear Coat、Subsurface Scattering、Anisotropy等高级着色模型。使用Default Lit或Unlit即可。
  • 减少数学运算：用查表（Texture Lookup）代替复杂的实时计算。例如，将角色破损度从0到1的渐变颜色，预先烘焙到一张1x256的渐变纹理中，材质中只需一次纹理采样，而不是动态的Lerp多个颜色节点。
  • 合并纹理通道：将金属度、粗糙度、环境光遮蔽（AO）打包到一张纹理的RGB三个通道中（即ORM贴图），减少纹理采样次数。

基于距离的LOD（细节层次）： 不仅网格体有LOD，材质也应有LOD。为动态材质创建两个版本：一个高清版（M_Character_HD）用于PC和主机，一个移动简化版（M_Character_Mobile）。在蓝图中，可以根据平台或距离动态切换材质实例所基于的父材质（这需要更复杂的管理逻辑）。更简单的方法是，在同一个材质中使用Quality Switch节点，根据着色质量等级自动选择不同的计算分支。

6.2 大规模动态物体的批处理与实例化渲染优化

对于大量相同物体（如一片随风摇摆的草，或一堆颜色可变的宝石），为每一个创建动态材质实例是不可接受的。此时应寻求批处理优化。

方法一：使用材质参数集合与顶点着色器。 如果动态变化是统一的（比如所有草都受同一阵风影响），将风力参数放在材质参数集合中。在草的材质里，利用世界位置偏移（World Position Offset）和顶点着色器，根据全局风力参数计算摆动。这样，成千上万的草可以合并到更少的绘制调用中，因为它们的材质实例（实际上是静态的）是相同的，只是引用了变化的全局参数。

方法二：使用实例化静态网格体与每实例数据。 对于需要独立变化的大量物体（比如一堆颜色各异的宝石），可以使用Instanced Static Mesh Component。你可以为每个实例定义自定义数据（通过Set Custom Data Value），这些数据会作为浮点数数组传递给着色器。在材质中，使用PerInstanceCustomData节点来读取这些值，并用于控制颜色等属性。这比为每个宝石创建独立的动态材质实例要高效得多，因为它仍然是一个绘制调用。

方法三：在蓝图中进行“分帧更新”。 如果确实有上百个对象需要每帧或频繁更新其动态材质参数，不要在同一帧更新所有对象。可以创建一个管理器，将这些对象放入一个数组，每帧只更新其中的几个（例如，每帧更新10个）。这样可以将性能开销均匀地分摊到多帧中，避免单帧卡顿。虽然每个对象的更新会有轻微延迟，但对于非核心的视觉效果（如远处树叶的飘动）通常是可接受的。

6.3 材质编译与烘焙的注意事项

动态材质参数在游戏运行时修改，但材质本身的着色器需要在打包前或运行时编译。这可能导致两个问题：

1. 运行时编译卡顿：如果材质非常复杂，且使用了之前未编译过的参数组合，可能会在游戏运行时触发着色器编译，导致瞬间卡顿。解决方法是在项目设置中，启用异步着色器编译，并尽可能在加载界面或非关键时段预编译可能用到的材质变体。也可以使用r.ShaderPipelineCache.Enabled 1控制台命令来启用管道缓存，加速后续编译。

2. 光照烘焙失效：动态材质参数的变化通常不会影响静态光照烘焙（Lightmass）。因为光照贴图是在编辑器阶段预先计算好的。如果你的动态材质会显著改变表面的颜色或自发光，而这些表面又参与了静态光照，那么烘焙的光照效果将不会随之改变，导致光影错乱。对于受动态材质影响的重要静态物体，考虑将其设置为可移动或静态但使用动态间接光照（Lumen），或者将受影响的区域改为使用动态光照。

7. 从蓝图到C++：追求极致性能的可选路径

对于追求极致性能的核心系统，或者需要在多个蓝图中复用复杂逻辑时，将动态材质控制的核心部分迁移到C++中是值得考虑的。这并非必须，但能带来显著优势：执行速度更快、类型安全、便于重构和团队协作。

7.1 为何以及何时考虑C++实现

  • 性能敏感循环：如果你需要在每帧为大量对象更新材质参数（例如，基于距离的淡入淡出），C++循环的效率远高于蓝图。
  • 复杂算法：参数的计算逻辑如果涉及复杂的数学运算、数据结构遍历，在C++中实现会更清晰、更高效。
  • 代码复用与架构：将材质控制功能封装成C++的ActorComponent或函数库，可以被所有蓝图项目干净地调用，有利于构建更稳定的游戏框架。
  • 网络同步：在多人游戏中，C++处理RPC和状态同步通常更直接、错误更少。

7.2 一个简单的C++动态材质控制函数示例

假设我们在C++中创建一个辅助函数，用于安全地设置网格体组件上动态材质实例的标量参数。

// 在某个头文件（如MaterialHelper.h）中声明 #pragma once #include "CoreMinimal.h" #include "Kismet/BlueprintFunctionLibrary.h" #include "MaterialHelper.generated.h" UCLASS() class YOURPROJECT_API UMaterialHelper : public UBlueprintFunctionLibrary { GENERATED_BODY() public: // 设置动态材质实例的标量参数 UFUNCTION(BlueprintCallable, Category = "Material", meta = (DisplayName = "Set Material Scalar Parameter")) static bool SetMaterialScalarParameter(UMeshComponent* MeshComp, int32 MaterialIndex, FName ParameterName, float Value); }; // 在对应的cpp文件（MaterialHelper.cpp）中实现 #include "MaterialHelper.h" #include "Components/MeshComponent.h" bool UMaterialHelper::SetMaterialScalarParameter(UMeshComponent* MeshComp, int32 MaterialIndex, FName ParameterName, float Value) { if (!MeshComp || MaterialIndex < 0 || MaterialIndex >= MeshComp->GetNumMaterials()) { return false; // 输入检查 } UMaterialInstanceDynamic* DynMaterial = Cast<UMaterialInstanceDynamic>(MeshComp->GetMaterial(MaterialIndex)); if (!DynMaterial) { // 如果当前不是动态实例，尝试创建一个 UMaterialInterface* ParentMaterial = MeshComp->GetMaterial(MaterialIndex); if (ParentMaterial) { DynMaterial = UMaterialInstanceDynamic::Create(ParentMaterial, nullptr); if (DynMaterial) { MeshComp->SetMaterial(MaterialIndex, DynMaterial); } } } if (DynMaterial) { DynMaterial->SetScalarParameterValue(ParameterName, Value); return true; } return false; }

这个函数首先检查输入有效性，然后尝试获取已有的动态实例。如果获取不到（说明材质还不是动态的），它会基于当前的父材质创建一个新的动态实例并应用。最后，设置参数值。在蓝图中，你现在可以像调用普通节点一样调用这个自定义函数，它更健壮，并且将创建和设置逻辑封装在了一起。

7.3 在C++中管理材质参数集合

对于材质参数集合，C++操作同样直接：

// 假设你已经有一个 UMaterialParameterCollection* 类型的变量 MyMPCRef if (MyMPCRef) { // 设置标量参数 MyMPCRef->SetScalarParameterValue(FName("TimeOfDay"), NewTimeValue); // 设置向量参数 MyMPCRef->SetVectorParameterValue(FName("FogColor"), NewFogColor); }

将这类操作封装在游戏状态（GameState）或游戏模式（GameMode）的C++类中，可以方便地进行权威的全局管理。

将核心逻辑移至C++后，蓝图层就变得非常轻薄，主要负责触发事件和传递数据。例如，角色受击时，蓝图只需调用C++函数ApplyDamageEffect(HitLocation, DamageAmount)，具体的伤害计算、材质参数变化逻辑都在C++中完成。这种架构不仅性能更好，也使得游戏逻辑更集中，更易于调试和维护。对于中小型项目，纯蓝图可能足够；但对于大型、性能要求高的项目，这种混合模式是更专业的选择。