一、前情概要
目前，我在开发的一个 android 项目需要各个功能做到线上动态化，其中，app 启动时显示的 loading 模块，会优先检测加载远程的 loading 模块，加载失败时，会使用 app 本身默认的 loading 视图，为此，我编写了一个 loadingloader 工具类：
/**
* loading 加载器
*
* @author gitlqr
* @since 2022/7/2
*/
object loadingloader {
private var isinited = false // 防止多次初始化
private lateinit var onloadfail: () -> unit // 远程loading加载失败时的回调
private lateinit var onloadcomplete: () -> unit // 加载完成后回调（无论成功失败）
fun init(onloadfail: () -> unit = {}, onloadcomplete: () -> unit = {}): loadingloader {
if (!isinited) {
this.onloadfail = onloadfail
this.onloadcomplete = onloadcomplete
isinited = true
} else {
log("you have inited, this time is not valid")
}
return this
}
fun go() {
if (isinited) {
loadremoteloading(callback = { issuccess ->
if (!issuccess) onloadfail()
onloadcomplete()
})
} else {
log("you must invoke init() firstly")
}
}
private fun loadremoteloading(callback: (boolean: boolean) -> unit) {
// 模拟远程 loading 模块加载失败
handler(looper.getmainlooper()).postdelayed({
callback(false)
}, 1000)
}
private fun log(msg: string) {
log.e("loadingupdater", msg)
}
}
loadingloader 工具类使用 kotlin 的单例模式，init() 方法接收 2 个回调参数，go() 方法触发加载远程 loading 模块，并根据加载结果执行回调，其中 isinited 用于防止该工具类被初始化多次。然后，在 app 的主入口 loadingactivity 中使用 loadingloader，当加载远程 loading 模块失败时，将原本隐藏的默认 loading 视图显示出来；当加载 loading 模块完成后（无论成功失败），模拟初始化数据并跳转主界面，关闭 loadingactivity:
/**
* app 启动时的 loading 界面
*
* @author gitlqr
* @since 2022/7/2
*/
class loadingactivity : appcompatactivity() {
override fun oncreate(savedinstancestate: bundle?) {
super.oncreate(savedinstancestate)
setcontentview(r.layout.activity_loading)
// loading 模块加载器
loadingloader.init(onloadfail, onloadcomplete).go()
}
override fun ondestroy() {
super.ondestroy()
log.e("gitlqr", "ondestroy")
}
private val onloadfail: () -> unit = {
// 显示默认 loading 界面
findviewbyid<view>(r.id.cl_def_loading).setvisibility(view.visible)
}
private val onloadcomplete: () -> unit = {
// 模拟初始化数据，1秒后跳转主界面
handler(looper.getmainlooper()).postdelayed({
val intent = intent(this, mainactivity::class.java)
intent.addflags(intent.flag_activity_new_task)
intent.addflags(intent.flag_activity_clear_task)
// 注意：此处意图使用的 flag，会将 loadingactivity 界面关闭，触发 ondestroy()
startactivity(intent)
}, 1000)
}
}
loadingactivity 的 xml 布局代码如下，默认的 loading 布局初始状态不可见，即 visibility="gone"：
<?xml version="1.0" encoding="utf-8"?>
<framelayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@color/black">
<androidx.constraintlayout.widget.constraintlayout
android:id="@+id/cl_def_loading"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#f00"
android:visibility="gone"
tools:visibility="visible">
<textview
android:layout_width="match_parent"
android:layout_height="match_parent"
android:gravity="center"
android:text="很好看的默认loading界面"
android:textcolor="@color/white"
android:textsize="60dp" />
<progressbar
android:id="@+id/pb_loading"
android:layout_width="0dp"
android:layout_height="0dp"
android:indeterminatedrawable="@drawable/anim_loading"
app:layout_constraintbottom_tobottomof="parent"
app:layout_constraintdimensionratio="1"
app:layout_constraintleft_toleftof="parent"
app:layout_constraintright_torightof="parent"
app:layout_constrainttop_totopof="parent"
app:layout_constraintvertical_bias="0.75"
app:layout_constraintwidth_percent="0.064" />
</androidx.constraintlayout.widget.constraintlayout>
</framelayout>
以上代码比较简单，现在来看下演示效果:
这里会发现一个问题，因为是以清空栈的方式启动 mainactivity，所以第二次启动时，理论上应该会跟第一次启动时界面显示效果完全一致，即每次启动都会显示默认的 loading 视图，但是实际情况并没有，而控制台的日志也证实了 loadingactivity 的 ondestroy() 有被触发：
二、摸索过程
1、代码执行了吗？
难道第二次启动 app 时，loadingactivity.onloadfail 没有触发吗？加上日志验证一下：
class loadingactivity : appcompatactivity() {
...
private val onloadfail: () -> unit = {
// 显示默认 loading 界面
val defloading = findviewbyid<view>(r.id.cl_def_loading)
defloading.setvisibility(view.visible)
log.e("gitlqr", "defloading.setvisibility --> ${defloading.visibility}")
}
}
重新打包再执行一遍上面的演示操作，日志输出如下：
说明 2 次启动都是有触发 loadingactivity.onloadfail 的，并且结果都是 0 ，即 view.visible。
此时有点怀疑人生，于是网上找了一圈
setvisibility() 失效的原因，基本上都是同一个内容（都特么抄来抄去的），说是做动画导致的，可是我这里并没有做动画，所以与网上说的情况不相符。
2、视图不显示的直接原因是什么？
既然，代码有输出日志，那说明 setvisibility(view.visible) 这行代码肯定执行过了，而界面上不显示，直接原因是什么？是因为默认 loading 视图的 visibility 依旧为 view.gone？又或者是因为其他因素导致 view 的尺寸出现了问题？这时，可以使用 androidstudio 的 layout inspector 工具，可以直观的分析界面的布局情况，为了方便 layout inspector 工具获取 loadingactivity 的布局信息，需要将 loadingactivity.onloadcomplete 中跳转主界面的代码注释掉，其他保持不变：
class loadingactivity : appcompatactivity() {
...
private val onloadcomplete: () -> unit = {
// 模拟初始化数据，1秒后跳转主界面
handler(looper.getmainlooper()).postdelayed({
// val intent = intent(this, mainactivity::class.java)
// intent.addflags(intent.flag_activity_new_task)
// intent.addflags(intent.flag_activity_clear_task)
// // 注意：此处意图的 flag，会将 loadingactivity 界面关闭，触发 ondestroy()
// startactivity(intent)
}, 1000)
}
}
然后重复上述演示操作，第一次启动，显示出默认 loading，手动按返回键退出 app，再第二次启动，不显示默认 loading：
控制台日志信息也如期输出，第二次启动确实执行了 setvisibility(view.visible)：
这时，使用 layout inspector（菜单栏 -> tools -> layout inspector），获取到 loadingactivity 的布局信息：
这里可以断定，就是默认 loading 视图的 visibility 依旧为 view.gone 的情况。
注：因为 view.gone 不占据屏幕空间，所以宽高都为 0，是正常的。
3、操作的视图是同一个吗？
现在回顾一下上述的 2 个线索，首先，代码中确定执行了 setvisibility(view.visible)，并且日志里也显示了该视图的显示状态为 0，即 view.visible：
其次，使用 layout inspector 看到的的视图状态却为 view.gone：
所以，真相只有一个，日志输出的视图 和 layout inspector 看到的的视图，肯定不是同一个！！为了验证这一点，代码再做如下调整，分别在 oncreate() 和 onloadfail 中打印默认 loading 视图信息：
class loadingactivity : appcompatactivity() {
...
override fun oncreate(savedinstancestate: bundle?) {
super.oncreate(savedinstancestate)
setcontentview(r.layout.activity_loading)
val defloading = findviewbyid<view>(r.id.cl_def_loading)
log.e("gitlqr", "oncreate ---> view is ${defloading}")
// loading 模块加载器
loadingloader.init(onloadfail, onloadcomplete).go()
}
private val onloadfail: () -> unit = {
// 显示默认 loading 界面
val defloading = findviewbyid<view>(r.id.cl_def_loading)
defloading.setvisibility(view.visible)
log.e("gitlqr", "defloading.setvisibility --> ${defloading.visibility}, view is ${defloading}")
}
}
再如上述演示操作一遍，日志输出如下：
可以看到第二次启动时，loadingactivity.onloadfail 中操作的视图，还是第一次启动时的那个视图，该视图是通过 findviewbyid 获取到的，说明 loadingactivity.onloadfail 中引用的 activity 是第一次启动时的 loadingactivity，也就是说 loadingactivity 发生内存泄露了。此时才焕然大悟，kotlin 中的 lambda 表达式（像 onloadfail、onloadcomplete 这种），对应到 java 中就是匿名内部类，通过 kotlin bytecode 再反编译成 java 代码可以验证这点：
public final class loadingactivity extends appcompatactivity {
private final function0 onloadfail = (function0)(new function0() {
// $ff: synthetic method
// $ff: bridge method
public object invoke() {
this.invoke();
return unit.instance;
}
public final void invoke() {
view defloading = loadingactivity.this.findviewbyid(1000000);
defloading.setvisibility(0);
stringbuilder var10001 = (new stringbuilder()).append("defloading.setvisibility --> ");
intrinsics.checkexpressionvalueisnotnull(defloading, "defloading");
log.e("gitlqr", var10001.append(defloading.getvisibility()).append(", view is ").append(defloading).tostring());
}
});
private final function0 onloadcomplete;
protected void oncreate(@nullable bundle savedinstancestate) {
super.oncreate(savedinstancestate);
this.setcontentview(1300004);
view defloading = this.findviewbyid(1000000);
log.e("gitlqr", "oncreate ---> view is " + defloading);
loadingloader.instance.init(this.onloadfail, this.onloadcomplete).go();
}
protected void ondestroy() {
super.ondestroy();
log.e("gitlqr", "ondestroy");
}
public loadingactivity() {
this.onloadcomplete = (function0)null.instance;
}
}
我们知道，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 的引用切断就行了：
object loadingloader {
private var isinited = false // 防止多次初始化
private lateinit var onloadfail: () -> unit // 远程loading加载失败时的回调
private lateinit var onloadcomplete: () -> unit // 加载完成后回调
fun go() {
if (isinited) {
loadremoteloading(callback = { issuccess ->
if (!issuccess) onloadfail()
onloadcomplete()
destroy() // 使命完成，释放资源
})
} else {
log("you must invoke init() firstly")
}
}
fun destroy() {
this.onloadfail = {}
this.onloadcomplete = {}
this.isinited = false
}
}
至此，因内存泄露导致 setvisibility() 失效的问题就解决掉了
到此这篇关于内存泄露导致android 中setvisibility() 失效原理的文章就介绍到这了,更多相关android setvisibility()失效内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！
