ios設計模式源碼

1. ios為什麼要使用設計模式

原因如下：
使用設計模式，為了代團數吵碼可重用性、讓代碼更容易被塌侍他人理解、保證代碼可靠性。設計模式使代碼編寫真正工程化。
iOS是由蘋果公司開發的畢氏移動操作系統。蘋果公司最早於2007年1月9日的Macworld大會上公布這個系統，最初是設計給iPhone使用的，後來陸續套用到iPodtouch、iPad上。

2. iOS設計模式2 - 觀察者模式_通知機制

NSnotificationCenter是一種典型的有調度中心的觀察者模式實現方式。以NSNotificationCenter為中心，觀察者往Center中注冊對某個主題對象的變化感興趣，主題對象通過NSNotificationCenter進行變化廣播。這種模型就是文章開始發布訂閱報紙在OC中的一種類似實現。所有的觀察和監聽行為都向同一個中心注冊，所有對象的變化也都通過同一個中心胡帆向外廣播。

在通知機制中對某個通知感興趣的所有對象都可以成為接收者。
首先,這些對象需要對通知中心(NSNotificationCenter)發出addObserver:selector:name:object:消息進行注冊,在投送對象投
送通知給通知中心時,通知中心就會把通知廣播給注冊過的接收者。所有的接收者都不知道通知是誰投送的,更不關心它的細節。投送對象與接收者是一對多的關系。接收者如果薯碼對通知不再關注,會給通知中心發出
removeObserver:name:object:消息解除注冊,以後不再接收通知。

1）注冊觀察者：（一般數做哪在viewDidLoad方法中實現）

2）接收廣播後的處理

3）解除注冊（一般在dealloc方法中解除＝注冊）

通過postNotificationName:object:userInfo:發送某一類型通知，廣播改變。

一個通知對象要包含的內容：

3. 三大平台設計模式分析之ios——新浪微博（2017.1.15）

選擇理由：新浪微博頁眉頁腳部分是經典的ios風格，在復雜的結構里也穿插著標簽式導航的變體等其他形式，還有復雜多樣的列表模式，在社交類APP里比較典型。

使用平台：iphone7

下圖（左圖）是新浪微博的首頁，頁眉是ios典型的導航欄，標題在中間，按鈕分布在左右兩邊，因為是首頁，不需要返回按鈕。微博在這里放置了一個叫做「好友關注動態」的頁面入口，用更多元的方式為用戶推薦好友。

用的是舵式導航，置於中間突出位置的是發布按鈕，點擊後從底部飛出6個按鈕，用戶可以選擇需要的發布方式。而原來的發布按鈕「+」號，順時針旋轉變成了X號，點擊X號又逆時針變回「+」號，同時頁面回到動態列表。在這個用戶最順手的位置做了這樣的交互，方便用戶快速地在發布和瀏覽之間快速切換。這兩個行為方式在社交類APP里是最核心的行為。

如上圖所示的首頁，有一個ios風格的內嵌式搜索框。剛進入首頁時候是沒有的，當頁面刷新或下拉之後就會出現。因為用戶無論是刷新或者下拉之後再返回，都是因為沒有找到或者錯過了自己想要的內容，這個時候提供搜索給用戶，可以讓用戶自己檢索想要的內容。

左邊這個是經典的ios風格下拉框——帶小三角的圓角矩形。右邊這個做了一些改變：(1)當分組很多的時候，下拉框可以上下滾動，顯示更多的內容。如果用tab導航的話，由於分組的名字是由用戶起的，欄位長度差異可能會比較大，會顯得比較凌亂，而且首頁的元素已經夠多了，再用tab導航的話內容區域就更小了。下拉框則可以在不需要時候收起，節約空間。(2)在下拉框的底部有一個「編輯我的分組」按鈕。這樣做的優點在於不需要頻繁地跳轉到另一個頁面，可以直接快速的切換分組，只有在要對分組進行編輯時，鋒跡才會跳轉到新的頁面，在新的頁面用戶可以更專注於編輯分組，而不用擔心誤操作，畢竟下拉框空間有限，不方便直接編輯。再說回左圖，有個小問題，就是圖標用了雷達的圖標。用戶點開會發現除了雷達還有其他的2個功能，所以用雷達的圖禪基兆標代表所有的功能會有歧義，它正確的意思不是「雷達」而是「雷達等功能」。不喜歡用「雷達」的用戶，也會比較難發現「掃一掃」和「打車」的功能。（現在賀租最新版本的微博里右上角只有「掃一掃」和「打車」，並且默認顯示掃一掃這個比較常用的功能）

微博中，下拉刷新和頁面載入用的都是這樣的菊花形載入，這種載入方式只表示狀態，沒有進度顯示，如果用戶長時間的等待的話，會感到不耐煩，不知何時才會載入完。但下拉刷新和頁面載入都屬於短時間的載入。在網路正常的情況下幾秒之內就能完成載入。所以不需要顯示進度，只需讓用戶明白正在載入即可。

微博的列表從整體的結構來說是以垂直列表為主，穿插著小圖輪播式的「好友關注」和「相關文章」。但是往細了說，根據微博內容的不同，呈現的結構也稍有區別，這些設計模式同樣也出現在其他社交類應用里：

1）純文字微博

除此以外微博還有很多類型的單元格，都是在文字後插入其他的內容，例如圖片、視頻、鏈接等。

2）圖片微博

文字後插入圖片的形式是微博乃至大部分的社交APP里最常見的一種模式。如下圖所示的是插有圖片的微博。根據圖片的數量不同，布局上會有些變化。只有一張圖片時，按實際比例展示成縮略圖，優點是展示出圖片最真實的比例效果，缺點是當圖片是豎圖的時候布局不是特別好看。圖片大於一張時會變成網格的布局，優點是在有限的空間里羅列盡可能多的內容，尺寸統一的方形圖片和較小的間距，看起來比較有品質。有些愛玩的網友會利用這個特點進行自定義的設計，例如把9張局部的圖拼成一張大圖，更有趣味性和視覺沖擊力。

值得一提的是，當圖片為4張時，正好形成一個四宮格。這樣就不會導致第二行只有一張圖片了。不過在有些app里還做了更好的處理，就是把4宮格單張縮略圖的尺寸比9宮格的單張尺寸做得略大一點。這樣排版上會看起來更飽滿。

3）視頻微博

除了圖片以外，插入視頻也是非常常見的一種模式。如下圖左圖所示，微博的視頻用一個相同的大圖比例呈現，圖片上會有一個播放按鈕。但其實當視頻拖動到頁面中間時，視頻會自動以無聲的方式播放並顯示進度。優點是可以讓用戶實時地看到視頻內容，比較生動。

4）文章微博

上圖右圖所示的是發布文章所生成的微博，會以一張較大的封面圖加上一行標題（圖下方）的形式呈現。這種形式在一些電商的社區也是常常會看到，例如淘寶微淘里的「熱文」。單張大圖以統一的比例呈現，與單圖微博（左上圖）不同的是，它更有感染力，看起來更有檔次，讓人產生一種內容很專業的感覺。因為在信息量如此之大的微博（包括其他社區），用戶往往是匆匆的瀏覽，如果不增強感染力，很難讓用戶駐足，甚至去瀏覽較長的內容。標題都在圖片之下，可見圖片才是吸引用戶的首要元素。不過微博這里的設計，標題的存在感似乎太弱了一些。和圖片的整體性有點欠缺，這樣容易讓用戶產生只有一張大圖的錯覺而錯過文章。

5）其他鏈接

除了以上所述的幾種主流的單元格模式以外，有些微博在文末也會插入如下圖所示的其他鏈接，可以是文章，也可以是商品、音樂等其他內容。以圖片+標題等內容的形式呈現。比起純文字來更生動，還可以知道鏈接的屬性，例如音樂的話上面會有一個播放的圖標之類的，缺點是感染力不夠，優點是不會占太多空間，在有限的空間里給用途提供足夠多的信息。

6）小圖輪播的推薦列表

下圖是微信的好友關注，其實不止是好友關注，還有推薦的文章等，都會以這種形式穿插在微博列表裡，目的是向用戶推薦好友或文章，以促進活躍度及強化社交。同時又不能影響用戶正常瀏覽微博，所以用這種形式可以在有限的空間里推薦足夠多的好友或文章，或其他信息給用戶。缺點是在用戶快速瀏覽時容易忽略。

1）下圖左圖是微博一級導航下的第二個tab——消息。同首頁一樣，標準的ios風格導航欄和內嵌式搜索，一進來的時候搜索是隱藏的，下拉才會顯示。

頁面內是標準的垂直列表。這種形式的優點是簡潔清晰，冷靜高效。用戶到這里來往往是主動尋找一些內容，不像在首頁常常是瀏覽的。所以這里不需要像首頁那麼復雜詳細的列表，只需要簡潔清晰的列表即可。根據用戶從左至右、從上至下的閱讀習慣，左邊一排呈現的是圖標或頭像，用戶可以一目瞭然。而「@我的」、「評論」、「贊」三個核心的社交功能圖標置頂，之後的內容按時間由近及遠排序，讓用戶可以隨時見到最新的消息。

上圖消息列表有2種單元格。一種是帶箭頭的二級列表，進去以後是子列表。這種形式的列表缺點是中間空白太多，有點浪費空間，而且不適用於層級太深，容易造成用戶的厭倦。所以微博在這里只用作二級列表，再進去就是最後一層列表——微博列表，層級很淺。

另一種是沒有箭頭的列表，進去以後是對話框列表。優點是顯示了一部分內容信息，用戶可以快速的做出判斷是否有興趣查看，提高了使用效率。根據ios的操作習慣，左滑可以進行刪除。缺點是呈現的內容太多不能再放置其他操作，比如箭頭、控制項等。所以這種形式最適合用於這種消息列表。

2）上圖（右圖）是「我」的界面。「我」與「消息」的界面一樣，是一個標準的垂直列表頁。由於這里只是功能的陳列，不像消息列表所要顯示時間等信息，所以這里每個單元格的高度都不高，剛剛好容納一行標題。「新的好友」、「我的相冊」、「草稿箱」這些原始的功能層級都不深，而「微博錢包」、「微博運動」、「粉絲服務」、「粉絲頭條」這些擴展的功能進去以後都是一個獨立功能的首頁。所以這里的內容層級都比較淺，適合這種帶箭頭的列表，可以直達目標頁面；四個擴展功能後面還有灰色的小字用來引導用戶；根據具體頁面的類型還進行了分隔。所以整個頁面看起來簡潔清晰，冷靜高效。

最後，這兩個頁面時都有一個共通的缺點，就是只有標題的單元格和有補充信息的單元格放在一起，布局上疏密明顯，只有標題的單元格看起來很單薄，標題右邊空盪盪的。而與其他信息的單元格對比之下就覺得密密麻麻的。

下圖（左起第一張）是微博的「發現」頁面。頭部是ios經典的導航欄搜索。下面是輪播banner，這里用了輪播是為了在有限的空間里多呈現一些廣告內容。再往下有兩行入口圖標，然後是微博列表。

微博列表模塊的開頭部分有個導航標簽式的導航。如果頁面上滑到了微博列表頭部的位置，或者點擊某個標簽，這條標簽式導航就會吸到頁面頂部，變成標簽式導航樣式的分段式導航，見縫插針插進了導航欄。這是因為每個標簽下面的內容信息量很大，還要分出第二層級，也就是吸到頂部以後

該導航下面出現的一行標簽(見右圖)。但是分段式導航的標簽不宜太多，最好2-3個，微博用了4個，但所幸都是2個字的，看起來不算太擁擠，因為還有返回按鈕，如果太擁擠的話，第一個標簽離返回太近也會有歧議。布局上也會顯得頭部太重。

如右上圖所示，「熱門」、「榜單」、「視頻」這三個板塊都是微博內容，標簽多於5個，所以做成了滾動式標簽。

這個設計的優點在於靈活的運用了標簽式導航的變化，讓用戶在沒有明顯的跳轉的情況下，順利的切換，不影響用戶閱讀的同時，承載了更大的內容量。缺點在於標簽不宜太多，例如「熱門」下的標簽

有三十多個，後面的標簽點擊率會很低。並且如果不是根據用戶的偏好進行排序的話，很有可能用戶並不喜歡前面的內容，而喜歡在最後面，但他未必知道後面會有，也未必有耐心瀏覽到最後。

而最後的「頭條」是用戶可以自己定製的新聞內容，所以只放了4個優先順序最高的，最後一個「更多」點擊後進入「全部頻道」（見上圖右圖），可以調整優先順序，或者選擇想去的頻道。與底部導航欄一樣的是，關閉按鈕還是在底部，這樣方便用戶快速地回到頭條頁面。缺點同樣也是標簽過多容易造成用戶的困惑。還有，不是在原標簽下直接展開的，而是滑出一個浮層，所以可能會有點跳出感。但比起滾動式標簽還是好一點，因為這種網格式布局的標簽列表，把每一個標簽都平等清晰的呈現給用戶，便於用戶快速的選擇，而不用反復操作滑動去找不確定是否會有的標簽。

1）下圖是「我」里的「我的贊」。頁眉也是典型的ios風格。標題在中間，右邊是ios風格的「更多」（安卓是豎著的，之後分析安卓的app時候會有圖），左側是返回，並且帶有上一級的標簽，即「我」。這頁的標簽式導航是一個典型的標簽式導航，並且一直置頂。無論頁面如何滾動，它一直都在，用戶可以便捷的再不同類目之間切換。

2）點擊三個點的「更多」按鈕從底部浮現選項，可以選擇「刷新」或「返回首頁」。這里只有2項，其實也可以做成2個按鈕放在右上角。之所以這樣做，好處首先是給用戶更大的點擊空間，避免誤操作。還有就是頁眉的布局不至於太擠。缺點就是需要多點一步。並且在上面點擊後從底部浮出浮層的話用戶的操作幅度有點大。但這和首頁的下拉框是有區別的，下拉框主要是同級頁面間的切換或者功能的切換。而這里是顯示更多操作，所以也不適合用下拉框。

4. iOS中都有什麼設計模式各個設計模式的作用

大致有23種

都是表示類與類之間的構架關系 也就是表示對象的邏輯關系

設計模式根據使用類型可以分為三種：

1、 創建模式：工廠模式、單子模式、建造者模式、原型模式顫和、工廠方法模式。

2、 結構模式：外觀模式、代理模式、適配器模式、組合模式、裝飾模式、橋模式、

共享模式。

3、 行為模式：模板模式、紀念品模式、觀察者模式、責任鏈模式、命令模式、聲明模式、

策略模式、中介模式、解釋器模式、訪問模式

說白了模式就是前人經過大量的實踐,總結出來的優化的對象關系 你也可以自己總結出來

3.iOS 10 隱私許可權設置

iOS 10 開始對隱私許可權更加嚴格，如果你不設置就會直接崩潰或洞指，現在很多遇到崩潰問題了，一般解決辦法都是在info.plist文件添加對應的Key-Value就可以了。

iOS 10 UIStatusBar方法過期:

在我們開發中有可能用到UIStatusBar一些屬性，在iOS 10 中這些方法已經過期了，如果你的項目中有用的話就得需要適配。上面的圖片也能發現，如果在iOS 10中你需要使用preferredStatusBar比如這樣：

//iOS 10 - (UIStatusBarStyle)preferredStatusBarStyle {    return UIStatusBarStyleDefault; }

我們都是用RGB來設置顏色，反正用起來也不是特別多樣化，這次新增的方法應該就是一個彌補吧。所以在iOS 10 蘋果官方建議我們使用sRGB，因為它性能更好，色彩更豐富。如果你自己為UIColor寫了一套分類的話也可嘗試替換為sRGB，UIColor類中新增衫配了兩個Api如下:

+ (UIColor *)colorWithDisplayP3Red:(CGFloat)displayP3Red green:(CGFloat)green blue:(CGFloat)blue alpha:(CGFloat)alpha NS_AVAILABLE_IOS(10_0); - (UIColor *)initWithDisplayP3Red:(CGFloat)displayP3Red green:(CGFloat)green blue:(CGFloat)blue alpha:(CGFloat)alpha NS_AVAILABLE_IOS(10_0);

5. iOS 設計模式（一）-代理模式

代理模式是一種消息傳遞方式，一個完整的代理模式包括：委託對象、代理對象和協議。
協議：用來指定代理雙方可以做什麼，必須做什麼。
委託對象：根據指定的協議，指定代理去完成什麼功能。
代理對象：根據指定的協議，完成委託方需要實現的功能。

從上圖中可以看到三方之間的關系，在實際應用中通過協議來規定代理雙方的行為，協議中的內容一般都是方法列表，當然也可以定義屬性。

協議是公共的定義，如果只是某個類使用，我們常做的就是寫在某個類中。如果是多個類都是用同一個協議，建議創建一個Protocol文件，在這個文件中定義協議。遵循的協議可以被繼承，例如我們常用的 UITableView ，由於繼承自 UIScrollView 的緣故，所以也將 UIScrollViewDelegate 繼承了過來，我們可以通過代理方法獲取 UITableView 偏移量等狀態參數。

協議只能定義公用的一套介面，灶散行類似於一個約束代理雙方的作用。但不能提供具體的實現方法，實現方法需要代理對象去實現。協議可以繼承其他協議，並且可以繼承多個協議，在iOS中對象是不支持多繼承的，而協議可以多繼承。

協議有兩個修飾符 @optional 和 @required ，創建一個協議如果沒有聲明，默認是 @required 狀態的。這兩個修飾符只是約定代理是否強制需要遵守協議，如果 @required 狀態的方法代理沒有遵守，會報一個黃色的警告，只是起一個約束的作用，沒有其他功能。

無論是 @optional 還是 @required ，在委託方調用代理方法時都需要做一個判斷，判斷代理是否實現當前方法，否則會導致崩潰。

在iOS中代理的本質就是代理對象內存的傳遞和操作，我們在委託類設置代理對象後，實際上只是用一個id類型的指針將代理對象進行了一個弱引用。委託方讓代理隱嘩方執行操作，實際上是在委託類中向這個id類型指針指向的對象發送消息，而這個id類型指針指向的對象，就是代理對象。

通過上面這張圖我們發現，其實委託方的代理屬性本質上就是代理對象自身，設置委託代理就是代理屬性指針指向代理對象，相當於代理對象只是在委託方中調用自己的方法，如果方法沒有實現就會導致崩潰。從崩潰的信息上來看，就可以看出來是代理方沒有實現協議中的方法導致的崩潰。

而協議只是一種語法，是聲明委託方中的代理屬性可以調用協議中聲明的方法，而協議中方法的實現還是有代理方完成，而協議掘和方和委託方都不知道代理方有沒有完成，也不需要知道怎麼完成。

由於代理對象使用強引用指針，引用創建的委託方對象，並且成為委託對象的代理。這就會導致委託對象的delegate屬性強引用代理對象，導致循環引用的問題，最終兩個對象都無法正常釋放。
我們將委託對象的delegate屬性，設置為弱引用屬性。
weak 和 assign 是一種「非擁有關系」的指針，通過這兩種修飾符修飾的指針變數，都不會改變被引用對象的引用計數。但是在一個對象被釋放後， weak 會自動將指針指向 nil ，而 assign 則不會。在iOS中，向 nil 發送消息時不會導致崩潰的，所以 assign 就會導致野指針的錯誤 unrecognized selector sent to instance 。
所以我們如果修飾代理屬性，還是用 weak 修飾，比較安全。

6. iOS中的常用的幾種設計模式

觀察者模式

應用場景：一般為model層對，controller和view進行的通知方式數蠢，不關心誰去接收，只負責發布信息。

優勢：解耦合

敏捷原則：介面隔離原則，開放-封閉原則

實例：通知中心，注冊通知中心，任何位置可以發送消息，注冊觀察者的對象可以接收。

kvo，鍵值對改變通知的觀察者。

MVC模式

應用場景：是一中非常古薯困陪老的設計模式，通過數據模型，控制器邏輯，視圖展示將應用程序進行邏輯尺殲劃分。

優勢：使系統，層次清晰，職責分明，易於維護

敏捷原則：對擴展開放-對修改封閉

實例：model-即數據模型，view-視圖展示，controller進行UI展現和數據交互的邏輯控制。