內存泄露導致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() 失效的問題就解決掉瞭
到此這篇關於內存泄露導致Android 中setVisibility() 失效原理的文章就介紹到這瞭,更多相關Android setVisibility()失效內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！
推薦閱讀：
- Androd 勇闖高階性能優化之佈局優化篇
- Android ViewStub使用方法學習
- Android實現顯示和隱藏密碼功能的示例代碼
- Android實現文字消除效果
- Android自定義Dialog的方法實例