⑴ android屏幕適配有哪些方法
Android 資源文件夾有其中兩種方式支持屏幕適配：
一、方法：
1.XXX XXX-ldpi XXX-mdpi XXX-hdpi XXX-xhdpi XXX-xxhdpi 這種方式 （推薦使用）
2.XXX XXX-123x456 後面是具體值（不推薦使用這種方式！）
當我們做適配處理時通常會在以上一堆文件夾中定義 xxx.xml 例如 定義一個 ： <dimen name="list_item_height">100dip</dimen>
二、適配舉例：
Android的匹配機制和手機系統有關：
規則一：Android4.0 以上的手機，先尋找和設備吻合的文件夾里的相應文件里的資源，如果沒有找到會繼續匹配它下面（比它解析度或密度小）的一些文件夾，最後去XXX 默認文件夾中匹配。
eg1: 小米2s (4.1 1280x720) 有文件夾 XXX XXX-320x240 XXX-800x480 XXX-1280x719 XXX-1280x720 XXX-1280x721 XXX-xhdpi
1.匹配XXX-xhdpi
2.匹配XXX-1280x720
3.匹配XXX-1280x719
4.匹配XXX-480x800
5.匹配XXX-320x240
6.匹配XXX
eg2：HTC ONE (4.2 1920×1080)
規則二：Android4.0 以下的手機，先尋找和設備吻合的文件夾里的相應文件里的資源，如果沒有找到會繼續匹配它下面（比它密度小）的一些文件夾。
eg:三星m250L(同三星9100 2.3.7 800x480) 有文件夾 XXX XXX-320x240 XXX-800x479 XXX-480x800 XXX-ldpi XXX-mdpi XXX-hdpi
1.匹配XXX-hdpi
2.匹配XXX-mdpi
3.匹配XXX-480x800
4.匹配XXX
5.匹配XXX-ldpi
6.程序退出
eg3:華為U8860(2.3.6 854x480)
所以在項目中<dimen name="list_item_height">50dip</dimen> 分別定義在
values : <dimen name="list_item_height">50dip</dimen> 和
values-320x240 : <dimen name="list_item_height">42dip</dimen> 中.
小米2s 會取 values-320x240 中42dip 的值。
⑵ Android屏幕適配-應用篇
Android屏幕適配-基礎篇
Android屏幕適配-應用篇
從兩個大方面闡述一下Android的屏幕適配：
Android推薦使用dp作為尺寸單位來適配UI ，通過dp加上自適應布局和weight比例布局可以基本解決不同手機上適配的問題，這基本是最原始的Android適配方案。
缺點 ：
（1）這種方案只能保證我們寫出來的界面適配絕大部分手機，部分手機仍然需要單獨適配，但dpi的不同，還是會存在差異。
（2）一般的設計稿都是以px為單位的，所以我們在寫layout文件的時候需要將px轉為dp，影響開發效率。
為了高效的實現UI開發，出現了新的適配方案，我把它稱作寬高限定符適配。簡單說，就是窮舉市面上所有的Android手機的寬高像素值，設定一個基準的解析度，其他解析度都根據這個基準解析度來計算，在不同的尺寸文件夾內部，根據該尺寸編寫對應的dimens文件:
鴻洋大神的作品 ，使用也超級簡單，核心功能就是在繪制的時候在onMeasure裡面做變換，重新計算px。
缺點 ：我們自定義的控制項可能會被影響或限制，可能有些特定的控制項（框架沒有做適配的控制項），需要單獨適配。
小結：上述幾種適配方案都是實際開發中用過的方案，但隨著技術不斷的更新，出現了更好的適配方案。
實現原理 ：Android會識別屏幕可用高度和寬度的最小尺寸的dp值（ 其實就是手機的寬度值 ），然後根據識別到的結果去資源文件中尋找對應限定符的文件夾下的資源文件。
sw限定符適配 和 寬高限定符適配 類似，區別在於，前者有很好的容錯機制，如果沒有value-sw360dp文件夾，系統會向下尋找，比如離360dp最近的只有value-sw350dp，那麼Android就會選擇value-sw350dp文件夾下面的資源文件。這個特性就完美的解決了上文提到的寬高限定符的容錯問題。
優點: 1.非常穩定，極低概率出現意外
2.不會有任何性能的損耗
3.適配范圍可自由控制，不會影響其他三方庫
缺點 ：就是多個dimens文件可能導致apk變大，幾百k。
附件： 生成sw文件的工具
實現原理 ： 修改系統的density值 （核心）
今日頭條適配是以設計圖的寬或高進行適配的，適配最終是改變系統density實現的。
過程：
AndroidAutoSize 是基於今日頭條適配方案，該開源庫已經很大程度上解決了今日頭條適配方案的兩個缺點，可以對activity，fragment進行取消適配。也是目前我的項目中所使用的適配方案。
使用也非常簡單只需兩步：
（1）引入：
（2）在 AndroidManifest 中填寫全局設計圖尺寸 (單位 dp)，如果使用副單位，則可以直接填寫像素尺寸，不需要再將像素轉化為 dp，詳情請查看 demo-subunits
⑶ Android屏幕適配之全面屏適配
從2017年開始，全面屏之戰逐漸如火如荼的展開了，那麼我們Android程序員又多了一個小事情，就是解決全面屏適配的問題。
全面屏和以前的屏幕相比，有以下幾點改變
聲明方式
ratio_float這個值怎麼取呢？
其實就是高寬比。
傳統的手機高寬比是：16 : 9 即 16 / 9 ≈ 1.78
那麼全面屏的手機寬高比：18 ：9 即 18 / 9 = 2
但是這個時候，我們需要注意一下，現在很多手機都在追求更大的高寬比，即讓屏幕頂部和底部邊框越小越好，比如現在的「小米 mix 3 」
即他的高寬比是
19.5 / 9 ≈ 2.17
所以保險起見，設置成為 2.2, 當然這個值也不是固定的，如果有更新的手機上市，沒准我們還得改。
即這樣設定就好了
Android 7.0 google 默認支持了分屏模式，即 Manifest 文件中配置 Activity 的
那麼這個時候就不需要再配置上面的 「最大屏幕高寬比」，就可以適配全面屏了。
但是如果通過自定義控制項將「分屏模式」禁止的話，就會出現屏幕 上下黑邊的效果，非常丑。
修改AndroidManifest.xml文件，設置targetSdkVersion>=26，就是應用升級到O版本。
不需要設置其他任何屬性，默認在任何縱橫比的屏幕都能全屏顯示。
（備註：有一種例外情況需要注意，應用如果已經適配到O版本，並且通過meta-data屬性android.max_aspect或者是android:MaxAspectRatio屬性設置了頁面支持的最大縱橫比，同時又通過android:resizeableActivity=「false」設置了頁面不支持分屏，這個時候系統會按照應用自己設置的最大縱橫比決定該頁面是否能全屏顯示，如果應用設置的最大縱橫比比手機屏幕比例小，那應用還是無法全屏顯示。）
默認 UI 為我們切的啟動頁面的圖是固定的，比如 1920*1080
這個能適配以前一般的解析度的手機，但是全面屏的出現，我們會發現，這個啟動頁的圖片會被拉伸，一般是縱向拉伸，因為 「高」 變大了。
那麼這種情況的解決方法其實有這么幾種思路：
本人還是覺得虛擬導航按鍵不是一個好東西，但是全面屏的出現，真的把我以前喜歡的"實體按鍵" 給舍棄掉了。
我倒是覺得替代以前的"實體按鍵"的最好的方法，還是手勢操作。起碼我覺得小米8 的手勢操作很 6 有沒有。再看看蘋果，壓根就不同虛擬按鍵考慮好不。。。
不過，這是我自己的拙見，請各位虛擬按鍵愛好者，不要噴我，先行謝過。
原則，虛擬按鈕的顯示樣式，其實根據當前具體的頁面情況進行調整，調整策略其實和status bar 的類似。
可以通過
來定義顏色。
或者通過設置當前activity 主題 或者設置application主題
在主題的樣式中設置：
即可。
頻繁的手機更新迭代，雖然讓我們程序員多了一些事情可做，但是卻也是我們喜聞樂見的事，手機在發展，說明我們的行業也在發展呀，況且，解決這些問題也不是難事。你說是不是呢？
如果沒看懂我的文章，請觀看小米官網提供的方案（其實是一致的）：
全面屏及虛擬鍵適配說明
⑷ Android 屏幕適配
摘自： https://www.jianshu.com/p/ec5a1a30694b
摘自： https://www.jianshu.com/p/337c47721690
摘自： https://www.jianshu.com/p/4669814362ee
因為ui設計師給你的設計圖是以px為單位的，Android開發則是使用dp作為單位的，那麼我們需要進行轉換：
擴展：
Android屏幕適配-基礎篇
Android推薦使用dp作為尺寸單位來適配UI ，通過dp加上自適應布局和weight比例布局可以基本解決不同手機上適配的問題，這基本是最原始的Android適配方案。
缺點：
（1）這種方案只能保證我們寫出來的界面適配絕大部分手機，部分手機仍然需要單獨適配，但dpi的不同，還是會存在差異。
（2）一般的設計稿都是以px為單位的，所以我們在寫layout文件的時候需要將px轉為dp，影響開發效率。
為了高效的實現UI開發，出現了新的適配方案，我把它稱作寬高限定符適配。簡單說，就是模仿市面上所有的Android手機的寬高像素值，設定一個基準的解析度，其他解析度都根據這個基準解析度來計算，在不同的尺寸文件夾內部，根據該尺寸編寫對應的dimens文件:
鴻洋大神的作品 ，使用也超級簡單，核心功能就是在繪制的時候在onMeasure裡面做變換，重新計算px。
缺點：
我們自定義的控制項可能會被影響或限制，可能有些特定的控制項（框架沒有做適配的控制項），需要單獨適配。
小結：上述幾種適配方案都是實際開發中用過的方案，但隨著技術不斷的更新，出現了更好的適配方案。
1.SmallestWidth適配（sw限定符適配）
實現原理：
Android會識別屏幕可用高度和寬度的最小尺寸的dp值（其實就是手機的寬度值），然後根據識別到的結果去資源文件中尋找對應限定符的文件夾下的資源文件。
sw限定符適配 和 寬高限定符適配 類似，區別在於，前者有很好的容錯機制，如果沒有value-sw360dp文件夾，系統會向下尋找，比如離360dp最近的只有value-sw350dp，那麼Android就會選擇value-sw350dp文件夾下面的資源文件。這個特性就完美的解決了上文提到的寬高限定符的容錯問
優點：
1.非常穩定，極低概率出現意外
2.不會有任何性能的損耗
3.適配范圍可自由控制，不會影響其他三方庫
缺點：
就是多個dimens文件可能導致apk變大，幾百k。
這里有個問題：
在項目的其他 mole 中怎麼實現適配？難道也要多套 dimens 文件？
解答：
並不需要多套 dimens 文件，只需要在 values 文件夾下有一套與 app mole 一樣的 dimens 文件即可達到適配。因為經過編譯，所有 mole 中的 dimen 數據都會統一歸類到主 mole（即 app mole）中的 values/dimens.xml 文件中了，然後系統又會根據你設置的值去找對應 values-swxxxdp 文件夾下的dimens.xml 文件中的值。
附件： [生成sw文件的工具]( https://links.jianshu.com/go ?
to=https%3A%2F%2Fgithub.com%2Fladingwu%2Fdimens_sw)
實現原理：修改系統的density值（核心）
今日頭條適配是以設計圖的寬或高進行適配的，適配最終是改變系統density實現的。
過程：
缺點：
1.只需要修改一次 density，項目中的所有地方都會自動適配，這個看似解放了雙手，減少了很多操作，但是實際上反應了一個缺點，那就是只能一刀切的將整個項目進行適配，但適配范圍是不可控的。
2.這個方案依賴於設計圖尺寸，但是項目中的系統控制項、三方庫控制項、等非我們項目自身設計的控制項，它們的設計圖尺寸並不會和我們項目自身的設
AndroidAutoSize 是基於今日頭條適配方案，該開源庫已經很大程度上解決了今日頭條適配方案的兩個缺點，可以對activity，fragment進行取消適配。也是目前我的項目中所使用的適配方案。
使用也非常簡單只需兩步：
第一步： 導入依賴
第二步： 配置AndroidManifest
在 AndroidManifest 中填寫全局設計圖尺寸 (單位 dp)，如果使用副單位，則可以直接填寫像素尺寸，不需要再將像素轉化為 dp，詳情請查看 demo-subunits
老師給的UI設計是在藍湖上的，因為還沒工作，接觸就藍湖，SW個人感覺好處就是藍湖上尺寸多少你就寫多少就行
⑸ Android-屏幕適配全攻略（絕對詳細）（一）
關鍵字： 屏幕適配 px dp dpi sp large限定符 .9.png
前言： 這篇文章依然是我在 [慕課網 ][h]學習 凱子哥 的同名視頻 Android-屏幕適配全攻略 ，所記錄下來的筆記---凱子哥講得真的超詳細。
[h]: http://www.imooc.com/ "MOOC"
從上圖可以看出，主流的解析度是前六種：1280×720、1920×1080、800×480、854×480、960×540、1184×720，不過我們有解決方案。看完這篇文章，想必你就可以解決常見的屏幕適配問題。
接下來正式進入正題。
介紹幾個在Android屏幕適配上非常重要的名詞：
屏幕尺寸 是指屏幕對角線的長度。單位是英寸，1英寸=2.54厘米
屏幕解析度 是指在橫縱向上的像素點數，單位是px，1px=1像素點，一般是縱向像素橫向像素，如1280×720
屏幕像素密度 是指每英寸上的像素點數，單位是dpi，即「dot per inch」的縮寫，像素密度和屏幕尺寸和屏幕解析度有關
dip： Density Independent Pixels（密度無關像素）的縮寫。以 160dpi 為基準，1dp=1px
dp： 同 dip
dpi： 屏幕像素密度的單位，「dot per inch」的縮寫
px： 像素，物理上的絕對單位
sp： Scale-Independent Pixels的縮寫，可以根據文字大小首選項自動進行縮放。Google推薦我們使用12sp以上的大小，通常可以使用12sp，14sp，18sp，22sp，最好不要使用奇數和小數。
用於區分不同的像素密度。
在Google官方開發文檔中，說明了 ** mdpi：hdpi：xhdpi：xxhdpi：xxxhdpi=2：3：4：6：8 ** 的尺寸比例進行縮放。例如，一個圖標的大小為48×48dp，表示在mdpi上，實際大小為48×48px，在hdpi像素密度上，實際尺寸為mdpi上的1.5倍，即72×72px，以此類推。
我們可以通過以下幾種方式來支持各種屏幕尺寸：
wrap_content： 根據控制項的內容設置控制項的尺寸
math_parent： 根據父控制項的尺寸大小設置控制項的尺寸
weight： 權重，在線性布局中可以使用weight屬性設置控制項所佔的比例
例如，我們要實現下圖所顯示的效果：當屏幕尺寸改變時，new reader控制項兩邊的控制項大小不變，new reader控制項會占完剩餘的空間。
具體布局文件如下：
小插曲： 關於 android:layout_weight 屬性
一般情況，我們都是設置要進行比例分配的方向的寬度為0dp，然後再用權重進行分配。如下：
效果為：
效果為：
button1寬度=L+（L-2L）×1/3=2/3L
button2寬度=L+（L-2L）×2/3=1/3L
當然，還有其他的方式，都可以運用此公式進行計算。
在實際開發中，我們一般使用0dp的方式，而不使用其他方式。
簡單的布局一般都使用 線性布局 ，而略微復雜點的布局，我們使用 相對布局 ，大多數時候，我們都是使用這兩種布局的嵌套。
我們使用 相對布局 的原因是， 相對布局 能在各種尺寸的屏幕上保持控制項間的相對位置。
res/layout/main.xml 單面板：
res/layout-large/main.xml 雙面板：
如果這個程序運行在屏幕尺寸大於7inch的設備上，系統就會載入 res/layout-large/main.xml 而不是 res/layout/main.xml ，在小於7inch的設備上就會載入 res/layout/main.xml 。
需要注意的是，這種通過 large 限定符分辨屏幕尺寸的方法，適用於android3.2之前。在android3.2之後，為了更精確地分辨屏幕尺寸大小，Google推出了最小寬度限定符。
res/layout-sw600dp/main.xml ，雙面板布局： Small Width 最小寬度
這種方式是不區分屏幕方向的。這種最小寬度限定符適用於android3.2之後，所以如果要適配android全部的版本，就要使用 large 限定符和 sw600dp 文件同時存在於項目 res 目錄下。
這就要求我們維護兩個相同功能的文件。為了避免繁瑣操作，我們就要使用布局別名。
由於後兩個文具文件一樣，我們可以用以下兩個文件代替上面三個布局文件：
res/layout/main.xml 單面板布局
res/layout/main_twopanes.xml 雙面板布局
然後在 res 下建立
res/values/layout.xml 、
res/values-large/layout.xml 、
res/values-sw600dp/layout.xml 三個文件。
默認布局
res/values/layout.xml :
Android3.2之前的平板布局
res/values-large/layout.xml :
Android3.2之後的平板布局
res/values-sw600dp/layout.xml :
這樣就有了 main 為別名的布局。
在activity中 setContentView(R.layout.main);
這樣，程序在運行時，就會檢測手機的屏幕大小，如果是平板設備就會載入 res/layout/main_twopanes.xml ，如果是手機設備，就會載入 res/layout/main.xml 。我們就解決了只使用一個布局文件來適配android3.2前後的所有平板設備。
如果我們要求給橫屏、豎屏顯示的布局不一樣。就可以使用 屏幕方向限定符 來實現。
例如，要在平板上實現橫豎屏顯示不用的布局，可以用以下方式實現。
res/values-sw600dp-land/layouts.xml :橫屏
res/values-sw600dp-port/layouts.xml :豎屏
自動拉伸點陣圖，即android下特有的 .9.png 圖片格式。
當我們需要使圖片在拉伸後還能保持一定的顯示效果，比如，不能使圖片中的重要像素拉伸，不能使內容區域受到拉伸的影響，我們就可以使用 .9.png 圖來實現。
要使用 .9.png ，必須先得創建 .9.png 圖片，androidSDK給我們提供了的工具就包含 .9.png 文件的創建和修改工具。雙擊 SDK安裝目錄 oolsdraw9patch.bat ，就會打開下圖所示的窗口。
下面是一個例子：
Button屬性設置：
如果我們選擇的內容區域偏差太大，可能就不會顯示出text值 BUTTON 。
好了，這篇文章寫的有點多了，剩下的內容放在 下篇文章 記錄吧。
內容提要：
解決方案-支持各種屏幕密度
解決方案-實施自適應用戶界面流程
未完待續
⑹ Android 屏幕適配
1： dp: android 尺寸的基本單位。 在不同的解析度的手機裡面，1dp對應著不同數量的px, 這樣就實現了dp定義一個控制項大小的時候，在不同解析度手機里表現出相應大小的像素值。
2： 屏幕解析度： 1080下160, 表示寬度有1080個像素點而高度有2160個像素點。常見的解析度有320x480， 480x800, 720x1280, 1080x1920等。
3： 屏幕尺寸： 以寸為單位， Android設備對角線的長度
4： 像素密度: 每英寸的像素點
5： 屏幕尺寸， 解析度，像素密度 三者之間的關系：
密度（dpi）= √（寬2 + 高2）/屏幕尺寸
6： px：像素，是屏幕上顯示數據的最基本的點
7： dpi：屏幕像素密度，每英寸上的像素點數
8： sp：與dp類似，通常用於指定字體的大小，當用戶修改手機顯示的字體時，字體大小會隨之改變。
1： dp適配方案： Android自帶的原始的適配方案， 在不同的解析度手機裡面表現出相應大小的像素點。
缺點： Android的碎片化嚴重， 如果生產廠家沒有根據屏幕尺寸、解析度和像素密度的關系來規則定義， 或者出一些亂七八糟的屏幕大小，這樣的適配方案就不在適合了。
2： 寬高限定符：枚舉所有的屏幕寬高像素值，根據等比縮放去適配。如果沒有找到對應的屏幕， 則取默認的。 目前這種方案已經被棄用。
缺點：
1： 佔用資源大，會增加APK的體積。
2： 容錯機制大需要精準命中資源文件才能適配，比如1920x1080的手機就一定要找到1920x1080的限定符，否則就只能用統一的默認的dimens文件了。而使用默認的尺寸的話，UI就很可能變形。
3：AndroidAutoLayout適配方案（停止維護）
4: SW限定符適配方案：（smallestWidth最小寬度適配）
Android 會去識別屏幕可用高度或者寬度的最小尺寸的dp值。然後根據識別到的結果去對應的資源文件裡面去找尋相應的結果。
如何生成：ScreenMatch插件
此方案跟寬高限定的適配方案相比，有很好的容錯機制， 如果沒有找到對應的適配寬度， 那麼會在vlues文件裡面去找跟他最接近的寬度。
5：今日頭條適配方案：
1>: px 轉 dp 的公式 dp = px / density.不管我們設定的單位是什麼， 最終我們都會將這些單位長度轉化為px的。density就是他們的轉化比， 所以，動態改變這個轉化比也是可以達到我們適配屏幕的目的的。
2>: 通過修改density值，強行把所有不同尺寸解析度的手機的寬度dp值改成一個統一的值（在清單文件中定義），這樣就解決了所有的適配問題。
3>: Density = 當前設備屏幕總寬度（單位為像素）/ 設計圖總寬度（單位為 dp) ；
4>：引入了AndroidAutoSize屏幕適配框架：
https://github.com/JessYanCoding/AndroidAutoSize
最後， 最重要的................
點贊 點贊 點贊， 不重要的事情也就說3遍......