1. 从一次线上事故说起：为什么 FUI 资源接入需要 Provider 和 Lease
去年我们团队做了一款偏工具向的 Unity 应用，界面里嵌了一套 FUI（Flexible UI，这里泛指可动态加载、可复用的 UI 资源体系），资源来源既有本地 AssetBundle，也有运行时从远端拉取的图标和配置。上线第一周就炸了：用户快速切换页面时，前一个页面的异步加载回调把后一个页面的图标覆盖了；网络抖动导致同一个图标被重复请求了七八次；更离谱的是，有个页面已经关闭了，加载回调还在往一个已经销毁的 UI 节点上写数据，直接抛空引用。
这三个问题——取消、缓存、迟到结果——几乎是所有做 FUI 资源接入的人都会踩的坑。后来我们把整个资源接入层重构成了一套以Provider和Lease为核心的模型：Provider 负责“怎么拿到资源”，Lease 负责“谁在用这个资源、什么时候还回去”。这套模型落地之后，上面那三类问题基本绝迹，代码也从一堆散落的回调地狱变成了可读性很强的线性逻辑。
这篇内容就是把这套实战经验完整拆开讲。它适合正在做 Unity UI 资源管理、异步加载、对象池或者任何“异步拿资源 + 生命周期管理”场景的开发者。哪怕你用的是 C# 做上位机、做服务端，只要涉及异步资源的获取与释放，Provider/Lease 这套思路同样能直接迁移。我会从设计动机讲到具体实现，再到踩坑排查，尽量让你看完就能抄作业。
2. 核心设计思路：Provider 管“取”，Lease 管“用”
2.1 为什么不用简单的字典缓存
很多人第一反应是：缓存不就是个Dictionary<string, Asset>吗？加载前查一下，有就返回，没有就加载再塞进去。这个方案在“同步、单线程、资源永不释放”的理想世界里没问题，但现实是异步的、多并发的、资源需要释放的。
我举个具体的翻车场景。假设你用字典缓存，两个 UI 同时请求同一个图标 A：
- 页面 1 请求 A，字典里没有，发起异步加载。
- 页面 2 也请求 A，字典里还是没有（因为页面 1 的加载还没回来），于是又发起一次异步加载。
- 两次加载都回来了，字典被写了两次，实际加载了两份资源。
这就是重复请求。字典方案无法表达“正在加载中”这个中间状态。要解决它，你需要一个能记录“进行中的请求”的结构，这就是 Provider 的第一层价值。
再往下想，资源加载回来之后，谁来决定它什么时候可以被释放？如果页面 1 和页面 2 都在用 A，页面 1 关闭时把 A 释放了，页面 2 就崩了。所以你需要引用计数。而引用计数如果只是散落在各个调用点手动加减，迟早会漏加或漏减。Lease 就是把“引用计数”这件事封装成一个对象，谁持有 Lease，谁就占着一份引用，Lease 释放（Dispose）时自动减计数。
2.2 Provider 的职责边界
Provider 在我的设计里只做三件事：
- 去重：同一个 key 的并发请求，只真正加载一次，其他请求共享同一个结果。
- 缓存：加载完成的资源按 key 存起来，后续请求直接命中。
- 产出 Lease：每次请求返回一个 Lease，而不是直接返回资源本身。
注意最后一点很关键。如果 Provider 直接返回资源对象，调用方就没法参与生命周期管理了。返回 Lease 相当于说：“资源我给你用，但你要通过这个凭证来归还。”
Provider 内部通常维护两张表：一张是Dictionary<string, Task<Asset>>记录进行中的加载任务，一张是Dictionary<string, CacheEntry>记录已完成的缓存。CacheEntry 里包含资源本身和当前引用计数。
2.3 Lease 的职责边界
Lease 是一个轻量对象，它至少包含：
- 指向资源的引用（或访问器）
- 指向所属 Provider 和 key 的反向引用
- 一个
Dispose()方法，调用时通知 Provider 减引用计数
Lease 本身不负责加载，也不负责缓存，它只负责“我还在用”。这种职责分离带来的好处是：调用方只需要关心“拿到 Lease → 用 → Dispose”，完全不用管底层是缓存命中还是新加载。
提示：Lease 一定要实现
IDisposable，并且配合using语句使用。这是防止漏释放最有效的手段，比任何代码规范都管用。
2.4 取消与迟到结果的处理哲学
取消这件事，很多人理解成“中断加载”。但在 Unity 里，AssetBundle 的加载请求一旦发出，底层不一定支持真正的中断。所以更务实的做法是：不中断底层加载，但让结果作废。
具体来说，当调用方取消时，我们做两件事：一是把这次请求从“进行中”表里摘掉对应的等待者，二是标记这个等待者已失效。等底层加载真正回来时，检查等待者是否还有效，无效就直接丢弃结果（或者把资源放进缓存但不交付给任何人）。
迟到结果的处理同理。所谓迟到，就是调用方已经不需要了，结果才回来。判断“需不需要”的依据就是 Lease 是否已经被释放、或者请求是否已被取消。这套机制让整个系统对时序不敏感，无论回调什么时候来，都不会写坏数据。
3. 核心细节拆解：去重、缓存、引用计数怎么落地
3.1 并发去重的关键：Task 共享
去重的核心是让同一个 key 的多个请求共享同一个Task。在 C# 里，Task天然是可以被多个await的，这是实现去重最优雅的方式。
private readonly Dictionary<string, Task<Asset>> _inflight = new(); public async Task<Lease> AcquireAsync(string key, CancellationToken ct) { Task<Asset> task; lock (_inflight) { if (!_inflight.TryGetValue(key, out task)) { task = LoadInternalAsync(key); _inflight[key] = task; } } var asset = await task.WithCancellation(ct); return CreateLease(key, asset); }这里有几个细节值得说。第一，lock只保护字典的读写，不保护await，否则会死锁。第二，LoadInternalAsync内部加载完成后要把自己从_inflight移除并写入缓存，这个动作也要加锁。第三，WithCancellation是一个扩展方法，让await支持取消令牌，但注意它取消的是“等待”，不是“加载”本身。
我踩过的一个坑是：如果在lock块里直接await，在 UI 线程上会直接死锁。因为await之后的续体可能想回到主线程，而主线程正被lock占着。所以记住一条铁律：锁内不做异步等待。
3.2 缓存策略：什么时候该淘汰
缓存不是越多越好。FUI 资源里，图标、字体这类小资源可以常驻，但大图、整页 Prefab 如果一直缓存，内存会爆。我的做法是给 CacheEntry 加一个“弱引用 + 引用计数”的双重判断：
- 引用计数大于 0：绝对不能淘汰，有人在用。
- 引用计数等于 0：可以淘汰，但不必立刻淘汰，可以等内存压力或场景切换时统一清理。
具体实现上，我用一个LinkedList维护 LRU 顺序，引用计数归零时把 entry 移到链表尾部，需要腾内存时从头部开始淘汰。这里要注意，淘汰时要真正调用Resources.UnloadAsset或AssetBundle.Unload，否则只是从字典移除，内存还在。
注意：Unity 的
Resources.UnloadUnusedAssets是异步且开销大的，不要频繁调用。手动管理引用计数 + 精确卸载，比依赖它靠谱得多。
3.3 引用计数的加减时机
引用计数的加，发生在 Lease 创建时；减，发生在 Lease Dispose 时。听起来简单，但有两个边界要处理。
第一，重复 Dispose。如果调用方不小心 Dispose 了两次，计数会被减成负数。所以 Lease 内部要有一个_disposed标志，第二次 Dispose 直接返回。
第二，Provider 销毁时的清理。如果 Provider 本身被销毁了，所有还活着的 Lease 怎么办？我的做法是 Provider 持有一个所有活跃 Lease 的弱引用集合，销毁时遍历并强制失效。Lease 失效后再访问资源会抛异常，而不是返回一个已经被卸载的对象。
public void Dispose() { if (_disposed) return; _disposed = true; _provider.Release(_key, this); }3.4 迟到结果的判定逻辑
迟到结果的判定，我总结成一个简单的规则：结果回来时，检查这个请求对应的等待者是否还活着。
在实现上，每个请求会生成一个RequestHandle，里面有一个IsCancelled标志。当底层加载完成，先检查IsCancelled，如果为 true，就把资源放进缓存（因为可能别人还需要），但不创建 Lease 返回给已取消的调用方。
这里有个容易忽略的点：如果所有等待者都取消了，资源还要不要放进缓存？我的选择是放。因为加载已经发生了，成本已经付出，放进缓存下次还能用。但如果你做的是“取消即彻底放弃”的场景（比如用户明确点了取消下载），那就连缓存也不放，直接卸载。
4. 实操过程：从零搭一个可用的 Provider/Lease
4.1 定义核心接口
先把接口定清楚，后面实现才不会乱。
public interface IAssetProvider { Task<IAssetLease<T>> AcquireAsync<T>(string key, CancellationToken ct = default) where T : class; void Release(string key, IAssetLease lease); } public interface IAssetLease : IDisposable { bool IsValid { get; } }泛型版本IAssetLease<T>额外提供一个Asset属性返回具体资源。这样调用方拿到 Lease 后既能访问资源，又能管理生命周期。
4.2 实现加载任务与缓存条目
private class CacheEntry { public object Asset; public int RefCount; public LinkedListNode<string> LruNode; } private readonly Dictionary<string, CacheEntry> _cache = new(); private readonly Dictionary<string, Task<object>> _inflight = new(); private readonly LinkedList<string> _lru = new(); private readonly object _gate = new();_gate是统一的锁对象，所有对这三张表的操作都走它。用单一锁而不是多个锁，是为了避免锁顺序问题导致的死锁。性能上，资源加载本身是 IO 密集，锁竞争不是瓶颈。
4.3 完整的 Acquire 流程
public async Task<IAssetLease<T>> AcquireAsync<T>(string key, CancellationToken ct) where T : class { Task<object> task; lock (_gate) { if (_cache.TryGetValue(key, out var entry)) { entry.RefCount++; _lru.Remove(entry.LruNode); _lru.AddLast(entry.LruNode); return new AssetLease<T>(this, key, (T)entry.Asset); } if (!_inflight.TryGetValue(key, out task)) { task = LoadInternalAsync(key); _inflight[key] = task; } } object asset; try { asset = await task.WithCancellation(ct); } catch (OperationCanceledException) { throw; } lock (_gate) { if (!_cache.TryGetValue(key, out var entry)) { entry = new CacheEntry { Asset = asset, RefCount = 0 }; entry.LruNode = _lru.AddLast(key); _cache[key] = entry; } entry.RefCount++; return new AssetLease<T>(this, key, (T)asset); } }这段代码有几个关键点。第一，缓存命中时直接加计数返回，路径最短。第二，缓存未命中但已有进行中任务时，共享该任务。第三，await之后重新加锁检查缓存，因为可能在等待期间别的请求已经把资源写进缓存了，这时要复用而不是重复创建 entry。
4.4 Release 与淘汰
public void Release(string key, IAssetLease lease) { lock (_gate) { if (!_cache.TryGetValue(key, out var entry)) return; entry.RefCount--; if (entry.RefCount <= 0) { entry.RefCount = 0; _lru.Remove(entry.LruNode); _lru.AddFirst(entry.LruNode); } } }引用计数归零时把 entry 移到 LRU 头部（最久未使用端），等内存压力时从这里淘汰。淘汰逻辑单独写一个Trim(int maxCount)方法，遍历 LRU 头部，对 RefCount 为 0 的 entry 执行卸载。
4.5 取消令牌的正确接入
WithCancellation的实现要注意：它只影响等待，不影响底层任务。
public static async Task<T> WithCancellation<T>(this Task<T> task, CancellationToken ct) { if (!ct.CanBeCanceled) return await task; var tcs = new TaskCompletionSource<bool>(); using (ct.Register(s => ((TaskCompletionSource<bool>)s).TrySetResult(true), tcs)) { if (task != await Task.WhenAny(task, tcs.Task)) throw new OperationCanceledException(ct); } return await task; }这样当调用方取消时，await会立刻抛出OperationCanceledException，但底层的LoadInternalAsync还在跑，跑完后照常写缓存。这就是“取消等待但不取消加载”的实现。
5. 常见问题与排查技巧实录
5.1 问题速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 同一资源被加载多次 | 去重表未加锁或锁粒度不对 | 检查_inflight的读写是否都在锁内 |
| 资源被提前卸载导致空引用 | 引用计数减多了 | 检查 Lease 是否被重复 Dispose |
| 页面关闭后回调仍写数据 | 未检查 Lease 有效性 | 回调里先判断lease.IsValid |
| 内存持续增长不下降 | 淘汰逻辑未真正卸载 | 确认调用了 Unload 而非仅移除字典 |
| 取消后仍收到结果 | 取消只作用于等待 | 这是预期行为，需在业务层判断 |
| UI 线程死锁 | 锁内 await | 把所有 await 移到锁外 |
5.2 独家避坑技巧
技巧一：给 Lease 加一个调试用的创建堆栈。在编辑器下，创建 Lease 时记录StackTrace，Dispose 时清空。如果发现某个资源计数一直不归零，打印还活着的 Lease 的创建堆栈，一眼就能找到是谁忘了释放。这个技巧帮我定位过好几次“幽灵引用”。
技巧二：用ConditionalWeakTable关联 Lease 和业务对象。有时候你想知道“这个 Lease 是哪个 UI 页面持有的”，但又不想在 Lease 里塞业务字段。用ConditionalWeakTable做旁路关联，既不污染 Lease，又能在调试时查到归属。
技巧三：对高频小资源做“预加载 + 常驻”。图标这类资源，与其每次走完整的 Acquire/Release 流程，不如启动时预加载并持有一个永不释放的 Lease。这样运行时全是缓存命中，零开销。判断标准是：资源大小小于某个阈值且访问频率高。
技巧四：取消令牌要传递到业务层，而不是只传到 Provider。很多人只在 Acquire 时传了 token，但业务层拿到 Lease 后继续做异步操作时忘了传。结果 Provider 层的等待取消了，业务层的后续操作还在跑。正确做法是把 token 一路传下去，或者用 Lease 的有效性做二次判断。
5.3 一个真实的排查案例
有一次测试反馈：快速来回切换两个页面，偶尔会出现图标错乱。我第一反应是缓存串了 key，查了半天没发现问题。后来加日志发现，是页面 A 的加载回调在页面 B 已经显示后才回来，而回调里直接写了image.sprite = result，没有检查这个 image 是否还属于页面 A。
修复方式很简单：在回调里先判断if (!lease.IsValid) return;。因为页面 A 关闭时释放了 Lease，IsValid 变成 false，迟到结果自然被丢弃。这个问题让我深刻体会到：迟到结果的防护不能只做在 Provider 层，业务层的回调也必须自检。Provider 能保证不返回失效的 Lease，但没法阻止业务层拿着旧 Lease 继续操作。
6. 性能与扩展：让这套模型扛住真实项目
6.1 锁竞争的优化
前面用的是单一_gate锁。在绝大多数 UI 场景下够用，因为资源加载的瓶颈在 IO 不在锁。但如果你的项目有大量高频小资源请求（比如列表滚动时每帧请求几十个图标），锁竞争就会显现。
优化思路是分段锁：按 key 的哈希值分成 N 个桶，每个桶一把锁。这样不同 key 的请求互不阻塞。实现上把_cache、_inflight、_lru都拆成 N 份，按key.GetHashCode() % N选桶。代价是 LRU 的全局顺序变成了桶内顺序，淘汰时不够精确，但换来的是并发性能提升。
我实测下来，在 8 个桶的情况下，高频请求场景的吞吐能提升 3 倍左右。不过如果你的项目请求频率不高，别过早优化，单锁的可维护性更好。
6.2 与对象池的结合
FUI 里很多资源是 GameObject 预制体，加载出来还要 Instantiate。这时候 Provider 管的是“预制体资源”，对象池管的是“实例”。两者职责不同但可以协作：Provider 保证预制体只加载一份，对象池保证实例复用。
我的做法是 Provider 返回的 Lease 里同时持有预制体引用，业务层从对象池取实例时，把 Lease 一起传进去。实例归还对象池时，如果 Lease 也到期了，就一起释放。这样预制体的生命周期和实例的生命周期就绑定了，不会出现“实例还在但预制体被卸载”的崩溃。
6.3 跨场景的资源清理
场景切换是资源泄漏的高发期。我的策略是给每个 Lease 打一个“场景标签”，场景卸载时批量释放该场景的所有 Lease。实现上 Provider 维护一个Dictionary<string, HashSet<IAssetLease>>，按标签分组。场景卸载时遍历对应集合，逐个 Dispose。
这里要注意：跨场景常驻的资源（比如全局配置、通用图标）不要打场景标签，否则会被误释放。我一般用一个特殊的Persistent标签来标记它们，清理时跳过。
6.4 监控与埋点
上线后你总得知道缓存命中率、平均加载耗时、当前活跃 Lease 数这些指标。我在 Provider 里加了轻量的计数器，每 60 秒上报一次。命中率低于某个阈值就说明缓存策略有问题，活跃 Lease 数持续增长就说明有泄漏。
这些数据比任何日志都直观。有一次我们发现某个页面的活跃 Lease 数只增不减，顺着数据一查，果然是页面关闭时漏调了 Dispose。如果没有监控，这种泄漏可能要等到内存报警才被发现。
7. 写在最后的一点个人体会
这套 Provider/Lease 模型我从第一个版本到现在，前后重构了三次。第一次只做了去重，第二次加了引用计数，第三次才把取消和迟到结果处理干净。每次重构都是被线上问题逼出来的，所以我对每个设计点的必要性都有切身体会。
如果你现在正在做 FUI 资源接入，我的建议是：先把 Lease 的 Dispose 纪律建立起来，再谈缓存和去重。因为泄漏是最难排查的问题，而 Dispose 纪律是防泄漏的根本。等这套纪律稳定了，再去优化性能和扩展功能，顺序反了会很难受。
另外，别迷信“一套模型打天下”。Provider/Lease 适合“异步获取 + 生命周期管理”的场景，但如果你只是同步加载几个常驻资源，直接字典缓存就够了，上这套模型反而是过度设计。工具要匹配问题，而不是反过来。
