做卡牌游戏最容易被低估的一块往往不是玩法逻辑而是UI框架。打出去一张牌、拖拽到目标身上、手牌刷新、费用变动、动画插播……这些交互看起来不起眼但一旦卡牌数量上百、技能效果组合复杂起来UI代码就会变成一团乱麻。我经历过从一张卡写一堆if else到最后重构出数据驱动加模块化框架的过程这篇文章就完整复盘一下这套设计思路和落地细节。写这篇文章不是为了教你搭一个“最牛框架”而是想把卡牌游戏UI最核心的问题聊透UI的状态到底该由谁来决定界面组件如何拆分才能不互相踩脚以及数据驱动这件事在Unity里到底怎么落地最顺手。适合正在做卡牌项目、或者准备从零开始搭UI框架的开发者参考。1. 为什么卡牌游戏UI必须走数据驱动路线1.1 卡牌UI的特殊性状态多、联动密、表现杂先把卡牌游戏的UI和普通游戏UI做个对比。RPG游戏的背包界面大多数时候是“静态列表”加“点击查看详情”状态变化频率低界面之间耦合不深。而卡牌游戏完全不是这样。一张卡牌从牌库到手牌、从手牌到战场、从战场到坟场整个过程伴随大量状态切换。比如手牌中的卡要有“费用是否足够”的高亮提示、拖动时要有跟随和缩放、悬停时要展示详情、打出后要有目标选择框、结算后还要有动画回调。这还不算各种Buff标记、属性变化、卡牌临时修改比如被法术buff了攻击力等等。这些状态不是孤立存在的。费用不足时整手牌都要变灰一张卡被拖起来其他手牌要自动让位某个目标被锁定时其他可作用目标要高亮。这种“牵一发动全身”的联动特性决定了你不能在每个UI控件里各自维护状态否则一定会出现“改了A忘了B”的灾难现场。1.2 数据驱动解决的核心矛盾状态同步打个比方。没有数据驱动的时候UI状态就像大家各写各的小黑板——手牌区写一个“当前费用”技能面板也写一个“当前费用”费用变了你得挨个去通知它们改。写习惯了也没觉得不对直到某天你加了一个新UI元素忘了让它监听费用变化于是它显示的数字永远是错的而且你根本不知道它错在哪。数据驱动的思路就是反过来的全游戏只维护一份“权威数据”所有UI都是这份数据的“投影”。费用是3那所有费用显示控件都从同一个地方读这个3费用变成2数据层发出通知所有订阅了这个数据的UI自动更新。这样只要数据正确UI就一定是正确的。这个思路其实和MVVM很像但在Unity的UGUI体系下我们不需要完整照搬MVVM框架只需要抓住核心数据是唯一事实来源UI层只做渲染和交互不持有业务状态。1.3 模块化解决的核心矛盾复用与隔离卡牌游戏UI的另一个痛点是复用。手牌区的卡牌、商店里的卡牌、卡组编辑界面的卡牌本质上都是“一张卡”但尺寸、可交互行为、展示信息可能都不同。如果不做模块化最常见的下场就是复制三份Card控件代码后续卡牌加了新属性比如“连击”图标三个地方各改一遍总有漏改的。模块化的目标是把“一张卡”这个UI实体抽象成可复用的组件通过配置和接口来控制它的表现与交互而不是为每个场景单独写一套。同时模块化还负责隔离——牌库逻辑不应该知道界面长什么样界面也不应该直接操作游戏数据。2. 顶层架构设计数据层、视图层、控制层怎么划分2.1 三层架构在Unity项目里的落地方式我最终采用的是类似“数据层-视图层-控制层”的三层结构但根据Unity的特点做了简化。数据层Model负责定义卡牌数据结构和游戏状态。包括卡牌静态配置、运行时状态比如当前费用、手牌列表、以及状态变更事件。这一层不引用任何Unity的UI组件纯C#类方便单元测试。视图层View就是UGUI控件本身负责显示数据和播放表现。视图层不直接修改游戏数据只响应数据变化并把用户操作转化成事件抛出。控制层Controller / Presenter连接数据层和视图层。监听视图层抛出的用户操作更新数据层订阅数据层的变化刷新视图层。在Unity项目中我通常用MonoBehaviour组件来充当Controller。这个结构看起来简单但真正执行起来会碰到很多细节问题。比如数据变化了该由谁通知视图我的方案是给数据层加一个轻量的事件系统而不是直接引入完整的UniRx或者R3。原因后面会讲。2.2 核心数据类设计CardData 与 CardConfig先看最底层的卡牌数据怎么设计。我把数据拆成了两层静态配置CardConfig从策划配置表Excel/JSON/ScriptableObject读取包含卡牌的ID、名称、费用、攻击力、生命值、卡面图片路径、技能ID列表等。这些数据在游戏运行期间不会变化。运行时实例CardData指一张“实际存在的卡”。比如你的卡组里有3张“火球术”它们的CardConfig是同一个但CardData各有自己的实例ID、当前附加的Buff、所处的区域手牌/牌库/战场等。这样拆有什么好处最直观的好处是省内存——卡牌配置只需要加载一份几百张卡共享同时也让逻辑更清晰策划改数值只需要改配置不用动代码。下面是一个简单的定义// 静态配置使用 ScriptableObject 便于策划在编辑器里配置 [CreateAssetMenu(fileName CardConfig, menuName Card/CardConfig)] public class CardConfig : ScriptableObject { public string cardId; public string cardName; public int cost; public int attack; public int health; public Sprite cardImage; public Liststring skillIds; } // 运行时卡牌实例 public class CardData { public string instanceId { get; private set; } public CardConfig config { get; private set; } public int currentAttack; public int currentHealth; public bool isBuffed; public CardZone zone; // 当前所在区域Deck/Hand/Battle/Grave public CardData(CardConfig config) { this.config config; this.instanceId Guid.NewGuid().ToString(); this.currentAttack config.attack; this.currentHealth config.health; this.zone CardZone.Deck; } }要注意的一点是不要在CardData里直接存GameObject引用否则数据层就被Unity对象绑死了。视图层需要获取卡牌对应的GameObject时可以通过CardView上记录的instanceId去查找或者由控制器统一管理映射关系。2.3 事件系统自己写还是用现成库数据驱动离不开事件系统。我的选择是自己写一个极简的C#事件总线而不是引入UniRx/R3。原因是卡牌项目的UI状态量级没那么大系统自带的event/C#事件完全够用而且泛型事件总线用起来更直观团队成员上手成本低。一个简单的实现思路public static class GameEvents { public static event Actionint OnCostChanged; public static event ActionCardData OnCardPlayed; public static event Actionstring OnCardZoneChanged; public static void CostChanged(int newCost) OnCostChanged?.Invoke(newCost); public static void CardPlayed(CardData card) OnCardPlayed?.Invoke(card); public static void CardZoneChanged(string instanceId) OnCardZoneChanged?.Invoke(instanceId); }这个event bus再精简一点也可以做成带接口的版本。但核心思想是全局状态变更通过静态事件广播UI组件只订阅和自己相关的事件。不过要注意事件总线用多了会难排查问题所以真实的项目里建议对事件进行分类管理不要所有事件都堆在一个静态类里。我自己的原则是全局性的事件费用、回合、区域内卡牌数量变化用事件总线局部交互比如某张卡的拖拽状态用UnityEvent或者C#直接方法回调。3. 模块化UI组件拆分从单张卡到整屏界面3.1 CardView一张卡的最小完整单元模块化的起点是CardView。这是整个UI框架的最小单元任何地方看到“一张卡”都用这个组件。CardView的职责有四个根据CardData刷新界面显示名称、费用、攻防、卡图、Buff图标提供交互入口点击、拖拽、悬停但不负责具体业务逻辑维护自身表现状态缩放、高亮、置灰、禁用隐藏和显示对应的GameObject但不管理生命周期由对象池管理看一个简化版的CardViewpublic class CardView : MonoBehaviour { [SerializeField] private TextMeshProUGUI nameText; [SerializeField] private TextMeshProUGUI costText; [SerializeField] private TextMeshProUGUI attackText; [SerializeField] private TextMeshProUGUI healthText; [SerializeField] private Image cardImage; [SerializeField] private GameObject buffIconRoot; [SerializeField] private CanvasGroup canvasGroup; private CardData data; public string InstanceId data?.instanceId; public CardData Data data; public void Setup(CardData cardData) { data cardData; Refresh(); } public void Refresh() { if (data null) return; nameText.text data.config.cardName; costText.text data.config.cost.ToString(); attackText.text data.currentAttack.ToString(); healthText.text data.currentHealth.ToString(); cardImage.sprite data.config.cardImage; } public void SetDimmed(bool dimmed) { canvasGroup.alpha dimmed ? 0.5f : 1f; canvasGroup.interactable !dimmed; } }这里的核心原则是Setup负责绑定数据Refresh负责刷新显示所有修改显示的方法都是被动响应。这样后续不管是从手牌拖到战场、还是从牌库抽到手牌都只需要改变数据并调用RefreshCardView自己不需要关心“我为什么变了”。3.2 区域容器HandView、DeckView、BattleView有了CardView之后还需要“容器”来管理多个CardView的排列和布局。我把这些容器统称为ZoneView每个区域一个组件。HandView手牌区负责手牌的横向排列、超出手牌数时的缩放、拖拽时其他手牌的让位、费用不足时的批量置灰。它不持有游戏数据只持有当前显示的CardView列表。DeckView牌库通常就是一张牌背图加一个数量角标。它需要监听牌库数量变化刷新角标抽牌动画时它要提供一个“牌从牌库飞出来”的起始位置。BattleView战场区管理已打出的卡牌布局包含站位、排序、战斗状态表现。这里的卡牌CardView和手牌的尺寸不同但在结构上是同一个组件只是在摆放时的参数不一样。我在做区域排序时用过两种方案一种是直接计算RectTransform的anchoredPosition另一种是使用HorizontalLayoutGroup加LayoutElement。实际体验下来手牌这种数量变化频繁、还要穿插拖拽动画的场景手写布局比LayoutGroup更可控。LayoutGroup在做数量变动的重新布局时会有明显的“跳动”感而且很难插动画。手写布局虽然代码多但你能完全掌控每一帧的插值进度。3.3 公共UI层费用、回合、按钮、技能描述除了卡牌本身卡牌游戏UI还需要费用条、回合指示器、结束回合按钮、技能描述弹窗、卡牌详情弹窗等公共元素。这些组件同样遵循数据驱动原则。比如费用条public class ManaBarView : MonoBehaviour { [SerializeField] private TextMeshProUGUI currentManaText; [SerializeField] private TextMeshProUGUI maxManaText; [SerializeField] private Image fillImage; private void OnEnable() { GameEvents.OnCostChanged OnCostChanged; } private void OnDisable() { GameEvents.OnCostChanged - OnCostChanged; } private void OnCostChanged(int newCost) { currentManaText.text newCost.ToString(); // 假设最大费用是10计算填充比例 fillImage.fillAmount newCost / 10f; } }这里有个值得强调的细节所有订阅了全局事件的View必须在OnDisable或OnDestroy里取消订阅。否则场景切换时很容易出现空引用异常——界面已经销毁了事件却依然触发了。这个问题在卡牌游戏这种频繁切换场景的项目里尤其常见。4. 实战实现从数据到界面的完整流转4.1 初始化从配置表到卡牌对象池就绪前面把架构和数据类都定好了这一节走一遍完整的实战流程游戏初始化时如何把卡牌数据加载出来、并按需实例化卡牌视图。第一步是加载配置。我用的是ScriptableObject加Excel导出工具策划在Excel配表通过工具生成ScriptableObject资产。运行时只持有一个CardLibrary的单例负责按cardId检索配置public class CardLibrary : MonoBehaviour { public static CardLibrary Instance { get; private set; } [SerializeField] private ListCardConfig allCards; private Dictionarystring, CardConfig cardMap; private void Awake() { Instance this; cardMap new Dictionarystring, CardConfig(); foreach (var card in allCards) { cardMap[card.cardId] card; } } public CardConfig GetCardConfig(string cardId) { cardMap.TryGetValue(cardId, out var config); return config; } }第二步是初始化对象池。卡牌游戏很讲究的是卡牌实例的复用。开局建立卡组时我们不希望反复Instantiate和Destroy卡牌对象这会产生GC压力以及卡顿。通常会维护一个CardView对象池public class CardPool : MonoBehaviour { [SerializeField] private CardView cardPrefab; [SerializeField] private Transform poolRoot; private StackCardView pool new StackCardView(); public CardView Get() { CardView view; if (pool.Count 0) { view pool.Pop(); view.gameObject.SetActive(true); } else { view Instantiate(cardPrefab, poolRoot); } return view; } public void Release(CardView view) { view.gameObject.SetActive(false); view.transform.SetParent(poolRoot); pool.Push(view); } }对象池的好处不只是省性能。在卡牌打出去之后如果效果是“洗回牌库”你可以直接把这张卡Release回池子然后重新从池子里取不用担心引用残留的问题。4.2 抽牌、出牌、状态刷新的完整链路接下来模拟一个最核心的流程抽一张牌到手牌玩家查看手牌然后点击打出。第一步抽牌。控制器CardController调用数据层的方法public class CardController : MonoBehaviour { [SerializeField] private HandView handView; [SerializeField] private GameObject gameBoardData; // 实际项目中可能是BattleManager public void DrawCard(string cardId) { // 1. 通过配置创建运行时数据 var config CardLibrary.Instance.GetCardConfig(cardId); var cardData new CardData(config); cardData.zone CardZone.Hand; // 2. 通过对象池获取CardView并放入手牌区 var cardView CardPool.Instance.Get(); cardView.Setup(cardData); handView.AddCard(cardView); // 3. 发送事件比如“手牌数量变化”“牌库数量减少” GameEvents.CardZoneChanged(cardData.instanceId); } }第二步界面刷新。CardView在Setup时就已经显示了正确数据所以“抽牌”这一步界面刷新基本是自动完成的。如果策划改了某张卡的临时数值比如被buff攻击力只需要调用对应CardView的Refresh或者通过事件找到这个CardView再刷新。第三步点击出牌。玩家点击一张卡CardView通过UnityEngine.EventSystems的IPointerClickHandler接口抛出点击事件public class CardView : MonoBehaviour, IPointerClickHandler { public UnityEventCardView onCardClicked; public void OnPointerClick(PointerEventData eventData) { onCardClicked?.Invoke(this); } }这里的onCardClicked是一个UnityEvent在Inspector里或者代码里由CardController来订阅。控制器收到点击事件后先判断费用是否足够、目标是否合法满足条件才真正执行出牌逻辑private void HandleCardClicked(CardView cardView) { var cardData cardView.Data; if (gameBoardData.CurrentMana cardData.config.cost) { // 提示费用不足 return; } // 扣除费用、执行卡牌效果、将卡移出战场…… gameBoardData.SpendMana(cardData.config.cost); gameBoardData.PlayCard(cardData); // 界面更新 CardPool.Instance.Release(cardView); handView.RemoveCard(cardView); GameEvents.CostChanged(gameBoardData.CurrentMana); }这个链路看起来简单但它是健康的控制器负责决策数据层负责状态变更视图层只管显示和交互谁都不越界。4.3 拖拽、悬停、目标选择的交互实现卡牌游戏UI里最复杂的交互不是点击而是拖拽选择目标。比如一张“对敌人造成3点伤害”的卡玩家拖到敌人身上松手卡牌生效。这个交互要处理好几个阶段拖拽开始、拖拽中、目标判定、松手结算。我采用的方式是在CardView上挂一个自定义的拖拽组件而不是用Unity自带的EventTrigger写死逻辑public class CardDragHandler : MonoBehaviour, IBeginDragHandler, IDragHandler, IEndDragHandler { [SerializeField] private CardView cardView; private Vector3 startPosition; private Transform startParent; private int startSiblingIndex; public void OnBeginDrag(PointerEventData eventData) { // 记录初始位置并把卡片提到最上层渲染 startPosition transform.position; startParent transform.parent; startSiblingIndex transform.GetSiblingIndex(); transform.SetParent(UIRoot.Instance.DraggingLayer); // 让卡片略微放大横向铺开便于拖拽 cardView.SetDraggingVisual(true); } public void OnDrag(PointerEventData eventData) { transform.position eventData.position; // 在拖拽过程中持续判断当前指针下的目标 // 如果目标合法高亮目标否则清除高亮 TargetSelector.Instance.UpdateHover(eventData.position); } public void OnEndDrag(PointerEventData eventData) { // 判断目标是否合法 bool isValid TargetSelector.Instance.TryConfirmTarget(eventData.position, out var target); if (isValid) { // 通知控制器执行出牌 cardView.onDragConfirmed?.Invoke(target); } else { // 回到原位 transform.SetParent(startParent); transform.SetSiblingIndex(startSiblingIndex); transform.position startPosition; } cardView.SetDraggingVisual(false); } }这个过程中有个容易踩坑的地方拖拽时卡牌层级必须挂到专门的“拖拽层”下否则卡牌会被其他UI遮挡。刚开始做的时候我直接改了CardView的父物体结果所有拖拽中的卡都跑到了屏幕最底下后来加了一个专门的UIRoot拖拽层才解决。这个层级在设置时需要禁用RectTransform的拉伸否则拖拽坐标会出问题。目标选择高亮也是一个常见痛点。我的方案是给所有可交互目标敌方随从、英雄等挂一个ITargetable接口目标选择器用射线检测或者根据屏幕坐标查找该坐标下的UI元素命中后调用目标的SetHighlighted方法。这样目标选择逻辑和卡牌逻辑完全解耦后续增加新的可互动对象只需要实现接口。5. 性能优化和Unity UI层级的实战细节5.1 UI层级和Overdraw做卡牌游戏必须重视卡牌游戏的UI元素数量不少尤其是战场上有大量卡牌、Buff图标、特效层叠加的时候如果层级没控制好Unity的UI网格会出现大量同屏绘制主线程的UI重建耗时和GPU的Overdraw都会飙升。我做性能分析时最常用的是Unity自带的Profiler再加上Frame Debugger查看每一帧的UI绘制批次。经验是将可以合并的静态UI元素背景、边框、底纹放在同一个Canvas下动态频繁的元素卡牌文字、血量数值单独放在一个子Canvas下避免频繁标记整个Canvas重建卡牌拖拽时只更新拖拽中的那张卡的RectTransform不要全屏刷新所有UI禁用不需要接收射线检测的Image的RaycastTarget其中“禁用RaycastTarget”这个优化是我觉得最简单也最有效的。默认创建的Image的RaycastTarget是勾选的意味着每个Image都会参与EventSystem的射线检测。一百张卡就有一百次检测再加上底下的面板、图标、文字一次点击要做的射线检测数量非常可观。把所有不需要交互的Image的RaycastTarget关掉卡牌拖拽的流畅度会有明显提升。5.2 对象池与Canvas的配合前面的CardPool对象池还需要考虑Canvas的问题。如果所有卡牌的CardView都在同一个Canvas下实例多了以后只要有几张卡的属性变化就会导致整个Canvas的重建。所以我在项目里按区域拆分Canvas手牌一个Canvas战场一个Canvas特效层一个Canvas。这个拆分带来了一个额外的好处手牌区做拖拽让位动画时只影响手牌Canvas的布局战场上的卡牌动画不会和手牌区互相干扰。这也是模块化的一部分——UI更新是以区域为单位的不是以整屏为单位。Canvas的拆分要和对象池协同。从池子里取出CardView时需要把它挂到对应区域的Canvas下。所以在CardPool.Get方法里需要接收一个parent参数这样做public CardView Get(Transform parent) { CardView view; if (pool.Count 0) { view pool.Pop(); view.gameObject.SetActive(true); } else { view Instantiate(cardPrefab, parent); } view.transform.SetParent(parent); view.transform.localScale Vector3.one; view.transform.localPosition Vector3.zero; return view; }这里要注意的是SetParent之后一定要重置localScale和localPosition否则在对象池里调整过的缩放和位置会带到新的区域里。踩过这个坑的同学应该不少——从池里取出的卡牌可能变成了0.5倍大小或者出现在莫名奇妙的坐标上。5.3 动画与特效层如何不干扰UI逻辑卡牌游戏有大量动画抽牌动画、出牌动画、伤害飘字、Buff图标闪烁。这些动画如果直接和CardView逻辑混在一起会让代码变得极其混乱。我的做法是把动画单独拆到一个UIFX层。CardView只负责“静态显示正确的数据和状态”任何动画都由独立的组件或管理器来驱动。例如抽牌动画AnimatedCardMover从牌库位置飞到手牌位置再把手牌加入HandView出牌动画卡牌飞出、目标被击中、伤害数字飘字悬停动画CardView提供一个SetHovering(bool)方法具体放大多少、描述面板从哪里弹出由HoverManager决定这里想强调一个设计原则动画层和逻辑层要在时间上解耦。比如打出“火球术”后卡牌要先播放“从手牌飞向目标”的动画动画结束后再执行伤害结算。如果直接在点击时就扣血动画还没播完目标已经少血了视觉和逻辑就分裂了。我用的做法是给动画加一个回调或者用ScriptableObject定义一个“卡牌表演序列”——先播放动画A回调后结算效果再播放动画B。这个序列和UI框架分离属于游戏表现层的内容但UI框架要能支持“等待动画完成再执行下一步”的机制。所以我的CardController里出牌逻辑是异步的简单用协程或者回调链来串联。6. 常见问题排查与踩坑记录6.1 手牌区卡牌重叠、位置跳动手牌数量多的时候卡牌要自动缩小并调整间距。如果手写的布局计算不够健壮最常见的问题是最后一张卡跳来跳去或者卡牌之间互相重叠。我当时用了一个比较简单但很稳的公式先根据手牌总数确定每张卡的宽度目标值再计算一个基准间距然后让每张卡通过位移动画移动到目标位置。重点在于刷新布局的时机要统一——不要在每张卡的数据变化时都触发一次布局而是集中在一个布局管理器里统一计算。手牌加入或移除时只调用一次RebuildHand()。6.2 事件订阅泄漏导致空引用这个在文章前面提过但值得再说一遍。卡牌游戏UI组件大多是动态生成和销毁的如果一个View订阅了GameEvents静态事件而OnDestroy里没有退订场景切换后再触发事件就会去调用一个已经销毁的MonoBehaviourUnity会报“MissingReferenceException”。后来我给自己定了一个铁律所有通过代码订阅的全局事件一律在OnDisable退订OnEnable订阅。不要放在Start和OnDestroy里。OnEnable和OnDisable的配对才是最稳定的因为即使物体SetActive(false)它也会正确执行OnDisable不会漏掉退订。6.3 卡牌拖拽时UI闪烁或穿透拖拽卡牌时如果出现其他UI闪烁大概率是层级问题。拖拽中的卡牌需要放在最高的拖拽层Canvas下同时这个Canvas要设置成Screen Space - Camera排序值高于所有游戏UI层。我给项目分了四个Canvas层级Canvas排序值用途UIBackgroundLayer0背景、通用底板UIGameLayer10手牌、战场、面板UIDragLayer100拖拽中的卡牌UIPopupLayer200弹窗、飘字这样分完之后拖拽中的卡牌永远在战场上最顶上不会被任何其他界面遮挡。弹窗又可以覆盖在拖拽层之上方便做“拖拽中弹出确认框”之类的需求。6.4 对象池SetActive引发的适配问题对象池里的卡牌在SetActive(true)之后如果使用了LayoutGroup实时布局会出现一帧的错位。因为LayoutGroup在物体激活后的下一帧才重新计算布局。我的规避方式是手牌区不用LayoutGroup用手写的布局其他区域如果用LayoutGroup就延迟一帧加入或者手动调用LayoutRebuilder.ForceRebuildLayoutImmediate。这里顺便提一个与Canvas相关的坑如果两层Canvas的兄弟顺序变化了比如动态设置SetAsLastSiblingRaycast的检测结果会发生变化可能导致某些按钮点击不到。排查这类问题最简单的方法是打开Frame Debugger查看对应UI元素的材质渲染顺序以及EventSystem的Raycast结果。7. 这套框架还能怎么扩展卡牌UI框架搭好之后扩展性会变得非常舒服。比如后续要加入“卡牌升级”功能——同一张卡有基础版和升级版只需要在CardConfig里加两个版本的配置CardData里指向哪个版本CardView刷新时自然显示对应数据。要支持“好友对战”或者“双人模式”只需要扩展CardData的状态机增加“对方战场”的区域把对方的CardView渲染出来即可。因为数据层和视图层是分离的视图层并不知道数据是来自本地还是网络。如果要嵌入多语言或远程配置CardConfig这个ScriptableObject可以改成从远程JSON动态构建CardView刷新时读取本地化文案。这些都是模块化带来的红利——单一数据源统一刷新机制。我个人在实际项目里感受最深的一点是UI框架这件事越早定越好。卡牌游戏开发前期交互和界面变更比玩法逻辑还要频繁如果一开始就搞数据驱动加模块化这套后续每个新功能都是在现有框架上按规则添加速度快、Bug少。如果前期用临时写法堆功能等到后期再重构那成本会高得让你怀疑人生。这套框架不是什么高深的东西核心也就两条数据是唯一的事实来源UI组件各管各的一亩三分地。但就是这两条能让你的卡牌项目UI代码保持清爽撑到项目上线。