本篇内容介绍了“内存泄露导致Android中setVisibility()失效怎么解决”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！目前，我在开发的一个 Android 项目需要各个功能做到线上动态化，其中，App 启动时显示的 Loading 模块，会优先检测加载远程的 Loading 模块，加载失败时，会使用 App 本身默认的 Loading 视图，为此，我编写了一个 LoadingLoader 工具类：LoadingLoader 工具类使用 Kotlin 的单例模式，init()方法接收 2 个回调参数，go()方法触发加载远程 Loading 模块，并根据加载结果执行回调，其中isInited用于防止该工具类被初始化多次。然后，在 App 的主入口 LoadingActivity 中使用 LoadingLoader，当加载远程 Loading 模块失败时，将原本隐藏的默认 Loading 视图显示出来；当加载 Loading 模块完成后（无论成功失败），模拟初始化数据并跳转主界面，关闭 LoadingActivity:LoadingActivity 的 xml 布局代码如下，默认的 Loading 布局初始状态不可见，即visibility="gone"：这里会发现一个问题，因为是以清空栈的方式启动 MainActivity，所以第二次启动时，理论上应该会跟第一次启动时界面显示效果完全一致，即每次启动都会显示默认的 Loading 视图，但是实际情况并没有，而控制台的日志也证实了 LoadingActivity 的 onDestroy() 有被触发：难道第二次启动 App 时，LoadingActivity.onLoadFail 没有触发吗？加上日志验证一下：重新打包再执行一遍上面的演示操作，日志输出如下：说明 2 次启动都是有触发 LoadingActivity.onLoadFail 的，并且结果都是 0 ，即 View.VISIBLE。既然，代码有输出日志，那说明setVisibility(View.VISIBLE)这行代码肯定执行过了，而界面上不显示，直接原因是什么？是因为默认 Loading 视图的 visibility 依旧为 View.GONE？又或者是因为其他因素导致 View 的尺寸出现了问题？这时，可以使用 AndroidStudio 的 Layout Inspector 工具，可以直观的分析界面的布局情况，为了方便 Layout Inspector 工具获取 LoadingActivity 的布局信息，需要将 LoadingActivity.onLoadComplete 中跳转主界面的代码注释掉，其他保持不变：然后重复上述演示操作，第一次启动，显示出默认 Loading，手动按返回键退出 App，再第二次启动，不显示默认 Loading。控制台日志信息也如期输出，第二次启动确实执行了setVisibility(View.VISIBLE)：这时，使用 Layout Inspector（菜单栏 -> Tools -> Layout Inspector）免费云主机域名，获取到 LoadingActivity 的布局信息：这里可以断定，就是默认 Loading 视图的 visibility 依旧为 View.GONE 的情况。注：因为 View.GONE 不占据屏幕空间，所以宽高都为 0，是正常的。现在回顾一下上述的 2 个线索，首先，代码中确定执行了setVisibility(View.VISIBLE)，并且日志里也显示了该视图的显示状态为 0，即 View.VISIBLE：其次，使用 Layout Inspector 看到的的视图状态却为 View.GONE：所以，真相只有一个，日志输出的视图 和 Layout Inspector 看到的的视图，肯定不是同一个！！为了验证这一点，代码再做如下调整，分别在 onCreate() 和 onLoadFail 中打印默认 Loading 视图信息：再如上述演示操作一遍，日志输出如下：可以看到第二次启动时，LoadingActivity.onLoadFail 中操作的视图，还是第一次启动时的那个视图，该视图是通过 findViewById 获取到的，说明 LoadingActivity.onLoadFail 中引用的 Activity 是第一次启动时的 LoadingActivity，也就是说 LoadingActivity 发生内存泄露了。此时才焕然大悟，Kotlin 中的 Lambda 表达式（像 onLoadFail、onLoadComplete 这种），对应到 Java 中就是匿名内部类，通过 Kotlin Bytecode 再反编译成 java 代码可以验证这点：我们知道，Java 中，匿名内部类会持有外部类的引用，即匿名内部类实例 onLoadFail 持有 LoadingActivity 实例，而 onLoadFail 又会通过LoadingLoader.init()方法传递给 LoadingLoader 这个单例对象，所以间接导致 LoadingLoader 持有了 LoadingActivity，因为单例生命周期与整个 App 进程相同，所以只要 App 进程不死，内存中就只有一分 LoadingLoader 实例，又因为是强引用，所以 GC 无法回收掉第一次初始化时传递给 LoadingLoader 的 LoadingActivity 实例，所以，无论重启多少次，onLoadFail 中永远都是拿着第一次启动时的 LoadingActivity 来执行 findViewById，拿到的 Loading 视图自然也不会是当前最新 LoadingActivity 的 Loading 视图。既然知道是因为 LoadingActivity 内存泄露导致的，那么解决方案也简单，就是在 LoadingLoader 完成它的使命之后，及时释放掉对 LoadingActivity 的引用即可，又因为 LoadingActivity 实际上并不是被 LoadingLoader 直接引用，而是被其内部变量 onLoadFail 直接引用的，那么在 LoadingLoader 中只需要将 onLoadFail 的引用切断就行了：“内存泄露导致Android中setVisibility()失效怎么解决”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注百云主机网站，小编将为大家输出更多高质量的实用文章！
本文小编为大家详细介绍“php类中的rewind方法如何用”，内容详细，步骤清晰，细节处理妥当，希望这篇“php类中的rewind方法如何用”文章能帮助大家解决疑惑，下面跟着小编的思路慢慢深入，一起来学习新知识吧。 在php中，rewind()函数方法用于将文…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
