IOS開發之尺寸
在移動端或者前端開發中,UI圖通常是帶標註的,指定某個控制元件的長寬等屬性,一般UI給的是68px,72px這樣的樣式,但是我們在開發過程中通常又並不是完全按照上面的標註去設定值,有時候需要將這個標註除以2或者除以3在進行賦值給frame,這其中的原因是因為標註一般都是按px格式給的,但是iOS底層繪製的時候是按照pt為單位進行繪製,這兩個的區別在於:
- px就是表示pixel,畫素,是螢幕上顯示資料的最基本的點。px是一個點,它不是自然界的長度單位,誰能說出一個“點”有多長多大麼?可以畫的很小,也可以很大。如果點很小,那畫面就清晰,我們稱它為“解析度高”,反之,就是“解析度低”。所以,“點”的大小是會“變”的,也稱為“相對長度”。
- pt就是point,是印刷行業常用單位,等於1/72英寸。pt全稱為point,但中文不叫“點”,查金山詞霸可以看到,確切的說法是一個專用的印刷單位“磅”,大小為1/72英寸。所以它是一個自然界標準的長度單位,也稱為“絕對長度”。
在瀏覽網頁過程中,所有的“大”“小”概念,都是基於“螢幕”這個“介面”上。“螢幕”上的各種資訊,包括文字、圖片、表格等等,都會隨螢幕的解析度變化而變化,一個100px寬度大小的圖片,在800×600解析度下,要佔螢幕寬度的1/8,但在1024×768下,則只佔約1/10。所以如果在定義字型大小時,使用px作為單位,那一旦使用者改變顯示器解析度從800到1024,使用者實際看到的文字就要變“小”(自然長度單位),甚至會看不清,影響瀏覽。
那是不是用pt做單位就沒這樣的問題呢?錯!問題同樣出現。剛才的例子已經很清楚的說明,在不同解析度下,無論是px還是pt,都會改變大小。以現在的電腦螢幕情況,還沒有一種單位可以保證,在不同解析度下,一個文字大小可以“固定不變”。因為這很難以實現也不是很有必要:全球電腦使用者以億來數,螢幕從14寸到40寸甚至更高都有,螢幕大小不同,解析度也不同,要保證一個字型在所有使用者面前大小一樣,實在是MISSION IMPOSSIBLE。
目前iOS的手機螢幕的解析度隨著機型的變化樣一直在變化,那麼我們在做開發時要如何做好適配呢?這就需要我們瞭解更多的關於iOS開發過程中的尺寸相關的一些知識了。
1.iPhone尺寸規格
1 inch = 2.54cm = 25.4mm
手機 |
尺寸 |
邏輯解析度(pt) |
畫素解析度(px) |
Scale factor |
PPI |
3GS |
3.5-inch |
320 x 480 |
320 x 480 |
@1x |
163 |
iPhone 4 |
3.5-inch |
320 x 480 |
640 x 960 |
@2x |
326 |
iPhone 5/5S/5C/SE |
4.0-inch |
320 x 568 |
640 x 1136 |
@2x |
326 |
iPhone 6/7/8 Plus |
5.5-inch |
414 x 736 |
1080 x 1920 |
@3x |
401 |
iPhone 6/6S/7/8 |
4.7-inch |
375 x 667 |
750 x 1334 |
@2x |
326 |
iPhone X/XS |
5.8-inch |
375 x 812 |
1125 x 2436 |
@3x |
458 |
iPhone XR |
6.1-inch |
414 x 896 |
828 x 1792 |
@2x |
326 |
iPhone XR Max |
6.5-inch |
414 x 896 |
1242 x 2688 |
@3x |
458 |
2.iPhone手機寬高
上表中的寬高(width/height)為手機的物理尺寸,包括顯示屏和邊框。 以下為iPhone4s的寬高示意圖:
3.螢幕尺寸
我們通常所說的iPhone5螢幕尺寸為4英寸、iPhone6螢幕尺寸為4.7英寸,指的是顯示屏對角線的長度(diagonal)。以下為iPhone5~6+的螢幕尺寸規格示意圖:
4.畫素密度PPI
PPI(Pixel Per Inch by diagonal):表示沿著對角線,每英寸所擁有的畫素(Pixel)數目。PPI數值越高,代表顯示屏能夠以越高的密度顯示影象,即通常所說的解析度越高、顆粒感越弱。
根據勾股定理,可以得知iPhone4(s)的PPI計算公式為:
計算結果稍有出入,這是因為畫素的離散取樣有鋸齒效應。
5.縮放因子(scale factor between logic point and device pixel)
(1)Scale起源
早期的iPhone3GS的螢幕解析度是320*480(PPI=163),iOS繪製圖形(CGPoint/CGSize/CGRect)均以point為單位(measured in points):
1 point = 1 pixel(Point Per Inch=Pixel Per Inch=PPI)
後來在iPhone4中,同樣大小(3.5 inch)的螢幕採用了 ofollow,noindex" target="_blank">Retina顯示技術 ,橫、縱向方向畫素密度都被放大到2倍,畫素解析度提高到 (320x2)x(480x2)= 960x640(PPI=326), 顯像解析度提升至iPhone3GS的4倍(1個Point被渲染成1個2x2的畫素矩陣)。
但是對於開發者來說,iOS繪製圖形的API依然沿襲point(pt,注意區分印刷行業的“磅”)為單位。在同樣的邏輯座標系下(320x480):
1 point = scale*pixel(在iPhone4~6中,縮放因子scale=2;在iPhone6+中,縮放因子scale=3)。
可以理解為:
scale=絕對長度比(point/pixel)=單位長度內的數量比(pixel/point)
(2)UIScreen.scale
UIScreen.h 中定義了該屬性:
// The natural scale factor associated with the screen.(read-only) @property(nonatomic,readonly) CGFloat scaleNS_AVAILABLE_IOS(4_0);
--------------------------------------------------------------------------------
This value reflects the scale factor needed to convert from the default logical coordinate space into the device coordinate space of this screen.
The default logical coordinate space is measured using points. For standard-resolution displays, the scale factor is 1.0 and one point equals one pixel. For Retina displays, the scale factor is 2.0 and one point is represented by four pixels.
--------------------------------------------------------------------------------
為了自動適應解析度,系統會根據裝置實際解析度,自動給UIScreen.scale賦值,該屬性對開發者只讀。
(3)UIScreen.nativeScale
iOS8新增了nativeScale屬性:
// Native scale factor of the physical screen @property(nonatomic,readonly) CGFloat nativeScale NS_AVAILABLE_IOS(8_0);
以下是iPhone6+下的輸出,初步看來 nativeScale與scale沒有太大區別 :
(lldb)p (CGFloat)[[UIScreen mainScreen] scale] (CGFloat) $1 = 3 (lldb) p(CGFloat)[[UIScreen mainScreen] nativeScale] (CGFloat) $2 = 3
(4)機型判別
在同樣的邏輯解析度下,可以通過scale引數識別是iPhone3GS還是iPhone4(s)。以下基於nativeScale引數,定義了探測機型是否為iPhone6+的巨集:
// not UIUserInterfaceIdiomPad #define IS_IPHONE (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone) // detect iPhone6 Plus based on its native scale #define IS_IPHONE_6PLUS (IS_IPHONE && [[UIScreenmainScreen] nativeScale] == 3.0f)
那麼,同樣的解析度和scale,如何區分機型iPhone4與4s、iPhone5與5s呢?通過 [[UIDevice currentDevice] model] 只能判別iPhone、iPad、iPod大類,要判斷iPhone具體機型型號,則需要通過 sysctlbyname("hw.machine") 獲取詳細的裝置引數資訊予以甄別。
6. Resolutions & Rendering
7. @2x / @3x 以及高倍圖適配
(1)@2x
@2x means the same “double”retina resolution that we’veseen on all iOS devices with retina displays to date, where each virtual pointin the user interface is represented by two physical pixels on thedisplay in each dimension, horizontal and vertical.
iPhone3GS時代,我們為一個應用提供圖示(或按鈕提供貼圖),只需要icon.png。針對現在的iPhone4~6 Retina顯示屏,需要製作額外的@2x高解析度版本。
例如在iPhone3GS中,scale=1,用的圖示是50x50pixel(logicalimage.size=50x50point);在iPhone4~6中,scale=2,則需要100×100pixel(logical image.size=50x50point,乘以image.scale=dimensions in pixels),並且命名為[email protected]。
如果APP要同時相容iPhone3GS~iPhone6,則需要提供icon.png/[email protected]兩種解析度的圖片。
(2)@3x
@3x means a new “triple” retina resolution, where eachuser interface point is represented by three display pixels. A single @2x pointis a 2 × 2 square of 4 pixels; an @3x point is a 3 × 3 square of 9 pixels.”
iPhone6+在實際渲染時,downsampling/1.15(1242x2208->1080x1920),準確的講,應該是@2.46x。蘋果為方便開發者用的是@3x的素材,然後再縮放到@2.46x上。
參考:《 為什麼iPhone 6 Plus要將3x渲染的2208x1242解析度縮小到1080p螢幕上? 》《 詳解 iPhone 6 Plus 的奇葩解析度 》《 iPhone 6 Plus螢幕解析度 》
如果APP要同時相容iPhone3GS~iPhone6+,則需要提供icon.png/[email protected]/[email protected]三種解析度的圖片。
需要注意的是,iOS APP圖示的 尺寸 和命名都需要遵守相關規範。
(3)高倍圖檔案命名
對於iPhone3、4/5/6、6+三類機型,需要按解析度提供相應的高倍圖並且檔名新增相應字尾,否則會拉伸(stretchable/resizable) 失真 (模糊或邊角出現鋸齒)。
以下基於UIImage的兩類初始化API簡介高倍圖的適配:
- +imageNamed:該方法使用系統快取,適合表檢視重複載入影象的情形。同時該API根據UIScreen的scale,自動查詢包含對應高倍圖字尾名(@2x)的檔案,如果找到二倍圖,則image.scale=2.0,對應邏輯size大小以point度量(pixel度量的一半);如果沒找到設定預設image.scale=1.0,對應邏輯size大小同畫素尺寸。因此,使用該方法,無需特意指定高倍圖字尾。在實際執行時,系統如果發現當前裝置是Retina屏(scale=2),會自動尋找"*@2x.png"命名格式的圖片,載入針對Retina屏的圖片素材,否則會失真。
- +imageWithContentsOfFile/+imageWithData:(scale:)/-initWithContentsOfFile:/-initWithData:(scale:) 這組方法建立的UIImage物件沒有使用系統快取,並且指定檔名必須包含明確的高倍圖字尾。如果檔名包含@2x字尾,則image.scale=2.0;否則預設image.scale=1.0,同樣對於Retina屏將會失真。
- 目前,適配iPhone6+時,除了一些鋪滿全屏的大圖(LogoIcon、LaunchImage)需提供三倍圖,其他的小圖仍可沿用原有的二倍圖自適應拉伸。
8.Screen Bounds & Application Frame
(1)UIScreen.bounds
// Bounds of entire screen in points(本地座標系,起點為[0,0]) @property(nonatomic,readonly) CGRect bounds; -------------------------------------------------------------------------------- //考慮轉屏的影響,按照實際螢幕方向(UIDeviceOrientation)的寬高 #define SCREEN_WIDTH ([UIScreenmainScreen].bounds.size.width) #define SCREEN_HEIGHT ([UIScreenmainScreen].bounds.size.height) #define STATUSBAR_HEIGHT ([UIApplicationsharedApplication].statusBarFrame.size.height) //不考慮轉屏的影響,只取豎屏(UIDeviceOrientationPortrait)的寬高 #define SCREEN_WIDTH MIN([UIScreenmainScreen].bounds.size.width, [UIScreenmainScreen].bounds.size.height) #define SCREEN_HEIGHT MAX([UIScreenmainScreen].bounds.size.height, [UIScreenmainScreen].bounds.size.width) #define STATUSBAR_HEIGHT MIN([UIApplicationsharedApplication].statusBarFrame.size.width, [UIApplicationsharedApplication].statusBarFrame.size.height) --------------------------------------------------------------------------------
(2)UIScreen.nativeBounds
iOS8新增了nativeBounds屬性,輸出豎屏畫素級解析度:
// The bounding rectangle of the physical screen,measured in pixels. (read-only) // This rectangle is based on the device in a portrait-up orientation. This value does not change as the device rotates. @property(nonatomic,readonly) CGRect nativeBounds NS_AVAILABLE_IOS(8_0); //以下是iPhone6+下的輸出: -------------------------------------------------------------------------------- (lldb) poNSStringFromCGRect([(UIScreen*)[UIScreen mainScreen] bounds]) {{0, 0}, {414, 736}} (lldb) poNSStringFromCGRect([(UIScreen*)[UIScreen mainScreen] nativeBounds]) {{0, 0}, {1242, 2208}} --------------------------------------------------------------------------------
(3)UIScreen.applicationFrame
// Frame of application screen area in points (i.e.entire screen minus status bar if visible) // bounds除去系統狀態列 @property(nonatomic,readonly) CGRect applicationFrame; -------------------------------------------------------------------------------- // APPFRAME_WIDTH=SCREEN_WIDTH #define APPFRAME_WIDTH ([UIScreen mainScreen].applicationFrame.size.width) // APPFRAME_HEIGHT=SCREEN_HEIGHT-STATUSBAR_HEIGHT //注意:橫屏(UIDeviceOrientationLandscape)時,iOS8預設隱藏狀態列,此時APPFRAME_HEIGHT=SCREEN_HEIGHT #define APPFRAME_HEIGHT ([UIScreen mainScreen].applicationFrame.size.height) --------------------------------------------------------------------------------
(4)bounds和frame的區別
下圖展示了 bounds和frame的區別 :
9.機型尺寸 適配 (Screen Scale Adaption)
從iPhone3GS/iPhone4(s)過渡到iPhone5(s)時,在邏輯上寬度不變高度稍高,之前舊的素材和佈局通過 AutoresizingFlexible 簡單適配即可執行得很好,但由於高寬比增大,上下兩端出現黑粗邊(典型如LaunchImage)。從解析度的角度來看,除了需要提供LaunchImage這種滿屏圖,其他基本沿用二倍圖(@2x);從螢幕尺寸角度來看,需要對縱向排版略加調整。
從iPhone5(s)發展到iPhone6(+),由於高寬比保持不變,iOS對圖示、圖片、字型進行等比放大自適應,清晰度會有所降低。同時,絕對座標佈局會導致在大屏下出現偏左偏上的問題。從解析度的角度來看,iPhone6沿用二倍圖(@2x),但需為iPhone6+提供更高的三倍圖(@3x);從螢幕尺寸角度來看,需要重新對UI元素尺寸和佈局進行適配,以期視覺協調。
(1)按寬度適配
我們先來看一下iPhone4~6(+)的螢幕高寬比:
- iPhone4(s):解析度960*640,高寬比1.5
- iPhone5(s):解析度1136*640,高寬比1.775
- iPhone6:解析度1334*750,高寬比1.779
- iPhone6+:解析度1920*1080,高寬比1.778
可粗略認為iPhone5(s)、6(+)的高寬比是一致的(16:9),即可以等比例縮放。因此可以按寬度適配:
fitScreenWidth= width*(SCREEN_WIDTH/320)
這樣,共有iPhone3/4/5、6、6+三組寬度,在iPhone6、6+下將按比例橫向放大。
(2)按高度適配
在同樣的寬度下,iPhone4(s)的屏高比iPhone5(s)低,若縱向排版緊張,可以iPhone5(s)為基準,按高度適配:
fitScreenHeight= height*(SCREEN_HEIGHT/568)
共有iPhone3/4、5、6、6+四組高度,在iPhone3/4下將按比例縱向縮小,在iPhone6、6+下將按比例縱向放大。
這裡需要注意 iPhone/iOS雙環上網的熱點欄對縱向佈局的影響 :iPhone作為個人熱點且有連線時,系統狀態列下面會多一行熱點連線提示欄"Personal Hotspot: * Connection",縱向會下壓20pt,[UIApplication sharedApplication].statusBarFrame高度變為40pt;當所有連線都斷開時,熱點欄消失,縱向高度恢復正常為20pt。詳情可參考《 iPhone/iOS開啟個人熱點的縱向適配小結 》。
(3)按字型適配
另外,iPhone的【設定】【通用】【輔助功能】中可以設定調節【更大字型】,APP也可以按字號適配:
例如適配表檢視(UITableView:UIScrollView),無法左右滑動,因此無論字號縮放比例多大,橫向都不應超過SCREEN_WIDTH。注意限定控制元件元素內容區域寬度以及間距,並設定適當的LineBreakMode。表檢視支援上下滑動,因此縱向上的表格行高和內容區域高度可按字號縮放。
對於縱向也不支援滑動的檢視,在螢幕可見視區內排版時,最好不要隨字號縮放,否則可能超出既定寬高。
10.UI相對佈局
考慮到iPhone機型的多樣性,不可能針對iPhone4(s)、5(s)、6、6+四種螢幕尺寸出四套視覺互動稿,也不要基於某一機型從上往下、從左往右給絕對標註,而應該關注subView在superView中的相對位置(EdgeInsets/Frame/Center)以及siblingView之間的偏移(Offset),儘量給出適合Autolayout的相對佈局比例(理想情況是隻給百分比)。假如互動按照iPhone5(s)下絕對標註,則在iPhone4(s)上可能擠出螢幕底部,而在iPhone6(+)上則可能橫向偏左或縱向偏上。
開發人員基於與螢幕邊緣的間距(Margin/EdgeInsets),定位邊緣處的控制元件(釘釘子)作為參照,然後基於控制元件尺寸和間隙進行相對計算排版。 這樣,若釘子移動,相鄰控制元件將順向偏移,不會因為區域性調整而出現凌亂 。
我們擷取 iPhone5s QQ 檔案助手列表中的檔案cell,使用 Sketch Measure 對其進行測量標註。
開啟[截圖.png]檔案,由於不包含 Sketch 圖元物件,無法進行 measure 標註(提示:請在畫板中使用該功能)。因此,第一步需要對要相對標註的各個UI元素進行物件化。依次 Insert Artboard 建立圖層 frame、thumbnail、title、detail、source、button。
選中整個cell的frame(bounds),進行 Measure size:width=640px(SCREEN_WIDTH),height=168px。預設橫向尺寸和縱向參考線都居中導致標註重疊,將縱向參考線右移至合適位置;也可選中WIDTH標註圖層中的text和label元素,在不移動參考線的前提下,利用滑鼠區域性移動標註字面量。
(1)縮圖標
- 在左側邊欄layer list中選中frame,再command選中檔案型別縮圖物件thumbnail,進行 Measure spacing,丈量縮圖左側相對frame的間距為24px。
- 選中檔案型別縮圖物件thumbnail,進行 measure size,由於正方形等寬為112px*112px,故橫縱標註重疊無影響。thumbnail在frame中縱向整體居中,因此上下邊距計算均攤即可,無需再給定標註。
(2)傳輸按鈕
- 對 button 和 frame 進行 Measure spacing,丈量按鈕右側相對frame的間距為24px。
- 選中按鈕button進行 measure size,其寬高為144px*60px。橫縱標註重疊影響視覺,將縱向參考線右移至合適位置。
- button在frame中縱向整體居中,因此上下邊距計算均攤即可,無需再給定標註。
(3)檔案資訊
- 對thumbnail和detail(title、source等寬且左對齊)進行 Measure spacing,丈量圖示右側相對detail的間距為20px;對button和detail進行 Measure spacing,丈量按鈕左側相對detail間距為20px。這樣,左側釘住thumbnail,右側釘住button,中間資訊部分的寬度無需給定,計算被動約束的橫向餘量即可。具體程式設計時,呼叫 sizeWithFont/boundingRectWithSize 可動態計算每行 label 的自然寬度,一般title都會超過約束寬度,因此需設定 lineBreakMode指定Wrapping省略或Truncating截斷格式。
- 選中檔案資訊第1行標題title和第2行詳情detail,進行 Measure spacing,測量縱向相對間距10px;第2行詳情detail和第3行來源的縱向相對間距也為10px。一般 UILabel 的文字在給定字型下的縱向自然顯示無約束,呼叫 sizeWithFont/boundingRectWithSize 可動態計算每行 label 的自然高度,title的上間距和source的底間距無需給定,通過計算縱向餘量均攤即可。
可簡單的基於屏寬橫縱比例進行scale縮放,將以上測量出的標註應用到iPhone6(+)大屏下,當然互動設計工程師最好還是針對特定機型都給定適配標註。蘋果在WWDC2012 iOS6中已提出了 Auto Layout 的概念,即使用約束條件來定義檢視的位置和尺寸,以適應不同尺寸和解析度的螢幕。