OpenGL上下文创建以及共享机制
在知识星球里面，有一个同学咨询纹理池是如何实现的。
关于纹理池的实现方案以及背后的原因、细节、技巧，只有长篇大论才足以论道，本文暂表不提。
针对问题本身，笔者发现这位同学对OpenGL中的共享资源存在误解，他认为OpenGL中可以共享FBO。
为了纠正错误，也为了让大家在使用OpenGL之前理清一些基本概念，笔者专门附上一篇旧文系统讲述上下文的创建及共享。
希望能够帮助到这个同学，同时我的回复也是抛砖引玉，如果各位看官有其他理解和一些自己的看法，欢迎交流。
以下是星球内的提问：
想问下纹理池是怎么实现的，纹理池里面缓存的是fbo吗？
下面是我的原文：
前文我们讲述了如何创建渲染窗口。看过的小伙伴们也知道OpenGL环境搭建除了创建渲染窗口，还有一个很重要的任务，那就是创建OpenGL上下文。
但我们想说的是，针对上下文，不是仅仅了解如何创建上下文就足够了，这还远远不够。
OpenGL中的上下文是一个使用非常复杂的基础概念，要运用好上下文，除了创建之外，围绕在多线程中的共享以及共享之后的上下文绑定，这些基础知识也必须了解。
我们将对上下文进行系统讲述。围绕着上下文，本文先会从上下文共享展开，这一节会告诉小伙伴们共享上下文的原因以及原理；接下来，我们会讲述如何创建上下文，并结合上文中渲染窗口的创建，让小伙伴学会完整搭建OpenGL开发环境；最后一节，我们会告诉小伙们绑定上下文的原理和规则。
一、共享
- 为什么共享上下文
上下文非常关键，也是学习OpenGL需要花力气理解的概念。上下文中存储了OpenGL所有的状态，这些状态在渲染命令触发之后会被GPU利用完成绘制。状态可以通过OpenGL API进行更新，这样可以让两次渲染动态呈现不同效果，大大拓展了渲染管线的灵活性。关于上下文，还有一个做OpenGL开发不可回避的特性，那就是它的线程相关。上下文被设计成线程相关是很自然的。
首当其中的原因就是状态的去中心化，方便管理。上下文中保存了绘制所需要的全部状态，如果不沿用去中心化理念设计成线程相关从而通过多线程分解这些状态，那么整个程序的所有状态就就会都保存在一个上下文中。这个上下文将是一个庞然大物，维护它需要关注数量繁多的状态，已经非常长难以管理。更加引入注意的是，这些状态会被持久化保存的特点导致每次绘制都需要对这些状态进行维护，这无疑会加深管理难度。可以说，没有线程相关，这些状态基本是无法维护的。
另外一个重要原因就是性能上的考虑。我们试想一下，如果只是一次简单的绘制，那么为了方便起见，我们确实可以在某个线程创建上下文，然后所有的OpenGL命令都放在这个线程执行。这好像逻辑上也是说的通的。可是现实往往不如人意，在实际开发中，这样简单的绘制仅仅是少数，更多时候，我们面临的绘制非常复杂，逻辑上的流程也十分冗繁，这时候性能问题就是我们不得不面对的一个问题。
一个典型的复杂绘制场景就是地图。为了快速完成地图更新，我们需要将地图的某些任务从主绘制线程中抽离出去，轻量化主绘制线程。这样，我们就需要另起线程去承载这些抽离出去的任务。这些任务能够被抽离出去的前提条件就是这个线程的数据可以和主绘制线程共享。
需要基于共享资源的思路进行流程优化或改造的业务很多，以小伙伴们熟悉的相机业务为例。相机一般会采集纹理，因此我们需要在采集线程中预备OpenGL环境。然而，在相机中OpenGL环境一般是由控件GLSurfaceView提供，GLSurfaceView的绘制线程是由自己创建的。无法共享资源的话，相机的开启就需要依赖GLSurfaceView控件初始化完成，并将GLSurfaceView创建的绘制线程作为采集线程。这显然会导致采集绘制线程任务过重以及相机打开速度偏慢（因为相机的开启需要串形化依赖控件的初始化了）。在相机的实际开发中，正因为有了上下文共享，这些问题也就不再困扰我们了。通过资源共享，采集线程和绘制线程能够访问同样的资源。它们的异步执行变为可能，相机首帧速度得到大大提升；同时，采集和绘制的线程分离也轻量化了采集线程和绘制线程的任务，对采集和绘制的各自的性能都有很大优化。
资源共享在性能上会带来如此大的优势，OpenGL的设计自然也不会忽视这一点。上下文的共享就是OpenGL中提供资源共享的方式。两个线程共享了上下文就能实现资源共享。它除了上面提到的是性能优化的有效途径，其实也是我们在OpenGL中减少资源占用的重要方式，例如一个线程复用另外一个线程的纹理就能减少内存使用。
- 共享哪些资源
在OpenGL上下文中，只有对象可以被共享。我们先介绍一下OpenGL中的对象。
- 只有对象可被共享
从API形态我们可以知道，OpenGL库是基于C语言实现的。这导致它的语言结构不易被翻译成其他高级语言。为了解决这个问题，OpenGL引入了一些抽象层，对象就是其中一个。
在OpenGL中，一个对象是指一些选项的集合，它代表OpenGL状态的一个子集。比如，我们可以用一个对象来代表图像数据，之后我们就可以设置它的格式、采样方式等等。对象可以看作一个C风格的结构体：
struct object_name {
GLfloat option1;
GLuint option2;
GLchar[] name;
};
浏览全文可以加入知识星球，学习交流更多内容!!!
