iOS里的HUD： 仔细阅读iOS设计指南就会发现并没有Toast这个控件，但iOS中确实有类似于Toast样式出现，例如iOS的音量调节提示。 iOS 把这个组件叫做 UIProgressHUD（HUD意思很可能是heads up display），可惜这个组件是系统私有的，第三方App无法直接获取使用，因此出现了各种模仿它的第三方控件，例如MBProgressHUD、 SVProgressHUD还有JGProgressHUD，从此以后HUD就成了iOS开发者里达成共识的半官方概念。
被泛化的Toast： 你要是执着的把HUD念做Toast，大家也能理解，因为如今Toast的概念已经泛化，早已打破了Android的规范。
在Android正统的规范中Toast：①出现在屏幕底部。②只能放文字不能带图标，文字要精简不宜太长。③是模态的，可以透过Toast对其他控件进行操作。④短时间后会自动消失。⑤不能对Toast进行交互，不能手动操作让Toast主动消失。
在市面上很容易找到打破这个规则的Toast样式，例如加载：出现在屏幕中间、带图标，是模态的，如果网速很慢，Toast可能会持续很长时间，可以通过操作让其主动消失。
泛化使得Toast原本的定义变得模糊，拓展了很多新的使用场景。控件定义和用途的变化也在随着时间演化，演化出符合业务和用户习惯的新形式反过来又会促成新的控件定义和规范，目前在移动平台里，似乎所有半透明矩形提示和反馈都可以被称作Toast。连iOS官方的Apple Store App都开始使用类似Toast的控件。
顶部Toast： 除了Toast概念的泛化，最近不少iOS App在尝试将Toast的位置由屏幕底部和中间改到顶部，这样做有几个好处：1.出现位置稳定。不会因为软键盘出现导致原本在屏幕底部或中间的Toast被遮盖或浮动到其他位置。2.更容易引起用户注意。iOS持续录音、GPS被使用、正在通话状态、还有活动指示器和系统push通知都出现在屏幕顶部，iOS用户更习惯于在顶部感知反馈信息。3.不干扰用户浏览主体内容。Toast出现在屏幕顶部不会遮挡主体内容。
Toast的未来： Toast有很多优点：1.占用屏幕空间小。2.不会打断用户操作。3.使用简单适用范围广，人人都是会用Toast的产品经理。但Toast也有不少缺点：1.出现时间短，在碎片化时代注意力不集中容易错过Toast提示。2.虽然非模态，但是黑乎乎的样式上给人一种模态的错觉，会打断心流。3.遮盖其他控件，但不能对Toast进行交互。
更为严重的是Toast被滥用的情况比较严重，当一个App在加载、表单提示、状态变更反馈、断网消息等使用Toast，不断出现的黑乎乎矩形会对整个体验带来非常大的阻塞感，有时候甚至会同时出现两个Toast或者持续弹出同一个Toast等令人啼笑皆非的情况。
代替Toast的其他形式: 滥用Toast是懒惰的做法，设计师完全有其他形式代替Toast，达到更优雅的用户体验。
页面内提示: 这种提示可以常驻在页面里，即使用户短时间内注意力转移，提示也不会消失，确保用户能一直完整的看到。此外页面内提示能容纳更多信息量，与页面本身风格比较契合，没有阻塞感，适合表单错误提示、加载过渡。
多态按钮: 如果按钮被按下后需要与服务器交互后才能真正响应操作，那么等待难以避免。这种情况下可以给按钮增加多个状态，让用户知道App已经接受到他的操作。典型的例子是支付宝的确认付款按钮，拥有付款前、正在付款和付款成功三个状态，反馈明显不需要额外再用Toast进行提示。
动效: 优雅的动态效果能给吸引用户注意力，富含情感给用户留下深刻印象。事物之间的关系可以通过动效进行隐喻。例如电商App加入购物车，商品飞入购物车中，有趣流畅。
震动和声音: 除了屏幕内反馈，屏幕外的反馈效果更强烈更真实。例如拍照时“咔擦”声音，还有启动静音模式时手机震动。考虑到手机放在包里感知不到震动或者手机音量太小，因此声音和震动建议作为辅助反馈手段。
Snackbar: Snackbar可以理解为是加强版的Toast。样式和规则与Toast非常相似，不同主要有两点：1.Snackbar支持主动滑动关闭。2.Snackbar可以附带一个操作（也可以不带）。
Toast是Android中用来显示显示信息的一种机制，和Dialog不一样的是，Toast是没有焦点的，而且Toast显示的时间有限，过一定的时间就会自动消失。默认效果,代码为： Toast.makeText(getApplicationContext(), "默认Toast样式",记录下在使用系统Toast存在的问题:
1. 当通知权限被关闭时华为等手机Toast不显示
2. Toast队列机制上在不同手机上可能不同
3. Toast的BadTokenException问题
当发现系统Toast存在问题时,不少同学使用自定义TYPE_TOAST弹框来实现相同效果.虽然情况下效果都是OK的,但TYPE_TOAST依然会存在问题:
4. Android8.0之后的token null is not valid问题(实测部分机型问题)
5. Android7.1之后，不允许同时展示两个TYPE_TOAST弹窗(实测部分机型问题)
那么解决方案是:
相信不少同学旧项目中封装的ToastUtil都是直接使用的ApplicationContext作为上下文，然后在需要弹窗的时候直接就是ToastUtil.show(str)，这样的使用方式对于我们来说是最方便的啦。
当然，使用YToast你也依然可以沿用这种封装方式，但这种方式在下面这个场景中可能会无法成功展示出弹窗(该场景下原生Toast也一样无法弹出)，不过请放心不会导致应用崩溃，而且这个场景出现的概率较小，有以下三个必要条件：
1.通知栏权限被关闭(通知栏权限默认都是打开的)
2.非MIUI手机
3.Android8.0以上的部分手机(我最近测试中的几部8.0+设备都不存在该问题)。
不过，如果想要保证在所有场景下都能正常展示弹窗，还是建议在YToast.make(context)时传入Activity作为上下文，这样在该场景下YToast会启用ActivityToast展示出弹窗。
接下来再详细分析下上面提到的五个问题。
看下方Toast源码中的show()方法，通过AIDL获取到INotificationManager，并将接下来的显示流程控制权交给NotificationManagerService。NMS中会对Toast进行权限校验，当通知权限校验不通过时，Toast将不做展示。
当然不同ROM中NMS可能会有不同，比如MIUI就对这部分内容进行了修改，所以小米手机关闭通知权限不会导致Toast不显示。
如何解决这个问题？只要能够绕过NotificationManagerService即可。
YToast通过使用TYPE_TOAST实现全局弹窗功能，不使用系统Toast,也没有使用NMS服务，因此不受通知权限限制。
我找了四台设备，创建两个Gravity不同的Toast并调用show()方法,结果出现了四种展示效果：
造成这个问题的原因应该是各大厂商ROM中NMS维护Toast队列的逻辑有差异。
同样的，YToast内部也维护着自己的队列逻辑，保证在所有手机上使用DToast的效果相同。
YToast中多个弹窗连续出现时：
相同优先级时，会终止上一个，直接展示后一个；
不同优先级时，如果后一个的优先级更高则会终止上一个，直接展示后一个。
什么情况下windowToken会失效？
UI线程发生阻塞，导致TN.show()没有及时执行，当NotificationManager的检测超时后便会删除WMS中的该token，即造成token失效。
如何解决？
因此对于8.0之前的我们也需要做相同的处理。YToast是通过反射完成这个动作，具体看下方实现：
Android8.0后对WindowManager做了限制和修改，特别是TYPE_TOAST类型的窗口，必须要传递一个token用于校验。
API25：（PhoneWindowManager.java源码）
API26：（PhoneWindowManager.java源码）
为了解决问题一，DovaToast不得不选择绕过NotificationManagerService的控制，但由于windowToken是NMS生成的，绕过NMS就无法获取到有效的windowToken，于是作为TYPE_TOAST的DovaToast就可能陷入第四个问题。
因此，DToast选择在DovaToast出现该问题时引入ActivityToast，在DovaToast无法正常展示时创建一个依附于Activity的弹窗展示出来，不过ActivityToast只会展示在当前Activity，不具有跨页面功能。
如果说有更好的方案，那肯定是去获取悬浮窗权限然后改用TYPE_PHONE等类型，但悬浮窗权限往往不容易获取，目前来看恐怕除了微信其他APP都不能保证拿得到用户的悬浮窗权限。
YToast的弹窗策略就是同一时间最多只展示一个弹窗，逻辑上就避免了此问题。因此仅捕获该异常。
其他建议
如果能够接受Toast不跨界面的话，建议使用SnackBar
