悬浮窗应该算各大厂商最先开始对应用下手的地方。
悬浮窗之所以讨人厌同样是因为被滥用，就像狗皮膏药一样贴在屏幕的上下左右，不管切换到哪个应用始终显示在最上层。悬浮窗的需求有点从电脑端延续的味道，以前桌面上经常跑出来个狮子，有个悬浮球，或者歌词。但那个时候占用桌面面积小，相比手机屏幕尺寸，现在的悬浮窗很容易覆盖住真正内容。那Android上面悬浮窗最初设计是想解决什么问题呢？
悬浮窗也即一个Window。WindowType有很多种，比如TYPE_PHONE，TYPE_TOAST，TYPE_SYSTEM_ALERT等，用在来电，低电量显示，状态栏，短暂toast提醒等。Android系统给每一种Window类型定义了一个高度，依次从上往下显示。官方文档描述是这样的：
文档里面说：下面这些值是系统定义的window类型，他们不是给普通应用用的。
既然不是预定义给应用用的，为啥应用能用呢？
从源码来看（摘自4.4版本，6.0以后版本权限管理更加严格），TYPE_TOAST的注释表明似乎是一段未写完的代码。而像TYPE_PHONE这类则是需要SYSTEM_ALERT_WINDOW权限，在6.0之前这是非常容易获取到的，只要在Manifest里面申明下即可。6.0以后需要运行时动态申请这个权限，申请方式跟普通的地理位置权限还不太一样，如下的方式：
if(!Settings.canDrawOverlays(MainActivity.this)){Intentintent=newIntent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION,Uri.parse("package:"+getPackageName()));startActivityForResult(intent,10);}
为什么TYPE_TOAST不需要权限仍然不得而知。事实上从某一次跟官方的现场交流会上，官方人员也承认悬浮窗事实上也不是设计给应用用的。而且当他们惊讶的发现国内市场悬浮窗的需求如此强大之后，他们做了一件惊人的改变：就是在AndroidO上面针对国内市场悬浮窗需求特别修改了悬浮窗的设计。
在Android O上面特别增加了TYPE_APPLICATION_OVERLAY来满足悬浮窗需求。需要注意的是即使你的应用TargetSdk不是等于O版本，可以继续使用TYPE_PHONE（O版本已废弃），但会显示在TYPE_APPLICATION_OVERLAY下面（所以想要显示在最上面要尽快适配O版本）。在使用TYPE_APPLICATION_OVERLAY的时候，系统还会进行提示是否允许该应用显示悬浮窗。
悬浮窗在国内的市场环境下有几个问题：
1.6.0以下即使Manifest里面定义了，也会被厂商自己扩展出来的悬浮窗开关默认禁掉
2.TYPE_TOAST在MIUI等机器上面被当做等同于TYPE_PHONE需要SYSTEM_ALERT_WINDOW权限
开发者需要做的事情：
1.优先使用TYPE_TOAST，但需要注意4.4版本之前无法接收事件也即无法交互以及MIUI问题。
2. 6.0及以后使用动态权限申请一般不会有问题，6.0之前可以根据机型动态下发权限打开页面的路径，来做到提醒用户去打开权限。尽可能引导用户，否则就等着来反馈为啥显示不了。
3.留意Android O对悬浮窗做出的重大修改对自己造成的影响
TYPE_TOAST在7.1版本上面还有一些小修改，一个uid只能加一个；曾经比较流行将Toast作为一个单例，隐藏toast的时候修改view的visibility为gone来替换removeView，然后通过不断setText和setVisibility为VISIBILE来实现Toast内容快速切换（原生Toast必须要等duration时长消失后再出现下一个）。使用这种方式在7.1版本上面会出现问题，该版本上面在应用失去焦点的时候会有个定时器自动隐藏掉这个Toast Window，setText和setVisibility无法恢复显示这个Window了。
WindowManagerService里面有两处判断焦点失去之后起定时器隐藏Toast Window。我们可以显示removeView之后再addView来进行兼容。
更多文章和互动请关注微信公众号：anzhuozhimei
网友评论