本文是為“初學者”或者作為從一開始就想要學習更多跨DPI和跨平臺設計知識的中級設計師準備的序言讀物。 沒有復雜的計算和不可分析的圖表，只是按照劃分直截了當地將內容呈獻給讀者，便于讀者理解以及直接運用到設計過程中，非常實用且專業的知識，記得收藏??>

如你所見，文本變大了，準確點說是兩倍大，然而正方形還保持不變，原因就是Photoshop按照PPI值放大了pt值，結果在PPI值變為兩倍的情況下文本大小增加為原來兩倍。而用像素定義的藍色正方形，保持了原來大小。像素就是一個像素點，不管PPI怎么配置它會一直保持一個像素。造成這個差異的是用來顯示它的屏幕的PPI值。

我們需要記住的是在做數字化設計的時候，PPI只會影響你對設計的感知、你的工作流和以pt為單位的圖案例如字體。如果你在工作資源文件里包含了各種PPI配置，程序就會根據接收到的文件的PPI比例在不同的文件里調整轉移視覺的大小，這會成為一個需要解決的問題。

那么，解決方案是什么呢？就是堅持使用PPI（對于1x設計，最好控制在72-120之間）。我個人使用72PPI，因為這是Photoshop的默認配置，我的同事也是。

附加:

PPI配置對輸出到web上的設計毫無影響。PPI配置只對基于PPI獨立計量（比如PT）產生的圖案有影響。像素是任何數字化設計的度量單位保持像素比以及設計的目標，而不是PPI在進行數字化設計時使用實際的PPI配置，你會感受到它在目標設備上的樣子（以1x的web/桌面設計72-120ppi為例）。在你的文件中自始至終保持相同的PPI配置

關于這個的額外趣味閱讀：StackExchange post

iOS上的PPI處理

是時候鉆研下特定平臺的設計了。

讓我們花點時間看看2014年年初時的iOS設備。 從屏幕大小和DPI的角度來看，iOS有兩種類型的手機設備和兩種類型的筆記本/臺式電腦屏幕。

對于手機，有iPhone和iPad。 在手機分類中，有過去的3GS（iOS6依舊支持）和更高版本，其中只有iPhone 3GS是非Retina。iPhone 5以及后來的都用了和iPhone 4/4s有相同DPI的更好的屏幕。讓我們來看看下面的列表：

2014年9月Apple宣布，現在又有2個新類別的iPhone：iPhone 6和iPhone 6 Plus。

iPhone 6比5要大一點（0.7英寸左右），但是PPI相同。iPhone 6 Plus由于它的尺寸，5.5英寸，產生了iOS上新的像素比，@3x。

相較于其他iPhone，iPhone 6 Plus控制展示比較特殊的是：視覺效果降頻。

以為iPhone 6設計為例，設計的畫布為1334750px，手機上就呈現1334750的物理像素。當為iPhone 6 Plus時，手機的分辨率小于渲染的圖像，因此你設計的分辨率為22081242px，展示時降頻為19201080px。如下圖：

物理分辨率比渲染分辨率小15%，會造成一些細節問題，比如半像素使得精細的地方變模糊。分辨率如此高也是很微妙的，除非你近距離觀察。因此，在2208*1242px的畫布上設計，需要注意設計中真正精細的地方，像是分隔符。模擬如下：

感謝Paintcode的說明，看看他們專門的頁面。點擊查看

在iPod touch分類中，iPod第四代出來的時候使用的是iOS6和非Retina。iPod第五代以及后面的都使用Retina屏幕并且兼容iOS7，它的屏幕大小與iPhone 5相同。

最后說說iPad。除了iPad 第一代，其余的都用的是iOS7，同時只有iPad2和iPad mini是非Retina屏幕。從設計的角度來看，iPad mini只是普通的iPad（一樣的PPI屏幕），但是物理體積更小，也就是說它們擁有相同的分辨率，只是大小從9.7英寸減小到了7.9英寸。保持同樣的比例，便會相應地增大像素點的密度，你的虛擬資源就會顯得更小了。

至于臺式機和筆記本，我們不會全面討論Apple提供的各種尺寸的屏幕。在今天，Apple提供的幾乎都是1x像素比的Retina屏幕（Macbook，Macbook Air，舊版Macbook Pros，臺式機顯示器），Retina只應用于13和15寸的Macbook Pro。iPad和iPhone像素比是2x。為臺式機設計與手機設計不同的是，你需要以相同方式設計來覆蓋這兩種不同類別的屏幕。

當只使用一種像素比時，基于iOS和OSX的設計是非常簡單的。我建議開始設計時先用基礎的PPI（例如，100%/1x）然后增加到2x并在2x的屏幕上校驗你的設計并且生成2x的資源。當你熟悉在1x和2x之間切換設計后，就能夠直接在2x上進行設計了，低分辨率時資源更小。如果你正在為Retina屏幕設計的話（Macbook Pro），這就特別有用。

引入資源，chrome為例

如圖所示，每次請求資源需要傳送兩張圖片。非Retina下圖片名為name.png，Retina的圖片增加到@2x命名為@2x.png，這是iOS開發約定的命名規范。

如果你創建了一個圖片只用在iPad上，我們在.@2x后面加上~iPad，這僅僅只是chrome的約定。對需要的資源都這樣處理，不要只用一個版本的資源來覆蓋所有DPI。

附加, iOS規則集:

@2x的資源必須始終是1x資源的兩倍。Retina資源加上@2x.始終創建100%和200%比例的圖片。1x和2x的資源始終要保持名字相同。在100%比例下開始設計，然后做乘法。傳遞.png格式的圖片。使用pt創建規范而不是px。

Android上的PPI處理

Android平臺的設備種類比iOS多，因為任何OEM都可以生產設備并且幾乎沒有比例的限制，然后加上自己版本號。結果就是生產出幾乎無限制的屏幕大小和DPI種類，電話和平板電腦一樣大，或者電話和平板電腦一樣小的情況比比皆是。為此，你的設計總是需要做適配。

在這個部分，我們將采用不同于iOS的方法，我們先來討論下像素比和DPI分類。

Android設備可以分為兩類：手機和平板電腦。這兩種設備又可以按照不同DPI分為：ldpi、mdpi、 tvdpi、 hdpi、 xhdpi、 xxhdpi和xxxhdpi。

幸好，有些比其他使用得更加頻繁，有些甚至已經棄用了。

首先我們要找到等價于iOS上1x的基礎單位。在Android上，這個基礎單位就是MDPI。

讓我們看看下面列表的像素比。

是的，很多，而且還沒有完，還有一個落下了。

實際上，目前正在使用的DPI有4個：MDPI, HDPI, XHDPI和XXHDPI。 LDPI是過時的DPI，現在已經不再使用，TVDPI是TV UI的特殊例子，在2012年版的Nexus 7中短暫使用過，在手機和平板電腦的使用中沒有考慮的必要。盡管如此，TVDPI的像素比（1.33x）還是被用在一些安卓系統的設備上，像是LG G手表，我們后面來討論這個。

讓我們結合帶著各自DPI的Android手機和平板電腦全面客觀地看待事物。

也許在現在這個時候有一個設備使用XXXHDPI的實際app資源，但也不是很常見。如果你能用額外時間生產XXXHDPI資源，你的app便不會過時。

引入資源，chrome為例

每次請求資源都需要傳遞一組4張圖片，從MDPI到XXHDPI，無需考慮LDPI。注意，在下面的chrome版本中，TVDPI的輸入在這個例子里的5張圖片里也很清楚。

和iOS一樣，我建議把100%或者1x的像素比作為你設計的基礎，這會讓設計在適配其他像素比的時候容易一點，特別是在像素比為1.33和1.5的安卓系統上。

看看下面安卓上chrome的返回按鈕的例子。

DPI后面跟著的建議名稱不是安卓官方指南強制要求的，這是我們為資源取名的方式，因為現在有限的設計工具很難給每個資源定義一個路徑。 考慮到一個資源有時有上百個資源文件，站在設計師的角度來說這是使輸出過程不那么痛苦以及避免重命名錯誤的一個途徑。資源在資源倉庫里面的存儲方式是有結構的，參考后面：

drawable-mdpi/asset.pngdrawable-hdpi/asset.pngetc…

如你所見，資源被截成了3232dp的正方形，Android像素比也會是小數。當用1.33或者1.5乘以一個數的時候，最后的結果很有可能就是小數。在這種情況下你需要通過四舍五入來讓數字變得有效。在這個例子中，321.33=42.56所以四舍五入之后是43px。

你需要注意以像素為單位的元素，比如筆畫。你需要確保你的筆畫既不是1px寬也不是2px同時也不像屏幕分辨率部分描述的那樣模糊。

附加, Android規則集:

Android有7種不同的DPI，你需要關注其中的4個：mdpi,hdpi,xhdpi,xxhdpi，如果希望你的app面向未來，可以關注XXXHDPI。MDPI是基礎的DPI或者1x像素比Android使用dp代替pt當作參數規格，但是他們是一樣的。用你最好的判斷來處理小數像素比。傳遞.png格式圖片。確保檢驗命名約定，與執行負責人共同完成輸出進程。

Mac、Chrome OS上的PPI

Mac（OSX）和Chrome OS在處理PPI方面是十分相似的。 兩個OS都支持常規的PPI（100%）和hi-res/retina PPI(200%)。像iPhone和iPad，就只有2x像素比。

即使大多數的用戶都使用Mac和Chrome OS，但是也有用戶會在低分辨率的設備上使用，我強烈建議將你的app面向未來的高端屏幕。面向未來對于ChromeOS意味著為Web-app或者網站創建hi-res資源，那絕不是浪費時間。當前有3種筆記本處理PPI，13寸、15寸Macbook pro以及Chromebook Pixel。除此之外，Chromebook Pixel還處理了touch。

引入資源，chrome為例

Chrome的工具欄按鈕資源就是相似性最好的例子。我們在兩個平臺上使用完全相同按鈕，即使代碼不同，視覺上也是一樣的?？聪旅孢@個chrome菜單按鈕的例子。

附加:

Chrome OS和OSX像素比相同，都是2.Chrome OS高分辨率展示也處理touch。

可拉伸資源

不管你的app是在桌面或者手機上。你通常都會引入可拉伸資源。

可拉伸資源的建立會使代碼在沒有減少渲染的情況下比實際需要的多。

他們與可重復資源即使有的時候展示結果一樣，工作方式也是不同的。

看看下面這個Chrome的例子。iOS上的工具欄在整個屏幕上只用了一個在x軸上平鋪的超細資源。

現在這種方式已經過時了，讓我們來看看不同平臺如何處理可拉伸資源。

iOS上的可拉伸資源

對iOS的設計師來說這個很簡單，因為拉伸在代碼里面定義比資源片段或者標記方式好。所有需要做的就是提供一個基礎圖片，如果你自己還沒有實現這個，可以將你的資源規范定義為水平或者豎直可擴展，或者兩者均可?？纯聪旅孢@個iOS上Chrome的默認按鈕的例子。

Android上的可拉伸資源

Android有和iOS不一樣的處理可拉伸資源的方式，它更依賴設計師一點。

在這個平臺你將采用九宮格，這些輔助線包括了4條圍繞資源本身的線。他們必須被當作資源的一部分來傳遞片段/圖片，用它來準確的呈現視覺規格。

他們定義了兩個區域：可拉伸區域和填充區域。一旦定義好，代碼就只會拉伸可拉伸區域，并把內容放在你定義的填充區域。

看看下面的例子，就是你前面看到的Chrome默認按鈕的Android版本。為了演示，我把他放大了。

如你所見，這個九宮格是一組4條純白色的bar。他們在任何DPI下都是寬1px，這是代碼表示的。可拉伸區域不包括圓角因為圓角不能平鋪開（否則看起來很難看）。在這個例子中，我們給按鈕添加了規格允許范圍內10dp的padding。.9也需要平鋪并且截斷部分要100%透明。如果不這樣，他就不能正常工作，需要修改。