有段日子我在项目里做业务抽象把和界面无关的逻辑逐步往自定义 Manager 类里搬。搬完没多久就接到同事求助自定义类里想弹 Toast直接Toast.makeText(mContext, ...)还好说可一旦要弹带图片的提示图就有点无从下手。默认 Toast 只能显示一行文字图标这种东西系统压根不给你留口子。更麻烦的是如果代码写在自定义类里经常连Context都没有this用不了getApplicationContext()也不是随便能调的。我跟他讲这个问题说穿了就两件事第一自定义类里怎么拿到可靠的Context第二怎么把一张图塞进 Toast 的 View 层级里。把这两件事想清楚剩下的就是布局写法和踩坑经验。这篇文章就把我当时的完整思路和实现过程展开说说适合正在做代码分层、想把业务工具类补全或者在非 Activity 环境弹提示图的开发者参考。1. 自定义类里操作 Toast 的症结Context 从哪来1.1 为什么 Toast 非要持有 Context很多人一开始绕不过弯我就在 Application 内部弹个提示而已为什么一定要Context因为 Toast 底层要通过Context获取系统服务NotificationManager或者经INotificationManager与系统进程通信同时还要读取主题、资源、包名等信息。说白了Toast 本质上不是一个“组件”它是向系统注册一条临时消息视图的请求必须知道“我是谁”才能在屏幕对应位置展示。Toast.makeText的第一个参数是Context但它的内部代码会立刻把传入的Context拿去获取包名和资源信息。你要是传null编译期过不去运行期也一定崩。自定义布局里的LayoutInflater.from(context)同样离不开 Context所以在自定义类里处理 Toast第一步永远不是写 Toast而是确认手里的 Context 是什么、生命周期怎样。1.2 自定义类里能拿 Context 的三种途径方法我基本都试过优先顺序是构造器传入、方法参数传入、Application 全局持有。第一种自定义类写成普通类构造器显式接收Contextclass ToastHelper(private val context: Context) { fun showWithIcon(message: String, iconRes: Int) { // 内部使用 context } }第二种不存字段每次方法调用时由调用方传入object ToastHelper { fun show(context: Context, message: String, iconRes: Int) { // 使用当前传入的 context } }第三种如果自定义类是单例或工具类可以在 Application 启动时保存全局 Contextclass App : Application() { override fun onCreate() { super.onCreate() appContext this } companion object { lateinit var appContext: Context } }第一种最稳第二种最灵活第三种最方便但容易产生“隐藏依赖”。我自己的建议是如果这个工具类只在特定模块内部用构造器传入最合适如果是全局的提示工具建议使用方法参数传入同时内部做空判断避免后期别人拿着null调用直接崩。1.3 用 ApplicationContext 还是 Activity Context这里要特别说明弹 Toast 推荐统一用applicationContext不推荐用 Activity。原因是 Toast 不会持有传入的Context做页面级别的生命周期绑定。如果你传 Activity只要 Toast 还没有自动消失就相当于间接持有了 Activity 的引用极端情况下会导致 Activity 无法被回收从而引发内存泄漏。虽然 Toast 展示时间很短但连续弹、排队弹的时候引用时长会被拉长。换成applicationContext后它就是全应用共享的实例生命周期天然比任何页面都长弹多少次都不会拖住 Activity。曾经有人担心用applicationContext会导致 Toast 样式跟系统主题不匹配实测没有这回事。Toast 视图的样式由系统渲染如果你用自定义布局布局的主题跟随自己写的 drawable、背景和颜色跟传入什么 Context 关系不大。2. 给 Toast 加图片的三种实现思路自定义 Toast 加图片网上方案不少但很多讲得乱七八糟甚至误导。我梳理下来真正可用的思路有三条自定义 View 布局、Spannable 图片插入、以及系统 Toast 配合 drawable 的曲线方案。2.1 自定义 View 承载图标和文字这是最直接、最可控的方案。思路是写一个 XML 布局里面放一个ImageView和一个TextView然后通过Toast.setView(view)把布局塞进 Toast 的视图容器中再调用show()显示。优点是非常直观图片和文字可以自由控制间距、大小、对齐方式、圆角背景。缺点是需要额外处理布局和 drawable自定义程度高时需要注意不同机型可能出现的适配问题比如深色模式、字体缩放等。但从日常项目统治力看这套方案是绝对的主流。2.2 Spannable 方式并不适合 Toast有人会想到在 Toast 的文字里拼一个ImageSpan实现“文字带上小图标”的效果。比如val spannable SpannableString( 保存成功) val drawable context.getDrawable(R.drawable.ic_success) drawable?.setBounds(0, 0, 32, 32) spannable.setSpan(ImageSpan(drawable), 0, 1, Spannable.SPAN_INCLUSIVE_EXCLUSIVE) Toast.makeText(context, spannable, Toast.LENGTH_SHORT).show()这样确实能把图片画进 TextView但它有几个明显短板图标大小只能通过setBounds控制想精确垂直居中很麻烦Toast 默认背景是灰黑色圆角矩形图片如果带透明背景还好如果是不规则图标会出现显示边界而且你没法给文字和图标之间做独立间距控制更没法把图标放在文字后面。做简单场景可以做正式通用组件没必要。2.3 用系统 Toast 配合自定义 drawable 的边界做法还有一种是完全不动布局只把系统 Toast 的 TextView 背景替换成图标加文字的 LayerDrawable或者用setCompoundDrawables给 TextView 设置复合图标。系统 Toast 内部持有一个TextView可以通过view.findViewById(android.R.id.message)拿到这个 TextView再设置它的 drawableval toast Toast.makeText(context, 保存失败, Toast.LENGTH_SHORT) val view toast.view val textView view?.findViewByIdTextView(android.R.id.message) textView?.setCompoundDrawablesWithIntrinsicBounds( context.getDrawable(R.drawable.ic_error), null, null, null ) toast.show()这个方式省去了自定义布局文件但可控性同样有限图标和文字之间的间距由系统 TextView 的 padding 决定你调整起来非常别扭而且不同 Android 版本的系统 Toast 布局内部 id 未必稳定。单看代码量它好像最少但如果后续需求要调整背景圆角、布局方向、最大宽度就会很吃力。结论就是只要你是想在正式项目里做通用组件老老实实走自定义 View 布局。3. 建一个带图 Toast 的完整实现步骤这一节直接给出可复用的步骤。以 Kotlin 为例假定要弹出的场景是“操作成功”和“操作失败”图标分别用ic_success和ic_error。3.1 布局 XML 和关键属性先创建res/layout/view_custom_toast.xml?xml version1.0 encodingutf-8? LinearLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:idid/toast_root android:layout_widthwrap_content android:layout_heightwrap_content android:backgrounddrawable/bg_custom_toast android:gravitycenter_vertical android:orientationhorizontal android:paddingStart16dp android:paddingEnd20dp android:paddingTop12dp android:paddingBottom12dp ImageView android:idid/toast_icon android:layout_width24dp android:layout_height24dp android:layout_marginEnd8dp android:contentDescriptionnull android:srcdrawable/ic_success / TextView android:idid/toast_message android:layout_widthwrap_content android:layout_heightwrap_content android:maxWidth280dp android:textColor#FFFFFF android:textSize14sp / /LinearLayout注意三个细节ImageView用固定 24dp 是比较保守的尺寸后续需要放大图标时可以直接在代码里改布局参数不影响文字。TextView的maxWidth一定要写否则极端情况下一行文案超过屏幕宽度会出现奇怪的截断。背景 drawable 用独立文件而不是直接写android:backgrounddrawable/bg_custom_toast之外的圆角属性。背景文件res/drawable/bg_custom_toast.xml?xml version1.0 encodingutf-8? shape xmlns:androidhttp://schemas.android.com/apk/res/android android:shaperectangle solid android:color#CC333333 / corners android:radius8dp / /shape#CC333333是半透明深灰比系统默认的纯黑在多数字体上有更好的视觉融合度。如果你项目里用的是 Material Design可换成?attr/colorInverseSurface但因为 Toast 是独立悬浮层直接写死色值会更稳。3.2 自定义类中的构建逻辑核心工具类我一般写成objectobject ToastImageHelper { fun show(context: Context, message: String, iconRes: Int) { val appContext context.applicationContext val toast Toast(appContext) val view LayoutInflater.from(appContext) .inflate(R.layout.view_custom_toast, null, false) val icon view.findViewByIdImageView(R.id.toast_icon) val text view.findViewByIdTextView(R.id.toast_message) if (iconRes ! 0) { icon.setImageResource(iconRes) icon.visibility ImageView.VISIBLE } else { icon.visibility ImageView.GONE } text.text message toast.view view toast.duration Toast.LENGTH_SHORT toast.show() } }这里有一个关键选择为什么不用Toast.makeText(appContext, message, Toast.LENGTH_SHORT)而是直接Toast(appContext)再用setView因为makeText内部会把传入的文字放入一个内部的默认 TextView 里紧接着你再setView覆盖整个布局无论如何都会有一次多余的视图构建。直接用Toast(appContext)则干净利落。不过要注意Toast(Context)这个构造方法从 Android 11 开始虽然仍可用但部分 lint 工具会提示建议改用Toast.makeText这是因为未来系统可能收紧自定义 Toast 的权限现阶段用自定义视图仍是官方允许的方式只是要留意后台弹窗限制的问题我在第四节细说。调用的地方很简单ToastImageHelper.show(this, 文件已保存, R.drawable.ic_success) ToastImageHelper.show(requireContext(), 网络异常, R.drawable.ic_error)3.3 多尺寸图标和背景适配图标资源建议准备 mdpi、hdpi、xhdpi、xxhdpi 多套尺寸或者直接用 Vector Drawable。Vector 在 Android 5.0 以上原生支持5.0 以下需要vectorDrawables.useSupportLibrary true项目本身一般也会开。使用 Vector 的好处是缩放不失真在 Toast 这种 24dp 小尺寸场景尤其合适。如果希望 Toast 背景能够自适应深色模式在values-night下可以补一个同名 drawable比如背景色改成更亮的半透明灰色。但实测中发现Toast 悬浮在内容之上系统自带的半透明黑在大多数界面已经够通用强行区分昼夜反而容易让 UI 显得杂。因此我的做法是业务工具类里保持深色背景如果产品确实要求跟随主题再改。4. 实测里最容易翻车的几个场景代码写出来不代表能顺利跑。真实项目里我在以下四个场景都踩过坑逐个说清楚。4.1 未初始化的 context 导致空指针如果工具类写成普通类并在构造器里接收Context很容易因为调用方传入了null或者还没初始化好的 context 而闪退。最常见的场景是某个单例工具类的初始化放在Application.onCreate()里但某个 ContentProvider 或第三方 SDK 先执行了最终导致工具类拿到的是未实例化的 context。我的习惯是加一道防护private var appContext: Context? null fun init(context: Context) { appContext context.applicationContext } private fun checkContext(): Context { return appContext ?: throw IllegalStateException(ToastImageHelper 必须初始化) }虽然抛出异常很粗暴但至少把错误提前暴露在调用栈里总比在show()中间某个位置突然 NPE 好定位。4.2 Android 11 及以上的显示限制这个问题是最隐蔽的也是最近几个版本才常见。从 Android 11API 30开始系统对后台应用弹 Toast 做了更严格的限制当应用处于后台时标准 Toast 仍然可以显示但自定义 View 类型的 Toast 有可能被系统忽略或延迟显示。Android 12 及以后后台应用弹自定义 Toast 的行为进一步收紧部分高分下自定义 Toast 甚至不会出现。如果你只是在 Activity 通过按钮点击触发完全不受影响。但如果你在后台 Service、广播接收器或者定时任务里弹自定义 Toast就要特别小心。我自己遇到过一个案例长连接的断线提醒放在 Service 里结果应用退到后台后自定义 Toast 死活不弹换成系统默认 Toast 才正常。解决思路有两个方向前台场景用自定义 Toast 保持视觉统一后台场景降级为系统默认 Toast或者直接改用通知栏消息甚至用 Snackbar 在回到前台时补提示。如果不想写两套逻辑可以把自定义 Toast 拆成两个方法一个处理前台一个处理后台fun showSystemToast(context: Context, message: String) { Toast.makeText(context, message, Toast.LENGTH_SHORT).show() }至于“回到前台时再弹”的延迟队列方案需要在前台回调里调用方法本质上是在 Activity 或 Fragment 的生命周期方法里补一次show而不是真的让后台 Toast 实现队列。4.3 图片资源 id 和 Drawable 混淆看起来是个很基础的错误但真的会发生。比如从接口返回的图标是 URL你打算异步加载图片。这时候有些代码会写成toastIcon.setImageDrawable(drawable)没问题这是对的。但也有代码写成Glide.with(appContext) .load(url) .into(toastIcon)然后 Toast 显示时图标区一片空白。原因是 Glide 的异步加载默认会绑定到一个ViewTarget上toastIcon此时虽然被 LayoutInflater 创建了但它并不在真实 View 树中而是被系统当作临时视图放到了 Toast 的窗口里。Glide 的加载请求完成后需要绑定到 attach 到窗口的 View 才能立即生效但 Toast 的显示生命周期太短加载慢一点就会错过显示时机。我的建议是如果图标来自网络先把 Bitmap 缓存下来再在 Toast 展示时同步设置。如果用 Glide至少用asBitmap()配合CustomTarget拿到 Bitmap 后直接setImageBitmap而不是把 ImageView 传给into。4.4 弹出顺序错乱与重复 Toast 的抑制快速连续点多个按钮会看到 Toast 一条接一条排队弹出有时显得很蠢有时还会因为上一条 Toast 还没消失、下一条已经在排队而出现“卡顿感”。控制这个问题的常见办法是在工具类里维护一个 Toast 实例新 Toast 弹出前先把上一条 cancel 掉。object ToastImageHelper { private var currentToast: Toast? null fun show(context: Context, message: String, iconRes: Int) { currentToast?.cancel() // 构建新 toast currentToast toast toast.show() } }这里要注意cancel()只能请求系统把当前 Toast 从队列里移除但如果你在极短时间连续调用系统队列可能还没来得及处理上一条的滞后回调导致上一条延迟消失后视觉效果上还是会出现“瞬闪两条”。更稳妥的做法是做节流规定同一时刻只保留最近的一到两次调用比如用一个AtomicBoolean或者Long记录上次弹出时间低于 500ms 的重复请求直接丢弃。5. 把临时方案整理成通用轻提示工具类写到这里已经能解决“在自定义类里展示带图片 Toast”的基本问题了。但如果只是在一个项目里写死几个固定资源代码复用价值其实不高。更进一步的常规演进是把它做成通用轻提示组件。5.1 静态方法封装与参数设计我最终在项目里沉淀的接口长这样object ToastHelper { fun show(context: Context, message: String) { show(context, message, 0) } fun show(context: Context, message: String, DrawableRes iconRes: Int) { showInternal(context, message, iconRes) } fun showError(context: Context, message: String) { show(context, message, R.drawable.ic_error) } fun showSuccess(context: Context, message: String) { show(context, message, R.drawable.ic_success) } }这个设计考虑了几点message单独成方法不要求调用方总是传图标这样使用门槛低iconRes为 0 时隐藏 ImageView而不是显示一个空白图标showError/showSuccess是快捷入口把最常见的两种业务场景交给调用方直接使用不用他们关心资源 id。5.2 支持网络图片延迟加载方案上面说了网络图片异步加载很容易错过 Toast 的显示时机所以我的通用版本做了妥协网络图片场景不直接走自定义 Toast而是先把图片缓存下来。实现上可以定义一个 PictureCacheobject PictureCache { private val cache LruCacheString, Bitmap(5 * 1024 * 1024) fun put(key: String, bitmap: Bitmap) { cache.put(key, bitmap) } fun get(key: String): Bitmap? { return cache.get(key) } }在网络图片加载成功的同时调用PictureCache.put(url, bitmap)等到要弹 Toast 时同步从缓存取。这种方式的优点是显示时零延迟缺点是首次加载可能还没有缓存。我的经验是弹 Toast 的场景通常是用户操作后的即时反馈真正需要展示复杂网络图标的频率不高如果一定要展示优先用本地资源或者预先下好的图标。如果产品坚持要支持网络图片并且允许延迟 100~300ms 显示那么可以这样实现fun showNetworkIconToast(context: Context, message: String, imageUrl: String) { val appContext context.applicationContext var toast: Toast? null val placeHolder LayoutInflater.from(appContext) .inflate(R.layout.view_custom_toast, null, false) toast Toast(appContext) toast.view placeHolder toast.duration Toast.LENGTH_LONG Glide.with(appContext) .asBitmap() .load(imageUrl) .into(object : CustomTargetBitmap() { override fun onResourceReady(resource: Bitmap, transition: Transitionin Bitmap?) { placeHolder.findViewByIdImageView(R.id.toast_icon) .setImageBitmap(resource) placeHolder.findViewByIdTextView(R.id.toast_message).text message toast?.show() } override fun onLoadCleared(placeholder: Drawable?) Unit override fun onLoadFailed(errorDrawable: Drawable?) { placeHolder.findViewByIdImageView(R.id.toast_icon) .setImageResource(R.drawable.ic_placeholder) placeHolder.findViewByIdTextView(R.id.toast_message).text message toast?.show() } }) }这里我建议用Toast.LENGTH_LONG给网络加载多一点容错时间。但你要有心理准备图片加载如果超过 1 秒用户体验会很差所以这个方案只适合权重很高的场景不适合通用所有 Toast。5.3 线程与生命周期安全自定义 Toast 的show()方法严格来说只要在当前线程有Looper就能跑但LayoutInflater和 UI 操作最好还是在主线程执行。你没法保证调用方一定在主线程里调用工具类所以在工具类内部做一次线程切换比较稳private fun runOnMainThread(action: () - Unit) { if (Looper.myLooper() Looper.getMainLooper()) { action() } else { mainHandler.post(action) } }同时也建议在show()里用applicationContext替代直接传入的context这样即便调用方 Activity 已经销毁Toast 也不会意外持有已被回收的 Context。如果拿到的是null直接返回而不是抛异常避免把问题放大。这里我把“返回”和“抛异常”的取舍给大家说透开发阶段抛异常能让你尽早发现问题但发布版本里由于某个第三方 SDK 传了 null 导致崩溃得不偿失所以我最终选择在 release 里静默失败、debug 里打日志。5.4 扩展成支持轻提示的完整方案做到这步你可以把整个组件再往上做一层让它兼容其他轻提示场景比如页面内浮动提示、网络错误重试提示、表单校验失败提示。思路是同一个“自定义布局 文本 图标”模板在不同场景采用不同容器Toast覆盖面广适合短暂全屏提示Snackbar适合页面内带操作按钮的提示页面顶部悬浮适合更醒目的通知。如果项目用到 Jetpack Compose也可以把同样的图标加文字组合封装成 Composable然后接入不同的展示宿主。不过那又是另一套代码了本文暂不展开。回看整条链路其实“自定义类里展示带图片的 Toast”这个需求真正难的不是 Toast 本身而是两件容易被忽略的事第一是 Context 的生命周期设计第二是系统对不同版本的 Toast 限制。只要把这两点从一开始就考虑进去后续无论怎么重构这个小组件都不会给你添乱。我在项目中最后留下的是两个小习惯也分享给你每个工具类方法第一行都先处理 Context 归一化统一转成applicationContext每个 Toast 都走同一个入口方法绝不在业务代码里散落各种Toast.makeText。慢慢你会发现为省这几行代码付出的整理成本在排查线上问题时能成倍赚回来。