Android我还可以相信你多少系列文章四之悬浮窗

我即将在2017.7.8号开一个直播讲堂，感兴趣的同学点击快来参加吧：https://segmentfault.com/l/15...
内容包括：

Android 知识体系分享

从入门到提高的学习路径

如何进一步突破瓶颈，进一步提升

充足的时间和大家讨论，回答大家问题

自我介绍：

网易 Android 专家工程师，网易云音乐 Android 负责人，主导从零开发了网易云音乐 Android
客户端，目前是杭州研究院专业委员会成员，负责每年的评级，规范起草，面试招聘等相关工作。参与并制作了网易云课堂 Android
微专业相关课程，反响不错。

悬浮窗应该算各大厂商最先开始对应用下手的地方。

悬浮窗之所以讨人厌同样是因为被滥用，就像狗皮膏药一样贴在屏幕的上下左右，不管切换到哪个应用始终显示在最上层。悬浮窗的需求有点从电脑端延续的味道，以前桌面上经常跑出来个狮子，有个悬浮球，或者歌词。但那个时候占用桌面面积小，相比手机屏幕尺寸，现在的悬浮窗很容易覆盖住真正内容。那Android上面悬浮窗最初设计是想解决什么问题呢？

悬浮窗也即一个Window。Window Type有很多种，比如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)) {
  Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION, Uri.parse("package:" + getPackageName()));
   startActivityForResult(intent, 10);
}

为什么TYPE_TOAST不需要权限仍然不得而知。事实上从某一次跟官方的现场交流会上，官方人员也承认悬浮窗事实上也不是设计给应用用的。而且当他们惊讶的发现国内市场悬浮窗的需求如此强大之后，他们做了一件惊人的改变：就是在Android O上面针对国内市场悬浮窗需求特别修改了悬浮窗的设计。

在Android O上面特别增加了TYPE_APPLICATION_OVERLAY来满足悬浮窗需求。需要注意的是即使你的应用TargetSdk不是等于O版本，可以继续使用TYPE_PHONE（O版本已废弃），但会显示在TYPE_APPLICATION_OVERLAY下面（所以想要显示在最上面要尽快适配O版本）。在使用TYPE_APPLICATION_OVERLAY的时候，系统还会进行提示是否允许该应用显示悬浮窗。

悬浮窗在国内的市场环境下有几个问题：

6.0以下即使Manifest里面定义了，也会被厂商自己扩展出来的悬浮窗开关默认禁掉

TYPE_TOAST在MIUI等机器上面被当做等同于TYPE_PHONE需要SYSTEM_ALERT_WINDOW权限

开发者需要做的事情：

优先使用TYPE_TOAST，但需要注意4.4版本之前无法接收事件也即无法交互以及MIUI问题。

6.0及以后使用动态权限申请一般不会有问题，6.0之前可以根据机型动态下发权限打开页面的路径，来做到提醒用户去打开权限。尽可能引导用户，否则就等着来反馈为啥显示不了。

留意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了。