Glide 图片加载通用优化策略工程实践版做Android开发这几年几乎每个项目都离不开图片加载。Glide是我用得最多的库没有之一。但有个观察一直憋在心里很多工程的Glide接入方式其实相当朴素基本就是Glide.with(context).load(url).into(imageView)一行走天下默认配置用到底。这样用不是不行只是当图片列表变长、图源变复杂、低端机变多的时候没做优化的问题就会集中暴露列表滑动掉帧、图片变形、内存暴涨、甚至直接OOM。这篇文章就是我在真实项目里反复折腾之后沉淀下来的通用优化方案。适用范围不限定某一类App几乎任何以Glide为图片加载框架的工程都能直接用。我会把优化动作拆成四层配置层、尺寸层、缓存层、加载调度层每层都给出可以直接抄走的代码和参数顺带解释清楚背后的原理和坑。只要你项目里在用Glide这篇内容至少能帮你解决两三个目前还没注意到的隐患。1. 优化前先想清楚工程里Glide到底在消耗什么1.1 先诊断再开药做性能优化最忌讳一上来就套各种技巧。同样是“图片加载慢”背后的原因可能完全不同。我一般按这三个方向排查第一是内存占用。一百张图片如果全部按原始分辨率解码一张2048乘1536的图就占12MB内存还是在ARGB_8888格式下。列表页如果是3列无限滑动内存直接失控。第二是加载速度。服务端给的原图超过1MB甚至几MB在弱网环境下用户要等好几秒才算真正看到图中间只有一张灰色占位图体验非常差。第三是交互流畅度。列表滚动时每张图片都触发网络请求、解码、缓存写入主线程虽然没有直接参与但频繁的异步回调一样会让列表帧率波动明显。推荐做法是先用systrace或者Profiler里的Memory Profiler跑一轮真实路径把问题量化出来再对应做方案。很多时候你会发现OOM根本不是内存不够而是Bitmap没有复用导致碎片化分配过多加载慢也不是Glide的问题而是接口返回的图片没做尺寸裁剪。1.2 优化目标拆解工程实践里的Glide优化本质上是在四件事之间找平衡加载速度、内存占用、图片质量、开发维护成本。四者不可兼得但绝大多数场景的合理目标是这样首屏图片在相对较短时间内可见不必等原图下载完成。列表滚动过程中不再有新的解码任务抢CPU掉帧明显减少。内存缓存控制在合理范围内App切后台再回来不触发大量回收。不牺牲肉眼可见的清晰度不能为了性能把图搞成马赛克。明确了目标你往下看每一步优化就会清楚它到底在解决哪个问题而不是为了炫技盲目加配置。2. 全局配置优化把AppGlideModule用明白2.1 一个合理的全局配置示例Glide 4.x的全局定制入口是AppGlideModule。它会在App启动时初始化Glide的单例所有后续加载都会共享这套配置。下面这个配置是我在多个项目里验证过的基础版GlideModule class MyGlideModule : AppGlideModule() { override fun applyOptions(context: Context, builder: GlideBuilder) { // 内存缓存设为全局可用内存的15%左右禁止无限制膨胀 val memoryCacheSize (Runtime.getRuntime().maxMemory() / 1024 / 1024 * 0.15).toInt() builder.setMemoryCache(LruResourceCache(memoryCacheSize * 1024 * 1024L)) // Bitmap池设置同量级避免频繁分配和GC builder.setBitmapPool(LruBitmapPool(memoryCacheSize * 1024 * 1024L)) // 默认解码格式兼容性优先 builder.setDefaultRequestOptions( RequestOptions() .format(DecodeFormat.PREFER_RGB_565) .disallowHardwareConfig() .timeout(15000) ) builder.setLogLevel(Log.ERROR) } override fun isManifestParsingEnabled() false }这里有一个容易被忽略的点isManifestParsingEnabled返回false。Glide 4之前是扫描Manifest里的meta-data来发现module改成直接GlideModule注解后如果我们不禁用Manifest解析每次启动会有额外的注解扫描和反射开销。虽然量不大但对启动速度敏感的项目这一行能省一点事。另外setMemoryCache的单位是字节不是KB也不是MB。我见过有人写成LruResourceCache(50)然后跑起来内存缓存小得离谱图片全部走磁盘滑动起来慢得让人抓狂。这里顺手把换算写清楚50MB就是50 * 1024 * 1024L。2.2 解码格式与Bitmap复用池的取舍DecodeFormat.PREFER_RGB_565是取舍后的默认选择。RGB_565每个像素只占2字节相比ARGB_8888的4字节直接省一半内存而且对大部分照片类图片来说人眼几乎看不出差异。但要注意RGB_565不支持透明度。如果是圆角头像、带透明通道的PNG就必须单独对那张图用ARGB_8888否则边缘会出现紫色或黑色描边。更优雅的做法是分场景指定格式而不仅是全局统一。比如普通列表图用PREFER_RGB_565头像、图标、透明背景图用PREFER_ARGB_8888:val avatarOptions RequestOptions() .format(DecodeFormat.PREFER_ARGB_8888) .circleCrop()Bitmap复用池的大小也值得说两句。Glide内部维护着一个BitmapPool同一解码尺寸的Bitmap会被回收后放进池子里下次加载同样尺寸的图直接复用省掉一次分配。如果池子太小回收来不及进池就被GC太大又会占着内存不放。我的经验是池容量跟内存缓存保持同一量级就可以不需要过分精细重点是别把它设成0或者一个极小值。2.3 生命周期感知被低估的省流策略Glide与生命周期绑定是它碾压其他加载库的核心优势之一但很多人没意识到这也是一种优化。Glide.with(context)传入的是Fragment或Activity时Glide会注册一个无UI的隐藏Fragment在宿主销毁时自动取消请求、释放资源。举个例子用户打开一个图文详情页划了几下就退出这时如果网络请求还在继续没有生命周期感知的库会继续把图片下载完再解码做了大量无用功。Glide绑定了生命周期后页面销毁会直接取消这个请求图片不会继续下载。在快速滑动列表然后又退出页面的场景下这个机制能省掉大量无用网络流量和解码开销。实际工程里我见过不少团队把Glide.with(applicationContext)用在一个本该感知页面的地方理由是“怕context泄漏”。这其实是用优化去制造另一个问题。只要不是在单例或全局静态View里都优先传Activity或Fragment。3. 尺寸控制从源头减少解码压力3.1 override尺寸比想象中更重要很多优化都围绕“加载后怎么处理”但最省事的优化是让Glide压根不要解码那么大的图。override(width, height)就是干这个的。它的意义不是把大图等比缩放显示而是让Glide在解码时就只解码到这个尺寸范围。举个例子一个ImageView在3列瀑布流里每格大概宽240dp高度按16比9算约135dp在720p的手机上对应的像素大约是480乘270。如果不写overrideGlide会加载一张服务端可能给到的最大尺寸——比如1080乘1920的原始图内存占用是480x270的十几倍。内存占用差距估算 1080 * 1920 * 4字节 8.3MB 480 * 270 * 4字节 0.5MB 差距约16倍所以对于固定布局的列表、宫格、轮播图一定要用override把目标尺寸锁定。对于自适应高度的页面大图可以通过读取ImageView.getLayoutParams()里的宽高再换算成px传给override。val options RequestOptions() .override(400, 400) .centerCrop() Glide.with(imageView.context) .load(url) .apply(options) .into(imageView)这里还有个容易被忽略的坑占位图。如果你的placeholder是一张尺寸很大的本地图Glide在 decode 占位图时也会走完整的内存流程同样会造成峰值内存上升。尽量准备尺寸匹配的占位图不要拿一张几千像素的图当placeholder。3.2 Downsampler的采样逻辑Glide 4.x内部默认用Downsampler来处理图片解码。他会先读图片的宽高信息再根据目标尺寸计算采样率比如inSampleSize为2、4、8等用区域采样而不是全尺寸解码后再缩放。这个机制决定了哪怕你load一张5000像素的大图只要override给了合理的尺寸内存就不会被撑爆。但要注意两件事。第一override给的值不能过小。采样率是按2的幂次估算的如果你给的目标是200x200但实际显示区域是800x800图片会被过采样导致发虚。第二Glide的采样是按fitCenter还是centerCrop的不同而计算不同基准尺寸同一个URL在同一屏不同布局下内存占用可能差出好几倍。这个不展开细讲你只需要知道不要写死一个尺寸给所有场景最好按显示区域实际尺寸来。3.3 超大图与长图必须单独处理很多App的详情页会展示超长截图或设计稿大图。这种场景直接走常规Glide链路即使设置override一个宽度1080、高度超过10000的长图解码出来仍然要占几十MB内存。低端机必崩。我实际项目里的方案是把大图分块处理。Glide有一个ImageDecoder的机制4.x里可以通过asBitmap加自定义Downsampler或者通过RegionDecoder手动分区域解码。但工程上更简单粗暴的方案是让服务端对长图单独做切片客户端用RecyclerView多段加载。如果服务端不支持至少也要把长图按最大宽度限制解码并在解码后立即用Bitmap.createBitmap裁剪加载完成后将原始大Bitmap回收。另外一个细节图片的旋转信息。手机拍照的JPG经常带EXIF旋转信息如果直接解码会得到旋转后的错误方向Glide内部的Downsampler会做自动旋转校正但这个过程会多一次复制操作。服务端能在上传时就处理掉EXIF客户端解码压力会小很多。4. 缓存体系理解四大磁盘策略与Signature4.1 磁盘缓存策略DATA还是RESOURCEGlide的磁盘缓存有两种核心数据单元DATA是原始下载数据RESOURCE是经过解码、变换后的最终Bitmap产物。四个策略对应不同的缓存组合策略缓存内容适用场景AUTOMATIC默认智能选择绝大多数场景Glide自行决策DATA只缓存原始数据同一URL需要多种尺寸展示RESOURCE只缓存变换后的资源同一尺寸反复展示ALL两者都缓存尺寸多变且原图下载成本高NONE不缓存隐私图、临时图默认的AUTOMATIC已经足够优秀它会根据变换情况选择比如你用了centerCrop和override它会缓存变换后的RESOURCE如果什么都没做它就缓存DATA。那我为什么还要单独说因为有个常见场景AUTOMATIC表现不理想同一个URL在一个页面需要大图在另一个页面需要小缩略图。如果缓存的是大尺寸的RESOURCE小图加载时还得重新请求网络。这种场景建议显式指定DiskCacheStrategy.DATA让所有尺寸展示都从同一份原始数据重新解码。解码过程远快于网络请求内存还因为尺寸控制变得更小。Glide.with(imageView.context) .load(url) .diskCacheStrategy(DiskCacheStrategy.DATA) .into(imageView)4.2 缓存Key的生成规则Transform一言不合就失效Glide的缓存Key不是简单地以URL为唯一标识。它是由多个属性组合生成的一个Key对象包括ModelURL或文件路径、signature、width、height、transformations、options等。这意味着同一个URL用centerCrop和用fitCenter缓存的是两份不同的RESOURCE。同一个URLoverride的宽高不同缓存也不同。同一个URL你如果自定了BitmapTransformation比如高斯模糊、圆角缓存Key也会随之变化每次变化都会重新走一次解码和变换。所以对动态变换很多的项目磁盘缓存膨胀速度会非常快。我见过一个社区App仅因圆角、模糊、灰度等变换组合磁盘缓存几个月下来能涨到1GB多。解决方案一般是定时手动清除Glide磁盘缓存或者把DiskCacheStrategy调整为DATA让变换后产物不落盘每次都在原始数据上重新计算。4.3 Signature解决URL不变内容变的经典问题运营在后台替换了同一路径的图片但URL没变客户端还缓存着旧图这种问题相信大家都遇到过。Glide提供了signature来解决覆盖场景。ObjectKey可以传入任意唯一标记比如服务端返回的图片版本号、文件修改时间等。val signature ObjectKey(data.version) // 服务端版本号 Glide.with(imageView.context) .load(url) .signature(signature) .into(imageView)只要signature变了缓存Key就变了Glide会认为这是一张新图重新加载。注意这个签名要在数据层每次刷新时都更新否则等于没设置。另外不要用时间戳当日志级别那样频繁变化的方案否则会导致所有缓存失效Glide退化为每次重新下载。5. 加载体验优化thumbnail、优先级与网络层定制5.1 thumbnail工作原理与正确用法thumbnail(0.1f)是Glide里最实用但经常被用错的一个API。它的含义是先加载目标图的10%尺寸作为预览等正式图加载完成后替换上去。这里面有一个误区——很多人以为这会让总流量变小实际上它不是省流量而是让首帧的感知速度变快。预览图小解码快可以先显示出来真实图继续在网络上下载下载完再替换。正确用法分两种// 用法一同URL缩略系数方式 Glide.with(imageView.context) .load(url) .thumbnail(0.1f) .into(imageView) // 用法二不同URL先用低清封面占位 Glide.with(imageView.context) .load(highQualityUrl) .thumbnail( Glide.with(imageView.context) .load(lowQualityUrl) ) .into(imageView)第二种用法更高级适用于视频封面、直播封面这类场景先用服务端生成的极低码率图可能只有几KB垫底等高清图下载完再替换。工程实践上第二种方案的感知速度提升非常明显尤其在弱网环境里用户至少可以第一时间看到内容的轮廓而不是干等loading。但要注意thumbnail和主请求共享同一个Target如果主请求加载失败缩略图不一定还能正常显示。真机上表现不稳定需要自己对加载失败做兜底处理。5.2 列表滚动时的加载调度管理RecyclerView快速滑动时每个item的ImageView都会触发Glide加载请求。如果不做任何管控瞬间会产生大量解码任务和内存分配即使Glide有生命周期也无济于事——因为这些View都还在屏幕上活跃。Glide本身没有自动的“滑动停止才加载”能力但Google的官方示例是在RecyclerView的OnScrollListener里手动控制recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() { override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) { when (newState) { RecyclerView.SCROLL_STATE_DRAGGING, RecyclerView.SCROLL_STATE_SETTLING - { Glide.with(context).pauseRequests() } RecyclerView.SCROLL_STATE_IDLE - { Glide.with(context).resumeRequests() } } } })这个方案看似粗暴但实测极其有效。它本质上把滑动过程中的所有新请求都挂起等用户停下来再一次性加载。对于信息流类App画面从快速滑动进入静止也就是几百毫秒内的事用户基本感知不到图片比平时晚出现但CPU尖峰和内存压力会大幅下降。另外一个细节pauseRequests挂起的是所有请求包括已经加载到一半的。Glide内部会对请求队列做处理不会丢请求只是暂缓。放心用。5.3 网络层定制OkHttp与超时切割Glide默认使用HttpURLConnection下载图片。我们项目里的实际感受是切换到OkHttp挂上统一拦截器后超时控制和缓存策略明显更顺手。Glide提供了AppGlideModule里注册OkHttp的扩展方式GlideModule class MyGlideModule : AppGlideModule() { override fun registerComponents(context: Context, glide: Glide, registry: Registry) { val client OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(20, TimeUnit.SECONDS) .addInterceptor { chain - val request chain.request().newBuilder() .header(Accept, image/*) .build() chain.proceed(request) } .build() registry.replace(GlideUrl::class.java, InputStream::class.java, OkHttpUrlLoader.Factory(client)) } }这里重点提一下超时。图片下载在弱网环境下非常容易触发超时Glide默认的timeout是10秒。如果是长图或大分辨率原图10秒经常不够。我一般把timeout结合override一起用如果图片被裁剪到列表尺寸10秒足够如果是详情页大图单独把超时放宽到30秒。关于网络层还有一个CDN层面的经验图片接口尽量走CDN并在URL上带尺寸参数。服务端按参数返回不同尺寸的图会彻底降低客户端的尺寸优化压力。Glide的override只影响解码后尺寸不影响网络传输体积——服务端给的原始文件是2MB你override成100x100也得先把2MB下载完再解码。这是我见过最多人混淆的地方。6. 内存治理与OOM兜底6.1 MemoryCategory动态调整Glide的每个RequestOptions都可以指定memoryCategory或者通过Glide.get(context).setMemoryCategory()从全局调整缓存大小。这个API在低内存设备上的价值往往被忽视。我在一个低端机适配项目里检测到设备可用内存低于某个阈值时会把MemoryCategory切换到MemoryCategory.LOW此时内存缓存缩水到默认的一半等App回到前台或者Memory压力降低后再切回MemoryCategory.NORMAL。这样可以让图片缓存主动让位给核心业务避免整个App因为图片被杀掉。if (deviceLowMemory()) { Glide.get(context).setMemoryCategory(MemoryCategory.LOW) } else { Glide.get(context).setMemoryCategory(MemoryCategory.NORMAL) }但注意动态调整MemoryCategory会影响已经缓存到内存里的图片它不会立刻回收所有缓存而是在后续put新缓存时按新比例淘汰。所以这个调整要尽量早做最好在Application入口就判定一次。6.2 硬件位图与RGB565内存减半的两种姿势Android 8.0之后Glide 4默认会使用硬件位图Hardware Bitmap。硬件位图直接存在于GPU内存跳过Java堆解码速度极快且不占App堆内存。但它有两个硬伤不能读取像素不能直接用在某些Canvas绘制场景。如果你把图显示在普通ImageView里硬件位图没有任何问题一旦你要对Bitmap做二次处理比如生成分享图、加滤镜就会碰到IllegalStateException。碰到这种场景我一般对特定图片禁用硬件位图val options RequestOptions() .disallowHardwareConfig() .format(DecodeFormat.PREFER_ARGB_8888)RGB_565前面已经提过省一半内存。两个方案结合大部分列表图用RGB565个别需要二次处理或者带透明通道的图单独用ARGB8888并禁用硬件位图。这个组合已经足够应对绝大多数工程项目的OOM风险。6.3 Bitmap复用与超大图的终极兜底即使做了override偶尔还是会遇到不可控的图片比如用户自己上传的原图、页面宽度撑满的超宽屏图。这时如果主流程里还挂着一堆其他大图内存也可能告急。兜底方案一监控OnTrimMemory。Glide内部有onTrimMemory回调会清理内存缓存我们也可以在App层面调用Glide.get(context).onTrimMemory(level)手动回收。效果立竿见影但图片需要重新加载。兜底方案二使用skipMemoryCache(true)来避免大图进入内存缓存。某些超清详情图如果只是单次展示没有必要留在内存缓存里占地方下次进页面重新加载一次磁盘缓存就够。Glide.with(context) .load(url) .skipMemoryCache(true) .diskCacheStrategy(DiskCacheStrategy.DATA) .into(imageView)这两个方案组合起来能够在处理极端大图时把对内存的影响降到最低同时不影响其他常规图片的缓存体验。7. 常见问题与排查经验速查7.1 高频问题对照表优化方案落地之后实际运行里还会冒出各种“看起来与Glide无关”的问题。把这些年遇到的典型问题整理成了一张表遇到直接对号入座。现象根因处理方案图片变绿边或发紫边透明图用了RGB_565解码该Image单独设置ARGB_8888列表快速滑动后白屏大量请求被pause后未正确resume检查scrollListener的IDLE是否被漏掉圆角图有黑色描边硬件位图不支持某些transform对该图disallowHardwareConfig同一URL图片不更新缓存Key未变旧缓存命中配合signature或服务端加版本号大图加载后闪退内存缓存、BitmapPool同时膨胀调低MemoryCategory并控制override图片加载不走磁盘缓存自定义了过大的signature或每次都变化用稳定的业务唯一标识做签名弱网下图片永远加载失败timeout太短长图下载超时单独放宽该请求的网络超时时间7.2 通过日志定位图片加载链路Glide内部日志分几个等级。调试阶段把setLogLevel(Log.VERBOSE)打开很多问题会直接暴露缓存是否命中、解码用了多少毫秒、请求有没有被cancel。日志关键字大概长这样Glide: Load failed for Model ... class java.io.FileNotFoundException Glide: Finished loading Bitmap from GlideUrl ... took 203 ms, size: 1200x800 Glide: Cancelled by Activity Lifecycle上线前记得把日志级别调回Log.ERROR否则生产环境会有一堆无用日志持续写盘。如果日志不够用可以加RequestListener来统计真实业务的加载失败率和耗时。这个统计不仅能发现网络问题还能看到不同图片大小下的解码耗时分布是后续进一步优化的数据基础。最后再分享一个排查小技巧调试Glide问题时很多人第一步就去翻代码逻辑但我建议你先去看服务端的响应头。重点看Content-Length和Content-Type再对比Glide的采样尺寸基本能判断是网络传输慢还是解码慢。这个方法救过我很多次。图片优化是个长期工程Glide的默认配置已经足够跑通大部分场景真正决定体验上限的往往是你在这些细节上愿意花多少心思。 
长河君 · 2026/9/28 14:28:58 · 阅读 1.2k Glide图片加载通用优化策略：配置、尺寸、缓存与加载调度
Glide 图片加载通用优化策略工程实践版做Android开发这几年几乎每个项目都离不开图片加载。Glide是我用得最多的库没有之一。但有个观察一直憋在心里很多工程的Glide接入方式其实相当朴素基本就是Glide.with(context).load(url).into(imageView)一行走天下默认配置用到底。这样用不是不行只是当图片列表变长、图源变复杂、低端机变多的时候没做优化的问题就会集中暴露列表滑动掉帧、图片变形、内存暴涨、甚至直接OOM。这篇文章就是我在真实项目里反复折腾之后沉淀下来的通用优化方案。适用范围不限定某一类App几乎任何以Glide为图片加载框架的工程都能直接用。我会把优化动作拆成四层配置层、尺寸层、缓存层、加载调度层每层都给出可以直接抄走的代码和参数顺带解释清楚背后的原理和坑。只要你项目里在用Glide这篇内容至少能帮你解决两三个目前还没注意到的隐患。1. 优化前先想清楚工程里Glide到底在消耗什么1.1 先诊断再开药做性能优化最忌讳一上来就套各种技巧。同样是“图片加载慢”背后的原因可能完全不同。我一般按这三个方向排查第一是内存占用。一百张图片如果全部按原始分辨率解码一张2048乘1536的图就占12MB内存还是在ARGB_8888格式下。列表页如果是3列无限滑动内存直接失控。第二是加载速度。服务端给的原图超过1MB甚至几MB在弱网环境下用户要等好几秒才算真正看到图中间只有一张灰色占位图体验非常差。第三是交互流畅度。列表滚动时每张图片都触发网络请求、解码、缓存写入主线程虽然没有直接参与但频繁的异步回调一样会让列表帧率波动明显。推荐做法是先用systrace或者Profiler里的Memory Profiler跑一轮真实路径把问题量化出来再对应做方案。很多时候你会发现OOM根本不是内存不够而是Bitmap没有复用导致碎片化分配过多加载慢也不是Glide的问题而是接口返回的图片没做尺寸裁剪。1.2 优化目标拆解工程实践里的Glide优化本质上是在四件事之间找平衡加载速度、内存占用、图片质量、开发维护成本。四者不可兼得但绝大多数场景的合理目标是这样首屏图片在相对较短时间内可见不必等原图下载完成。列表滚动过程中不再有新的解码任务抢CPU掉帧明显减少。内存缓存控制在合理范围内App切后台再回来不触发大量回收。不牺牲肉眼可见的清晰度不能为了性能把图搞成马赛克。明确了目标你往下看每一步优化就会清楚它到底在解决哪个问题而不是为了炫技盲目加配置。2. 全局配置优化把AppGlideModule用明白2.1 一个合理的全局配置示例Glide 4.x的全局定制入口是AppGlideModule。它会在App启动时初始化Glide的单例所有后续加载都会共享这套配置。下面这个配置是我在多个项目里验证过的基础版GlideModule class MyGlideModule : AppGlideModule() { override fun applyOptions(context: Context, builder: GlideBuilder) { // 内存缓存设为全局可用内存的15%左右禁止无限制膨胀 val memoryCacheSize (Runtime.getRuntime().maxMemory() / 1024 / 1024 * 0.15).toInt() builder.setMemoryCache(LruResourceCache(memoryCacheSize * 1024 * 1024L)) // Bitmap池设置同量级避免频繁分配和GC builder.setBitmapPool(LruBitmapPool(memoryCacheSize * 1024 * 1024L)) // 默认解码格式兼容性优先 builder.setDefaultRequestOptions( RequestOptions() .format(DecodeFormat.PREFER_RGB_565) .disallowHardwareConfig() .timeout(15000) ) builder.setLogLevel(Log.ERROR) } override fun isManifestParsingEnabled() false }这里有一个容易被忽略的点isManifestParsingEnabled返回false。Glide 4之前是扫描Manifest里的meta-data来发现module改成直接GlideModule注解后如果我们不禁用Manifest解析每次启动会有额外的注解扫描和反射开销。虽然量不大但对启动速度敏感的项目这一行能省一点事。另外setMemoryCache的单位是字节不是KB也不是MB。我见过有人写成LruResourceCache(50)然后跑起来内存缓存小得离谱图片全部走磁盘滑动起来慢得让人抓狂。这里顺手把换算写清楚50MB就是50 * 1024 * 1024L。2.2 解码格式与Bitmap复用池的取舍DecodeFormat.PREFER_RGB_565是取舍后的默认选择。RGB_565每个像素只占2字节相比ARGB_8888的4字节直接省一半内存而且对大部分照片类图片来说人眼几乎看不出差异。但要注意RGB_565不支持透明度。如果是圆角头像、带透明通道的PNG就必须单独对那张图用ARGB_8888否则边缘会出现紫色或黑色描边。更优雅的做法是分场景指定格式而不仅是全局统一。比如普通列表图用PREFER_RGB_565头像、图标、透明背景图用PREFER_ARGB_8888:val avatarOptions RequestOptions() .format(DecodeFormat.PREFER_ARGB_8888) .circleCrop()Bitmap复用池的大小也值得说两句。Glide内部维护着一个BitmapPool同一解码尺寸的Bitmap会被回收后放进池子里下次加载同样尺寸的图直接复用省掉一次分配。如果池子太小回收来不及进池就被GC太大又会占着内存不放。我的经验是池容量跟内存缓存保持同一量级就可以不需要过分精细重点是别把它设成0或者一个极小值。2.3 生命周期感知被低估的省流策略Glide与生命周期绑定是它碾压其他加载库的核心优势之一但很多人没意识到这也是一种优化。Glide.with(context)传入的是Fragment或Activity时Glide会注册一个无UI的隐藏Fragment在宿主销毁时自动取消请求、释放资源。举个例子用户打开一个图文详情页划了几下就退出这时如果网络请求还在继续没有生命周期感知的库会继续把图片下载完再解码做了大量无用功。Glide绑定了生命周期后页面销毁会直接取消这个请求图片不会继续下载。在快速滑动列表然后又退出页面的场景下这个机制能省掉大量无用网络流量和解码开销。实际工程里我见过不少团队把Glide.with(applicationContext)用在一个本该感知页面的地方理由是“怕context泄漏”。这其实是用优化去制造另一个问题。只要不是在单例或全局静态View里都优先传Activity或Fragment。3. 尺寸控制从源头减少解码压力3.1 override尺寸比想象中更重要很多优化都围绕“加载后怎么处理”但最省事的优化是让Glide压根不要解码那么大的图。override(width, height)就是干这个的。它的意义不是把大图等比缩放显示而是让Glide在解码时就只解码到这个尺寸范围。举个例子一个ImageView在3列瀑布流里每格大概宽240dp高度按16比9算约135dp在720p的手机上对应的像素大约是480乘270。如果不写overrideGlide会加载一张服务端可能给到的最大尺寸——比如1080乘1920的原始图内存占用是480x270的十几倍。内存占用差距估算 1080 * 1920 * 4字节 8.3MB 480 * 270 * 4字节 0.5MB 差距约16倍所以对于固定布局的列表、宫格、轮播图一定要用override把目标尺寸锁定。对于自适应高度的页面大图可以通过读取ImageView.getLayoutParams()里的宽高再换算成px传给override。val options RequestOptions() .override(400, 400) .centerCrop() Glide.with(imageView.context) .load(url) .apply(options) .into(imageView)这里还有个容易被忽略的坑占位图。如果你的placeholder是一张尺寸很大的本地图Glide在 decode 占位图时也会走完整的内存流程同样会造成峰值内存上升。尽量准备尺寸匹配的占位图不要拿一张几千像素的图当placeholder。3.2 Downsampler的采样逻辑Glide 4.x内部默认用Downsampler来处理图片解码。他会先读图片的宽高信息再根据目标尺寸计算采样率比如inSampleSize为2、4、8等用区域采样而不是全尺寸解码后再缩放。这个机制决定了哪怕你load一张5000像素的大图只要override给了合理的尺寸内存就不会被撑爆。但要注意两件事。第一override给的值不能过小。采样率是按2的幂次估算的如果你给的目标是200x200但实际显示区域是800x800图片会被过采样导致发虚。第二Glide的采样是按fitCenter还是centerCrop的不同而计算不同基准尺寸同一个URL在同一屏不同布局下内存占用可能差出好几倍。这个不展开细讲你只需要知道不要写死一个尺寸给所有场景最好按显示区域实际尺寸来。3.3 超大图与长图必须单独处理很多App的详情页会展示超长截图或设计稿大图。这种场景直接走常规Glide链路即使设置override一个宽度1080、高度超过10000的长图解码出来仍然要占几十MB内存。低端机必崩。我实际项目里的方案是把大图分块处理。Glide有一个ImageDecoder的机制4.x里可以通过asBitmap加自定义Downsampler或者通过RegionDecoder手动分区域解码。但工程上更简单粗暴的方案是让服务端对长图单独做切片客户端用RecyclerView多段加载。如果服务端不支持至少也要把长图按最大宽度限制解码并在解码后立即用Bitmap.createBitmap裁剪加载完成后将原始大Bitmap回收。另外一个细节图片的旋转信息。手机拍照的JPG经常带EXIF旋转信息如果直接解码会得到旋转后的错误方向Glide内部的Downsampler会做自动旋转校正但这个过程会多一次复制操作。服务端能在上传时就处理掉EXIF客户端解码压力会小很多。4. 缓存体系理解四大磁盘策略与Signature4.1 磁盘缓存策略DATA还是RESOURCEGlide的磁盘缓存有两种核心数据单元DATA是原始下载数据RESOURCE是经过解码、变换后的最终Bitmap产物。四个策略对应不同的缓存组合策略缓存内容适用场景AUTOMATIC默认智能选择绝大多数场景Glide自行决策DATA只缓存原始数据同一URL需要多种尺寸展示RESOURCE只缓存变换后的资源同一尺寸反复展示ALL两者都缓存尺寸多变且原图下载成本高NONE不缓存隐私图、临时图默认的AUTOMATIC已经足够优秀它会根据变换情况选择比如你用了centerCrop和override它会缓存变换后的RESOURCE如果什么都没做它就缓存DATA。那我为什么还要单独说因为有个常见场景AUTOMATIC表现不理想同一个URL在一个页面需要大图在另一个页面需要小缩略图。如果缓存的是大尺寸的RESOURCE小图加载时还得重新请求网络。这种场景建议显式指定DiskCacheStrategy.DATA让所有尺寸展示都从同一份原始数据重新解码。解码过程远快于网络请求内存还因为尺寸控制变得更小。Glide.with(imageView.context) .load(url) .diskCacheStrategy(DiskCacheStrategy.DATA) .into(imageView)4.2 缓存Key的生成规则Transform一言不合就失效Glide的缓存Key不是简单地以URL为唯一标识。它是由多个属性组合生成的一个Key对象包括ModelURL或文件路径、signature、width、height、transformations、options等。这意味着同一个URL用centerCrop和用fitCenter缓存的是两份不同的RESOURCE。同一个URLoverride的宽高不同缓存也不同。同一个URL你如果自定了BitmapTransformation比如高斯模糊、圆角缓存Key也会随之变化每次变化都会重新走一次解码和变换。所以对动态变换很多的项目磁盘缓存膨胀速度会非常快。我见过一个社区App仅因圆角、模糊、灰度等变换组合磁盘缓存几个月下来能涨到1GB多。解决方案一般是定时手动清除Glide磁盘缓存或者把DiskCacheStrategy调整为DATA让变换后产物不落盘每次都在原始数据上重新计算。4.3 Signature解决URL不变内容变的经典问题运营在后台替换了同一路径的图片但URL没变客户端还缓存着旧图这种问题相信大家都遇到过。Glide提供了signature来解决覆盖场景。ObjectKey可以传入任意唯一标记比如服务端返回的图片版本号、文件修改时间等。val signature ObjectKey(data.version) // 服务端版本号 Glide.with(imageView.context) .load(url) .signature(signature) .into(imageView)只要signature变了缓存Key就变了Glide会认为这是一张新图重新加载。注意这个签名要在数据层每次刷新时都更新否则等于没设置。另外不要用时间戳当日志级别那样频繁变化的方案否则会导致所有缓存失效Glide退化为每次重新下载。5. 加载体验优化thumbnail、优先级与网络层定制5.1 thumbnail工作原理与正确用法thumbnail(0.1f)是Glide里最实用但经常被用错的一个API。它的含义是先加载目标图的10%尺寸作为预览等正式图加载完成后替换上去。这里面有一个误区——很多人以为这会让总流量变小实际上它不是省流量而是让首帧的感知速度变快。预览图小解码快可以先显示出来真实图继续在网络上下载下载完再替换。正确用法分两种// 用法一同URL缩略系数方式 Glide.with(imageView.context) .load(url) .thumbnail(0.1f) .into(imageView) // 用法二不同URL先用低清封面占位 Glide.with(imageView.context) .load(highQualityUrl) .thumbnail( Glide.with(imageView.context) .load(lowQualityUrl) ) .into(imageView)第二种用法更高级适用于视频封面、直播封面这类场景先用服务端生成的极低码率图可能只有几KB垫底等高清图下载完再替换。工程实践上第二种方案的感知速度提升非常明显尤其在弱网环境里用户至少可以第一时间看到内容的轮廓而不是干等loading。但要注意thumbnail和主请求共享同一个Target如果主请求加载失败缩略图不一定还能正常显示。真机上表现不稳定需要自己对加载失败做兜底处理。5.2 列表滚动时的加载调度管理RecyclerView快速滑动时每个item的ImageView都会触发Glide加载请求。如果不做任何管控瞬间会产生大量解码任务和内存分配即使Glide有生命周期也无济于事——因为这些View都还在屏幕上活跃。Glide本身没有自动的“滑动停止才加载”能力但Google的官方示例是在RecyclerView的OnScrollListener里手动控制recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() { override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) { when (newState) { RecyclerView.SCROLL_STATE_DRAGGING, RecyclerView.SCROLL_STATE_SETTLING - { Glide.with(context).pauseRequests() } RecyclerView.SCROLL_STATE_IDLE - { Glide.with(context).resumeRequests() } } } })这个方案看似粗暴但实测极其有效。它本质上把滑动过程中的所有新请求都挂起等用户停下来再一次性加载。对于信息流类App画面从快速滑动进入静止也就是几百毫秒内的事用户基本感知不到图片比平时晚出现但CPU尖峰和内存压力会大幅下降。另外一个细节pauseRequests挂起的是所有请求包括已经加载到一半的。Glide内部会对请求队列做处理不会丢请求只是暂缓。放心用。5.3 网络层定制OkHttp与超时切割Glide默认使用HttpURLConnection下载图片。我们项目里的实际感受是切换到OkHttp挂上统一拦截器后超时控制和缓存策略明显更顺手。Glide提供了AppGlideModule里注册OkHttp的扩展方式GlideModule class MyGlideModule : AppGlideModule() { override fun registerComponents(context: Context, glide: Glide, registry: Registry) { val client OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(20, TimeUnit.SECONDS) .addInterceptor { chain - val request chain.request().newBuilder() .header(Accept, image/*) .build() chain.proceed(request) } .build() registry.replace(GlideUrl::class.java, InputStream::class.java, OkHttpUrlLoader.Factory(client)) } }这里重点提一下超时。图片下载在弱网环境下非常容易触发超时Glide默认的timeout是10秒。如果是长图或大分辨率原图10秒经常不够。我一般把timeout结合override一起用如果图片被裁剪到列表尺寸10秒足够如果是详情页大图单独把超时放宽到30秒。关于网络层还有一个CDN层面的经验图片接口尽量走CDN并在URL上带尺寸参数。服务端按参数返回不同尺寸的图会彻底降低客户端的尺寸优化压力。Glide的override只影响解码后尺寸不影响网络传输体积——服务端给的原始文件是2MB你override成100x100也得先把2MB下载完再解码。这是我见过最多人混淆的地方。6. 内存治理与OOM兜底6.1 MemoryCategory动态调整Glide的每个RequestOptions都可以指定memoryCategory或者通过Glide.get(context).setMemoryCategory()从全局调整缓存大小。这个API在低内存设备上的价值往往被忽视。我在一个低端机适配项目里检测到设备可用内存低于某个阈值时会把MemoryCategory切换到MemoryCategory.LOW此时内存缓存缩水到默认的一半等App回到前台或者Memory压力降低后再切回MemoryCategory.NORMAL。这样可以让图片缓存主动让位给核心业务避免整个App因为图片被杀掉。if (deviceLowMemory()) { Glide.get(context).setMemoryCategory(MemoryCategory.LOW) } else { Glide.get(context).setMemoryCategory(MemoryCategory.NORMAL) }但注意动态调整MemoryCategory会影响已经缓存到内存里的图片它不会立刻回收所有缓存而是在后续put新缓存时按新比例淘汰。所以这个调整要尽量早做最好在Application入口就判定一次。6.2 硬件位图与RGB565内存减半的两种姿势Android 8.0之后Glide 4默认会使用硬件位图Hardware Bitmap。硬件位图直接存在于GPU内存跳过Java堆解码速度极快且不占App堆内存。但它有两个硬伤不能读取像素不能直接用在某些Canvas绘制场景。如果你把图显示在普通ImageView里硬件位图没有任何问题一旦你要对Bitmap做二次处理比如生成分享图、加滤镜就会碰到IllegalStateException。碰到这种场景我一般对特定图片禁用硬件位图val options RequestOptions() .disallowHardwareConfig() .format(DecodeFormat.PREFER_ARGB_8888)RGB_565前面已经提过省一半内存。两个方案结合大部分列表图用RGB565个别需要二次处理或者带透明通道的图单独用ARGB8888并禁用硬件位图。这个组合已经足够应对绝大多数工程项目的OOM风险。6.3 Bitmap复用与超大图的终极兜底即使做了override偶尔还是会遇到不可控的图片比如用户自己上传的原图、页面宽度撑满的超宽屏图。这时如果主流程里还挂着一堆其他大图内存也可能告急。兜底方案一监控OnTrimMemory。Glide内部有onTrimMemory回调会清理内存缓存我们也可以在App层面调用Glide.get(context).onTrimMemory(level)手动回收。效果立竿见影但图片需要重新加载。兜底方案二使用skipMemoryCache(true)来避免大图进入内存缓存。某些超清详情图如果只是单次展示没有必要留在内存缓存里占地方下次进页面重新加载一次磁盘缓存就够。Glide.with(context) .load(url) .skipMemoryCache(true) .diskCacheStrategy(DiskCacheStrategy.DATA) .into(imageView)这两个方案组合起来能够在处理极端大图时把对内存的影响降到最低同时不影响其他常规图片的缓存体验。7. 常见问题与排查经验速查7.1 高频问题对照表优化方案落地之后实际运行里还会冒出各种“看起来与Glide无关”的问题。把这些年遇到的典型问题整理成了一张表遇到直接对号入座。现象根因处理方案图片变绿边或发紫边透明图用了RGB_565解码该Image单独设置ARGB_8888列表快速滑动后白屏大量请求被pause后未正确resume检查scrollListener的IDLE是否被漏掉圆角图有黑色描边硬件位图不支持某些transform对该图disallowHardwareConfig同一URL图片不更新缓存Key未变旧缓存命中配合signature或服务端加版本号大图加载后闪退内存缓存、BitmapPool同时膨胀调低MemoryCategory并控制override图片加载不走磁盘缓存自定义了过大的signature或每次都变化用稳定的业务唯一标识做签名弱网下图片永远加载失败timeout太短长图下载超时单独放宽该请求的网络超时时间7.2 通过日志定位图片加载链路Glide内部日志分几个等级。调试阶段把setLogLevel(Log.VERBOSE)打开很多问题会直接暴露缓存是否命中、解码用了多少毫秒、请求有没有被cancel。日志关键字大概长这样Glide: Load failed for Model ... class java.io.FileNotFoundException Glide: Finished loading Bitmap from GlideUrl ... took 203 ms, size: 1200x800 Glide: Cancelled by Activity Lifecycle上线前记得把日志级别调回Log.ERROR否则生产环境会有一堆无用日志持续写盘。如果日志不够用可以加RequestListener来统计真实业务的加载失败率和耗时。这个统计不仅能发现网络问题还能看到不同图片大小下的解码耗时分布是后续进一步优化的数据基础。最后再分享一个排查小技巧调试Glide问题时很多人第一步就去翻代码逻辑但我建议你先去看服务端的响应头。重点看Content-Length和Content-Type再对比Glide的采样尺寸基本能判断是网络传输慢还是解码慢。这个方法救过我很多次。图片优化是个长期工程Glide的默认配置已经足够跑通大部分场景真正决定体验上限的往往是你在这些细节上愿意花多少心思。