eoeandroid特25第二十五期應(yīng)用終端適配

一.APP性能之終端兼容優(yōu)化——by二.APP性能之終端兼容優(yōu)化——by詩帆三.APP性能之終端兼容優(yōu)化——by承影四.APP性能之終端兼容優(yōu)化——by游戲五.APP性能之終端兼容優(yōu)化——bycangely六.APP性能之終端兼容優(yōu)化——by七.APP性能之終端兼容優(yōu)化——八.APP性能之終端兼容優(yōu)化——bytangke300九.APP性能之終端兼容優(yōu)化——by冰靈十.APP性能之終端兼容優(yōu)化——byyava555十一.APP性能之終端兼容優(yōu)化——by沒文化十二.APP性能之終端兼容優(yōu)化——byChengChangmu十三.APP性能之終端兼容優(yōu)化——byhoushijie3十四.APP性能之終端兼容優(yōu)化——by離開十五.APP性能之終端兼容優(yōu)化——bysfshine十六.APP性能之終端兼容優(yōu)化——byyado十七.APP性能之終端兼容優(yōu)化——by1：Android多屏幕適配介紹附錄2：Android屏幕適配戶們在擁有了終端選擇的同時，卻很少有人會知道開發(fā)APP的程序員們?yōu)榇烁冻龅男乃帷狝ndroid的 用能正常運行在的終端設(shè)備上。Geek行動-APP性能終極優(yōu)化之如何提高終端適配率》活動中的一段宣“Android太碎片！終端千千萬，俺們程序猿and程序媛好辛辛苦苦勤勤懇懇熬夜玩命開發(fā)一個APP，除了想創(chuàng)意搞美工，尼瑪還要去看市面上那些終端能不能安裝的了，如果大部分能裝，那就算對苦的奮斗有了一個絲應(yīng)該有的“但是現(xiàn)實很骨感，只有一個：那就是，沒有哪個Android系統(tǒng)上的APP所以本期特將針對android碎片化而產(chǎn)生的如何解決終端適配優(yōu)化問題。特內(nèi)所用文章主要來自活動所產(chǎn)生的優(yōu)秀內(nèi)容，最大程度的保留了社區(qū)網(wǎng)友們作品的原汁原味，故讀者們特最后一部分附錄為社區(qū)特約Android開發(fā)大神留有同學(xué)為大家精心準(zhǔn)備的大禮，內(nèi)容主要采自Android，精心翻譯而成。在此向留有的大力支持表示感謝！本期特在校稿階段得到了eoe社區(qū)團隊諸位熱心網(wǎng)友的指正，因為人數(shù)太多，在此一 往期特地址 eoandroid開發(fā)者社區(qū)活躍會員，現(xiàn)在在一家剛起步的軟件公司擔(dān)任軟件工程師，ndrod應(yīng)用開發(fā)，其實是個菜鳥，會的東西不是很多，但自認(rèn)為Jaa的面向?qū)ο笤O(shè)計思想和VC計想，對設(shè)模感，以直在持也一在慢看過《三個傻瓜》之后，有一種信念讓擁有一技之長，在一次偶然的機會中后來，2011年下半年開始學(xué)Android，再然后，就一直到了現(xiàn)在！承影，山東，在校大三學(xué)生黨一枚。主修java語言。有扎實的java基礎(chǔ)和優(yōu)秀的設(shè)計 作安卓，一度夢想成為很牛的android程序員，常進取，愛學(xué)習(xí)，本文 豬豬,想必你也知道,Android平臺的終端至少有千種之多,各個版本的系統(tǒng)都有,2次開發(fā)改造的系統(tǒng),版本確實不少；而且分辨率也相當(dāng)分散,并不像哪么集中.2、Android的解決方案.3、與ScrollView的結(jié)合.6、9patch工具的使用.在3個drawable文件夾下面分別放置高密度、中等密度和低密度的此外,需要說明的是：可以只在文件夾drawable_hdpi下面放置一密度的 ,進行放大操作,會顯的很模糊.謝謝.注：工程test_demo_01的源代碼見附件.testdemo01.zip(6.55MB,按住ctrl點 接下來開始在layout文件夾中設(shè)計布局.<LinearLayoutxmlns:android="http://s android:orientation="vertical">android:text="與ScrollView結(jié)合的布局"/>>附源代碼testdemo02.zip(1.71MB,按住ctrl點 采用HTML5和CSS3制作界面,然后在WebView視圖上進行顯示,然后通過JavaScript進行的交互是一<metaname="viewportcontent="width=deviceuser-scalable=0；"2、可以設(shè)置不同的CSS級聯(lián)樣式表,來適應(yīng)不同寬度的屏幕.HTMLUI.zip(103.68KB,按住ctrl點 該屬性的作用是決定控件在其父布局中的顯示權(quán)重,一般用于線性布局中.其值越小,則對應(yīng)的layout_widthlayout_height的優(yōu)先級就越高,一般橫向布局中,決定的是layout_width的優(yōu)先級；縱向布局中,決定的是layout_height的優(yōu)先級.先看下面的styles(style_layout.xml)<style<item<item<style<item<item<!--<item<!--<item<LinearLayoutxmlns:android="http://s 整個界面布局看起來非常直觀,只是嵌套的邏輯要自己理下.顯示效果如下圖,480x800的界面,320x480的界面(后面的圖也如此),可以看出顯示比例和代碼中完全一致,我就不多說了,大家對照下部分屏幕的寬度或高度都是80的整數(shù)倍(個別特殊的除外),不同的等分在不同的分辨率中設(shè)定不同的尺寸值.<LinearLayoutxmlns:android="http://s margin這樣的值也用到了自定義尺寸,如果這個marginlayout_weight來控制的話,無疑要多嵌套一層線性布局,所以說沒有一個方法是十全十美的,這第2個方法有時候用起來反而還要方便一些)也許很多人會這種方法,因為即使是也是推薦使用xml的方式寫布局.不過我們在這不會像Swing那樣寫那么多麻煩的布局代碼,因為我們只是在代碼中重新設(shè)定控件的寬高度而已,xml布publicclassConstantpublicstaticintdisyWidth;//屏幕寬度publicstaticintdisyHeight;//屏幕高度}DisyMetricsdisyMetrics=newDisyMetrics();Constant.disyWidth=disyMetrics.widthPixels;Constant.disyHeight=disyMetricsheightPixels;<LinearLayoutxmlns:android="http://s //第一個按鈕,寬度100%,高度10%LinearLayout.LayoutParamsparams=new(int)(Constant.disyHeight*0.1f+0.5f));//第二個按鈕,寬度100%,高度30%LinearLayout.LayoutParamsparams2=new(int)(Constant.disyHeight*0.3f+0.5f));LinearLayout.LayoutParamsparams3=newLinearLayout.LayoutParams((int)(Constant.disyWidth*0.5f+0.5f),(int)(Constant.disyHeight*0.2f+0.5f));//LinearLayout.LayoutParamsparams4=newLinearLayout.LayoutParams((int)(Constant.disyWidth*0.7f+0.5f),本文 的的QVGA=320*WQVGA=320*WQVGA2=400*WQVGA3=432*HVGA=480*VGA=640*WVGA=800*WVGA2=768*FWVGA=854*DVGA=960*PAL=576*NTSC=486*SVGA=800*Web網(wǎng)頁開發(fā)計意圖,這個前提是布局里的單位是dip。也算是一種創(chuàng)意吧。layout_weightlayout_weight值，默認(rèn)為零，意思是需要顯示多大的視圖就占據(jù)多大的屏幕空間。若賦個高于零的值，則將父視圖中的可用空layout_weightlayout_weight值和在其它視圖屏幕布局的layout_weightlayout_widthfill_parent時，對于一個組件，layout_weightfill_parent。的寬度相對于其它組件越小。但最小不小于wrap_content。androidHTML5CSS3WebView視圖上進行顯示，然后通過而且現(xiàn)在已經(jīng)有比較成開發(fā)平臺使用HTML5+CSS3+JavaScript+Rexsee擴展的API。其號稱即使不神奇的是現(xiàn)在的JQuery也出了 androidwebjQuery。力挺?。。⌒圆攀莂pp的王道啊。inflateActivity中布局是個有性能消耗的過程。每增加一個嵌套的布局和視圖都會對應(yīng)用的性能造都不要在一個布局中包含超過80個視圖，否則，消耗在inflate操作上的時間會很大。套限制在10層以下是好的實踐。 以下是網(wǎng)友總結(jié)的三星i9100運行游戲時候出現(xiàn)的情況：)))《速度與5》(FastandFurious5)——看到標(biāo)題畫面后就退《達》(Avatar)——所有物體都變成白)))《之城》(Gangster)——所有物體都變成白)))本文 很多人都嘗試在屏幕設(shè)配上,找出一條通用的解決方案,可惜的是,就算是也沒法提供這樣的幫助,更別說我們這些苦的程序員,這里有個小故事,大家都知道,android版吧,有個采訪,的初始人就說,天收到最多的用戶反饋就是為什么不能在他的android上運行,但是,我已經(jīng)設(shè)配了幾百個android幕！買可沒有人會說”你好,我要一個Normal大幕,密度最好是hdpi的”.這是一個幫助我們優(yōu)化view的非常重要的工具的,接下來的大部分時間,都會借住這個工具進行講解,這個工具沉睡在androidsdk tools下hierarchyviewer.bat,或者用Everything這樣的搜索硬盤的工具直接找到！這么一就是我們一個o,World項目的View布局結(jié)構(gòu),在HierarchyViewer上你點擊每個按鈕就會有非常詳細的布局信息,所以,hierarchyViewer的介紹到此為止!關(guān)于這個工具的詳細使用,DebuggingandProfilingUserInterfaces這里不做贅述！應(yīng)該是每個android開發(fā)程序員的！！android:gravity="center"><Buttonandroid:id="@+id/button1"android:layout_width="wrap_content"android:text="@string/back"/><ImageViewandroid:id="@+id/imageView1"android:layout_width="wrap_content"android:src="@drawable/header_back"/>我們從這個圖中,我們可以看到,view的三個節(jié)點去完成!假設(shè),view個人建議,常用的Widget的所有參數(shù)都盡量了解一遍!在閱讀文檔的時候我們發(fā)現(xiàn)了Button,有一個可以<Buttonandroid:id="@+id/button1"android:layout_width="wrap_content"android:layout_height="wrap_content"android:background="@drawable/btn_headtita"android:text="@string/back"android:textColor="#ffffff"/>3N級復(fù)雜度的布局,變成了一個N級復(fù)雜的!所以,我建議各位android開發(fā)朋友,在考慮優(yōu)化的時候先把api文檔里面的內(nèi)容爛熟與心,不然,這樣折騰下去,很浪費時間! 所謂,模塊化布局就是要你熟悉使用<include/>這個 <LinearLayoutxmlns:android="http://s /apk/res/android"android:layout_width="fill_parent"android:layout_height="fill_parent"android:orientation="vertical">在高效布局里面,有一條準(zhǔn)則就是,盡量的減少節(jié)點!!!!如同,我們發(fā)現(xiàn),其實LinearLayout其實啥都沒干,我們卻 <Buttonandroid:id="@+id/button1"android:layout_width="wrap_content"android:drawableLeft="@drawable/header_back"android:gravity="center"android:layout_gravity="center_vertical|center_horizontal"android:padding="10dp"android:text="@string/back"android:textColor="#ffffff"/>講了,這么一大堆東西,貌似,沒怎么如何去優(yōu)化?都是在說一些操作性的東西,其實,這世上沒有優(yōu)化方減少復(fù)雜度,往往,兼容問題的出現(xiàn),就是布局太復(fù)雜了,例如,我舉的那個按鈕布局,本來一個View就能完成,view完成,在使用的時候,出現(xiàn)問題的概率也大幅度提升!所以,布局以簡單為本,那樣兼容問題就可本文 這是關(guān)于不同分辨率的Android設(shè)備的適配的一些個人想法,歡迎拍磚.另外,所有的組件都沒有寫在XML布局文件中,都是java代碼創(chuàng)建的.1,使界面看起來合理,沒有不合常理的情況出現(xiàn).由于android系統(tǒng)自動適配的不確定性,可能使畫面出現(xiàn)的錯誤,比如下面圖中的錯誤,木牌本應(yīng)掛在柱子上,在自動適配中可能出現(xiàn)這種情況,這就是不合常理的情況,也是必須要避免的.2,使界面看起來更舒服.界面的元素不能有變形,各個元間的距離和元素在屏幕的坐標(biāo)位置也要設(shè)計合理.由于之前的項目用到的太多,如果考慮高、中、低三種分辨率用各自的,雖然適配稍微容易些,但會使最終的APK臃腫無比,所以我考慮的就是使用一套,來適配所有的分辨率.適配不應(yīng)該僅僅是技術(shù)方面的工作.產(chǎn)品策劃/UI的設(shè)計,技術(shù)負責(zé)實現(xiàn),這似乎沒有什么太多可講的東西.但是如果在項目正式開發(fā)初期,能夠確定UI的基本方案,就可以在適配這個環(huán)節(jié)上節(jié)省大量的工作時間.接上一步,兩個問題可以這樣解決.將柱子和3個木牌看成一個整體,確定他們的位置關(guān)系,最好能用矩形表現(xiàn)出來.這三個等高的小矩形,每個矩形居中放一個木牌,這樣就形成了一個整體.在適配時,僅對這個整體的坐標(biāo)位置和寬高尺寸做調(diào)整,在任何分辨率中都不會出現(xiàn)木牌沒有掛在柱子上的錯誤.UI修改時,應(yīng)該在修改方案確定后,由產(chǎn)品經(jīng)理/策劃/美工盡快提供需要修改的坐標(biāo)值,例本文 Andorid的特性注定了我們開發(fā)者要為其在各種終端上的兼容傷透腦筋,但任其終端兼容再復(fù)雜再麻煩,作為幕相對角測量得出,為了簡單起見,android將其定義為四種屏幕大?。簊mall,normal,large,andextralarge.屏幕密義成四種：ldpi,mdpi,hdpi,andxhdpi.低密度(ldpi中密度(mdpi高密度(hdpi(320xhdpi)幕QVGAHVGAWXGA且傳統(tǒng)意義我們也將這幾種分辨率的屏幕作為其所代表的dpi的屏,也就意味這我們?nèi)绻m配這幾種屏,會適配80%左右的機器.對于界面如何設(shè)計我沒有多少發(fā)言權(quán),UE設(shè)計的界面,好的界面咱就不說了,我觀,但是給適配帶來了極大的,因為很容易出現(xiàn)線與線接不上的問題,雖然最終還是解決這些問題,但卻花費了大量精力在微調(diào)布局上.所以說好的界面設(shè)計可以讓以后的適配事半功倍.至于怎么設(shè)計界面,詳見/design/index.html.確的解釋,個人感覺以MDPI為基準(zhǔn)有兩點好處(個人觀點)：更容易確定大小,因為在這個dpi下的dp=px(像素、dp轉(zhuǎn)化：px=dp*(dpi/160)),畢竟美工是理與LDPI為基準(zhǔn)就有可能在HDPI上正文部分顯示區(qū)域又過大.在android適配中像素其實是很不靠譜的,而dpsp一般情況下比較適用,因為是比例單位,并且盡量在一開可能不止一個人9.png的使用,的確它是非常好用的,不僅可以降低的大小,而且可以在適配中做到相當(dāng)好的作用,因為它可以指定拉伸的區(qū)域,具體怎么做9.png網(wǎng)上一大堆,就不細說了.一開始我就說每個人有適合每個人的兼容,這個屬性對于那些喜歡相對布局的人可能用處不大了,但是喜歡線性布局的人,可以說是適配的layout_weight="1"和layout_width="fill_parent",這樣主要固定住選項卡與底層狀態(tài)欄中間部分是自適應(yīng)的.<LinearLayoutxmlns:android="http://s android:orientation="vertical"android:layout_width="fill_parent"android:layout_height="fill_parent"android:background="#ffffff"><LinearLayoutandroid:orientation="horizontal"android:layout_height="fill_parent"android:layout_weight="1"/>android:layout_height="fill_parent"android:layout_weight="1"/>android:layout_height="fill_parent"android:layout_weight="1"/><LinearLayoutandroid:orientation="horizontal"android:layout_weight="1"android:background="#ff00ff"><LinearLayoutandroid:orientation="horizontal"起到了很大的作用,并且在適配與平板之間也有類似的功能,因為我們可以將布局組裝成一套新的布局來適配平板,這和4.0上的fragment設(shè)計思想是很像的.不要在代碼中選擇使用單位,最好在資源中配置,但是如果一定得使用,dpdp其轉(zhuǎn)換成像素來使intpxValue=(int)(dpValue*scale+0.5f);DisyMetricsdm=newDisyMetrics();intwidth=dm.widthPixels;前7步都是對傳統(tǒng)意義上的屏幕適配的做法,但有了前7步并不一定可以真正適配所有機器,這就需要我們在對特殊屏幕時需要做特殊的處理,具體做法可能最終還是得寫一些相對應(yīng)的布局,放在相對應(yīng)的layout下.本文 我原來做過幾個軟件,都遇到過兼容和分辨率問題,我用的機子是HTCONEX我家里人全部都是用的android(被我強制買的安卓,嘿嘿),其實也有私心,就是為了測試各種軟件,我家里每個人的的分辨率2,建立好文件夾后,每個文件會對應(yīng)一個分辨率,你需要對每個layout文件夾里的大小,位置,等一切3,如果上面的兩步你都做好了,先別忙運行,AndroidManifest.xml里加上下面這段代碼才能起作用,不<supports-screensandroid:anyDensity="true"android:largeScreens="true"android:normalScreens="true"android:smallScreens="true"/>下面再對大家一個軟件優(yōu)化的建議(其實也算不上市優(yōu)化,就是減輕軟件大小的方法而已),當(dāng)一個成功的作品的時候,肯定會少不了有很多的,素材,和一些音頻文件,但是如果放在drawabe里,會大大加深打包后軟件的大小,所以建議大家把能放在網(wǎng)上的,盡量放在網(wǎng)上,(這里僅限單獨的開發(fā)者,公司開發(fā)者我這里就不說了,我都是剛學(xué)習(xí),還沒那個能力,呵呵),然后從網(wǎng)絡(luò)上出來再顯示在程序上,關(guān)于網(wǎng)絡(luò)在搜一下,一大把的！好了,到這里就完了,上面的一些如果有錯誤或不足的歡迎高手回帖補充,android沒多久,大家互本文 Android設(shè)備適配.對開發(fā)者來說,也是除了應(yīng)用邏輯以外需要重點考慮的一個重要因素.因為這點將會直接影響到用戶對應(yīng)用的印象和體驗.對此也出了很多應(yīng)對措施來解決Android的碎片化.①這點也許這是開發(fā)者遇到的最頭疼的問題,Android,轉(zhuǎn)投其他平臺.其實這點并不可怕,為我們提供了很多resourcequalifier來解決此問題.根據(jù)不同分辨率,不同系統(tǒng)版本,不同屏幕尺寸,不同屏幕方向,不同語言,不同地區(qū),UI的模式,sim卡也能匹配,具體請看下面resources.html都是對適配很有用的),詳情見:/guide/topics/resources/drawable-resourcehtml<shape UI資源圖,針對不同分辨率的屏幕drawable-ldpi,drawable-mdpi,drawable-hdpi是最常見的分辨率的.mdpi的設(shè)備用hdpi的資源,這樣會造成消耗大量的內(nèi)存,mdpi的設(shè)備都硬件配置都不layoutLinearLayout時,Viewandroid:layout_weight來自動排布,也是一個用作自適應(yīng)不錯的選擇.就如下面代碼:<LinearLayoutxmlns:android="http://s /apk/res/android"android:layout_width="fill_parent"android:layout_height="fill_parent">當(dāng)LinearLayout的android:orientation為horizontal時別忘了將含layout_weight屬性的子View的layout_width0dp.vertical時,layout_weight屬性的子Viewlayout_height0dp,這樣可以減少LinearLayout在onMeasure時計算量.①說到版本兼容性,第一個想到的就要是用低版本sdk開發(fā),這樣在所有高于設(shè)備上正常運行.但是有個弊端就是無法使用Android高版本提供新特性.于是這個時候"AndroidCompatibilitypackage"就出場了,這個library是為低版本提供一些兼容高版本的特性,如Fragment,Vie ger等等,開發(fā)者可以在低版本的系統(tǒng)使用高版本的特性..androidminSdkVersion,android:minSdkVersion很好理解,就是該應(yīng)用支持的最低apilevel的設(shè)備,android:targetSdkVersion則是用來區(qū)分是使用" 比如上面的代碼,就是最低版本是apilevel7(Android2.1),apilevel低于11(Android3.0)就使用"AndroidCompatibilitypackage"提供的兼容類(Fragment),11(Android3.0)就使用3.0提供的.②還有個版本兼容性能用到的就是Java提供的反射機制,這樣也可以使開發(fā)者的應(yīng)用在某個方法可用的時候進行調(diào)用.這個可以通過查詢開檔進行查詢.流程看下圖:當(dāng)然針對某些實例變量也能通過反射來改變,這個就需要去查詢源碼,不推薦UI①layoutopt-曾經(jīng)作為獨立的app于sdk/tools 中,高版本的sdk將他集成到ADT中了.主要功能檢測你編寫的layout中哪些View是無用的,哪些是可以兩個合并到一個,達到相同的UI效果的.該工具報出如下警告.以便于開發(fā)者修改.具體大家可以下這個工具的用法5:22Theroot-level<FrameLayout/>canberecedwith<merge/>10:21ThisLinearLayoutlayoutoritsFrameLayoutparentisuseless-1:-1Thislayouthastoomanyviews:83views,itshouldhave<=,②hierarchyviewer-該工具位于sdk/tools 中.可以幫助開發(fā)查看自己應(yīng)用View的結(jié)構(gòu)和嵌套的層次,View,已經(jīng)層級關(guān)系.開發(fā)者可以通過點擊節(jié)點來獲取此節(jié)點的當(dāng)前狀態(tài)圖,同時節(jié)點下會有三個可能是紅黃綠的圓點,分別表示你的這個View在measure,layout,draw所消耗的時間和其他50%View作對比.就如生活中的紅黃綠燈一樣的效果.綠色當(dāng)然最好.①說到代碼優(yōu)化,這兒是我收集的一個表格14調(diào)用55調(diào)用HashMap的 調(diào)用HashMapput()根據(jù)表格,就知道應(yīng)該避免做哪些不必要的操作了②在Android源碼中也經(jīng)常見到這樣的寫法,"將一個實例變量賦值給一個局部變量,然后用這個局部變量"(局部緩存),特別是在onDraw方法或者循環(huán)中.會經(jīng)常用到.因為Java局部變量速度會比實例變量快.③盡量使用普通循環(huán),而不是使用使用實現(xiàn) ble接口的foreach循環(huán).因為移動設(shè)備性能有限.I tor的hasNext()和next()方法,從上面表格可以看出調(diào)用方法,比屬性更耗時本文 眾所周知,在更新androidSDK的同時,也更新了許多更靈活的新功能,這些功能或多或少地會造成運另一方面目前大多數(shù)的安卓用戶都是基于這兩個ROM,所以兼容性也不錯.這里推薦國內(nèi)最著名的APPCAN開發(fā)平臺htt /,不僅是全中文的開檔,而且功能不輸這個宅Max(http )是用discuz架設(shè)起來的,在appcan可以方便地找到對應(yīng)的插件.整個本文 Android設(shè)備繁多,根據(jù)屏幕尺寸系統(tǒng)將設(shè)備分為小/中/大/極大四種類型,又根據(jù)屏幕密度將設(shè)備分為低密度/中密度/高密度/.因此,App要適配所有設(shè)備,4x4=16種情況,但實際上我們只需要考慮幾種常見的機型就可以,例如WVGA800/WVGA854/WVGA800*/WVGA854*/WXGA,其它不同一個界面針對和平板設(shè)計如果差別很小,只有paddingsize的區(qū)別,可以將這些padding和size用dimen進行,具體是寫到values/dimens.xmlvalues-large-mdpi/dimens.xml文件中.這樣的好處就是編寫一個layout布resources.html#AlternativeResourcesxhdpi:2.0、hdpi:1.5、mdpi:1.0baseline)、ldpi:使用"wrap_content"and"match_parent"RelativeLayout布局使用.9.pngdpsppx的使用 低密度(ldpi中密度(mdpi高密度(hdpi幕QVGAHVGAWXGA大小中Android有自己的匹配設(shè)計意圖,當(dāng)你分別在這三個文件夾下放不同的時,在處理的時候android會自動大和縮小,如果你上方有字體這個會更明顯的看到效果,因為它會把放大或者縮小你看到的字體會變得<supports-screensandroid:largeScreens="true"android:normalScreens="true"android:anyDensity="true"看單詞我們應(yīng)該知道都是啥意思了,不過我還是稍微解釋一下在文件加入這句話的含android:anyDensity="true",這句話就是說當(dāng)我們的程序安裝到不同密度的上時,程序會自動加載放在對應(yīng)的資源的文件夾hdpi,mdpi,ldpi文件夾中的資源. <dimen 看到上面各個大神對兼容問題的解決方案,心潮澎湃,學(xué)到了很多,也不能藏私,在這里一點自己在做兼9xml文件中大量采用了這兩種方式的結(jié)合體,RelativeLayout的在父節(jié)點中居中,左對齊,右對齊等都是不隨分辨率改變而改變的.LinearLayout布局下android:layout_weight=""屬性十分好用,比如你想實現(xiàn)一行出現(xiàn)三個等寬的TextView,怎么辦？用這個屬性就可以很輕松的達到效果(具體用法網(wǎng)上搜搜一坨坨的),如果可以在代碼中動態(tài)的控制某個控件的寬和高占當(dāng)前屏幕(任何分辨率)的一定比例.可以先獲得屏幕的寬和高,然后通過設(shè)置控件的LayoutParam的方式(大概是這樣,錯誤,歡迎拍磚)來設(shè)定控件的寬和高以及位置.本文 針對這種情況,Android提供了一套標(biāo)準(zhǔn),它將屏幕分為三類,所以當(dāng)你新建一個Android工程后,工程自動為你創(chuàng)建三個存放不同分辨率,UI的文件夾,UI對應(yīng)不同分辨率及密度的屏幕.這三個文件夾只是告訴Android你設(shè)計的UI是針對哪種屏幕分辨率及密度進行設(shè)計的,Android終端會在打開應(yīng)用的時候自動根據(jù)終端類型去匹配與文件夾里提供的UI相近分辨率及密度的.假設(shè)終端屏是WVGA類型的,也就是密度為240,那么程序打開時,會去提取drawable-hdpi文件夾下,然后用一個物理像素去顯示一個像素,因為你把是放在drawable-hdpi文件夾下的,也就是告訴Android你當(dāng)?shù)拿芏扰c屏幕密度相同,則不進行縮放.當(dāng)?shù)拿芏扰c屏幕密度不同,則進行縮放.Android中長度單位最好使用與物理像素?zé)o關(guān)的邏輯像素dip,這樣Android就能幫助我們自動適應(yīng)不同的屏幕,保持設(shè)計意圖.Android中大小的轉(zhuǎn)換是基于密度,與屏幕分辨率和尺寸大小無關(guān).密度越大顯示就越清晰.總結(jié)UI,Android總能通過放大或者縮小來適應(yīng)屏幕來保證設(shè)計意圖,這個前提是布局里的單位是dip本文 Filedir/");//}IntentintentFilef=newFile(dir,Uriu=Uri} Buttonbutton=(Button) {=());//} ode,intresultCode,Intentdata) ode==CAPTURE_CODE&&resultCode=={Filedir/");//=Bitmapcbitmap= Filedir/");////if(!dir.exists())//dir////Uriu=//null,//Uriu=BitmapBitmapcbitmapMediaStore.Images.Media.getBitmap(//從圖像到bitmap理Bitmapcbitmap= Filefile StringzteBitmapzteBitmap=);//CanvascanvasPaintp=ne}}}}呵呵簡單吧?其實在開發(fā)中有些東西不用非得用高深的東西解決(我做了很多camera的改寫結(jié)果效果也就那 這段時間一直在做系統(tǒng)自帶應(yīng)用的修改布局這些東西正好也來一下.我也看到了前面有人提到layout_weight這個東西.其實我也是一得這個是很好的一個屬性,我就稍加詳細的說下提供給新手參考,因為<LinearLayoutxmlns:android="http://s >>>屏幕上可以保證一定的布局不會改變.layout_weight方式來做.就完全其實我覺得可能是電腦也蒙了到底你是想鬧哪樣的結(jié)果.所以0dp很.反正谷歌源碼都是這么寫的.我也就隨波逐流了.現(xiàn)在總結(jié)下.其實layout_weight就是控制高度或者寬度的一定比例.如果你想控制高度比例.那么容器方向垂直,組件高度為0dplayout_weight=你想要的比例,如果你想控制寬度比例,那么容器方向水平,組件寬度為0dplayout_weight=你想要的比例就好了.合理的搭配好容器的方向垂直、水平和組件的,便可以組裝出一很好的使用這個屬性,確定好現(xiàn)在的layout_weight到底是在控制高度還是寬度. 說到APP終端兼容,確實不是一件容易的事情,在沒有一個合適的兼容性測試平臺之前,最多的是靠的是經(jīng)驗,其次靠的是設(shè)備測試和用戶反饋.而對于開發(fā)過一段時間的android應(yīng)用的鄙人來說,認(rèn)為有以下幾點值得在終端①常用RelativeLayout,它不僅能解決布局顯示的問題,而且對比連續(xù)使用LinearLayout來說,程序的運行效率形.LinearLayout對比RelativeLayout來說,優(yōu)點是代碼量少,缺點是布局的不穩(wěn)定性和性能上的低效,個人理解上,Relative最常用為主布局,LinearLayout用在小地方,FrameLayout一般用來占位或有時重寫,Absoluayout一3/4,1/2,1/4,因為通常的屏幕尺寸是——ldpi120,mdpi160,hdpi240,xhdpi320.擁有更好的效果,但是又要考慮到向下兼容,自己又很難割舍.比如4.0的硬件加速功能.那怎么辦呢.①2.x版本之前打開恢復(fù)出廠設(shè)置是必須顯式調(diào)用,4.0之后打開恢復(fù)出廠可以可以隱式調(diào)用(類名又不再intversion=Intentintent=new}②2.x版本沒有硬件加速,而4.0以上又支持了硬件加速,但是我們的應(yīng)用在4.0上運行需要加載的資源以達到更佳效果(又必須是在硬件加速開啟的條件下),2.3上則要減少資源的加載,我們可以這么做publicObjectcallMethod(Class<?>_class,StringmethodName,Objectargs[])throwsSecurityException,{Methodmethod=_class.getMethod(methodName,newClass[0]);Objectobject=method.invoke(_class,args);}booleancallSuccess=false;try{callMethod(View.class,"isHardwareAccelerated",newObject[0]);callSuccess=true;{{{}catch {{}//doloadhigh//doloadlow}//doyour} 度,下在Android產(chǎn)品開發(fā)中,適配方面遇到的幾類和解決思路.上的日量.那么在適配上的要求,絕不僅僅是在各款上的功能可用.以下的是在設(shè)計時都要重當(dāng)程序達到一定的復(fù)雜程度以后,OutOfMemory是一個頭痛的問題,相信很多程序員都遇到過.雖然Java語言支持收集,但在Android開發(fā)中一不還是容易OutOfMemory異常.這些問題在項目的一開始可能不會引起重視,而當(dāng)需要適配的時候,問題就會出來.重復(fù).這里可以合理使用Java的軟機制來在內(nèi)存吃緊時回收,而內(nèi)存富裕時保持在內(nèi)存中供下分辨率下選擇.這個安卓的UI框架提供了一套機制 比如適應(yīng)Android某個版本以后的特性的功能,需要向前兼容.序提供了一系列API，所以在目標(biāo)平臺的分辨率是可以完全確定的情況下，程序也可以精確的控制自身在目標(biāo)資源分類符long和notlong。味著屏幕長寬比。在Android系統(tǒng)中，程序一般并不直接處理分辨率。以屏幕分辨率為基礎(chǔ)，沿屏幕長寬方向排列的像素。密度較低的屏幕，在長和寬方向都只有比較少的像素，而密度無關(guān)的像素需要的DIP縮放操作。要把密度無關(guān)像素轉(zhuǎn)換為屏幕像素，可以用這樣一個簡單的公式：pixelsdips*來定義你程序的界面布局，因為這樣可以保證你的UI在各種分辨率的屏幕上都可以正常顯示。mm:毫米,標(biāo)準(zhǔn)長度單位pt:磅,標(biāo)準(zhǔn)長度單位,1/72英寸.低密度(ldpi中密度(mdpi高密度(hdpi幕<supports-screensandroid:largeScreens="true"android:normalScreens="true"android:anyDensity="true"android:smallScreens="true"android:xlargeScreens="true">"裝在不同密度的上時，程序會分別加載hdpi,mdpi,ldpi文件夾中的資源。樣的話，應(yīng)用就會在小密度上加載mdpi文件中的資源。DisyMetricsmetric=newDisyMetrics();intdensityDpimetric.densityDpi;DPI（120160不同密度的進行分別設(shè)置。這里地圖的偏移量可以在values-xpdi，values-hpdi,values-mdpi,values-ldpi四種文件夾中的dimens.xml文件進行設(shè)置<dimen <dimen Android應(yīng)用程序支持橫豎屏幕的切換，androidActivityActivityActivity的地方進行如下的配置而有的程序是適合橫豎屏切換的。如何處理呢？首先要在配置Activity的時候進行如下的配置：{//landdonothingis//portdonothingis}}使用RelativeLayout設(shè)備都至少會有600dp的寬]，這樣就可以這樣定義一個布局文件：res/layout-sw600dp/main.xml(這是一個res/layout/main.xmlAndroid3.2之前的設(shè)備上使用這樣的表示方法，仍然需要使用xlarge來處理這樣的大屏幕情況3.2Smallest-width的標(biāo)識符，為了兼容之前的設(shè)備，仍然需要res/layout-sw600dpmulti-panelayout（3.2上進行使用，但是與上面的布局文件一致，都是two-pane的布局）res/layout/main.xml,single-panelayout使用9-patch，9-patch是一種有限制的可伸縮的格式，為了避免通常的在伸縮后出現(xiàn)的不某些不適配，比如中有個logo,你不希望這個logo隨拉伸而拉伸，那么我們就應(yīng)該使用這種格式的用dp，或者sp來表示大??；窗體Activity來顯示對于的內(nèi)容；判斷當(dāng)前的布局UI流程的設(shè)計，首先需要知道當(dāng)前使用的是哪個布局，two-paneorsingle-pane，因為前面講到系統(tǒng)會自動根據(jù)當(dāng)前屏幕來選擇顯示對應(yīng)的布局文件；根據(jù)當(dāng)前布局有不同的反應(yīng)，某些動作會根據(jù)當(dāng)前的布局而有不同的反映。例如如果你的應(yīng)用是么需要跳轉(zhuǎn)到另外一個Activity來顯示對于的內(nèi)容；而避免duplication.例如，ArticleFragment被使用在dual-pane的布局里面，<LinearLayoutxmlns:android="http://s <fragmentandroid:id="@+id/headlines"android:layout_height="fill_parent"<fragmentandroid:id="@+id/article"android:layout_height="fill_parent"的繪制，可以使用系統(tǒng)的Canvas類來實現(xiàn)。Android運行在提供不同屏幕尺寸和密度的多種設(shè)備上。對應(yīng)用程序而言，Android系統(tǒng)提供一致的跨設(shè)備的開發(fā)環(huán)境并且處理適配不同顯示屏幕的大部分工作。同時，系統(tǒng)提供API，允許針對不同的屏幕尺寸和密度來控制的應(yīng)用程序UI，從而為不同的屏幕配置來優(yōu)化UI設(shè)計。的.apk文件提供優(yōu)化的用戶體驗。的屏幕配置的總括，以及API和底層屏幕適配特性的概覽。,,,DPI（每英寸點數(shù)。例如，“低”的密度屏幕比“正?！被颉案摺泵蹹PDP單位轉(zhuǎn)換為屏幕像素是簡單的：PXDP*（DPIAndroid1.6（APILevel4）開始，Android提供了對多個屏幕尺寸和密度的支持，以反映出設(shè)備可能有的Android系統(tǒng)的功能，為每個屏幕配置優(yōu)化應(yīng)用程序的用戶界面，從而確保應(yīng)用程,,設(shè)備的配置，此設(shè)備即擁有一個HVGA屏幕的T- 每個廣義的大小和密度了一系列實際的屏幕尺寸和密度。例如，兩個設(shè)備，這兩個設(shè)備報告的正常屏Android抽象了應(yīng)用程序的這些差異，因此可以提供廣義的大小和密度設(shè)計的用戶界面，讓系統(tǒng)需要處理任何最終的調(diào)整。圖1顯示了不同的大小和密度大致分類成不同的大小和密度組。（選擇性資源。通常情況下，應(yīng)該為不同的屏幕尺寸提供alternativelayoutsalternativebitmapimages。在運行時，系統(tǒng)基于當(dāng)前設(shè)備的廣義屏幕尺寸或密度為應(yīng)用程序采用適當(dāng)?shù)馁Y源，UI元素（如按鈕，在低密度屏幕上顯示較大而在23.2中，textviewbitmap以像素為單位指定尺寸（像素單位，所以視圖的物理尺寸在地密度屏幕上2中是一樣的。然而，對低密度和高密度的屏幕，系統(tǒng)按比例調(diào)高或在大多數(shù)情況下，可以簡單的通過用密度無關(guān)像素（dpunits）來定義所有的布局尺寸或者適當(dāng)?shù)耐ㄟ^"wrap_content"bitmapdrawableAndroid支持多屏幕的基礎(chǔ)。系統(tǒng)處理的應(yīng)用程序屏幕適配的大部分工作，盡管如此，為了更妥善處理不式運行。應(yīng)用程序支持的屏幕尺寸，應(yīng)該在manifest文件中包括<supports-screens>元素。smallnormallarge,xlarge。例如，一個超大大屏幕的布局，應(yīng)該在layout-xlarge/。新技術(shù)來布局資源在為Android3.2設(shè)計平板布局部分有進一步討論?？梢允褂孟薅ǚ麃硖峁┟芏认嚓P(guān)的資源，這些限定符包括ldpi(low),mdpi(medium),hdpi(drawabledrawable資源。與hdpi為限定符的資源（drawable-hdpi/）會最佳匹配，所以系統(tǒng)使用該下的drawable資源。drawable/下的就是是默認(rèn)的資源。系統(tǒng)假定默然而，當(dāng)系統(tǒng)試圖尋找一個密度相關(guān)的資源但是在密度相關(guān)的下沒有找到時，系統(tǒng)并不總是使用默認(rèn)資源。系統(tǒng)可能會改用其他密度相關(guān)的資源之一，以提供更好的縮放結(jié)果。例如，當(dāng)尋找一個低密度資源而沒找到時，系統(tǒng)傾0.5輕松地將高密度資源縮小為低密度，這種縮放要個字符串，可以在Android項目追加到資源 <qualifier1所示，它限定了這些資源可以用于的屏幕配置(hdpi或xlarge).>— 比如,xlarge是一個超大屏幕的限定符。當(dāng)追加此字符串到一個資源 xlarge(~160dpi).(Thisisthebaselinedensity.)Resourcesforalldensities.Thesedensity-independentresources.Thesystemdoesnotscaleresourcestaggedwiththisqualifier,regardlessofthecurrentscreen'sdensity.Resourcesforscreenssomewherebetweenmdpiandhdpi;approxima y213dpi.Thisisnotconsidereda"primary"densitygroup.Itismostlyintendedforevisionsandmostappsshouldn'tneedit—providingmdpiandhdpiresourcesissufficientformostappsandthesystemwillscalethemasappropriate.Ifyoufinditnecessarytoprovidetvdpiresources,youshouldsizethematafactorof1.33*mdpi.Forexample,a100pxx100pximageformdpiscreensshouldbe133pxx133pxfortvdpi.Resourcesforscreensinthelandscapeorientation(wideaspectratio).Resourcesforscreensintheportraitorientation(tallaspectratio).AspectResourcesforscreensthathaveasignificantlytallerorwideraspectratio(wheninportraitorlandscapeorientation,respectively)thanthebaselinescreenResourcesforusescreensthathaveanaspectratiothatissimilartothebaselinescreenconfiguration.要使用表1中的尺寸限定符）的屏幕提供不同的bitmapdrawable。 //layoutfornormalscreensize("default") //layoutforsmallscreensize //layoutforlargescreensizeres/layout-xlarge/my_layout.xml//layoutforextralargescreensize //bitmapformediumdensity //bitmapforhighdensity //bitmapforextrahighdensityAlternativeResources。注意，Androd系統(tǒng)在運行時選擇使用哪些資源時，它使用某些邏輯來決定“最佳匹配”的資源。也就是說，使（（，所源是age限的是是個a-ie的備。放置nodpi配置限定符的 。如果用戶界面，需要讓位圖來適應(yīng)視圖的大?。ㄈ缫粋€按鈕的背景，應(yīng)該使用Nine-Patch位圖文件。Nine-PatchPNG文件它可以在特定的二維地區(qū)伸展。當(dāng)系統(tǒng)需要拉伸位圖所在的視圖時，系統(tǒng)會拉伸Nine-Patch文件，但是僅僅拉伸的是指定區(qū)域。正因為如此，不需要提供不同的屏幕尺寸不同的，因Nine-PatchNine-Patch文件。.幾乎每個應(yīng)用程序都應(yīng)當(dāng)為不同的屏幕密度提供資源，因為幾乎每一個應(yīng)用程序都擁有一個啟動圖標(biāo)，而,) 為48x48像素的位圖（應(yīng)用程序啟動圖標(biāo)，與之對應(yīng)的所有不同的尺寸應(yīng)當(dāng)是：菜單圖標(biāo)，狀態(tài)欄圖標(biāo)，tab圖標(biāo)等等。Android3.2對于第一代運行Android3.0的平板電腦來說，平板布局的適合方式是使用xlarge限定符（比如xlarge/義資源的方式。這種新技術(shù)是基于布局所需的空間數(shù)量（600dp寬，而不是試圖讓布局去符合廣義的尺不可用的。因此，的尺寸應(yīng)當(dāng)明確的是activity所需的尺寸—當(dāng)系統(tǒng)應(yīng)當(dāng)提供多少空間給布局時，它會UIActionBar被認(rèn)為是應(yīng)用程序的一部分空間，盡管布局沒有Thefundamentalsizeofascreen,asindicatedbytheshortestdimensionoftheavailablescreenarea.Specifically,thedevice'ssmallestWidthistheshortestofthescreen'savailableheightandwidth(youmayalsothinkofitasthe"smallestpossiblewidth"forthescreen).Youcanusethisqualifiertoensurethat,regardlessofthescreen'scurrentorientation,yourapplication'shasatleast<N>dpsofwidthavailableforitForexample,ifyourlayoutrequiresthatitssmallestdimensionofscreenareabeatleast600dpatalltimes,thenyoucanusethisqualifertocreatethelayouttheseresourcesonlywhenthesmallestdimensionofavailablescreenisatleast600dp,regardlessofwhetherthe600dpsideistheuser-perceivedheightorwidth.ThesmallestWidthisafixedscreensizecharacteristicofthedevice;thedevice'ssmallestWidthdoesnotchangewhenthescreen'sorientationThesmallestWidthofadevicetakesintoaccountscreendecorationsandsystemUI.Forexample,ifthedevicehaspersistentUIelementsonthescreenthataccountforspacealongtheaxisofthesmallestWidth,thesystemdeclaresthesmallestWidthtobesmallerthantheactualscreensize,becausethosearescreenpixelsnotavailableforyourUI.Thisisanalternativetothegeneralizedscreensizequalifiers(small,normal,large,xlarge)thatallowsyoutodefineadiscretenumberfortheeffectivesizeavailableforyourUI.UsingsmallestWidthtodeterminethegeneralscreensizeisusefulbecausewidthisoftenthedrivingfactorindesigningalayout.AUIwilloftenscrollvertically,buthavefairlyhardconstraintsontheminimumspaceitneedshorizontally.Theavailablewidthisalsothekeyfactorindeterminingwhethertouseaone-panelayoutforhandsetsormulti-panelayoutfortablets.Thus,youlikelycaremostaboutwhatthesmallestpossiblewidthwillbeoneachdevice.Specifiesaminimumavailablewidthindpunitsatwhichtheresourcesshouldbeused—definedbythe<N>value.system'scorrespondingvalueforthewidthchangeswhenscreen'sorientationswitchesbetweenlandscapeandportraittoreflectthecurrentactualwidththat'savailableforyourUI.Thisisoftenusefultodeterminewhethertouseamulti-layout,becauseevenonatabletdevice,youoftenwon'twantsamemulti-panelayoutforportraitorientationasyoudolandscape.Thus,youcanusethistospecifytheminimumrequiredforthelayout,insteadofusingboththescreensizeSpecifiesaminimumscreenheightindpunitsatwhichtheresourcesshouldbeused—definedbythe<N>value.system'scorrespondingvaluefortheheightchangeswhenscreen'sorientationswitchesbetweenlandscapeandportraittoreflectthecurrentactualheightthat'savailableforyourUI.Usingthistodefinetheheightrequiredbyyourlayoutisusefulthesamewayasw<N>dpisfordefiningtherequiredinsteadofusingboththescreensizeandorientationHowever,mostappswon'tneedthisqualifier,consideringthatoftenscrollverticallyandarethusmoreflexiblewithhowheightisavailable,whereasthewidthis