Activity，活動介面。直接與使用者進行交流的橋樑。包含了所有該應用需要與使用者互動的元件。
如何生成一個Activity呢？（本文的IDE是Eclipse）
在src資料夾下新建一個包，在包下新建自己的Activity。在新建的Activity中，就要編寫我們需要這個Activity所要完成的各種內容操作以及顯示效果。當然，一個單純的類無法完成各種操作以及介面的顯示。因此Android的API中包含了各種方法及類使得我們方便的與手機進行操作而不需要關係底層與前端是如何連線的。在我們自己的類中繼承Activity這個類，這個類包含了Activity的各種操作。對於我們的類最重要也是最關鍵的就是重寫onCreate方法。通過該方法可以在手機中建立一個Activity（即我們自己的Activity）。
現在有了Activity了，但是這個Activity是一片空白的，我們需要新增我們想要的顯示效果。Android將UI的設計與Activity的互動操作分開，使得我們可以分別設計兩者相應的內容。在Android中，我們使用XML檔案給我們的Activity設計UI佈局相關內容。XML是一種可擴充套件標記語言，其最大的好處就是可以自定義。可以建立開發者想要的各種內容。唯一的限制就是開發者的想象力了。那麼Activity和XML是如何聯絡起來的呢？在Activity這個父類中，包含著setContentView這個方法。這個方法即為Activity與XML連線的橋樑。那麼這個方法是如何使用的呢？那麼就要提到XML檔案其實是一種資原始檔，不過它是佈局的資原始檔。在Android中為了方便管理各種資源，統一將其放入名為R.java的檔案中。並且各個資源以唯一的ID進行標識。因此，只需要在setContentView這個方法中傳入我們想要的佈局ID即可將Activity與XML檔案關聯起來了。
好，現在Activity有了，相應的佈局也有了，那麼Android如何檢測到該Activity呢？AndroidManifest.xml檔案就誕生了。該檔案管理了本APP的基本資訊，包名，主題，名稱以及包含的Activity。那麼當我們新建了自己的Activity並添加了相應的佈局後，為了讓該APP知道這個Activity屬於該APP，就要將該Activity加入AndroidMainfest.xml檔案中。告訴APP，嘿，大家是自家人。當然，一個APP通常有著不止一個Activity，那麼我們怎麼知道哪個Activity應該在使用者點選APP圖示後首先進入使用者的眼簾呢？這就需要我們希望作為首頁的Activity下加入標籤了只要有了這個標記，即告訴APP，我是第一個，其他的往後站。
到此為止，一個活生生的Activity就被我們帶到了這個世界。
那麼這個活生生的“生命”會的壽命有多長呢？（Activity的生命週期）
那麼在講到生命週期之前，要提出返回棧的概念。什麼是返回棧呢？在Android手機中，一個應用軟體（APP）即為一個任務，為了管理這個任務，就誕生了返回棧，由於APP是由多個Activity組成的，所以管理這個APP就是管理其中的返回棧。在預設的情況下，就採用的是棧的先進後出的概念，並規定棧頂的Activity即為此時正顯示給使用者的Activity。當我們啟動一個新的Activity，它就會被壓入棧，處於棧頂位置。當我們按下back返回鍵時，需要銷燬一個Activity時，此Activity又出棧。基於此，管理APP。
那麼一個人的一輩子有幼兒，少年，青年，中年和老年幾個不同的時期，也即不同的狀態。對於一個Activity來說，同樣存在幾個不同的時期，稱為執行狀態。就一個Activity來說，它包含4種不同的執行狀態：
執行狀態：當前正在執行，與使用者正“聊天”的狀態。
暫停狀態：由於“第三者”的插足，不得不暫停與使用者的交流，但不會消失於使用者眼前。並且在手機記憶體極度缺少的時候就會狠下心消滅它。
停止狀態：被打入冷宮，連皇上的面都見不到。甚至可能在不為人知的時候被系統給悄悄消滅掉。
銷燬狀態：慘被拋棄，併成為系統最喜歡的點心。
那麼Activity是如何在各個狀態間進行切換的呢？Android提供了7個回撥函式，對應了Activity的7個生命週期。通過這7個重要角色，使得Activity在各個狀態間來回穿梭（當然，若被銷燬了，就永遠的Say goodbye了）。
onCreate()：建立Activity的方法，前面也提到過，這是最重要的方法了，它彷彿上帝之手，一手建立了Activity這個可愛的孩子。
onStart()：該方法最吃香，因為它掌管著可以見到使用者的大權。
onResume()：Activity準備了一肚子話要說，這個方法告訴Activity：“說吧。”。
onPause()：紅燈標誌，不好意思，你先休息一會讓其他操作先走。
onStop()：各個Activity都很討厭它，因為，它直接撤走了和使用者交流的權利，甚至都不讓見面了。
onDestroy()：最令人生畏的方法了，Activity見到無不避而遠之。它就是個殺人狂，建誰殺誰。
onRestart()：這個方法是個寵兒，它會重新賦予與使用者交流的權利。
一個完整的生命週期從onCreate()開始直至onDestroy()。
一個使用者可見的生命週期則從onStart()到onStop()。
一個前臺生命週期則是從onResume()至onPause()為止。
對於一個APP我們可以以不同的方式啟動它，即不同的方式管理其Activity。Android為我們提供了4種不同的方式：
standard：標準模式，即預設的啟動模式，管理方式如上所述，採取先入後出的管理方式，並且不管棧內的內容，只要顯示一個Activity就產生一個對應的例項。
singleTop：該模式在棧的基礎上，在新產生一個Activity之前，會首先檢測棧頂是否就是所需的Activity，若是則直接使用。否則再建立。
singleTask：同樣在棧的基礎上，在新產生一個Activity之前，會檢測整個棧中是否就有該Activity的例項，若有則呼叫該例項，否則再建立。
singleInstance：這個模式最頑皮，我們知道啟動一個APP就會生成一個返回棧管理Activity。那麼若需要同一個Activity在不同的APP中呼叫的話，就需要在各自的返回棧中都產生對應的例項。此模式的優點就體現出來了。它會單獨生成一個返回棧專門用於管理這些需要共享的Activity。而不需要為各個返回棧都生成一個例項。
到此為止，Activity的一切資訊都被我們扒拉的差不多了。Activity也無奈的喊了聲：“你真是夠夠的了！”。