本文收集整理了 Android 面試中會遇到與 Android 知識相關的簡述題。

基本概念

Android 的四大元件

Acitivity、Service、BroadcastReceiver、ContentProvider

Activity :

應用程式中，一個Activity通常就是一個單獨的螢幕，它上面可以顯示一些控制元件也可以監聽並處理使用者的事件做出響應。

BroadcastReceiver廣播接收器:

應用程式可以使用它對外部事件進行過濾只對感興趣的外部事件(如當電話呼入時，或者資料網路可用時)進行接收並做出響應。廣播接收器沒有使用者介面。然而，它們可以啟動一個activity或serice 來響應它們收到的資訊，或者用NotificationManager 來通知使用者。通知可以用很多種方式來吸引使用者的注意力──閃動背燈、震動、播放聲音等。一般來說是在狀態列上放一個持久的圖示，使用者可以開啟它並獲取訊息。

Service 服務:

一個Service 是一段長生命週期的，沒有使用者介面的程式，可以用來開發如監控類程式。

Content Provider內容提供者 :

android平臺提供了Content Provider使一個應用程式的指定資料集提供給其他應用程式。這些資料可以儲存在檔案系統中、在一個SQLite資料庫、或以任何其他合理的方式。其他應用可以通過ContentResolver類(見ContentProviderAccessApp例子)從該內容提供者中獲取或存入資料.(相當於在應用外包了一層殼),只有需要在多個應用程式間共享資料是才需要內容提供者。例如，通訊錄資料被多個應用程式使用，且必須儲存在一個內容提供者中。它的好處:統一資料訪問方式。

參考：

四大元件的具體作用以及用法

• Acitivity 用於顯示介面，接收使用者輸入，和使用者互動。
• Service 運行於後臺無介面的程式，用於在後臺完成一下任務，例如：音樂播放等。
• BroadCast Receiver 接收系統或應用發出的廣播並作出響應，例如：電話的呼入撥出等。
• Content Provider 用於把APP本身的資料共享給其他APP，提供本APP資料的存取介面給其他APP。

Android平臺的framework的層次結構？

應用層、應用框架層、中介軟體（核心庫和執行時）、Linux核心

Activity

Activity 生命週期

• 啟動Activity：onCreate->onStart->onResume
• 鎖屏或被其它Activity覆蓋：onPause->onStop
• 解鎖或由被覆蓋狀態再回到前臺：onRestart->onStart->onResume
• 跳轉到其它Activity或按Home進入後臺：onPause->onStop
• 退回到此Activity：onRestart->onStart->onResume
• 退出此Activity：onPause->onStop->onDestory
• 對話方塊彈出不會執行任何生命週期(注：對話方塊如果是Activity(Theme為Dialog)，還是會執行生命週期的)
• 從A跳轉到B：當B的主題為透明時，A只會執行onPause（A-onPause->B-(onCreate->onStart->onResume)）
• 從A跳轉到B：A-onPause->B-(onCreate->onStart->onResume)-A-onStop(注意是A執行onPause後開始執行B的生命週期，B執行onResume後，A才執行onStop，所以儘量不要在onPause中做耗時操作)
• 從B返回到A：B-onPause->A-(onRestart->onStart->onResume)-B-(onStop->onDestroy)

Activity和Fragment生命週期有哪些？

Activity——onCreate->onStart->onResume->onPause->onStop->onDestroy

Fragment——onAttach->onCreate->onCreateView->onActivityCreated->onStart->onResume->onPause->onStop->onDestroyView->onDestroy->onDetach

Activity四種啟動模式的區別（LanchMode 的應用場景）

• standard 模式

這是預設模式，每次啟用Activity時都會建立Activity例項，並放入任務棧中。

• singleTop 模式

如果在任務的棧頂正好存在該Activity的例項，就重用該例項( 會呼叫例項的 onNewIntent() )，否則就會建立新的例項並放入棧頂，即使棧中已經存在該Activity的例項，只要不在棧頂，都會建立新的例項。

• singleTask 模式

如果在棧中已經有該Activity的例項，就重用該例項(會呼叫例項的 onNewIntent() )。重用時，會讓該例項回到棧頂，因此在它上面的例項將會被移出棧。如果棧中不存在該例項，將會建立新的例項放入棧中。

• singleInstance 模式

在一個新棧中建立該Activity的例項，並讓多個應用共享該棧中的該Activity例項。一旦該模式的Activity例項已經存在於某個棧中，任何應用再啟用該Activity時都會重用該棧中的例項( 會呼叫例項的 onNewIntent() )。其效果相當於多個應用共享一個應用，不管誰啟用該 Activity 都會進入同一個應用中。

設定啟動模式的位置在 AndroidManifest.xml 檔案中 Activity 元素的 Android:launchMode 屬性。

singleTop適合接收通知啟動的內容顯示頁面。例如，某個新聞客戶端的新聞內容頁面，如果收到10個新聞推送，每次都開啟一個新聞內容頁面是很煩人的。

singleTask適合作為程式入口點。例如瀏覽器的主介面。不管從多少個應用啟動瀏覽器，只會啟動主介面一次，其餘情況都會走onNewIntent，並且會清空主介面上面的其他頁面。

singleInstance應用場景：鬧鈴的響鈴介面。 你以前設定了一個鬧鈴：上午6點。在上午5點58分，你啟動了鬧鈴設定介面，並按 Home 鍵回桌面；在上午5點59分時，你在微信和朋友聊天；在6點時，鬧鈴響了，並且彈出了一個對話方塊形式的 Activity(名為 AlarmAlertActivity) 提示你到6點了(這個 Activity 就是以 SingleInstance 載入模式開啟的)，你按返回鍵，回到的是微信的聊天介面，這是因為 AlarmAlertActivity 所在的 Task 的棧只有他一個元素， 因此退出之後這個 Task 的棧空了。如果是以 SingleTask 開啟 AlarmAlertActivity，那麼當鬧鈴響了的時候，按返回鍵應該進入鬧鈴設定介面。

Activity中類似onCreate、onStart運用了哪種設計模式，優點是什麼

模板模式。每次新建一個Actiivty時都會覆蓋onCreate，onStart等方法,這些方法在父類中就相當於一個模板。

如何將一個Activity設定成視窗的樣式

• 在AndroidManifest.xml檔案中設定當前需要改變成視窗樣式的Activity的屬性。

1

android:theme="@android:style/Theme.Dialog"

• 在styles.xml檔案中自定義一個主題樣式，改主題樣式必須繼承Dialog的樣式.

Activity的啟動過程

1. 無論是通過Launcher來啟動Activity，還是通過Activity內部呼叫startActivity介面來啟動新的Activity，都通過Binder程序間通訊進入到ActivityManagerService程序中，並且呼叫ActivityManagerService.startActivity介面；
2. ActivityManagerService呼叫ActivityStack.startActivityMayWait來做準備要啟動的Activity的相關資訊；
3. ActivityStack通知ApplicationThread要進行Activity啟動排程了，這裡的ApplicationThread代表的是呼叫ActivityManagerService.startActivity介面的程序，對於通過點選應用程式圖示的情景來說，這個程序就是Launcher了，而對於通過在Activity內部呼叫startActivity的情景來說，這個程序就是這個Activity所在的程序了；
4. ApplicationThread不執行真正的啟動操作，它通過呼叫ActivityManagerService.activityPaused介面進入到ActivityManagerService程序中，看看是否需要建立新的程序來啟動Activity；
5. 對於通過點選應用程式圖示來啟動Activity的情景來說，ActivityManagerService在這一步中，會呼叫startProcessLocked來建立一個新的程序，而對於通過在Activity內部呼叫startActivity來啟動新的Activity來說，這一步是不需要執行的，因為新的Activity就在原來的Activity所在的程序中進行啟動；
6. ActivityManagerService呼叫ApplicationThread.scheduleLaunchActivity介面，通知相應的程序執行啟動Activity的操作；
7. ApplicationThread把這個啟動Activity的操作轉發給ActivityThread，ActivityThread通過ClassLoader匯入相應的Activity類，然後把它啟動起來。

window和activity之間關係？

WindowManager 的相關知識

Activity、Window 和 View 三者的區別

• 一個 Activity 構造的時候一定會構造一個 Window(PhoneWindow)，並且只有一個。
• 這個Window會有一個ViewRoot(View、ViewGroup)。
• 通過addView()載入佈局。
• WindowMangerService 接收訊息，並且回到 Activity 函式，比如onKeyDown()。

Activity 是控制單元，Window 是承載模型，View 是顯示檢視

一個activity開啟另外一個activity，再開啟一個activity？回去的時候發生了什麼操作？

onActivityResult(int requestCode, int resultCode, Intent data)方法的用法；

如果你想在Activity中得到新開啟Activity關閉後返回的資料，你需要使用系統提供的startActivityForResult(Intent intent,int requestCode)方法開啟新的Activity，新的Activity關閉後會向前面的Activity傳回資料，為了得到傳回的資料，你必須在前面的Activity中重寫onActivityResult(int requestCode, int resultCode,Intent data)方法。

不用Service,B頁面為音樂播放，從A跳到B，再返回，如何使音樂繼續播放？

A使用startActivityForResult方法開啟B，B類結束時呼叫finish;A類的Intent有一個子Activity結束事件onActivityResult，在這個事件裡繼續播放音樂。

記憶體不足時，怎麼保持Activity的一些狀態，在哪個方法裡面做具體操作？

在onSaveInstanceState方法中儲存Activity的狀態，在onRestoreInstanceState或onCreate方法中恢復Activity的狀態

onSaveInstanceState方法

• 用於儲存Activity的狀態儲存一些臨時資料
• Activity被覆蓋或進入後臺，由於系統資源不足被kill會被呼叫
• 使用者改變螢幕方向會被呼叫
• 跳轉到其它Activity或按Home進入後臺會被呼叫
• 會在onStop之前被呼叫，和onPause的順序不固定的

onRestoreInstanceState(Bundle savedInstanceState)方法

• 用於恢復儲存的臨時資料，此方法的Bundle引數也會傳遞到onCreate方法中，你也可以在onCreate(Bundle savedInstanceState)方法中恢復資料
• onRestoreInstanceState和onCreate的區別：當onRestoreInstanceState被呼叫時Bundle引數一定是有值的，不用做為null判斷，onCreate的Bundle則可能會為null。官方文件建議在此方法中進行資料恢復。
• 由於系統資源不足被kill之後又回到此Activity會被呼叫
• 使用者改變螢幕方向重建Activity時會被呼叫
• 會在onStart之後被呼叫

同一個程式不同的Activity如何放在不同的任務棧中？

需要為不同的activity設定不同的affinity屬性，啟動activity的Intent需要包含FLAG_ACTIVITY_NEW_TASK標記。

如何安全退出已呼叫多個Activity的Application？

• 記錄開啟的Activity：每開啟一個Activity，就記錄下來。在需要退出時，關閉每一個Activity即可。
• 傳送特定廣播：在需要結束應用時，傳送一個特定的廣播，每個Activity收到廣播後，關閉即可。
• 遞迴退出：在開啟新的Activity時使用startActivityForResult，然後自己加標誌，在onActivityResult中處理，遞迴關閉。

有幾種在activity之間切換的方法？

startActivity()

startActivityForResult()

Fragment

Fragment生命週期

Activity中如何動態的新增Fragment？

123456789101112131415161718

//向活動新增碎片,根據螢幕的縱向和橫向顯示//1,獲取碎片管理器FragmentManager fragment=getFragmentManager();//2,碎片的顯示需要使用FragmentTransaction類操作FragmentTransaction transacction=fragment.beginTransaction();//獲取螢幕管理器和預設的顯示Display display=getWindowManager().getDefaultDisplay();//判斷橫屏if(display.getWidth()>display.getHeight()){	//獲取java類	Frament1 frament1 =  new Frament1();	transacction.replace(android.R.id.content, frament1);}else{	Frament2 frament2 =  new Frament2();	transacction.replace(android.R.id.content, frament2);}//使用FragmentTransaction必須要committransacction.commit();

Fragment 特點

• Fragment可以作為Activity介面的一部分組成出現；
• 可以在一個Activity中同時出現多個Fragment，並且一個Fragment也可以在多個Activity中使用；
• 在Activity執行過程中，可以新增、移除或者替換Fragment；
• Fragment可以響應自己的輸入事件，並且有自己的生命週期，它們的生命週期會受宿主Activity的生命週期影響。
• Fragment可以輕鬆得建立動態靈活的UI設計，可以適應於不同的螢幕尺寸。從手機到平板電腦。
• Fragment 解決Activity間的切換不流暢，輕量切換。
• Fragment 替代TabActivity做導航，效能更好。
• Fragment做區域性內容更新更方便，原來為了達到這一點要把多個佈局放到一個activity裡面，現在可以用多Fragment來代替，只有在需要的時候才載入Fragment，提高效能。

Fragment巢狀多個Fragment會出現bug嗎？

怎麼理解Activity和Fragment的關係？

• Fragment 擁有和 Activity 一致的生命週期，它和 Activity 一樣被定義為 Controller 層的類。有過中大型專案開發經驗的開發者，應該都會遇到過 Activity 過於臃腫的情況，而 Fragment 的出現就是為了緩解這一狀況，可以說 它將螢幕分解為多個「Fragment（碎片）」（這句話很重要），但它又不同於 View，它乾的實質上就是 Activity 的事情，負責控制 View 以及它們之間的邏輯。
• 將螢幕碎片化為多個 Fragment 後，其實 Activity 只需要花精力去管理當前螢幕內應該顯示哪些 Fragments，以及應該對它們進行如何佈局就行了。這是一種元件化的思維，用 Fragment 去組合了一系列有關聯的 UI 元件，並管理它們之間的邏輯，而 Activity 負責在不同螢幕下（例如橫豎屏）佈局不同的 Fragments 組合。
• 這種碎片不單單能管理可視的 Views，它也能執行不可視的 Tasks，它提供了 retainInstance 屬性，能夠在 Activity 因為螢幕狀態發生改變（例如切換橫豎屏時）而銷燬重建時，依然保留例項。這示意著我們能在 RetainedFragment 裡面執行一些在螢幕狀態發生改變時不被中斷的操作。例如使用 RetainedFragment 來快取線上音樂檔案，它在橫豎屏切換時依然維持下載進度，並通過一個 DialogFragment 來展示進度。

Service

Service的生命週期。

Service是執行在後臺的android元件，沒有使用者介面，不能與使用者互動，可以執行在自己的程序，也可以執行在其他應用程式的上下
文裡。

Service隨著啟動形式的不同，其生命週期稍有差別。當用Context.startService()來啟動時，Service的生命週期依次為:oncreate——>onStartCommand——>onDestroy

當用Context.bindService()啟動時:onStart——>onBind——>onUnbind——>onDestroy

Service有哪些啟動方法，有什麼區別，怎樣停用Service？

Service啟動方式有兩種；一是Context.startService和Context.bindService。

區別是通過startService啟動時Service元件和應用程式沒多大的聯絡；當用訪問者啟動之後，如果訪問者不主動關閉，Service就不會關閉，Service元件之間因為沒什麼關聯，所以Service也不能和應用程式進行資料互動。

而通過bindService進行繫結時，應用程式可以通過ServiceConnection進行資料互動。在實現Service時重寫的onBind方法中，其返回的物件會傳給ServiceConnection物件的onServiceConnected(ComponentName name, IBinder service)中的service引數；也就是說獲取了serivce這個引數就得到了Serivce元件返回的值。Context.bindService(Intent intent,ServiceConnection conn,int flag)其中只要與Service連線成功conn就會呼叫其onServiceConnected方法

停用Service使用Context.stopService

註冊Service需要注意什麼

無論使用哪種啟動方法，都需要在xml裡註冊你的Service，就像這樣:

123

<service  android:name=".packnameName.youServiceName"  android:enabled="true" />

service 可以執行耗時操作嗎

不能，超過20s就會出現ARN

Service和Activity在同一個執行緒嗎

預設情況下是在同一個主執行緒中。但可以通過配置android:process=”:remote” 屬性讓 Service 執行在不同的程序。

Service分為本地服務（LocalService）和遠端服務（RemoteService）：

1、本地服務依附在主程序上而不是獨立的程序，這樣在一定程度上節約了資源，另外Local服務因為是在同一程序因此不需要IPC，

也不需要AIDL。相應bindService會方便很多。主程序被Kill後，服務便會終止。

2、遠端服務為獨立的程序，對應程序名格式為所在包名加上你指定的android:process字串。由於是獨立的程序，因此在Activity所在程序被Kill的時候，該服務依然在執行，

不受其他程序影響，有利於為多個程序提供服務具有較高的靈活性。該服務是獨立的程序，會佔用一定資源，並且使用AIDL進行IPC稍微麻煩一點。

按使用方式可以分為以下三種：

1. startService 啟動的服務：主要用於啟動一個服務執行後臺任務，不進行通訊。停止服務使用stopService；
2. bindService 啟動的服務：該方法啟動的服務可以進行通訊。停止服務使用unbindService
3. startService 同時也 bindService 啟動的服務：停止服務應同時使用stepService與unbindService

Service與Activity怎麼實現通訊

• 通過Binder物件。Activity呼叫bindService (Intent service, ServiceConnection conn, int flags)方法，得到Service物件的一個引用，這樣Activity可以直接呼叫到Service中的方法，如果要主動通知Activity，我們可以利用回撥方法。Binder 相關知識參考：http://blog.csdn.net/boyupeng/article/details/47011383

• 通過廣播。Service向Activity傳送訊息，可以使用廣播，當然Activity要註冊相應的接收器。比如Service要向多個Activity傳送同樣的訊息的話，用這種方法就更好。

Service裡面可以彈出 dialog 或 Toast 嗎

可以。getApplicationContext()

Toast必須在UI主執行緒上才能正常顯示，而在Service中是無法獲得Acivity的Context的，在service中想顯示出Toast只需將show的訊息傳送給主執行緒Looper就可以了。此時便可顯示Toast。

1234567

Handler handler = new Handler(Looper.getMainLooper());  handler.post(new Runnable() {    public void run() {      Toast.makeText(getApplicationContext(), "存Service is runing!",                     Toast.LENGTH_SHORT).show();    }  });

Dialog的用法與此類似，但是要多加個許可權，在manifest中新增此許可權以彈出dialog

12

<uses-permission Android:name="android.permission.SYSTEM_ALERT_WINDOW" />dialog.getWindow().setType((WindowManager.LayoutParams.TYPE_SYSTEM_ALERT));

什麼時候使用Service?

比如播放多媒體的時候，使用者啟動了其他的Activity這個時候程式要在後臺繼續播放。比如檢測SD卡上檔案的變化。在或者在後臺記錄你地理位置的改變等等。

說說Activity、Intent、Service是什麼關係

一個Activity通常是一個單獨的螢幕，每一個Activity都被實現為一個單獨的類，這些類都是從Activity基類中繼承來的，Activity類顯示有檢視控制元件組成的使用者介面，並對檢視控制元件的事件做出響應。

Intent的呼叫是用來進行架構螢幕之間的切換的。Intent是描述應用想要做什麼。Intent資料結果中最重要的部分是動作和動作對應的資料，一個動作對應一個動作資料。

Service是執行在後臺的程式碼，不能與使用者互動，可以執行在自己的程序，也可以執行在其他應用程式的上下文裡。需要通過某一個Activity或其他Context物件來呼叫。

Activity 跳轉到Activity,Activtiy啟動Service,Service開啟Activity都需要Intent表明跳轉的意圖，以及傳遞引數，Intent是這些元件間訊號傳遞的傳承者。

怎麼在啟動一個activity時就啟動一個service

在activity的onCreate裡寫startService(xxx);然後this.finish();結束自己..

這是最簡單的方法 可能會有螢幕一閃的現象，如果UI要求嚴格的話用AIDL把

為什麼在Service中建立子執行緒而不是Activity中

這是因為Activity很難對Thread進行控制，當Activity被銷燬之後，就沒有任何其它的辦法可以再重新獲取到之前建立的子執行緒的例項。而且在一個Activity中建立的子執行緒，另一個Activity無法對其進行操作。但是Service就不同了，所有的Activity都可以與Service進行關聯，然後可以很方便地操作其中的方法，即使Activity被銷燬了，之後只要重新與Service建立關聯，就又能夠獲取到原有的Service中Binder的例項。因此，使用Service來處理後臺任務，Activity就可以放心地finish，完全不需要擔心無法對後臺任務進行控制的情況。

Service 與 Thread 的區別

很多時候，你可能會問，為什麼要用 Service，而不用 Thread 呢，因為用 Thread 是很方便的，比起 Service 也方便多了，下面我詳細的來解釋一下。

1). Thread：Thread 是程式執行的最小單元，它是分配CPU的基本單位。可以用 Thread 來執行一些非同步的操作。

2). Service：Service 是android的一種機制，當它執行的時候如果是Local Service，那麼對應的 Service 是執行在主程序的 main 執行緒上的。如：onCreate，onStart 這些函式在被系統呼叫的時候都是在主程序的 main 執行緒上執行的。如果是Remote Service，那麼對應的 Service 則是執行在獨立程序的 main 執行緒上。因此請不要把 Service 理解成執行緒，它跟執行緒半毛錢的關係都沒有！

既然這樣，那麼我們為什麼要用 Service 呢？其實這跟 android 的系統機制有關，我們先拿 Thread 來說。Thread 的執行是獨立於 Activity 的，也就是說當一個 Activity 被 finish 之後，如果你沒有主動停止 Thread 或者 Thread 裡的 run 方法沒有執行完畢的話，Thread 也會一直執行。因此這裡會出現一個問題：當 Activity 被 finish 之後，你不再持有該 Thread 的引用。另一方面，你沒有辦法在不同的 Activity 中對同一 Thread 進行控制。

舉個例子：如果你的 Thread 需要不停地隔一段時間就要連線伺服器做某種同步的話，該 Thread 需要在 Activity 沒有start的時候也在執行。這個時候當你 start 一個 Activity 就沒有辦法在該 Activity 裡面控制之前建立的 Thread。因此你便需要建立並啟動一個 Service ，在 Service 裡面建立、執行並控制該 Thread，這樣便解決了該問題（因為任何 Activity 都可以控制同一 Service，而系統也只會建立一個對應 Service 的例項）。

因此你可以把 Service 想象成一種訊息服務，而你可以在任何有 Context 的地方呼叫 Context.startService、Context.stopService、Context.bindService，Context.unbindService，來控制它，你也可以在 Service 裡註冊 BroadcastReceiver，在其他地方通過傳送 broadcast 來控制它，當然這些都是 Thread 做不到的。

如何保證 Service 在後臺不被 kill

• onStartCommand方法，返回START_STICKY

START_STICKY 在執行onStartCommand後service程序被kill後，那將保留在開始狀態，但是不保留那些傳入的intent。不久後service就會再次嘗試重新建立，因為保留在開始狀態，在建立 service後將保證呼叫onstartCommand。如果沒有傳遞任何開始命令給service，那將獲取到null的intent。

START_NOT_STICKY 在執行onStartCommand後service程序被kill後，並且沒有新的intent傳遞給它。Service將移出開始狀態，並且直到新的明顯的方法（startService）呼叫才重新建立。因為如果沒有傳遞任何未決定的intent那麼service是不會啟動，也就是期間onstartCommand不會接收到任何null的intent。

START_REDELIVER_INTENT 在執行onStartCommand後service程序被kill後，系統將會再次啟動service，並傳入最後一個intent給onstartCommand。直到呼叫stopSelf(int)才停止傳遞intent。如果在被kill後還有未處理好的intent，那被kill後服務還是會自動啟動。因此onstartCommand不會接收到任何null的intent。

• 提升service優先順序

在AndroidManifest.xml檔案中對於intent-filter可以通過android:priority = “1000”這個屬性設定最高優先順序，1000是最高值，如果數字越小則優先順序越低，同時適用於廣播。

• 提升service程序優先順序

Android中的程序是託管的，當系統程序空間緊張的時候，會依照優先順序自動進行程序的回收。Android將程序分為6個等級,它們按優先順序順序由高到低依次是:

1.前臺程序( FOREGROUND_APP)
2.可視程序(VISIBLE_APP )
3.次要服務程序(SECONDARY_SERVER )
4.後臺程序 (HIDDEN_APP)
5.內容供應節點(CONTENT_PROVIDER)
6.空程序(EMPTY_APP)

當service執行在低記憶體的環境時，將會kill掉一些存在的程序。因此程序的優先順序將會很重要，可以使用startForeground 將service放到前臺狀態。這樣在低記憶體時被kill的機率會低一些。

• onDestroy方法裡重啟service

service +broadcast 方式，就是當service走ondestory的時候，傳送一個自定義的廣播，當收到廣播的時候，重新啟動service；

• Application加上Persistent屬性
• 監聽系統廣播判斷Service狀態

通過系統的一些廣播，比如：手機重啟、介面喚醒、應用狀態改變等等監聽並捕獲到，然後判斷我們的Service是否還存活，別忘記加許可權啊。

什麼是IntentService？有何優點？

IntentService也是一個Service，是Service的子類；IntentService和Service有所不同，通過Looper和Thread來解決標準Service中處理邏輯的阻塞的問題。

優點：Activity的程序，當處理Intent的時候，會產生一個對應的Service,Android的程序處理器現在會盡可能的不kill掉你。

IntentService的使用場景與特點。

IntentService是Service的子類，是一個非同步的，會自動停止的服務，很好解決了傳統的Service中處理完耗時操作忘記停止並銷燬Service的問題

優點：

• 一方面不需要自己去new Thread
• 另一方面不需要考慮在什麼時候關閉該Service

onStartCommand中回調了onStart，onStart中通過mServiceHandler傳送訊息到該handler的handleMessage中去。最後handleMessage中回撥onHandleIntent(intent)。

IntentService 作用是什麼

IntentService 是繼承於 Service 並處理非同步請求的一個類，在IntentService 內有一個工作執行緒來處理耗時操作，啟動 IntentService 的方式和啟動傳統 Service 一樣，同時，當任務執行完後，IntentService 會自動停止，而不需要我們去手動控制。另外，可以啟動 IntentService 多次，而每一個耗時操作會以工作佇列的方式在 IntentService 的 onHandleIntent 回撥方法中執行，並且，每次只會執行一個工作執行緒，執行完第一個再執行第二個，以此類推。

IntentService 與 Service的異同

• 直接建立一個預設的工作執行緒,該執行緒執行所有的intent傳遞給onStartCommand()區別於應用程式的主執行緒。
• 直接建立一個工作佇列,將一個意圖傳遞給你onHandleIntent()的實現,所以我們就永遠不必擔心多執行緒。
• 當請求完成後自己會呼叫stopSelf()，所以你就不用呼叫該方法了。
• 提供的預設實現onBind()返回null，所以也不需要重寫這個方法。so easy啊
• 提供了一個預設實現onStartCommand(),將意圖工作佇列,然後傳送到你onHandleIntent()實現。真是太方便了

ContentProvider

ContentProvider 簡介

ContentProvider(內容提供者)：為儲存和獲取資料提供統一的介面。可以在不同的應用程式之間共享資料。Android已經為常見的一些資料提供了預設的ContentProvider

1. ContentProvider 為儲存和讀取資料提供了統一的介面
2. 使用ContentProvider，應用程式可以實現 app 間資料共享
3. Android內建的許多資料都是使用ContentProvider形式，供開發者呼叫的(如視訊，音訊，圖片，通訊錄等)

請介紹下ContentProvider是如何實現資料共享的

建立一個屬於你自己的Content provider或者將你的資料新增到一個已經存在的Content provider中，前提是有相同資料型別並且有寫入Content provider的許可權。

ContentProvider使用方法

Broadcast

註冊廣播有哪幾種方式,有什麼區別

• 在應用程式的程式碼中註冊

12

registerReceiver（receiver，filter）；// 註冊BroadcastReceiverunregisterReceiver（receiver）；// 取消註冊BroadcastReceiver

當BroadcastReceiver更新UI，通常會使用這樣的方法註冊。啟動Activity時候註冊BroadcastReceiver，Activity不可見時候，取消註冊。

• 在androidmanifest.xml當中註冊

12345

<receiver>    <intent-filter>     <action Android:name = "android.intent.action.PICK"/>    </intent-filter></receiver>

1)第一種不是常駐型廣播，也就是說廣播跟隨程式的生命週期。

2)第二種是常駐型，也就是說當應用程式關閉後，如果有資訊廣播來，程式也會被系統呼叫自動執行。

• 靜態註冊：在AndroidManifest.xml檔案中進行註冊，當App退出後，Receiver仍然可以接收到廣播並且進行相應的處理
• 動態註冊：在程式碼中動態註冊，當App退出後，也就沒辦法再接受廣播了

一個 app 被殺掉程序後，是否還能收到廣播

靜態註冊的常駐型廣播接收器還能接收廣播。

Android引入廣播機制的用意？

無序廣播、有序廣播

本地廣播和全域性廣播有什麼差別

全域性廣播 BroadcastReceiver 是針對應用間、應用與系統間、應用內部進行通訊的一種方式。

本地廣播 LocalBroadcastReceiver 僅在自己的應用內傳送接收廣播，也就是隻有自己的應用能收到。因廣播資料在本應用範圍內傳播，不用擔心隱私資料洩露的問題。 不用擔心別的應用偽造廣播，造成安全隱患。 相比在系統內傳送全域性廣播，它更高效。

Intent

Intent的使用方法，可以傳遞哪些資料型別。

通過查詢Intent/Bundle的API文件，我們可以獲知，Intent/Bundle支援傳遞基本型別的資料和基本型別的陣列資料，以及String/CharSequence型別的資料和String/CharSequence型別的陣列資料。而對於其它型別的資料貌似無能為力，其實不然，我們可以在Intent/Bundle的API中看到Intent/Bundle還可以傳遞Parcelable（包裹化，郵包）和Serializable（序列化）型別的資料，以及它們的陣列/列表資料。

所以要讓非基本型別和非String/CharSequence型別的資料通過Intent/Bundle來進行傳輸，我們就需要在資料型別中實現Parcelable介面或是Serializable介面。

介紹一下Intent、IntentFilter

Context

Context區別

• Activity和Service以及Application的Context是不一樣的,Activity繼承自ContextThemeWraper.其他的繼承自ContextWrapper
• 每一個Activity和Service以及Application的Context都是一個新的ContextImpl物件
• getApplication()用來獲取Application例項的，但是這個方法只有在Activity和Service中才能呼叫的到。那麼也許在絕大多數情況下我們都是在Activity或者Service中使用Application的，但是如果在一些其它的場景，比如BroadcastReceiver中也想獲得Application的例項，這時就可以藉助getApplicationContext()方法，getApplicationContext()比getApplication()方法的作用域會更廣一些，任何一個Context的例項，只要呼叫getApplicationContext()方法都可以拿到我們的Application物件。
• Activity在建立的時候會new一個ContextImpl物件並在attach方法中關聯它，Application和Service也差不多。ContextWrapper的方法內部都是轉調ContextImpl的方法
• 建立對話方塊傳入Application的Context是不可以的
• 儘管Application、Activity、Service都有自己的ContextImpl，並且每個ContextImpl都有自己的mResources成員，但是由於它們的mResources成員都來自於唯一的ResourcesManager例項，所以它們看似不同的mResources其實都指向的是同一塊記憶體
• Context的數量等於Activity的個數 + Service的個數 + 1，這個1為Application

Application Context 和 Activity Context 異同

Context 的理解

Handler

Handler 原理

Andriod提供了Handler 和 Looper 來滿足執行緒間的通訊。Handler先進先出原則。Looper類用來管理特定執行緒內物件之間的訊息交換(MessageExchange)。

Looper: 一個執行緒可以產生一個Looper物件，由它來管理此執行緒裡的MessageQueue(訊息佇列)。

Handler: 你可以構造Handler物件來與Looper溝通，以便push新訊息到MessageQueue裡;或者接收Looper從Message Queue取出)所送來的訊息。

Message Queue(訊息佇列):用來存放執行緒放入的訊息。

執行緒：UIthread 通常就是main thread，而Android啟動程式時會替它建立一個MessageQueue。

參考：

Handler訊息機制，postDelayed會造成執行緒阻塞嗎？對記憶體有什麼影響？

Handler, Looper的理解

相關推薦