【Android】当关闭通知权限后无法显示Toast的解决方案V2.0

##前言 既然能看到这篇博文，就说明你一定看过这个【Android】当关闭通知消息权限后无法显示系统Toast的解决方案 。然后，我很开心的告诉你，兄弟，可能你们的心病这次就解决了~当然，没看过上一篇博文的还是建议看下，看看以前的解决思路，看看之前的实现方式和一些遇到的问题，说不定对你也很有收获呢。 ##怎么使用 github地址：https://github.com/Blincheng/EToast2 如果大家有任何什么问题，欢迎大家加入EToast交流群和我一起讨论和改进。 QQ群：EToast交流群 群号码：547279762 更新日志：（具体请移步到 github查看）

v2.2.1（2019年5月28日10:24:41）

在2.2.0的基础上优化初始化方式，无需手动初始化，在集成后直接使用EToastUtils.show(text)即可使用。 技术说明： 主要实现方式参考了Lifecycle组件的初始化的方式，通过自定义ContentProvider去初始化一些库或者其他的内容。

V2.2.0（2018年11月15日15:25:20）来了，米娜桑，我还没有忘记大家~

希望本次修改，可以做到适配全部机型和系统(吧？)，发现任何问题可以在Issues中留言或者直接进群联系群主。

新增EToastUtils，需要在Application中注册EToastUtils，调用方法为EToastUtils.show(text); 适配到Android 9，对于Android M以下的机型直接绕过悬浮窗权限弹出全局Toast 优化对context使用Application的支持，前提是需要提前在Application中注册EToastUtils

Step 1. Add the JitPack repository to your build file

Step 2. Add the dependency

然后，就大大咧咧的用吧

EToast 一个关闭系统消息通知后依然可以显示的Toast，此版本完全是独立于v1.x.x的版本，实现方式上也是完全的不同，尽量的参考系统Toast的源码去实现。 和上代EToast相比，有以下的改动：

由于在Android5.0以下无法获取是否打开系统通知权限，所以为了防止用户看不到Toast，最终的逻辑优化了一下：

需要注意的是，此Toast非彼Toast，应该使用“import com.mic.etoast2.Toast”，建议在BaseActivity中如下使用：

好了，没有兴趣想看看怎么实现的，只是来拿货的，你就可以走了/(ㄒoㄒ)/~~

然后本文会有点长~请耐心往下看，哈哈哈。 ##实现思路 ###首先思考下这个版本要做什么事

###那么，怎么解决 ####刚开始我也脑子中思考了许久，想想有什么好的办法可以解决以上问题呢？当然，结果肯定是有的。不过貌似也遇到了一些坎坷。刚好呢，我之前抽空看了一下Glide的源码，因为类似的图片框架加载就和Activity、Fragment等的声明周期密切相关~具体Glide的源码我就不展开了，简单说下：

上面就是Glide的最简单用法，whit(this)在一开始就把当前环境丢进去了哈然后那么久开始仿照直接写呗。（忘记说了哈由于之前好像说过以后的博文直接用Kotlin开发，不知道大家能不能习惯哈~）

我们先来看下构造函数，还是通过makeText(…)只是说，这边重载了很多个不同参数的函数，也就是说，Context不限制喽~比如是Activity的话，EToast的生命周期就跟着Activity走，如果是ApplicationContext的话，那就跟着整个App生命周期走，Fragment也一样。 主要看看参数为Cotext的时候：

其实就是和Glide学的，这边对context进行了分类处理喽当然先看看是不是在主线程喽不然的话也没意义是吧。然后说说重点，为什么Glide的所有图片都可以那么灵活聪明呢？为什么都可以跟着生命周期一起走呢？其实，当你简单看一下源码就知道了（以下是Glide的源码）：

其实不难发现，不管你在Glide.with()方法中传入的是Activity、FragmentActivity、v4包下的Fragment、还是app包下的Fragment，最终的流程都是一样的，那就是会向当前的Activity当中添加一个隐藏的Fragment，然后你就领悟了吧~这个时候其实就有生命周期了。然后这样的话，就简单了，你只需要在Fragment中的每个生命周期回调中调用你自己定义的接口做对应的事情就OK喽 ~这样别人用起来是不是也相当方便，当生命被销毁的时候，自然就释放你的Toast的资源。其实这种方式对于你来说，以后如果想要封装一个控件，然后呢需要绑定生命周期来做一些事情或者搞事情，这种方法就很棒哈。

所以我做了，看代码

这就是常规的显示一个DialogFragment，当然还有些其他的细节，比如：

这边的就是为了使我们的点击穿透~当你点击DilaogFragment 的时候，点击事件还可以往下传递。然后呢，把所有的生命周期对应的方法绑定起来，也就完事儿了~当然，由于情况很多种，其实还有一个

只不过是继承的包不一样而已了，其余代码是一致的。但是呢，我发现当我对Dialog设置不同显示效果的时候，的确有些不一样的事情，如果我隐藏标题，这个时候点击事件向下传递，其实透过Dialog以后，点击的位置回向上偏移50个点左右，当然，为什么引起的，大家肯定也能想到。就是标题隐藏了，导致实际位置往上走了，但是下面的Activity或Fragment的点击位置也就被偏移了。那么不隐藏标题呢，可能大家的需求不一致~又有说不清的情况。其实东西最终是写完了，目录结构如下：

但是！但是！我们再仔细想想上面我们要解决的问题哈好像也是都解决了吧但是最终还是被我抛弃了我觉得是不是太臃肿了，就一个Toast以至于这么大费周折吗？主要还有点击偏移的问题，这个就不好解决了。还有dialog的style问题，那么又产生新的问题喽好吧好吧，就当自己练练手了/(ㄒoㄒ)/~~（如果有感兴趣的，可以私聊我要源码哈~）

所以 最终，我决定从Toast源码入手，看看系统是怎么做的！我们就算不改系统的，那我们仿照系统的来做一套Toast为什么不可以呢？哈哈哈，那就开始分析源码吧。

###Toast源码分析 切记看源码不要一定盯着某一行代码去拼命理解，然后卡在那里…

嗯，就是这个方法了哈~这边能看出2个信息

然后看show()方法

然后，这边来看先要拿到一个INotificationManager ，然后service.enqueueToast(pkg, tn, mDuration); 这个很关键啊，是队列！有木有，其实这样就能理解了，为什么系统的Toast是那种很讨厌的，一个接着一个慢慢的出来的，有时候点个10下，你App都退了，却还能看到一只在弹Toast。其实这东西，我们并不关注，我们主要是看看系统的Toast的是怎么显示在屏幕上的，是吧。那么继续跟踪源码，我们看看TN又是什么鬼呢？

哈哈哈~这个时候是不是真相大白了，看handleShow这边才是我们的关键，原来啊，Toast的视图是通过WindowManager的addView来加载的。那么Toast的原来总结一下就是这样： 先通过makeText()实例化出一个Toast，然后调用toast.show()方法，这时并不会马上显示Toast，而是会实例化一个TN变量，然后通过service.enqueueToast()将其加到服务队列里面去等待显示。在TN中进行调控Toast的显示格式以及里面的hide()、show()方法来控制Toast的显示和消失。然后最可悲的是这个队列是系统维护的，我们并不能干涉，所以才会出现我们屏蔽系统通知的时候，连Toast都没有了哈~

###真正实现EToast2 那么既然上面做了那么多事，我们也看了Toast的源码，那么就直接仿照Google的也来写一套呗，这样不是所的问题都解决了么，不受系统控制，然后还可以把那个队列去掉~优化一下显示规则什么的，是吧。

上面就是EToast2的全部源码了是不是很少，就那么点点。看构造函数，其实我们也是借用了Google的Toast，拿到里面的布局喽这样就是原汁原味了，至少，是吧。然后其余设置其实和Toast没有什么区别，唯一不同的是没有队列了，然后显示的规则是就是： 由于在Android5.0以下无法获取是否打开系统通知权限，所以为了防止用户看不到Toast，最终的逻辑优化了一下：

然后Toast这边我也做了一点优化，舍弃了一些接口，比如setText（Resid）。因为Toast显示的内容一般变化比较大，所以一般不会通过String写在本地吧~真的要用，我想你也有办法用的，是吧。（别说我偷懒）

##总结 最后呢，经过这么一波三折，东西终于弄完了，这边也要特别感谢xiaogaofudao 帮忙测试和提供一些建议，非常感谢。 v2.0.1最新版本你已经上线了哦经过本人和其他的一些用户使用体验，应该是可以的，如果大家在使用中发现什么问题，欢迎及时联系哦(づ￣ 3￣)づ