上周我把手头这个 TestChannel 类彻底拆了一遍。这个类负责产测设备的通信通道撑着硬件交互、数据采集、状态管理和事件通知四摊事最夸张的时候有2300多行。前脚刚改完串口波特率后脚状态机就跟着跳错事件通知又把界面刷得乱跳。拆之前我忍了很久直到某次现场反馈“设备明明连着UI 却显示离线”我才下决心动手。这次重构用了两个核心手段模块化设计和异步编程。把代码拆分到独立文件后每个文件只干一件事采集链路用 async/await 串起来终于不再是牵一发而动全身的“上帝类”。如果你手上也有一个跑了好几年、什么功能都往里塞的老类这次拆解的思路和踩坑记录应该能给你一些参考。1. 先说说我为什么一定要动这个类1.1 两千多行一个类改动像走钢丝TestChannel 原本不是没写过注释而是注释已经救不了一个结构失控的类。类里的字段、方法、回调之间互相引用硬件收包后直接改状态状态变更又触发事件事件处理函数里又回头调用硬件发指令。光串口数据接收这一个地方就牵扯了缓冲管理、粘包分包、校验、状态迁移、UI 通知五层逻辑。我试过一次小改动把一帧数据里的温度字段从 int 改成 double结果解析方法变了一个返回值后续三个状态分支全部要跟着调整光梳理调用链就花了半天。这种“上帝类”最大的问题是职责没有边界。表面看是一个类实际是四五个模块强行塞在一个文件里。硬件交互是 IO 密集数据采集是算法逻辑状态管理是业务规则事件通知是外部接口它们的变更频率和失败模式完全不同。硬把它们放在一起意味着任何一处改动都可能导致另外三处出问题。我们团队后来统计过这个文件的历史 Bug 里有将近一半是“改 A 坏 B”根因就是耦合太深。1.2 为什么不重写而选择拆文件重构我也想过推倒重写。但仔细评估后放弃了原因很现实这套代码已经在产线上跑了两年很多边界行为是现场问题逼出来的比如某些老设备握手时多回一个字节某些采集卡在断线后要等三秒才报错。重写等于把这些隐含行为全部丢掉回归测试成本极高。拆分重构则可以保留已验证的逻辑只调整代码边界每拆完一个模块就编译跑一次现有测试风险可控得多。所以我给自己定了三条原则第一拆分后的每个文件只承担一种职责第二模块之间只能通过接口交流不能直接 new 来 new 去第三所有异步边界必须显式标注谁启动后台任务谁负责取消必须清楚。后文我会具体展开这三条是怎么落地的。2. 模块化拆分先画边界再动手2.1 四层职责一个门面动刀之前我先把原类里的字段和方法全部列出来按依赖关系归类结果非常清晰硬件操作类代码是一组数据解析与组帧是一组运行状态与模式切换是一组对外通知回调是一组。于是我把它们拆成四个独立模块同时保留一个 TestChannel 门面类作为对外的统一入口。模块文件职责提供的主要能力IHardwarePort.cs/SerialPortHardware.cs硬件交互与串口/网口设备建立连接读写原始字节流DataCollector.cs数据采集读取字节流完成粘包处理、校验、组帧产出数据包ChannelStateMachine.cs状态管理维护连接、就绪、采集中、故障等状态执行状态迁移规则ChannelEventBus.cs事件通知统一管理订阅者发布采集完成、状态变化、异常等事件TestChannel.cs门面聚合组装以上模块对外提供 Start/Stop/Connect 等入口方法拆的时候我一直在提醒自己文件数量不是目的依赖方向才是。门面类只做组装不写业务采集模块只依赖硬件接口不感知具体设备状态模块不直接碰串口事件模块更不反向去操作采集逻辑。这样无论后续换硬件、改协议、加状态影响面都控制在单个文件里。2.2 接口先定下来实现随后跟模块化设计里最容易翻车的点是先写实现类再回头抽接口。因为实现类之间很容易互相引用抽出来的接口全是妥协依赖关系依然混乱。我这次反过来先定义交互接口再把原代码里的具体逻辑迁移到接口实现类里。硬件交互层的接口长这样public interface IHardwarePort : IAsyncDisposable { ValueTaskint ReadAsync(Memorybyte buffer, CancellationToken cancellationToken); ValueTask WriteAsync(ReadOnlyMemorybyte data, CancellationToken cancellationToken); ValueTask ConnectAsync(CancellationToken cancellationToken); }采集模块依赖的是IHardwarePort而不是SerialPortHardware。好处是写单元测试时可以 mock 出一个内存端口想回什么字节就回什么字节不用真的接设备。后面给采集逻辑单测时这个方法帮了大忙很多以前没法覆盖的异常分支都能直接模拟。2.3 目录结构与文件划分实际拆分后的目录是这样Channel/ ├── TestChannel.cs // 门面生命周期管理与模块组装 ├── Hardware/ │ ├── IHardwarePort.cs │ └── SerialPortHardware.cs ├── Collector/ │ ├── DataCollector.cs │ └── DataBatch.cs ├── State/ │ ├── ChannelState.cs │ └── ChannelStateMachine.cs └── Event/ ├── ChannelEventBus.cs └── ChannelEventArgs.cs每个文件行数被控制在 300 行以内注释覆盖到“为什么这么做”的层面。比如IHardwarePort的ReadAsync注释里特别写了一句调用方必须处理返回 0 的情况这表示对端已关闭连接避免有人把死循环写成无限空转。这类注释在原来的巨型类里根本写不出来因为逻辑散落在四个回调里注释写哪儿都别扭。3. 异步编程让阻塞调用不再卡住整条链路3.1 同步改异步先找准阻塞点原代码不是没有多线程而是用了非常原始的SerialPort.DataReceived事件加Thread.Sleep轮询。硬件读取是同步的一次Read可能要等几十毫秒期间线程被白白占住采集线程一边读数据一边还要处理 UI 刷新一旦数据量大整个通道的响应直接变慢。异步改造不是把每个方法都加上async那样只会制造一堆无意义的线程切换。真正的切入点是 IO 边界和事件通知两个地方。IO 读取用ValueTask返回等待期间不占线程事件发布用异步处理方法避免一个慢订阅者拖慢整个采集循环。这样做的结果非常明显原来一个数据包从硬件到达 UI 要经过三个线程切换现在采集线程读完直接入队消费者异步批量处理UI 拿到的延迟反而更稳定。3.2 用 Channel 做生产消费缓冲数据采集场景里最典型的模式是“生产者-消费者”。硬件源源不断吐字节如果每次都立刻同步处理并通知 UI消费速度稍微慢一点背压就会直接打到硬件通信上甚至引发丢包。原来的做法是开一个Queue加锁满就丢数据没有任何背压策略现场经常抱怨采集数据偶发缺帧。这次我换成了 .NET 内置的System.Threading.Channels.ChannelT专门解决这类生产消费队列问题。它内部是无锁并发结构性能比手动lock高得多同时支持容量限制和背压策略。我创建了一个有界通道private readonly ChannelDataBatch _dataChannel Channel.CreateBoundedDataBatch( new BoundedChannelOptions(1024) { FullMode BoundedChannelFullMode.Wait });容量 1024 不是随便拍的。我算过现场实际数据采样频率 10Hz每包数据 4KB正常情况下每秒产生 10 个包即每秒 40KB。消费者批处理速度大约是每秒 500 包足够覆盖突发流量。1024 这个深度在内存占用上约等于 4MB完全可接受同时能在消费端短暂卡顿时缓冲约 100 秒的数据量。FullMode BoundedChannelFullMode.Wait是关键。它表示当队列满时生产者WriteAsync会主动等待而不是丢弃数据。这样就把背压反馈机制建立起来了消费变慢时采集循环自动放慢而不是默默丢数。以前我用过DropOldest表面上不阻塞但事后对账时发现丢包排查难度特别大。所以这里宁可使用 Wait 让生产端停下来也不允许数据悄悄消失。3.3 取消与生命周期管理异步重构还有一个容易忽略的点停止通道时如何优雅退出。原来的代码里有个Stop()方法只是把_isRunning设为 false但正在阻塞的Read根本不会退出线程就一直吊在那儿最终导致重新启动时状态错乱。新实现里我让StartAsync和StopAsync都接收CancellationToken。停止流程是先取消令牌然后调用_dataChannel.Writer.TryComplete()让消费者把队列里剩余的数据处理完再等待采集任务结束最后释放硬件资源。每一步都有超时保护避免某个硬件驱动不响应导致卡死。这个细节后来救了我一次——某台设备固件异常停止命令发出去后硬件没有任何回应原来的写法会直接卡死 UI现在能在 3 秒超时后强制结束并报出清晰错误。4. 核心代码实现与踩坑记录4.1 硬件交互层ReadAsync/WriteAsync 的封装硬件模块的核心是SerialPortHardware。它拿到SerialPort后用BaseStream.ReadAsync做真正的异步读写而不是依赖DataReceived事件。这是我总结出的第一个坑DataReceived事件在 .NET 里是在线程池回调上触发的而且不同版本、不同驱动下触发时机有细微差异用它做生产数据源很容易出现竞态。改用BaseStream.ReadAsync后所有读取行为都统一在一个循环里逻辑完全可控。public async ValueTaskint ReadAsync(Memorybyte buffer, CancellationToken cancellationToken) { try { return await _stream.ReadAsync(buffer, cancellationToken).ConfigureAwait(false); } catch (OperationCanceledException) { return 0; } catch (IOException ex) { RaiseError(ex); return 0; } }这里返回 0 表示没读到数据上层采集循环看到 0 后要再次等待或者判定为断开不能直接退出。断线检测的逻辑我放在状态机里硬件层只管数据读写和异常上报。这种单一职责让硬件替换变得轻松同一个IHardwarePort后来也实现了网络 Socket 版本采集层代码一行没改。4.2 数据采集层组帧、校验、入队数据采集是这次拆分收益最大的部分。原来读字节和解析帧混在一起改动一个解析规则就得把整个读取循环重新看一遍。现在DataCollector里只有一个后台任务职责非常纯粹从硬件接口读数据找帧头拼完整帧做校验封装成DataBatch写入通道。组帧时的粘包和半包问题是最常见的坑。我的做法是维护一个_buffer缓冲区每次ReadAsync返回的数据先追加到缓冲区然后循环检查里面是否有一个完整帧。找到完整帧就截取出来剩余数据保留如果缓冲区的数据不够一帧就继续等下一批。这个过程不能用简单的Array.Copy硬编码必须用可增长的缓冲结构否则遇到大帧就会越界。我在注释里明确画了两种包的拆分示意后续维护的人即使不懂协议也能照着边界处理。校验环节更值得细说。原代码在硬件接收线程里做校验校验失败的帧直接丢什么都不记。我重构后保留丢帧逻辑但额外发布一个FrameInvalidEvent带上原始长度和校验结果。这样现场再报“数据不对”时终于有了排查依据而不是两眼一抹黑。4.3 状态管理状态机独立成类状态管理原来的实现是几个bool字段拼出来的_isConnected、_isRunning、_isCollecting组合起来有 8 种状态但真正合法的只有 4 种其他组合全靠开发者自觉避免。这次我重构成一个标准状态机只允许显式迁移。public sealed class ChannelStateMachine { private readonly object _sync new object(); private ChannelState _currentState ChannelState.Disconnected; public ChannelState CurrentState { get { lock (_sync) return _currentState; } } public bool TryTransitTo(ChannelState target, out string reason) { lock (_sync) { if (!IsValidTransition(_currentState, target)) { reason ${_currentState} - {target} is invalid; return false; } _currentState target; reason string.Empty; return true; } } }状态迁移表被定义成一个二维数组IsValidTransition查表判断。比如只有Connected才能进入Collecting只有Collecting才能回到ReadyFaulted只能跳到Disconnected。非法迁移不再靠程序员自律而是代码层面直接拦住。事件通知模块会在状态变更时收到通知UI 那边永远只看到合法状态值不会出现“又连接又断开”的鬼畜界面。lock在这里是必要的因为状态可能在硬件事件线程、采集线程、外部控制线程三个地方被修改。有人可能想用volatile但状态迁移不是单字段读写它包含“检查目标态再赋值”的复合操作必须加锁保证原子性。这个我也在注释里写清楚了避免后来的人把lock当成性能瓶颈乱删。4.4 事件通知统一总线避免回调地狱旧的 TestChannel 对外公开了十多个委托属性UI 可以直接给某个事件赋值。表面看很灵活但实际使用中经常出现“在事件 A 里订阅事件 B又在事件 B 里调用事件 A”的循环触发。这次我把所有通知收拢到ChannelEventBus里对外只提供Subscribe和Publish两种操作。public sealed class ChannelEventBus { private readonly ConcurrentDictionaryType, ListDelegate _handlers new(); public IDisposable SubscribeTEvent(FuncTEvent, ValueTask handler) where TEvent : ChannelEventArgs { var type typeof(TEvent); var list _handlers.GetOrAdd(type, _ new ListDelegate()); lock (list) { list.Add(handler); } return new UnsubscribeToken(this, type, handler); } public async ValueTask PublishAsyncTEvent(TEvent eventArgs) where TEvent : ChannelEventArgs { var type typeof(TEvent); if (!_handlers.TryGetValue(type, out var list)) return; ListDelegate snapshot; lock (list) { snapshot new ListDelegate(list); } foreach (var handler in snapshot) { if (handler is FuncTEvent, ValueTask typedHandler) { await typedHandler(eventArgs); } } } }通过ConcurrentDictionary按事件类型存订阅者发布时只通知对应类型不再像以前那样把一堆事件桶全遍历一遍。Subscribe返回一个UnsubscribeToken让订阅方可以用语句块订阅、自动取消避免内存泄漏。这里有个细节为什么发布时要把订阅者列表先快照一份因为订阅/取消订阅和事件发布可能发生在不同线程直接遍历原列表会在某次快速刷新时抛“集合已修改”异常。快照虽然多了一点分配但换来了发布期间的稳定性实测在每秒 50 次事件、频繁订阅退订的场景下没有任何问题。4.5 常见问题与排查速查表重构不是一锤子买卖单元测试和现场验证阶段我排掉了不少问题整理成一张速查表常见问题可能原因解决思路UI 响应越来越慢消费端处理太慢队列塞满后生产者 Wait增加消费者数量或把事件处理拆成多个批次异步执行停止操作卡死超过 5 秒硬件ReadAsync没有遵守 CancellationToken给 StopAsync 加超时超时后强制释放硬件资源偶发数据丢帧校验失败或队列容量满后被丢弃事件总线上增加 InvalidFrameEvent统计丢帧原因状态显示异常外部直接改了状态字段没有走状态机状态字段改为只读所有状态变更必须调用 TryTransitTo事件重复触发订阅方法被注册多次没有正确退订使用 Subscribe 返回的 IDisposable声明周期结束即退订还有一个从实践中得来的避坑经验在异步方法里千万不要调用.Result或.Wait()去同步等待异步任务。一旦线程池资源不够就会出现死锁程序看起来像没响应实际是等待链被卡住。我在采集循环里吃过一次大亏排查很久才发现某个业务模块用eventTask.AsTask().GetAwaiter().GetResult()把异步事件同步化直接导致采集线程阻塞。统一改成await之后采集链路就再也没出现过这种问题。另外把ConfigureAwait(false)用在中间层代码里是个好习惯。采集模块不关心 UI 上下文继续等待时不需要强行回到主线程能减少上下文切换。但 UI 层的事件处理器不要用ConfigureAwait(false)否则会出现界面线程安全问题。这个边界我至少给三处代码写过注释后来同事接手时一眼就能看懂哪些方法能任意加await哪些必须回到 UI 线程。5. 重构后给我最大的几个改变这次重构之后TestChannel 从 2300 行变成了每个文件 200 到 300 行单个类一眼看得到全貌。最直观的好处是测试终于能写了。以前想测采集逻辑必须真接一台设备现在只要 mock 一个IHardwarePort喂它一段精心构造的字节流就能断言组帧、校验、状态迁移是否按预期执行。上周我新加的协议帧类型整个测试用例写下来不到半小时这在重构之前是不可想象的。更重要的改变是心态。以前只要产品经理说“加一个采集项”我的第一反应是“又要动那坨代码了别炸就行”。现在每个改动点都有明确归属改协议去采集层改状态规则去状态机改通知频率去事件总线。即使出了问题也从“四处翻代码”变成了“按模块定位”排查效率提升非常明显。如果你也想拆一个类似的“上帝类”我的建议很简单先别急着动文件把原类里的方法按依赖关系画一遍搞清楚谁调谁、谁该依赖谁再开始迁移代码。每次拆分提交都要保持能编译、能运行宁可拆慢一点也不要让中间态变成另一个维护噩梦。异步化同样如此先找出真正的 IO 阻塞点和共享状态边界改成 async/await 才有意义否则只是在代码里多撒了一堆Task.Run反而更乱。
