做 Unity 客户端的朋友应该都有这种体会UI 代码是项目里腐烂速度最快的部分没有之一。尤其是登录页这种看着简单、改起来要命的模块——今天加个按钮明天改个输入框校验后天又要接新的第三方登录渠道等项目经理过来跟你说我们要换个弹窗样式的时候你看着那几百行又臭又长的 LoginPanel.cs只想当场辞职。我接手过几个项目登录页基本都是单文件承载所有逻辑UI 操作、网络请求、数据存储全写在一起调试全靠打断点人肉定位测试更是无从谈起。这篇文章想聊的是我最近在 FUI 框架上做的一次展示层解耦实践拿一个最日常的登录页当试验田把 UGUI 的界面表现、测试替身的逻辑模拟、权限边界的层级管控全部串起来验证了一遍。整个过程踩了不少坑也沉淀了几个我觉得值得复用的设计思路。FUI 是我们内部基于 Unity UGUI 搭建的一套 UI 框架核心目标就是解决多端 UI 复用和界面逻辑混乱的问题。如果你也在做 Unity 项目架构梳理或者正在被 UI 代码的耦合问题折磨这篇文章应该能给你一些可以直接落地的参考。1. 项目背景为什么我要拿登录页开刀1.1 FUI 是什么为什么要拆先交代一下 FUI 的背景。FUI 取自 Flexible UI 的缩写是我们团队在 UGUI 之上封装的一层 UI 框架。它没有重复造轮子没有自己实现一套渲染层而是在 Canvas、RectTransform、Graphic 这些 UGUI 基础组件之上做了三件事界面生命周期的统一管理、界面资源的加载释放、以及界面逻辑的分层约束。说直白点FUI 就是给团队定了一套写 UI 的规矩谁违反了规矩代码 review 就会被拦下来。为什么要定规矩我先说一个特别典型的场景。项目早期为了快速出包登录页逻辑一般是这么写的LoginPanel.cs 里直接持有 Button、InputField、Text 的引用在 Start 里给按钮挂 onClick 监听监听方法里直接发 HTTP 请求回调回来以后直接改 Text 内容、切换面板显隐、把 token 塞进 PlayerPrefs。这套代码在最开始的时候跑得挺好毕竟需求就一条账号密码登录。但需求会变的。等产品说我们要支持手机验证码登录你发现得在 LoginPanel 里加一个模式切换等产品说微信授权也要上你发现得引第三方 SDK还得在按钮回调里嵌一套 SDK 的初始化流程等到产品说UI 要改一版布局大调整你面对的是一坨牵一发动全身的泥潭。UI 代码和业务代码像麻花一样缠在一起改任何一个按钮的显示逻辑都可能误伤到网络请求或数据存储。更痛苦的是你想在编辑器里单独验一下登录按钮的交互逻辑还得先把后端服务起起来否则根本走不通全流程。FUI 的解耦思路其实很朴素把登录页长什么样交给 View 层管把登录流程怎么走交给 Presenter 层管把账号怎么验证、token 怎么存交给 Service 层管。每一层只依赖自己上一层暴露的接口不依赖具体实现。这样登录页就变成一个随时可以替换的壳子内部逻辑完全独立——今天用 UGUI明天换 UIToolkit后天接个原生插件业务层代码一行都不用动。1.2 登录页作为验证场景的优势有人可能会问选登录页做验证是不是因为登录页简单恰恰相反登录页是麻雀虽小五脏俱全的典型。我把它拆开列了一遍一个标准登录页至少包含五类能力输入组件用户名输入框、密码输入框涉及 InputField 的文本校验、ContentType 设置、占位符切换交互组件登录按钮、注册入口、忘记密码入口涉及按钮的可交互状态管理、防重复点击状态反馈加载中转圈、登录成功跳转、登录失败错误提示涉及多状态切换的 UI 表现数据交互调登录接口、处理 token、保存登录态、恢复会话涉及网络层调用和数据持久化异常处理网络超时、参数错误、服务端错误码解析涉及各种边界情况的兜底这五类能力任何一个成熟的 UI 框架都必须正面回答。拿登录页来验证解耦方案等于用最小成本把框架的完整能力过了一遍而且登录页是每个项目从第一天就要写的界面不存在额外造模块的负担试错了也不心疼。我在这次实践里还加了一个附加目标让登录页在没有真实后端的情况下也能被完整地自动化测试。这个目标直接推动了测试替身这件事的落地后面我会详细讲。2. 整体设计与解耦思路2.1 分层架构从一坨到三件套这次登录页的解耦我最终采用的是 MVP 变体准确说是 View Presenter Service 的三层结构。为什么不直接上 MVVM老实讲Unity 里没有像 WPF 那样完善的数据绑定机制MVVM 要在 UGUI 上落地就得自己写 Binding还得依赖反射或者代码生成学习成本和维护成本都不低。MVP 的 Presenter 是纯 C# 类不依赖任何 UnityEngine 类型这就意味着单元测试可以直接跑在 EditMode 下秒级反馈。三层的职责划分如下View视图层只负责 UGUI 控件的组织和表现。持有控件引用、监听用户输入事件、把事件转发给 Presenter、响应 Presenter 的状态更新指令来修改界面。Presenter表现层负责登录流程的业务编排。监听 View 转发过来的事件调用 Service 的接口处理回调结果决定 UI 应该切到什么状态。Service服务层负责登录相关的数据能力。封装登录请求、token 存储、会话恢复对外只暴露接口不暴露实现细节。这里最关键的一点是依赖方向View 依赖 Presenter 的接口Presenter 依赖 Service 的接口Service 谁都不依赖。所有依赖都是面向抽象的具体实现类的实例化统一交给一个简单的工厂或者容器管理。这样在做测试的时候我们可以轻松地给 Service 换一个 Fake 实现给 View 换一个 Recording 实现从而实现任意层的独立验证。在项目结构上我按层拆了三个程序集Assembly DefinitionFUI.View、FUI.Presenter、FUI.Service。引用关系严格单向View 引用 PresenterPresenter 引用 ServiceService 不引用任何人。程序集是 Unity 编译期的硬约束如果有人在 View 层直接用了 Service 层的 namespace编译阶段就会报错。这比任何代码审查工具都刚性。2.2 接口先行登录模块的契约设计动手写代码之前我第一件事是定义接口。这一步非常关键因为接口就是契约契约定死了后面每一层的实现才能并行推进。登录模块我一共定义了三个接口分别对应三层// Service 层对外暴露的登录能力 public interface ILoginService { void Login(string username, string password, ActionLoginResult callback); void Logout(); bool IsLoggedIn { get; } string Token { get; } } // Presenter 层提供给 View 的流程控制方法 public interface ILoginPresenter { void OnLoginClicked(string username, string password); void OnRememberPasswordToggle(bool isOn); void OnDestroy(); } // View 层提供给 Presenter 的界面刷新方法 public interface ILoginView { void SetLoading(bool isLoading); void SetError(string message); void OnLoginSucceed(); }三个接口从三个方向把登录模块切开了。ILoginService 不包含任何 UI 相关的类型Login 的回调用 Action 而不是 UnityEvent这样 Service 层就不会被 UnityEngine 绑定EditMode 测试随便跑。ILoginPresenter 的方法参数是字符串而不是 UGUI 控件这样无论界面输入来自 InputField 还是原生输入框PresenterView 都能处理。ILoginView 的方法描述的是界面状态而不是具体操作这样 View 的实现可以自由决定状态切换的表现方式。顺便说一句LoginResult 这个返回值类型我是刻意做成一个不可变的 DTOData Transfer Object包含 Success、ErrorCode、ErrorMessage 字段。它既不是 Service 的内部类也不是 View 的私有类而是放在一个公共的 module 命名空间里。这个类型是层与层之间的通信语言必须稳定、简洁、不带任何一方的私货。2.3 事件驱动UI 与逻辑的通信协议三层之间的通信我没有采用直接调方法 回调的朴素方式而是引入了一个轻量级的事件总线。这个决定是从一次真实需求里得到的教训登录页的登录成功事件除了发请求的 Service 自己知道还可能有外部模块比如第三方授权回调、App 唤起参数解析也知道。如果都用直接的调用链事件来源一多依赖关系就会乱成一团。我实现的 IEventBus 很薄核心就三个方法Publish、Subscribe、Unsubscribe。底层用一个字典存委托列表不引第三方库代码量不超过五十行public sealed class EventBus : IEventBus { private readonly DictionaryType, Delegate _handlers new(); public void SubscribeT(ActionT handler) { if (_handlers.TryGetValue(typeof(T), out var existing)) _handlers[typeof(T)] Delegate.Combine(existing, handler); else _handlers[typeof(T)] handler; } public void UnsubscribeT(ActionT handler) { if (_handlers.TryGetValue(typeof(T), out var existing)) _handlers[typeof(T)] Delegate.Remove(existing, handler); } public void PublishT(T message) { if (_handlers.TryGetValue(typeof(T), out var existing)) (existing as ActionT)?.Invoke(message); } }登录模块里View 的按钮点击被包装成 LoginButtonClickedMessagePresenter 订阅这个消息来触发流程Service 登录完成以后 Publish 一个 LoginResultMessagePresenter 再订阅这个消息来更新 View。这套通信协议最大的好处测试替身可以只向总线发布一个假的登录成功消息就能从外部驱动 Presenter 的状态流转完全不需要真正点击 UI、不需要真实网络。事件总线本身成了测试的后门这是我做解耦之前没想到的额外红利。3. UGUI 登录页的具体实现3.1 从 UGUI 源码看 Canvas 与 RectTransform 的工作机制在动手搭界面之前我重新翻了一遍 UGUI 源码重点研究两个问题Canvas 的更新机制到底是怎么触发的RectTransform 的布局计算什么时候会失效。这俩问题直接决定了登录页在频繁切换状态的场景下会不会产生性能问题。UGUI 的渲染更新核心在 CanvasUpdateRegistry 这个类里。每个 GraphicImage、Text 这些只要调用了 SetVerticesDirty就会把自己注册进 CanvasUpdateRegistry等到 Canvas 的 willRenderCanvases 事件触发时统一执行 Rebuild。简单说UGUI 的网格重建是标记-延迟-批处理机制不是即时发生的。这意味着如果你在 Update 里每帧改一个 Text 的内容那个 Text 的网格就每帧被标记一次 dirty每帧重建一次顶点数据代价非常大。登录页最常见的问题就是 loading 动画里放了一个请稍候...的 Text然后代码每帧去改它的透明度或者位置结果整个 Canvas 每帧重建机型稍微差一点就开始掉帧。RectTransform 的问题更隐蔽我打赌很多人踩过但没意识到。RectTransform 的 anchorMin、anchorMax、sizeDelta、anchoredPosition 这些属性决定了它相对父节点的布局但当你连续修改多个属性时布局计算并不会立刻全部生效。比如你先改了 sizeDelta立刻读 rect.width读到的可能是旧值要等到下一帧的布局刷新之后才能拿到新值。这个布局延迟在动态创建控件、动态调整表单尺寸时非常容易踩坑。我之前遇到过一个 bug登录成功以后要展示一个用户协议弹窗弹窗宽度根据文本长度动态计算算出来的宽度总是偏小就是因为读 rect 读早了。实操中的应对方式有三条第一登录页里所有需要高频更新的控件尽量避开 SetVerticesDirty 的触发路径。比如 loading 转圈动画我自己写了一个旋转的 RectTransform 组件每帧只改 rotation 的 Z 值不触发任何 Graphic 的 dirty性能开销极小。第二输入框的校验反馈、错误提示这类频次低但需要醒目效果的内容用两个预设好的 GameObject 做显示隐藏切换需要显示错误时就 SetActive(true)不需要就 SetActive(false)而不是动态 new 一个 Text 再设一堆属性。第三如果需要同时改多个 RectTransform 属性改完之后调用一次 RectTransform.ForceUpdateRectTransforms(true) 强制刷新保证后续读取的值是准确的。3.2 登录页的层级结构与组件挂载具体到登录页的 UGUI 表现我搭了这样一棵层级树从外到内LoginPanel (Canvas 下的根节点挂 LoginView.cs) ├── Background 半透明底图纯展示用 ├── ContentPanel 表单容器挂 VerticalLayoutGroup 自动排列 │ ├── TitleText 标题 欢迎登录 │ ├── UsernameInput 输入框InputField Placeholder │ ├── PasswordInput 输入框ContentType Password │ ├── ErrorTip 错误提示 Text默认隐藏 │ ├── LoginButton 登录按钮 │ └── BottomLinks 底部 注册 / 忘记密码 链接区 └── LoadingMask 全屏半透明遮罩 转圈动画默认隐藏这个层级有几个设计上的讲究。第一ContentPanel 用 VerticalLayoutGroup这样当 ErrorTip 显示或隐藏时下边的按钮和链接能自动重新排列省去了手动调坐标的麻烦。第二ErrorTip 和 LoadingMask 默认隐藏它们的显示切换成本是 SetActive 的开销但这是低频操作影响可以忽略。第三整个登录页只有一个 Canvas没有嵌套 Canvas。嵌套 Canvas 会把渲染拆成多批虽然某些场景有其必要性但登录页这种高度简单的界面完全不需要多一个 Canvas 就多一份重建的开支。组建挂载的顺序我很有心得。我在 LoginView.cs 上用 [SerializeField] 在 Inspector 里拖引用拿控件而不是在 Awake 里 GetComponent。为什么两个原因。第一Inspector 拖引用在编辑器下就能发现引用失效如果你把节点删了或者改名了Inspector 的引用会变成 Missing一眼就能看出来而运行时 GetComponent 要等运行到那一帧才报错甚至不报错只是静默给个 null。第二GetComponent 依赖节点路径和命名规则美术同学改一个节点名你的代码就崩了而拖引用只依赖对象本身不管它叫什么、在哪个位置只要能拖进来就行。3.3 数据绑定与界面刷新的实现方式MVP 模式下 View 的界面更新完全由 Presenter 驱动。我在 LoginView 里实现了 ILoginView 接口接口方法就是 Presenter 更新界面的唯一入口不允许存在第二条路径。SetLoading(bool isLoading) 的实现isLoading 为 true 时显示 LoadingMask把登录按钮的 interactable 置为 false防止用户在网络请求期间重复点击isLoading 为 false 时恢复按钮状态、隐藏 LoadingMask。LoadingMask 的显隐我用了一个 CanvasGroup 加淡入淡出的协程效果更柔和比直接 SetActive 的跳变体验好很多。SetError(string message) 的实现里隐藏了一些体验细节错误提示出现时我会把错误文本赋值到 ErrorTip然后调用 ErrorTip 的 GameObject 的 SetActive(true)。同时把用户名输入框或者密码输入框的文本全选一下方便用户直接修改。这几个体验细节全都放在 View 层Presenter 根本不知道也不关心错误是怎么展示的——它只做了要把这条错误告诉用户的决策。输入框的文本监听用 InputField.onValueChanged用户在输入框里每敲一个字LoginView 都会收到通知。但注意LoginView 收到通知后不会自己做任何输入校验只是把最新的用户名和密码透传给 Presenter。校验逻辑统一放 Presenter比如用户名不能为空密码长度必须大于等于 6 位密码不能包含空格。这样设计的动机很明确如果以后登录页从 UGUI 换成 H5 或者其他方案校验逻辑可以原封不动复用不会因为界面技术栈切换而重写一遍业务规则。关于 InputField 还有一个隐藏很深的坑当你给 InputField.text 赋值时比如从存档里自动填充用户名赋值后输入框的文本不会立刻刷新视觉呈现特别是密码框。解决方法是赋值之后手动调用一次 inputField.ForceLabelUpdate()。这个 API 在 UGUI 的 InputField 源码里是个 public 方法但文档基本没提过我是翻源码找校验问题的时候看见的。这也算是我这次实践的额外收获之一——UGUI 源码在 GitHub 上是公开的遇到问题的时候真的应该直接去读源码比在论坛上盲搜效率高得多。4. 测试替身没有后端也能完整验证登录4.1 测试替身的四种基本形态测试替身Test Double这个词来自 Gerard Meszaros 的《xUnit Test Patterns》泛指在测试中用来替代真实依赖的对象。很多人一提到测试替身就想到 Mock其实替身有四种形态它们各有各的适用场景Dummy只是为了能通过编译、填满参数列表而存在的对象方法体全空不会被真正调用。比如 ILoginView 的空实现登录用例里只需要它能传进构造函数。Stub为测试提供预设的返回数据或行为。比如一个 ILoginService 的 StubLogin 方法被调用后总是回调登录成功。Fake有一个能用的简化实现但不是生产代码。比如一个 FakeLoginService用硬编码的用户名密码做验证验证通过就返回成功。Mock记录调用行为测试跑完以后去断言这个方法被调了几次参数是什么。比如一个 RecordingLoginView把 SetLoading 的每一次调用都记下来最后断言 loading 被正确打开和关闭。这四种形态不是互斥的同一个对象可以既是 Stub 又是 Mock取决于测试里怎么定义它。但有一条核心原则必须坚持测试里不要用真实依赖真实网络、真实数据库、真实 UI 事件。一旦用了真实依赖测试就变成了集成测试跑得慢、不稳定而且失败了你很难定位到底是哪一层出了问题。4.2 登录模块的 Fake 与 Stub 设计这次登录模块我一共做了三个测试替身。第一个是 FakeLoginService。它实现 ILoginService内部持有两个硬编码账号比如 admin/123456 和 test/test123。Login 方法判断传入的用户名密码是否匹配匹配就回调成功并设置 Token不匹配就回调失败并返回错误码用户名或密码错误。这个 Fake 的用途是跑接近真实的流程——它不是总是成功至少能模拟成功和失败两条主路径让 Presenter 的流程编排代码得到充分锻炼。第二个是 StubLoginService。它也实现 ILoginService但构造时需要注入一个预设的 LoginResult。比如我可以 new 一个总是返回网络超时的 Stub专门用来验证 UI 在超时场景下是否正确展示错误提示、是否正确恢复按钮状态。Stub 的价值在于确定性真实网络里你没法保证每一次超时都能稳定复现Stub 可以。有了它超时这个分支的代码可以百分之百被测试到。第三个是 RecordingLoginView。它实现 ILoginView把 SetLoading、SetError、OnLoginSucceed 的所有调用记录到一个 List 里。测试跑完后断言列表里的调用顺序是否符合预期。比如一次成功登录的流程正确的调用顺序应该是 SetLoading(true) → SetLoading(false) → OnLoginSucceed如果顺序不对说明流程编排有 bug。这个替身是行为验证的核心工具。这三个替身合起来基本能覆盖登录页的全部逻辑分支成功、失败、超时、防重复点击、按钮状态切换、错误提示展示。我需要的不是像外界想象的那样写一堆 Mock而是三个对象反复组合使用。4.3 自动化测试用例怎么搭Unity 的官方测试框架是 Unity Test FrameworkUTF支持 EditMode 测试和 PlayMode 测试。登录逻辑的单元测试放 EditMode 就够了因为 Presenter 和 Service 都是纯 C# 类不依赖场景和 UGUI 对象。下面是一个典型的测试用例[Test] public void Login_WrongPassword_ShouldShowError() { var service new FakeLoginService(); var view new RecordingLoginView(); var presenter new LoginPresenter(service, view); presenter.OnLoginClicked(admin, wrong); Assert.AreEqual(1, view.SetErrorCount); Assert.AreEqual(用户名或密码错误, view.LastError); Assert.IsFalse(view.IsLoading); }这个用例没有创建任何场景对象没有发起真实网络请求跑完也就几毫秒。我在项目里给登录模块写了大大小小 30 多个这样的用例覆盖了成功、失败、空参数、超时、重复点击、登出后再登录、token 失效等场景。每次改登录相关的代码跑一遍测试集回归成本从原来的手动起服务、开场景、点页面降到了三十秒之内。这个差距做过传统 UI 手测的人应该能体会到有多爽。PlayMode 测试我也补了一个端到端的集成用例启动真实场景、实例化登录面板、用代码给 InputField.text 赋值来模拟输入、通过执行按钮的 onClick 来模拟点击、然后断言 LoadingMask 的显隐状态是否按照预期切换。这类测试比较慢因为要加载完整场景所以我只在 CI 上跑本地开发环境主要依赖 EditMode 那一套秒级反馈的用例。这里有必要提一句 NUnit 的经典陷阱在 EditMode 测试里断言异步逻辑比如 Service 的 callback时要注意 callback 可能不是立即执行的需要用一个 ManualResetEvent 或者直接在 Fake 里同步调用 callback。我在这上面栽过一次测试明明逻辑没错但断言时回调还没被触发结果是假失败白白排查了半天。建议所有 Fake/Stub 在测试里都走同步回调的方式不要在测试里依赖真实协程或者异步线程。5. 权限边界解耦的最后一公里5.1 登录态与权限模型解耦做到前四节的程度UI 和逻辑已经分离得比较干净了但还有一个容易忽略、而且往往在后期才爆雷的问题权限边界。登录页看起来只做登录这一件事但它涉及的数据极其敏感用户名、密码、token、用户资料。如果 View 层能直接访问 Service 层的敏感方法比如改 token、读用户数据表那解耦就白做了。因为界面层的代码是需求变动最频繁的地方bug 密度最高如果这些 bug 能直接污染数据层后果不堪设想。我定义的权限模型分三层公开层Public任何人都能访问。比如用户名是否为空的校验方法、当前登录按钮是否可点击的查询状态。登录层Authenticated只有登录成功后才能访问。比如获取用户昵称、头像、修改密码。内部层Internal只有 Service 层自己的实现能访问。比如 token 的具体存储位置、用户数据的字段细节。在代码层面用接口来落实这个模型。ILoginService 只暴露登录、登出、是否已登录、获取 token这些公开能力——注意公开能力里我刻意不放设置 token这个写操作因为 token 的写入只应该发生在 Service 内部的登录成功回调里外部没有任何理由去改它。获取用户详情的接口放在独立的 IUserInfoService 里并且要求调用方必须通过一个已登录会话的上下文对象来访问。实际上就是一个门面加一层上下文校验public class UserSession { private string _token; private UserProfile _profile; public bool IsLoggedIn !string.IsNullOrEmpty(_token); public UserProfile GetProfile() { if (!IsLoggedIn) throw new NotLoggedInException(未登录状态下禁止访问用户资料); return _profile; } internal void UpdateSession(string token, UserProfile profile) { _token token; _profile profile; } }注意 UpdateSession 标记了 internal这意味着它只能在 Service 程序集内部被调用。View 层或者 Presenter 层的代码想强行调用编译期就会被拒。这个细节就是权限边界在代码层面的落地方式——不靠自觉、不靠注释约定靠语言本身的访问修饰符和程序集边界来保证。5.2 界面层能碰什么、不能碰什么具体到界面层View我定了几条硬性红线违反任何一条都算架构事故第一View 层永远不能持有 Service 层实现的引用。View 只能通过 Presenter 拿到结果数据至于这个数据是真是假、来自远端 API 还是本地缓存View 一概不关心、也一概不能关心。第二View 层不能直接读写 PlayerPrefs不能实例化 HttpClient 或者 UnityWebRequest 的请求类。数据持久化和网络请求是 Service 层的职责View 里出现任何存数据或发请求的代码都是架构违规。之所以这么定是因为一旦 UI 代码里出现了网络请求你就再也无法在无后端环境里测试 UI 了而且 UI 的频繁刷新会带来大量不可控的网络副作用。第三View 层不能自己 new Presenter。Presenter 的创建必须走框架的注入入口我在 FUI 里提供了一个简单的静态容器这样在测试环境里才能方便地把真实 Presenter 替换成带 Stub Service 的 Presenter。如果 View 自己 new那这条链路就断了。第四View 层不能调用任何 Service 层没有在接口中声明的方法。这条规则有点抽象落地方式是前面提到的程序集命名空间隔离View 程序集不引用 Service 程序集自然就调不到未声明的方法。强制引用关系由编译期保证不用人肉检查。这几条红线光靠团队纪律不够我写了一个简单的静态检查工具扫描 View 程序集里的类型引用列表只要发现引用了 Service 命名空间下的类型就输出一个 warning 并把注释里的违规原因显示出来。工具很小几十行代码但在 Code Review 之前能自动拦截掉大部分越界行为。5.3 边界规则落地代码层面的约束前面提到了程序集定义这其实是边界规则落地的最强保证。我把项目按层拆成三个 .asmdef 文件引用关系单向锁定FUI.View引用 FUI.Presenter以及 UnityEngine.UI 这些 UGUI 程序集FUI.Presenter引用 FUI.Service以及 UnityEngine.CoreModule 中的基础类型FUI.Service不引用任何上层程序集只引用基础框架库这个依赖图一旦建立Unity 的编译系统就会强制执行你在 FUI.View 里哪怕只是 using 了一下 FUI.Service 的命名空间编译直接报错。这比任何架构文档、任何 code review 规则都可靠因为它把架构约束嵌入了工具链本身。同时我遵循了接口隔离原则。每个层对外暴露的接口都极力做小只包含调用方真正需要的方法。为什么接口小很重要一是好替身——接口越小测试替身要实现的空方法就越少二是防越权——接口大了调用方就容易看到不该看的东西顺手调一个不该调的方法。ILoginService 里绝对不会出现 UpdateUserProfile 这种登录之外的能力要更新用户资料请通过 IUserInfoService 走鉴权流程。权限边界的另一个层面是 UI 交互层的权限控制。登录成功以后某些 UI 元素比如修改密码按钮只有在用户登录后才能显示某些操作比如查看个人中心在未登录时点击应该弹出登录引导。这些逻辑我放在一个 UIController 类里统一管理它的工作方式是订阅 UserSession 的状态变化事件按当前登录状态决定 UI 上哪些元素可见、哪些元素可交互。注意这个 UIController 并不知道为什么要显示这些按钮它只是一个纯粹的状态到表现的映射器。6. 踩坑记录与实操心得6.1 遇到的典型问题这次实践前后折腾了小半个月踩的坑不少挑几个有代表性的记录一下希望后来者能少走弯路。第一个坑是 InputField.ContentType 的问题。密码输入框在 UGUI 里要把 ContentType 设为 Password这样会把明文显示成星号。但如果你在代码里直接给 InputField.text 赋值比如自动填充用户上次记住的密码赋值之后输入框不会自动重新解析星号显示结果就会出现密码框里显示明文的诡异现象。解决办法是赋值之后手动调用 inputField.ForceLabelUpdate() 强制刷新一次标签显示。这个 API 在 UGUI 源码里是个 public 方法但文档里几乎查不到我是翻了 InputField 源码才发现的。第二个坑是事件总线的对象泄漏。如果 Presenter 订阅了事件总线但销毁时没有取消订阅事件源比如一个静态的 EventBus仍然持有 Presenter 的强引用整个对象树就泄漏了。在 Unity 里这个问题尤其隐蔽场景切走了你不会立刻看到崩溃内存慢慢涨直到哪天突然 OOM 或者卡顿排查起来特别费劲。我的应对方案是在 Presenter 基类里加一个统一的 OnDestroy 虚方法面板关闭时强制调用所有已注册的 Unsubscribe 操作。事件总线的 Subscribe 和 Unsubscribe 必须成对出现就像加锁和解锁一样这是一条硬性纪律。第三个坑是 ScrollRect 和 InputField 的拖拽冲突。登录页如果嵌在一个可滚动的 ScrollRect 里用户从输入框区域开始拖动时有时候会触发 ScrollRect 的滚动而不是输入框的点击或选区操作。这个问题排查了很久才发现解法倒不复杂给输入框所在的区域挂一个自定义的 DragHandler在 BeginDrag 时把 ScrollRect 的 vertical 属性暂时关闭EndDrag 时再恢复。这个小补丁后来被抽成了公共组件项目里所有 ScrollRect 内嵌输入框的场景都在复用。第四个坑是程序集重构带来的循环引用编译错误。我一开始把公共接口比如 ILoginService 放在了 FUI.Service 里后来发现 FUI.Presenter 引用了 ServiceService 如果也想引用某个公共工具类就会报循环引用。解决方式是新建了一个 FUI.Abstractions 程序集专门放跨层接口和公共 DTO让 Service、Presenter、View 都依赖它谁都不依赖具体的实现层。这个抽象层下沉的思路算是这次实践里结构上的一个重要修正。6.2 排查技巧与工具排查 UI 问题我有自己的一套路径按照优先级从高到低排列。首选工具是 Unity Profiler但要学会看。登录页最常见的问题是 UI 重建Canvas Rebuild过多。在 Profiler 的 CPU 视图中搜索 Canvas.SendWillRenderCanvases 或者 CanvasUpdateRegistry如果发现这一项的耗时占比很高说明界面上有大量 Graphic 在被频繁标记 dirty。逐个排查是不是有动画在每帧改颜色是不是有代码在 Update 里改 Text 内容是不是有控件尺寸在每帧变化找到之后改成只在状态真正变化时才标记 dirty的做法。其次是 UGUI 源码调试。UGUI 的开源代码在 GitHub 上是公开的我把它下载下来用 IDE 直接打开遇到问题就搜相关类的实现。比如之前遇到按钮点击没反应从 EventSystem 的源码里看到事件路由是先从 GraphicRaycaster 获取射线命中的 UI 元素然后从最上层往下分发事件。排查才发现按钮上方有一个透明 Image 把射线挡住了。这个经历给我一个教训UI 射线检测被遮挡永远是 UI 交互问题的第一嫌疑先看层级再看代码。最后分享一个我自己的 debug 小工具一个运行时 UI 层级查看器。用一个 OnGUI 面板在游戏运行时显示鼠标当前位置命中的所有 UI 控件的名字和完整层级路径。排查点到的东西不是预期控件这种问题非常高效。代码大概二十行只是遍历 GraphicRaycaster.Raycast 的结果然后 Debug 输出但真的是救命利器。6.3 对解耦这件事的重新认识实践做完我对解耦这个词有了新的理解。解耦本身不是目的而是手段。真实目标是把容易变化的部分和不容易变化的部分分开让团队可以独立修改、独立验证、独立部署。登录页这个实验让我验证了一条路径只要分层清晰、接口明确、权限边界可控哪怕是 UGUI 这种表现层感极强的技术栈也能写出干净、可测试的逻辑来。之前总觉得游戏 UI 特别难做自动化测试这次做完才发现难的不是技术是没把测试需要的后门提前设计进去——测试替身就是那个后门而解耦是打开后门的第一步。另外一点体会是关于度的把握。解耦不是越彻底越好。如果项目只有两三个人、界面只有四五个模块那过度设计比耦合更可怕——手写一堆接口、事件、程序集改一个小需求要动五个文件效率低到令人绝望。我个人的判断标准是当你开始频繁为改 UI 导致逻辑崩掉买单时才是引入这套分层结构的时机。换句话说解耦的收益来自变动频率高变动的模块才值得投入解耦成本长期稳定不变的模块强行拆层反而是自找麻烦。最后再分享一个小技巧如果你想在项目里实践这套思路建议从业务里挑一个最小的、高频变动的模块下手比如登录页、注册页、个人中心都行。不要一上来就重构整个 UI 系统那种大爆炸式的重构风险太高出了问题你根本分不清是架构的问题还是实现的问题。小步快跑用一个小模块先验证方案的可行性跑通了再逐步推广。我个人在实际操作中的体会是先用一个登录页把三层结构、事件总线、测试替身、程序集约束全部跑一遍等于把框架的完整能力预热了一次后面再接入第二个页面的时候基本就是复制粘贴的体力活了。 Unity UGUI登录页解耦实践：从MVP分层到测试替身
做 Unity 客户端的朋友应该都有这种体会UI 代码是项目里腐烂速度最快的部分没有之一。尤其是登录页这种看着简单、改起来要命的模块——今天加个按钮明天改个输入框校验后天又要接新的第三方登录渠道等项目经理过来跟你说我们要换个弹窗样式的时候你看着那几百行又臭又长的 LoginPanel.cs只想当场辞职。我接手过几个项目登录页基本都是单文件承载所有逻辑UI 操作、网络请求、数据存储全写在一起调试全靠打断点人肉定位测试更是无从谈起。这篇文章想聊的是我最近在 FUI 框架上做的一次展示层解耦实践拿一个最日常的登录页当试验田把 UGUI 的界面表现、测试替身的逻辑模拟、权限边界的层级管控全部串起来验证了一遍。整个过程踩了不少坑也沉淀了几个我觉得值得复用的设计思路。FUI 是我们内部基于 Unity UGUI 搭建的一套 UI 框架核心目标就是解决多端 UI 复用和界面逻辑混乱的问题。如果你也在做 Unity 项目架构梳理或者正在被 UI 代码的耦合问题折磨这篇文章应该能给你一些可以直接落地的参考。1. 项目背景为什么我要拿登录页开刀1.1 FUI 是什么为什么要拆先交代一下 FUI 的背景。FUI 取自 Flexible UI 的缩写是我们团队在 UGUI 之上封装的一层 UI 框架。它没有重复造轮子没有自己实现一套渲染层而是在 Canvas、RectTransform、Graphic 这些 UGUI 基础组件之上做了三件事界面生命周期的统一管理、界面资源的加载释放、以及界面逻辑的分层约束。说直白点FUI 就是给团队定了一套写 UI 的规矩谁违反了规矩代码 review 就会被拦下来。为什么要定规矩我先说一个特别典型的场景。项目早期为了快速出包登录页逻辑一般是这么写的LoginPanel.cs 里直接持有 Button、InputField、Text 的引用在 Start 里给按钮挂 onClick 监听监听方法里直接发 HTTP 请求回调回来以后直接改 Text 内容、切换面板显隐、把 token 塞进 PlayerPrefs。这套代码在最开始的时候跑得挺好毕竟需求就一条账号密码登录。但需求会变的。等产品说我们要支持手机验证码登录你发现得在 LoginPanel 里加一个模式切换等产品说微信授权也要上你发现得引第三方 SDK还得在按钮回调里嵌一套 SDK 的初始化流程等到产品说UI 要改一版布局大调整你面对的是一坨牵一发动全身的泥潭。UI 代码和业务代码像麻花一样缠在一起改任何一个按钮的显示逻辑都可能误伤到网络请求或数据存储。更痛苦的是你想在编辑器里单独验一下登录按钮的交互逻辑还得先把后端服务起起来否则根本走不通全流程。FUI 的解耦思路其实很朴素把登录页长什么样交给 View 层管把登录流程怎么走交给 Presenter 层管把账号怎么验证、token 怎么存交给 Service 层管。每一层只依赖自己上一层暴露的接口不依赖具体实现。这样登录页就变成一个随时可以替换的壳子内部逻辑完全独立——今天用 UGUI明天换 UIToolkit后天接个原生插件业务层代码一行都不用动。1.2 登录页作为验证场景的优势有人可能会问选登录页做验证是不是因为登录页简单恰恰相反登录页是麻雀虽小五脏俱全的典型。我把它拆开列了一遍一个标准登录页至少包含五类能力输入组件用户名输入框、密码输入框涉及 InputField 的文本校验、ContentType 设置、占位符切换交互组件登录按钮、注册入口、忘记密码入口涉及按钮的可交互状态管理、防重复点击状态反馈加载中转圈、登录成功跳转、登录失败错误提示涉及多状态切换的 UI 表现数据交互调登录接口、处理 token、保存登录态、恢复会话涉及网络层调用和数据持久化异常处理网络超时、参数错误、服务端错误码解析涉及各种边界情况的兜底这五类能力任何一个成熟的 UI 框架都必须正面回答。拿登录页来验证解耦方案等于用最小成本把框架的完整能力过了一遍而且登录页是每个项目从第一天就要写的界面不存在额外造模块的负担试错了也不心疼。我在这次实践里还加了一个附加目标让登录页在没有真实后端的情况下也能被完整地自动化测试。这个目标直接推动了测试替身这件事的落地后面我会详细讲。2. 整体设计与解耦思路2.1 分层架构从一坨到三件套这次登录页的解耦我最终采用的是 MVP 变体准确说是 View Presenter Service 的三层结构。为什么不直接上 MVVM老实讲Unity 里没有像 WPF 那样完善的数据绑定机制MVVM 要在 UGUI 上落地就得自己写 Binding还得依赖反射或者代码生成学习成本和维护成本都不低。MVP 的 Presenter 是纯 C# 类不依赖任何 UnityEngine 类型这就意味着单元测试可以直接跑在 EditMode 下秒级反馈。三层的职责划分如下View视图层只负责 UGUI 控件的组织和表现。持有控件引用、监听用户输入事件、把事件转发给 Presenter、响应 Presenter 的状态更新指令来修改界面。Presenter表现层负责登录流程的业务编排。监听 View 转发过来的事件调用 Service 的接口处理回调结果决定 UI 应该切到什么状态。Service服务层负责登录相关的数据能力。封装登录请求、token 存储、会话恢复对外只暴露接口不暴露实现细节。这里最关键的一点是依赖方向View 依赖 Presenter 的接口Presenter 依赖 Service 的接口Service 谁都不依赖。所有依赖都是面向抽象的具体实现类的实例化统一交给一个简单的工厂或者容器管理。这样在做测试的时候我们可以轻松地给 Service 换一个 Fake 实现给 View 换一个 Recording 实现从而实现任意层的独立验证。在项目结构上我按层拆了三个程序集Assembly DefinitionFUI.View、FUI.Presenter、FUI.Service。引用关系严格单向View 引用 PresenterPresenter 引用 ServiceService 不引用任何人。程序集是 Unity 编译期的硬约束如果有人在 View 层直接用了 Service 层的 namespace编译阶段就会报错。这比任何代码审查工具都刚性。2.2 接口先行登录模块的契约设计动手写代码之前我第一件事是定义接口。这一步非常关键因为接口就是契约契约定死了后面每一层的实现才能并行推进。登录模块我一共定义了三个接口分别对应三层// Service 层对外暴露的登录能力 public interface ILoginService { void Login(string username, string password, ActionLoginResult callback); void Logout(); bool IsLoggedIn { get; } string Token { get; } } // Presenter 层提供给 View 的流程控制方法 public interface ILoginPresenter { void OnLoginClicked(string username, string password); void OnRememberPasswordToggle(bool isOn); void OnDestroy(); } // View 层提供给 Presenter 的界面刷新方法 public interface ILoginView { void SetLoading(bool isLoading); void SetError(string message); void OnLoginSucceed(); }三个接口从三个方向把登录模块切开了。ILoginService 不包含任何 UI 相关的类型Login 的回调用 Action 而不是 UnityEvent这样 Service 层就不会被 UnityEngine 绑定EditMode 测试随便跑。ILoginPresenter 的方法参数是字符串而不是 UGUI 控件这样无论界面输入来自 InputField 还是原生输入框PresenterView 都能处理。ILoginView 的方法描述的是界面状态而不是具体操作这样 View 的实现可以自由决定状态切换的表现方式。顺便说一句LoginResult 这个返回值类型我是刻意做成一个不可变的 DTOData Transfer Object包含 Success、ErrorCode、ErrorMessage 字段。它既不是 Service 的内部类也不是 View 的私有类而是放在一个公共的 module 命名空间里。这个类型是层与层之间的通信语言必须稳定、简洁、不带任何一方的私货。2.3 事件驱动UI 与逻辑的通信协议三层之间的通信我没有采用直接调方法 回调的朴素方式而是引入了一个轻量级的事件总线。这个决定是从一次真实需求里得到的教训登录页的登录成功事件除了发请求的 Service 自己知道还可能有外部模块比如第三方授权回调、App 唤起参数解析也知道。如果都用直接的调用链事件来源一多依赖关系就会乱成一团。我实现的 IEventBus 很薄核心就三个方法Publish、Subscribe、Unsubscribe。底层用一个字典存委托列表不引第三方库代码量不超过五十行public sealed class EventBus : IEventBus { private readonly DictionaryType, Delegate _handlers new(); public void SubscribeT(ActionT handler) { if (_handlers.TryGetValue(typeof(T), out var existing)) _handlers[typeof(T)] Delegate.Combine(existing, handler); else _handlers[typeof(T)] handler; } public void UnsubscribeT(ActionT handler) { if (_handlers.TryGetValue(typeof(T), out var existing)) _handlers[typeof(T)] Delegate.Remove(existing, handler); } public void PublishT(T message) { if (_handlers.TryGetValue(typeof(T), out var existing)) (existing as ActionT)?.Invoke(message); } }登录模块里View 的按钮点击被包装成 LoginButtonClickedMessagePresenter 订阅这个消息来触发流程Service 登录完成以后 Publish 一个 LoginResultMessagePresenter 再订阅这个消息来更新 View。这套通信协议最大的好处测试替身可以只向总线发布一个假的登录成功消息就能从外部驱动 Presenter 的状态流转完全不需要真正点击 UI、不需要真实网络。事件总线本身成了测试的后门这是我做解耦之前没想到的额外红利。3. UGUI 登录页的具体实现3.1 从 UGUI 源码看 Canvas 与 RectTransform 的工作机制在动手搭界面之前我重新翻了一遍 UGUI 源码重点研究两个问题Canvas 的更新机制到底是怎么触发的RectTransform 的布局计算什么时候会失效。这俩问题直接决定了登录页在频繁切换状态的场景下会不会产生性能问题。UGUI 的渲染更新核心在 CanvasUpdateRegistry 这个类里。每个 GraphicImage、Text 这些只要调用了 SetVerticesDirty就会把自己注册进 CanvasUpdateRegistry等到 Canvas 的 willRenderCanvases 事件触发时统一执行 Rebuild。简单说UGUI 的网格重建是标记-延迟-批处理机制不是即时发生的。这意味着如果你在 Update 里每帧改一个 Text 的内容那个 Text 的网格就每帧被标记一次 dirty每帧重建一次顶点数据代价非常大。登录页最常见的问题就是 loading 动画里放了一个请稍候...的 Text然后代码每帧去改它的透明度或者位置结果整个 Canvas 每帧重建机型稍微差一点就开始掉帧。RectTransform 的问题更隐蔽我打赌很多人踩过但没意识到。RectTransform 的 anchorMin、anchorMax、sizeDelta、anchoredPosition 这些属性决定了它相对父节点的布局但当你连续修改多个属性时布局计算并不会立刻全部生效。比如你先改了 sizeDelta立刻读 rect.width读到的可能是旧值要等到下一帧的布局刷新之后才能拿到新值。这个布局延迟在动态创建控件、动态调整表单尺寸时非常容易踩坑。我之前遇到过一个 bug登录成功以后要展示一个用户协议弹窗弹窗宽度根据文本长度动态计算算出来的宽度总是偏小就是因为读 rect 读早了。实操中的应对方式有三条第一登录页里所有需要高频更新的控件尽量避开 SetVerticesDirty 的触发路径。比如 loading 转圈动画我自己写了一个旋转的 RectTransform 组件每帧只改 rotation 的 Z 值不触发任何 Graphic 的 dirty性能开销极小。第二输入框的校验反馈、错误提示这类频次低但需要醒目效果的内容用两个预设好的 GameObject 做显示隐藏切换需要显示错误时就 SetActive(true)不需要就 SetActive(false)而不是动态 new 一个 Text 再设一堆属性。第三如果需要同时改多个 RectTransform 属性改完之后调用一次 RectTransform.ForceUpdateRectTransforms(true) 强制刷新保证后续读取的值是准确的。3.2 登录页的层级结构与组件挂载具体到登录页的 UGUI 表现我搭了这样一棵层级树从外到内LoginPanel (Canvas 下的根节点挂 LoginView.cs) ├── Background 半透明底图纯展示用 ├── ContentPanel 表单容器挂 VerticalLayoutGroup 自动排列 │ ├── TitleText 标题 欢迎登录 │ ├── UsernameInput 输入框InputField Placeholder │ ├── PasswordInput 输入框ContentType Password │ ├── ErrorTip 错误提示 Text默认隐藏 │ ├── LoginButton 登录按钮 │ └── BottomLinks 底部 注册 / 忘记密码 链接区 └── LoadingMask 全屏半透明遮罩 转圈动画默认隐藏这个层级有几个设计上的讲究。第一ContentPanel 用 VerticalLayoutGroup这样当 ErrorTip 显示或隐藏时下边的按钮和链接能自动重新排列省去了手动调坐标的麻烦。第二ErrorTip 和 LoadingMask 默认隐藏它们的显示切换成本是 SetActive 的开销但这是低频操作影响可以忽略。第三整个登录页只有一个 Canvas没有嵌套 Canvas。嵌套 Canvas 会把渲染拆成多批虽然某些场景有其必要性但登录页这种高度简单的界面完全不需要多一个 Canvas 就多一份重建的开支。组建挂载的顺序我很有心得。我在 LoginView.cs 上用 [SerializeField] 在 Inspector 里拖引用拿控件而不是在 Awake 里 GetComponent。为什么两个原因。第一Inspector 拖引用在编辑器下就能发现引用失效如果你把节点删了或者改名了Inspector 的引用会变成 Missing一眼就能看出来而运行时 GetComponent 要等运行到那一帧才报错甚至不报错只是静默给个 null。第二GetComponent 依赖节点路径和命名规则美术同学改一个节点名你的代码就崩了而拖引用只依赖对象本身不管它叫什么、在哪个位置只要能拖进来就行。3.3 数据绑定与界面刷新的实现方式MVP 模式下 View 的界面更新完全由 Presenter 驱动。我在 LoginView 里实现了 ILoginView 接口接口方法就是 Presenter 更新界面的唯一入口不允许存在第二条路径。SetLoading(bool isLoading) 的实现isLoading 为 true 时显示 LoadingMask把登录按钮的 interactable 置为 false防止用户在网络请求期间重复点击isLoading 为 false 时恢复按钮状态、隐藏 LoadingMask。LoadingMask 的显隐我用了一个 CanvasGroup 加淡入淡出的协程效果更柔和比直接 SetActive 的跳变体验好很多。SetError(string message) 的实现里隐藏了一些体验细节错误提示出现时我会把错误文本赋值到 ErrorTip然后调用 ErrorTip 的 GameObject 的 SetActive(true)。同时把用户名输入框或者密码输入框的文本全选一下方便用户直接修改。这几个体验细节全都放在 View 层Presenter 根本不知道也不关心错误是怎么展示的——它只做了要把这条错误告诉用户的决策。输入框的文本监听用 InputField.onValueChanged用户在输入框里每敲一个字LoginView 都会收到通知。但注意LoginView 收到通知后不会自己做任何输入校验只是把最新的用户名和密码透传给 Presenter。校验逻辑统一放 Presenter比如用户名不能为空密码长度必须大于等于 6 位密码不能包含空格。这样设计的动机很明确如果以后登录页从 UGUI 换成 H5 或者其他方案校验逻辑可以原封不动复用不会因为界面技术栈切换而重写一遍业务规则。关于 InputField 还有一个隐藏很深的坑当你给 InputField.text 赋值时比如从存档里自动填充用户名赋值后输入框的文本不会立刻刷新视觉呈现特别是密码框。解决方法是赋值之后手动调用一次 inputField.ForceLabelUpdate()。这个 API 在 UGUI 的 InputField 源码里是个 public 方法但文档基本没提过我是翻源码找校验问题的时候看见的。这也算是我这次实践的额外收获之一——UGUI 源码在 GitHub 上是公开的遇到问题的时候真的应该直接去读源码比在论坛上盲搜效率高得多。4. 测试替身没有后端也能完整验证登录4.1 测试替身的四种基本形态测试替身Test Double这个词来自 Gerard Meszaros 的《xUnit Test Patterns》泛指在测试中用来替代真实依赖的对象。很多人一提到测试替身就想到 Mock其实替身有四种形态它们各有各的适用场景Dummy只是为了能通过编译、填满参数列表而存在的对象方法体全空不会被真正调用。比如 ILoginView 的空实现登录用例里只需要它能传进构造函数。Stub为测试提供预设的返回数据或行为。比如一个 ILoginService 的 StubLogin 方法被调用后总是回调登录成功。Fake有一个能用的简化实现但不是生产代码。比如一个 FakeLoginService用硬编码的用户名密码做验证验证通过就返回成功。Mock记录调用行为测试跑完以后去断言这个方法被调了几次参数是什么。比如一个 RecordingLoginView把 SetLoading 的每一次调用都记下来最后断言 loading 被正确打开和关闭。这四种形态不是互斥的同一个对象可以既是 Stub 又是 Mock取决于测试里怎么定义它。但有一条核心原则必须坚持测试里不要用真实依赖真实网络、真实数据库、真实 UI 事件。一旦用了真实依赖测试就变成了集成测试跑得慢、不稳定而且失败了你很难定位到底是哪一层出了问题。4.2 登录模块的 Fake 与 Stub 设计这次登录模块我一共做了三个测试替身。第一个是 FakeLoginService。它实现 ILoginService内部持有两个硬编码账号比如 admin/123456 和 test/test123。Login 方法判断传入的用户名密码是否匹配匹配就回调成功并设置 Token不匹配就回调失败并返回错误码用户名或密码错误。这个 Fake 的用途是跑接近真实的流程——它不是总是成功至少能模拟成功和失败两条主路径让 Presenter 的流程编排代码得到充分锻炼。第二个是 StubLoginService。它也实现 ILoginService但构造时需要注入一个预设的 LoginResult。比如我可以 new 一个总是返回网络超时的 Stub专门用来验证 UI 在超时场景下是否正确展示错误提示、是否正确恢复按钮状态。Stub 的价值在于确定性真实网络里你没法保证每一次超时都能稳定复现Stub 可以。有了它超时这个分支的代码可以百分之百被测试到。第三个是 RecordingLoginView。它实现 ILoginView把 SetLoading、SetError、OnLoginSucceed 的所有调用记录到一个 List 里。测试跑完后断言列表里的调用顺序是否符合预期。比如一次成功登录的流程正确的调用顺序应该是 SetLoading(true) → SetLoading(false) → OnLoginSucceed如果顺序不对说明流程编排有 bug。这个替身是行为验证的核心工具。这三个替身合起来基本能覆盖登录页的全部逻辑分支成功、失败、超时、防重复点击、按钮状态切换、错误提示展示。我需要的不是像外界想象的那样写一堆 Mock而是三个对象反复组合使用。4.3 自动化测试用例怎么搭Unity 的官方测试框架是 Unity Test FrameworkUTF支持 EditMode 测试和 PlayMode 测试。登录逻辑的单元测试放 EditMode 就够了因为 Presenter 和 Service 都是纯 C# 类不依赖场景和 UGUI 对象。下面是一个典型的测试用例[Test] public void Login_WrongPassword_ShouldShowError() { var service new FakeLoginService(); var view new RecordingLoginView(); var presenter new LoginPresenter(service, view); presenter.OnLoginClicked(admin, wrong); Assert.AreEqual(1, view.SetErrorCount); Assert.AreEqual(用户名或密码错误, view.LastError); Assert.IsFalse(view.IsLoading); }这个用例没有创建任何场景对象没有发起真实网络请求跑完也就几毫秒。我在项目里给登录模块写了大大小小 30 多个这样的用例覆盖了成功、失败、空参数、超时、重复点击、登出后再登录、token 失效等场景。每次改登录相关的代码跑一遍测试集回归成本从原来的手动起服务、开场景、点页面降到了三十秒之内。这个差距做过传统 UI 手测的人应该能体会到有多爽。PlayMode 测试我也补了一个端到端的集成用例启动真实场景、实例化登录面板、用代码给 InputField.text 赋值来模拟输入、通过执行按钮的 onClick 来模拟点击、然后断言 LoadingMask 的显隐状态是否按照预期切换。这类测试比较慢因为要加载完整场景所以我只在 CI 上跑本地开发环境主要依赖 EditMode 那一套秒级反馈的用例。这里有必要提一句 NUnit 的经典陷阱在 EditMode 测试里断言异步逻辑比如 Service 的 callback时要注意 callback 可能不是立即执行的需要用一个 ManualResetEvent 或者直接在 Fake 里同步调用 callback。我在这上面栽过一次测试明明逻辑没错但断言时回调还没被触发结果是假失败白白排查了半天。建议所有 Fake/Stub 在测试里都走同步回调的方式不要在测试里依赖真实协程或者异步线程。5. 权限边界解耦的最后一公里5.1 登录态与权限模型解耦做到前四节的程度UI 和逻辑已经分离得比较干净了但还有一个容易忽略、而且往往在后期才爆雷的问题权限边界。登录页看起来只做登录这一件事但它涉及的数据极其敏感用户名、密码、token、用户资料。如果 View 层能直接访问 Service 层的敏感方法比如改 token、读用户数据表那解耦就白做了。因为界面层的代码是需求变动最频繁的地方bug 密度最高如果这些 bug 能直接污染数据层后果不堪设想。我定义的权限模型分三层公开层Public任何人都能访问。比如用户名是否为空的校验方法、当前登录按钮是否可点击的查询状态。登录层Authenticated只有登录成功后才能访问。比如获取用户昵称、头像、修改密码。内部层Internal只有 Service 层自己的实现能访问。比如 token 的具体存储位置、用户数据的字段细节。在代码层面用接口来落实这个模型。ILoginService 只暴露登录、登出、是否已登录、获取 token这些公开能力——注意公开能力里我刻意不放设置 token这个写操作因为 token 的写入只应该发生在 Service 内部的登录成功回调里外部没有任何理由去改它。获取用户详情的接口放在独立的 IUserInfoService 里并且要求调用方必须通过一个已登录会话的上下文对象来访问。实际上就是一个门面加一层上下文校验public class UserSession { private string _token; private UserProfile _profile; public bool IsLoggedIn !string.IsNullOrEmpty(_token); public UserProfile GetProfile() { if (!IsLoggedIn) throw new NotLoggedInException(未登录状态下禁止访问用户资料); return _profile; } internal void UpdateSession(string token, UserProfile profile) { _token token; _profile profile; } }注意 UpdateSession 标记了 internal这意味着它只能在 Service 程序集内部被调用。View 层或者 Presenter 层的代码想强行调用编译期就会被拒。这个细节就是权限边界在代码层面的落地方式——不靠自觉、不靠注释约定靠语言本身的访问修饰符和程序集边界来保证。5.2 界面层能碰什么、不能碰什么具体到界面层View我定了几条硬性红线违反任何一条都算架构事故第一View 层永远不能持有 Service 层实现的引用。View 只能通过 Presenter 拿到结果数据至于这个数据是真是假、来自远端 API 还是本地缓存View 一概不关心、也一概不能关心。第二View 层不能直接读写 PlayerPrefs不能实例化 HttpClient 或者 UnityWebRequest 的请求类。数据持久化和网络请求是 Service 层的职责View 里出现任何存数据或发请求的代码都是架构违规。之所以这么定是因为一旦 UI 代码里出现了网络请求你就再也无法在无后端环境里测试 UI 了而且 UI 的频繁刷新会带来大量不可控的网络副作用。第三View 层不能自己 new Presenter。Presenter 的创建必须走框架的注入入口我在 FUI 里提供了一个简单的静态容器这样在测试环境里才能方便地把真实 Presenter 替换成带 Stub Service 的 Presenter。如果 View 自己 new那这条链路就断了。第四View 层不能调用任何 Service 层没有在接口中声明的方法。这条规则有点抽象落地方式是前面提到的程序集命名空间隔离View 程序集不引用 Service 程序集自然就调不到未声明的方法。强制引用关系由编译期保证不用人肉检查。这几条红线光靠团队纪律不够我写了一个简单的静态检查工具扫描 View 程序集里的类型引用列表只要发现引用了 Service 命名空间下的类型就输出一个 warning 并把注释里的违规原因显示出来。工具很小几十行代码但在 Code Review 之前能自动拦截掉大部分越界行为。5.3 边界规则落地代码层面的约束前面提到了程序集定义这其实是边界规则落地的最强保证。我把项目按层拆成三个 .asmdef 文件引用关系单向锁定FUI.View引用 FUI.Presenter以及 UnityEngine.UI 这些 UGUI 程序集FUI.Presenter引用 FUI.Service以及 UnityEngine.CoreModule 中的基础类型FUI.Service不引用任何上层程序集只引用基础框架库这个依赖图一旦建立Unity 的编译系统就会强制执行你在 FUI.View 里哪怕只是 using 了一下 FUI.Service 的命名空间编译直接报错。这比任何架构文档、任何 code review 规则都可靠因为它把架构约束嵌入了工具链本身。同时我遵循了接口隔离原则。每个层对外暴露的接口都极力做小只包含调用方真正需要的方法。为什么接口小很重要一是好替身——接口越小测试替身要实现的空方法就越少二是防越权——接口大了调用方就容易看到不该看的东西顺手调一个不该调的方法。ILoginService 里绝对不会出现 UpdateUserProfile 这种登录之外的能力要更新用户资料请通过 IUserInfoService 走鉴权流程。权限边界的另一个层面是 UI 交互层的权限控制。登录成功以后某些 UI 元素比如修改密码按钮只有在用户登录后才能显示某些操作比如查看个人中心在未登录时点击应该弹出登录引导。这些逻辑我放在一个 UIController 类里统一管理它的工作方式是订阅 UserSession 的状态变化事件按当前登录状态决定 UI 上哪些元素可见、哪些元素可交互。注意这个 UIController 并不知道为什么要显示这些按钮它只是一个纯粹的状态到表现的映射器。6. 踩坑记录与实操心得6.1 遇到的典型问题这次实践前后折腾了小半个月踩的坑不少挑几个有代表性的记录一下希望后来者能少走弯路。第一个坑是 InputField.ContentType 的问题。密码输入框在 UGUI 里要把 ContentType 设为 Password这样会把明文显示成星号。但如果你在代码里直接给 InputField.text 赋值比如自动填充用户上次记住的密码赋值之后输入框不会自动重新解析星号显示结果就会出现密码框里显示明文的诡异现象。解决办法是赋值之后手动调用 inputField.ForceLabelUpdate() 强制刷新一次标签显示。这个 API 在 UGUI 源码里是个 public 方法但文档里几乎查不到我是翻了 InputField 源码才发现的。第二个坑是事件总线的对象泄漏。如果 Presenter 订阅了事件总线但销毁时没有取消订阅事件源比如一个静态的 EventBus仍然持有 Presenter 的强引用整个对象树就泄漏了。在 Unity 里这个问题尤其隐蔽场景切走了你不会立刻看到崩溃内存慢慢涨直到哪天突然 OOM 或者卡顿排查起来特别费劲。我的应对方案是在 Presenter 基类里加一个统一的 OnDestroy 虚方法面板关闭时强制调用所有已注册的 Unsubscribe 操作。事件总线的 Subscribe 和 Unsubscribe 必须成对出现就像加锁和解锁一样这是一条硬性纪律。第三个坑是 ScrollRect 和 InputField 的拖拽冲突。登录页如果嵌在一个可滚动的 ScrollRect 里用户从输入框区域开始拖动时有时候会触发 ScrollRect 的滚动而不是输入框的点击或选区操作。这个问题排查了很久才发现解法倒不复杂给输入框所在的区域挂一个自定义的 DragHandler在 BeginDrag 时把 ScrollRect 的 vertical 属性暂时关闭EndDrag 时再恢复。这个小补丁后来被抽成了公共组件项目里所有 ScrollRect 内嵌输入框的场景都在复用。第四个坑是程序集重构带来的循环引用编译错误。我一开始把公共接口比如 ILoginService 放在了 FUI.Service 里后来发现 FUI.Presenter 引用了 ServiceService 如果也想引用某个公共工具类就会报循环引用。解决方式是新建了一个 FUI.Abstractions 程序集专门放跨层接口和公共 DTO让 Service、Presenter、View 都依赖它谁都不依赖具体的实现层。这个抽象层下沉的思路算是这次实践里结构上的一个重要修正。6.2 排查技巧与工具排查 UI 问题我有自己的一套路径按照优先级从高到低排列。首选工具是 Unity Profiler但要学会看。登录页最常见的问题是 UI 重建Canvas Rebuild过多。在 Profiler 的 CPU 视图中搜索 Canvas.SendWillRenderCanvases 或者 CanvasUpdateRegistry如果发现这一项的耗时占比很高说明界面上有大量 Graphic 在被频繁标记 dirty。逐个排查是不是有动画在每帧改颜色是不是有代码在 Update 里改 Text 内容是不是有控件尺寸在每帧变化找到之后改成只在状态真正变化时才标记 dirty的做法。其次是 UGUI 源码调试。UGUI 的开源代码在 GitHub 上是公开的我把它下载下来用 IDE 直接打开遇到问题就搜相关类的实现。比如之前遇到按钮点击没反应从 EventSystem 的源码里看到事件路由是先从 GraphicRaycaster 获取射线命中的 UI 元素然后从最上层往下分发事件。排查才发现按钮上方有一个透明 Image 把射线挡住了。这个经历给我一个教训UI 射线检测被遮挡永远是 UI 交互问题的第一嫌疑先看层级再看代码。最后分享一个我自己的 debug 小工具一个运行时 UI 层级查看器。用一个 OnGUI 面板在游戏运行时显示鼠标当前位置命中的所有 UI 控件的名字和完整层级路径。排查点到的东西不是预期控件这种问题非常高效。代码大概二十行只是遍历 GraphicRaycaster.Raycast 的结果然后 Debug 输出但真的是救命利器。6.3 对解耦这件事的重新认识实践做完我对解耦这个词有了新的理解。解耦本身不是目的而是手段。真实目标是把容易变化的部分和不容易变化的部分分开让团队可以独立修改、独立验证、独立部署。登录页这个实验让我验证了一条路径只要分层清晰、接口明确、权限边界可控哪怕是 UGUI 这种表现层感极强的技术栈也能写出干净、可测试的逻辑来。之前总觉得游戏 UI 特别难做自动化测试这次做完才发现难的不是技术是没把测试需要的后门提前设计进去——测试替身就是那个后门而解耦是打开后门的第一步。另外一点体会是关于度的把握。解耦不是越彻底越好。如果项目只有两三个人、界面只有四五个模块那过度设计比耦合更可怕——手写一堆接口、事件、程序集改一个小需求要动五个文件效率低到令人绝望。我个人的判断标准是当你开始频繁为改 UI 导致逻辑崩掉买单时才是引入这套分层结构的时机。换句话说解耦的收益来自变动频率高变动的模块才值得投入解耦成本长期稳定不变的模块强行拆层反而是自找麻烦。最后再分享一个小技巧如果你想在项目里实践这套思路建议从业务里挑一个最小的、高频变动的模块下手比如登录页、注册页、个人中心都行。不要一上来就重构整个 UI 系统那种大爆炸式的重构风险太高出了问题你根本分不清是架构的问题还是实现的问题。小步快跑用一个小模块先验证方案的可行性跑通了再逐步推广。我个人在实际操作中的体会是先用一个登录页把三层结构、事件总线、测试替身、程序集约束全部跑一遍等于把框架的完整能力预热了一次后面再接入第二个页面的时候基本就是复制粘贴的体力活了。