Activity生命周期和啟動模式理解

一、生命周期

1.正常情況下生命周期分析

activity_lifecycle.png

完整生命周期:onCreate -> onDestroy
可見生命周期:onStart -> onStop
前臺生命周期: onResume -> onPause

2.常見生命周期的區別

1. onCreate 和 onStart

(1)可見與不可見的區別。前者不可見,后者可見。
(2)onCreate方法只在Activity創建時執行一次,而onStart方法在Activity的切換以及按Home鍵返回桌面再切回應用的過程中被多次調用。

2.onStart 和 onRestart

如果一個activity第一次創建,那么只會走onStart,如果是切換應用或者桌面,那么就會走onRestart
If it's destroyed onCreate(.) > onStart(.) > onResume(.) is called(variables are lost, redraw).
If it's stopped onRestart(.) > onStart(.) > onResume(.) is called(variables are not lost, redraw)

3.onStart 和 onResume

onStart activity 可見,不在前臺
onResume activity 可見,前臺且可與用戶交互
這2個的主要區別就是Activity此時是否可以與用戶交互

4.onPause 和 onStop

這2個狀態通常是配對執行的,
有一種情況是特殊的,新啟動的Activity是一個透明的界面,那么第一個Activity執行onPause后,onStop是不會調用的

<activity android:name=".SecondActivity"
    android:theme="@style/Theme.AppCompat.Dialog" />

5.onStop & onDestroy

onStop階段Activity還沒有被銷毀,對象還在內存中,此時可以通過切換Activity再次回到該Activity,而onDestroy階段Activity被銷毀

tips:

不同的生命周期適合不同的資源初始化或者釋放工作,實踐和工作中多總結。http://www.lxweimin.com/p/fb44584daee3

3.常見操作的生命周期

1.Launcher點擊啟動

01-16 10:57:22.429 26845-26845/? I/ActivityLife: onCreate...
01-16 10:57:22.429 26845-26845/? I/ActivityLife: onStart...
01-16 10:57:22.429 26845-26845/? I/ActivityLife: onResume...

2.back鍵退出

01-16 10:58:58.139 26845-26845/? I/ActivityLife: onPause...
01-16 10:58:58.459 26845-26845/? I/ActivityLife: onStop...
01-16 10:58:58.459 26845-26845/? I/ActivityLife: onDestroy...

3.HOME鍵退出然后再次點擊啟動

01-16 10:59:49.019 26845-26845/? I/ActivityLife: onPause...
01-16 10:59:49.309 26845-26845/? I/ActivityLife: onStop...
01-16 11:00:06.519 26845-26845/? I/ActivityLife: onRestart...
01-16 11:00:06.519 26845-26845/? I/ActivityLife: onStart...
01-16 11:00:06.519 26845-26845/? I/ActivityLife: onResume...

4.鎖屏解鎖

01-16 11:02:33.739 26845-26845/? I/ActivityLife: onPause...
01-16 11:02:33.779 26845-26845/? I/ActivityLife: onStop...
01-16 11:02:35.509 26845-26845/? I/ActivityLife: onRestart...
01-16 11:02:35.529 26845-26845/? I/ActivityLife: onStart...
01-16 11:02:35.529 26845-26845/? I/ActivityLife: onResume...

2.異常情況下的生命周期分析

1.觸發情況:

1.系統資源相關的配置發生變化導致Activity被殺死和重建
2.系統內存資源不足,lmk

2.執行的特殊生命周期:

onSaveInstanceState & onRestoreInstanceState

1.onSaveInstanceState 通常在onStop之前,用于保存Activity數據
2.onRestoreInstanceState 通常在onStart之后,恢復Activity數據

tips:

在onCreate和onRestoreInstanceState中都有一個參數savedInstanceState,二者的區別是:onRestoreInstanceState的參數是一定有值的,我們不用額外的判斷它是否為空,但是onCreate不行,onCreate如果正常啟動的話,savedInstanceState的值是null

3.典型示例,系統配置變化,屏幕旋轉

public class MainActivity extends AppCompatActivity {

    private static final String TAG = "ActivityLife";

    private static final String EDIT_TAG = "edit_tag";
    private EditText editText;

    @Override
    protected void onSaveInstanceState(Bundle outState) {
        Log.i(TAG, "onSaveInstanceState...");
        super.onSaveInstanceState(outState);
        String s = editText.getText().toString();
        outState.putString(EDIT_TAG,s);
    }

    @Override
    protected void onRestoreInstanceState(Bundle savedInstanceState) {
        super.onRestoreInstanceState(savedInstanceState);
        Log.i(TAG, "onRestoreInstanceState...");
        //onCreate 或者這里恢復數據均可
        editText.setText(savedInstanceState.getString(EDIT_TAG));
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Log.i(TAG, "onCreate...");
        editText = (EditText) findViewById(R.id.edit_content);
        if (savedInstanceState != null){
            Log.i(TAG, "onCreate savedInstanceState is not null");
            editText.setText(savedInstanceState.getString(EDIT_TAG));
        }
    }
}

從Lanucher啟動并且旋轉一次屏幕,生命周期如下:

01-16 11:59:30.459 29726-29726/? I/ActivityLife: onCreate...
01-16 11:59:30.459 29726-29726/? I/ActivityLife: onStart...
01-16 11:59:30.459 29726-29726/? I/ActivityLife: onResume...
01-16 11:59:38.609 29726-29726/? I/ActivityLife: onPause...
01-16 11:59:38.609 29726-29726/? I/ActivityLife: onSaveInstanceState...
01-16 11:59:38.619 29726-29726/? I/ActivityLife: onStop...
01-16 11:59:38.619 29726-29726/? I/ActivityLife: onDestroy...
01-16 11:59:38.669 29726-29726/? I/ActivityLife: onCreate...
01-16 11:59:38.669 29726-29726/? I/ActivityLife: onCreate savedInstanceState is not null
01-16 11:59:38.669 29726-29726/? I/ActivityLife: onStart...
01-16 11:59:38.669 29726-29726/? I/ActivityLife: onRestoreInstanceState...
01-16 11:59:38.669 29726-29726/? I/ActivityLife: onResume...

4.onConfigurationChanged

當系統配置發生變化,如果不希望Activity重新創建,可以在AndroidManifest文件中給Activity加上屬性,以屏幕旋轉為例

android:configChanges="orientation|screenSize"

注意:從 Android 3.2(API 級別 13)開始,當設備在縱向和橫向之間切換時,“屏幕尺寸”也會發生變化。因此,在開發針對 API 級別 13 或更高版本(正如 minSdkVersion 和 targetSdkVersion 屬性中所聲明)的應用時,若要避免由于設備方向改變而導致運行時重啟,則除了 "orientation" 值以外,您還必須添加 "screenSize" 值。 也就是說,您必須聲明 android:configChanges="orientation|screenSize"。

configChanges相關屬性

config_changes.PNG

二、Activity的啟動模式

1.Activity的四種啟動模式

standard:標準模式,每次啟動一個Activity都會重新創建一個新的實例,不管這個實例是否已經存在
singleTop:棧頂復用模式,如果新的Activity已經位于任務棧的棧頂,那么此Activity就不會被重新創建,同時他的onNewIntent方法會被回調
singleTask:棧內復用模式,如果一個Activity在一個任務棧內存在,那么多次啟動這個Activity都不會重新創建實例,它的onNewIntent方法也會被回調
singleInstance:單實例模式,具有此種模式的Activity只能單獨的位于一個任務棧中

standard 和 singleTop都比較好理解,下面主要分析下singleTask和singleInstance的特點。會用到的調試命令:

adb shell dumpsys activity | grep com.example.sven.activitydemo

2.singleTask的特點

1.singleTask 和 taskAffinity

1.launchMode=singleTask 的應用啟動時是否會創建新的任務和taskAffinity屬性有關

設置了"singleTask"啟動模式的Activity,它在啟動的時候,會先在系統中查找屬性值affinity等于它的屬值taskAffinity的任務存在;如果存在這樣的任務,它就會在這個任務中啟動,否則就會在新任務中啟動。因此如果我們想要設置了"singleTask"啟動模式的Activity在新的任務中啟動,就要為它設置一個唯一的taskAffinity屬性值。

示例:A應用中,A0(表示啟動界面,A1跳轉的第二個界面,依次類推)A0-A1
(1)設置SecondActivity launchMode="singleTask",但不指定taskAffinity

TaskRecord{576dbde #53 A=com.example.sven.activitydemo U=0 sz=2}
    Run #5: ActivityRecord{dc04be8 u0 com.example.sven.activitydemo/.SecondActivity t53}
    Run #4: ActivityRecord{bebf9d2 u0 com.example.sven.activitydemo/.MainActivity t53}

可以看到,雖然設置了singleTask的lanuchModel,但是MainActivity和SecondActivity還是在同一個任務棧中

(2)設置SecondActivity launchMode="singleTask" ,同時指定taskAffinity = "com.example.sven.activitydemo.second"

TaskRecord{705495 #55 A=com.example.sven.activitydemo.second U=0 sz=1}
    Run #5: ActivityRecord{5a9b163 u0 com.example.sven.activitydemo/.SecondActivity t55}
TaskRecord{9d799aa #54 A=com.example.sven.activitydemo U=0 sz=1}
    Run #4: ActivityRecord{5e9adf5 u0 com.example.sven.activitydemo/.MainActivity t54}

可以看到,設置了taskAffinity后,新的Activity就運行在新的任務棧里了

tips:

默認情況下,所有Activity的所需任務棧名均為包名,所以說如果將上面的taskAffinity屬性設置為包名,SecondActivity也是不會在新的任務棧中啟動的

2.在同一個任務棧中具有唯一性
如果設置了"singleTask"啟動模式的Activity不是在新的任務中啟動時,它會在已有的任務中查看是否已經存在對應的Activity實例,如果存在,就會把位于這個Activity實例上面的Activity全部結束掉,最終這個Activity實例位于任務的堆棧頂端中。
示例:
MainActity SecondActivty ThirdActivty(以上3個Activity用A、B、C代表)在2種條件下執行如下過程 A -> B ->C -> A ->B

(1) SecondActivty launchMode="singleTask",taskAffinity=包名,最終棧中的結果如下

TaskRecord{8d620aa #62 A=com.example.sven.activitydemo U=0 sz=2}
    Run #5: ActivityRecord{ab051c1 u0 com.example.sven.activitydemo/.SecondActivity t62}
    Run #4: ActivityRecord{56fcc63 u0 com.example.sven.activitydemo/.MainActivity t62}

(2) 設置SecondActivty 指定 taskAffinity = "com.example.sven.activitydemo.second"

  TaskRecord{4e4a3bc #61 A=com.example.sven.activitydemo.second U=0 sz=1}
    Run #5: ActivityRecord{f48dc2b u0 com.example.sven.activitydemo/.SecondActivity t61}
  TaskRecord{ea52f45 #60 A=com.example.sven.activitydemo U=0 sz=1}
    Run #4: ActivityRecord{9e4ab1 u0 com.example.sven.activitydemo/.MainActivity t60}

可以看到在2種情況下, 不論是否設定taskAffinity,在SecondActivity棧頂的實例都被清掉了

3.任務(Task)不僅可以跨應用(Application),還可以跨進程(Process)

示例:
2個應用中A,B中,2個ActivityA1,B1的singleTask的Activity的taskAffinity設置為相同,執行如下過程 A0->A1,B0->B1

android:launchMode="singleTask"
android:taskAffinity="com.example.sven.activitydemo.second"

TaskRecord{a412e6e #71 A=com.example.sven.activitydemo.second U=0 sz=2}
    Run #5: ActivityRecord{12bc505 u0 com.example.sven.activitydemo2/.SecondActivityCopy t71}
  TaskRecord{fa790f #72 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #4: ActivityRecord{2610bd9 u0 com.example.sven.activitydemo2/.MainActivityCopy t72}
  TaskRecord{a412e6e #71 A=com.example.sven.activitydemo.second U=0 sz=2}
    Run #3: ActivityRecord{ca0064a u0 com.example.sven.activitydemo/.SecondActivity t71}
  TaskRecord{c224d9c #70 A=com.example.sven.activitydemo U=0 sz=1}
    Run #2: ActivityRecord{4257b8e u0 com.example.sven.activitydemo/.MainActivity t70}

可以看到相同taskAffinity的Run#5和Run#3是在同一個任務棧a412e6e中的。

tips:

Application,Task和Process的區別與聯系
application翻譯成中文時一般稱為“應用”或“應用程序”,在android中,總體來說一個應用就是一組組件的集合。
task是在程序運行時,只針對activity的概念。說白了,task是一組相互關聯的activity的集合,它是存在于framework層的一個概念,控制界面的跳轉和返回。這個task存在于一個稱為backstack的數據結構中,也就是說,framework是以棧的形式管理用戶開啟的activity。這個棧的基本行為是,當用戶在多個activity之間跳轉時,執行壓棧操作,當用戶按返回鍵時,執行出棧操作。
process一般翻譯成進程,進程是操作系統內核中的一個概念,表示直接受內核調度的執行單位。在應用程序的角度看,我們用java編寫的應用程序,運行在dalvik虛擬機中,可以認為一個運行中的dalvik虛擬機實例占有一個進程,所以,在默認情況下,一個應用程序的所有組件運行在同一個進程中。但是這種情況也有例外,即,應用程序中的不同組件可以運行在不同的進程中。只需要在manifest中用process屬性指定組件所運行的進程的名字。如下所示:

 <activity
        android:name=".SecondActivityCopy"
       android:process=":remote"
        android:allowTaskReparenting="true" />

4.allowTaskReparenting
一個應用A啟動另一個應用B的B1(standard模式)Activity,如果這個Activity的allowTaskReparenting屬性為true的話,那么B啟動后B1直接會轉移到B的任務棧中。現象就是A啟動B1,在啟動B時,顯示的就是B1,而不是B0

A -> B1:

TaskRecord{fc84b0d #46 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #1: ActivityRecord{8ebbcf3 u0 com.example.sven.activitydemo2/.SecondActivityCopy t46}
  TaskRecord{137b068 #45 A=com.example.sven.activitydemo U=0 sz=1}
    Run #0: ActivityRecord{b7827ad u0 com.example.sven.activitydemo/.MainActivity t45}


啟動B
TaskRecord{fc84b0d #46 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #1: ActivityRecord{8ebbcf3 u0 com.example.sven.activitydemo2/.SecondActivityCopy t46}
  TaskRecord{137b068 #45 A=com.example.sven.activitydemo U=0 sz=1}
    Run #0: ActivityRecord{b7827ad u0 com.example.sven.activitydemo/.MainActivity t45}

4.SingleInstance的特點

1.singleInstance模式啟動的Activity具有全局唯一性
整個系統中只會存在一個這樣的實例,如果在啟動這樣的Activity時,已經存在了一個實例,那么會把它所在的任務調度到前臺,重用這個實例。

示例:
2 個應用A,B,設置B1 launchMode="singleInstance", 執行如下過程,先B -> B1, 再A0 ->B1

TaskRecord{9b9bb06 #108 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #3: ActivityRecord{5520232 u0 com.example.sven.activitydemo2/.SecondActivityCopy t108}
TaskRecord{7b4a5c7 #107 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #2: ActivityRecord{6cf92f7 u0 com.example.sven.activitydemo2/.MainActivityCopy t107}

TaskRecord{9b9bb06 #108 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #4: ActivityRecord{5520232 u0 com.example.sven.activitydemo2/.SecondActivityCopy t108}
TaskRecord{3cccdb5 #109 A=com.example.sven.activitydemo U=0 sz=1}
    Run #3: ActivityRecord{facfdb u0 com.example.sven.activitydemo/.MainActivity t109}
TaskRecord{7b4a5c7 #107 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #2: ActivityRecord{6cf92f7 u0 com.example.sven.activitydemo2/.MainActivityCopy t107}

可以看到 2 個過程中B1 的Taskrecord沒有發生變化

2.singleInstance模式啟動的Activity具有獨占性
它會獨自占用一個任務,被他開啟的任何activity都會運行在其他任務中,但是否能夠開啟一個新任務,要看當前系統中是不是已經有了一個和要開啟的Activity的taskAffinity屬性相同的任務。
示例:
B0->B1 B1->A3(B0和B1又因為上個原則,所以是在不同的任務棧中)

  TaskRecord{94de3cf #69 A=com.example.sven.activitydemo U=0 sz=1}
    Run #2: ActivityRecord{89ba288 u0 com.example.sven.activitydemo/.ThirdActivity t69}
  TaskRecord{2ad415c #68 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #1: ActivityRecord{73d6ca u0 com.example.sven.activitydemo2/.SecondActivityCopy t68}
  TaskRecord{6d70c65 #67 A=com.example.sven.activitydemo2 U=0 sz=1}
    Run #0: ActivityRecord{3941c44 u0 com.example.sven.activitydemo2/.MainActivityCopy t67}

先啟動A0(A3和A0是運行在同一個棧中) B0->B1 B1->A3

TaskRecord{5db49f9 #71 A=com.example.sven.activitydemo U=0 sz=2}
  Run #3: ActivityRecord{dfea174 u0 com.example.sven.activitydemo/.ThirdActivity t71}
TaskRecord{e7e8d3e #73 A=com.example.sven.activitydemo2 U=0 sz=1}
  Run #2: ActivityRecord{cb12857 u0 com.example.sven.activitydemo2/.SecondActivityCopy t73}
TaskRecord{3f750ec #72 A=com.example.sven.activitydemo2 U=0 sz=1}
  Run #1: ActivityRecord{2efad8b u0 com.example.sven.activitydemo2/.MainActivityCopy t72}
TaskRecord{5db49f9 #71 A=com.example.sven.activitydemo U=0 sz=2}
  Run #0: ActivityRecord{c39fdab u0 com.example.sven.activitydemo/.MainActivity t71}

可以看到A3(Run #2)會在A0 (Run #5)的任務棧中46bac8a

tips:

啟動時是否開啟任務棧,考慮3個點:1.被啟動的Activity的launchModel,如果是singleTask要同時考慮它的taskAffinity
2.啟動Activity的launchmode(singleInstance)
3.當前是否有被啟動應用的任務棧

4.Activity的flag

1.Intent.FLAG_ACTIVITY_NEW_TASK

等價于 launchMode = singleTask

2.Intent.FLAG_ACTIVITY_SINGLE_TOP

等價于 launchMode = singleTop 設置singleTop 和一起使用taskAffinity ,只有singleTop的效果

3.Intent.FLAG_ACTIVITY_CLEAR_TOP

檢查目標棧中是否有對應的實例,如果有就會將該實例之上的所有棧都清掉
A-B(正常啟動)->C->A->B(clearTop方式啟動)
(1) B的launchmode 是standard

TaskRecord{fec37c7 #134 A=com.example.sven.activitydemo U=0 sz=4}
    Run #5: ActivityRecord{91e286b u0 com.example.sven.activitydemo/.MainActivity t134}
    Run #4: ActivityRecord{775d8ae u0 com.example.sven.activitydemo/.ThirdActivity t134}
    Run #3: ActivityRecord{20304d6 u0 com.example.sven.activitydemo/.SecondActivity t134}
    Run #2: ActivityRecord{b049afa u0 com.example.sven.activitydemo/.MainActivity t134}

TaskRecord{fec37c7 #134 A=com.example.sven.activitydemo U=0 sz=2}
   Run #3: ActivityRecord{4fdc1db u0 com.example.sven.activitydemo/.SecondActivity t134}
    Run #2: ActivityRecord{b049afa u0 com.example.sven.activitydemo/.MainActivity t134}

可以看到,如果被啟動的SecondActivity的啟動模式是standard,那么B會重新創建新的實例并且之前的實例及實例之上的Activity都會出棧

(2) B的launchmode是singleTask

TaskRecord{249ecaa #135 A=com.example.sven.activitydemo U=0 sz=4}
    Run #5: ActivityRecord{1116cb u0 com.example.sven.activitydemo/.MainActivity t135}
    Run #4: ActivityRecord{92b068e u0 com.example.sven.activitydemo/.ThirdActivity t135}
    Run #3: ActivityRecord{96bd6b6 u0 com.example.sven.activitydemo/.SecondActivity t135}
    Run #2: ActivityRecord{44bf730 u0 com.example.sven.activitydemo/.MainActivity t135}

TaskRecord{249ecaa #135 A=com.example.sven.activitydemo U=0 sz=2}
    Run #3: ActivityRecord{96bd6b6 u0 com.example.sven.activitydemo/.SecondActivity t135}
    Run #2: ActivityRecord{44bf730 u0 com.example.sven.activitydemo/.MainActivity t135}

可以看到,如果被啟動的SecondActivity的啟動模式是SingleTask,那么B會清除實例之上的Activity,并且調用onNewIntent方法

總結:主要2個點,清除被啟動Activity之上的實例,是否創建新的實例和被啟動Activity的lanuchMode有關

4. Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS

具有這個標記的Activity不會出現在歷史Activity的記錄中,和android:excludeFromRecents作用相同

tips:啟動模式有2種設置方法,通過設置Intent的FLAG 和 AndroidManifest.xml ,第一種方式的優先級大于第二種方式

三、IntentFilter的匹配規則

Activity的顯示調用和隱式調用:http://blog.csdn.net/xiao__gui/article/details/11392987

一個activity可以有多個過濾器,每個過濾器均可以有多個action,category和data

1.action的匹配規則

Intent 中的 action 只要有一個與過濾器(manifest中的intent-filter)的匹配,就可調用這個過濾器所在的組件。

2.category的匹配規則

category 表示類別,最常見就是這2個

<category android:name="android.intent.category.LAUNCHER" />
 <category android:name="android.intent.category.DEFAULT" />

1. 隱式啟動時intent會自動的添加一個默認的category,所以隱式啟動時,過濾器中的默認的category必須要加

 <category android:name="android.intent.category.DEFAULT"/>

2. 隱式啟動時,intent中添加的category必須包含在過濾器中

3.data的匹配規則

data 表示該組件可以支持的數據格式與類型,intent 至少可以匹配過濾器中的一個

主要由兩部分組成:1.mimeType 2.URI ,語法如下:

<data android:scheme="string"
    android:host="string"
    android:port="string"
    android:path="string"
    android:pathPattern="string"
    android:pathPrefix="string"
    android:mimeType="string" />

(1) mimeType 指的是支持的數據類型與格式
常見的有:1.text/plain 2.image/jpeg 3.video/* 4.audio/*
/ 號前面的是數據類型,后面是具體格式。

(2) URI 格式:

<scheme>://<host>:<port>/[<path>]|[<pathPrefix>]|[pathPattern]

1.scheme、host、port、path分別表示URI的模式、主機名和端口號和路徑

例如:http://www.baidu.com:80/search/info

2.如果scheme或者host未指定那么URI就無效

3.URI 是有默認值的,content 和 file,這里不是很理解,不過發現這樣一種情況:

在intent-filter 中添加任意一種mimeType,不指定URI

<data android:mimeType="image/jpeg"/>

intent啟動時,設置URI為 content:.* 或 file:.* 均可啟動

intent.setDataAndType(Uri.parse("content://abc"), "image/jpeg");

4.data 是有如下2種寫法的,效果是一樣的

<data android:scheme="file"
      android:host="abc"
      android:mimeType="text/plain"/>

<data android:scheme="file"/>
<data android:host="abc"/>
<data android:mimeType="text/plain"/>

如果一個intent-filter 中有多個data 并且他們的URI均不同,建議用第一種。

data 的匹配規則這里只列舉的常用的一部分,還有些情況類似與如下,也可以匹配到,可以將URI 和MIMETYPE的關理解為action和category的關系

<data android:scheme="http" android:host="abc" android:mimeType="text/plain"/>
<data android:scheme="http" android:host="abc2" android:mimeType="image/png"/>

intent.setDataAndType(Uri.parse("http://abc"), "image/png");

只能理解為 URI 和MIMETYPE 其實類似于 action 和 category的關系,采用如下的寫法更能表現兩者的關系,具體大家在實踐中多多理解

  <data android:scheme="file" android:host="abc" />
  <data android:scheme="file" android:host="abc2" />
  <data android:mimeType="text/plain" />
  <data android:mimeType="image/png" />

tips:

1.如果要為Intent指定完整的data,必須要調用setDataAndType方法,不能先調用setData然后調用setType,因為這兩個方法會彼此清除對方的值。
2.當我們啟動Activity可以通過resolveActivity判斷是否有對應的Activity

if(this.getPackageManager().resolveActivity(intent, 0) != null){
    startActivity(intent);
}

3.特殊的一組action和category,標記應用啟動時打開的Activity,少了任何一個都沒有意義

<intent-filter>
    <action android:name="android.intent.action.MAIN" />
    <category android:name="android.intent.category.LAUNCHER" />
</intent-filter>

4.顯示Component調用也是可以跨應用的,需要顯示指定Activity屬性 android:exported="true" 或者添加一個intent-Filter,否則會報AndroidRuntime異常,通過Tip 3是不能檢查出intent是否正常。

以上這些自己寫了個Demo,方便大家調試和學習:
http://download.csdn.net/detail/time_traveller14/9880456
http://download.csdn.net/detail/time_traveller14/9880457

問題:

  1. onSaveInstanceState 為何會在跳轉到別的Activity、Home鍵以及鎖屏時調用?
  2. category 和 data 的更多用法?

參考資料:
https://developer.android.com/reference/android/app/Activity.html
https://developer.android.com/guide/topics/manifest/activity-element.html?hl=zh-cn#config
http://blog.csdn.net/u011240877/article/details/71305797
《Android 開發藝術之旅》

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,702評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,143評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 175,553評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,620評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,416評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,940評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,024評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,170評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,709評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,597評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,784評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,291評論 5 357
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,029評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,407評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,663評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,403評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,746評論 2 370

推薦閱讀更多精彩內容