企业官网建设流程全解析

剧本杀App里最考验客户端开发功底的地方，往往不是剧本详情页，也不是地图搜店，而是那个看起来不起眼的组队消息列表。

原因很简单：组队消息是一个高频交互的实时入口，玩家在这里完成“看到有人组队—快速判断—一键加入”的全链路。消息稍微慢一秒、按钮稍微错一位，车队就满员了，用户就流失了。所以当我们团队开始做鸿蒙端跨平台适配时，第一个决定就是把组队消息连同它的快捷操作能力，从业务页面里彻底抽出来，做成一个独立组件。

这篇文章把我完成的一个“React Native鸿蒙跨平台剧本杀组队消息与快捷入口组件”从设计到落地的全过程写清楚，包括消息列表展示、快捷入口管理、快捷操作触发、消息详情预览这四大核心功能怎么拆、怎么实现、哪里容易踩坑。如果你也在做跨平台IM类列表、或者需要在一个组件里同时承载“展示+操作+跳转”多重职责，这篇应该对你有用。

1. 组队消息为什么值得单独做一个组件：来自业务侧的真实的痛点

1.1 组队场景不是普通IM，它是“限时+限次”的强操作消息

我最早接到这个需求时，产品给的原话是：“新版组队页的体验太差了，玩家从看到消息到进车队平均要跳四五个页面，车队满了都不知道。”我一开始还不信，自己用测试账号跑了一遍完整流程，才意识到问题有多严重。

常规IM消息（比如好友说说、系统通知）是“看完即止”的，用户不需要在消息列表里做决策。但剧本杀组队消息完全不是这样：玩家看到一个“某房主发起硬核本，差2人”的消息时，他必须在极短时间内决定“要不要加入”，然后立刻执行操作。如果消息列表只能“看”不能“做”，用户就要退出列表、去车队大厅、搜索房间、再申请加入，等这一套操作走完，车队已经满员了。

组队消息本质上是“限时+限次”的强操作消息。所谓限时，是指车主或房主通常只会等待几分钟，超时车队就散了；所谓限次，是指每个剧本杀车队都有明确的人数上限，先到先得，后到的只能被拒。

这就决定了消息列表不能只是一个展示型列表，它必须同时具备：

• 消息的聚合展示（谁、什么剧本、什么时间、几人车队）
• 就地操作的能力（加入、拒绝、查看详情）
• 快捷跳转的能力（一键进房间、一键查看车队状态）

这三个能力如果散落在不同的页面和模块里，用户心智负担极重。我们做过一个简单的埋点统计，发现老版本里从消息点击到成功进入车队，平均需要8到14秒，而车队满员的平均时间只有3分钟左右。这组数据直接说服了所有人：必须做一个承载“展示+操作+跳转”的组件。

1.2 组件要解决的四个核心问题，其实就是用户的四个瞬间

我在设计组件时，把用户行为拆成了四个“瞬间”，每一个瞬间对应一个核心功能。这个拆法帮我把模糊的需求变成了可落地的模块边界。

用户拿起手机看到通知栏有一条组队消息时的第一个瞬间，是“这是什么”。对应的是消息列表展示功能，需要把消息的要素（头像、昵称、剧本、人数、时间）一目了然地铺开。

第二个瞬间是“我要不要马上处理”。对应的是快捷入口管理，也就是说用户不能只在一类消息里打转，他要能在组队消息、好友请求、系统通知、车队动态之间快速切换入口，甚至能自定义入口顺序，把最关心的分类放在最顺手的位置。

第三个瞬间是“既然要处理，那就别让我再打开一个页面”。对应的是快捷操作触发，在消息项上直接放“加入”“拒绝”“查看详情”按钮，让用户一步到位。

第四个瞬间是“在不打扰我的前提下，让我看清楚到底怎么回事”。对应的是消息详情预览，在不跳转完整页面的情况下，通过弹层或卡片预览剧本信息、车队构成、剩余时间，让用户做出更准确的决策。

这四个功能不是并列关系，而是递进关系：列表负责触达，入口负责分流，操作负责转化，预览负责决策支撑。想明白这一层之后，组件的技术边界和数据结构也就清晰了。

2. 技术选型和组件架构：鸿蒙跨平台背景下为什么选 React Native

2.1 跨平台方案对比：RN 在这个场景里的优势不是性能，而是“动态性”

团队在立项时对技术栈有过一轮认真讨论。我们的现有业务有一部分是原生开发的，另一部分是 React Native 的，而鸿蒙作为新平台必须被覆盖。当时的候选方案主要有三个。

第一个方案是三端原生各写一套（Android、iOS、鸿蒙）。这个方案性能最好，但我们的排期不允许，组队消息组件涉及的页面逻辑、状态同步、埋点上报都要重写，至少多花两倍时间。

第二个方案是 Flutter。Flutter 在 UI 一致性上确实好，但问题在于我们团队现有的大量业务代码是 TypeScript/React 生态，迁移成本高，而且 Flutter 在鸿蒙端的第三方插件成熟度在当时还比不上 RN。

第三个方案就是 React Native 加上鸿蒙适配层。我们团队当时选择 RN，最核心的考量不是它的性能（RN 的性能在长列表场景下确实需要调优），而是它的动态性和生态：JavaScript 逻辑可以热更新、业务同学可以用熟悉的 React 技术栈、社区里有很多现成的列表和交互组件可以借鉴。

RN 在鸿蒙端的表现，我后面细讲。这里先说结论：如果你的场景是“多端复用 + 业务迭代快 + 团队已经具备前端技术储备”，RN 是性价比很高的选择。但如果你做的是极度依赖原生手势或高性能渲染的组件，要慎重。

2.2 组件目录结构与数据流设计：让四大功能各司其职

组件没有采用单个大文件的写法，而是按功能模块拆成了清晰的目录结构。我习惯于把“数据层”和“UI层”彻底分开，因为组队消息组件会同时被多个页面引用，不同的页面可能只用到其中一部分能力。

组件顶层分为四个模块：

packages/team-message/ ├── components/ // UI 组件 │ ├── MessageList/ // 消息列表展示 │ ├── QuickEntry/ // 快捷入口管理 │ ├── QuickAction/ // 快捷操作触发 │ └── DetailPreview/ // 消息详情预览 ├── models/ // 数据模型与类型定义 ├── store/ // 组件内部状态管理 ├── services/ // 网络请求、消息通道、原生桥接 └── utils/ // 时间格式化、埋点、权限判断等工具

这四个 UI 模块相互独立，它们之间不直接产生组件引用，而是通过一个轻量级的内部事件总线通信。比如用户点击了消息列表里的“快捷加入”按钮，MessageList 组件不做业务处理，只向事件总线派发一个“onQuickJoin”事件，由 QuickAction 模块负责真正调用接口、更新状态、并把结果回传给 MessageList 刷新。这样做的好处是，列表和操作逻辑解耦了，后续如果要让消息卡片出现在首页推荐流里，可以直接复用 QuickAction 模块，而不需要把列表逻辑一起带过去。

数据流上，我采用的是单向数据流。组件内部维护一个 Store，所有消息数据和入口配置都先进入 Store，再由 Store 向各 UI 模块派发更新。这样排查问题比较舒服：用户反馈“消息没刷新”，我第一件事不是找 UI 代码，而是去查 Store 里的数据源是不是最新的。

2.3 鸿蒙端 RN 桥接的几个关键基础能力

鸿蒙端的 RN 适配和 Android/iOS 不太一样，桥接层需要额外处理一些平台特有的能力。在跑通组件之前，我先把下面这几个基础能力在鸿蒙端验证了一遍。

推送消息的接收。组队消息的实时性来自推送。在鸿蒙端，我们通过原生侧封装了一个 PushModule，把系统推送回调透传给 RN 侧，RN 侧监听后更新 Store 里的消息列表。

权限判断。快捷入口里有“创建车队”“发起组队”这类入口，不同玩家身份看到的入口不一样。权限判断结果在原生侧更可靠，我们做了一个简单的 RN 桥接方法checkUserPermission，原生侧返回布尔值，RN 侧根据返回值过滤入口配置。

App 前后台切换。这是一个容易被忽略的点。组队消息在 App 退到后台再回到前台时，需要一个“刷新消息列表”的时机。原生侧在 App 回到前台时会发一个生命周期事件给 RN，RN 侧收到后做静默拉取。

这几个桥接能力当时在鸿蒙端都踩过坑，细节我放到最后一章说。这里先提醒：RN 在鸿蒙端的桥接 API 命名与 Android 端有差异，一定要做平台判断，不能用同一个桥接方法名直通。

3. 消息列表展示：从数据源到 UI 的完整链路

3.1 消息模型的字段设计：宁可多冗余，不要反复联调

消息列表是整个组件的地基。地基没打好，后面快捷操作、详情预览都会跟着出问题。我在设计消息模型时，遵循一个原则：一个消息对象在列表场景下要能自解释，不要为了显示一条消息去额外查三次接口。

实际使用的消息模型大致长这样：

export interface TeamMessage { messageId: string; // 服务端生成的消息唯一ID type: 'invite' | 'apply' | 'system' | 'remind'; status: 'unread' | 'read' | 'expired'; title: string; // 消息标题，如“张三邀请你加入车队” content: string; // 消息摘要，如“硬核推理本《迷雾山庄》 19:30开场” scriptName: string; // 剧本名称 teamId: string; // 车队ID，点击快捷入口时拼接跳转 teamTotalCount: number; // 车队总人数 teamCurrentCount: number; // 当前已加入人数 remainMinutes: number; // 剩余可加入时间，单位分钟 fromUser: { userId: string; nickname: string; avatar: string; }; createTime: number; // 服务端时间戳，毫秒 extraJson: string; // 扩展字段，保留给详情预览使用 }

这个模型之所以把scriptName、teamTotalCount、teamCurrentCount这些字段冗余进来，是因为它们会在列表、预览、快捷操作三个场景反复使用。如果模型里只有messageId，那每次渲染一个列表项都要根据 ID 再拉一次详情，列表滚动起来就是一场灾难。

可能有人会问：冗余字段会不会导致消息数据不同步？比如车队人数变了，消息里的teamCurrentCount还是旧的。我的处理办法是不在列表里做实时人数更新。列表只展示“收到消息时的人数状态”，如果需要看实时人数，引导用户点击详情预览，预览接口返回的是最新数据。这个语义上的取舍很重要，务必在产品层面讲清楚，否则开发同学会被“人数不变”的 bug 反复折磨。

3.2 FlatList 性能优化：消息列表必须能扛住300条以上的历史消息

RN 的 FlatList 在数据量小时表现尚可，但组队消息组件有一个特殊点：玩家可能积累了大量历史消息，一次性拉取300条并不罕见。如果不做性能优化，列表在快速滚动时会出现明显的白屏和卡顿。

我总结下来比较有效的手段是下面几个。

第一个是getItemLayout。这个方法很多人忽略，但它的作用很大。消息列表的每一项高度几乎是固定的（同一款卡片样式下的高度差不超过几个像素），我直接把固定高度传进去，让 FlatList 在计算滚动位置时不用动态去量每一项的高度。实测滚动流畅度有明显提升。

const ITEM_HEIGHT = 96; const getItemLayout = (_data: ArrayLike<TeamMessage> | null | undefined, index: number) => ({ length: ITEM_HEIGHT, offset: ITEM_HEIGHT * index, index, });

第二个是避免在 renderItem 里写内联函数。每次渲染创建新的函数引用会导致 FlatList 频繁重刷，尤其是当列表项内部有状态刷新（比如未读变已读）时，容易引发整列表重渲染。正确做法是把单项卡片抽成一个React.memo包裹的组件，单项状态更新只触发该组件重渲染。

第三个是合理设置windowSize和maxToRenderPerBatch。这两个参数的调优逻辑是：一次渲染太多项会阻塞 JS 线程，渲染太少项滚动时又会频繁加载。我最终调的经验值是windowSize={7}、maxToRenderPerBatch={10}，在低端鸿蒙设备上也试过，表现稳定。

3.3 消息分组和未读标识：让列表“有层次”而不是“一坨”

组队消息列表和普通聊天列表有一个显著区别：消息类型多（邀请、申请、系统、提醒），如果全部按照时间倒序堆在一起，玩家很难分清哪些是“需要我处理的”，哪些只是“通知”。

我们最终采用了两级分组策略。第一级按消息类型分成四个分区（待处理、邀请、申请、系统通知），第二级在“待处理”分区里按时间倒序排列。这样玩家打开列表第一眼看到的永远是“现在最需要我处理的”。

分区之间的切换栏，实际上就是后面要讲的快捷入口的一部分。也就是说，快捷入口不仅承载了全局导航功能，还在组件内部承担了列表分区的切换职责。这算是我在设计过程里一个比较满意的点——入口和列表复用同一套状态管理，不用做两套切换逻辑。

未读标识的处理有一条经验值得分享：不要只用一个红色的数字角标。我们在实际用户调研里发现，玩家看到“您有12条未读组队消息”时，大多数人完全不知道这12条里哪些是已经满员的车队。所以我们把status为expired（已过期）的消息，在未读标识上做了一个斜杠删除线的效果，配合“已满员”的灰色标签，玩家不用点进去就知道这条不用管了。

4. 快捷入口管理：动态化配置是灵魂所在

4.1 入口的数据结构：服务端下发代替本地写死

快捷入口如果仅靠客户端写死几个按钮，那算不上“管理”。真正的管理应该是运营同学可以动态调整入口的展示、排序和可见范围，不需要发版。所以入口配置的结构从一开始就设计成“服务端下发 + 客户端渲染”。

我们用的入口配置模板大致是：

{ "entryId": "team_invite", "name": "组队邀请", "icon": "icon_team_invite", "sort": 1, "visible": true, "permission": "all", "badgeType": "count", "targetPage": "TeamMessageList?tab=invite" }

每个入口有独立的entryId，客户端根据entryId去匹配本地要渲染的图标和跳转逻辑，而不是直接信任服务端下发的页面路径。这一点很重要：服务端可以决定“显不显示”“排在哪里”，但不能决定“跳到哪里”，跳转逻辑必须由客户端做映射，否则一旦服务端被篡改或误配，客户端会跳转到不存在的页面。

4.2 拖拽排序与本地记忆：用户把入口调整成“自己的顺手位置”

服务端下发的排序只是默认排序，用户应该能按自己的习惯调整。我们在快捷入口区域支持了长按拖拽排序，这个操作在 RN 端需要用到手势响应系统。

在 RN 中，拖拽排序的通用做法是监听PanResponder或者使用社区库的DraggableFlatList。我最终选了自己手写一个轻量的拖拽排序方案，原因有两个：一个是第三方拖拽库在鸿蒙端的兼容性当时还没被充分验证，另一个是我们的入口数量最多八个，远没有到需要虚拟列表的程度，手写成本不高。

手写拖拽排序的核心思路并不复杂：每个入口卡片监听长按事件，长按触发后进入“拖拽模式”，此时手指移动位置被转换成目标索引，在 store 里更新入口顺序，UI 通过Animated库做平滑移动动画。

拖拽排序结果我做了两级保存：先保存在组件 store 里（用户在当前会话内有效），再异步同步到本地存储（下次启动依然保持）。为什么不同步到服务端？因为入口排序是个人偏好数据，服务端同步的成本高收益低，本地存储完全够用。

4.3 权限控制与场景化入口：不同用户看到的入口完全不同

快捷入口的“管理”还有一个隐含需求：不同身份的用户看到的入口应该不同。房主需要看到“创建车队”，普通玩家需要看到“搜索车队”；女生用户可能需要看到“女生优先车队”，男生用户则不需要。

这个逻辑很简单，但实现时有个坑：不要在客户端硬编码“身份决定入口”，因为身份判断会有时差和例外。比如用户刚刚通过了车主认证，服务端还没来得及把认证结果同步到客户端缓存，此时客户端如果拿缓存判断，就会错误地隐藏“创建车队”入口。

我们的做法是：服务端在下发入口配置时，附带一份用户的权限快照。客户端以快照为准做渲染，不自行判断身份。权限快照的有效期是 10 分钟，过期后组件静默拉取最新配置。这样既避免了实时鉴权的网络开销，又保证了入口显示的相对及时。

5. 快捷操作触发：消息即操作，从看到到完成只用一步

5.1 操作类型枚举与统一事件分发

快捷操作是组件的核心价值所在。我在设计时把操作定义为以下几个类型：

export enum QuickActionType { JOIN_TEAM = 'join_team', REJECT_APPLY = 'reject_apply', ACCEPT_APPLY = 'accept_apply', VIEW_DETAIL = 'view_detail', APPLY_TEAM = 'apply_team', CANCEL_APPLY = 'cancel_apply', }

每个消息卡片根据消息类型和当前状态，展示对应的操作按钮组合。比如收到一条“邀请加入车队”的消息，未读状态下展示“查看详情”和“一键加入”两个按钮；收到一条“有人申请加入你的车队”的消息，展示“同意”“拒绝”和“查看详情”。

这里最容易犯的错误是把 UI 按钮的展示逻辑写散。我在组件里维护了一个“消息类型 × 消息状态 → 操作按钮”的映射表，集中管理，而不是在每个卡片组件里用三五个 if else 判断。映射表的好处是产品想要调整按钮组合时，只需要改一处配置。

5.2 一键加入的完整链路：接口调用、延迟防抖、状态回写

以“一键加入”为例，完整的链路是这样的。

用户点击加入按钮后，组件立即进入 loading 状态，按钮置灰并显示“加入中…”。与此同时，组件发出一个网络请求到后端joinTeam接口。请求的参数包括teamId、messageId（这个消息来源）、source（标识是从哪个入口发起的加入）。

请求返回成功后，组件更新两条数据：第一条是服务端下发的车队最新人数信息，用于刷新消息列表里的teamCurrentCount；第二条是把消息状态改为read，并关闭对应的未读角标。

这里有一个容易被忽略的细节：如果接口是异步的，用户在等待期间又点了其他消息的加入按钮，就可能导致状态错乱。我们的处理方式是在 store 里设置一个pendingActionMap，以 teamId 为 key 记录正在进行的操作，同一个车队不能同时发起两个请求。

5.3 操作失败的兜底与回滚：宁可提示用户，也不假装成功

一键加入最常见的失败原因是车队已满或车队已解散。这种失败不是网络问题，而是状态冲突问题——用户看到的消息是几分钟前的，但车队在这几分钟里已经满员。

对于这类失败，最重要的是不能只弹一个“操作失败”的 toast。我们的做法是：当加入失败原因为“车队已满”时，组件会自动触发一次详情预览的局部刷新，把车队人数更新到最新，同时把消息状态标记为expired，卡片变为灰色。用户看到的是“这个车队已经不行了”的完整信息，而不是一头雾水地看到一个失败提示。

这个设计看起来只是细节优化，但对用户体验的提升非常明显。之前老版本里用户加入失败后往往会重复点击多次，因为他不确定是网络问题还是车队问题。现在失败原因与状态同步更新，重复操作率下降了至少六成。

6. 消息详情预览：确认之后再做决定，预览是决策的最后一道闸门

6.1 从列表到预览的三级状态切换

很多消息组件只有“列表”和“详情页”两个状态，我要多加一个“预览”状态。原因是剧本杀组队消息包含的信息密度比较高：剧本名、车队发起人、当前人数、剩余时间、剧本封面……这些信息全部塞进列表卡片里不现实，但直接跳到完整详情页又显得太重。预览状态恰好居中，既能承载更多信息，又不打断当前的操作流。

预览的实现方式是在列表页面底部弹出一个半屏卡片。卡片展开时用Animated做 220ms 的滑入动画，背景蒙版逐渐变暗。用户可以从预览卡片里看到剧本封面、车队成员头像列表、剩余时间倒计时，以及两个主要操作按钮“加入车队”和“查看完整详情”。

预览卡片本身不是从零开发的。我复用了详情页的部分组件，把详情页 RDL（详情页信息区块）拆成了可复用原子组件。详情页展示的全部信息，预览卡片只展示其中一个子集。这样保证了预览和详情的视觉一致性，也让维护成本降低。

6.2 预览内容的实时性：不能拿旧数据误导玩家

预览卡片最容易出的问题是内容陈旧。因为预览是在列表页弹出的，列表页的数据可能已经过去几分钟，但玩家在预览卡片里看到的倒计时“剩余5分钟”，实际可能已经只有2分钟了。

我们在预览卡片弹出时，会调用一次teamDetailBrief接口，拉取车队最新的精简信息，只包含人数、剩余时间、车队状态三个字段。这个接口不返回完整详情，所以数据量很小，在正常网络环境下 150ms 内可以返回。

这里有一个权衡：如果不调用这个接口，预览可以做到秒开；但玩家决策时可能看到错误信息。如果每次都调用，预览就会有一个短暂的 loading 态。

我的取舍是：预览卡片先立即用列表里的旧数据渲染（保证秒开），同时在后台静默拉取最新数据，返回后无感替换。如果新数据发现车队已满，就在预览卡片顶部展示一条“该车队已满员”的红条提醒。这样既保证了速度，也保证了准确性。

6.3 预览与列表的联动状态：已读标记和清空逻辑

玩家在预览里看完一条消息，关闭预览回到列表时，这条消息就应该标记为已读。这个联动的实现并不复杂，关键在于触发时机：预览卡片关闭时，无论用户是否点击了操作按钮，只要预览内容真实展示过，就认为这条消息“已经看过”。

联动逻辑我单独放在一个usePreviewLinkage的 hook 里，它负责三件事：监听预览卡片的显隐、更新消息的status、刷新列表的未读角标。这个 hook 的细节比较琐碎，但有一句话值得记住：标记已读的动作应该是“预览关闭”驱动的，而不是“详情加载完成”驱动的，因为用户可能根本没有等到详情加载完成就关闭了预览。

7. 鸿蒙端实测效果与踩坑记录

7.1 真机性能数据：首屏渲染与滚动帧率

组件开发完成后，我们在鸿蒙真机上做了两轮完整的性能验证。第一轮是低端设备，第二轮是中高端设备。测试时开启开发者模式下的 GPU 渲染分析和掉帧检测。

最终的数据大致如下：

这个数据说明了两件事：组件化的收益是真实可见的，首屏和滚动性能在合理优化后，与原生方案的差距已经缩小到可接受的范围。

7.2 我踩过的三个典型坑，以及对应的解决方案

第一个坑是鸿蒙端的PanResponder与列表滚动手势冲突。长按拖拽入口时，手指轻微移动会被系统识别为滚动操作，导致拖拽入口没反应、列表却开始滚动。解决方法是拖拽模式开启时，临时给外层列表设置scrollEnabled={false}并用状态标志位控制，拖拽结束再恢复。

第二个坑是Animated动画在鸿蒙端的时序问题。预览卡片关闭动画结束时，蒙版的透明度没有归零，导致页面残留一层极淡的暗色遮罩，看起来像屏幕变脏了。排查后发现是动画回调里使用了setTimeout与动画完成回调的时序不一致。修复方案是不用setTimeout，全部改为Animated的useNativeDriver原生化驱动模式，动画完成后在回调里同步重置样式。

第三个坑是消息列表里同一个用户重复操作触发重复请求。用户快速点击“加入”按钮两次时，前一次请求还没返回，后一次又发出去了，导致服务端收到两条重复的入队请求。除了在 store 里加pendingActionMap做前端拦截之外，我还和后端约定在 joinTeam 接口里做了幂等校验，同一个 userId 在同一车队 5 秒内只能入队一次。双重保险之后，生产环境再也没出现过重复入队的问题。

8. 组件扩展空间和后续优化方向

这个组件上线后，又陆续接到几个新的需求，这里顺带说说我看到的扩展空间。

第一个扩展方向是把快捷入口从“功能入口”升级为“运营位”。目前的入口跳转目标都指向组件内部页面，但运营同学明确表示，他们希望某些入口可以跳转到 H5 活动页、专题页甚至外部小程序。如果要把入口做成通用运营位，数据结构里的targetPage字段就要扩展成targetType + targetUrl，客户端根据 targetType 做分发。

第二个扩展方向是消息列表的多端同步已读状态。目前已读状态只保存在本地，用户换了设备之后已读标记就丢了。要做成服务端同步，需要引入消息位点（message cursor）的概念，客户端每次读操作都向服务端上报位点。这个功能对 IM 类组件是刚需，值得好好设计。

第三个方向更长远，是把消息详情预览做成“可交互预览”，也就是说在预览卡片里就能看到剧本的音频介绍、车队成员的真实评价摘要，而不只是静态信息。这本质上是在预览里嵌一个轻量信息流，需要提前考虑缓存策略和离线状态。

对一个组件来说，它的价值不在于写了一堆漂亮的代码，而在于它能在业务变化时快速自我调整。组队消息与快捷入口组件在设计之初就把核心功能边界定得比较清楚，所以面对这些新需求，我基本不需要改动第一版的数据模型，只需要在服务端下发配置和前端渲染上做增量扩展就够了。这也是我会在这个方向继续投入的原因。