大图加载与分片：BitmapRegionDecoder分片加载、TiledBitmap、超大图内存管理、GPU上传优化

说实话，大图加载这个问题，几乎每个Android开发都会遇到。我记得刚入行那会儿，产品经理拿着一张8000x6000像素的景区导览图，说「就正常加载显示就行」。我心想这有什么难的？结果一加载，直接OOM，应用闪退。那场面，至今难忘。

后来我才明白，对于超大图，我们不能「一口吃成胖子」。得学会分片加载、分块管理、按需渲染。今天我就把这几年的实战经验，系统性地梳理一遍。

为什么超大图会撑爆内存？

先算一笔账。一张4000x3000像素的图片，如果使用ARGB_8888格式加载到内存，每个像素占4字节。那么占用的内存是：

4000 × 3000 × 4 = 48,000,000 字节 ≈ 45.8 MB

一张图就吃掉将近50MB。如果同时加载两三张，再加上其他业务内存，应用不崩才怪。你想想看，手机总共才多少内存可用？

为什么会这样？因为Bitmap在内存中是「解压后的原始像素数据」。它不像文件那样压缩着，而是每个像素都实实在在占着内存。所以，大图加载的核心思路就一个字——分。

BitmapRegionDecoder：分片加载的利器

我个人习惯用BitmapRegionDecoder来处理超大图。它允许我们只加载图片的某个矩形区域，而不是整张图。这在展示地图、长图、高清海报时特别有用。

基本用法如下：

// 从输入流创建RegionDecoder
InputStream is = getAssets().open("huge_map.jpg");
BitmapRegionDecoder decoder = BitmapRegionDecoder.newInstance(is, false);

// 获取图片实际宽高
int width = decoder.getWidth();
int height = decoder.getHeight();

// 定义要加载的区域（比如左上角1000x800区域）
Rect rect = new Rect(0, 0, 1000, 800);
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565; // 节省一半内存

// 只加载指定区域
Bitmap bitmap = decoder.decodeRegion(rect, options);
imageView.setImageBitmap(bitmap);

我在项目中遇到过一种情况：用户手指滑动时，需要实时加载新的可见区域。这时候不能每次都重新创建decoder，要复用。我一般把decoder做成单例，配合手势监听动态计算可见区域。

TiledBitmap：像地图一样分块加载

BitmapRegionDecoder虽然能加载局部，但每次滑动都重新解码，性能还是不够。更好的方案是TiledBitmap——把大图切成若干小块（Tile），只加载和渲染可见区域的Tile。

这个思路其实借鉴了地图SDK。Google Maps、高德地图都是这么干的。一张世界地图，不可能一次性加载所有瓦片，而是根据当前缩放级别和可视范围，动态加载需要的瓦片。

我实现过一个简单的TiledBitmap方案：

// 定义瓦片大小（通常256x256或512x512）
private static final int TILE_SIZE = 256;

// 计算瓦片数量
int tilesX = (int) Math.ceil((float) bitmapWidth / TILE_SIZE);
int tilesY = (int) Math.ceil((float) bitmapHeight / TILE_SIZE);

// 根据当前可见区域，计算需要加载的瓦片索引
int startTileX = visibleRect.left / TILE_SIZE;
int endTileX = (visibleRect.right + TILE_SIZE - 1) / TILE_SIZE;
int startTileY = visibleRect.top / TILE_SIZE;
int endTileY = (visibleRect.bottom + TILE_SIZE - 1) / TILE_SIZE;

// 只加载这些瓦片
for (int x = startTileX; x < endTileX; x++) {
    for (int y = startTileY; y < endTileY; y++) {
        loadTile(x, y); // 从磁盘或内存缓存中加载
    }
}

嗯，这里要注意：瓦片加载一定要做缓存。我一般用LruCache做内存缓存，用DiskLruCache做磁盘缓存。用户滑动时，优先从内存取，取不到再从磁盘取，最后才解码原图。

超大图内存管理：别让Bitmap成为内存杀手

讲完了分片加载，咱们聊聊内存管理。说白了，就是三个字——用多少，占多少。

我总结了几条实战原则：

• 按需采样：用inSampleSize对图片进行降采样。比如ImageView只有200x200，就没必要加载4000x3000的原图。采样到接近目标尺寸即可。
• 及时回收：不再显示的Bitmap，及时调用recycle()。特别是分片加载时，离开可视区域的瓦片Bitmap，要立即回收。
• 复用内存：使用inBitmap复用Bitmap内存。Android 3.0以后支持，能有效减少GC压力。
• 监控内存：用Profiler或LeakCanary监控Bitmap占用。我习惯在Debug模式下，把每个Tile的占用打印出来，方便排查。

// 复用Bitmap的示例
BitmapFactory.Options options = new BitmapFactory.Options();
options.inMutable = true;
options.inBitmap = reusableBitmap; // 之前回收的Bitmap对象

// 解码时，系统会尝试复用inBitmap的内存
Bitmap bitmap = BitmapFactory.decodeFile(path, options);

GPU上传优化：别让纹理上传卡了UI

最后聊聊GPU上传。Bitmap解码出来是在CPU内存里，要显示到屏幕上，得上传到GPU纹理。这个过程如果处理不好，会直接卡掉UI线程。

为什么会卡？因为纹理上传是同步操作。你调用canvas.drawBitmap()时，如果纹理还没上传，系统会先上传再绘制。一张大图上传可能耗时几十毫秒，UI线程就被阻塞了。

我建议的做法是：

• 异步上传：在子线程中提前把Bitmap上传为OpenGL纹理。用GLSurfaceView或TextureView配合HandlerThread来做。
• 分块上传：对于超大图，不要一次性上传整张纹理。而是把瓦片分别上传，每块纹理小，上传快。
• 纹理缓存：上传后的纹理ID要缓存起来。下次直接使用纹理ID绘制，不需要重新上传。

// 伪代码：异步上传纹理
HandlerThread uploadThread = new HandlerThread("TextureUpload");
uploadThread.start();
Handler uploadHandler = new Handler(uploadThread.getLooper());

uploadHandler.post(() -> {
    int[] textureIds = new int[1];
    glGenTextures(1, textureIds, 0);
    glBindTexture(GL_TEXTURE_2D, textureIds[0]);
    GLUtils.texImage2D(GL_TEXTURE_2D, 0, bitmap, 0);
    // 缓存纹理ID
    textureCache.put(tileKey, textureIds[0]);
});

我记得有一次优化一个高清画册应用，用户翻页时总是卡顿。排查后发现是纹理上传占用了UI线程。改成异步上传后，翻页流畅得像翻真书一样。

知识体系总览

我把整个大图加载与分片的知识体系画了张图，方便你理解各个模块之间的关系：

从这张图可以看出来，整个体系的核心就是「分而治之」。不管是分片加载、瓦片管理，还是内存复用、异步上传，本质上都是在做同一件事——把大问题拆成小问题，逐个解决。

好了，关于大图加载与分片的内容就讲到这里。这些方法我在多个项目中验证过，效果都很稳定。你如果在实际开发中遇到类似问题，不妨试试这些思路。