|
|
2011年1月10日
Activity啟動(dòng)方式有四種，分別是：
standard
singleTop
singleTask
singleInstance
可以根據(jù)實(shí)際的需求為Activity設(shè)置對(duì)應(yīng)的啟動(dòng)模式，從而可以避免創(chuàng)建大量重復(fù)的Activity等問題。
設(shè)置Activity的啟動(dòng)模式，只需要在AndroidManifest.xml里對(duì)應(yīng)的<activity>標(biāo)簽設(shè)置android:launchMode屬性，例如：
- <activity
- android:name=".A1"
- android:launchMode="standard" />
默認(rèn)模式，可以不用寫配置。在這個(gè)模式下，都會(huì)默認(rèn)創(chuàng)建一個(gè)新的實(shí)例。因此，在這種模式下，可以有多個(gè)相同的實(shí)例，也允許多個(gè)相同Activity疊加。例如：若我有一個(gè)Activity名為A1, 上面有一個(gè)按鈕可跳轉(zhuǎn)到A1。那么如果我點(diǎn)擊按鈕，便會(huì)新啟一個(gè)Activity A1疊在剛才的A1之上，再點(diǎn)擊，又會(huì)再新啟一個(gè)在它之上……點(diǎn)back鍵會(huì)依照棧順序依次退出。singleTop可以有多個(gè)實(shí)例，但是不允許多個(gè)相同Activity疊加。即，如果Activity在棧頂?shù)臅r(shí)候，啟動(dòng)相同的Activity，不會(huì)創(chuàng)建新的實(shí)例，而會(huì)調(diào)用其onNewIntent方法。例如：若我有兩個(gè)Activity名為B1,B2,兩個(gè)Activity內(nèi)容功能完全相同，都有兩個(gè)按鈕可以跳到B1或者B2，唯一不同的是B1為standard，B2為singleTop。若我意圖打開的順序?yàn)锽1->B2->B2，則實(shí)際打開的順序?yàn)锽1->B2（后一次意圖打開B2，實(shí)際只調(diào)用了前一個(gè)的onNewIntent方法）若我意圖打開的順序?yàn)锽1->B2->B1->B2，則實(shí)際打開的順序與意圖的一致，為B1->B2->B1->B2。singleTask只有一個(gè)實(shí)例。在同一個(gè)應(yīng)用程序中啟動(dòng)他的時(shí)候，若Activity不存在，則會(huì)在當(dāng)前task創(chuàng)建一個(gè)新的實(shí)例，若存在，則會(huì)把task中在其之上的其它Activity destory掉并調(diào)用它的onNewIntent方法。如果是在別的應(yīng)用程序中啟動(dòng)它，則會(huì)新建一個(gè)task，并在該task中啟動(dòng)這個(gè)Activity，singleTask允許別的Activity與其在一個(gè)task中共存，也就是說，如果我在這個(gè)singleTask的實(shí)例中再打開新的Activity，這個(gè)新的Activity還是會(huì)在singleTask的實(shí)例的task中。例如：若我的應(yīng)用程序中有三個(gè)Activity,C1,C2,C3，三個(gè)Activity可互相啟動(dòng)，其中C2為singleTask模式，那么，無論我在這個(gè)程序中如何點(diǎn)擊啟動(dòng)，如：C1->C2->C3->C2->C3->C1-C2，C1,C3可能存在多個(gè)實(shí)例，但是C2只會(huì)存在一個(gè)，并且這三個(gè)Activity都在同一個(gè)task里面。但是C1->C2->C3->C2->C3->C1-C2，這樣的操作過程實(shí)際應(yīng)該是如下這樣的，因?yàn)閟ingleTask會(huì)把task中在其之上的其它Activity destory掉。操作：C1->C2 C1->C2->C3 C1->C2->C3->C2 C1->C2->C3->C2->C3->C1 C1->C2->C3->C2->C3->C1-C2實(shí)際：C1->C2 C1->C2->C3 C1->C2 C1->C2->C3->C1 C1->C2若是別的應(yīng)用程序打開C2，則會(huì)新啟一個(gè)task。如別的應(yīng)用Other中有一個(gè)activity，taskId為200，從它打開C2，則C2的taskIdI不會(huì)為200，例如C2的taskId為201，那么再從C2打開C1、C3，則C2、C3的taskId仍為201。注意：如果此時(shí)你點(diǎn)擊home，然后再打開Other，發(fā)現(xiàn)這時(shí)顯示的肯定會(huì)是Other應(yīng)用中的內(nèi)容，而不會(huì)是我們應(yīng)用中的C1 C2 C3中的其中一個(gè)。singleInstance只有一個(gè)實(shí)例，并且這個(gè)實(shí)例獨(dú)立運(yùn)行在一個(gè)task中，這個(gè)task只有這個(gè)實(shí)例，不允許有別的Activity存在。例如：程序有三個(gè)ActivityD1,D2,D3，三個(gè)Activity可互相啟動(dòng)，其中D2為singleInstance模式。那么程序從D1開始運(yùn)行，假設(shè)D1的taskId為200，那么從D1啟動(dòng)D2時(shí)，D2會(huì)新啟動(dòng)一個(gè)task，即D2與D1不在一個(gè)task中運(yùn)行。假設(shè)D2的taskId為201，再從D2啟動(dòng)D3時(shí)，D3的taskId為200，也就是說它被壓到了D1啟動(dòng)的任務(wù)棧中。若是在別的應(yīng)用程序打開D2，假設(shè)Other的taskId為200，打開D2，D2會(huì)新建一個(gè)task運(yùn)行，假設(shè)它的taskId為201，那么如果這時(shí)再從D2啟動(dòng)D1或者D3，則又會(huì)再創(chuàng)建一個(gè)task，因此，若操作步驟為other->D2->D1，這過程就涉及到了3個(gè)task了。
系統(tǒng)4.0.3以后的
File file=new File(""); Uri uri1 = Uri.fromFile(file); Intent intent = new Intent(); intent.setAction(Intent.ACTION_SEND); //intent.setType("audio/*"); intent.setType("application/octet-stream"); ComponentName comp=new ComponentName("com.mediatek.bluetooth","com.mediatek.bluetooth.BluetoothShareGatewayActivity"); intent.setComponent(comp); intent.putExtra(Intent.EXTRA_STREAM, uri1); startActivity(intent); 系統(tǒng)4.0.3以前的 Intent intent = new Intent(); intent.setAction(Intent.ACTION_SEND); //這個(gè)類型函數(shù)是自己工具類的方法，你可以自己設(shè)置文件類型，例如圖片文件：image/* //不想寫類型直接*/*也是可以的 intent.setType("audio/*"); //這里setClassName就是指定藍(lán)牙，不寫這句就彈出選擇用什么發(fā)送 //有藍(lán)牙啊，gmail啊，彩信之類的 intent.setClassName("com.android.bluetooth" , "com.android.bluetooth.opp.BluetoothOppLauncherActivity"); intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File(""))); startActivity(intent); ArrayList<Uri> uris = new ArrayList<Uri>(); uris.add(Uri.fromFile(new File("/sdcard/111.txt"))); uris.add(Uri.fromFile(new File("/sdcard/222.txt"))); Intent intent = new Intent(); intent.setAction(Intent.ACTION_SEND_MULTIPLE); intent.setType("video/*"); intent.setClassName("com.android.bluetooth" , "com.android.bluetooth.opp.BluetoothOppLauncherActivity"); //intent.setClassName("com.mediatek.bluetooth","com.mediatek.bluetooth.BluetoothShareGatewayActivity"); //intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File("/sdcard/111.txt")) ); //intent.putExtra(Intent.EXTRA_STREAM, Uri.fromFile(new File("/sdcard/222.txt"))); intent.putExtra(Intent.EXTRA_STREAM, uris); startActivity(intent);
我們?cè)陧撁娌季值臅r(shí)候，經(jīng)常會(huì)設(shè)置容器的長度，但是到底該使用哪個(gè)作為長度的單位而懊惱。在Android中支持的描述大小區(qū)域的類型有以下幾種: px(pixels)——像素：不同的設(shè)備顯示效果相同，一般我們HVGA代表320x480像素，這個(gè)用的比較多。 dip(device independent pixels)——設(shè)備獨(dú)立像素：這個(gè)和設(shè)備硬件有關(guān)，一般我們?yōu)榱酥С諻CGA、HVGA和QVGA推薦使用這個(gè)，不依賴于像素。等同于dp。 sp(scaled pixels—best for text size)——帶比例的像素。 pt(points)——磅：1pt = 1/72英寸 in(inches)——英寸 mm(millimeters)——毫米 到底px和dip有什么區(qū)別呢？ dip != px 主要是針對(duì)不同設(shè)備而言的。在Density是160的設(shè)備上，比如用AVDManager創(chuàng)建的默認(rèn)模擬器，dip和px是一樣的但是如果同樣的代碼，換到不同Density的設(shè)備上，比如換到一個(gè)Density是240的設(shè)備上，dip和px體現(xiàn)出來的大小就不一樣了。px不管在什么樣的設(shè)備上都是那樣長，但是dip會(huì)根據(jù)設(shè)備變化；WQVGA屏density=120；QVGA屏density=120；HVGA屏density=160；WVGA屏density=240；density值表示每英寸有多少個(gè)顯示點(diǎn)，與分辨率是兩個(gè)概念。
當(dāng)屏幕density=240時(shí)使用hdpi標(biāo)簽的資源
當(dāng)屏幕density=160時(shí)，使用mdpi標(biāo)簽的資源
當(dāng)屏幕density=120時(shí)，使用ldpi標(biāo)簽的資源。
不加任何標(biāo)簽的資源是各種分辨率情況下共用的。布局時(shí)盡量使用單位dip，少使用px。
換算公式為：
pixs =dips * (densityDpi/160). dips=(pixs*160)/densityDpi 如何獲得設(shè)備的屏幕分辨率和屏幕密度？
例如分辨率為480*800，密度為240的設(shè)備，方法如下DisplayMetrics dm =getResources().getDisplayMetrics(); dm.densityDpi=240 dm.widthPixels=480 dm.heightPixels=800
首先啟動(dòng)android模擬器。
打開cmd命令行窗口。輸入adb -s emulator-5554 shell
此時(shí)可以管理系統(tǒng)文件夾了，再輸入ls
可以看到列出了文件夾和文件，輸入cd system/app再輸入ls
可以看到系統(tǒng)自帶的應(yīng)用程序apk文件，刪除你想要?jiǎng)h除的，例如Phone.apk，輸入rm Phone.apk
此時(shí)會(huì)看到提示說rm failed for Phone.apk, Read-only file system那是因?yàn)檫@些是只讀文件，我們沒有權(quán)限刪除它。所以接下來要做的是獲取權(quán)限，首先查看權(quán)限，輸入mount
可以看到/dev/block/mtdblock0 /system yaffs2 ro 0 0說明在system這個(gè)地方我們沒有權(quán)限那么接下來我們就來獲取權(quán)限，輸入mount -o remount,rw -t yaffs2 /dev/block/mtdblock0 /system
沒有提示錯(cuò)誤，再次查看權(quán)限，輸入mount
可以看到/dev/block/mtdblock0 /system yaffs2 rw 0 0
說明我們已經(jīng)獲取到權(quán)限了此時(shí)再輸入rm Phone.apk就可以成功刪除了
最后一點(diǎn)，就算你成功刪除了，android模擬器每次啟動(dòng)時(shí)也會(huì)恢復(fù)回來。
那么如何永久刪除呢，很簡單，刪除SdkSetup.apk，輸入rm SdkSetup.apk
還沒完，找到avd目錄(一般在我的文檔)，進(jìn)入xxxx.avd目錄，刪除cache.img和userdata-qemu.img
還有還有，找到%SDK_HOME%/platforms/android-X/images/system.img，復(fù)制到上面的目錄中。
最后最后，再重啟模擬器，大功告成！
如果你的游戲不吃CPU，用View就比較好，符合標(biāo)準(zhǔn)Android操作方式，由系統(tǒng)決定刷新surface的時(shí)機(jī)。 但如果很不幸的，你做不到不讓你的程序吃CPU，你就只好使用SurfaceView來強(qiáng)制刷新surface了，不然系統(tǒng)的UI進(jìn)程很可能搶不過你那些吃CPU的線程。 當(dāng)然其實(shí)不止這兩種方法來刷新Surface的，這兩種只是純Java應(yīng)用比較常見的方法。 SurfaceView和View最本質(zhì)的區(qū)別在于，surfaceView是在一個(gè)新起的單獨(dú)線程中可以重新繪制畫面而View必須在UI的主線程中更新畫面。 那么在UI的主線程中更新畫面 可能會(huì)引發(fā)問題，比如你更新畫面的時(shí)間過長，那么你的主UI線程會(huì)被你正在畫的函數(shù)阻塞。那么將無法響應(yīng)按鍵，觸屏等消息。 當(dāng)使用surfaceView 由于是在新的線程中更新畫面所以不會(huì)阻塞你的UI主線程。但這也帶來了另外一個(gè)問題，就是事件同步。比如你觸屏了一下，你需要surfaceView中 thread處理，一般就需要有一個(gè)event queue的設(shè)計(jì)來保存touch event，這會(huì)稍稍復(fù)雜一點(diǎn)，因?yàn)樯婕暗骄€程同步。 所以基于以上，根據(jù)游戲特點(diǎn)，一般分成兩類。 1 被動(dòng)更新畫面的。比如棋類，這種用view就好了。因?yàn)楫嬅娴母率且蕾囉?onTouch 來更新，可以直接使用 invalidate。 因?yàn)檫@種情況下，這一次Touch和下一次的Touch需要的時(shí)間比較長些，不會(huì)產(chǎn)生影響。 2 主動(dòng)更新。比如一個(gè)人在一直跑動(dòng)。這就需要一個(gè)單獨(dú)的thread不停的重繪人的狀態(tài)，避免阻塞main UI thread。所以顯然view不合適，需要surfaceView來控制。
android多國語言文件夾文件匯總?cè)缦拢?/p> 中文（中國）：values-zh-rCN 中文（臺(tái)灣）：values-zh-rTW 中文（香港）：values-zh-rHK 英語（美國）：values-en-rUS 英語（英國）：values-en-rGB 英文（澳大利亞）：values-en-rAU 英文（加拿大）：values-en-rCA 英文（愛爾蘭）：values-en-rIE 英文（印度）：values-en-rIN 英文（新西蘭）：values-en-rNZ 英文（新加坡）：values-en-rSG 英文（南非）：values-en-rZA 阿拉伯文（埃及）：values-ar-rEG 阿拉伯文（以色列）：values-ar-rIL 保加利亞文: values-bg-rBG 加泰羅尼亞文：values-ca-rES 捷克文：values-cs-rCZ 丹麥文：values-da-rDK 德文（奧地利）：values-de-rAT 德文（瑞士）：values-de-rCH 德文（德國）：values-de-rDE 德文（列支敦士登）：values-de-rLI 希臘文：values-el-rGR 西班牙文（西班牙）：values-es-rES 西班牙文（美國）：values-es-rUS 芬蘭文（芬蘭）：values-fi-rFI 法文（比利時(shí)）：values-fr-rBE 法文（加拿大）：values-fr-rCA 法文（瑞士）：values-fr-rCH 法文（法國）：values-fr-rFR 希伯來文：values-iw-rIL 印地文：values-hi-rIN 克羅里亞文：values-hr-rHR 匈牙利文：values-hu-rHU 印度尼西亞文：values-in-rID 意大利文（瑞士）：values-it-rCH 意大利文（意大利）：values-it-rIT 日文：values-ja-rJP 韓文：values-ko-rKR 立陶宛文：valueslt-rLT 拉脫維亞文：values-lv-rLV 挪威博克馬爾文：values-nb-rNO 荷蘭文(比利時(shí))：values-nl-BE 荷蘭文（荷蘭）：values-nl-rNL 波蘭文：values-pl-rPL 葡萄牙文（巴西）：values-pt-rBR 葡萄牙文（葡萄牙）：values-pt-rPT 羅馬尼亞文：values-ro-rRO 俄文：values-ru-rRU 斯洛伐克文：values-sk-rSK 斯洛文尼亞文：values-sl-rSI 塞爾維亞文：values-sr-rRS 瑞典文：values-sv-rSE 泰文：values-th-rTH 塔加洛語：values-tl-rPH 土耳其文：values--r-rTR 烏克蘭文：values-uk-rUA 越南文：values-vi-rVN
Intent.FLAG_ACTIVITY_REORDER_TO_FRONT的意思是，如果task中已經(jīng)有這個(gè)activity A，那么就把A拿到task的最頂層，而不是創(chuàng)建一個(gè)新的activity。
所以不加flag也不會(huì)影響界面的切過去，只是會(huì)影響task的順序而已。
Android:stackFromBottom="true" 設(shè)置該屬性之后你做好的列表就會(huì)顯示在列表的最下面，值為true和false android:transcriptMode="alwaysScroll" 要用ListView或者其它顯示大量Items的控件實(shí)時(shí)跟蹤或者查看信息，并且希望最新的條目可以自動(dòng)滾動(dòng)到可視范圍內(nèi)。通過設(shè)置的控件 transcriptMode屬性可以將Android平臺(tái)的控件（支持ScrollBar）自動(dòng)滑動(dòng)到最底部。 c acheColorHint屬性，很多人希望能夠改變一下它的背景，使他能夠符合整體的UI設(shè)計(jì)，改變背景背很簡單只需要準(zhǔn)備一張圖片然后指定屬性 android:background="@drawable/bg"，不過當(dāng)你這么做以后，發(fā)現(xiàn)背景是變了，但是當(dāng)你拖動(dòng)，或者點(diǎn)擊list空白位置的 時(shí)候發(fā)現(xiàn)ListItem都變成黑色的了，破壞了整體效果。 如果只是換背景的顏色的話，可以直接指定 android:cacheColorHint為你所要的顏色，如果你是用圖片做背景的話，那也只要將 android:cacheColorHint指定為透明（#00000000）就可以了 android:divider="@drawable/list_driver" 其中 @drawable/list_driver 是一個(gè)圖片資源，如果不想顯示分割線則只要設(shè)置為android:divider="@drawable/@null" 就可以了 android:scrollbars="none"與setVerticalScrollBarEnabled(true);的效果是一樣的，不活動(dòng)的 時(shí)候隱藏，活動(dòng)的時(shí)候也隱藏 android:fadeScrollbars="true" 配置ListView布局的時(shí)候，設(shè)置這個(gè)屬性為true就可以實(shí)現(xiàn)滾動(dòng)條的自動(dòng)隱藏和顯示。 fadingEdge屬性，上邊和下邊有黑色的陰影 android:fadingEdge="none" 設(shè)置后沒有陰影了 
<activity android:name=".usual.activity.Declaration" android:theme="@android:style/Theme.Translucent.NoTitleBar" />
1.背景自適應(yīng)且不失真問題的存在
制作自適應(yīng)背景圖片是UI開發(fā)的一個(gè)廣泛問題，也是界面設(shè)計(jì)師渴望解決的問題，我相信我們彼此都深有體會(huì)。
比如,列表的背景圖一定，但是列表的高度隨著列表數(shù)據(jù)項(xiàng)會(huì)發(fā)生變化；標(biāo)題欄的背景，無論橫屏還是豎屏，高分辨率還是低分辨率，都能自動(dòng)填充滿，而且不失真等等背景問題。
根據(jù)以往的經(jīng)驗(yàn)，我們一般采用先切圖后拼湊的做法，這種做法本來我想在這里和大家介紹一下，其實(shí)有的時(shí)候還是很有用的，但是說起來會(huì)比較麻煩，就不說這個(gè)非重點(diǎn)了，略去，如果大家真的要介紹，在回復(fù)中說明，我再考慮一下。
Android針對(duì)這種情況，專門制作了一種.9.PNG格式來解決這個(gè)問題。 2.9.PNG格式。
我不想在這里過多的討論P(yáng)NG格式的定義問題。但是.9.PNG確實(shí)是標(biāo)準(zhǔn)的PNG格式，只是在最外面一圈額外增加1px的邊框，這個(gè)1px的邊框就是 用來定義圖片中可擴(kuò)展的和靜態(tài)不變的區(qū)域。特別說明，left和top邊框中交叉部分是可拉伸部分，未選中部分是靜態(tài)區(qū)域部分。right和bottom 邊框中交叉部分則是內(nèi)容部分（變相的相當(dāng)于定義看一個(gè)內(nèi)邊距，神似padding功能，后面我會(huì)單獨(dú)介紹一下），這個(gè)參數(shù)是可選的, 如下圖。
 在Android中以9.PNG格式的圖片未背景，則能夠自定義拉伸而不失真，比如系統(tǒng)的Button就是一個(gè)典型的例子。
其實(shí)呢，無論是left和top，還是right和bottom都是把圖片分成9塊 (邊角四塊是不能縮放的，其他的四塊則是允許縮放的)，所以叫做9.PNG。 3. 使用Draw9Patch.jar制作9.PNG圖片之定義拉伸區(qū)域。
前面已經(jīng)了解到9.PNG格式的工作方式，下面我們使用谷歌提供的Draw9Patch(運(yùn)行android-sdk-windows\tools目錄下的Draw9Patch.bat)來制作.9.PNG圖片。
第一步：準(zhǔn)備要拉伸的圖片。
非常小的一張圖片，我希望以此為背景，中間部分填充文章內(nèi)容。
第二步：制作.9.PNG圖片。
打開Draw9Patch,把圖片拖進(jìn)去，如下：
默認(rèn)的拉伸是整體拉伸，其實(shí)邊框部分我們并不想拉伸，好，我們自己來定義拉伸區(qū)域，如下圖：
  然后點(diǎn)擊File,導(dǎo)出為content.9.png。
第三步：在layout文件中使用制作的 .9.PNG圖片.
新建工程Draw9Patch，默認(rèn)主Activity為Draw9PatchActivity.java: 2 | public void onCreate(Bundle savedInstanceState) |
4 | super.onCreate(savedInstanceState); |
5 | setContentView(R.layout.main); |
我們把content.9.png文件拷貝到/res/drawable文件夾下，打開/res/layout目錄下的main.xml，申明如下： 01 | <?xml version="1.0" encoding="utf-8"?> |
02 | <LinearLayout xmlns:android=" |
03 | android:orientation="vertical" |
04 | android:layout_width="fill_parent" |
05 | android:layout_height="fill_parent" |
06 | android:background="#777" |
07 | android:padding="8dip" |
10 | android:layout_width="fill_parent" |
11 | android:layout_height="wrap_content" |
12 | android:text="正文:A NinePatchDrawable graphic is a stretchable bitmap image." |
13 | android:background="@drawable/content" |
14 | android:textColor="#000" |
如圖，
我們修改text， 01 | <?xml version="1.0" encoding="utf-8"?> |
02 | <LinearLayout xmlns:android=" |
03 | android:orientation="vertical" |
04 | android:layout_width="fill_parent" |
05 | android:layout_height="fill_parent" |
06 | android:background="#777" |
07 | android:padding="8dip" |
10 | android:layout_width="fill_parent" |
11 | android:layout_height="wrap_content" |
12 | android:text=" 正文:A NinePatchDrawable graphic is a stretchable bitmap image, which Android will automatically resize to accommodate the contents of the View in which you have placed it as the background. A NinePatch drawable is a standard PNG image that includes an extra 1-pixel-wide border." |
13 | android:background="@drawable/content" |
14 | android:textColor="#000" |
如圖，
 可以看出，邊框非常的清晰。下圖是未使用.9.PNG的對(duì)比圖，而且也不是我們要的效果：  到這里為止，我們已經(jīng)基本會(huì)制作.9.PNG圖片了。為了知識(shí)體系的全面性和深入性，我們繼續(xù)。
4.使用Draw9Patch.jar制作9.PNG圖片之定義內(nèi)容區(qū)域。
是不是覺得文字和邊距挨的太近，好，我們使用right和bottom邊的線來定義內(nèi)容區(qū)域，來達(dá)到增大內(nèi)邊距的目的。
我們定義了一個(gè)很小的內(nèi)容區(qū)域，其他的地方則自動(dòng)充當(dāng)邊框，從而使內(nèi)邊距顯的很大，如下圖，
在這里，我要特別說明，一開始為了增大內(nèi)邊距，很容易慣性思維，在<TextView>中申明 android:padding="10dip" 之類的，我在這里勸告朋友們不要這么做，一是你將無法預(yù)知你的顯示，二是這比較混淆，因?yàn)樵O(shè)置內(nèi)容區(qū)域就是確定padding，所以我在前面部分說他們是 神似。我個(gè)人認(rèn)為通過內(nèi)容區(qū)域設(shè)定padding比在布局xml中定義padding更優(yōu)雅，更簡潔！
關(guān)于Draw9Patch工具的其他使用說明，我在次不再累述，因?yàn)橐f的話太多，為了節(jié)省篇幅，請(qǐng)參考官方文檔。 5.制作.9.PNG的高級(jí)技巧。
對(duì)于初學(xué)Draw9Patch的人來說，這可以算是高級(jí)技巧，那就是：拉伸區(qū)域，可以不是連續(xù)的，可以不止一塊，而且是和自定義的邊框線的長度成正比。
直接上圖說明：
 6.SDK中如何處理9.PNG圖片。
SDK專門針對(duì)9.PNG做了定義和處理，這里我們只是做個(gè)簡單的流程分析，Bitmap在讀取圖像流數(shù)據(jù)的時(shí)候，會(huì)把判斷圖片的 NinePatchChunk(9Patch數(shù)據(jù)塊)，如果NinePatchChunk不為空，則是 NinePatchDrawable，NinePatchDrawable則又會(huì)交給NinePatch處理： 1 | setNinePatchState(new NinePatchState( |
2 | new NinePatch(bitmap, bitmap.getNinePatchChunk(), "XML 9-patch"), |
NinePatch檢驗(yàn)成功則調(diào)用本地方法，繪制出最終的圖片： 1 | nativeDraw(canvas.mNativeCanvas, location, |
2 | mBitmap.ni(), mChunk, paint != null ? paint.mNativePaint : 0, |
3 | canvas.mDensity, mBitmap.mDensity); |
7.android系統(tǒng)中大量應(yīng)用了9.PNG圖片。
通過解壓隨便一個(gè)rom，找到里面的framework_res.apk,里面有大量的9.PNG格式文件，被廣泛的應(yīng)用起來，比如常見的有：
按鈕：  
解鎖：  
下拉框：  
標(biāo)題欄：
Toast：
還有搜索，鍵盤，放大縮小控件，時(shí)間加減等等，我就不一一列舉。 8.最后送上一些圖例，以饗讀者，以做后鑒： 賞圖1 本人之作  賞圖2 下拉按鈕  賞圖3 文章頭部背景  賞圖4 系統(tǒng)頭部背景  轉(zhuǎn)載于 http://www.cnblogs.com/qianxudetianxia/archive/2011/04/17/2017591.html
方法一： Java代碼  - public void saveIcon(Bitmap icon) {
- if (icon == null) {
- return;
- }
-
- // 最終圖標(biāo)要保存到瀏覽器的內(nèi)部數(shù)據(jù)庫中，系統(tǒng)程序均保存為SQLite格式，Browser也不例外，因?yàn)閳D片是二進(jìn)制的所以使用字節(jié)數(shù)組存儲(chǔ)數(shù)據(jù)庫的
- // BLOB類型
- final ByteArrayOutputStream os = new ByteArrayOutputStream();
- // 將Bitmap壓縮成PNG編碼，質(zhì)量為100%存儲(chǔ)
- icon.compress(Bitmap.CompressFormat.PNG, 100, os);
- // 構(gòu)造SQLite的Content對(duì)象，這里也可以使用raw
- ContentValues values = new ContentValues();
- // 寫入數(shù)據(jù)庫的Browser.BookmarkColumns.TOUCH_ICON字段
- values.put(Browser.BookmarkColumns.TOUCH_ICON, os.toByteArray());
-
- DBUtil.update(....);//調(diào)用更新或者插入到數(shù)據(jù)庫的方法
- }
方法二：如果數(shù)據(jù)表入口時(shí)一個(gè)content:URI Java代碼 - import android.provider.MediaStore.Images.Media;
- import android.content.ContentValues;
- import java.io.OutputStream;
-
- // Save the name and description of an image in a ContentValues map.
- ContentValues values = new ContentValues(3);
- values.put(Media.DISPLAY_NAME, "road_trip_1");
- values.put(Media.DESCRIPTION, "Day 1, trip to Los Angeles");
- values.put(Media.MIME_TYPE, "image/jpeg");
-
- // Add a new record without the bitmap, but with the values just set.
- // insert() returns the URI of the new record.
- Uri uri = getContentResolver().insert(Media.EXTERNAL_CONTENT_URI, values);
-
- // Now get a handle to the file for that record, and save the data into it.
- // Here, sourceBitmap is a Bitmap object representing the file to save to the database.
- try {
- OutputStream outStream = getContentResolver().openOutputStream(uri);
- sourceBitmap.compress(Bitmap.CompressFormat.JPEG, 50, outStream);
- outStream.close();
- } catch (Exception e) {
- Log.e(TAG, "exception while writing image", e);
- }
1、成員變量（全局變量）命名首字母以m開頭第二個(gè)字母大寫；（e.g int mIndex = 0）
2、常量全部大寫 3、靜態(tài)的變量命名首字母以s開頭第二個(gè)字母大寫；（e.g static int sIndex = 0）
原文出自：http://blog.csdn.net/aa4790139/article/details/6754230 第一種情況：
Proguard returned with error code 1. See console
Error: C:/Documents (系統(tǒng)找不到指定文件)
后來發(fā)現(xiàn)是因?yàn)閷⒄麄€(gè)工程放到了桌面上，而桌面的目錄是C:/Documents and Settings/Administrator/桌面，在這里面有空格，而proguard進(jìn)行發(fā)編譯的時(shí)候是不允許有空格的
如果換了正確路徑還不好用的話，直接刪除proguard就好了 注意：SDK和程序路徑最好不要有空格符 第二種情況： Proguard returned with error code 1. See console
異常： java.lang.ArrayIndexOutOfBoundsException 解決辦法：將proguard.cfg中的"-dontpreverify"改成“-dontoptimize” 參考文章：http://groups.google.com/group/android-developers/browse_thread/thread/eca3b0f5ce6ad00f
建一個(gè)自己的博客，既可以練習(xí)php，mysql，還能了解一些網(wǎng)站基礎(chǔ)知識(shí)。好了現(xiàn)在我就吧自己建立玩站的過程寫下來，供大家參考！過程是漫長的，只有自己摸索，才能不斷增加經(jīng)驗(yàn)，才能自己解決問題！ 首先我們得要個(gè)空間，這個(gè)空間是用來放網(wǎng)頁文件滴，其實(shí)網(wǎng)站就是一個(gè)文件夾，里面放了許多網(wǎng)頁，在靜態(tài)網(wǎng)頁中，當(dāng)你用瀏覽器訪問這個(gè)文件時(shí)它會(huì)首先訪問index.html，自己動(dòng)手做過的同學(xué)肯定知道，當(dāng)你把別人網(wǎng)站拷下來的時(shí)候體會(huì)就明顯了，我就這么干的（好像很廢話）。 1.我前前后后申請(qǐng)了N多空間，不是空間太小，就是無法登陸，或者DNS解析不上，所以我推薦用www.simplefreeweb.com，完全免費(fèi)滴，等一晚上就把賬號(hào)密碼發(fā)過來了，后臺(tái)有很多工具mysql，phpmyadmin等等（額- -！我忘了說一點(diǎn)，懂一點(diǎn)數(shù)據(jù)庫和php的同學(xué)上手快一些，因?yàn)槟氵B數(shù)據(jù)庫，表都不知道，那出現(xiàn)問題你都不知道在哪里）。 2.注冊(cè)好能登陸的前提下，再到cn.wordpress.org下載他們的wordpress（這是別人做好的玩站模板，直接可用，里面是php文件如果你自己有自信比他做的好，或者練習(xí)php，那就自己做吧）解壓上傳到空間，上傳工具很多，我用的是filezilla，用www.simplefreeweb.com提供的ftp站好密碼，上傳到ftp里面的www目錄下，記住上傳wordpress文件下的文件，不要把wordpress文件夾一起傳上去，要不然你要訪問yourname.simplefreeweb.com/wordpress才能訪問。 3.上傳完成，用simplefreeweb給你的后臺(tái)登陸網(wǎng)址登陸，在里面建立數(shù)據(jù)庫，再向數(shù)據(jù)庫添加用戶的時(shí)候一定要勾選全部權(quán)限，要不然在后面wordpress安裝的時(shí)候會(huì)連接出現(xiàn)問題！ 4.建立好數(shù)據(jù)庫后，登陸你的網(wǎng)站yourname.simplefreeweb.com，會(huì)出現(xiàn)wordpress安裝導(dǎo)向，按照步驟就可以啦！ 5.yourname.simplefreeweb.com這個(gè)是人家的二級(jí)域名，既不個(gè)性，有很難記，所以我們得要個(gè)自己的。網(wǎng)上的頂級(jí)域名很多但價(jià)格不菲，而且申請(qǐng)麻煩，所以我建議到http://www.dot.tk申請(qǐng)，很方便！ 綁定域名，就是將這個(gè)域名指向你的網(wǎng)站，方法主要是域名解析，免費(fèi)的解析商也很多，很久都沒消息（我的就是，ywww.simplefreeweb.com自帶的解析不給力啊）。但是，tk里面有個(gè)域名跳轉(zhuǎn)，當(dāng)你申請(qǐng)完后把你的yourname.simplefreeweb.com填進(jìn)去，這樣當(dāng)訪問你的域名，如我的www.liubos.k時(shí)候，直接跳到liubo.simplefreeweb.com。好處是方便，缺點(diǎn)是當(dāng)別人訪問非主頁時(shí)，還是顯示原來的網(wǎng)址！又等一晚上！第二天再訪問自己的網(wǎng)站www.xxx.tk吧！說到xxx，我又邪惡了，呵呵！
摘要: android 使用contentobserver監(jiān)聽數(shù)據(jù)庫內(nèi)容變化在android中經(jīng)常會(huì)用到改變數(shù)據(jù)庫內(nèi)容后再去使用數(shù)據(jù)庫更新的內(nèi)容，很多人會(huì)重新去query一遍，但是這樣的問題就是程序會(huì)特別占內(nèi)存，而且有可能會(huì)摟關(guān)cursor而導(dǎo)致程序內(nèi)存未釋放等等。其實(shí)android內(nèi)部提供了一種ContentObserver的東西來監(jiān)聽數(shù)據(jù)庫內(nèi)容的變化。ContentObserver的構(gòu)造函數(shù)需要一個(gè)參... 閱讀全文
最近有個(gè)需求，不去調(diào)用系統(tǒng)界面發(fā)送彩信功能。做過發(fā)送短信功能的同學(xué)可能第一反應(yīng)是這樣：
不使用 StartActivity，像發(fā)短信那樣，調(diào)用一個(gè)類似于發(fā)短信的方法
SmsManager smsManager = SmsManager.getDefault();
smsManager.sendTextMessage(phoneCode, null, text, null, null);
可以實(shí)現(xiàn)嗎？ 答案是否定的，因?yàn)閍ndroid上根本就沒有提供發(fā)送彩信的接口，如果你想發(fā)送彩信，對(duì)不起，請(qǐng)調(diào)用系統(tǒng)彩信app界面，如下
Intent sendIntent = new Intent(Intent.ACTION_SEND, Uri.parse("mms://"));
sendIntent.setType("image/jpeg");
String url = "file://sdcard//tmpPhoto.jpg";
sendIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse(url));
startActivity(Intent.createChooser(sendIntent, "MMS:"));
但是這種方法往往不能滿足我們的需求，能不能不調(diào)用系統(tǒng)界面，自己實(shí)現(xiàn)發(fā)送彩信呢？經(jīng)過幾天的努力，終于找到了解決辦法。
第一步：先構(gòu)造出你要發(fā)送的彩信內(nèi)容，即構(gòu)建一個(gè)pdu，需要用到以下幾個(gè)類，這些類都是從android源碼的MMS應(yīng)用中mms.pdu包中copy出來的。你需要將pdu包中的所有類 都拷貝到你的工程中，然后自己酌情調(diào)通。 final SendReq sendRequest = new SendReq(); final PduBody pduBody = new PduBody(); final PduPart part = new PduPart();//存放附件，每個(gè)附件是一個(gè)part，如果添加多個(gè)附件，就想body中add多個(gè)part。 pduBody.addPart(partPdu); sendRequest.setBody(pduBody); final PduComposer composer = new PduComposer(ctx, sendRequest); final byte[] bytesToSend = composer.make(); //將彩信的內(nèi)容以及主題等信息轉(zhuǎn)化成byte數(shù)組，準(zhǔn)備通過http協(xié)議發(fā)送到 ”http://mmsc.monternet.com”; 第二步：發(fā)送彩信到彩信中心。 構(gòu)建pdu的代碼：
String subject = "測(cè)試彩信";
String recipient = "接收彩信的號(hào)碼";//138xxxxxxx
final SendReq sendRequest = new SendReq();
final EncodedStringValue[] sub = EncodedStringValue.extract(subject);
if (sub != null && sub.length > 0) {
sendRequest.setSubject(sub[0]);
}
final EncodedStringValue[] phoneNumbers = EncodedStringValue.extract(recipient);
if (phoneNumbers != null && phoneNumbers.length > 0) {
sendRequest.addTo(phoneNumbers[0]);
}
final PduBody pduBody = new PduBody();
final PduPart part = new PduPart();
part.setName("sample".getBytes());
part.setContentType("image/png".getBytes());
String furl = "file://mnt/sdcard//1.jpg";
final PduPart partPdu = new PduPart();
partPdu.setCharset(CharacterSets.UTF_8);//UTF_16
partPdu.setName(part.getName());
partPdu.setContentType(part.getContentType());
partPdu.setDataUri(Uri.parse(furl));
pduBody.addPart(partPdu);
sendRequest.setBody(pduBody);
final PduComposer composer = new PduComposer(ctx, sendRequest);
final byte[] bytesToSend = composer.make();
Thread t = new Thread(new Runnable() {
@Override
public void run() {
try {
HttpConnectInterface.sendMMS(ctx, bytesToSend);
//
} catch (IOException e) {
e.printStackTrace();
}
}
});
t.start();發(fā)送pdu到彩信中心的代碼： public static String mmscUrl = "http://mmsc.monternet.com";
// public static String mmscUrl = "http://www.baidu.com/";
public static String mmsProxy = "10.0.0.172";
public static String mmsProt = "80";
private static String HDR_VALUE_ACCEPT_LANGUAGE = "";
// Definition for necessary HTTP headers.
private static final String HDR_KEY_ACCEPT = "Accept";
private static final String HDR_KEY_ACCEPT_LANGUAGE = "Accept-Language";
private static final String HDR_VALUE_ACCEPT =
"*/*, application/vnd.wap.mms-message, application/vnd.wap.sic";
public static byte[] sendMMS(Context context, byte[] pdu)throws IOException{
HDR_VALUE_ACCEPT_LANGUAGE = getHttpAcceptLanguage();
if (mmscUrl == null) {
throw new IllegalArgumentException("URL must not be null.");
}
HttpClient client = null;
try {
// Make sure to use a proxy which supports CONNECT.
client = HttpConnector.buileClient(context);
HttpPost post = new HttpPost(mmscUrl);
//mms PUD START
ByteArrayEntity entity = new ByteArrayEntity(pdu);
entity.setContentType("application/vnd.wap.mms-message");
post.setEntity(entity);
post.addHeader(HDR_KEY_ACCEPT, HDR_VALUE_ACCEPT);
post.addHeader(HDR_KEY_ACCEPT_LANGUAGE, HDR_VALUE_ACCEPT_LANGUAGE);
//mms PUD END
HttpParams params = client.getParams();
HttpProtocolParams.setContentCharset(params, "UTF-8");
HttpResponse response = client.execute(post);
LogUtility.showLog(tag, "111");
StatusLine status = response.getStatusLine();
LogUtility.showLog(tag, "status "+status.getStatusCode());
if (status.getStatusCode() != 200) { // HTTP 200 is not success.
LogUtility.showLog(tag, "!200");
throw new IOException("HTTP error: " + status.getReasonPhrase());
}
HttpEntity resentity = response.getEntity();
byte[] body = null;
if (resentity != null) {
try {
if (resentity.getContentLength() > 0) {
body = new byte[(int) resentity.getContentLength()];
DataInputStream dis = new DataInputStream(resentity.getContent());
try {
dis.readFully(body);
} finally {
try {
dis.close();
} catch (IOException e) {
Log.e(tag, "Error closing input stream: " + e.getMessage());
}
}
}
} finally {
if (entity != null) {
entity.consumeContent();
}
}
}
LogUtility.showLog(tag, "result:"+new String(body));
return body;
} catch (IllegalStateException e) {
LogUtility.showLog(tag, "",e);
// handleHttpConnectionException(e, mmscUrl);
} catch (IllegalArgumentException e) {
LogUtility.showLog(tag, "",e);
// handleHttpConnectionException(e, mmscUrl);
} catch (SocketException e) {
LogUtility.showLog(tag, "",e);
// handleHttpConnectionException(e, mmscUrl);
} catch (Exception e) {
LogUtility.showLog(tag, "",e);
//handleHttpConnectionException(e, mmscUrl);
} finally {
if (client != null) {
// client.;
}
}
return new byte[0];
}至此，彩信的發(fā)送算是完成了。
總結(jié)：android的彩信相關(guān)操作都是沒有api的，包括彩信的讀取、發(fā)送、存儲(chǔ)。這些過程都是需要手動(dòng)去完成的。想要弄懂這些過程，需要仔細(xì)閱讀android源碼中的mms這個(gè)app。還有就是去研究mmssms.db數(shù)據(jù)庫，因?yàn)椴市诺淖x取和存儲(chǔ)其實(shí)都是對(duì)mmssms.db這個(gè)數(shù)據(jù)庫的操作過程。而且因?yàn)檫@個(gè)是共享的數(shù)據(jù)庫，所以只能用ContentProvider這個(gè)組件去操作db。 總之，想要研究彩信這塊(包括普通短信)，你就必須的研究mmssms.db的操作方法，多多了解每個(gè)表對(duì)應(yīng)的哪個(gè)uri，每個(gè)uri能提供什么樣的操作，那些字段代表短信的那些屬性等。
最后推薦個(gè)好用的sqlite查看工具：SQLite Database Browser。
注意到在Activity的API中有大量的onXXXX形式的函數(shù)定義，除了我們前面用到的onCreate以外，還有onStart，onStop以及onPause等等。從字面上看，它們是一些事件回調(diào)，那么次序又是如何的呢？其實(shí)這種事情，自己做個(gè)實(shí)驗(yàn)最明白不過了。在做這個(gè)實(shí)驗(yàn)之前，我們先得找到在Android中的Log是如何輸出的。
顯然，我們要用的是android.util.log類，這個(gè)類相當(dāng)?shù)暮唵我子茫驗(yàn)樗峁┑娜且恍╈o態(tài)方法：
 Log.v(String tag, String msg); //VERBOSE
Log.d(String tag, String msg); //DEBUG
Log.i(String tag, String msg); //INFO
Log.w(String tag, String msg); //WARN
Log.e(String tag, String msg); //ERROR
輸出的LOG信息，如果用Eclipse+ADT開發(fā)，在LogCat中就可以看到，否則用adb logcat也行，不過我是從來都依賴于IDE環(huán)境的。
好了，現(xiàn)在我們修改前面的HelloThree代碼：
public void onStart()
 {
 super.onStart();
Log.v(TAG,"onStart");
 }
public void onStop()
{
super.onStop();
Log.v(TAG,"onStop");
}
public void onResume()
{
super.onResume();
Log.v(TAG,"onResume");
}
public void onRestart()
{
super.onRestart();
Log.v(TAG,"onReStart");
}
public void onPause()
{
super.onPause();
Log.v(TAG,"onPause");
}
public void onDestroy()
{
super.onDestroy();
Log.v(TAG,"onDestroy");
}
public void onFreeze(Bundle outState)
{
super.onFreeze(outState);
Log.v(TAG,"onFreeze");
}
在啟動(dòng)第一個(gè)界面Activity One時(shí)，它的次序是：
onCreate (ONE) - onStart (ONE) - onResume(ONE)
雖然是第一次啟動(dòng)，也要走一遍這個(gè)resume事件。然后，我們點(diǎn)goto跳到第二個(gè)Activity Two中（前一個(gè)沒有關(guān)閉），這時(shí)走的次序是：
onFreeze(ONE) - onPause(ONE) - onCreate(TWO) - onStart(TWO) - onResume(TWO) - onStop(ONE)
說明，第二個(gè)Activity Two在啟動(dòng)前，One會(huì)經(jīng)歷一個(gè)：凍結(jié)、暫停的過程，在啟動(dòng)Two后，One才會(huì)被停止？
然后，我們?cè)冱c(diǎn)back回到第一個(gè)界面，這時(shí)走的次序是：
onPause(TWO) - onActivityResult(ONE) - onStart(ONE) - onRestart(ONE) - onResume(ONE) - onStop(TWO) - onDestroy(TWO)
說明，返回時(shí)，Two沒有經(jīng)歷凍結(jié)就直接暫停了，在One接收參數(shù)，重啟后，Two就停止并被銷毀了。
最后，我們點(diǎn)一下Exit退出應(yīng)用，它的次序是：
onPause(ONE) - onStop(ONE) - onDestroy(ONE)
說明如果我們用了finish的話，不會(huì)有freeze，但是仍會(huì)經(jīng)歷pause - stop才被銷毀。
這里有點(diǎn)疑問的是：為什么回來時(shí)先是Start才是Restart？可是文檔中的圖上畫的卻是先restart再start的啊？不過，后面的表格中的描述好象是正確的，start后面總是跟著resume（如果是第一次）或者restart（如果原來被stop掉了，這種情況會(huì)在start與resume中插一個(gè)restart）。
下面不跑例子了，看看文檔吧。
1.Android用Activity Stack來管理多個(gè)Activity，所以呢，同一時(shí)刻只會(huì)有最頂上的那個(gè)Activity是處于active或者running狀態(tài)。其它的Activity都被壓在下面了。
2.如果非活動(dòng)的Activity仍是可見的（即如果上面壓著的是一個(gè)非全屏的Activity或透明的Activity），它是處于paused狀態(tài)的。在系統(tǒng)內(nèi)存不足的情況下，paused狀態(tài)的Activity是有可被系統(tǒng)殺掉的。只是不明白，如果它被干掉了，界面上的顯示又會(huì)變成什么模樣？看來下回有必要研究一下這種情況了。
3.幾個(gè)事件的配對(duì)可以比較清楚地理解它們的關(guān)系。Create與Destroy配成一對(duì)，叫entrie lifetime，在創(chuàng)建時(shí)分配資源，則在銷毀時(shí)釋放資源；往上一點(diǎn)還有Start與Stop一對(duì)，叫visible lifetime，表達(dá)的是可見與非可見這么一個(gè)過程；最頂上的就是Resume和Pause這一對(duì)了，叫foreground lifetime，表達(dá)的了是否處于激活狀態(tài)的過程。
4.因此，我們實(shí)現(xiàn)的Activity派生類，要重載兩個(gè)重要的方法：onCreate()進(jìn)行初始化操作，onPause()保存當(dāng)前操作的結(jié)果。
除了Activity Lifecycle以外，Android還有一個(gè)Process Lifecycle的說明：
在內(nèi)存不足的時(shí)候，Android是會(huì)主動(dòng)清理門戶的，那它又是如何判斷哪個(gè)process是可以清掉的呢？文檔中也提到了它的重要性排序：
1.最容易被清掉的是empty process，空進(jìn)程是指那些沒有Activity與之綁定，也沒有任何應(yīng)用程序組件（如Services或者IntentReceiver）與之綁定的進(jìn)程，也就是說在這個(gè)process中沒有任何activity或者service之類的東西，它們僅僅是作為一個(gè)cache，在啟動(dòng)新的Activity時(shí)可以提高速度。它們是會(huì)被優(yōu)先清掉的。因此建議，我們的后臺(tái)操作，最好是作成Service的形式，也就是說應(yīng)該在Activity中啟動(dòng)一個(gè)Service去執(zhí)行這些操作。
2.接下來就是background activity了，也就是被stop掉了那些activity所處的process，那些不可見的Activity被清掉的確是安全的，系統(tǒng)維持著一個(gè)LRU列表，多個(gè)處于background的activity都在這里面，系統(tǒng)可以根據(jù)LRU列表判斷哪些activity是可以被清掉的，以及其中哪一個(gè)應(yīng)該是最先被清掉。不過，文檔中提到在這個(gè)已被清掉的Activity又被重新創(chuàng)建的時(shí)候，它的onCreate會(huì)被調(diào)用，參數(shù)就是onFreeze時(shí)的那個(gè)Bundle。不過這里有一點(diǎn)不明白的是，難道這個(gè)Activity被killed時(shí)，Android會(huì)幫它保留著這個(gè)Bundle嗎？
3.然后就輪到service process了，這是一個(gè)與Service綁定的進(jìn)程，由startService方法啟動(dòng)。雖然它們不為用戶所見，但一般是在處理一些長時(shí)間的操作（例如MP3的播放），系統(tǒng)會(huì)保護(hù)它，除非真的沒有內(nèi)存可用了。
4.接著又輪到那些visible activity了，或者說visible process。前面也談到這個(gè)情況，被Paused的Activity也是有可能會(huì)被系統(tǒng)清掉，不過相對(duì)來說，它已經(jīng)是處于一個(gè)比較安全的位置了。
5.最安全應(yīng)該就是那個(gè)foreground activity了，不到迫不得已它是不會(huì)被清掉的。這種process不僅包括resume之后的activity，也包括那些onReceiveIntent之后的IntentReceiver實(shí)例。
在Android Application的生命周期的討論中，文檔也提到了一些需要注意的事項(xiàng)：因?yàn)锳ndroid應(yīng)用程序的生存期并不是由應(yīng)用本身直接控制的，而是由Android系統(tǒng)平臺(tái)進(jìn)行管理的，所以，對(duì)于我們開發(fā)者而言，需要了解不同的組件Activity、Service和IntentReceiver的生命，切記的是：如果組件的選擇不當(dāng)，很有可能系統(tǒng)會(huì)殺掉一個(gè)正在進(jìn)行重要工作的進(jìn)程。
啟動(dòng)代碼混淆功能在較新版本的Android tools和ADT，項(xiàng)目工程里面是帶有proguard.cfg的代碼混淆配置文件，但默認(rèn)是沒有啟動(dòng)這個(gè)配置的，需要手動(dòng)地在default.properties里面添加指定這個(gè)配置文件：# Project target. target=android-3 proguard.config=proguard.cfg 然后按F5刷新當(dāng)前項(xiàng)目工程，這時(shí)候Eclipse檢測(cè)了文件的變動(dòng)而重新編譯！ 生成簽名發(fā)布apk1.Eclipse工程中右鍵工程，彈出選項(xiàng)中選擇 android工具-生成簽名應(yīng)用包： 2.選擇需要打包的android項(xiàng)目工程(注：這里會(huì)自動(dòng)選擇當(dāng)前的Project的)： 3.如果已有私鑰文件，選擇私鑰文件 輸入密碼，如果沒有私鑰文件見 第6和7步創(chuàng)建私鑰文件： 4.輸入私鑰別名和密碼： 5.選擇APK存儲(chǔ)的位置，并完成設(shè)置 開始生成： 6.沒有私鑰文件的情況，創(chuàng)建私鑰文件（注：這里私鑰文件的Location位置最好自己選擇一個(gè)新位置，便于牢記，而且最好把這個(gè)私鑰文件備份到其他地方去以免丟失，因?yàn)閼?yīng)用程序的更新需要同一私鑰文件）： 7.輸入私鑰文件所需信息，并創(chuàng)建（注：這里的密碼是用于Key的別名的，和上面的KeyStore文件的不同，這點(diǎn)可以看步驟3和4。另外下面的名字，開發(fā)者資料等是不需要全部填寫的，dialog會(huì)有提示的）： 這時(shí)候生成的apk,我發(fā)現(xiàn)是比debug版本的要小！如果你發(fā)現(xiàn)沒有變小的話，請(qǐng)確認(rèn)項(xiàng)目工程是重新編譯的！但代碼混淆的效果一般般，基本上還是可以看到原來的語句！
摘要: android:allowTaskReparenting 用來標(biāo)記Activity能否從啟動(dòng)的Task移動(dòng)到有著affinity的Task（當(dāng)這個(gè)Task進(jìn)入到前臺(tái)時(shí)）——“true”，表示能移動(dòng)，“false”，表示它必須呆在啟動(dòng)時(shí)呆在的那個(gè)Task里。 ... 閱讀全文
Apk簽名首先要有一個(gè)keystore的簽名用的文件.
keystore是由jdk自帶的工具keytool生成的.具體生成方式參考一下:
開始->運(yùn)行->cmd->cd 到你安裝的jdk的目錄這里我是 C:\Program Files\Java\jdk1.6.0_10\bin
然后輸入：keytool -genkey -alias asaiAndroid.keystore -keyalg RSA -validity 20000 -keystore asaiAndroid.keystore
-alias 后跟的是別名這里是 asaiAndroid.keystore
-keyalg 是加密方式這里是 RSA
-validity 是有效期 這里是 20000
-keystore 就是要生成的keystore的名稱 這里是 asaiAndroid.keystore
然后按回車
按回車后首先會(huì)提示你輸入密碼：這個(gè)在簽名時(shí)要用的要記住了哦。
然后會(huì)再確認(rèn)你的密碼。
之后會(huì)依次叫你輸入 姓名，組織單位，組織名稱，城市區(qū)域，省份名稱，國家代碼等。
參考：
運(yùn)行完可以在 C:\Program Files\Java\jdk1.6.0_10\bin 里找到剛才生產(chǎn)的keyStore文件
好現(xiàn)在開始給Apk簽名了：
在 C:\Program Files\Java\jdk1.6.0_10\bin 還提供一個(gè)工具 jarsigner.exe
好現(xiàn)在可以在剛才的命令行后繼續(xù)運(yùn)行以下命令給APK簽名：
jarsigner -verbose -keystore asaiAndroid.keystore -signedjar LotteryOnline_signed.apk LotteryOnline.apk asaiAndroid.keystore
-keystore：keystore 的名稱
LotteryOnline_signed.apk 是簽完名后的APK
LotteryOnline.apk 是簽名前的apk
然后按回車：會(huì)要求輸入剛才設(shè)置的密碼，輸入后按回車就開始簽名了。
參考：
運(yùn)行成功后在 C:\Program Files\Java\jdk1.6.0_10\bin 目錄下會(huì)多出一個(gè)被簽名的apk文件，
參考：
摘要: alert_dark_framealert_light_framearrow_down_floatarrow_up_floatbottom_barbtn_defaultbtn_default_smallbtn_dialogbtn_dropdownbtn_minusbtn_plusbtn_radiobtn_starbtn_star_big_offbtn_star_big_onbutton_onoff... 閱讀全文
摘要: JAVA語言中的反射機(jī)制： 在Java 運(yùn)行時(shí) 環(huán)境中，對(duì)于任意一個(gè)類，能否知道這個(gè)類有哪些屬性和方法？ 對(duì)于任意一個(gè)對(duì)象，能否調(diào)用他的方法？這些答案是肯定的，這種動(dòng)態(tài)獲取類的信息，以及動(dòng)態(tài)調(diào)用類的方法的功能來源于JAVA的反射。從而使java具有動(dòng)態(tài)語言的特性。 JAVA反射機(jī)制主要提供了以下功能：&n... 閱讀全文
1、匯編語言
2、解釋性語言-------運(yùn)行慢，沒解釋一行，運(yùn)行一行
3、編譯性語言-------直接編譯成目標(biāo)程序，再運(yùn)行
下載的TomCat免安裝版在啟動(dòng)時(shí)的問題，在啟動(dòng)的時(shí)候運(yùn)行P處理的時(shí)候，會(huì)出現(xiàn)閃一下就消失的現(xiàn)象，
配置CATALINA_HOME=“C:\apache-tomcat-6.0.32”
JAVA_HOME="C:\Program Files\Java\jdk1.6.0_13"
PATH="C:\Program Files\Java\jdk1.6.0_13\bin"
1、conf目錄下的server.xml文件，在</Host>標(biāo)簽的上面加上
<Context path="/test" docBase="E:\javaWeb\Test\WebRoot" reloadable="true" /> 這句話
http://video.sina.com.cn/playlist/3545082-1349419557-1.html#25689407
1.1內(nèi)存分配方面：
堆：一般由程序員分配釋放，若程序員不釋放，程序結(jié)束時(shí)可能由OS回收 。注意它與數(shù)據(jù)結(jié)構(gòu)中的堆是兩回事，分配方式是類似于鏈表。可能用到的關(guān)鍵字如下：new、malloc、delete、free等等。
棧：由編譯器(Compiler)自動(dòng)分配釋放，存放函數(shù)的參數(shù)值，局部變量的值等。其操作方式類似于數(shù)據(jù)結(jié)構(gòu)中的棧。
1.2申請(qǐng)方式方面：
堆：需要程序員自己申請(qǐng)，并指明大小。在c中malloc函數(shù)如p1 = (char *)malloc(10)；在C++中用new運(yùn)算符，但是注意p1、p2本身是在棧中的。因?yàn)樗麄冞€是可以認(rèn)為是局部變量。
棧：由系統(tǒng)自動(dòng)分配。 例如，聲明在函數(shù)中一個(gè)局部變量 int b；系統(tǒng)自動(dòng)在棧中為b開辟空間。
1.3系統(tǒng)響應(yīng)方面：
堆：操作系統(tǒng)有一個(gè)記錄空閑內(nèi)存地址的鏈表，當(dāng)系統(tǒng)收到程序的申請(qǐng)時(shí)，會(huì)遍歷該鏈表，尋找第一個(gè)空間大于所申請(qǐng)空間的堆結(jié)點(diǎn)，然后將該結(jié)點(diǎn)從空閑結(jié)點(diǎn)鏈表中刪除，并將該結(jié)點(diǎn)的空間分配給程序，另外，對(duì)于大多數(shù)系統(tǒng)，會(huì)在這塊內(nèi)存空間中的首地址處記錄本次分配的大小，這樣代碼中的delete語句才能正確的釋放本內(nèi)存空間。另外由于找到的堆結(jié)點(diǎn)的大小不一定正好等于申請(qǐng)的大小，系統(tǒng)會(huì)自動(dòng)的將多余的那部分重新放入空閑鏈表中。
棧：只要棧的剩余空間大于所申請(qǐng)空間，系統(tǒng)將為程序提供內(nèi)存，否則將報(bào)異常提示棧溢出。
1.4大小限制方面：
堆：是向高地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)，是不連續(xù)的內(nèi)存區(qū)域。這是由于系統(tǒng)是用鏈表來存儲(chǔ)的空閑內(nèi)存地址的，自然是不連續(xù)的，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限于計(jì)算機(jī)系統(tǒng)中有效的虛擬內(nèi)存。由此可見，堆獲得的空間比較靈活，也比較大。
棧：在Windows下, 棧是向低地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)，是一塊連續(xù)的內(nèi)存的區(qū)域。這句話的意思是棧頂?shù)牡刂泛蜅５淖畲笕萘渴窍到y(tǒng)預(yù)先規(guī)定好的，在WINDOWS下，棧的大小是固定的（是一個(gè)編譯時(shí)就確定的常數(shù)），如果申請(qǐng)的空間超過棧的剩余空間時(shí)，將提示overflow。因此，能從棧獲得的空間較小。
1.5效率方面：
堆：是由new分配的內(nèi)存，一般速度比較慢，而且容易產(chǎn)生內(nèi)存碎片，不過用起來最方便，另外，在WINDOWS下，最好的方式是用VirtualAlloc分配內(nèi)存，他不是在堆，也不是在棧是直接在進(jìn)程的地址空間中保留一快內(nèi)存，雖然用起來最不方便。但是速度快，也最靈活。
棧：由系統(tǒng)自動(dòng)分配，速度較快。但程序員是無法控制的。
1.6存放內(nèi)容方面：
堆：一般是在堆的頭部用一個(gè)字節(jié)存放堆的大小。堆中的具體內(nèi)容有程序員安排。
棧：在函數(shù)調(diào)用時(shí)第一個(gè)進(jìn)棧的是主函數(shù)中后的下一條指令（函數(shù)調(diào)用語句的下一條可執(zhí)行語句）的地址然后是函數(shù)的各個(gè)參數(shù)，在大多數(shù)的C編譯器中，參數(shù)是由右往左入棧，然后是函數(shù)中的局部變量。 注意: 靜態(tài)變量是不入棧的。當(dāng)本次函數(shù)調(diào)用結(jié)束后，局部變量先出棧，然后是參數(shù)，最后棧頂指針指向最開始存的地址，也就是主函數(shù)中的下一條指令，程序由該點(diǎn)繼續(xù)運(yùn)行。
1.7存取效率方面：
堆：char *s1 = "Hellow Word"；是在編譯時(shí)就確定的；
棧：char s1[] = "Hellow Word"； 是在運(yùn)行時(shí)賦值的；用數(shù)組比用指針?biāo)俣纫煲恍驗(yàn)橹羔樤诘讓訁R編中需要用edx寄存器中轉(zhuǎn)一下，而數(shù)組在棧上直接讀取。
小結(jié)
1、靜態(tài)變量不入棧。
2、棧由編譯器自動(dòng)分配和釋放。棧中存放局部變量和參數(shù)，函數(shù)調(diào)用結(jié)束后，局部變量先出棧，然后是參數(shù)。
3、數(shù)組比用指針?biāo)俣纫煲恍驗(yàn)橹羔樤诘讓訁R編中需要用edx寄存器中轉(zhuǎn)一下，而數(shù)組在棧上直接讀取。
4、堆是由程序員通過new、malloc、free、delete等指令進(jìn)行分配和釋放。如果程序員沒有進(jìn)行釋放，程序結(jié)束時(shí)可能有OS回收。
5、堆是由new分配的內(nèi)存，速度較慢；棧是由系統(tǒng)自動(dòng)分配，速度較快。
6、比如存放在棧里面的數(shù)組，是在運(yùn)行時(shí)賦值。而存在堆里面的指針數(shù)據(jù)，是在編譯時(shí)就確定的。
附：
一. 在c中分為這幾個(gè)存儲(chǔ)區(qū)
1.棧 - 由編譯器自動(dòng)分配釋放
2.堆 - 一般由程序員分配釋放，若程序員不釋放，程序結(jié)束時(shí)可能由OS回收
3.全局區(qū)（靜態(tài)區(qū)），全局變量和靜態(tài)變量的存儲(chǔ)是放在一塊的，初始化的全局變量和靜態(tài)變量在一塊區(qū)域，未初始化的全局變量和未初始化的靜態(tài)變量在相鄰的另一塊區(qū)域。- 程序結(jié)束釋放
4.另外還有一個(gè)專門放常量的地方。- 程序結(jié)束釋放
在函數(shù)體中定義的變量通常是在棧上，用malloc, calloc, realloc等分配內(nèi)存的函數(shù)分配得到的就是在堆上。在所有函數(shù)體外定義的是全局量，加了static修飾符后不管在哪里都存放在全局區(qū)（靜態(tài)區(qū)）,在所有函數(shù)體外定義的static變量表示在該文件中有效，不能extern到別的文件用，在函數(shù)體內(nèi)定義的static表示只在該函數(shù)體內(nèi)有效。另外，函數(shù)中的"adgfdf"這樣的字符串存放在常量區(qū)。比如：
 int a = 0; //全局初始化區(qū)
 char *p1; //全局未初始化區(qū)
 void main()
 {
 int b; //棧
 char s[] = "abc"; //棧
 char *p2; //棧
 char *p3 = "123456"; //123456{post.content}在常量區(qū)，p3在棧上
 static int c = 0; //全局（靜態(tài)）初始化區(qū)
 p1 = (char *)malloc(10); //分配得來得10字節(jié)的區(qū)域在堆區(qū)
 p2 = (char *)malloc(20); //分配得來得20字節(jié)的區(qū)域在堆區(qū)
 strcpy(p1, "123456");
 //123456{post.content}放在常量區(qū)，編譯器可能會(huì)將它與p3所指向的"123456"優(yōu)化成一塊
 }
二.在C++中，內(nèi)存分成5個(gè)區(qū)，他們分別是堆、棧、自由存儲(chǔ)區(qū)、全局/靜態(tài)存儲(chǔ)區(qū)和常量存儲(chǔ)區(qū)
1.棧，就是那些由編譯器在需要的時(shí)候分配，在不需要的時(shí)候自動(dòng)清楚的變量的存儲(chǔ)區(qū)。里面的變量通常是局部變量、函數(shù)參數(shù)等。
2.堆，就是那些由new分配的內(nèi)存塊，他們的釋放編譯器不去管，由我們的應(yīng)用程序去控制，一般一個(gè)new就要對(duì)應(yīng)一個(gè)delete。如果程序員沒有釋放掉，那么在程序結(jié)束后，操作系統(tǒng)會(huì)自動(dòng)回收。
3.自由存儲(chǔ)區(qū)，就是那些由malloc等分配的內(nèi)存塊，他和堆是十分相似的，不過它是用free來結(jié)束自己的生命的。
4.全局/靜態(tài)存儲(chǔ)區(qū)，全局變量和靜態(tài)變量被分配到同一塊內(nèi)存中，在以前的C語言中，全局變量又分為初始化的和未初始化的，在C++里面沒有這個(gè)區(qū)分了，他們共同占用同一塊內(nèi)存區(qū)。
5.常量存儲(chǔ)區(qū)，這是一塊比較特殊的存儲(chǔ)區(qū)，他們里面存放的是常量，不允許修改（當(dāng)然，你要通過非正當(dāng)手段也可以修改）
三. 談?wù)劧雅c棧的關(guān)系與區(qū)別
具體地說，現(xiàn)代計(jì)算機(jī)(串行執(zhí)行機(jī)制)，都直接在代碼底層支持棧的數(shù)據(jù)結(jié)構(gòu)。這體現(xiàn)在，有專門的寄存器指向棧所在的地址，有專門的機(jī)器指令完成數(shù)據(jù)入棧出棧的操作。這種機(jī)制的特點(diǎn)是效率高，支持的數(shù)據(jù)有限，一般是整數(shù)，指針，浮點(diǎn)數(shù)等系統(tǒng)直接支持的數(shù)據(jù)類型，并不直接支持其他的數(shù)據(jù)結(jié)構(gòu)。因?yàn)闂５倪@種特點(diǎn)，對(duì)棧的使用在程序中是非常頻繁的。對(duì)子程序的調(diào)用就是直接利用棧完成的。機(jī)器的call指令里隱含了把返回地址推入棧，然后跳轉(zhuǎn)至子程序地址的操作，而子程序中的ret指令則隱含從堆棧中彈出返回地址并跳轉(zhuǎn)之的操作。C/C++中的自動(dòng)變量是直接利用棧的例子，這也就是為什么當(dāng)函數(shù)返回時(shí)，該函數(shù)的自動(dòng)變量自動(dòng)失效的原因。
和棧不同，堆的數(shù)據(jù)結(jié)構(gòu)并不是由系統(tǒng)(無論是機(jī)器系統(tǒng)還是操作系統(tǒng))支持的，而是由函數(shù)庫提供的。基本的malloc/realloc/free 函數(shù)維護(hù)了一套內(nèi)部的堆數(shù)據(jù)結(jié)構(gòu)。當(dāng)程序使用這些函數(shù)去獲得新的內(nèi)存空間時(shí)，這套函數(shù)首先試圖從內(nèi)部堆中尋找可用的內(nèi)存空間，如果沒有可以使用的內(nèi)存空間，則試圖利用系統(tǒng)調(diào)用來動(dòng)態(tài)增加程序數(shù)據(jù)段的內(nèi)存大小，新分配得到的空間首先被組織進(jìn)內(nèi)部堆中去，然后再以適當(dāng)?shù)男问椒祷亟o調(diào)用者。當(dāng)程序釋放分配的內(nèi)存空間時(shí)，這片內(nèi)存空間被返回內(nèi)部堆結(jié)構(gòu)中，可能會(huì)被適當(dāng)?shù)奶幚?比如和其他空閑空間合并成更大的空閑空間)，以更適合下一次內(nèi)存分配申請(qǐng)。這套復(fù)雜的分配機(jī)制實(shí)際上相當(dāng)于一個(gè)內(nèi)存分配的緩沖池(Cache)，使用這套機(jī)制有如下若干原因：
1. 系統(tǒng)調(diào)用可能不支持任意大小的內(nèi)存分配。有些系統(tǒng)的系統(tǒng)調(diào)用只支持固定大小及其倍數(shù)的內(nèi)存請(qǐng)求(按頁分配)；這樣的話對(duì)于大量的小內(nèi)存分類來說會(huì)造成浪費(fèi)。
2. 系統(tǒng)調(diào)用申請(qǐng)內(nèi)存可能是代價(jià)昂貴的。系統(tǒng)調(diào)用可能涉及用戶態(tài)和核心態(tài)的轉(zhuǎn)換。
3. 沒有管理的內(nèi)存分配在大量復(fù)雜內(nèi)存的分配釋放操作下很容易造成內(nèi)存碎片。
堆和棧的對(duì)比
從以上知識(shí)可知，棧是系統(tǒng)提供的功能，特點(diǎn)是快速高效，缺點(diǎn)是有限制，數(shù)據(jù)不靈活；而棧是函數(shù)庫提供的功能，特點(diǎn)是靈活方便，數(shù)據(jù)適應(yīng)面廣泛，但是效率有一定降低。棧是系統(tǒng)數(shù)據(jù)結(jié)構(gòu)，對(duì)于進(jìn)程/線程是唯一的；堆是函數(shù)庫內(nèi)部數(shù)據(jù)結(jié)構(gòu)，不一定唯一。不同堆分配的內(nèi)存無法互相操作。棧空間分靜態(tài)分配和動(dòng)態(tài)分配兩種。靜態(tài)分配是編譯器完成的，比如自動(dòng)變量(auto)的分配。動(dòng)態(tài)分配由alloca函數(shù)完成。棧的動(dòng)態(tài)分配無需釋放(是自動(dòng)的)，也就沒有釋放函數(shù)。為可移植的程序起見，棧的動(dòng)態(tài)分配操作是不被鼓勵(lì)的！堆空間的分配總是動(dòng)態(tài)的，雖然程序結(jié)束時(shí)所有的數(shù)據(jù)空間都會(huì)被釋放回系統(tǒng)，但是精確的申請(qǐng)內(nèi)存/ 釋放內(nèi)存匹配是良好程序的基本要素。
1.碎片問題：對(duì)于堆來講，頻繁的new/delete勢(shì)必會(huì)造成內(nèi)存空間的不連續(xù)，從而造成大量的碎片，使程序效率降低。對(duì)于棧來講，則不會(huì)存在這個(gè)問題，因?yàn)闂Ｊ窍冗M(jìn)后出的隊(duì)列，他們是如此的一一對(duì)應(yīng)，以至于永遠(yuǎn)都不可能有一個(gè)內(nèi)存塊從棧中間彈出，在他彈出之前，在他上面的后進(jìn)的棧內(nèi)容已經(jīng)被彈出，詳細(xì)的可以>參考數(shù)據(jù)結(jié)構(gòu)，這里我們就不再一一討論了。
2.生長方向：對(duì)于堆來講，生長方向是向上的，也就是向著內(nèi)存地址增加的方向；對(duì)于棧來講，它的生長方向是向下的，是向著內(nèi)存地址減小的方向增長。
3.分配方式：堆都是動(dòng)態(tài)分配的，沒有靜態(tài)分配的堆。棧有2種分配方式：靜態(tài)分配和動(dòng)態(tài)分配。靜態(tài)分配是編譯器完成的，比如局部變量的分配。動(dòng)態(tài)分配由alloca函數(shù)進(jìn)行分配，但是棧的動(dòng)態(tài)分配和堆是不同的，他的動(dòng)態(tài)分配是由編譯器進(jìn)行釋放，無需我們手工實(shí)現(xiàn)。
4.分配效率：棧是機(jī)器系統(tǒng)提供的數(shù)據(jù)結(jié)構(gòu)，計(jì)算機(jī)會(huì)在底層對(duì)棧提供支持：分配專門的寄存器存放棧的地址，壓棧出棧都有專門的指令執(zhí)行，這就決定了棧的效率比較高。堆則是C/C++函數(shù)庫提供的，它的機(jī)制是很復(fù)雜的，例如為了分配一塊內(nèi)存，庫函數(shù)會(huì)按照一定的算法（具體的算法可以參考數(shù)據(jù)結(jié)構(gòu)/操作系統(tǒng)）在堆內(nèi)存中搜索可用的足夠大小的空間，如果沒有足夠大小的空間（可能是由于內(nèi)存碎片太多），就有可能調(diào)用系統(tǒng)功能去增加程序數(shù)據(jù)段的內(nèi)存空間，這樣就有機(jī)會(huì)分到足夠大小的內(nèi)存，然后進(jìn)行返回。顯然，堆的效率比棧要低得多。
明確區(qū)分堆與棧:
在bbs上，堆與棧的區(qū)分問題，似乎是一個(gè)永恒的話題，由此可見，初學(xué)者對(duì)此往往是混淆不清的，所以我決定拿他第一個(gè)開刀。
首先，我們舉一個(gè)例子：
 void f()
 {
 int* p=new int[5];
 }
 這條短短的一句話就包含了堆與棧，看到new，我們首先就應(yīng)該想到，我們分配了一塊堆內(nèi)存，那么指針p呢？他分配的是一塊棧內(nèi)存，所以這句話的意思就是：在棧內(nèi)存中存放了一個(gè)指向一塊堆內(nèi)存的指針p。在程序會(huì)先確定在堆中分配內(nèi)存的大小，然后調(diào)用operator new分配內(nèi)存，然后返回這塊內(nèi)存的首地址，放入棧中，他在VC6下的匯編代碼如下：
00401028 push 14h
0040102A call operator new (00401060)
0040102F add esp,4
00401032 mov dword ptr [ebp-8],eax
00401035 mov eax,dword ptr [ebp-8]
00401038 mov dword ptr [ebp-4],eax
這里，我們?yōu)榱撕唵尾]有釋放內(nèi)存，那么該怎么去釋放呢？是delete p么？澳，錯(cuò)了，應(yīng)該是delete []p，這是為了告訴編譯器：我刪除的是一個(gè)數(shù)組，VC6就會(huì)根據(jù)相應(yīng)的Cookie信息去進(jìn)行釋放內(nèi)存的工作。
好了，我們回到我們的主題：堆和棧究竟有什么區(qū)別？
主要的區(qū)別由以下幾點(diǎn)：
1、管理方式不同；
2、空間大小不同；
3、能否產(chǎn)生碎片不同；
4、生長方向不同；
5、分配方式不同；
6、分配效率不同；
管理方式：對(duì)于棧來講，是由編譯器自動(dòng)管理，無需我們手工控制；對(duì)于堆來說，釋放工作由程序員控制，容易產(chǎn)生memory leak。
空間大小：一般來講在32位系統(tǒng)下，堆內(nèi)存可以達(dá)到4G的空間，從這個(gè)角度來看堆內(nèi)存幾乎是沒有什么限制的。但是對(duì)于棧來講，一般都是有一定的空間大小的，例如，在VC6下面，默認(rèn)的棧空間大小是1M（好像是，記不清楚了）。當(dāng)然，我們可以修改：
打開工程，依次操作菜單如下：Project->Setting->Link，在Category 中選中Output，然后在Reserve中設(shè)定堆棧的最大值和commit。
注意：reserve最小值為4Byte；commit是保留在虛擬內(nèi)存的頁文件里面，它設(shè)置的較大會(huì)使棧開辟較大的值，可能增加內(nèi)存的開銷和啟動(dòng)時(shí)間。
堆和棧相比，由于大量new/delete的使用，容易造成大量的內(nèi)存碎片；由于沒有專門的系統(tǒng)支持，效率很低；由于可能引發(fā)用戶態(tài)和核心態(tài)的切換，內(nèi)存的申請(qǐng)，代價(jià)變得更加昂貴。所以棧在程序中是應(yīng)用最廣泛的，就算是函數(shù)的調(diào)用也利用棧去完成，函數(shù)調(diào)用過程中的參數(shù)，返回地址，EBP和局部變量都采用棧的方式存放。所以，我們推薦大家盡量用棧，而不是用堆。
另外對(duì)存取效率的比較:
代碼:
 char s1[] = "aaaaaaaaaaaaaaa";
 char *s2 = "bbbbbbbbbbbbbbbbb"; aaaaaaaaaaa是在運(yùn)行時(shí)刻賦值的；
而bbbbbbbbbbb是在編譯時(shí)就確定的；
但是，在以后的存取中，在棧上的數(shù)組比指針?biāo)赶虻淖址?例如堆)快。
比如：
 void main()
 {
 char a = 1;
 char c[] = "1234567890";
 char *p ="1234567890";
 a = c[1];
 a = p[1];
 return;
 }對(duì)應(yīng)的匯編代碼
10: a = c[1];
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]
0040106A 88 4D FC mov byte ptr [ebp-4],cl
11: a = p[1];
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]
00401070 8A 42 01 mov al,byte ptr [edx+1]
00401073 88 45 FC mov byte ptr [ebp-4],al
第一種在讀取時(shí)直接就把字符串中的元素讀到寄存器cl中，而第二種則要先把指針值讀到edx中，在根據(jù)edx讀取字符，顯然慢了.
無論是堆還是棧，都要防止越界現(xiàn)象的發(fā)生（除非你是故意使其越界），因?yàn)樵浇绲慕Y(jié)果要么是程序崩潰，要么是摧毀程序的堆、棧結(jié)構(gòu)，產(chǎn)生以想不到的結(jié)果,就算是在你的程序運(yùn)行過程中，沒有發(fā)生上面的問題，你還是要小心，說不定什么時(shí)候就崩掉,編寫穩(wěn)定安全的代碼才是最重要的
android 的短信數(shù)據(jù)庫的讀取
android短信的數(shù)據(jù)庫的Uri是不公開的, 讀取起來時(shí)灰常不方便的, 這里做了下總結(jié).
用adb指令將mmssms.db從/data/data/com.android.providers.telephony/databases中pull出來
經(jīng)常使用到的表有
canonical_addresses, sms, threads三個(gè)表格
sms是存儲(chǔ)著所有的短信, 主要的列有_id, thread_id, address, person, date, read, type, body
關(guān)于的sms的Uri有
發(fā)件箱 content://sms/outbox
收件箱 content://sms/inbox
草稿箱 content://sms/draft
conversations content://sms/conversations
threads表存儲(chǔ)著每一個(gè)短信對(duì)話的線程. 主要列有_id, date, message_count, recipient_ids, snippet, read
recipient_ids 存放的是參與此次對(duì)話的person的id, 然而這個(gè)id不是通訊錄里面的id, 而是canonical_addresses 的id. 這就是canonical_addresses 表格的作用
threads 表 uri: content://mms-sms/conversations?simple=true
canonical_addresses 表 uri content://mms-sms/canonical-addresses
今天入住blogjava
-------------2011、1、10
|