无论是 bundle 还是 assetManager 加载资源时，只要未完成之前，应该支持中途 cancel 加载，我不知道unity 支持与否。
因为这个太容易造成开发者疏忽大意，导致资源泄露，内存暴涨。
场景一：通常我们打开一个独立的UI，开发者通常会在打开时加载资源，关闭时释放资源。但是这个UI里，如有一个或多个资源仍在加载中，你以为你在关闭UI时，调用了 bundle.release(url-path)，但实际上这个 one-asset就在内存中了。
当然本来可以避免的，但是一般在开发代码时：一般会想到加载资源，释放资源的“正确”时机就是“用”和“不用”的时候，很少在开发时会想到还有一种情况是“想用时突然又不用了”的时机。
那如果，我们在关闭UI，也就是“不用”时，再调用一次 bundle.cancel(url-path)，那是不是很符合开发习惯的思维呢？
这里只是举例一个场景，后面有了再继续补充。
场景二…
场景二…
场景二…
我也提过类似需求了https://forum.cocos.org/t/topic/137819/4
bundle有很多该做的工作都没做。例如在load一个资源完成前，重复调用load，也会跑完整的加载流程，加载中的状态是不是应该记录下…
资源提供的addref和decref不是提供了缓存和释放的功能
拒收
而且有些问题一直没改
加载刚释放的资源，加载完成后的资源是已经被释放过的
加载两次同一资源，在第一次加载完成后修改引用计数，第二次加载完成返回资源对象的引用计数和第一次的对象不一致
问题我反馈过，但是他们没改
能用就行.
tnt 框架中对楼主所说的问题进行了处理，每个独立UI可以单独管理资源，当UI关闭后，如果有正在加载的资源，会在加载完成后自动释放。可以作为参考看一下。
AssetLoaderAssetLoader 资源的加载释放管理，每个模块或者每个界面都可以实例化一个加载器，在退出模块或者关闭界面的时候一次性释放所依赖的资源，而不影响其他模块或界面的相同依赖资源。
AssetLoader 的使用基本与 引擎 Bundle 加载资源的方法一致。
在本框架中，每个弹窗都持有了一个 加载器
this.loader，为当前弹窗加载资源时直接使用弹窗内置的加载器。
LoaderMgrLoaderMgr 加载器管理类，通过任意键值获取或实例化一个加载器
全局共享的
AssetLoader为tnt.loaderMgr.share，
如果想将一些资源常驻内存，可以使用tnt.loaderMgr.get("persist").load(...);，这里的"persist"为任意 key，只要不对"persist"这个加载器进行释放，里面加载的资源就会常驻于内存
如果想在任意位置访问场景持有的加载器，可以使用
tnt.loaderMgr.scene。
ResourcesMgrResourcesMgr 加载器的封装，相当于 LoaderMgr + AssetLoader 的结合，只是为了方便使用
…
…
是，第一点记忆犹深，以前趟过坑。加载过程中释放asset，load回调的asset是不能用的。
感觉bundle这个功能写的太不专业了，有一点经验的程序写异步加载，都会考虑到这些情况。
不太明白，加载完成，即使你的UI已经取消了，可是没有引用，不是会自动销毁吗
不太明白+1 加载资源为啥需要中途取消呢，加载后存在内存不就好了，引用计数是0，等回收时间到了检测没用到资源不就释放了么， 加载同一资源，只加载一分资源，但是把多个回调存进去不就可以了么，，，，
资源太多，没加载完又加载另外的，会卡
楼上那2位，大概连资源释放都没弄清楚了 
新增说明：
本回答无意义，也不想有意义
如果是我们没理解的话，可以说一下是什么问题，你这样回答是无意义的
你如果说是批量资源加载，并且还在待加载队列中的资源，那么取消加载没问题。如果你是指已经在加载中的资源，已经产生了实际上的字节流，那么取消资源加载，它的意义是什么，就事论事 你 一上来就这么不友好讨论
其实可以利用 cc.assetManager.downloader.register 方法改掉下载 ，在里面调用XMLHttpRequest 去请 求资源，然后 回传XMLHttpRequest你自己管理，需要时直接调用那个XMLHttpRequest对像的.abort()就 可以打断下载了，满足你想中途取消的需求
细说一下。