Android Application 對象介紹

來源:互聯網
上載者:User

摘自 http://www.cnblogs.com/elleniou/archive/2012/05/16/2502661.html

What is Application
Application和Activity,Service一樣是android架構的一個系統組件,當android程式啟動時系統會建立一個 application對象,用來儲存系統的一些資訊。通常我們是不需要指定一個Application的,這時系統會自動幫我們建立,如果需要建立自己 的Application,也很簡單建立一個類繼承 Application並在manifest的application標籤中進行註冊(只需要給Application標籤增加個name屬性把自己的 Application的名字定入即可)。
android系統會為每個程式運行時建立一個Application類的對象且僅建立一個,所以Application可以說是單例 (singleton)模式的一個類.且application對象的生命週期是整個程式中最長的,它的生命週期就等於這個程式的生命週期。因為它是全域 的單例的,所以在不同的Activity,Service中獲得的對象都是同一個對象。所以通過Application來進行一些,資料傳遞,資料共用 等,資料緩衝等操作。
Data passing between components using Application
假如有一個Activity A, 跳轉到 Activity B ,並需要推薦一些資料,通常的作法是Intent.putExtra() 讓Intent攜帶,或者有一個Bundle把資訊加入Bundle讓Intent推薦Bundle對象,實現傳遞。但這樣作有一個問題在 於,Intent和Bundle所能攜帶的資料類型都是一些基本的資料類型,如果想實現複雜的資料傳遞就比較麻煩了,通常需要實現 Serializable或者Parcellable介面。這其實是Android的一種IPC資料傳遞的方法。如果我們的兩個Activity在同一個 進程當中為什麼還要這麼麻煩呢,只要把需要傳遞的對象的引用傳遞過去就可以了。
基本思路是這樣的。在Application中建立一個HashMap ,以字串為索引,Object為value這樣我們的HashMap就可以儲存任何類型的對象了。在Activity A中把需要傳遞的對象放入這個HashMap,然後通過Intent或者其它途經再把這人索引的字串傳遞給Activity B ,Activity B 就可以根據這個字串在HashMap中取出這個對象了。只要再向下轉個型 ,就實現了對象的傳遞。
Data caching in Application
我一般會習慣在application中建立兩個HashMap一個用於資料的傳遞,一個用於緩 存一些資料。比如有一個Activity需要從網站擷取一些資料,擷取完之後我們就可以把這個資料cache到Application 當中,當版面設定到其它Activity再回來的時候,就可以直接使用緩衝好的資料了。但如果需要cache一些大量的資料,最好是cache一些軟引用)SoftReference ,並把這些資料cache到本地rom上或者sd卡上。如果在application中的緩衝不存在,從本機快取尋找,如果本機快取的資料也不存在再從網 絡上擷取。
PitFalls
使用Application如果儲存了一些不該儲存的對象很容易導致記憶體流失。如果在Application的oncreate中執行比較 耗時的操作,將直接影響的程式的啟動時間。不些清理工作不能依靠onTerminate完成,因為android會盡量讓你的程式一直運行,所以很有可能 onTerminate不會被調用。
MemoryLeak
在Java中記憶體流失是只,某個(某些)對象已經不在被使用應該被gc所回收,但有一個對象持有這個對象的引用而阻止這個對象被回收。比如我 們通常會這樣建立一個View TextView tv = new TextView(this);這裡的this通常都是Activity。所以這個TextView就持有著這個Activity的引用。下面看張圖 (Google IO 2011 ppt中抄得)

通常情況下,當使用者轉動手機的時候,android會重新調用OnCreate()方法產生一個新的Activity,原來的 Activity應該被GC所回收。但如果有個對象比如一個View的範圍超過了這個Activity(比如有一個static對象或者我們把這個 View的引用放到了Application當中),這時候原來的Activity將不能被GC所回收,Activity本身又持有很多個物件的引用,所以 整個Activity的記憶體被泄漏了。
經常導致記憶體流失的一些原因:
keeping a long-lived reference to a Context.持有一個context的對象,從而gc不能回收。
1,一個View,的範圍超出了所在的Activity的範圍,比如一個static的View或者 把一個View cache到了application當中 etc
2,某些與View關聯的Drawable的範圍超出了Activity的範圍。
3,Runnable對象:比如在一個Activity中啟用了一個新線程去執行一個任務,在這期間這個Activity被系統回收了, 但Runnalbe的任務還沒有執行完畢並持有Activity的引用而泄漏,但這種泄漏一般來泄漏一段時間,只有Runnalbe的線程執行完閉,這個 Activity又可以被正常回收了。
4,記憶體類的對象範圍超出Activity的範圍:比如定義了一個記憶體類來儲存資料,又把這個記憶體類的對象傳給了其它Activity 或者Service等。因為內部類的對象會持有當前類的引用,所以也就持有了Context的引用。解決方案是如果不需要當前的引用把內部類寫成 
static或者,把內部類抽取出來變成一個單獨的類,或者把避免內部對象範圍超出Activity的範圍。
out Of Memery Error 在android中每一個程式所分到的記憶體大小是有限的,如果超過了這個數就會報Out Of Memory Error。android給程式分配的記憶體大小與手機硬體有關,以下是一些手機的資料:
G1:16M Droid:24 Nexus One:32M Xoom:48Ms
所以盡量把程式中的一些大的資料cache到本地檔案。以免記憶體使用量量超標。
Snippets
1,通過Application在兩個Activity間傳遞資料

記得資料傳遞完成之後,把存放在application的HashMap中的資料remove掉,以免發生記憶體的泄漏。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.