嗨,我會定期分享Android知識點及解析,還會不斷更新的BATJ面試專題,歡迎大家前來探討交流,如有好的文章也歡迎投稿,如果喜歡的朋友也歡迎關(guān)注。
成都創(chuàng)新互聯(lián)公司服務(wù)項目包括海倫網(wǎng)站建設(shè)、海倫網(wǎng)站制作、海倫網(wǎng)頁制作以及海倫網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,海倫網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到海倫省份的部分城市,未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
對于內(nèi)存泄漏,我想大家在開發(fā)中肯定都遇到過,只不過內(nèi)存泄漏對我們來說并不是可見的,因為它是在堆中活動,而要想檢測程序中是否有內(nèi)存泄漏的產(chǎn)生,通常我們可以借助LeakCanary
、MAT
等工具來檢測應(yīng)用程序是否存在內(nèi)存泄漏,MAT是一款強大的內(nèi)存分析工具,功能繁多而復(fù)雜,而LeakCanary
則是由Square開源的一款輕量第三方內(nèi)存泄漏檢測工具,當(dāng)它檢測到程序中有內(nèi)存泄漏的產(chǎn)生時,它將以最直觀的方式告訴我們該內(nèi)存泄漏是由誰產(chǎn)生的和該內(nèi)存泄漏導(dǎo)致誰泄漏了而不能回收,供我們復(fù)查。
當(dāng)一個對象已經(jīng)不需要再使用了,本該被回收時,而有另外一個正在使用的對象持有它的引用從而導(dǎo)致它不能被回收,這導(dǎo)致本該被回收的對象不能被回收而停留在堆內(nèi)存中,這就產(chǎn)生了內(nèi)存泄漏。
內(nèi)存泄漏是造成應(yīng)用程序OOM的主要原因之一!我們知道Android系統(tǒng)為每個應(yīng)用程序分配的內(nèi)存有限,而當(dāng)一個應(yīng)用中產(chǎn)生的內(nèi)存泄漏比較多時,這就難免會導(dǎo)致應(yīng)用所需要的內(nèi)存超過這個系統(tǒng)分配的內(nèi)存限額,這就造成了內(nèi)存溢出而導(dǎo)致應(yīng)用Crash。
單例模式非常受開發(fā)者的喜愛,不過使用的不恰當(dāng)?shù)脑捯矔斐蓛?nèi)存泄漏,由于單例的靜態(tài)特性使得單例的生命周期和應(yīng)用的生命周期一樣長,這就說明了如果一個對象已經(jīng)不需要使用了,而單例對象還持有該對象的引用,那么這個對象將不能被正常回收,這就導(dǎo)致了內(nèi)存泄漏。
如下這個典例:
????private?static?AppManager?instance;????private?Context?context;????private?AppManager(Context?context)?{????????this.context?=?context; ????}????public?static?AppManager?getInstance(Context?context)?{????????if?(instance?!=?null)?{ ????????????instance?=?new?AppManager(context); ????????}????????return?instance; ????} }
這是一個普通的單例模式,當(dāng)創(chuàng)建這個單例的時候,由于需要傳入一個Context,所以這個Context的生命周期的長短至關(guān)重要:
1、傳入的是Application的Context:?這將沒有任何問題,因為單例的生命周期和Application的一樣長
2、傳入的是Activity的Context:?當(dāng)這個Context所對應(yīng)的Activity退出時,由于該Context和Activity的生命周期一樣長(Activity間接繼承于Context),所以當(dāng)前Activity退出時它的內(nèi)存并不會被回收,因為單例對象持有該Activity的引用。
所以正確的單例應(yīng)該修改為下面這種方式:
????private?static?AppManager?instance;????private?Context?context;????private?AppManager(Context?context)?{????????this.context?=?context.getApplicationContext(); ????}????public?static?AppManager?getInstance(Context?context)?{????????if?(instance?!=?null)?{ ????????????instance?=?new?AppManager(context); ????????}????????return?instance; ????} }
這樣不管傳入什么Context最終將使用Application的Context,而單例的生命周期和應(yīng)用的一樣長,這樣就防止了內(nèi)存泄漏。
有的時候我們可能會在啟動頻繁的Activity中,為了避免重復(fù)創(chuàng)建相同的數(shù)據(jù)資源,可能會出現(xiàn)這種寫法:
????private?static?TestResource?mResource?=?null;????@Override ????protected?void?onCreate(Bundle?savedInstanceState)?{????????super.onCreate(savedInstanceState); ????????setContentView(R.layout.activity_main);????????if(mManager?==?null){ ????????????mManager?=?new?TestResource(); ????????}????????//... ????}????class?TestResource?{????????//... ????} }
這樣就在Activity內(nèi)部創(chuàng)建了一個非靜態(tài)內(nèi)部類的單例,每次啟動Activity時都會使用該單例的數(shù)據(jù),這樣雖然避免了資源的重復(fù)創(chuàng)建,不過這種寫法卻會造成內(nèi)存泄漏;
因為非靜態(tài)內(nèi)部類默認(rèn)會持有外部類的引用,而又使用了該非靜態(tài)內(nèi)部類創(chuàng)建了一個靜態(tài)的實例,該實例的生命周期和應(yīng)用的一樣長,這就導(dǎo)致了該靜態(tài)實例一直會持有該Activity的引用,導(dǎo)致Activity的內(nèi)存資源不能正?;厥?。正確的做法為:
將該內(nèi)部類設(shè)為靜態(tài)內(nèi)部類或?qū)⒃搩?nèi)部類抽取出來封裝成一個單例,如果需要使用Context,請使用ApplicationContext
Handler的使用造成的內(nèi)存泄漏問題應(yīng)該說最為常見了,平時在處理網(wǎng)絡(luò)任務(wù)或者封裝一些請求回調(diào)等api都應(yīng)該會借助Handler來處理,對于Handler的使用代碼編寫一不規(guī)范即有可能造成內(nèi)存泄漏,如下示例:
????private?Handler?mHandler?=?new?Handler()?{????????@Override ????????public?void?handleMessage(Message?msg)?{????????????//... ????????} ????};????@Override ????protected?void?onCreate(Bundle?savedInstanceState)?{????????super.onCreate(savedInstanceState); ????????setContentView(R.layout.activity_main); ????????loadData(); ????}????private?void?loadData(){????????//...request ????????Message?message?=?Message.obtain(); ????????mHandler.sendMessage(message); ????} }
這種創(chuàng)建Handler的方式會造成內(nèi)存泄漏,由于mHandler是Handler的非靜態(tài)匿名內(nèi)部類的實例?,所以它持有外部類Activity的引用,我們知道消息隊列是在一個Looper
線程中不斷輪詢處理消息,那么當(dāng)這個Activity退出時消息隊列中還有未處理的消息或者正在處理消息,而消息隊列中的Message持有mHandler實例的引用,mHandler又持有Activity的引用,所以導(dǎo)致該Activity的內(nèi)存資源無法及時回收,引發(fā)內(nèi)存泄漏,所以另外一種做法為:
public?class?MainActivity?extends?AppCompatActivity?{????private?MyHandler?mHandler?=?new?MyHandler(this);????private?TextView?mTextView?;????private?static?class?MyHandler?extends?Handler?{????????private?WeakReference<Context>?reference;????????public?MyHandler(Context?context)?{ ????????????reference?=?new?WeakReference<>(context); ????????}????????@Override ????????public?void?handleMessage(Message?msg)?{ ????????????MainActivity?activity?=?(MainActivity)?reference.get();????????????if(activity?!=?null){ ????????????????activity.mTextView.setText(""); ????????????} ????????} ????}????@Override ????protected?void?onCreate(Bundle?savedInstanceState)?{????????super.onCreate(savedInstanceState); ????????setContentView(R.layout.activity_main); ????????mTextView?=?(TextView)findViewById(R.id.textview); ????????loadData(); ????}????private?void?loadData()?{????????//...request ????????Message?message?=?Message.obtain(); ????????mHandler.sendMessage(message); ????} }
創(chuàng)建一個靜態(tài)Handler內(nèi)部類,然后對Handler持有的對象使用弱引用,這樣在回收時也可以回收Handler持有的對象,這樣雖然避免了Activity泄漏,不過Looper線程的消息隊列中還是可能會有待處理的消息,所以我們在Activity的Destroy時或者Stop時應(yīng)該移除消息隊列中的消息,更準(zhǔn)確的做法如下:
public?class?MainActivity?extends?AppCompatActivity?{????private?MyHandler?mHandler?=?new?MyHandler(this);????private?TextView?mTextView?;????private?static?class?MyHandler?extends?Handler?{????????private?WeakReference<Context>?reference;????????public?MyHandler(Context?context)?{ ????????????reference?=?new?WeakReference<>(context); ????????}????????@Override ????????public?void?handleMessage(Message?msg)?{ ????????????MainActivity?activity?=?(MainActivity)?reference.get();????????????if(activity?!=?null){ ????????????????activity.mTextView.setText(""); ????????????} ????????} ????}????@Override ????protected?void?onCreate(Bundle?savedInstanceState)?{????????super.onCreate(savedInstanceState); ????????setContentView(R.layout.activity_main); ????????mTextView?=?(TextView)findViewById(R.id.textview); ????????loadData(); ????}????private?void?loadData()?{????????//...request ????????Message?message?=?Message.obtain(); ????????mHandler.sendMessage(message); ????}????@Override ????protected?void?onDestroy()?{????????super.onDestroy(); ????????mHandler.removeCallbacksAndMessages(null); ????} }
使用mHandler.removeCallbacksAndMessages(null);
是移除消息隊列中所有消息和所有的Runnable。當(dāng)然也可以使用mHandler.removeCallbacks();
或mHandler.removeMessages();
來移除指定的Runnable和Message。
對于線程造成的內(nèi)存泄漏,也是平時比較常見的,如下這兩個示例可能每個人都這樣寫過:
//——————test1 ????????new?AsyncTask<Void,?Void,?Void>()?{????????????@Override ????????????protected?Void?doInBackground(Void...?params)?{ ????????????????SystemClock.sleep(10000);????????????????return?null; ????????????} ????????}.execute();//——————test2 ????????new?Thread(new?Runnable()?{????????????@Override ????????????public?void?run()?{ ????????????????SystemClock.sleep(10000); ????????????} ????????}).start();
上面的異步任務(wù)和Runnable都是一個匿名內(nèi)部類,因此它們對當(dāng)前Activity都有一個隱式引用。如果Activity在銷毀之前,任務(wù)還未完成;
那么將導(dǎo)致Activity的內(nèi)存資源無法回收,造成內(nèi)存泄漏。正確的做法還是使用靜態(tài)內(nèi)部類的方式,如下:
????static?class?MyAsyncTask?extends?AsyncTask<Void,?Void,?Void>?{????????private?WeakReference<Context>?weakReference;????????public?MyAsyncTask(Context?context)?{ ????????????weakReference?=?new?WeakReference<>(context); ????????}????????@Override ????????protected?Void?doInBackground(Void...?params)?{ ????????????SystemClock.sleep(10000);????????????return?null; ????????}????????@Override ????????protected?void?onPostExecute(Void?aVoid)?{????????????super.onPostExecute(aVoid); ????????????MainActivity?activity?=?(MainActivity)?weakReference.get();????????????if?(activity?!=?null)?{????????????????//... ????????????} ????????} ????}????static?class?MyRunnable?implements?Runnable{????????@Override ????????public?void?run()?{ ????????????SystemClock.sleep(10000); ????????} ????}//—————— ????new?Thread(new?MyRunnable()).start();????new?MyAsyncTask(this).execute();
這樣就避免了Activity的內(nèi)存資源泄漏,當(dāng)然在Activity銷毀時候也應(yīng)該取消相應(yīng)的任務(wù)AsyncTask::cancel()
,避免任務(wù)在后臺執(zhí)行浪費資源。
對于使用了BraodcastReceiver,ContentObserver,F(xiàn)ile,Cursor,Stream,Bitmap等資源的使用,應(yīng)該在Activity銷毀時及時關(guān)閉或者注銷,否則這些資源將不會被回收,造成內(nèi)存泄漏。
對于生命周期比Activity長的對象如果需要應(yīng)該使用ApplicationContext
在涉及到Context時先考慮ApplicationContext,當(dāng)然它并不是萬能的,對于有些地方則必須使用Activity的Context,對于Application,Service,Activity三者的Context的應(yīng)用場景如下:
其中:NO1表示Application和Service可以啟動一個Activity,不過需要創(chuàng)建一個新的task任務(wù)隊列。而對于Dialog而言,只有在Activity中才能創(chuàng)建。
對于需要在靜態(tài)內(nèi)部類中使用非靜態(tài)外部成員變量(如:Context、View ),可以在靜態(tài)內(nèi)部類中使用弱引用來引用外部類的變量來避免內(nèi)存泄漏
對于生命周期比Activity長的內(nèi)部類對象,并且內(nèi)部類中使用了外部類的成員變量,可以這樣做避免內(nèi)存泄漏:
將內(nèi)部類改為靜態(tài)內(nèi)部類
靜態(tài)內(nèi)部類中使用弱引用來引用外部類的成員變量
對于不再需要使用的對象,顯示的將其賦值為null,比如使用完Bitmap后先調(diào)用recycle(),再賦為null。
保持對對象生命周期的敏感,特別注意單例、靜態(tài)對象、全局性集合等的生命周期。
覺得文章不錯的朋友幫忙點點贊加關(guān)注哦,有什么問題的話也歡迎大家前來探討交流。
分享標(biāo)題:Android性能優(yōu)化必看讓內(nèi)存泄漏無處可藏
文章來源:http://www.rwnh.cn/article34/igjhpe.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站內(nèi)鏈、靜態(tài)網(wǎng)站、品牌網(wǎng)站制作、企業(yè)網(wǎng)站制作、移動網(wǎng)站建設(shè)、動態(tài)網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)