先说说需求场景，由于界面上可以显示n*n（n最大4）布局区域的图像序列，每个序列可能有上百张图像，首先肯定是把每个序列的第一张图像加载出来，剩下的image就慢慢整，所以需要做一个预加载的策略。
理一下思路
首先需要一个请求池，放所有准备加载的图像，然后在操作过程中肯定会带来一些顺序的变动（比如对第四个序列滚动到了第20张图像，那肯定这张图像就最优先加载）所以需要有权重。检查可能会切换，所以需要重置请求池的方法。还需要可配置并发数量，因为某些影像会很大，就一张一张加载比较高效。原本获取image的地方，都是调用 loadAndCacheImage 方法，现在要统一管理所有请求，需要改成调用loadAndCacheImagePlus。最后由于还有个进度条的功能（预加载的进度条，每个序列的缩略图上显示），所以成功后需要有回调，也放在配置里。所以需要提供 捋一下大概：
- 请求池（初始化、添加、重置、轮训、并发数）
- 权重（排序）
- 初始化的配置（并发数，成功的回调）
- 提供一个
loadAndCacheImagePlus方法来代替loadAndCacheImage获取图像数据
cornerstoneTools源码里有个 requestPoolManager 文件，看了一下就是请求池的管理，大体思路是一样的，不过它这儿没有真正的权重，它的权重是靠 loadImage 时的 priority 配置，去看了下具体的实现，这个权重是计算层面的，不是请求层面的，请求还是发出去了，所以不好直接使用人家的这个请求管理。
实现
请求池是一个大的概念，囊括了各种请求的统一调度，定义为TaskHelper 。目前这边只有图像的加载，所以再专门新建 cornerstone-image-request 来写图像请求的逻辑。
task-helper
1.请求池
taskPool存放请求，每个请求是一个对象，包含唯一标识的key、execute执行函数、priority权重等，execute执行函数需要是个promise，因为调用的地方需要等待请求池执行结果。
2.轮训
请求池需要有轮训机制，初始化后就开始轮训检查taskPool中是否有需要处理的请求，有的话就停止轮训，执行完剩余并发数量的请求，然后再重新开始轮训。
3.cachedTask
比如序列的第一张图像和它的缩略图都要加载，此时都在加载队列中等待，所以此时有两个promise在等待结果，所以需要一个对象来记录每个task的额外属性（比如subscribe、extra，以免新的task进来后丢失了原来的数据）
4.权重
轮训检测到有内容则开始执行executeTask，每次执行前先按权重排序，因为addTask时有可能会塞进来高权重的，就要在执行的时候换到前面来。
剩下的逻辑都比较清晰就不赘述了....（大体代码如下）
// task-helper.js
let taskPool = []; // 请求池
let numRequest = 0; // 正在执行数量
let maxRequest = 4; // 可配置
let taskTimer; // 轮训的定时器
let cachedTask = {}; // 存放的任务数据
// 预加载池的添加
function addTaskIntoPool(task) {
return new Promise((resolve, reject) => {
const cache = cachedTask[task.key];
const subscribe = (executeRes) => {
if (executeRes.success) {
resolve(executeRes.res)
} else {
reject(executeRes.err)
}
};
const priority = (task.priority || task.priority === 0) || 999;
if (cache) {
cache.priority = priority;
const callbacks = cache.callbacks || [];
callbacks.push(subscribe)
} else {
task.callbacks = [subscribe]
cachedTask[task.key] = task;
taskPool.push(task);
}
})
}
// 执行下载
function executeTask() {
if (taskPool.length > 0) {
sortTaskPool();
const executeRequest = maxRequest - numRequest;
if (executeRequest > 0) {
for ( let i = 0; i < executeRequest; i++ ) {
const task = taskPool.shift();
if (!task) {
return
}
numRequest++;
task.execute().then((res) => {
numRequest--;
task.callbacks && task.callbacks.map(callback => {
callback({success: true, res})
});
executeTask();
}, (err) => {
numRequest--;
task.callbacks && task.callbacks.map(callback => {
callback({success: false, err})
});
delete cachedTask[task.key];
executeTask();
})
}
}
} else {
startTaskTimer();
}
}
// 轮训检查请求池中是否有请求需要执行
function startTaskTimer() {
taskTimer = setInterval(() => {
if (taskPool.length > 0) {
stopTaskTimer();
executeTask();
}
}, 500)
}
// 停止轮训
function stopTaskTimer() {
clearInterval(taskTimer);
taskTimer = null;
}
....
2.cornerstone-image-request
拿到序列数据后调用初始化task-helper的请求池，携带什么额外的配置都是自由逻辑，对于task-helper来说都是黑的，比如下面的extra，就是希望在成功回调时知道这个图像是哪个序列的，方便做进度条。
import { addTaskIntoPool } from './task-helper';
function addTaskPool(series) {
lodash.forEach(series, (item) => {
if (item && item.imageIds) {
lodash.forEach(item.imageIds, (imageId) => {
const imageTask = buildImageRequestTask(imageId, {
extra: { series: item.seriesInstanceUID }
});
addTaskIntoPool(imageTask)
})
}
});
}
这儿主要的是提供 loadAndCacheImagePlus 方法出来，先看下cornerstone的imageCache中有没有，有的话直接用，没有就调用task-helper的 addTaskIntoPool 把任务添加到请求池中。
priority=999是因为这个方法是用来代替loadAndCacheImage的，调用这方法的地方都是要直接获取数据，所以优先级是最高的。
由于cornerstone.loadAndCacheImage是个promise，直接当做execute就执行了（虽然promise是pending），所以要再包一层，最终还是个promise就行。
function loadAndCacheImagePlus(imageId, priority = 999) {
return new Promise((resolve, reject) => {
const imageLoadObject = cornerstone.imageCache.getImageLoadObject(imageId);
if (imageLoadObject) {
imageLoadObject.promise.then((image) => {
resolve(image);
}, (err) => {
reject(err);
})
} else {
const imageTask = buildImageRequestTask(imageId, { priority })
addTaskIntoPool(imageTask).then((res) => {
resolve(res)
}).catch(e => {
reject(e)
})
}
});
}
function buildImageRequestTask(imageId, config = {}) {
return {
key: imageId,
...config,
execute: () => {
return cornerstone.loadAndCacheImage(imageId)
}
};
}
最后
简单的可控制的请求池就这样子了，可以满足我们目前的需求，需要改进的是错误的机制和重试机制，还有别的请求的兼容等，需要细细考虑完善。
