iOS多分辨率適配綜述

最近在掘金上分享了一篇關於性能優化文章iOS性能優化系列篇之「優化整體原則」，第一次發表文章在網上，結果收到了好多人的正面的反饋，受到了一點點鼓舞，這篇文章是好久之前組內作的一個分享，整理成文字分享給你們，裏面主要內的是一些關於iOS佈局經常使用的技術和多分辨率適配的一些方案，還略微延伸到其餘平臺的多分辨率適配方案，內容大可能是一些資料的整理和綜述，但願你們可以喜歡。

iOS平臺經常使用佈局技術

Frame

• 定義：計算絕對座標，賦值給UIView的frame屬性。

• 優勢：使用簡單直接，無學習成本。

• 缺點：不夠靈活，在多分辨率適配或者橫豎屏變化時，UIView很難根據要求自動改變佈局，若是要寫出adaptive的界面，須要根據不一樣屏幕方向、分辨率、機型等信息，相應的寫不少frame變化的代碼。

• 第三方庫：設置frame的一些方便的第三方庫， 在必定程度上解決了這些問題。好比

  1.Facade連接

  2.ios-view-frame-builder連接

  3.Neon連接, swift版

上訴第三方庫簡化了手寫frame的流程，並提供了好比相對位置的便捷寫法還有對於view group的佈局方法。可是提供給沒有適配屏幕的功能。

• 我的建議：

  1、 子view的佈局相關的代碼寫在layoutSubview裏面。我認爲這樣的好處有：

  1.佈局代碼位置統一，其餘人接手新代碼的時候直接在layoutSubview就能夠找到佈局信息。若是把佈局都寫到initWithFrame中，一個問題是若是子view依賴父view的bounds，這個時候每每父view尚未獲得正確的frame，好比即便你設置了UITableViewCell的高度爲80，但此時你取到的仍是默認的44。還一個問題是若是代碼裏有其餘影響佈局的邏輯，好比點擊一個button，另一個view變小，這樣佈局代碼散就會落在不一樣的位置，帶來Shotgun代碼，若是把佈局代碼統一放到layoutSubview裏面，在點擊button的時候修改下狀態量，再setNeedsLayout就可在layoutSubview根據狀態不一樣採用不一樣的佈局。

  2.佈局自動調用，能夠實現簡單的自動適配等效果。好比橫豎屏的佈局差別不是特別大，同一套frame佈局能夠實現適配，轉屏的時候自動就能夠從新layout，無需本身在轉屏時機手動從新佈局。

  2、佈局不要使用絕對座標。最好結合使用屏幕寬高、相對位置(好比A的左邊距離B的右邊10，A的center X與父View的center X相同等)、百分比（好比A的寬度和父View的寬度相同或者是其一半）、Edge Insets（好比A的right爲10）等，這樣在適配要求不高的狀況下也能夠實現較好的適配效果。

Springs&Struts（autoresizingMask）

• 定義：Springs&Struts決定了當UIView的父View的bounds變化時，其自身的座標如何變化：是有flexible or fixed margins (the struts)， width and height (the springs)。UIView的autoresizingMask屬性有以下枚舉值：UIViewAutoresizingFlexibleLeftMargin、UIViewAutoresizingFlexibleWidth、UIViewAutoresizingFlexibleRightMargin、UIViewAutoresizingFlexibleTopMargin、UIViewAutoresizingFlexibleHeight和UIViewAutoresizingFlexibleBottomMargin（這些值能夠取或進行合併）。

• 優勢：簡單，也便是使用簡單方便。好比經常使用若是想使子view的size和父view的size始終相同，能夠用UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight便可。

• 缺點：缺點也是簡單，這個簡單是其應用場景的簡單，僅僅能使用中一些簡單的佈局case，從定義上就能夠看出Springs&Struts描述的是子view和父view的關係，沒法實現子view之間有佈局相關性的複雜場景。而且沒有涉及子view變化的時候具體應該變化多少。

  好比想使用Springs&Struts實現以下視圖的佈局，示例來源連接。全部的間距是20， 上面兩個view的寬度相同，全部view的高度相同：

那麼若是使用Springs&Struts：

1.上方綠色view設置以下：

2.上方黃色view設置以下：

3.下面藍色view設置以下：

通過上述對Springs&Struts的設置，轉屏後，效果仍然錯誤，效果以下：

若是想正確實現要求的佈局，只能在轉屏的時候本身手動修改frame才能實現。

Autolayout

• 定義：Autolayout佈局的過程本質是解決描述各個view佈局信息的一組線性方程組的過程。每個約束表明一個線性方程，用Autolayout佈局的最終目的就是聲明一組描述各個view佈局信息的線性方程組，使得這個方程組有且有惟一解，這個解就是每一個view的frame值。約束的描述：item1.attribute1 = multiplier × item2.attribute2 + constant。下圖較直觀的展示了什麼是constraint。圖片來源

• 優勢：

  1.Designing by intent。 Autolayout最大的優勢就是擺脫之前手寫frame的煩惱，用constraints來描述view自己或者view和view之間的佈局關係。這是徹底不一樣的思惟也便是Designing by intent。一旦constraints創建好，剩下的都由Autolayout來替咱們解決。

  2.國際化。同一個表述在不一樣國家的語言中，文字的長度差別很大，使用Autolayout能夠很好的解決這個問題。

  3.多分辨率適配，不管分辨率、機型、橫豎屏怎麼變化，Autolayout都會替咱們自動將view的frame最終設置好。

  5.Dynamic Type。有關Dynamic Type的相關知識能夠參考Supporting Dynamic Type。

• 缺點：

  1.相對複雜，學習曲線較大，坑比較多。若是使用過Autolayout，會發現其中有不少坑，好比UIScrollView約束設置連接，忘記設置translatesAutoresizingMaskIntoConstraints爲NO, Autolayout的debug調試連接，作動畫等等。（其實這些也並不算什麼缺點，只不過須要時間去學習和理解）。

  2.大多數老工程都是基於傳統的frame來進行佈局，都有本身的一套佈局方案，很難遷移到新技術。

  3.在view多的時候或者對性能要求比較高的場合下性能會出現問題。這纔是autolayout在應用到實踐過程當中最大的問題。這兩篇文章定量的評測了autolayout在不一樣數量view下的性能表現Auto Layout Performance on iOS 和Optimising Autolayout 。而在實際應用過程當中，的確也會有性能問題。搜狗iOS輸入法在最初適配不一樣鍵盤尺寸的按鍵佈局時，使用了 Autolayout 的解決方案，影響了鍵盤調起速度，後續針對鍵盤調起速度的優化過程當中，經過Instruments的Time Profiler才定位到該問題，參考搜狗輸入法性能優化實踐。還有XING app的開發者在他們在項目初期，在列表的佈局上使用了Autolayout。帶來了沒法解決的性能問題，因此放棄使用Autolayout，博客連接Auto Layout in Cells – Don’t!。還有LinkedIn團隊也遇到了一樣的問題，他們爲此開發了LayoutKit來代替Autolayout，他們在介紹LayoutKit的時候，這樣寫道"LinkedIn created LayoutKit because we have found that Auto Layout is not performant enough for complicated view hierarchies in scrollable views."

• 使用Autolayout經常使用的幾種方式：

  1.直接使用 NSLayoutConstraint的constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant:方法。例如：

  

  2.使用NSLayoutAnchor。例如：

  

  NSLayoutAnchor在iOS9以後才能使用，蘋果推出NSLayoutAnchor的緣由我猜想應該是參考了市面上流行的第三方庫的解決辦法，爲了解決使用1方法建立constraint過於繁瑣的問題。UIView具體屬性有：

  

  3.Visual Format Language(VFL)。例如：

  

  VFL應用起來比較簡潔方便，不過因爲建立的constraints沒法單獨去操做，因此調試起來很不方便，很難作動畫。

  4.使用interface builder, 從Apple對interface builder的不斷改進還有WWDC中相關視頻等信息中，咱們能夠發現Apple認爲使用interface builder建立constraints纔是best practice。這就把話題引到了一直存在的很大爭議，究竟是用純手工寫佈局好仍是使用使用interface builder好。這裏有喵神寫的博客代碼手寫UI，xib和StoryBoard間的博弈，以及Interface Builder的一些小技巧和唐巧的文章iOS 開發中的爭議（二）。具體如何選擇你們可本身判斷。

  5.其餘第三方庫。由於你們對蘋果提供的Autolayout的API不滿意，Github上有不少針對對Autolayout封裝的庫，使用起來大大減小了代碼量，很好上手。好比其中Objc寫的、最爲普遍使用的Masonry和PureLayout，swift語言寫的SnapKit和Cartography。有興趣的可本身瞭解下。

  6.Stack Views. UIStackView(iOS9+)class provides a streamlined interface for laying out a collection of views in either a column or a row. Stack views let you leverage the power of Auto Layout, creating user interfaces that can dynamically adapt to the device’s orientation, screen size, and any changes in the available space. The stack view manages the layout of all the views in its arrangedSubviews property. These views are arranged along the stack view’s axis, based on their order in the arrangedSubviews array. The exact layout varies depending on the stack view’s axis, distribution, alignment, spacing, and other properties. 其實Stack View和Android的Linear Layout相似，都是提供在同一方向（橫向或者縱向）佈局多個view的便捷方法。我以爲iOS中不只僅是UIStackView，UICollectionView使用得當，在特定的應用場景下也能夠簡單地實現適配不一樣屏幕的做用。

• 學習Autolayout。能夠參考Apple的GuideAuto Layout Guide。還有一些優秀的博文，好比objc上的Advanced Auto Layout Toolbox還有raywenderlich上的Auto Layout Tutorial in iOS 9 Part 1: Getting Started和Auto Layout Tutorial in iOS 9 Part 2: Constraints還有WWDC上關於Autolayout相關的視頻等等。

第三方佈局方案

除了上面蘋果官方提供的兩種佈局技術，還有其餘的方案，好比：

• CSSLayout，是Facebook開源的對flexbox跨平臺的實現。他主要的目的是使web, android, iOS, 和windows的開發者使用同一種佈局技術來實現佈局，節省學習成本，尤爲是對web開發者。

• ComponentKit，也是是Facebook開源的項目。官方介紹目前Facebook的iOS app大多都使用componentkit。 componentkit使用functional, declarative的方式去構建UI。官方介紹其優勢有：

  1."ComponentKit takes a functional, declarative approach to building UI and emphasizes a one-way data flow from immutable models to immutable components that describe how views should be configured" "It was built to power Facebook's News Feed and is now used throughout the Facebook iOS app."

  2."It performs layout on a background thread, creates the minimal view hierarchy to render the components on screen and has intelligent view reuse. This results in great scroll performance and a snappy system overall."

• LayoutKit 官方介紹"LinkedIn created LayoutKit because we have found that Auto Layout is not performant enough for complicated view hierarchies in scrollable views."而且和autolayout作了對比：

  LayoutKit has many benefits over using Auto Layout:

  1.Fast: LayoutKit is as fast as manual layout code and significantly faster than Auto Layout.

  2.Asynchronous: Layouts can be computed in a background thread so user interactions are not interrupted.

  3.Declarative: Layouts are declared with immutable data structures. This makes layout code easier to develop, code review, debug, and maintain.

  4.Cacheable: Layout results are immutable data structures so they can be precomputed in the background and cached to increase user perceived performance.

• MyLayout， 這個是國內的iOS開發者寫的，其我的在主頁上介紹項目的亮點在於「一套功能強大的iOS界面佈局庫，他不是在AutoLayout的基礎上進行的封裝，而是一套基於對frame屬性的設置，並經過重載layoutSubview函數來實現對子視圖進行佈局的佈局框架。所以能夠無限制的運行在任何版本的iOS系統中。其設計思想以及原理則參考了Android的佈局體系和iOS自動佈局以及SizeClass的功能，經過提供的：線性佈局MyLinearLayout、相對佈局MyRelativeLayout、框架佈局MyFrameLayout、表格佈局MyTableLayout、流式佈局MyFlowLayout、浮動佈局MyFloatLayout、路徑佈局MyPathLayout七個佈局類，以及對SizeClass的支持，來完成對界面的佈局。MyLayout具備功能強大、簡單易用、幾乎不用設置任何約束、能夠完美適配各類尺寸的屏幕等優點。」

上面介紹了一些第三方的佈局方案，你們有興趣能夠研究下，特別是ComponentKit。不過在實際應用的過程當中對這些第三方庫須要謹慎使用，須要完全理解其原理並針對項目特色進行調研，要在使用成本和帶來的收益之間進行平衡。

其餘平臺經常使用佈局技術

因爲早期iOS平臺上屏幕分辨率種類較少，即便到後期和Android或者web相比也是很少，再加上目前市面上的app大多僅支持iPhone且爲豎屏，致使開發者對多分辨率適配並不重視。相關適配的文章也很少。在適配方面咱們能夠借鑑下其餘平臺的解決方案，開闊下本身的思路。因爲我沒有作深刻的學習，僅作簡單介紹，有興趣的同窗能夠自行深刻了解。

Android平臺佈局技術

和iOS相似，Android聲明佈局也大致有兩種途徑：參考

1.Declare UI elements in XML.（在iOS平臺，Xcode以XML格式儲存xib和storyboard文件內容。編譯時，Xcode將xib和storyboard文件編譯成二進制文件，即nib文件。運行時，nib文件會被載入並實例化來建立新的視圖。）

2.Instantiate layout elements at runtime.

具體的佈局的手段有參考：

• Relative Layout is a view group that displays child views in relative positions. The position of each view can be specified as relative to sibling elements (such as to the left-of or below another view) or in positions relative to the parent RelativeLayout area (such as aligned to the bottom, left or center).

  

  

• Linear Layout(和iOS中的UIStackView相似)LinearLayout is a view group that aligns all children in a single direction, vertically or horizontally. You can specify the layout direction with the android:orientation attribute.

  

  

• Building Layouts with an Adapter， 好比List View（UITableView）和Grid View（UICollectionView）
• Constraint Layout(Autolayout) ConstraintLayout allows you to create large and complex layouts with a flat view hierarchy (no nested view groups). It's similar to RelativeLayout in that all views are layed out according to relationships between sibling views and the parent layout, but it's more flexible than RelativeLayout and easier to use with Android Studio's Layout Editor.

其餘平臺多分辨適配策略

Android平臺多分辨適配策略

參考1 參考2 參考3

Android和iOS是目前市場份額最大的兩個移動平臺，因爲Android平臺的開放性，致使其碎片化極爲嚴重，固然隨之而來的屏幕的尺寸也十分繁雜（如圖），所以多分辨率的適配工做對於Android平臺來講應該是一個極爲重要的事情。做爲iOS開發者，咱們能夠了解下Android平臺的適配策略，看是否有能夠借鑑的地方。

從上圖能夠看出，Android平臺的屏幕的種類是多麼的繁雜。

The foundation of Android's support for multiple screens is its ability to manage the rendering of an application's layout and bitmap drawables in an appropriate way for the current screen configuration. The system handles most of the work to render your application properly on each screen configuration by scaling layouts to fit the screen size/density and scaling bitmap drawables for the screen density, as appropriate. To more gracefully handle different screen configurations, however, you should also:

• Explicitly declare in the manifest which screen sizes your application supports
• Provide different bitmap drawables for different screen densities
• Using configuration qualifiers（Size、Density、Orientation和Aspect ratio等）
• Designing alternative layouts and drawables

Best Practices

• Use wrap_content, match_parent, or the dp(iOS中的point相似，) unit for layout dimensions. If you use "wrap_content"(iOS中的Intrinsic Content Size相似), the width or height of the view is set to the minimum size necessary to fit the content within that view, while "match_parent" makes the component expand to match the size of its parent view.
• Use RelativeLayout. Do not use hard-coded pixel values in your application code.Do not use AbsoluteLayout
• Use Size Qualifiers. Your application should also provide several alternative layouts to target different screen configurations. You do so by using configuration qualifiers, which allows the runtime to automatically select the appropriate resource based on the current device’s configuration (such as a different layout design for different screen sizes).
• Use the Smallest-width Qualifier. The Smallest-width qualifier allows you to target screens that have a certain minimum width given in dp.
• Use Orientation Qualifiers.
• Use Layout Aliases 爲了兼容性和減小重複佈局，Layout Aliases能夠是多個限定符描述對應同一個layout.xml
• Use Nine-patch Bitmaps（.9.png）, 和iOS中的resizable image相似，Xcode中的Image Slicing也能夠幫助開發者用可視化的方式完成resizable image
• Build a Responsive UI with ConstraintLayout參考

從上面介紹的官方適配參考來看，Android平臺適配的整體思路就是將設備按照屏幕的特色分紅不一樣的類別，同類別的屏幕具備差異不大的適配特性，而後經過Qualifier來爲不一樣的屏幕分類提供不一樣的資源（layout，image等）。整體思路和iOS平臺有些類似也有不一樣，好比Android平臺使用的Qualifiers，iOS平臺也會根據不一樣屏幕給出2X 3X、設備類型（iPhone iPad）、size class、memory等屬性對應的圖片，只不過Android平臺的Qualifiers更豐富，對設備區分的更詳細。還有xml的使用上，我我的以爲Android平臺的更輕量級一些（雖然Android也有和iOS相似的interface builder）, Android平臺對xml的定位我的感受更像CSS。我以爲這個是咱們作iOS開發能夠借鑑的一個地方，用比較輕量級的配置文件（xml、json或plist）來將客戶端佈局的部分和業務邏輯分離開，增長其擴展性。因爲interface builder沒法動態下發，而使用xml不只能夠完成由數據驅動UI，還能夠動態下發佈局，特別適合須要支持不一樣主題，或者有着比較強烈的界面動態化需求的應用。

iOS平臺多分辨率適配策略及實例

以前介紹了iOS平臺經常使用佈局技術，這些都是佈局的工具，單一的佈局技術並不能解決多分辨率適配的問題，要適配多分辨率須要將多種相關佈局技術結合起來並須要採用必定的適配策略。下面是經常使用的適配策略：

• Adaptive User Interfaces下面Apple官方推薦的多分辨率適配的解決方案，能夠參考官方的GuideAdaptive User Interfaces，還有一些優秀的博文，好比iOS 中的 UI 自適應、WWDC 2014 Session筆記 - iOS界面開發的大一統。這裏我簡單的整理和介紹下，你們能夠有空能夠仔細的學習下，畢竟這是官方推薦，表明之後的發展趨勢。

Best Practice

1.Interface Builder. Apple一直竭盡全力的推廣和改進Interface Builder，Interface Builder可很方便的設置constraints，特別從iOS8的Size Class概念的提出，Interface Builder在Adaptive User Interfaces的優點更加明顯。具體能夠參考Adaptive Layout Tutorial in iOS 9: Getting Started

2.Image Asset。使用Image Asset可爲不一樣的設備提供不一樣的圖片素材，以達到最優的用戶體驗。下圖展現了目前Image Asset能夠配置的選項。配置好後在對應的目錄下實際上是一個json配置文件（咱們也能夠參考這個方案，本身寫配置文件，來支持更復雜的圖片配置邏輯），編譯後生成.car文件。

其中有幾個選項你們能夠關注下，一個是Width還有Height。這個就是能夠指定Size Class的選項。還有Scale Factors，這個選項有Single Vector或Vector With Overrides（Vector With Overrides是Single Vector的加強, 能夠在放置完矢量圖以後繼續放置@1x、@2x和@3x的png格式的圖片。放置的png會優先覆蓋矢量圖, 未放置對應倍率圖片的設備纔會使用矢量圖對應生成的圖片），這個選項主要是爲了支持矢量圖，能夠只放一張PDF的圖片，編譯後Xcode會自動生成1x，2x，3x的圖，須要注意的是使用他並不會減小包的體積，由於不是運行時的特性。還有Slicing，能夠在圖形化界面裏設置拉伸參數。雖然Image Asset有諸如使用方便等優勢，可是咱們在使用過程當中仍是須要衡量其帶來的便捷性和問題。（1）好比Image Asset會生成1X圖片，目前不少應用已經不支持1X的設備了，這樣會帶來包大小的問題。（2）Image Asset雖然支持矢量圖，可是並非運行時的特性，編譯後仍然會生成1x 2x 3x圖片，對安裝包大小沒有起到減小的做用，甚至會更大（一個是多了1x圖片，另一個是若是本身提供2x 3x圖片可在添加前用一些工具用png圖片壓縮），在圖片對安裝包大小影響的優化上，一個優化點是能夠本身實現對矢量圖的支持，這樣就提供一份PDF便可，另外一個是使用工具對png圖片壓縮，還一個比較極端優化的方式是本身在代碼裏面畫圖片（能夠第一次畫而後本地化，以後就直接讀取磁盤文件），在具體實施的過程當中，能夠借用PaintCode來節省本身編寫繪圖代碼的時間。 （3）還有其Image Asset只支持imageNamed，這樣若是一些應用想有本身的圖片緩存策略的話就沒法實現了。

3.UITraitCollection。 Apple的API文檔裏面這樣介紹UITraitCollection: A trait collection describes the iOS interface environment for your app, including traits such as horizontal and vertical size class, display scale, and user interface idiom. To create an adaptive interface, write code to adjust your app’s layout according to changes in these traits. The iOS trait environment is exposed though the traitCollection property of the UITraitEnvironment protocol. This protocol is adopted by the following classes: UIScreen, UIWindow, UIViewController, UIPresentationController, and UIView. You access specific trait values using the UITraitCollection horizontalSizeClass, verticalSizeClass, displayScale, and userInterfaceIdiom properties. The values that express idiom and size traits are defined in the UIUserInterfaceIdiom and UIUserInterfaceSizeClass enumerations; the value for the display scale trait is expressed as a floating point number. To make your view controllers and views responsive to changes in the iOS interface environment, override the traitCollectionDidChange: method from the trait environment protocol. To customize view controller animations in response to interface environment changes, override the willTransitionToTraitCollection:withTransitionCoordinator: method of the UIContentContainer protocol.

UITraitCollection圖例：

UITraitCollection變化流程：

上圖是在代碼裏面根據UITraitCollection的變化相應的改變佈局。若是用Interface Builder的話，系統會幫你自動處理UITraitCollection變化所須要調整的部分。

Size Classes。是UITraitCollection裏面和Adaptive User Interfaces關係比較大的屬性。Size Classes是iOS8以後蘋果最新提出來的，和以往的將屏幕以具體尺寸劃分不一樣，Size Classes對屏幕進行了抽象分類，經過屏幕的感官表現，將其分爲普通 (Regular) 和緊密 (Compact) 兩個種類 (class)。這樣就把屏幕的適配工做從無窮盡的尺寸適配轉換成3*3種屏幕的適配，咱們能夠在同一種類的屏幕上使用同一種佈局，大大減小了適配工做量。之前universal應用使用storyboard時，分紅iPad.storyboard 和iPhone.storyboard 來分別寫，使用了Size Classes就不須要這麼麻煩了。 特別在iOS9中，隨着多任務 (multi-tasking) 的推出，這個概念變得愈發重要。

4.Dynamic Type 能夠根據Trait Collection的變化調整字體。

5.Layout Guides 參考 The UILayoutGuide class defines a rectangular area that can interact with Auto Layout. Use layout guides to replace the dummy views you may have created to represent inter-view spaces or encapsulation in your user interface. Traditionally, there were a number of Auto Layout techniques that required dummy views. A dummy view is an empty view that does not have any visual elements of its own and serves only to define a rectangular region in the view hierarchy. For example, if you wanted to use constraints to define the size or location of an empty space between views, you needed to use a dummy view to represent that space. If you wanted to center a group of objects, you needed a dummy view to contain those objects. Similarly, dummy views could be used to contain and encapsulate part of your user interface. Dummy views let you break up a large, complex user interface into self-contained, modular chunks. When used properly, they could greatly simplify your Auto Layout constraint logic.

There are a number of costs associated with adding dummy views to your view hierarchy. First, there is the cost of creating and maintaining the view itself. Second, the dummy view is a full member of the view hierarchy, which means that it adds overhead to every task the hierarchy performs. Worst of all, the invisible dummy view can intercept messages that are intended for other views, causing problems that are very difficult to find.

The UILayoutGuide class is designed to perform all the tasks previously performed by dummy views, but to do it in a safer, more efficient manner. Layout guides do not define a new view. They do not participate in the view hierarchy. Instead, they simply define a rectangular region in their owning view’s coordinate system that can interact with Auto Layout.

Layout guides can be used to define an equal spacing between a series of views.

Layout guides can also act as a black box, containing a number of other views and controls. This lets you encapsulate part of your view, breaking your layout into modular chunks.

6.UIAppearance 能夠經過appearanceForTraitCollection獲取特定UITraitCollection的UIAppearance，而後對UIAppearance進行自定義適配，以達到不一樣UITraitCollection自動使用不一樣的UIAppearance。

• Web View。這塊其實並非Native的解決方案，其適配的所須要的技術和策略在web的端早就有不少比較成熟的方案。可是在客戶端開發中有必定的應用場景，好比一些運營需求較高的場合，須要作到很強的佈局和邏輯的動態化（固然這種狀況也可使用Reactive Native、 Weex、luaView甚至JS Patch等動態化方案）。另一種狀況是展現類網頁內容的app，好比騰訊新聞、每天快報和今日頭條等。這些app展現的內容的排版大多從網頁而來，若是採用native的方式來解決會十分複雜，所以在大多狀況下都使用web view。

• 代碼裏判斷機型、屏幕尺寸、橫豎屏等狀態，根據不一樣狀態並結合必定的縮放策略給UIView設置不一樣的frame。這種方式屬於比較簡單的適配方案，若是項目頁面比較多，view的層次比較複雜的話，須要適配的分辨率種類多，代碼裏會有不少判斷的代碼，最致命的是若是新增屏幕尺寸須要適配的話，須要很大的工做量。雖然這種方式缺點不少，但也是目前確實國內各大小app使用最多的方案。主要緣由有：

  1.項目立項早。早期iOS佈局技術較爲單一，且屏幕尺寸也不多。因此大部分都是採用手寫frame。隨着新的屏幕尺寸的增長，因爲遷移到新的技術成本太大，因此大多簡單適配了事。

  2.所需適配分辨率很少。目前大多數應用都是僅支持iPhone版，且除了少數頁面大多數頁面都是豎屏。因此須要適配的分辨率就有限了。除了320 × 480以外，其餘三種屏幕的高寬比基本都在1.78附近。因此通常設計只須要給出一種分辨率的設計稿（通常選擇iPhone6--「爲何選擇iPhone 6做爲基準尺寸」或者iPhone5）， 只要寫frame注意前面講的一些事項以外，再配合一些簡單的縮放策略便可實現適配工做，這是知乎上手機淘寶團隊回答的適配和縮放策略。手淘適配規則總結起來就一句話：文字流式，控件彈性，圖片等比縮放。控件彈性指的是，navigation、cell、bar 等適配過程當中垂直方向上高度不變；水平方向寬度變化時，經過調整元素間距或元素右對齊的方式實現自適應。這樣屏幕越大，在垂直方向上能夠顯示更多內容，發揮大屏幕的優點。

• 使用配置文件驅動UI佈局。這部分實際上是參考Android的適配方案，能夠爲不一樣屏幕尺寸設計一套或者多套的layout，其中配置文件中能夠加入一些縮放策略。而後根據屏幕不一樣採用不一樣的配置文件。這種方式的好處是將佈局和業務邏輯分開、適配擴展性好、能夠動態下發配置文件改變UI佈局。