系统启动时，数据动态加载业务若干思考

当一个数据量比较大的系统，在启动时，如果采用静态加载的方式，消耗的时间让人抓狂，几分钟以上很正常。

举一个画面是三维的系统为例，在系统启动时，一个模型要显示在画面中，要做以下几方面工作：1.读取系统数据；2.跟据数据进行资源加载；3.把加载的画面显示出来；如果采用顺序加载方式，三个步骤挨个执行，当数据量较大时，用户需要等待几分钟才能进入到系统当中，造成极大的不便。

其中一种优化方式，是采用加载线程池的方法。

具体方法是系统启动后，创建一个线程池，池内比如有6个线程（线程池的度为6），那么可以同时处理6类模型的显示工作，配合资源的并发与同步，那么就实现了动态加载和显示，缩短了进入系统的等待时间，配和好资源加载优先级，那么用户的使用体验就得到了提高。

我觉得这种方法还有改进的地方，改进的方面主要从架构设计角度角度考虑。

6度的线程池，每一个度顺序完成1到3的工作，读取数据，进行加载，最后显示。我们假设现在有16个模型数据需要显示在画面中（实际情况是几万倍），每一步需要的时间是t ，那么最终这些模型显示出来的总时间是12/6×3t + 3t =8t。

如果将这1个6度的线程池，分为3个2度的线程池pool1,pool2,pool3，简称p1,p2,p3，p1负责执行数据读取，p2负责执行资源加载p3负责显示，那么原本3合1的一种作业类型，被拆分为3种作业类型，对应这3中业务需要。从设计角度讲，满足单一职责，降低耦合度，方便以后针对3种业务的升级改造，另外，当其中一个线程池空闲时，可以帮助处理其它业务作业，比如：开始时刻，6度全部用来读取数据，耗时1个t，6个数据读取进来以后，p2退出进行资源加载，p3与p1进行数据读取，当p2将资源加载进来后，p3退出读取数据，进行显示。也就是说，3个t 以后，3个线程池，回到了各自的本职工作。5t 的时候，p1结束读取，帮助p2进行加载，7t的时候，p1和p2结束记载，帮助p3进行显示，8t的时候全部工作结束。

消耗时间如下图：

时间效率上没有变化。

综上，从设计角度讲，改进方法似乎更优。