先把结论放前面微信语音通话那种悬浮窗技术上并不复杂核心就三件事——WindowManager、WindowManager.LayoutParams、还有一套能陪你折腾半天的生命周期管理。很多人一听到“悬浮窗”就以为是系统级悬浮窗要申请“悬浮窗权限”要在设置页里手动开启实际上微信语音通话用的是应用内悬浮窗走的是Activity级别的Window机制根本不需要悬浮窗权限。搞明白这一点方向就不会跑偏。这篇文章会按照我实际做过的方案把整个实现思路、关键代码、踩坑记录全部过一遍。适合有Android基础、想在自己项目里做类似“语音通话最小化”效果的开发者也适合刚接触Window机制、对悬浮窗原理还不透的朋友。1. 先搞清楚你要做的是“应用内悬浮窗”不是系统级悬浮窗1.1 两种悬浮窗的区别悬浮窗按作用域分成两种一种是应用内悬浮窗窗口只出现在自己App的界面之上离开App就看不见了另一种是系统级悬浮窗需要申请SYSTEM_ALERT_WINDOW权限窗口能悬浮在所有应用之上甚至能显示在桌面。微信语音通话的悬浮窗属于前者。你切到其他App时微信会退回到后台通话悬浮窗只在你回到微信后还在它本质上是驻扎在微信自己的Task里的一个小窗口。如果你的需求是“退出应用后悬浮窗仍然可见”那才需要系统级悬浮窗。这个区分决定了整个实现方案的走向。应用内悬浮窗不需要权限申请不涉及系统设置页的引导也不需要处理Android 6.0以上的悬浮窗权限弹窗开发成本低一大截。但代价是悬浮窗的“生命周期”和Activity绑定Activity销毁了窗口就没了所以做的时候要在合适的时机重建。1.2 为什么微信选应用内方案微信没有采用系统级悬浮窗一是因为系统级悬浮窗的权限弹窗在国产ROM上极其不可控——MIUI、EMUI、Flyme各家对权限的管理策略差异很大用户不授权就完全没法用二是因为语音通话悬浮窗的目的是“方便用户在微信内继续操作”不需要跨应用显示。我在实际项目里也碰到过类似需求当时产品想做一个“边看视频边回复消息”的悬浮窗最后评估还是用了应用内方案理由很简单用户只有在App内部才有回复消息的场景跨应用场景根本不存在。所以动手之前先问自己一句“我的悬浮窗需要出现在其他应用上面吗”不需要的话老老实实做应用内悬浮窗省下的权限适配工作量够你写好多业务代码了。2. 整体架构与窗口管理设计2.1 WindowManager的基本用法Android里所有窗口都是通过WindowManager添加的Activity的setContentView底层也是这个机制。实现悬浮窗的通用套路是WindowManager windowManager (WindowManager) context.getSystemService(Context.WINDOW_SERVICE); WindowManager.LayoutParams params new WindowManager.LayoutParams( WindowManager.LayoutParams.WRAP_CONTENT, WindowManager.LayoutParams.WRAP_CONTENT, WindowManager.LayoutParams.TYPE_APPLICATION_PANEL, WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE, PixelFormat.TRANSLUCENT ); windowManager.addView(suspendView, params);关键在第三个参数window type。TYPE_APPLICATION_PANEL表示这是一个应用内的面板窗口它要跟一个“宿主窗口”关联悬浮窗会显示在宿主Activity之上。还有个参数是token用来和宿主绑定一般通过Activity.getWindow().getAttributes().token获取。用TYPE_APPLICATION_PANEL的好处是窗口不会跑到其他应用上去即使用户切到别的App这个悬浮窗也会跟着宿主Task隐藏不会产生跨应用的视觉残留。这是微信语音通话悬浮窗能保持行为干净的重要原因。如果你想省掉token的关联可以用TYPE_APPLICATION_ATTACHED_DIALOG但实际体验下来这玩意儿在某些机型上层级不对容易出现“悬浮窗跑到Dialog下面”的尴尬问题。我个人推荐直接上TYPE_APPLICATION_PANEL坑最少。2.2 布局结构设计悬浮窗的布局要讲究。微信语音通话悬浮窗分为两个状态展开态和收起态。展开态是一个大概120dp宽的圆角卡片显示对方名字、通话时长、麦克风开关、挂断按钮收起态是缩小成一个小圆球通常是一个50dp左右的圆形只显示通话中图标或头像。我建议把两种状态做成两个独立的View不要试图用一个View去调整尺寸和内容。原因有二第一动画变化如果用scale动画内容会跟着变形圆形头像会被压成椭圆第二状态切换时View自身的measure/layout逻辑会变得复杂遇到文字换行、按钮排列的问题非常难调。更好的做法是维护两个View实例通过addView和removeView做切换。切换时用TranslateAnimation或ScaleAnimation做一个过渡动画视觉上顺畅很多。代码层面用一个Status枚举维护当前状态public enum FloatStatus { EXPANDED, COLLAPSED }切换状态时先判断当前状态旧View移除新View添加加动画时不打断用户的视觉连贯性。在动画结束后再做状态变更回调避免在动画过程中用户又触发了一次点击导致状态错乱。2.3 任务栈与Activity生命周期策略悬浮窗的生命周期必须和宿主Activity同步。最常见的做法是监听宿主Activity的onPause、onStop、onDestroy分别处理悬浮窗的隐藏、恢复和销毁。有个细节很多新手会忽略语音通话悬浮窗的“最小化”动作本身其实是一个新的Activity。微信的实现里通话界面会启动一个透明或者小尺寸的Activity承载悬浮窗而原来的通话主界面在后台被finish或者只是stop了。我在项目里采用的方式是通话Activity检测到用户按下Home键或者点了“最小化”按钮时不是finish自己而是启动一个FloatActivity把悬浮窗内容放进去。这样悬浮窗虽然不是传统意义的“窗口”但拥有了Activity的完整生命周期切后台、回前台、内存回收时系统都能正确处理。这种方法唯一的代价是多一个Activity的启动开销但在现在的手机性能面前基本可以忽略。换来的是生命周期处理变得极其清晰onCreate里addViewonDestroy里removeView不会出现窗口和Activity生命周期不同步的泄漏问题。2.4 为什么不用View加到DecorView上有人会问“我在Activity的ContentView上加一个View设置TranslationX/Y不也能实现拖动效果吗何必用WindowManager”能用但不推荐。加到DecorView上的View会随着页面跳转、键盘弹起、沉浸式布局变化而错乱。尤其通话过程中如果拉起了一个权限弹窗或者系统键盘DecorView的布局会被重新测量悬浮窗的位置就会窜。WindowManager管理的窗口是独立层级不受Activity布局变化影响悬浮窗在该在的位置就在哪痛少很多。另外加在WindowManager里的View可以设置FLAG_NOT_FOCUSABLE避免悬浮窗抢焦点微信语音通话的悬浮窗即使展开状态下点击里面的按钮也不会让背后的Activity失焦用户操作体验和直接操作Activity没有区别。3. 核心实现初始化、拖拽与动画细节3.1 初始化WindowManager.LayoutParams初始化这一步是整个悬浮窗实现的地基参数设置有讲究。我常用的参数配置WindowManager.LayoutParams params new WindowManager.LayoutParams(); params.width dp2px(120); params.height dp2px(64); params.type WindowManager.LayoutParams.TYPE_APPLICATION_PANEL; params.flags WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE; params.format PixelFormat.TRANSLUCENT; params.gravity Gravity.TOP | Gravity.START; params.x 0; params.y 0; params.token activity.getWindow().getAttributes().token; params.windowAnimations android.R.style.Animation_Translucent;width和height可以是固定值也可以用WRAP_CONTENT。固定值的好处是拖拽计算的边界更可控但内容如果动态变化比如时间从“12:34”变成“12:34:56”可能会出现文字溢出。所以我更推荐用一个完整的布局容器外层固定尺寸内层自适应。FLAG_NOT_FOCUSABLE是必须的。如果不加这个flag悬浮窗会抢占焦点按下返回键时先关闭悬浮窗而不是先处理Activity的返回逻辑这种体验很怪。还有一些额外flag可以按需加FLAG_NOT_TOUCH_MODAL不阻塞Activity的其他触摸事件、FLAG_LAYOUT_NO_LIMITS允许窗口超出屏幕边界拖拽动画更自然。3.2 拖拽与跟手效果拖拽的核心是监听悬浮窗的onTouchEvent或者直接在addView前给View设置OnTouchListener。监听ACTION_DOWN记录初始坐标和触摸点位置ACTION_MOVE时计算偏移并更新params.x和params.y。case MotionEvent.ACTION_MOVE: { params.x initialX (int) (event.getRawX() - downRawX); params.y initialY (int) (event.getRawY() - downRawY); windowManager.updateViewLayout(suspendView, params); return true; }注意一定用getRawX/getRawY因为悬浮窗本身的getX/getY是相对父容器的坐标在窗口更新时会变得很不可靠。我第一版实现就用了event.getX()结果拖拽到一半悬浮窗会突然跳一下排查了很久才发现是坐标系的锅。updateViewLayout调用频率很高ACTION_MOVE期间几乎每帧都在调。首先要保证不要在主线程里做耗时操作。其次建议在移动过程中用params.x/params.y直接赋值不要反复new LayoutParams对象免得触发额外的GC。实测下来这个方案在绝大多数手机上都能保持跟手即使是在低端机上性能也能接受。3.3 拖拽结束吸附边缘微信语音通话悬浮窗拖出去之后松手会自动滑到屏幕边缘。这个是悬浮窗体验的关键就要靠动画把窗口移动到位。我常用的做法是拖拽松手后判断悬浮窗中心点离屏幕哪条边近然后计算目标坐标int screenWidth getScreenWidth(); int centerX params.x viewWidth / 2; int targetX; if (centerX screenWidth / 2) { targetX 0; } else { targetX screenWidth - viewWidth; }然后用ValueAnimator或ObjectAnimator做位移动画动画时长150ms到200ms插值器用DecelerateInterpolator。动画过程中需要实时调用updateViewLayout。用ObjectAnimator可以直接对自定义属性做动画写法比较简洁。需要注意一点动画结束时一定要在onAnimationEnd里更新params的最终值防止动画因为某种原因中断后坐标没对上。吸附边缘后还有个细节如果悬浮窗不小心被拖到了屏幕最顶上或最底下得处理上下边界。通常的做法是让悬浮窗始终停留在屏幕可见区域内至少留一点边缘阻尼避免用户无法完全拖出去。3.4 点击和长按手势的冲突处理悬浮窗既要能拖动又要能点击展开、长按实现更多功能。这就涉及到手势判定。我的策略是用触摸移动距离判断ACTION_DOWN之后如果移动超过系统TouchSlop阈值就认为是拖动否则松手时按点击处理。if (event.getAction() MotionEvent.ACTION_UP) { if (Math.abs(event.getRawX() - downRawX) touchSlop Math.abs(event.getRawY() - downRawY) touchSlop) { performClick(); } }TouchSlop可以通过ViewConfiguration.get(context).getScaledTouchSlop()拿到。注意这里的performClick不是View自带的performClick而是自己去触发悬浮窗的展开逻辑不要依赖ViewConfiguration的Clickable属性否则会出现拖动结束还会触发Click的误判非常烦人。3.5 展开收起动画展开收起动画我建议用两种方式配合尺寸变化用View的layoutParams动画内容切换用透明度渐变。展开时把CollapsedView的alpha动画设为0ExpandedView的alpha从0到1同时把ExpandedView的宽高从0或小值撑到目标尺寸。收起时反过来。这个动画看起来简单但有个常见的坑动画过程中要不断更新params.width和params.height如果直接用View的layoutParams而不是WindowManager的LayoutParams窗口不会正确变化。必须用updateViewLayout(params)一起更新宽高和坐标。如果你觉得这里太绕有另一个偷懒方案悬浮窗本身尺寸不变切换时直接用setVisibility去切换内部的两个子View。缺点是整体尺寸始终等于较大状态那一个视觉上不够“灵动”。考虑到语音通话悬浮窗不是高频交互我推荐还是做一次真正的尺寸动画体验会好很多。3.6 生命周期与内存泄漏规避悬浮窗持有Activity的Context引用是最容易内存泄漏的地方。用context.getApplicationContext()创建View会导致WindowManager无法正确添加窗口没有Window token的窗口添加不了所以实际只能用Activity的Context。规避方法在Activity的onDestroy里必须removeView并且把View的引用置空。最好再配合一个BaseActivity声明周期回调来统一管理Override protected void onDestroy() { super.onDestroy(); if (windowManager ! null suspendView ! null) { windowManager.removeView(suspendView); suspendView null; } }还有一个常见泄漏场景View里注册了BroadcastReceiver或者EventBus悬浮窗销毁时没有注销。我踩过一次坑悬浮窗里有一个计时器Textview用Handler每秒更新一次结果Activity销毁后Handler还活着导致整个Activity泄漏。后来用了LifecycleObserver统一处理class FloatLifecycleObserver implements DefaultLifecycleObserver { Override public void onDestroy(LifecycleOwner owner) { removeFloatWindow(); } }这个方案比在各种Callback里手动remove要干净得多而且和Activity的Lifecycle绑定得更紧密推荐。4. 实战排障常见问题与排查实录4.1 悬浮窗不显示 / 显示了但拿不到焦点最常见的“不显示”原因是type选错了。用TYPE_APPLICATION_PANEL的时候如果没有传token或者token传的是null窗口会创建失败而且Activity还不报错日志里也看不到明显异常。要检查三处确保token来自你要悬浮的Activity的Window不是Application的。确保addView调用在Activity的onCreate之后不要在Application.onCreate这种没有Window的环境里调用。检查params.width/height是否有值如果两个都是0或者MATCH_PARENT可能窗口被撑满了或者被裁掉了。拿不到焦点的问题基本是FLAG_NOT_FOCUSABLE没设置全。注意除了flag设置View本身不能设置clickable/focusable为true不然还是会抢占焦点。我在做通话悬浮窗时遇到过一次Toast弹完后悬浮窗突然不可点击了最后发现是有个后台进程把窗口的某些flag改了排查起来非常隐蔽。这种问题推荐在addView后打日志把params的flags、focusable状态都打出来比对正常和异常路径效率会高很多。4.2 拖拽后悬浮窗坐标跳变坐标跳变三个高发原因使用了getX()而不是getRawX()导致在触摸过程中基准坐标系被updateViewLayout改变了。屏幕旋转后没有重新计算悬浮窗位置导致悬浮窗跑到屏幕外。横竖屏切换时params.x/params.y没有重置窗口显示在系统栏下面。横竖屏的处理比较麻烦我的方案是监听ConfigurationChanged在屏幕方向变化时暂停窗口动画把悬浮窗重新摆到屏幕中间或者原来的相对位置。如果懒得做动画至少在onConfigurationChanged里reset一次params坐标到默认值别让用户“找不到悬浮窗”。4.3 updateViewLayout频繁调用触摸卡顿拖拽本身每帧都在updateViewLayout部分中低端机上会卡。优化的思路有三个在拖拽过程中关闭悬浮窗内部的动画比如Textview的计时刷新频率降低到1秒一次不要在每帧都触发invalidate。减少View层级悬浮窗的布局不要嵌套太深避免每帧measure/layout太重。用FLAG_LAYOUT_NO_LIMITS让窗口不限制在屏幕边界可以减少系统对窗口的layout边界计算。实测下来这三招用完哪怕在骁龙4系的机器上拖拽都基本不掉帧了。不过这也要看你悬浮窗内部内容的复杂度如果里面有个视频预览SurfaceView那性能的瓶颈就在SurfaceView的合成上这种场景建议把悬浮窗做成单独的表面而不是普通View。4.4 悬浮窗和软键盘冲突如果悬浮窗需要弹出输入框比如蓝牙耳机名称编辑软键盘会把悬浮窗顶上去甚至挡住。通常用adjustResize和adjustPan解决但悬浮窗不属于普通Activity的ContentViewadjustResize对它无效。我的方案是监听ViewTreeObserver.OnGlobalLayoutListener软键盘弹出时如果是展开态就把悬浮窗往上移动一段距离收起时恢复。高度可以通过rootView.getRootWindowInsets()算出键盘高度然后直接调整params.y注意params.y的值要加上原来的偏移量不要直接覆盖。4.5 双窗口重叠多次调用addViewActivity恢复时可能触发多次onResume导致addView被重复调用出现两个悬浮窗叠在一起。解决办法是addView之前检查if (suspendView.getParent() null) { windowManager.addView(suspendView, params); }但View.getParent()在WindowManager里不能保证100%可靠因为窗口移除后parent可能为null了。更稳妥的方式是维护一个AtomicBoolean状态标记或者统一交给LifecycleObserver回调去add/remove不要直接在onResume里裸调用addView。4.6 悬浮窗遮挡应用内容有网友问过“悬浮窗会不会挡住App自己的按钮”答案会。应用内悬浮窗显示在Activity之上会拦截触摸事件。如果悬浮窗恰好覆盖了某个重要的操作按钮用户体验会很糟糕。解决办法有两个方向一是降低悬浮窗尺寸用小圆点形态尽量减少遮挡面积。二是收到对应用户的明显操作时自动切换成收起态。比如用户在悬浮窗周围滑动时把悬浮窗往边缘再吸附一点。微信语音通话悬浮窗用的是第一种思路收起状态是一个很小的头像几乎不遮挡内容。等到用户需要操作时才展开展开状态是主动行为不打扰正常操作。4.7 某些机型上悬浮窗不响应触摸小米部分机型上TYPE_APPLICATION_PANEL的窗口触摸事件会被系统拦截表现为悬浮窗点击没反应。这类问题一般是系统对窗口类型的触摸分发策略有差异。稳妥做法是换成TYPE_APPLICATION_ATTACHED_DIALOG或者TYPE_PHONE但要评估是否需要系统权限。如果做的是系统级悬浮窗那就绕不开权限申请。我的经验是先把权限判断逻辑写好权限没通过时给用户一个引导浮层点击跳转到设置页并在onResume里重新检查权限结果。不推荐用反射去操作系统悬浮窗开关这属于黑科技在Android 10以后的机型上基本都被封了稳定性不值得投入。5. 进阶扩展从应用内悬浮窗升级到系统级悬浮窗5.1 权限申请与适配如果产品经理非要“退出App之后还能看悬浮窗”那就老老实实做系统级悬浮窗绕不开权限。Android 6.0以上用Settings.canDrawOverlays(context)检查没有权限时用Intent跳转设置页Intent intent new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse(package: getPackageName())); startActivity(intent);需要声明SYSTEM_ALERT_WINDOW权限uses-permission android:nameandroid.permission.SYSTEM_ALERT_WINDOW /系统级悬浮窗的type要改为TYPE_APPLICATION_OVERLAYAndroid 8.0以上强制使用目标API在29以下才可以用TYPE_PHONE。窗口层级上TYPE_APPLICATION_OVERLAY不低于普通Activity但低于系统弹窗千万别做弹窗浮层悬浮在上面会被系统管理机制限制。5.2 系统级悬浮窗的冻结与恢复系统级悬浮窗最大的痛苦是息屏后、切App后的状态管理。建议用服务承载悬浮窗而不是Activity。服务在后台运行通过onStartCommand接收命令来addView/removeView这样即使Activity被回收窗口还能存在。但注意Android 8.0后后台服务在熄屏一段时间后会被系统冻结悬浮窗不一定能实时响应触摸。我的经验是语音通话类场景必须保持前台服务利用前台服务通知的“call”类型或者“mediaPlayback”类型来保活。如果不保活用户的耳机控制马上就失灵了体验极差。5.3 和画中画模式的取舍如果你需要的是“上层的、不遮挡的小窗”Android自带画中画PIP模式在Android 8.0以上也覆盖了大多数场景。PIP模式有系统级窗口能力有自动的动画和尺寸管理不用自己写拖拽逻辑省很多事。但PIP模式的UI布局比较受限只能用RemoteViews或一个简单的Activity内容自定义程度远不如WindowManager方案。微信语音通话悬浮窗没选PIP我猜测是因为需要高度自定义的UI和交互——音量滑条、麦克风控制、联系人信息PIP模式下实现这些很痛苦。如果你只是想让视频电话在通话中变成小窗优先评估PIP如果有复杂的交互和UI再考虑WindowManager方案。5.4 内存与性能的进阶考虑系统级悬浮窗常驻内存需要更严格地控制View的等级和内存占用。不要在悬浮窗里加载高分辨率图片不要用多层半透明叠加这些都会增加合成开销。我自己的经验法则是悬浮窗View层级控制在3层以内背景层用圆角Drawable而不是Bitmap图片用VectorDrawable或者压缩后的位图Textview减少重绘次数。实测150dp的悬浮窗内容内存占用控制在5MB以内问题不大超出这个数说明布局或者图片加载逻辑有问题该优化就优化。6. 悬浮窗功能还可以怎么玩做完了基础功能后有些扩展点还是挺有意思的我把个人试过的几个方向列一下6.1 多Surface播放器如果你在悬浮窗里放一个视频通话画面那就不能只用普通View了需要SurfaceView或者TextureView。注意SurfaceView有单独的Surface悬浮窗的背景层和Surface之间可能会出现黑色闪屏处理方法是给SurfaceView设置zOrderOnTop或zOrderMediaOverlay。我在项目里实测过TextureView比SurfaceView稳定一些因为它走的是硬件层合成不会穿帮。但TextureView的内存开销稍微更大而且不支持在低端机器上做画面旋转SDK 26前有兼容问题。在悬浮窗里播视频推荐用TextureView。6.2 语音动画与视觉反馈通话悬浮窗里加一个声波动画原地画圈圈或者波动条会让用户觉得“这个悬浮窗是活的”。实现方式就是自定义View在onDraw里根据音量大小画不同长度的线段或者用Canvas.drawCircle画扩散波纹。这里要控制好动画帧率每帧更新幅度不要太大否则CPU占用率飙升。实测下来6dB音量区间映射6-7根动感条30fps的动画CPU占用可以控制在2%以内。再加一个自定义属性动画整体效果就很像样了。6.3 手势区域与防误触悬浮窗上的按钮如果太小用户容易误触。我的做法是把可点击区域扩大用TouchDelegate或者直接加大按钮的透明响应区。比如一个24dp的关闭按钮实际可点击区域是32dp甚至40dpAndroid的点击目标最小建议是48dp悬浮窗按钮受尺寸限制但也尽量做到40dp。另一个思路悬浮窗整体可以上下滑动调节音量按钮就不做那么密集了。微信就是这么做的上下滑动调节音量左右滑动切换通话对象交互效率很高。实现并不复杂就是onTouchEvent里根据滑动方向和距离映射到不同的功能。6.4 双指缩放如果你想给悬浮窗加“缩放”功能双指pinch手势判定可以用ScaleGestureDetector监听缩放比例后动态修改params.width/height同时要重新计算params.x/params.y保持中心点不变。这个交互在视频悬浮窗中很实用但是涉及的计算量会多一些要注意边界判断别让窗口小于最小尺寸或者大于屏幕的一半。7. 写在最后我做这个功能的一些体会悬浮窗功能看起来就是个“小窗口”但真正深度做完一遍后你会发现它牵扯到Android整个窗口体系、事件分发体系、生命周期管理还考验你对各种机型适配的耐心。我个人的一点体会是悬浮窗的实现并不难难的是“何时显示、何时隐藏、何时允许拖、何时不允许拖”这些状态判断。一定要把状态机设计好先画清楚状态流转图再动手写代码。等代码写完了再回头优化动画和交互细节。如果一开始就直接写拖拽和动画后面加状态逻辑会改得怀疑人生。另外一个经验是悬浮窗类的功能一定要有完善的日志开关Debug模式下把每次addView/removeView/updateViewLayout、参数变更都打出来。这个问题排查太重要了。好多“神奇消失”的悬浮窗bug最后都是靠日志比对定位到是某个回调里多了一次removeView。最后再分享一个细节布局文件里的悬浮窗背景不要用纯色Drawable用圆角Drawable加一点半透明能做到微信那种“毛玻璃”的伪效果。我需要特别说明真正的毛玻璃效果要用RenderEffect或者Elevation加模糊但大多数项目根本不需要一个圆角半透明Drawable配合android:elevation的阴影视觉上已经非常干净了。希望这篇文章能帮你把Android悬浮窗这件事彻底吃透。如果有什么实现细节没有写清楚的地方按上面的思路自己动手做一遍应该能踩掉80%的坑。踩完剩下的20%欢迎来交流一起填坑。