|
2011年2月23日
Activity啟動方式有四種,分別是:
standard singleTop singleTask singleInstance
可以根據實際的需求為Activity設置對應的啟動模式,從而可以避免創建大量重復的Activity等問題。
設置Activity的啟動模式,只需要在AndroidManifest.xml里對應的<activity>標簽設置android:launchMode屬性,例如:
- <activity
- android:name=".A1"
- android:launchMode="standard" />
下面是這四種模式的作用:standard 默認模式,可以不用寫配置。在這個模式下,都會默認創建一個新的實例。因此,在這種模式下,可以有多個相同的實例,也允許多個相同Activity疊加。例如:若我有一個Activity名為A1, 上面有一個按鈕可跳轉到A1。那么如果我點擊按鈕,便會新啟一個Activity A1疊在剛才的A1之上,再點擊,又會再新啟一個在它之上……點back鍵會依照棧順序依次退出。singleTop可以有多個實例,但是不允許多個相同Activity疊加。即,如果Activity在棧頂的時候,啟動相同的Activity,不會創建新的實例,而會調用其onNewIntent方法。例如:若我有兩個Activity名為B1,B2,兩個Activity內容功能完全相同,都有兩個按鈕可以跳到B1或者B2,唯一不同的是B1為standard,B2為singleTop。若我意圖打開的順序為B1->B2->B2,則實際打開的順序為B1->B2(后一次意圖打開B2,實際只調用了前一個的onNewIntent方法)若我意圖打開的順序為B1->B2->B1->B2,則實際打開的順序與意圖的一致,為B1->B2->B1->B2。singleTask只有一個實例。在同一個應用程序中啟動他的時候,若Activity不存在,則會在當前task創建一個新的實例,若存在,則會把task中在其之上的其它Activity destory掉并調用它的onNewIntent方法。如果是在別的應用程序中啟動它,則會新建一個task,并在該task中啟動這個Activity,singleTask允許別的Activity與其在一個task中共存,也就是說,如果我在這個singleTask的實例中再打開新的Activity,這個新的Activity還是會在singleTask的實例的task中。例如:若我的應用程序中有三個Activity,C1,C2,C3,三個Activity可互相啟動,其中C2為singleTask模式,那么,無論我在這個程序中如何點擊啟動,如:C1->C2->C3->C2->C3->C1-C2,C1,C3可能存在多個實例,但是C2只會存在一個,并且這三個Activity都在同一個task里面。但是C1->C2->C3->C2->C3->C1-C2,這樣的操作過程實際應該是如下這樣的,因為singleTask會把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實際:C1->C2 C1->C2->C3 C1->C2 C1->C2->C3->C1 C1->C2若是別的應用程序打開C2,則會新啟一個task。如別的應用Other中有一個activity,taskId為200,從它打開C2,則C2的taskIdI不會為200,例如C2的taskId為201,那么再從C2打開C1、C3,則C2、C3的taskId仍為201。注意:如果此時你點擊home,然后再打開Other,發現這時顯示的肯定會是Other應用中的內容,而不會是我們應用中的C1 C2 C3中的其中一個。singleInstance只有一個實例,并且這個實例獨立運行在一個task中,這個task只有這個實例,不允許有別的Activity存在。例如:程序有三個ActivityD1,D2,D3,三個Activity可互相啟動,其中D2為singleInstance模式。那么程序從D1開始運行,假設D1的taskId為200,那么從D1啟動D2時,D2會新啟動一個task,即D2與D1不在一個task中運行。假設D2的taskId為201,再從D2啟動D3時,D3的taskId為200,也就是說它被壓到了D1啟動的任務棧中。若是在別的應用程序打開D2,假設Other的taskId為200,打開D2,D2會新建一個task運行,假設它的taskId為201,那么如果這時再從D2啟動D1或者D3,則又會再創建一個task,因此,若操作步驟為other->D2->D1,這過程就涉及到了3個task了。
系統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); 系統4.0.3以前的 Intent intent = new Intent(); intent.setAction(Intent.ACTION_SEND); //這個類型函數是自己工具類的方法,你可以自己設置文件類型,例如圖片文件:image/* //不想寫類型直接*/*也是可以的 intent.setType("audio/*"); //這里setClassName就是指定藍牙,不寫這句就彈出選擇用什么發送 //有藍牙啊,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);
我們在頁面布局的時候,經常會設置容器的長度,但是到底該使用哪個作為長度的單位而懊惱。在Android中支持的描述大小區域的類型有以下幾種: px(pixels)——像素:不同的設備顯示效果相同,一般我們HVGA代表320x480像素,這個用的比較多。 dip(device independent pixels)——設備獨立像素:這個和設備硬件有關,一般我們為了支持WCGA、HVGA和QVGA推薦使用這個,不依賴于像素。等同于dp。 sp(scaled pixels—best for text size)——帶比例的像素。 pt(points)——磅:1pt = 1/72英寸 in(inches)——英寸 mm(millimeters)——毫米 到底px和dip有什么區別呢? dip != px 主要是針對不同設備而言的。在Density是160的設備上,比如用AVDManager創建的默認模擬器,dip和px是一樣的但是如果同樣的代碼,換到不同Density的設備上,比如換到一個Density是240的設備上,dip和px體現出來的大小就不一樣了。px不管在什么樣的設備上都是那樣長,但是dip會根據設備變化;WQVGA屏density=120;QVGA屏density=120;HVGA屏density=160;WVGA屏density=240;density值表示每英寸有多少個顯示點,與分辨率是兩個概念。
當屏幕density=240時使用hdpi標簽的資源 當屏幕density=160時,使用mdpi標簽的資源 當屏幕density=120時,使用ldpi標簽的資源。
不加任何標簽的資源是各種分辨率情況下共用的。布局時盡量使用單位dip,少使用px。
換算公式為: pixs =dips * (densityDpi/160). dips=(pixs*160)/densityDpi 如何獲得設備的屏幕分辨率和屏幕密度?
例如分辨率為480*800,密度為240的設備,方法如下DisplayMetrics dm =getResources().getDisplayMetrics(); dm.densityDpi=240 dm.widthPixels=480 dm.heightPixels=800
首先啟動android模擬器。 打開cmd命令行窗口。輸入adb -s emulator-5554 shell 此時可以管理系統文件夾了,再輸入ls 可以看到列出了文件夾和文件,輸入cd system/app再輸入ls 可以看到系統自帶的應用程序apk文件,刪除你想要刪除的,例如Phone.apk,輸入rm Phone.apk 此時會看到提示說rm failed for Phone.apk, Read-only file system那是因為這些是只讀文件,我們沒有權限刪除它。所以接下來要做的是獲取權限,首先查看權限,輸入mount 可以看到/dev/block/mtdblock0 /system yaffs2 ro 0 0說明在system這個地方我們沒有權限那么接下來我們就來獲取權限,輸入mount -o remount,rw -t yaffs2 /dev/block/mtdblock0 /system 沒有提示錯誤,再次查看權限,輸入mount 可以看到/dev/block/mtdblock0 /system yaffs2 rw 0 0 說明我們已經獲取到權限了此時再輸入rm Phone.apk就可以成功刪除了
最后一點,就算你成功刪除了,android模擬器每次啟動時也會恢復回來。 那么如何永久刪除呢,很簡單,刪除SdkSetup.apk,輸入rm SdkSetup.apk 還沒完,找到avd目錄(一般在我的文檔),進入xxxx.avd目錄,刪除cache.img和userdata-qemu.img 還有還有,找到%SDK_HOME%/platforms/android-X/images/system.img,復制到上面的目錄中。 最后最后,再重啟模擬器,大功告成!
如果你的游戲不吃CPU,用View就比較好,符合標準Android操作方式,由系統決定刷新surface的時機。 但如果很不幸的,你做不到不讓你的程序吃CPU,你就只好使用SurfaceView來強制刷新surface了,不然系統的UI進程很可能搶不過你那些吃CPU的線程。 當然其實不止這兩種方法來刷新Surface的,這兩種只是純Java應用比較常見的方法。 SurfaceView和View最本質的區別在于,surfaceView是在一個新起的單獨線程中可以重新繪制畫面而View必須在UI的主線程中更新畫面。 那么在UI的主線程中更新畫面 可能會引發問題,比如你更新畫面的時間過長,那么你的主UI線程會被你正在畫的函數阻塞。那么將無法響應按鍵,觸屏等消息。 當使用surfaceView 由于是在新的線程中更新畫面所以不會阻塞你的UI主線程。但這也帶來了另外一個問題,就是事件同步。比如你觸屏了一下,你需要surfaceView中 thread處理,一般就需要有一個event queue的設計來保存touch event,這會稍稍復雜一點,因為涉及到線程同步。 所以基于以上,根據游戲特點,一般分成兩類。 1 被動更新畫面的。比如棋類,這種用view就好了。因為畫面的更新是依賴于 onTouch 來更新,可以直接使用 invalidate。 因為這種情況下,這一次Touch和下一次的Touch需要的時間比較長些,不會產生影響。 2 主動更新。比如一個人在一直跑動。這就需要一個單獨的thread不停的重繪人的狀態,避免阻塞main UI thread。所以顯然view不合適,需要surfaceView來控制。
android多國語言文件夾文件匯總如下: 中文(中國):values-zh-rCN 中文(臺灣):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 法文(比利時):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 荷蘭文(比利時):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中已經有這個activity A,那么就把A拿到task的最頂層,而不是創建一個新的activity。
所以不加flag也不會影響界面的切過去,只是會影響task的順序而已。
Android:stackFromBottom="true" 設置該屬性之后你做好的列表就會顯示在列表的最下面,值為true和false android:transcriptMode="alwaysScroll" 要用ListView或者其它顯示大量Items的控件實時跟蹤或者查看信息,并且希望最新的條目可以自動滾動到可視范圍內。通過設置的控件 transcriptMode屬性可以將Android平臺的控件(支持ScrollBar)自動滑動到最底部。 c acheColorHint屬性,很多人希望能夠改變一下它的背景,使他能夠符合整體的UI設計,改變背景背很簡單只需要準備一張圖片然后指定屬性 android:background="@drawable/bg",不過當你這么做以后,發現背景是變了,但是當你拖動,或者點擊list空白位置的 時候發現ListItem都變成黑色的了,破壞了整體效果。 如果只是換背景的顏色的話,可以直接指定 android:cacheColorHint為你所要的顏色,如果你是用圖片做背景的話,那也只要將 android:cacheColorHint指定為透明(#00000000)就可以了 android:divider="@drawable/list_driver" 其中 @drawable/list_driver 是一個圖片資源,如果不想顯示分割線則只要設置為android:divider="@drawable/@null" 就可以了 android:scrollbars="none"與setVerticalScrollBarEnabled(true);的效果是一樣的,不活動的 時候隱藏,活動的時候也隱藏 android:fadeScrollbars="true" 配置ListView布局的時候,設置這個屬性為true就可以實現滾動條的自動隱藏和顯示。 fadingEdge屬性,上邊和下邊有黑色的陰影 android:fadingEdge="none" 設置后沒有陰影了 
<activity android:name=".usual.activity.Declaration" android:theme="@android:style/Theme.Translucent.NoTitleBar" />
1.背景自適應且不失真問題的存在 制作自適應背景圖片是UI開發的一個廣泛問題,也是界面設計師渴望解決的問題,我相信我們彼此都深有體會。 比如,列表的背景圖一定,但是列表的高度隨著列表數據項會發生變化;標題欄的背景,無論橫屏還是豎屏,高分辨率還是低分辨率,都能自動填充滿,而且不失真等等背景問題。 根據以往的經驗,我們一般采用先切圖后拼湊的做法,這種做法本來我想在這里和大家介紹一下,其實有的時候還是很有用的,但是說起來會比較麻煩,就不說這個非重點了,略去,如果大家真的要介紹,在回復中說明,我再考慮一下。 Android針對這種情況,專門制作了一種.9.PNG格式來解決這個問題。 2.9.PNG格式。 我不想在這里過多的討論PNG格式的定義問題。但是.9.PNG確實是標準的PNG格式,只是在最外面一圈額外增加1px的邊框,這個1px的邊框就是 用來定義圖片中可擴展的和靜態不變的區域。特別說明,left和top邊框中交叉部分是可拉伸部分,未選中部分是靜態區域部分。right和bottom 邊框中交叉部分則是內容部分(變相的相當于定義看一個內邊距,神似padding功能,后面我會單獨介紹一下),這個參數是可選的, 如下圖。
在Android中以9.PNG格式的圖片未背景,則能夠自定義拉伸而不失真,比如系統的Button就是一個典型的例子。 其實呢,無論是left和top,還是right和bottom都是把圖片分成9塊 (邊角四塊是不能縮放的,其他的四塊則是允許縮放的),所以叫做9.PNG。 3. 使用Draw9Patch.jar制作9.PNG圖片之定義拉伸區域。 前面已經了解到9.PNG格式的工作方式,下面我們使用谷歌提供的Draw9Patch(運行android-sdk-windows\tools目錄下的Draw9Patch.bat)來制作.9.PNG圖片。 第一步:準備要拉伸的圖片。  非常小的一張圖片,我希望以此為背景,中間部分填充文章內容。 第二步:制作.9.PNG圖片。 打開Draw9Patch,把圖片拖進去,如下:
 默認的拉伸是整體拉伸,其實邊框部分我們并不想拉伸,好,我們自己來定義拉伸區域,如下圖:
  然后點擊File,導出為content.9.png。 第三步:在layout文件中使用制作的 .9.PNG圖片. 新建工程Draw9Patch,默認主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的對比圖,而且也不是我們要的效果: 到這里為止,我們已經基本會制作.9.PNG圖片了。為了知識體系的全面性和深入性,我們繼續。 4.使用Draw9Patch.jar制作9.PNG圖片之定義內容區域。 是不是覺得文字和邊距挨的太近,好,我們使用right和bottom邊的線來定義內容區域,來達到增大內邊距的目的。
 我們定義了一個很小的內容區域,其他的地方則自動充當邊框,從而使內邊距顯的很大,如下圖,
 在這里,我要特別說明,一開始為了增大內邊距,很容易慣性思維,在<TextView>中申明 android:padding="10dip" 之類的,我在這里勸告朋友們不要這么做,一是你將無法預知你的顯示,二是這比較混淆,因為設置內容區域就是確定padding,所以我在前面部分說他們是 神似。我個人認為通過內容區域設定padding比在布局xml中定義padding更優雅,更簡潔! 關于Draw9Patch工具的其他使用說明,我在次不再累述,因為要說的話太多,為了節省篇幅,請參考官方文檔。 5.制作.9.PNG的高級技巧。 對于初學Draw9Patch的人來說,這可以算是高級技巧,那就是:拉伸區域,可以不是連續的,可以不止一塊,而且是和自定義的邊框線的長度成正比。 直接上圖說明:
6.SDK中如何處理9.PNG圖片。 SDK專門針對9.PNG做了定義和處理,這里我們只是做個簡單的流程分析,Bitmap在讀取圖像流數據的時候,會把判斷圖片的 NinePatchChunk(9Patch數據塊),如果NinePatchChunk不為空,則是 NinePatchDrawable,NinePatchDrawable則又會交給NinePatch處理: 1 | setNinePatchState( new NinePatchState( |
2 | new NinePatch(bitmap, bitmap.getNinePatchChunk(), "XML 9-patch" ), |
NinePatch檢驗成功則調用本地方法,繪制出最終的圖片: 1 | nativeDraw(canvas.mNativeCanvas, location, |
2 | mBitmap.ni(), mChunk, paint != null ? paint.mNativePaint : 0 , |
3 | canvas.mDensity, mBitmap.mDensity); |
7.android系統中大量應用了9.PNG圖片。 通過解壓隨便一個rom,找到里面的framework_res.apk,里面有大量的9.PNG格式文件,被廣泛的應用起來,比如常見的有: 按鈕:  解鎖:  下拉框:  標題欄: Toast: 還有搜索,鍵盤,放大縮小控件,時間加減等等,我就不一一列舉。 8.最后送上一些圖例,以饗讀者,以做后鑒: 賞圖1 本人之作  賞圖2 下拉按鈕 賞圖3 文章頭部背景 賞圖4 系統頭部背景  轉載于 http://www.cnblogs.com/qianxudetianxia/archive/2011/04/17/2017591.html
方法一: Java代碼  - public void saveIcon(Bitmap icon) {
- if (icon == null) {
- return;
- }
-
- // 最終圖標要保存到瀏覽器的內部數據庫中,系統程序均保存為SQLite格式,Browser也不例外,因為圖片是二進制的所以使用字節數組存儲數據庫的
- // BLOB類型
- final ByteArrayOutputStream os = new ByteArrayOutputStream();
- // 將Bitmap壓縮成PNG編碼,質量為100%存儲
- icon.compress(Bitmap.CompressFormat.PNG, 100, os);
- // 構造SQLite的Content對象,這里也可以使用raw
- ContentValues values = new ContentValues();
- // 寫入數據庫的Browser.BookmarkColumns.TOUCH_ICON字段
- values.put(Browser.BookmarkColumns.TOUCH_ICON, os.toByteArray());
-
- DBUtil.update(....);//調用更新或者插入到數據庫的方法
- }
方法二:如果數據表入口時一個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開頭第二個字母大寫;(e.g int mIndex = 0) 2、常量全部大寫 3、靜態的變量命名首字母以s開頭第二個字母大寫;(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 (系統找不到指定文件) 后來發現是因為將整個工程放到了桌面上,而桌面的目錄是C:/Documents and Settings/Administrator/桌面,在這里面有空格,而proguard進行發編譯的時候是不允許有空格的 如果換了正確路徑還不好用的話,直接刪除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
建一個自己的博客,既可以練習php,mysql,還能了解一些網站基礎知識。好了現在我就吧自己建立玩站的過程寫下來,供大家參考!過程是漫長的,只有自己摸索,才能不斷增加經驗,才能自己解決問題! 首先我們得要個空間,這個空間是用來放網頁文件滴,其實網站就是一個文件夾,里面放了許多網頁,在靜態網頁中,當你用瀏覽器訪問這個文件時它會首先訪問index.html,自己動手做過的同學肯定知道,當你把別人網站拷下來的時候體會就明顯了,我就這么干的(好像很廢話)。 1.我前前后后申請了N多空間,不是空間太小,就是無法登陸,或者DNS解析不上,所以我推薦用www.simplefreeweb.com,完全免費滴,等一晚上就把賬號密碼發過來了,后臺有很多工具mysql,phpmyadmin等等(額- -!我忘了說一點,懂一點數據庫和php的同學上手快一些,因為你連數據庫,表都不知道,那出現問題你都不知道在哪里)。 2.注冊好能登陸的前提下,再到cn.wordpress.org下載他們的wordpress(這是別人做好的玩站模板,直接可用,里面是php文件如果你自己有自信比他做的好,或者練習php,那就自己做吧)解壓上傳到空間,上傳工具很多,我用的是filezilla,用www.simplefreeweb.com提供的ftp站好密碼,上傳到ftp里面的www目錄下,記住上傳wordpress文件下的文件,不要把wordpress文件夾一起傳上去,要不然你要訪問yourname.simplefreeweb.com/wordpress才能訪問。 3.上傳完成,用simplefreeweb給你的后臺登陸網址登陸,在里面建立數據庫,再向數據庫添加用戶的時候一定要勾選全部權限,要不然在后面wordpress安裝的時候會連接出現問題! 4.建立好數據庫后,登陸你的網站yourname.simplefreeweb.com,會出現wordpress安裝導向,按照步驟就可以啦! 5.yourname.simplefreeweb.com這個是人家的二級域名,既不個性,有很難記,所以我們得要個自己的。網上的頂級域名很多但價格不菲,而且申請麻煩,所以我建議到http://www.dot.tk申請,很方便! 綁定域名,就是將這個域名指向你的網站,方法主要是域名解析,免費的解析商也很多,很久都沒消息(我的就是,ywww.simplefreeweb.com自帶的解析不給力啊)。但是,tk里面有個域名跳轉,當你申請完后把你的yourname.simplefreeweb.com填進去,這樣當訪問你的域名,如我的www.liubos.k時候,直接跳到liubo.simplefreeweb.com。好處是方便,缺點是當別人訪問非主頁時,還是顯示原來的網址!又等一晚上!第二天再訪問自己的網站www.xxx.tk吧!說到xxx,我又邪惡了,呵呵!
摘要: android 使用contentobserver監聽數據庫內容變化在android中經常會用到改變數據庫內容后再去使用數據庫更新的內容,很多人會重新去query一遍,但是這樣的問題就是程序會特別占內存,而且有可能會摟關cursor而導致程序內存未釋放等等。其實android內部提供了一種ContentObserver的東西來監聽數據庫內容的變化。ContentObserver的構造函數需要一個參... 閱讀全文
最近有個需求,不去調用系統界面發送彩信功能。做過發送短信功能的同學可能第一反應是這樣: 不使用 StartActivity,像發短信那樣,調用一個類似于發短信的方法 SmsManager smsManager = SmsManager.getDefault(); smsManager.sendTextMessage(phoneCode, null, text, null, null); 可以實現嗎? 答案是否定的,因為android上根本就沒有提供發送彩信的接口,如果你想發送彩信,對不起,請調用系統彩信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:"));
但是這種方法往往不能滿足我們的需求,能不能不調用系統界面,自己實現發送彩信呢?經過幾天的努力,終于找到了解決辦法。 第一步:先構造出你要發送的彩信內容,即構建一個pdu,需要用到以下幾個類,這些類都是從android源碼的MMS應用中mms.pdu包中copy出來的。你需要將pdu包中的所有類 都拷貝到你的工程中,然后自己酌情調通。 final SendReq sendRequest = new SendReq(); final PduBody pduBody = new PduBody(); final PduPart part = new PduPart();//存放附件,每個附件是一個part,如果添加多個附件,就想body中add多個part。 pduBody.addPart(partPdu); sendRequest.setBody(pduBody); final PduComposer composer = new PduComposer(ctx, sendRequest); final byte[] bytesToSend = composer.make(); //將彩信的內容以及主題等信息轉化成byte數組,準備通過http協議發送到 ”http://mmsc.monternet.com”; 第二步:發送彩信到彩信中心。 構建pdu的代碼:
String subject = "測試彩信";
String recipient = "接收彩信的號碼";//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(); 發送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];
} 至此,彩信的發送算是完成了。 總結:android的彩信相關操作都是沒有api的,包括彩信的讀取、發送、存儲。這些過程都是需要手動去完成的。想要弄懂這些過程,需要仔細閱讀android源碼中的mms這個app。還有就是去研究mmssms.db數據庫,因為彩信的讀取和存儲其實都是對mmssms.db這個數據庫的操作過程。而且因為這個是共享的數據庫,所以只能用ContentProvider這個組件去操作db。 總之,想要研究彩信這塊(包括普通短信),你就必須的研究mmssms.db的操作方法,多多了解每個表對應的哪個uri,每個uri能提供什么樣的操作,那些字段代表短信的那些屬性等。 最后推薦個好用的sqlite查看工具:SQLite Database Browser。
注意到在Activity的API中有大量的onXXXX形式的函數定義,除了我們前面用到的onCreate以外,還有onStart,onStop以及onPause等等。從字面上看,它們是一些事件回調,那么次序又是如何的呢?其實這種事情,自己做個實驗最明白不過了。在做這個實驗之前,我們先得找到在Android中的Log是如何輸出的。
顯然,我們要用的是android.util.log類,這個類相當的簡單易用,因為它提供的全是一些靜態方法:
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
前面的tag是由我們定義的一個標識,一般可以用“類名_方法名“來定義。 輸出的LOG信息,如果用Eclipse+ADT開發,在LogCat中就可以看到,否則用adb logcat也行,不過我是從來都依賴于IDE環境的。
好了,現在我們修改前面的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");
} 在HelloThreeB中也同樣增加這樣的代碼,編譯,運行一下,從logcat中分析輸出的日志。 在啟動第一個界面Activity One時,它的次序是: onCreate (ONE) - onStart (ONE) - onResume(ONE) 雖然是第一次啟動,也要走一遍這個resume事件。然后,我們點goto跳到第二個Activity Two中(前一個沒有關閉),這時走的次序是: onFreeze(ONE) - onPause(ONE) - onCreate(TWO) - onStart(TWO) - onResume(TWO) - onStop(ONE) 說明,第二個Activity Two在啟動前,One會經歷一個:凍結、暫停的過程,在啟動Two后,One才會被停止? 然后,我們再點back回到第一個界面,這時走的次序是: onPause(TWO) - onActivityResult(ONE) - onStart(ONE) - onRestart(ONE) - onResume(ONE) - onStop(TWO) - onDestroy(TWO) 說明,返回時,Two沒有經歷凍結就直接暫停了,在One接收參數,重啟后,Two就停止并被銷毀了。 最后,我們點一下Exit退出應用,它的次序是: onPause(ONE) - onStop(ONE) - onDestroy(ONE) 說明如果我們用了finish的話,不會有freeze,但是仍會經歷pause - stop才被銷毀。
這里有點疑問的是:為什么回來時先是Start才是Restart?可是文檔中的圖上畫的卻是先restart再start的啊?不過,后面的表格中的描述好象是正確的,start后面總是跟著resume(如果是第一次)或者restart(如果原來被stop掉了,這種情況會在start與resume中插一個restart)。
下面不跑例子了,看看文檔吧。
1.Android用Activity Stack來管理多個Activity,所以呢,同一時刻只會有最頂上的那個Activity是處于active或者running狀態。其它的Activity都被壓在下面了。
2.如果非活動的Activity仍是可見的(即如果上面壓著的是一個非全屏的Activity或透明的Activity),它是處于paused狀態的。在系統內存不足的情況下,paused狀態的Activity是有可被系統殺掉的。只是不明白,如果它被干掉了,界面上的顯示又會變成什么模樣?看來下回有必要研究一下這種情況了。
3.幾個事件的配對可以比較清楚地理解它們的關系。Create與Destroy配成一對,叫entrie lifetime,在創建時分配資源,則在銷毀時釋放資源;往上一點還有Start與Stop一對,叫visible lifetime,表達的是可見與非可見這么一個過程;最頂上的就是Resume和Pause這一對了,叫foreground lifetime,表達的了是否處于激活狀態的過程。
4.因此,我們實現的Activity派生類,要重載兩個重要的方法:onCreate()進行初始化操作,onPause()保存當前操作的結果。
除了Activity Lifecycle以外,Android還有一個Process Lifecycle的說明:
在內存不足的時候,Android是會主動清理門戶的,那它又是如何判斷哪個process是可以清掉的呢?文檔中也提到了它的重要性排序:
1.最容易被清掉的是empty process,空進程是指那些沒有Activity與之綁定,也沒有任何應用程序組件(如Services或者IntentReceiver)與之綁定的進程,也就是說在這個process中沒有任何activity或者service之類的東西,它們僅僅是作為一個cache,在啟動新的Activity時可以提高速度。它們是會被優先清掉的。因此建議,我們的后臺操作,最好是作成Service的形式,也就是說應該在Activity中啟動一個Service去執行這些操作。
2.接下來就是background activity了,也就是被stop掉了那些activity所處的process,那些不可見的Activity被清掉的確是安全的,系統維持著一個LRU列表,多個處于background的activity都在這里面,系統可以根據LRU列表判斷哪些activity是可以被清掉的,以及其中哪一個應該是最先被清掉。不過,文檔中提到在這個已被清掉的Activity又被重新創建的時候,它的onCreate會被調用,參數就是onFreeze時的那個Bundle。不過這里有一點不明白的是,難道這個Activity被killed時,Android會幫它保留著這個Bundle嗎?
3.然后就輪到service process了,這是一個與Service綁定的進程,由startService方法啟動。雖然它們不為用戶所見,但一般是在處理一些長時間的操作(例如MP3的播放),系統會保護它,除非真的沒有內存可用了。
4.接著又輪到那些visible activity了,或者說visible process。前面也談到這個情況,被Paused的Activity也是有可能會被系統清掉,不過相對來說,它已經是處于一個比較安全的位置了。
5.最安全應該就是那個foreground activity了,不到迫不得已它是不會被清掉的。這種process不僅包括resume之后的activity,也包括那些onReceiveIntent之后的IntentReceiver實例。
在Android Application的生命周期的討論中,文檔也提到了一些需要注意的事項:因為Android應用程序的生存期并不是由應用本身直接控制的,而是由Android系統平臺進行管理的,所以,對于我們開發者而言,需要了解不同的組件Activity、Service和IntentReceiver的生命,切記的是:如果組件的選擇不當,很有可能系統會殺掉一個正在進行重要工作的進程。
啟動代碼混淆功能在較新版本的Android tools和ADT,項目工程里面是帶有proguard.cfg的代碼混淆配置文件,但默認是沒有啟動這個配置的,需要手動地在default.properties里面添加指定這個配置文件:# Project target. target=android-3 proguard.config=proguard.cfg 然后按F5刷新當前項目工程,這時候Eclipse檢測了文件的變動而重新編譯! 生成簽名發布apk1.Eclipse工程中右鍵工程,彈出選項中選擇 android工具-生成簽名應用包: 2.選擇需要打包的android項目工程(注:這里會自動選擇當前的Project的): 3.如果已有私鑰文件,選擇私鑰文件 輸入密碼,如果沒有私鑰文件見 第6和7步創建私鑰文件: 4.輸入私鑰別名和密碼: 5.選擇APK存儲的位置,并完成設置 開始生成: 6.沒有私鑰文件的情況,創建私鑰文件(注:這里私鑰文件的Location位置最好自己選擇一個新位置,便于牢記,而且最好把這個私鑰文件備份到其他地方去以免丟失,因為應用程序的更新需要同一私鑰文件): 7.輸入私鑰文件所需信息,并創建(注:這里的密碼是用于Key的別名的,和上面的KeyStore文件的不同,這點可以看步驟3和4。另外下面的名字,開發者資料等是不需要全部填寫的,dialog會有提示的): 這時候生成的apk,我發現是比debug版本的要小!如果你發現沒有變小的話,請確認項目工程是重新編譯的!但代碼混淆的效果一般般,基本上還是可以看到原來的語句!
摘要: android:allowTaskReparenting 用來標記Activity能否從啟動的Task移動到有著affinity的Task(當這個Task進入到前臺時)——“true”,表示能移動,“false”,表示它必須呆在啟動時呆在的那個Task里。 ... 閱讀全文
Apk簽名首先要有一個keystore的簽名用的文件. keystore是由jdk自帶的工具keytool生成的.具體生成方式參考一下: 開始->運行->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 然后按回車 按回車后首先會提示你輸入密碼:這個在簽名時要用的要記住了哦。 然后會再確認你的密碼。 之后會依次叫你輸入 姓名,組織單位,組織名稱,城市區域,省份名稱,國家代碼等。 參考:
運行完可以在 C:\Program Files\Java\jdk1.6.0_10\bin 里找到剛才生產的keyStore文件
好現在開始給Apk簽名了: 在 C:\Program Files\Java\jdk1.6.0_10\bin 還提供一個工具 jarsigner.exe 好現在可以在剛才的命令行后繼續運行以下命令給APK簽名: jarsigner -verbose -keystore asaiAndroid.keystore -signedjar LotteryOnline_signed.apk LotteryOnline.apk asaiAndroid.keystore -keystore:keystore 的名稱 LotteryOnline_signed.apk 是簽完名后的APK LotteryOnline.apk 是簽名前的apk 然后按回車:會要求輸入剛才設置的密碼,輸入后按回車就開始簽名了。 參考:
運行成功后在 C:\Program Files\Java\jdk1.6.0_10\bin 目錄下會多出一個被簽名的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語言中的反射機制: 在Java 運行時 環境中,對于任意一個類,能否知道這個類有哪些屬性和方法? 對于任意一個對象,能否調用他的方法?這些答案是肯定的,這種動態獲取類的信息,以及動態調用類的方法的功能來源于JAVA的反射。從而使java具有動態語言的特性。 JAVA反射機制主要提供了以下功能:&n... 閱讀全文
1、匯編語言 2、解釋性語言-------運行慢,沒解釋一行,運行一行 3、編譯性語言-------直接編譯成目標程序,再運行
下載的TomCat免安裝版在啟動時的問題,在啟動的時候運行P處理的時候,會出現閃一下就消失的現象,
配置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>標簽的上面加上
<Context path="/test" docBase="E:\javaWeb\Test\WebRoot" reloadable="true" /> 這句話
http://video.sina.com.cn/playlist/3545082-1349419557-1.html#25689407
1.1內存分配方面:
堆:一般由程序員分配釋放,若程序員不釋放,程序結束時可能由OS回收 。注意它與數據結構中的堆是兩回事,分配方式是類似于鏈表。可能用到的關鍵字如下:new、malloc、delete、free等等。
棧:由編譯器(Compiler)自動分配釋放,存放函數的參數值,局部變量的值等。其操作方式類似于數據結構中的棧。
1.2申請方式方面:
堆:需要程序員自己申請,并指明大小。在c中malloc函數如p1 = (char *)malloc(10);在C++中用new運算符,但是注意p1、p2本身是在棧中的。因為他們還是可以認為是局部變量。
棧:由系統自動分配。 例如,聲明在函數中一個局部變量 int b;系統自動在棧中為b開辟空間。
1.3系統響應方面:
堆:操作系統有一個記錄空閑內存地址的鏈表,當系統收到程序的申請時,會遍歷該鏈表,尋找第一個空間大于所申請空間的堆結點,然后將該結點從空閑結點鏈表中刪除,并將該結點的空間分配給程序,另外,對于大多數系統,會在這塊內存空間中的首地址處記錄本次分配的大小,這樣代碼中的delete語句才能正確的釋放本內存空間。另外由于找到的堆結點的大小不一定正好等于申請的大小,系統會自動的將多余的那部分重新放入空閑鏈表中。
棧:只要棧的剩余空間大于所申請空間,系統將為程序提供內存,否則將報異常提示棧溢出。
1.4大小限制方面:
堆:是向高地址擴展的數據結構,是不連續的內存區域。這是由于系統是用鏈表來存儲的空閑內存地址的,自然是不連續的,而鏈表的遍歷方向是由低地址向高地址。堆的大小受限于計算機系統中有效的虛擬內存。由此可見,堆獲得的空間比較靈活,也比較大。
棧:在Windows下, 棧是向低地址擴展的數據結構,是一塊連續的內存的區域。這句話的意思是棧頂的地址和棧的最大容量是系統預先規定好的,在WINDOWS下,棧的大小是固定的(是一個編譯時就確定的常數),如果申請的空間超過棧的剩余空間時,將提示overflow。因此,能從棧獲得的空間較小。
1.5效率方面:
堆:是由new分配的內存,一般速度比較慢,而且容易產生內存碎片,不過用起來最方便,另外,在WINDOWS下,最好的方式是用VirtualAlloc分配內存,他不是在堆,也不是在棧是直接在進程的地址空間中保留一快內存,雖然用起來最不方便。但是速度快,也最靈活。
棧:由系統自動分配,速度較快。但程序員是無法控制的。
1.6存放內容方面:
堆:一般是在堆的頭部用一個字節存放堆的大小。堆中的具體內容有程序員安排。
棧:在函數調用時第一個進棧的是主函數中后的下一條指令(函數調用語句的下一條可執行語句)的地址然后是函數的各個參數,在大多數的C編譯器中,參數是由右往左入棧,然后是函數中的局部變量。 注意: 靜態變量是不入棧的。當本次函數調用結束后,局部變量先出棧,然后是參數,最后棧頂指針指向最開始存的地址,也就是主函數中的下一條指令,程序由該點繼續運行。
1.7存取效率方面:
堆:char *s1 = "Hellow Word";是在編譯時就確定的;
棧:char s1[] = "Hellow Word"; 是在運行時賦值的;用數組比用指針速度要快一些,因為指針在底層匯編中需要用edx寄存器中轉一下,而數組在棧上直接讀取。
小結
1、靜態變量不入棧。
2、棧由編譯器自動分配和釋放。棧中存放局部變量和參數,函數調用結束后,局部變量先出棧,然后是參數。
3、數組比用指針速度要快一些,因為指針在底層匯編中需要用edx寄存器中轉一下,而數組在棧上直接讀取。
4、堆是由程序員通過new、malloc、free、delete等指令進行分配和釋放。如果程序員沒有進行釋放,程序結束時可能有OS回收。
5、堆是由new分配的內存,速度較慢;棧是由系統自動分配,速度較快。
6、比如存放在棧里面的數組,是在運行時賦值。而存在堆里面的指針數據,是在編譯時就確定的。
附:
一. 在c中分為這幾個存儲區
1.棧 - 由編譯器自動分配釋放
2.堆 - 一般由程序員分配釋放,若程序員不釋放,程序結束時可能由OS回收
3.全局區(靜態區),全局變量和靜態變量的存儲是放在一塊的,初始化的全局變量和靜態變量在一塊區域,未初始化的全局變量和未初始化的靜態變量在相鄰的另一塊區域。- 程序結束釋放
4.另外還有一個專門放常量的地方。- 程序結束釋放
在函數體中定義的變量通常是在棧上,用malloc, calloc, realloc等分配內存的函數分配得到的就是在堆上。在所有函數體外定義的是全局量,加了static修飾符后不管在哪里都存放在全局區(靜態區),在所有函數體外定義的static變量表示在該文件中有效,不能extern到別的文件用,在函數體內定義的static表示只在該函數體內有效。另外,函數中的"adgfdf"這樣的字符串存放在常量區。比如:
int a = 0; //全局初始化區
char *p1; //全局未初始化區
void main()
{
int b; //棧
char s[] = "abc"; //棧
char *p2; //棧
char *p3 = "123456"; //123456{post.content}在常量區,p3在棧上
static int c = 0; //全局(靜態)初始化區
p1 = (char *)malloc(10); //分配得來得10字節的區域在堆區
p2 = (char *)malloc(20); //分配得來得20字節的區域在堆區
strcpy(p1, "123456");
//123456{post.content}放在常量區,編譯器可能會將它與p3所指向的"123456"優化成一塊
}

二.在C++中,內存分成5個區,他們分別是堆、棧、自由存儲區、全局/靜態存儲區和常量存儲區
1.棧,就是那些由編譯器在需要的時候分配,在不需要的時候自動清楚的變量的存儲區。里面的變量通常是局部變量、函數參數等。
2.堆,就是那些由new分配的內存塊,他們的釋放編譯器不去管,由我們的應用程序去控制,一般一個new就要對應一個delete。如果程序員沒有釋放掉,那么在程序結束后,操作系統會自動回收。
3.自由存儲區,就是那些由malloc等分配的內存塊,他和堆是十分相似的,不過它是用free來結束自己的生命的。
4.全局/靜態存儲區,全局變量和靜態變量被分配到同一塊內存中,在以前的C語言中,全局變量又分為初始化的和未初始化的,在C++里面沒有這個區分了,他們共同占用同一塊內存區。
5.常量存儲區,這是一塊比較特殊的存儲區,他們里面存放的是常量,不允許修改(當然,你要通過非正當手段也可以修改)
三. 談談堆與棧的關系與區別
具體地說,現代計算機(串行執行機制),都直接在代碼底層支持棧的數據結構。這體現在,有專門的寄存器指向棧所在的地址,有專門的機器指令完成數據入棧出棧的操作。這種機制的特點是效率高,支持的數據有限,一般是整數,指針,浮點數等系統直接支持的數據類型,并不直接支持其他的數據結構。因為棧的這種特點,對棧的使用在程序中是非常頻繁的。對子程序的調用就是直接利用棧完成的。機器的call指令里隱含了把返回地址推入棧,然后跳轉至子程序地址的操作,而子程序中的ret指令則隱含從堆棧中彈出返回地址并跳轉之的操作。C/C++中的自動變量是直接利用棧的例子,這也就是為什么當函數返回時,該函數的自動變量自動失效的原因。
和棧不同,堆的數據結構并不是由系統(無論是機器系統還是操作系統)支持的,而是由函數庫提供的。基本的malloc/realloc/free 函數維護了一套內部的堆數據結構。當程序使用這些函數去獲得新的內存空間時,這套函數首先試圖從內部堆中尋找可用的內存空間,如果沒有可以使用的內存空間,則試圖利用系統調用來動態增加程序數據段的內存大小,新分配得到的空間首先被組織進內部堆中去,然后再以適當的形式返回給調用者。當程序釋放分配的內存空間時,這片內存空間被返回內部堆結構中,可能會被適當的處理(比如和其他空閑空間合并成更大的空閑空間),以更適合下一次內存分配申請。這套復雜的分配機制實際上相當于一個內存分配的緩沖池(Cache),使用這套機制有如下若干原因:
1. 系統調用可能不支持任意大小的內存分配。有些系統的系統調用只支持固定大小及其倍數的內存請求(按頁分配);這樣的話對于大量的小內存分類來說會造成浪費。
2. 系統調用申請內存可能是代價昂貴的。系統調用可能涉及用戶態和核心態的轉換。
3. 沒有管理的內存分配在大量復雜內存的分配釋放操作下很容易造成內存碎片。
堆和棧的對比
從以上知識可知,棧是系統提供的功能,特點是快速高效,缺點是有限制,數據不靈活;而棧是函數庫提供的功能,特點是靈活方便,數據適應面廣泛,但是效率有一定降低。棧是系統數據結構,對于進程/線程是唯一的;堆是函數庫內部數據結構,不一定唯一。不同堆分配的內存無法互相操作。棧空間分靜態分配和動態分配兩種。靜態分配是編譯器完成的,比如自動變量(auto)的分配。動態分配由alloca函數完成。棧的動態分配無需釋放(是自動的),也就沒有釋放函數。為可移植的程序起見,棧的動態分配操作是不被鼓勵的!堆空間的分配總是動態的,雖然程序結束時所有的數據空間都會被釋放回系統,但是精確的申請內存/ 釋放內存匹配是良好程序的基本要素。
1.碎片問題:對于堆來講,頻繁的new/delete勢必會造成內存空間的不連續,從而造成大量的碎片,使程序效率降低。對于棧來講,則不會存在這個問題,因為棧是先進后出的隊列,他們是如此的一一對應,以至于永遠都不可能有一個內存塊從棧中間彈出,在他彈出之前,在他上面的后進的棧內容已經被彈出,詳細的可以>參考數據結構,這里我們就不再一一討論了。
2.生長方向:對于堆來講,生長方向是向上的,也就是向著內存地址增加的方向;對于棧來講,它的生長方向是向下的,是向著內存地址減小的方向增長。
3.分配方式:堆都是動態分配的,沒有靜態分配的堆。棧有2種分配方式:靜態分配和動態分配。靜態分配是編譯器完成的,比如局部變量的分配。動態分配由alloca函數進行分配,但是棧的動態分配和堆是不同的,他的動態分配是由編譯器進行釋放,無需我們手工實現。
4.分配效率:棧是機器系統提供的數據結構,計算機會在底層對棧提供支持:分配專門的寄存器存放棧的地址,壓棧出棧都有專門的指令執行,這就決定了棧的效率比較高。堆則是C/C++函數庫提供的,它的機制是很復雜的,例如為了分配一塊內存,庫函數會按照一定的算法(具體的算法可以參考數據結構/操作系統)在堆內存中搜索可用的足夠大小的空間,如果沒有足夠大小的空間(可能是由于內存碎片太多),就有可能調用系統功能去增加程序數據段的內存空間,這樣就有機會分到足夠大小的內存,然后進行返回。顯然,堆的效率比棧要低得多。
明確區分堆與棧:
在bbs上,堆與棧的區分問題,似乎是一個永恒的話題,由此可見,初學者對此往往是混淆不清的,所以我決定拿他第一個開刀。
首先,我們舉一個例子:
void f()
{
int* p=new int[5];
}

這條短短的一句話就包含了堆與棧,看到new,我們首先就應該想到,我們分配了一塊堆內存,那么指針p呢?他分配的是一塊棧內存,所以這句話的意思就是:在棧內存中存放了一個指向一塊堆內存的指針p。在程序會先確定在堆中分配內存的大小,然后調用operator new分配內存,然后返回這塊內存的首地址,放入棧中,他在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
這里,我們為了簡單并沒有釋放內存,那么該怎么去釋放呢?是delete p么?澳,錯了,應該是delete []p,這是為了告訴編譯器:我刪除的是一個數組,VC6就會根據相應的Cookie信息去進行釋放內存的工作。
好了,我們回到我們的主題:堆和棧究竟有什么區別?
主要的區別由以下幾點:
1、管理方式不同;
2、空間大小不同;
3、能否產生碎片不同;
4、生長方向不同;
5、分配方式不同;
6、分配效率不同;
管理方式:對于棧來講,是由編譯器自動管理,無需我們手工控制;對于堆來說,釋放工作由程序員控制,容易產生memory leak。
空間大小:一般來講在32位系統下,堆內存可以達到4G的空間,從這個角度來看堆內存幾乎是沒有什么限制的。但是對于棧來講,一般都是有一定的空間大小的,例如,在VC6下面,默認的棧空間大小是1M(好像是,記不清楚了)。當然,我們可以修改:
打開工程,依次操作菜單如下:Project->Setting->Link,在Category 中選中Output,然后在Reserve中設定堆棧的最大值和commit。
注意:reserve最小值為4Byte;commit是保留在虛擬內存的頁文件里面,它設置的較大會使棧開辟較大的值,可能增加內存的開銷和啟動時間。
堆和棧相比,由于大量new/delete的使用,容易造成大量的內存碎片;由于沒有專門的系統支持,效率很低;由于可能引發用戶態和核心態的切換,內存的申請,代價變得更加昂貴。所以棧在程序中是應用最廣泛的,就算是函數的調用也利用棧去完成,函數調用過程中的參數,返回地址,EBP和局部變量都采用棧的方式存放。所以,我們推薦大家盡量用棧,而不是用堆。
另外對存取效率的比較:
代碼:
char s1[] = "aaaaaaaaaaaaaaa";
char *s2 = "bbbbbbbbbbbbbbbbb";
aaaaaaaaaaa是在運行時刻賦值的;
而bbbbbbbbbbb是在編譯時就確定的;
但是,在以后的存取中,在棧上的數組比指針所指向的字符串(例如堆)快。
比如:
void main()
{
char a = 1;
char c[] = "1234567890";
char *p ="1234567890";
a = c[1];
a = p[1];
return;
}
對應的匯編代碼
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
第一種在讀取時直接就把字符串中的元素讀到寄存器cl中,而第二種則要先把指針值讀到edx中,在根據edx讀取字符,顯然慢了.
無論是堆還是棧,都要防止越界現象的發生(除非你是故意使其越界),因為越界的結果要么是程序崩潰,要么是摧毀程序的堆、棧結構,產生以想不到的結果,就算是在你的程序運行過程中,沒有發生上面的問題,你還是要小心,說不定什么時候就崩掉,編寫穩定安全的代碼才是最重要的
android 的短信數據庫的讀取
android短信的數據庫的Uri是不公開的, 讀取起來時灰常不方便的, 這里做了下總結.
用adb指令將mmssms.db從/data/data/com.android.providers.telephony/databases中pull出來
經常使用到的表有
canonical_addresses, sms, threads三個表格
sms是存儲著所有的短信, 主要的列有_id, thread_id, address, person, date, read, type, body
關于的sms的Uri有
發件箱 content://sms/outbox
收件箱 content://sms/inbox
草稿箱 content://sms/draft
conversations content://sms/conversations
threads表存儲著每一個短信對話的線程. 主要列有_id, date, message_count, recipient_ids, snippet, read
recipient_ids 存放的是參與此次對話的person的id, 然而這個id不是通訊錄里面的id, 而是canonical_addresses 的id. 這就是canonical_addresses 表格的作用
threads 表 uri: content://mms-sms/conversations?simple=true
canonical_addresses 表 uri content://mms-sms/canonical-addresses
|