您好,登錄后才能下訂單哦!
本篇內容介紹了“內存泄露導致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() 有被觸發:
難道第二次啟動 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(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,是正常的。
現在回顧一下上述的 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 } }
“內存泄露導致Android中setVisibility()失效怎么解決”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。