为什么要把多张图片拼成一张纹理页？
《加载多个尺寸不一致的贴图时， 显存会出现碎片空间》
《贴图单元数量是有限的》
假设最坏情况只支持1个贴图单元，这时候你有一个2D角色的两个对象实例，分别处于不同的动作帧，如果没有合并贴图把同一角色所有帧都合到一张贴图里，那么要绘制这两个对象就会提交两次贴图，如果是合并贴图就只需要提交一次，然后通过在shader里面取不同的坐标来获得对应动作的贴图。API 能能绑定的贴图数量是有限的，比如一次只能填 128 个坑。想切换贴图必须把原先占坑的贴图换出来，换坑是很耗费时间的操作（你得让之前坑里的把事情做完吧，等啊等），因此游戏中希望尽可能减少这类操作。怎么办呢？就是把不同的贴图合起来……等于是一个坑里占了好几张图片（稍微挤挤还是挤得下的），就不需要那么频繁得换贴图了。推广到一个游戏场景，有各种特效和角色，尽可能合并贴图带来的好处就是执行效率的提升。比如显卡支持10个贴图单元，那么你可以尽量把当前场景用到的各种贴图提交上去，然后把对象的顶点信息一次性提交上去，最好情况是只要一次贴图提交和一次draw call。更极端点，你的场景对象没有变化的情况下，之后的所有帧，你都不用重新提交贴图了，只需要每帧提交对象的顶点信息就可以了。
《要求纹理尺寸必须是2的整次幂》
在openGL ES 1.0的时代，要求贴图的尺寸都必须是2的整次幂，所以即使是一个513x513的图片，也会创建一张1024x1024的贴图。如果游戏的图片比较多的话，这个浪费的内存还是相当可观的。于是出现了一种技术，就是把多个不同给的小图片整合到一张大的2的整次幂的图片中，这样有几个好处，一个是节省了很多内存，一个是免去了很多的文件操作次数。
《文件数量多管理成本高、读取速度慢、接口占用多》
站在游戏开发者的角度，资源贴图的数量跟着游戏规模几何上升。如果一张图一个文件的话，海量的文件会让你欲仙欲死。且不说读取大量小图片文件的速度远远比不上读取单个大图片文件，更不要说编辑起来也很麻烦了。从代码角度，在D3D11中，维护一张纹理图片，需要一个ID3D11ShaderResourceView接口。如果用多个文件，那么每个文件都需要一个接口来维护。对程序来讲也是个不小的负担。而且，图形引擎本身就支持裁切纹理操作，合理使用纹理坐标，就可以从一大张图上裁剪下任何一个矩形区域的小图。这样做的效率也是很高的。
对于某些2D游戏而言，人物动画帧如果分开的话，需要一幅幅载入，耗时且占内存，不方便管理和调用。如果把它们做成一副图片，帧与帧之间等距离的话，一次只需载入一次，而且播放到第几帧，就直接把显示区域往后挪第几块，方便快捷。
《UI都是预先合图》
可以将UI按场景分类然后提前合在一张纹理上。这样场景UI在同一纹理不管层次如何都可以一次提交到显存。减少Drawcall来优化性能。甚至有些UI设计师风格统一，一二三级窗口都是九宫格等，一张大纹理基本能摆下所有的UI。免去了多个小图片的I/O以及解码，在loading时期就加载完毕，大大解决游戏中打开窗口时因为图片加载解码产生的卡顿。重要的是所有UI一个批次就可绘制完成。
《小图片占用空间更大》
因为存储管理的最小单位是“簇”，小于一簇的数据也会占用一簇，所以细碎的图片在储存上也会比合在一起的整图大，不管存储是在硬盘中还是显存中。