android解析度適配

㈠ android 屏幕適配基礎知識

最近參考 今日頭條演算法 ，優化了項目的屏幕適配策略。下面是適配過程中的一些心得，部分內容來源於網路。

舉個例子：屏幕解析度為：1920*1080，屏幕尺寸為5吋的話，那麼dpi為440。

dp就是密度自適應的像素。1dp表示 在dpi為160的設備上的一顆像素
px與dp的換算公式px = dp * (dpi / 160)，很顯然，由於相同解析度但不同屏幕大小的設備dpi是不同的，導致px和dp的基本不存在一個固定的換算關系，為了方便屏幕適配，Android設置了6個通用的密度，換算px與dp時採取通用密度計算，而非設備實際的密度。

以下為6種通用密度，以及其最小的解析度

得到上面通用密度之後，我們換算dp與px多了一種簡便方式。Android系統用mdpi(160dpi)作為基準，此時1px = 1dp，又有px = dp * (dpi / 160)，所以我們可以很容易的得到以下換算：

sp在dp的基礎上引入了scaleFactor變數，一般用於字型大小，可在系統設置里調大。

同一張圖片放到以上4個解析度類型的文件夾里，在頁面上呈現的效果如下

實際呈現的演算法為： 圖片尺寸 * 系統density / 文件夾 density
因為圖片尺寸、系統density都是固定的，因此圖片最終尺寸表現為： 圖片放的位置越"low"，呈現的尺寸越大

比如 圖片寬度200px，系統 density =3，則圖片寬度

下面是詳細的解釋

我們知道，不管在布局文件中填寫的是什麼單位，它最後都會被系統轉化為 px。系統的轉換演算法如下：

可以看到 px = dp*density 。

橫向適配的最終目的：讓100dp的寬度，在各個機型上，在屏幕上所佔的 比例相同 。
其核心演算法是px = dp* density。通過修改density這個變數，我們可以讓px和畫布標注的px值一致，達到適配的效果。

美工同學提供的畫布寬度為 750px（iphone6） ，開發中，我們對這些px標注 除2 得到dp值進行使用。
那麼density如何求出呢？ 根據系統演算法px = dp*density，反推 density =px/dp
拿橫向適配畫布， density對於不同解析度的手機修改後如下：

375是我們拿UI畫布橫向解析度750/2得出。

㈡ Android 屏幕解析度適配

Android屏幕解析度千奇百怪，怎麼讓app在不同的解析度的設備上「看起來一樣」呢？
你也許還有以下疑惑：

這篇文章將會針對以上問題一一解答。

Pixels 我們看到屏幕上的圖像由一個個像素組成，像素里包含色彩信息。
如常說的手機解析度：1080 x 1920 指的是手機寬度可展示1080像素，高度可展示1920像素。

Pixels Per Inch 每英寸長度所具有的像素個數，單位面積內像素越多，圖像顯示越清晰。
ppi一般用在顯示器、手機、平板等描述屏幕精細度。

Dots Per Inch 每英寸長度所具有的點數。
dpi一般用來描述列印（書本、雜志、電報）的精細度

density-independent pixels (device-independent pixels 我查了一下，官網更多時候使用前者，有的時候也顯示後者），dip是縮寫，也可以更簡單些稱作dp。該單位的目的是屏蔽不同設備密度差異，後面細說。

Scalable pixels 用於設置字體，在用戶更改字體大小時候會適配。

澄清了基本概念，我們現在從一個例子開始說明以上單位之間的區別與聯系。

布局文件里有個View，長寬都是200px，分別在解析度為480(寬)x800(高）簡稱A設備、1080(寬)x1920(高）簡稱B設備，效果如下:

左邊是A設備，右邊是B設備。問題出來了，同樣長寬都是200px，為啥A設備顯示很大，B設備顯示很小呢？你可能會說B設備的橫向解析度1080比A設備的480大，所以在B設備上看起來比較小。來看看A、B設備橫向到底是多少英寸，怎麼來計算呢？這時候就需要用到ppi了，既然知道橫向的像素點個數，也知道每英寸能容納的像素點，當然可以得知橫向的尺寸了。

其中一種方式獲取DisplayMetrics對象：

A設備寬度尺寸：480(px)/240(ppi)=2inch
B設備寬度尺寸：1080(px)/420(ppi)=2.5inch
可以看出，A、B設備尺寸差別不大。A設備ppi=240 B設備ppi=420，明顯地看出B設備單位長度上比A設備能夠容納更多的像素，因此同樣的200px，B設備只需要較小的尺寸就能夠顯示，因此在B設備上的view看起來比A設備小很多。
知道了問題的原因，然而顯示的效果卻不能接受。

我們總不能自己判斷每個設備的ppi，然後計算實際需要多少像素，再動態設置view的大小吧，那layout里的靜態布局大小就無法動態更改適應了。想當然的能有一個統一的地方替我們轉換，沒錯！Android系統已經幫我們實現了轉換。接下來就是dpi、dp出場了。

Android系統使用dpi來描述屏幕的密度，使用dp來描述密度與像素的關系。
A設備dpi=240
B設備dpi=420
Android系統最終識別的單位是px，怎麼將dpi和px關聯起來呢？，答案是dp。
Android規定當dpi=160時，1dp=1px，當dpi=240時，1dp=1.5px，依此類推，並且給各個范圍的dpi取了簡易的名字加以直觀的識別，如120<dpi<=160，稱作為mdpi，120<dpi<=240 稱作hdpi，最終形成如下規則：

現在知道了dp能夠在不同dpi設備上對應不同px，相當於中間轉換層，我們只需要將view長寬單位設置為合適的dp，就無需關注設備之間密度差異，系統會幫我們完成dp-px轉換。將我們之前的例子稍微更改，再看看效果驗證一下：

通過上面對dp的了解，我們知道在設定view大小、間距時使用dp能最大限度地屏蔽設備密度之間的差異。可能你就會問了，那bitmap展示的時候如何適配不同密度的設備呢？

自定義view從磁碟上載入一張圖片，並將之顯示在view上，view的大小決定於bitmap大小。依舊以上述A、B設備為例，展示結果如下：

左邊是A設備，右邊是B設備。
明顯地看出，在A設備顯示比B設備大很多，實際上和我們之前用px來描述view的大小原理是一樣的，bitmap的寬、高都是px在描述，而bitmap決定了view的寬、高，最終導致A設備和B設備上的view大小（寬、高像素）是一樣的，而它們屏幕密度又不相同，因此產生了差異。
那不會每次都需要我們自己根據屏幕密度來轉換bitmap大小吧？幸運的是，Android已經為我們考慮到了。

生成不同密度的目錄有什麼作用？
A設備dpi=240，根據dpi范圍，屬於hdpi
B設備dpi=420，根據dpi范圍，屬於xxhdpi
圖片原始尺寸：photo1.jpg(寬高 172px-172px)
當我們想要在不同密度設備上顯示同一張圖片並且想要「看起來一樣大時」。假設設計的時候以hdpi為准，放置photo1.jpg為172*172，那麼根據計算規則在xxhdpi上需要設置photo1.jpg為:

現在hdpi和xxhdpi目錄下分別存放了同名圖片：photo1.jpg，只是大小不同。當程序運行的時候：

來看看效果：

左邊A設備，右邊B設備
針對不同的密度設計不同的圖片大小，最大限度保證了同一圖片在不同密度設備上表現「看起來差不多大」。
來看看A、B設備上圖片占內存大小：

說明在B設備上顯示photo1.jpg需要更多的內存。
上邊只是列舉了hdpi、xxhdipi，同理對於mdpi、xhdpi、xxxhdpi根據規則放入相應大小的圖片，程序會根據不同的設備密度從對應的mipmap文件夾下載入資源。如此一來，我們無需關注bitmap在不同密度設備上顯示問題了。

在mipmap各個文件夾下都放置同一套資源的不同尺寸文件似乎有點太佔apk大小，能否只放某個密度下圖片，其餘的靠系統自己適配呢？
現在只保留hdpi下的photo1.jpg圖片，看看在A、B設備上運行情況如何：

看起來和上張圖差不多，說明系統會幫我們適配B設備上的圖片。
再來看看A、B設備上圖片占內存大小：
先看A設備：

對比photo1.jpg 分別放在hdpi、xxhdpi和只放在hdpi下可以看出：B設備上圖片所佔內存變小了。為什麼呢？接下來從源碼里尋找答案。

A、B設備同樣載入hdpi/photo1.jpg，返回的bitmap大小不相同，我們從這方法開始一探究竟。

上面涉及到的關鍵點是density，分別是TypedValue的density和Options的density。
先來看看TypedValue density:

再來看看Options density

現在分析B設備載入hdpi/photo1.jpg如何做的:

和我們之前調試的結果一致。

B設備是怎麼決定使用hdpi下的圖片資源呢？
根據實驗（嘗試找了源碼，沒怎麼看懂，因此只是做了實驗，可能在不同密度設備上找尋規則不一樣）：B設備先找屬於自己密度范圍文件夾下的圖片，B設備屬於xxhdpi，先查看xxhdpi有沒有photo1.jpg，如果沒有則往更高的密度找，比它高的密度是xxxhdpi，還是沒有，則往低密度找，找xhdpi，沒有再找hdpi，找到了則返回構造好的TypedValue，剩下的就是我們前面分析的。
既然我們只想放某個密度下的一份切圖，該放哪個密度下呢？從系統尋找規則看，更推薦放置在更高密度下的，因為如果放在低密度下，那麼當運行在高密度設備上時，圖片會進行放大，可能導致不清晰。我一般習慣放在xxhdpi下。

Android Studio默認創建了不同密度的mipmap文件夾，默認放置了ic_launcher.png。我們普通的切圖該放drawable還是mipmap下呢？對於這個問題網上也是眾說紛紜，實際上對於我們來說，關注的重點是圖片放在drawable或者mipmap，載入出來bitmap是否有差異，如果沒有差異放在哪就看習慣了。通過實踐，普通的切圖放drawable和mipmap下載入出來的bitmap是沒有差異的，只不過用drawable的話需要自己創建不同密度的文件夾。我習慣於放在drawable下(啟動圖標logo還是放在mipmap下）。

前邊 [注1] 留了個問題，我們使用dp來表示view的大小了，為啥兩個看起來還是有些差距？下面我們更加直觀地看一個例子。
A設備dpi=240 密度1.5 解析度(寬高px)：480 * 800
B設備dpi=420 密度2.625 解析度(寬高px)：1080 * 1794
換算成dp
A設備解析度：320dp * 533dp
B設備解析度：411dp * 683dp
依舊是上邊的例子：

將view寬高分別設置為320dp，看看效果：

左邊A設備，右邊B設備
可以看出同樣的320dp大小，A設備鋪滿了屏幕，而B設備沒有。這效果顯然是不能接受的，Android考慮到不同設備寬高不同，推出了"寬高限定符"。以A、B設備為例：
在res文件夾下創建文件夾：

假設設計師出圖是按照800x480，那麼我們創建dimen文件的時候

該文件放在values-800x480文件夾下。
根據解析度比例算出1794x1080的dimen值

這樣子，A、B設備載入資源的時候使用對應解析度限定符下的px，如果找不到再找默認值，可以在一定程度上解決屏幕寬高碎片化適配問題。
但是這樣子的限定比較嚴格，需要測試各種解析度，後來Android又推出了"smallest-width"簡稱最小寬度限制。
A設備寬320dp
B設備寬411dp
假設設計師切圖標准屏幕寬是320dp(A設備），那麼可以定義如下dimen.xml文件

該文件放在values-sw320dp文件夾下
根據規則，計算B設備dimen.xml

現在我們繼續來看之前的view

通過對dimen引用，A設備尋找和自己寬度一樣的dimen文件，找到values-sw320dp，dp320=320dp。B設備尋找和自己寬度一樣的dimen文件，找到values-sw411dp，dp320=410dp。這樣子同樣的dp320，得出不同的值，就適配了屏幕寬度不同的問題。
看看效果：

這次B設備也鋪滿了屏寬。

綜上，為了適配不同屏幕大小，推薦使用dp+smallest-width。

獲取設備dpi最終都是從這方法獲取的，實際上就是讀取系統的配置文件。因此我們也可以通過adb shell 獲取：

可以看出dpi是系統配置好的，當然有些手機是可以設置解析度的，設置之後我們查看解析度：

解析度變低了，dpi也變小了。

㈢ 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遍......

㈤ Android機型適配總結

解析度對應DPI

ldpi  QVGA (240×320)

mdpi  HVGA (320×480)

hdpi  WVGA (480×800),FWVGA (480×854)

xhdpi  720P（1280*720）

xxhdpi 1080p（1920*1080 ）

xxxhdpi 4K（3840×2160）

機型適配方面常規處理方法：

1、開發之前UI給出不同尺寸標準的多套素材，一般情況下給出：hdpi、xhdpi、xxxhdpi 三種尺寸類型的素材。

2、特殊類型圖片使用Android Studio內置draw9path工具進行製作，例如聊天界面中內容背景圖片。

3、布局編寫時盡量使用 Linearlayout 與  RelativeLayout，LinearLayout內部可以使用weight（權重）屬性將子控制項的尺寸按比例進行設置。RelativeLayout 內部可以使用layout_align...(相對於xxx)屬性將子控制項的尺寸相對於父控制項或相對於其他子控制項進行設置。

4、設置尺寸的時候長度單位  布局使用 dp  字元使用  sp。 其實字體大小的尺寸使用  dp 也可以，但是sp的情況下 用戶使用系統設置字體大小的時候可以改變控制項中字體的大小，但是使用dp設置的字體就不會產生變化。

5、針對每一個屏幕的尺寸生成一套px與dp的轉換方案，詳情見博客： Android機型適配方案 。

6、google推出了一個百分比布局庫，可以使用百分比的方式進行布局尺寸的設置，詳情見博客： Android百分比布局庫（percent-support-lib）解析與擴展

7、利用自定義View的方式去解決，其實原理也是，在繪制View的時候，獲取屏幕的尺寸然後按照一定的比例去設置控制項的尺寸

還有一些瑣碎知識點需要了解並記住：

1. px (pixels)像素 ：

一個像素通常被視為圖像的最小的完整采樣，這個用的比較多,特別是web開發,頁面基本都是使用像素作為單位的.

2.dp：

這個是最常用但也最難理解的尺寸單位。它與「像素密度」密切相關，所以首先我們解釋一下什麼是像素密度。假設有一部手機，屏幕的物理尺寸為1.5英寸x2英寸，屏幕解析度為240x320，則我們可以計算出在這部手機的屏幕上，每英寸包含的像素點的數量為240/1.5=160dpi（橫向）或320/2=160dpi（縱向），160dpi就是這部手機的像素密度，像素密度的單位dpi是Dots Per Inch的縮寫，即每英寸像素數量。橫向和縱向的這個值都是相同的，原因是大部分手機屏幕使用正方形的像素點。

不同的手機/平板可能具有不同的像素密度，例如同為4寸手機，有480x320解析度的也有800x480解析度的，前者的像素密度就比較低。Android系統定義了四種像素密度：低（120dpi）、中（160dpi）、高（240dpi）和超高（320dpi），它們對應的dp到px的系數分別為0.75、1、1.5和2，這個系數乘以dp長度就是像素數。例如界面上有一個長度為「80dp」的圖片，那麼它在240dpi的手機上實際顯示為80x1.5=120px，在320dpi的手機上實際顯示為80x2=160px。如果你拿這兩部手機放在一起對比，會發現這個圖片的物理尺寸「差不多」。

3.dip：

與dp完全相同，只是名字不同而已。在早期的Android版本里多使用dip，後來為了與sp統一就建議使用dp這個名字了。

4.sp：

與縮放無關的抽象像素（Scale-independent Pixel）。sp和dp很類似但唯一的區別是，Android系統允許用戶自定義文字尺寸大小（小、正常、大、超大等等），當文字尺寸是「正常」時1sp=1dp=0.00625英寸，而當文字尺寸是「大」或「超大」時，1sp>1dp=0.00625英寸。類似我們在windows里調整字體尺寸以後的效果——窗口大小不變，只有文字大小改變。

還有一些詳細的情況需要了解，都在這個博客里： 點擊進入

㈥ Android設備的界面適配設計

Android設備App設計中有一個問題可能會被設計師忽略，在各種解析度各種尺寸「雜屏」的界面適配。可能產出的界面稿在常用的720*1280的解析度中是完美，但一到各個不同解析度不同尺寸的設備後

這里就談談適配，了解適配讓設計從PS、sketch到移動設備上都能完美呈現。

如此繁雜的安卓設備，採用哪個標准設計呢？

1.選擇一種尺寸一種解析度作為基準。

2.選擇2-3款主流的Android設備，制定一套適配規則。（國內主流設備、解析度可參考友盟指數）

3.部分極端效果特別注釋說明。

目前移動端設計師多採用iPhone 5與6的解析度設計，這兩個解析度也最接近Android xhdpi的720*1280，設計之後再做等比適配（不做設計元素等比適配會導致Android設備上視覺呈現較小）。

我則傾向於選取720*1280的解析度設計。優點是處於常用解析度的中間值，對小解析度大解析度調整也較容易。另外iOS@1x的320與720剛好是2.25的倍率關系，使用sketch等比輸出快捷多了。（如果時間成本允許的話可以將Android的標注單位用dp，具體的設備尺寸、解析度知識這里不詳描述，可見文章最後面的「Android基礎知識」）

案例說明：

雅虎新聞為各個dpi做了優化，圖片等比縮放，文字區域等比縮放，並且考慮到在低dpi下會被推移至第二屏，就減小圖片了高度，保持文字區域最小高度。

老司機都不會忘記的，僅提醒下新手，每個圖標記得輸出多個比例。並且記得查看各個比例下圖標的顯示效果。

案例說明：

還是拿一個雅虎新聞的例子，大家感受下。

Android設備的系統各個廠商都做了定製化，默認的字體庫可能不同，且字體占空間大小可能不同。不同設備顯示文字會出現不同效果。設計時考慮3點：

多採用流式布局，不對單行做字數限制（如「單行顯示多少個字」「文本寬度多少」），而是定義文本容器的高寬，超出則用「…」「漸隱」或者「遮擋」等方式省略。

若較長的文本需要完整顯示，設計時預留換行空間。

若文本需要在單行完整顯示（如提示類文字），盡量控制字數（建議16字內），避免小屏不夠放置。

案例說明：

圖文混排同一行顯示時，圖片等比固定在右側顯示，文字部分區域寬度會因設備不同出現較大的差異，預留文字多行高度。如下圖不同設備下文字的展示空間有差異，需要考慮小解析度下預留多行文字空間。如圖2第二條新聞標題文字溢出的醜陋展示，建議設定一個文字區域最大高度，超出部分則隱藏。

單行出現多個文字元素時，注意元素在低dpi下的顯示層級，提前說明好該情況的覆蓋或者隱藏規則。如下圖第一個用戶名稱，在低dpi下，避免各元素交錯，而省略了超出的用戶名稱。

圖片常用的方式有固定寬度dp等比縮放高度（用於非通欄圖片）；固定高度dp等比縮放寬度（用於橫向滾動圖片，如全屏相冊中的縱向圖片）；根據屏幕寬度等比縮放（橫向通欄圖片）。設計時考慮3點：

注意圖片佔用的寬高比，避免大屏設備上占據大量空間，導致內容比例不協調同時降低了屏幕利用率。

考慮到設備屏幕密度不同，輸出圖片時別忘了輸出多個解析度。

考慮圖片寬高比過大的縮略圖處理（最常見的處理方式：高度遠大於寬度時，是給出最大區域，讓圖片等寬居中填充該區域，只顯示該區域；寬度遠大於高度時，與展示區域等高居中取部分顯示。當然也可能出現特殊顯示要求，需要根據具體情況具體處理。）

案例說明：

網易游戲相冊的全屏瀏覽中，大於設備寬高比的寬圖按照最大寬度放置，小於設備寬高比的高度按照最大高度放置。

一行多張圖片要考慮圖片的在不同設備下等比縮放帶來顯示效果的差異。排列時會有兩種情況：

1.要求在一行內顯示完，根據圖片的顯示效果決定放置的數量，超過則不顯示（如下圖1第二條新聞）

2.流式布局，當圖片寬度小於設定值時自動換行（如下圖2相冊展示，低dpi低解析度設備一行顯示3張，高的顯示4-5張，且按比例撐滿屏幕寬度）。

寬高比超出設計區域時的處理，如網路貼吧中列表的小圖模式，給出了正方形區域，當圖片非正方形時，根據寬高中的短邊等比撐滿正方形區域後，截取了圖片居中的部分顯示。

在固定區域內多元素混合放置時，文字一般採取流式布局，圖片多採用等比縮放，圖標元素多採用 彈性布局，即元素內容本身規格不變，考慮水平、垂直方向的間距做相應擴展。設備屏幕越大，在擴展方向上可以顯示更多內容，發揮了大屏幕的優勢。

彈性布局需要給出哪一個元素dp不變，哪一個元素縮放的策略。

彈性布局下部分距離標注採用百分比標注。

當有兩個等比縮放元素時考慮避免重疊的情況。

案例說明：

網易游戲的新聞列表樣式，每一條新聞區域，要求圖片dp不變，而文字區域進行彈性縮放。

下圖網易游戲專區中間的幽靈按鈕圖標為確保點按效果，按照固定dp顯示，中間間隔的寬度按照設備寬度的百分比來確定

網易游戲求交往的界面，中間卡片區域大小根據設備等比縮放，如中間用戶頭像與「同喜歡2款游戲」的文字，在設計時需要考慮產品的目標設備中最小設備下的布局顯示效果，避免出現重疊的情況。而縱向的元素數量也需要如此考慮。

Android界面適配的案例說明就寫到這里啦。

設計時多考慮各個元素（圖標、文本、圖片、區域）在不同設備的情況。當然，做設計時也不是死板的按照建議來實現，特別是固定區域下的元素放置，根據實際情況來處理即可。

Android系統的UI也在不斷進化完善，隨著設計趨勢的改變，Android除了常見的卡片、列表、浮層外，可能會有更多的展示方式，而Android設備也是逐漸淘汰ldpi與mdpi，設備的解析度逐漸變大。也就要求我們需要不斷的去了解嘗試新的設計趨勢，產出最好的方案。

這不是彩蛋哈，僅僅補充安卓設備的基礎知識，老司機完全可以忽略，供新手參考閱讀。

為展示設備的多樣化，貼出Android屏幕尺寸示意圖（藍色矩形的大小代表不同尺寸，顏色深淺則代表所佔百分比的大小。）

屏幕大小以屏幕尺寸來衡量，指屏幕的對角線的長度，單位是英寸，1英寸=2.54厘米

目前的主流尺寸：5.0" ~ 5.5" (有繼續往更大尺寸發展的趨勢，但趨於穩定)

常見的設備尺寸： 4" ~ 10" 。

手機適配參考尺寸： 4" ~ 6"

手機 + 平板適配參考尺寸： 4" ~ 10」

屏幕解析度是指在橫縱向上的像素點數，單位是px，1px=1個像素點。一般以縱向像素*橫向像素，如1960*1080。

屏幕像素密度是指每英寸上的像素點數，單位是dpi，即「dot per inch」的縮寫。目前每個屏幕像素可以認為就是一個「點」。

屏幕 dpi 的計算方式:

Android 設備中 dpi 分幾個段：

•ldpi：~ 120 dpi (幾乎絕跡)

•mdpi：~ 160 dpi (罕見)

•hdpi：~ 240 dpi (逐漸減少中)

•xhdpi：~ 320 dpi

•xxhdpi：~ 480 dpi

•xxxhdpi：~ 640dpi (目前較少)

dp(與 dip 同義) 是在 160dpi 下每個像素對應的物理尺寸，可近似理解為:

•160 dp = 1 inch

•1 dp = 1 / 160 inch = 0.15875 mm

•1 dp = 1 px (160 dpi 屏幕下)

•1 dp = 2 px (320 dpi 屏幕下)

Android的屏幕適配指標都基於物理尺寸（即屏幕的物理大小），而非像素（解析度）。為什麼呢？這里根據dp與px適配出兩種效果來說明。

按 dp 適配不同屏幕的效果如下，內容的物理尺寸變化不大:

若直接按照像素適配，出現以下情況，高像素密度的設備內容顯得特別小，影響布局與可用性：

屏幕長邊和短邊的比例。

目前手持設備的 長邊 dpi 和 短邊 dpi 普遍非常接近，可認為屏幕比例和屏幕水平、垂直像素比例一致

屏幕比例目前趨於 16:9 ~ 16:10 (8:5)

因不少設備使用了虛擬按鍵，所以通常非全屏的 app 可用面積略低，屏幕比例更接近 16:10

㈦ 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