Android 手機(jī)上的應(yīng)用一般情況下都在一個(gè)進(jìn)程中運(yùn)行。
但是,也可以指定Activity或者Service在Remote 進(jìn)程中執(zhí)行。多數(shù)情況下,只有在用戶認(rèn)為應(yīng)用退出后還需要繼續(xù)后臺(tái)長(zhǎng)期運(yùn)行的應(yīng)用,才需要這樣做。此時(shí),該應(yīng)用有兩個(gè)進(jìn)程。
還有一種hack的方式,在apk中通過調(diào)用命令行來啟動(dòng)另外的進(jìn)程。此種方式用戶不可見,也不安全。不提倡。
官網(wǎng)幫助文檔鏈接:
http://developer.android.com/guide/components/fragments.html
主要看兩張圖,和跑代碼
一,F(xiàn)ragment的生命周
二,與Activity生命周期的對(duì)比
場(chǎng)景演示 : 切換到該Fragment
11-29 14:26:35.095: D/AppListFragment(7649): onAttach
11-29 14:26:35.095: D/AppListFragment(7649): onCreate
11-29 14:26:35.095: D/AppListFragment(7649): onCreateView
11-29 14:26:35.100: D/AppListFragment(7649): onActivityCreated
11-29 14:26:35.120: D/AppListFragment(7649): onStart
11-29 14:26:35.120: D/AppListFragment(7649): onResume
屏幕滅掉:
11-29 14:27:35.185: D/AppListFragment(7649): onPause
11-29 14:27:35.205: D/AppListFragment(7649): onSaveInstanceState
11-29 14:27:35.205: D/AppListFragment(7649): onStop
屏幕解鎖
11-29 14:33:13.240: D/AppListFragment(7649): onStart
11-29 14:33:13.275: D/AppListFragment(7649): onResume
切換到其他Fragment:
11-29 14:33:33.655: D/AppListFragment(7649): onPause
11-29 14:33:33.655: D/AppListFragment(7649): onStop
11-29 14:33:33.660: D/AppListFragment(7649): onDestroyView
切換回本身的Fragment:
11-29 14:33:55.820: D/AppListFragment(7649): onCreateView
11-29 14:33:55.825: D/AppListFragment(7649): onActivityCreated
11-29 14:33:55.825: D/AppListFragment(7649): onStart
11-29 14:33:55.825: D/AppListFragment(7649): onResume
回到桌面
11-29 14:34:26.590: D/AppListFragment(7649): onPause
11-29 14:34:26.880: D/AppListFragment(7649): onSaveInstanceState
11-29 14:34:26.880: D/AppListFragment(7649): onStop
回到應(yīng)用
11-29 14:36:51.940: D/AppListFragment(7649): onStart
11-29 14:36:51.940: D/AppListFragment(7649): onResume
退出應(yīng)用
11-29 14:37:03.020: D/AppListFragment(7649): onPause
11-29 14:37:03.155: D/AppListFragment(7649): onStop
11-29 14:37:03.155: D/AppListFragment(7649): onDestroyView
11-29 14:37:03.165: D/AppListFragment(7649): onDestroy
11-29 14:37:03.165: D/AppListFragment(7649): onDetach
比Activity多了一些生命周期,完整和Activity對(duì)接上,大家好好利用。
轉(zhuǎn)載:http://blog.csdn.net/forever_crying/article/details/8238863/
ANR定義:在Android上,如果你的應(yīng)用程序有一段時(shí)間響應(yīng)不夠靈敏,系統(tǒng)會(huì)向用戶顯示一個(gè)對(duì)話框,這個(gè)對(duì)話框稱作應(yīng)用程序無響應(yīng)對(duì)話框(ANR:Application Not Responding),用戶可以選擇“等待”讓應(yīng)用程序繼續(xù)運(yùn)行,也可以選擇“強(qiáng)制關(guān)閉”。所以一個(gè)順暢合理的應(yīng)用程序不會(huì)出現(xiàn)ANR,而讓用戶處理這個(gè)對(duì)話框。因此,在程序里對(duì)響應(yīng)性能的設(shè)計(jì)很重要,這樣系統(tǒng)不會(huì)顯示ANR給用戶。
默認(rèn)情況下,Android的Activity執(zhí)行時(shí)間為5s,BroadcastReceiver的最長(zhǎng)執(zhí)行時(shí)間為10s.
第一,什么會(huì)引發(fā)ANR
在Android里,應(yīng)用程序響應(yīng)由Activity Manager和WindowManager系統(tǒng)服務(wù)監(jiān)視的,當(dāng)它監(jiān)聽到一下一種情況時(shí),Android就會(huì)針對(duì)特定的應(yīng)用程序顯示ANR:
1).在5秒內(nèi)沒有響應(yīng)輸入事件(例如,按鍵按下,屏幕觸摸)
2).BroadcastReceiver在10秒內(nèi)沒有執(zhí)行完畢
造成以上兩點(diǎn)多原因有很多,比如在主線程中做非常耗時(shí)的操作,比如下載,IO異常等。
潛在的耗時(shí)操作,例如網(wǎng)絡(luò)或數(shù)據(jù)庫操作或者高耗時(shí)的計(jì)算如改變位圖尺寸,這些操作應(yīng)該放在子線程中(或者以數(shù)據(jù)庫為例,通過異步請(qǐng)求的方式)來完成,然而,不是說你的主線程阻塞在那里等待子線程來完成--也不用調(diào)用Thread.wait()或Thread.sleep();替代的方法是主線程需要為子線程提供一個(gè)handler,以便完成時(shí)能夠交給主線程,以這種方式設(shè)計(jì)你的應(yīng)用程序,將能保證你的主線程保持對(duì)輸入的響應(yīng)性并能避免由于5秒輸入事件的超時(shí)引發(fā)的ANR對(duì)話框。
第二,如何避免ANR
1.運(yùn)行在主線程里的任何方法都盡可能少做事情。特別是,Activity應(yīng)該在它的關(guān)鍵生命周期方法(如onCreate()和onResume())里盡可能少的去做創(chuàng)建操作。(可以采用重新開啟子線程的方式,然后使用Handler+Message的方式做一些操作,比如更新主線程中的ui等)
2.應(yīng)用程序應(yīng)該避免在BroadcastReceiver里做耗時(shí)的操作或計(jì)算。但不再是在子線程里做這些任務(wù)(因?yàn)?BroadcastReceiver的生命周期短),替代的是,如果響應(yīng)Intent廣播需要執(zhí)行一個(gè)耗時(shí)的動(dòng)作的話,應(yīng)用程序應(yīng)該啟動(dòng)一個(gè) Service。(此處需要注意的是可以在廣播接受者中啟動(dòng)Service,但是卻不可以在Service中啟動(dòng)broadcasereciver,關(guān)于原因后續(xù)會(huì)有介紹,此處不是本文重點(diǎn))
3.避免在Intent Receiver里啟動(dòng)一個(gè)Activity,因?yàn)樗鼤?huì)創(chuàng)建一個(gè)新的畫面,并從當(dāng)前用戶正在運(yùn)行的程序上搶奪焦點(diǎn)。如果你的應(yīng)用程序在響應(yīng)Intent廣 播時(shí)需要向用戶展示什么,你應(yīng)該使用Notification Manager來實(shí)現(xiàn)。
總結(jié):anr異常也是在程序中自己經(jīng)常遇到的問題,主要的解決辦法自己最常用的就是不要在主線程中做耗時(shí)的操作,而應(yīng)放在子線程中來實(shí)現(xiàn),比如采用Handler+mesage的方式,或者是有時(shí)候需要做一些和網(wǎng)絡(luò)相互交互的耗時(shí)操作就采用asyntask異步任務(wù)的方式(它的底層其實(shí)Handler+mesage有所區(qū)別的是它是線程池)等,在主線程中更新UI。
java.version
Java 運(yùn)行時(shí)環(huán)境版本
java.vendor
Java 運(yùn)行時(shí)環(huán)境供應(yīng)商
java.vendor.url
Java 供應(yīng)商的 URL
java.home
Java 安裝目錄
java.vm.specification.version
Java 虛擬機(jī)規(guī)范版本
java.vm.specification.vendor
Java 虛擬機(jī)規(guī)范供應(yīng)商
java.vm.specification.name
Java 虛擬機(jī)規(guī)范名稱
java.vm.version
Java 虛擬機(jī)實(shí)現(xiàn)版本
java.vm.vendor
Java 虛擬機(jī)實(shí)現(xiàn)供應(yīng)商
java.vm.name
Java 虛擬機(jī)實(shí)現(xiàn)名稱
java.specification.version
Java 運(yùn)行時(shí)環(huán)境規(guī)范版本
java.specification.vendor
Java 運(yùn)行時(shí)環(huán)境規(guī)范供應(yīng)商
java.specification.name
Java 運(yùn)行時(shí)環(huán)境規(guī)范名稱
java.class.version
Java 類格式版本號(hào)
java.class.path
Java 類路徑
java.library.path
加載庫時(shí)搜索的路徑列表
java.io.tmpdir
默認(rèn)的臨時(shí)文件路徑
java.compiler
要使用的 JIT 編譯器的名稱
java.ext.dirs
一個(gè)或多個(gè)擴(kuò)展目錄的路徑
os.name
操作系統(tǒng)的名稱
os.arch
操作系統(tǒng)的架構(gòu)
os.version
操作系統(tǒng)的版本
file.separator
文件分隔符(在 UNIX 系統(tǒng)中是“/”)
path.separator
路徑分隔符(在 UNIX 系統(tǒng)中是“:”)
line.separator
行分隔符(在 UNIX 系統(tǒng)中是“/n”)
user.name
用戶的賬戶名稱
user.home
用戶的主目錄
user.dir
用戶的當(dāng)前工作目錄
while ((line = reader.readLine()) != null) {
response.append(line).append(
System.getProperty("line.separator"));
}
public class SystemProperty {
public static void main(String args[]) {
System.out.println("java_vendor:" + System.getProperty("java.vendor"));
System.out.println("java_vendor_url:"
+ System.getProperty("java.vendor.url"));
System.out.println("java_home:" + System.getProperty("java.home"));
System.out.println("java_class_version:"
+ System.getProperty("java.class.version"));
System.out.println("java_class_path:"
+ System.getProperty("java.class.path"));
System.out.println("os_name:" + System.getProperty("os.name"));
System.out.println("os_arch:" + System.getProperty("os.arch"));
System.out.println("os_version:" + System.getProperty("os.version"));
System.out.println("user_name:" + System.getProperty("user.name"));
System.out.println("user_home:" + System.getProperty("user.home"));
System.out.println("user_dir:" + System.getProperty("user.dir"));
System.out.println("java_vm_specification_version:"
+ System.getProperty("java.vm.specification.version"));
System.out.println("java_vm_specification_vendor:"
+ System.getProperty("java.vm.specification.vendor"));
System.out.println("java_vm_specification_name:"
+ System.getProperty("java.vm.specification.name"));
System.out.println("java_vm_version:"
+ System.getProperty("java.vm.version"));
System.out.println("java_vm_vendor:"
+ System.getProperty("java.vm.vendor"));
System.out
.println("java_vm_name:" + System.getProperty("java.vm.name"));
System.out.println("java_ext_dirs:"
+ System.getProperty("java.ext.dirs"));
System.out.println("file_separator:"
+ System.getProperty("file.separator"));
System.out.println("path_separator:"
+ System.getProperty("path.separator"));
System.out.println("line_separator:"
+ System.getProperty("line.separator"));
}
轉(zhuǎn)載:http://blog.csdn.net/kongqz/article/details/3987198 當(dāng)某個(gè)activity變得“容易”被系統(tǒng)銷毀時(shí),該activity的onSaveInstanceState就會(huì)被執(zhí)行,除非該activity是被用戶主動(dòng)銷毀的,例如當(dāng)用戶按BACK鍵的時(shí)候。
注意上面的雙引號(hào),何為“容易”?言下之意就是該activity還沒有被銷毀,而僅僅是一種可能性。這種可能性有哪些?通過重寫一個(gè)activity的所有生命周期的onXXX方法,包括onSaveInstanceState和onRestoreInstanceState方法,我們可以清楚地知道當(dāng)某個(gè)activity(假定為activity A)顯示在當(dāng)前task的最上層時(shí),其onSaveInstanceState方法會(huì)在什么時(shí)候被執(zhí)行,有這么幾種情況:
1、當(dāng)用戶按下HOME鍵時(shí)。
這是顯而易見的,系統(tǒng)不知道你按下HOME后要運(yùn)行多少其他的程序,自然也不知道activity A是否會(huì)被銷毀,故系統(tǒng)會(huì)調(diào)用onSaveInstanceState,讓用戶有機(jī)會(huì)保存某些非永久性的數(shù)據(jù)。以下幾種情況的分析都遵循該原則
2、長(zhǎng)按HOME鍵,選擇運(yùn)行其他的程序時(shí)。
3、按下電源按鍵(關(guān)閉屏幕顯示)時(shí)。
4、從activity A中啟動(dòng)一個(gè)新的activity時(shí)。
5、屏幕方向切換時(shí),例如從豎屏切換到橫屏?xí)r。
在屏幕切換之前,系統(tǒng)會(huì)銷毀activity A,在屏幕切換之后系統(tǒng)又會(huì)自動(dòng)地創(chuàng)建activity A,所以onSaveInstanceState一定會(huì)被執(zhí)行。
總而言之,onSaveInstanceState的調(diào)用遵循一個(gè)重要原則,即當(dāng)系統(tǒng)“未經(jīng)你許可”時(shí)銷毀了你的activity,則onSaveInstanceState會(huì)被系統(tǒng)調(diào)用,這是系統(tǒng)的責(zé)任,因?yàn)樗仨氁峁┮粋€(gè)機(jī)會(huì)讓你保存你的數(shù)據(jù)(當(dāng)然你不保存那就隨便你了)。
至于onRestoreInstanceState方法,需要注意的是,onSaveInstanceState方法和onRestoreInstanceState方法“不一定”是成對(duì)的被調(diào)用的,onRestoreInstanceState被調(diào)用的前提是,activity A“確實(shí)”被系統(tǒng)銷毀了,而如果僅僅是停留在有這種可能性的情況下,則該方法不會(huì)被調(diào)用,例如,當(dāng)正在顯示activity A的時(shí)候,用戶按下HOME鍵回到主界面,然后用戶緊接著又返回到activity A,這種情況下activity A一般不會(huì)因?yàn)閮?nèi)存的原因被系統(tǒng)銷毀,故activity A的onRestoreInstanceState方法不會(huì)被執(zhí)行。
另外,onRestoreInstanceState的bundle參數(shù)也會(huì)傳遞到onCreate方法中,你也可以選擇在onCreate方法中做數(shù)據(jù)還原。
轉(zhuǎn)載:http://gundumw100.iteye.com/blog/1115080
| |||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
---|---|---|---|---|---|---|---|---|---|
29 | 30 | 1 | 2 | 3 | 4 | 5 | |||
6 | 7 | 8 | 9 | 10 | 11 | 12 | |||
13 | 14 | 15 | 16 | 17 | 18 | 19 | |||
20 | 21 | 22 | 23 | 24 | 25 | 26 | |||
27 | 28 | 29 | 30 | 31 | 1 | 2 | |||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
常用鏈接
留言簿(2)
隨筆分類
- Android(49)
- Androidpn(2)
- hibernate(1)
- Https(1)
- JavaCard(3)
- jQuery(6)
- netty
- NFC(1)
- react框架(1)
- spring(2)
- SpringBoot(1)
- Tomcat+Eclipse(18)
- WebService(2)
- 一些心得(1)
隨筆檔案
- 2020年4月 (4)
- 2015年7月 (5)
- 2015年6月 (6)
- 2015年5月 (4)
- 2015年4月 (3)
- 2015年3月 (1)
- 2015年2月 (1)
- 2015年1月 (4)
- 2014年12月 (1)
- 2014年11月 (2)
- 2014年10月 (2)
- 2014年9月 (2)
- 2014年5月 (5)
- 2014年3月 (3)
- 2014年2月 (2)
- 2014年1月 (8)
- 2013年12月 (2)
- 2013年7月 (2)
- 2013年6月 (4)
- 2013年5月 (16)
- 2012年7月 (1)
- 2012年3月 (2)
- 2011年7月 (6)
文章分類
文章檔案
相冊(cè)
收藏夾
Java
搜索
最新隨筆
最新評(píng)論

- 1.?re: Android JSON的簡(jiǎn)單例子
- 評(píng)論內(nèi)容較長(zhǎng),點(diǎn)擊標(biāo)題查看
- --JSON.COM
- 2.?re: androidpn(本文服務(wù)器為tomcat)
- 評(píng)論內(nèi)容較長(zhǎng),點(diǎn)擊標(biāo)題查看
- --Deepak Singh