這樣就需要我們考慮不同裝置不同的解析度，處理起來比較麻煩。
比如說，按照官方的做法，我們需要提供諸如 xx.png, [email protected], [email protected], xx~ipad.png, and [email protected] 這樣不同的,
另外還有在程式中寫大量 if (...) else if 這樣的**來區分不同的裝置, 想想就覺得煩。
尤其是像我這樣的個體開發者... 弄那麼多套. 簡直要命。
所以我的做法是, 固定乙個大小, 來相容不同的裝置。
這裡, 我把我需要的, 都按照螢幕大小為 2048 * 1536 來繪製。 也就是說, 我們的背景圖的大小是 2048 * 1536， 其他也是依照這個比例來繪製。
然後，載入每個場景的時候, 都設定場景大小為 2048 * 1536，並且顯示方式為 aspectfill。
如下, 預設的spritekit專案, 做簡單的修改: (gameviewcontroller.swift)
//
// gameviewcontroller.swift
// zombieconga
//// created by colin on 14/12/21.
//import uikit
import spritekit
class gameviewcontroller: uiviewcontroller
override func prefersstatusbarhidden() -> bool
}
我們知道. 2048 * 1536 是ipad retina 的解析度。也是我們需要適配的裝置裡面解析度最高的。 所以我選擇了這個大小。讓它來相容解析度低的裝置。（不會導致失真, 當然，造成不必要的開銷是在所難免的，但是相對為每個裝置準備一套還是更加優秀的）
也就是說， 2048 * 1536 在ipad retina上是完美顯示的。 那在其他裝置上呢？ 這裡就要依靠 aspectfill了。
簡單看一下下面這張圖:
橙色整體區域表示我們場景的真實大小。 黑色線框內的區域表示場景展示在裝置上的真實大小。
看下ipad retina。 他的橙色區域和 黑色線框內的區域是完美吻合的，也就是說在裝置上能完整顯示。
再看下iphone4s。 它的真實解析度應該是 960 * 640 (這裡是橫屏顯示)， 但是黑色線框內的區域確實2048 * 1136，是原來的2.1倍。
這要歸功於 aspectfill了。 接觸過ios開發的應該都知道, aspectfill是顯示的一種模式。它保持縱橫比縮放，影象可能不完全顯示。（可以理解成兩個方向一起放縮，當兩個方向都達到螢幕大小時候，才停止放縮。這時候先達到螢幕大小的那個因為之後的繼續放縮，會導致那個方向上的影象被截去。故顯示不完全）
同理，iphone6 的顯示效果如圖所示。
• ipad retina [4:3 or 1.33]: displayed as-is to fit the 2048x1536 screen size.
• ipad non-retina [4:3 or 1.33]: aspect fill will scale a 2048x1536 playable area by 0.5 to fit the 1024x768 screen size.
• iphone 4s [3:2 or 1.5]: aspect fill will scale a 2048x1366 playable area by 0.47 to fit the 960x640 screen size.
• iphone 5 [16:9 or 1.77]: aspect fill will scale a 2048x1152 playable area by 0.56 to fit the 1136x640 screen size.
• iphone 6 [16:9 or 1.77]: aspect fill will scale a 2048x1152 playable area by 0.64 to fit the 1334x750 screen size.
• iphone 6 plus [16:9 or 1.77]: aspect fill will scale a 2048x1152 playable area by 0.93 to fit the 1920x1080 screen size.
總的來說, 使用這樣的方法，相對來說讓不同裝置間的操作統一了（我們的操作都以場景大小 2048*1536為準）。
但是從上也能很直觀的看出，場景中有些區域是顯示不完整的。 比如看iphone6，如果把乙個精靈放在 (0, 0)點， 那麼就有可能看不到了，如果那個精靈不夠大的話，因為（0，0）點不再裝置螢幕顯示區域內。
但是，相對與一般的逐個適配，我還是比較推崇上述做法。
iOS開發日誌 多螢幕適配
ios現在已經進入雜屏時代，想想5年前的320 480跟320 568.在iphone6的年代，我們多數的適配方案是簡單的縮放，然而現在已經進入齊劉海時代，這種方案已經不適合了，我們不得不使用別的適配方案，這裡簡單理一下自動布局 trait variations size class 自動布局這裡就...
iOS 螢幕適配
螢幕適配 1 螢幕適配的發展過程 計算frame autoreszing 父控制項和子控制項的關係 autolayout 任何控制項都可以產生關係 sizeclass 沒有螢幕適配，直接使用frame固定子控制項的大小 螢幕大小一樣，但是如果進行ipad開發，就需要考慮螢幕適配 螢幕大小不一樣，需要...
iOS螢幕適配
ios的螢幕適配從純frame到autoresizingmask再到autolayout,autoresizingmask autolayout sizeclassesautoresizingmask和autolayout不相容 sizeclasses依賴autolayout autoresizin...