Android - setVisibility() 失效,竟然是因为内存泄露
# 一、前情概要
目前,我在开发的一个 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() 失效的问题就解决掉了,要坚信,在代码的世界里,没有魔法~
- 01
- Flutter - 危!3.24版本苹果审核被拒!11-13
- 02
- Flutter - 轻松搞定炫酷视差(Parallax)效果09-21
- 03
- Flutter - 轻松实现PageView卡片偏移效果09-08