今天打算开始在博客园上，记录自己在开发小型软件的过程中，对于设计的一些思考。既算作一种分享，也是文字总结。

我打算编写一个渲染系统，当然开发已经进行了半年，成果多少是有。加载场景，灯光阴影等功能都具备。GUI，脚本等开发也十分顺利的进入尾声。但是就在最近，热切想实现的一个功能却成了阻碍，摆在我面前，如何实现资源异步加载。

目前项目使用OpenGL作为底层渲染接口，由于OpenGL的上下文是线程环境相关的，无法做到在渲染线程之外的线程中执行GPU资源加载。如果把资源加载的工作都放在渲染线程中，必然会出现渲染卡顿的缺点。

为解决上述问题，特做如下修改：

1、根据资源用于CPU或GPU，进行分类；

2、引入多线程的异步资源加载机制；

通过上述方案，系统除了拥有渲染主线程，还拥有异步加载CPU资源的其他线程。如此，多线程异步一定程度解决加载资源导致的卡顿问题，但是仍然无法避免加载GPU资源导致的卡顿。因为OpenGL限定了渲染和GPU资源加载必须在相同线程，所以GPU方面造成的卡顿无法避免，除非使用更加高级的底层渲染API，如Vulkan。

该方案的一个缺点是，异步加载的方式提高了编程的复杂性，例如，有时必须等多个CPU资源异步加载完成时，才会执行GPU资源的加载。那么就需要一个类似屏障的东西，来保证多个异步加载过程结束后，才发起GPU资源加载过程。于是，资源加载机制又发生了一次变动，即支持多线程环境下的多CPU资源加载与同步机制。相比之前的一个个CPU资源多线程加载，再异步呈递，现在的机制变成了多线程加载多个CPU资源，等待所有资源加载完成，才一同异步呈递给调用者。

这种机制在很多开源引擎框架中出现，例如Cocos。

 cc.assetManager.loadAny({'path': 'images/background'}, {'myParam': 'important'}, callback);