『壹』 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兼容性適配（一）—— 設備兼容性概覽
Android 適用於眾多類型的設備，從手機到平板電腦和電視都能搭載使用。作為開發者，如此廣泛的設備類型能為您的應用帶來廣大的潛在受眾群體。為了能在所有這些設備上順利運行，應用應該容許部分設備功能的變化，並提供可適應不同屏幕配置的靈活界面。
隨著您進一步閱讀 Android 開發相關內容，您可能會在各種語境下遇到「兼容性」一詞。兼容性有兩種類型：設備兼容性和應用兼容性。
作為應用開發者，您無需擔心設備是否兼容 Android，因為只有與 Android 兼容的設備才會附帶 Google Play 商店或該設備的官方手機應用市場。因此，您可以放心，通過Google Play 商店和官方手機應用市場安裝您的應用的用戶使用的是 Android 兼容設備。
不過，您確實需要考慮您的應用是否兼容每一種可能的設備配置。由於 Android 以各種設備配置運行，因此部分功能並不適用於所有設備。例如，某些設備可能未配備羅盤感測器。如果應用的核心功能需要使用羅盤感測器，那麼應用只能與帶有羅盤感測器的設備兼容。
應用可通過平台 API 利用 Android 支持的各種功能。有些功能基於硬體（例如羅盤感測器），有些功能基於軟體（如應用窗口微件），有些功能則依賴於平台版本。並非每台設備都支持所有功能，因此您可能需要根據應用所需的功能控制應用在設備上的可用性。
要盡可能擴大應用的用戶群，您應設法使用單個 APK 支持盡可能多的設備配置。在大多數情況下，要實現這一目標，您可以在運行時停用可選功能，並為應用資源提供針對不同配置的替代選項（例如針對不同屏幕尺寸的不同布局）。不過，如果需要，您可以根據以下設備特徵，通過 Google Play 商店限制應用在設備上的可用性：
為了讓您根據設備功能管理應用的可用性，Android 為可能並不適用於所有設備的任何硬體或軟體功能定義了功能 ID。例如，羅盤感測器的功能 ID 為 FEATURE_SENSOR_COMPASS，而應用微件的功能 ID 為 FEATURE_APP_WIDGETS。
根據需要，要在用戶的設備不具備特定功能時阻止用戶安裝您的應用，您可以通過應用清單文件中的<uses-feature>元素聲明這一點。
例如，如果您的應用在沒有羅盤感測器的設備上沒有意義，您可以使用以下清單標記聲明需要羅盤感測器：
Google Play 商店會將您的應用所需的功能與每個用戶的設備上可用的功能進行比較，以確定您的應用是否與每台設備兼容。如果設備不具備您的應用所需的所有功能，則用戶無法安裝您的應用。
但是，如果應用的主要功能不需要某項設備功能，則應將required屬性設置為 "false"並在運行時檢查是否有該設備功能。如果應用功能在當前設備上不可用，請適當降級相應的應用功能。例如，您可以通過調用hasSystemFeature()來查詢功能是否可用，如下所示：
Java
Kotlin
不同的設備可能會運行不同版本的 Android 平台，例如 Android 4.0 或 Android 4.4。每個後續的平台版本通常會添加之前版本中不可用的新 API。為表明可用的 API 集，每個平台版本都會指定API 級別。例如，Android 1.0 是 API 級別 1，而 Android 4.4 是 API 級別 19。
通過 API 級別，您可以使用<uses-sdk>清單標記及其minSdkVersion屬性來聲明應用兼容的最低版本。例如，Android 4.0（API 級別 14）中添加了 日歷提供程序 API。如果您的應用在沒有這些 API 的情況下無法運行，您應將 API 級別 14 聲明為應用的最低支持版本。
minSdkVersion屬性聲明應用兼容的最低版本，targetSdkVersion屬性聲明應用經過優化後適用的最高版本。
不過，請注意<uses-sdk>元素中的屬性會被替換為build.gradle文件中的相應屬性。因此，如果您使用的是 Android Studio，則必須在其中指定minSdkVersion和targetSdkVersion值：
要詳細了解build.gradle文件，請參閱 如何配置編譯版本 。
每個後續版本的 Android 都為使用之前平台版本的 API 構建的應用提供兼容性，因此您的應用應始終與未來版本的 Android 兼容，同時使用已記錄的 Android API。
注意 ： targetSdkVersion 屬性不會阻止您的應用安裝在高於指定值的平台版本上，但它很重要，因為它向系統指示您的應用是否應繼承較新版本中的行為更改。如果您不將 targetSdkVersion 更新到最新版本，則系統會認為您的應用在最新版本上運行時需要一些向後兼容性行為。例如，在 Android 4.4 中的行為更改 中，使用 AlarmManager API 創建的鬧鍾現在默認不精確，因此系統可以批量處理應用鬧鍾並節省系統電量，但如果您的目標 API 級別低於「19」，則系統會為您的應用保留之前的 API 行為。
不過，如果您的應用使用的是較新平台版本中添加的 API，但其主要功能並不需要這些 API，則應在運行時檢查 API 級別，並在 API 級別過低時適當降級相應的功能。在這種情況下，請將 minSdkVersion 盡量設置為適用於應用主要功能的最低值，然後將當前系統的版本 SDK_INT 與 Build.VERSION_CODES 中對應於您要檢查的 API 級別的一個代號常量進行比較。例如：
Android 可在各種尺寸的設備上運行，包括手機、平板電腦和電視。為了按照屏幕類型對設備進行分類，Android 為每種設備定義了兩個特徵：屏幕尺寸（屏幕的物理尺寸）和屏幕密度（屏幕上像素的物理密度，稱為 DPI）。為了簡化不同的配置，Android 將這些變體歸納成組，使它們更容易作為定位目標：
四種廣義的尺寸：小、標准、大和特大。
還有幾種廣義的密度：mdpi（中）、hdpi（高）、xhdpi（超高）、xxhdpi（超超高）等。
默認情況下，您的應用會兼容所有屏幕尺寸和密度，因為系統會根據需要對各個屏幕的界面布局和圖片資源進行相應的調整。不過，您應針對不同的屏幕尺寸添加專門的布局，針對常見的屏幕密度添加優化的點陣圖圖片，以優化每種屏幕配置的用戶體驗。
『叄』 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 屏幕適配
摘自： 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個人感覺好處就是藍湖上尺寸多少你就寫多少就行