Android加载弹窗(loading dialog)封装的思考

前言

我们在进行网络请求或者其他一些耗时的操作时，为了良好的用户的体验和系统稳定性，需要弹出dialog来提示用户，并且限制用户的操作行为。有的的loading dialog是纯进度条的方式，有的是自定义的特殊动画效果，有的是进度条+文字，但无论哪种，都需要创建dialog，为了避免重复的模板代码，往往会对dialog进行封装。

1 系统全局dialog

因为某些特殊需求，比如请求失败统一自动关闭loading dialog，很多人的想法都是希望封装一个在系统内全局存在，随处可调用的dialog，常见的流传比较广的封装方式有两种。

1.1 基于栈顶activity系统全局dialog

一般我们创建的dialog都是依附于activity，假设现在管理全局弹窗的工具名为DialogManager，如果要在非activity中弹出dialog，那就必须要把当前处于栈顶的activity (这里称为：TopActivity) 传给DialogManager，直接传递的话，就需要activity持有DialogManager实例，这样就不能实现全局化了，所以我们必须通过间接的方式来传递。常见的做法是通过监听activity的生命周期，来取得当前的TopActivity，比如通过ActivityLifecycleCallbacks进行监听。

1.2 基于Service的悬浮窗

这种方式也是网上流传比较广的一种方式，利用WindowManager.LayoutParams.TYPE_SYSTEM_ALERT、WindowManager.LayoutParams.TYPE_TOAST、WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY
等属性来将dialog变为悬浮窗，这种方式的坑也很多，比如权限限制，版本适配，第三方厂商ROM适配等，网上可以找到很多相关资料， 这里不作详细叙述。

2 非全局的dialog

基本上我们的网络请求都是在Activity或者Fragment中发起的，退求其次，我们可以在BaseActivity/BaseFragment中封装一个loading dialog，这样就能很方便的调用了。而且Google官方在很早之前就推荐使用DialogFragment来替代普通的dialog，而Fragment是必须依附Activity的，在BaseActivity/BaseFragment中封装也更方便。(PS：DialogFragment的优势在网上已经有很多文章讲解，这里不作详细叙述。)

记录，分享，交流。