android適配方案

① 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 10（29）適配方案簡要說明

Android 10（29）適配方案簡要說明

1、根據Google官方文檔說明，Android10引入了大量變更

官方文檔： https://developer.android.google.cn/about/versions/10/highlights?hl=zh_cn

1.1、Android 10 中的隱私權變更

1.1.1重大隱私權變更

分區存儲

針對外部存儲的過濾視圖，可提供對特定於應用的文件和媒體集合的訪問許可權 訪問和共享外部存儲中的文件的應用 使用特定於應用的目錄和媒體集合目錄

增強了用戶對位置許可權的控制力

僅限前台許可權，可讓用戶更好地控制應用對設備位置信息的訪問許可權 在後台時請求訪問用戶位置信息的應用 確保在沒有後台位置信息更新的情況下優雅降級

使用 Android 10 中引入的許可權在後台獲取位置信息

系統執行後台 Activity

針對從後台啟動 Activity 實施了限制 不需要用戶互動就啟動 Activity 的應用 使用通知觸發的 Activity

不可重置的硬體標識符

針對訪問設備序列號和 IMEI 實施了限制 訪問設備序列號或 IMEI 的應用 使用用戶可以重置的標識符

無線掃描許可權

訪問某些 WLAN、WLAN 感知和藍牙掃描方法需要獲得精確位置許可權 使用 WLAN API 和藍牙 API 的應用 針對相關使用場景請求 ACCESS_FINE_LOCATION 許可權

1.1.2更多隱私權變更

標識符和數據： 針對硬體標識符（如 IMEI、序列號、MAC 和類似數據）實施了新限制。

移除了聯系人親密程度信息

隨機分配 MAC 地址

對 /proc/net 文件系統的訪問許可權實施了限制

對不可重置的設備標識符實施了限制

限制了對剪貼板數據的訪問許可權

保護 USB 設備序列號

攝像頭和連接性： 針對攝像頭元數據和連接 API 提供了更強大的保護措施。 對訪問攝像頭詳情和元數據的許可權實施了限制

對啟用和停用 WLAN 實施了限制

對直接訪問已配置的 WLAN 網路實施了限制

一些電話 API、藍牙 API 和 WLAN API 需要精確位置許可權

許可權 ： 針對許可權模型和要求的一些變更。

限制對屏幕內容的訪問

面向用戶的許可權檢查（針對舊版應用）

身體活動識別

從界面中移除了許可權組

1.2影響應用的行為變更

文檔： https://developer.android.google.cn/about/versions/10/behavior-changes-all?hl=zh_cn

限制非 SDK 介面： 為了幫助確保應用的穩定性和兼容性，Android 平台開始限制應用在 Android 9（API 級別 28）中使用非 SDK 介面。Android 10 包含更新後的受限制非 SDK 介面列表（基於與 Android 開發者之間的協作以及最新的內部測試）。我們的目標是在限制使用非 SDK 介面之前確保有可用的公開替代方案。

手勢導航： 從 Android 10 開始，用戶可以在設備中啟用手勢導航。用戶啟用後，手勢導航會影響設備上的所有應用，無論應用是否以 API 級別 29 為目標平台。例如，如果用戶從屏幕邊緣向內滑動，系統會將該手勢解讀為「返回」導航，除非應用針對屏幕的相應部分明確替換該手勢。

NDK 方面的變更

共享對象不得包含文本重定位

Bionic 庫和動態鏈接器路徑變更

系統二進制文件/庫會映射到只執行內存

安全方面的變更

 TLS 1.3 默認處於啟用狀態

TLS 不信任使用 SHA-1 簽名的證書

KeyChain 行為變更和改進

其他 TLS 和加密更改

WLAN 直連廣播

在 Android 10 中，以下與 WLAN 直連相關的廣播不具有粘性：

WIFI_P2P_CONNECTION_CHANGED_ACTION

WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

如果的應用依賴於在注冊時接收這些廣播（因為其之前一直具有粘性），請在初始化時使用適當的 get() 方法獲取信息。

WLAN 感知功能  

Android 10 擴大了支持范圍，現在可以使用 WLAN 感知數據路徑輕松創建 TCP/UDP 套接字。要創建連接到 ServerSocket 的 TCP/UDP 套接字，客戶端設備需要知道伺服器的 IPv6 地址和埠。這在之前需要通過頻外方式進行通信（例如使用 BT 或 WLAN 感知第 2 層消息傳遞），或者使用其他協議（例如 mDNS）通過頻內方式發現。而藉助 Android 10，可以將此類消息作為網路設置的一部分進行傳遞。

Go 設備上的 SYSTEM_ALERT_WINDOW

在 Android 10（Go 版本）設備上運行的應用無法獲得 SYSTEM_ALERT_WINDOW 許可權。這是因為繪制疊加層窗口會使用過多的內存，這對低內存 Android 設備的性能十分有害。

如果在搭載 Android 9 或更低版本的 Go 版設備上運行的應用獲得了 SYSTEM_ALERT_WINDOW 許可權，則即使設備升級到 Android 10，也會保留此許可權。不過，尚不具有此許可權的應用在設備升級後便無法獲得此許可權了。

如果 Go 設備上的應用發送具有 ACTION_MANAGE_OVERLAY_PERMISSION 操作的 intent，則系統會自動拒絕此請求，並將用戶轉到設置屏幕，上面會顯示不允許授予此許可權，原因是它會減慢設備的運行速度。如果 Go 設備上的應用調用 Settings.canDrawOverlays()，則此方法始終返回 false。同樣，這些限制不適用於在設備升級到 Android 10 之前便已收到 SYSTEM_ALERT_WINDOW 許可權的應用。

關於以舊版 Android 系統為目標平台的應用的警告

在搭載 Android 10 或更高版本的設備上，如果用戶首次運行以 Android 5.1（API 級別 22）或更低版本為目標平台的應用，則會看到警告。如果此應用要求用戶授予許可權，則系統會先向用戶提供調整應用許可權的機會，然後才會允許此應用首次運行。

由於 Google Play 的目標 API 方面的要求，用戶只有在運行最近未更新的應用時才會看到這些警告。對於通過其他商店分發的應用，我們也將於 2019 年引入類似的目標 API 方面的要求。如需詳細了解這些要求，請參閱在 2019 年擴展目標 API 級別方面的要求。

移除了 SHA-2 CBC 加密套件

以下 SHA-2 CBC 加密套件已從平台中移除：

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

這些加密套件不如使用 GCM 的類似加密套件安全，並且大多數伺服器要麼同時支持這些加密套件的 GCM 變體和 CBC 變體，要麼二者均不支持。

應用使用情況的變更

UsageStats 應用使用情況方面的改進 - 當在分屏或畫中畫模式下使用應用時，Android 10 現在能夠使用 UsageStats 准確地跟蹤應用使用情況。此外，Android 10 可以正確地跟蹤免安裝應用的使用情況。

按應用開啟灰度模式 - Android 10 可針對各個應用設置灰度顯示模式。

按應用開啟干擾模式 - Android 10 可以選擇性地將應用設置為「干擾模式」，此時系統會禁止顯示其通知，並且不會將其顯示為推薦的應用。

暫停和播放 - 在 Android 10 中，暫停的應用無法播放音頻。

HTTPS 連接變更

如果在 Android 10 上運行的應用將 null 傳遞給 setSSLSocketFactory()，則會出現 IllegalArgumentException。在以前的版本中，將 null 傳遞給 setSSLSocketFactory() 與傳入當前的默認 SSL 套接字工廠效果相同。

android.preference 庫已棄用

從 Android 10 開始，將棄用 android.preference 庫。開發者應該改為使用 AndroidX preference 庫，這是 Android Jetpack 的一部分。如需獲取其他有助於遷移和開發的資源，請查看經過更新的設置指南以及我們的公開示例應用和參考文檔。

ZIP 文件實用程序庫變更

Android 10 對 java.util.zip 軟體包（用於處理 ZIP 文件）中的類進行了以下變更。這些變更會讓庫的行為在 Android 和使用 java.util.zip 的其他平台之間更加一致。

Inflater

在以前的版本中，如果在調用 end() 之後調用 Inflater 類中的某些方法，這些方法會拋出 IllegalStateException。在 Android 10 中，這些方法會改為拋出 NullPointerException。

ZipFile

在 Android 10 及更高版本中，如果所提供的 ZIP 文件不包含任何文件，則 ZipFile 的構造函數（採用的參數類型為 File、int 和 Charset）不會拋出 ZipException。

ZipOutputStream

在 Android 10 及更高版本中，如果 ZipOutputStream 中的 finish() 方法嘗試為不包含任何文件的 ZIP 文件寫入輸出流，則此方法不會拋出 ZipException。

攝像頭變更

很多使用攝像頭的應用都會假定如果設備採用縱向配置，則物理設備也會處於縱向，正如攝像頭方向中所述。在過去可以做出這樣的假定，但隨著可用的設備類型（例如可折疊設備）的擴展，這一情況發生了變化。針對這些設備做出這樣的假定可能導致相機取景器的顯示產生錯誤的旋轉和/或縮放。

以 API 級別 24 或更高級別為目標平台的應用應該明確設置 android:resizeableActivity，並提供必要的功能來處理多窗口操作。

電池用量跟蹤

從 Android 10 開始，只要在發生重大充電事件之後拔下設備電源插頭，SystemHealthManager 就會重置其電池用量統計信息。一般來說，重大充電事件指的是設備電池已充滿，或者設備電量從幾乎耗盡變為即將充滿。

在 Android 10 之前，無論何時拔下設備電源插頭，無論電池電量有多微小的變化，電池用量統計信息都會重置。

Android Beam 已棄用

在 Android 10 中，我們正式棄用了 Android Beam，這是一項舊版功能，可通過近距離無線通信 (NFC) 在多個設備之間啟動數據共享。我們還棄用了一些相關的 NFC API。Android Beam 仍可供需要的設備製造商合作夥伴使用，但它已不再處於積極的開發階段。不過，Android 仍將繼續支持其他的 NFC 功能和 API，並且從標簽和付款中讀取數據等使用場景仍將繼續按預期執行。

③ 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 10、11 存儲適配總結

鏈接：https://www.jianshu.com/p/d5573e312bb8

先來看看存儲區域劃分

1、分區存儲原理

1、App訪問自身內部存儲空間、訪問外部存儲空間-App私有目錄不需要任何許可權(這個與Android 10.0之前一致)

2、外部存儲空間-共享存儲空間、外部存儲空間-其它目錄 App無法通過路徑直接訪問，不能新建、刪除、修改目錄/文件等

3、外部存儲空間-共享存儲空間、外部存儲空間-其它目錄 需要通過Uri訪問

分區存儲的變更在於第二點、第三點。

2、Android 10.0 存儲訪問方式變更地方在於

自帶外部存儲-共享存儲空間和自帶外部存儲-其它目錄

以上兩個地方不能通過路徑直接訪問文件，而是需要通過Uri訪問。

3、Android 10/11 存儲適配建議

通過分析Android 10/11存儲適配方式，了解到了不同的系統需要如何進行適配，此時就需要一個統一的適配方案了。

適配核心

分區存儲是核心，App自身產生的文件應該存放在自己的目錄下：

/sdcard/Android/data/packagename/ 和/data/data/packagename/

這兩個目錄本App無需申請訪問許可權即可申請，其它App無法訪問本App的目錄。

適配共享存儲

共享存儲空間里的文件需要通過Uri構造輸入輸出流訪問，Uri獲取方式有兩種：MediaStore和SAF。

適配其它目錄

在Android 11上需要申請訪問所有文件的許可權。

第一步

在AndroidManifest.xml里添加如下欄位：

許可權聲明：

<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/><uses-permissionandroid:name="android.permission.READ_EXTERNAL_STORAGE"/><uses-permissionandroid:name="android.permission.MANAGE_EXTERNAL_STORAGE"/>

在<application/>標簽下添加如下欄位：

android:requestLegacyExternalStorage="true"

第二步

如果需要訪問共享存儲空間，則判斷運行設備版本是否大於等於Android6.0，若是則需要申請WRITE_EXTERNAL_STORAGE 許可權。拿到許可權後，通過Uri訪問共享存儲空間里的文件。

如果需要訪問其它目錄，則通過SAF訪問

第三步

如果想要做文件管理器、病毒掃描管理器等功能。則判斷運行設備版本是否大於等於Android 6.0，若是先需要申請普通的存儲權。若運行設備版本為Android 10.0，則可以直接通過路徑訪問/sdcard/目錄下文件(因為禁用了分區存儲)；若運行設備版本為Android 11.0，則需要申請MANAGE_EXTERNAL_STORAGE 許可權。

⑤ 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機型適配總結

解析度對應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里調整字體尺寸以後的效果——窗口大小不變，只有文字大小改變。

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