13518219792
可以把組合體想象成為一個實(shí)體，它包含著同一類型的其它實(shí)體。例如算術(shù)表達(dá)式，其包括操作數(shù)、操作符和另一個操作數(shù)，其中，另一個操作數(shù)也可以是操作數(shù)、操作符和另一個操作數(shù)。整個結(jié)構(gòu)就像由父節(jié)點(diǎn)實(shí)體和子節(jié)點(diǎn)實(shí)體連接而成的樹。它就像同一個祖先的族譜樹一樣，族譜中每個節(jié)點(diǎn)都有相同的姓。假設(shè)詢問曾祖父（樹的根節(jié)點(diǎn)），請問家里幾口人？操作將從樹根往下傳，樹中的每個有孩子的組合體會對孩子的總數(shù)與孩子們返回的數(shù)求和，然后將這個和返回。不必分別請求族譜樹中的每個成員，可以向樹發(fā)送消息對其整體進(jìn)行操作。
創(chuàng)新互聯(lián)是一家以網(wǎng)絡(luò)技術(shù)公司，為中小企業(yè)提供網(wǎng)站維護(hù)、成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計、網(wǎng)站備案、服務(wù)器租用、域名注冊、軟件開發(fā)、小程序定制開發(fā)等企業(yè)互聯(lián)網(wǎng)相關(guān)業(yè)務(wù)，是一家有著豐富的互聯(lián)網(wǎng)運(yùn)營推廣經(jīng)驗的科技公司，有著多年的網(wǎng)站建站經(jīng)驗，致力于幫助中小企業(yè)在互聯(lián)網(wǎng)讓打出自已的品牌和口碑，讓企業(yè)在互聯(lián)網(wǎng)上打開一個面向全國乃至全球的業(yè)務(wù)窗口：建站聯(lián)系電話：18982081108
在面向?qū)ο筌浖O(shè)計中我們借用類似的思想，組合結(jié)構(gòu)可以非常復(fù)雜，我們需要通過統(tǒng)一的接口把整個復(fù)雜結(jié)構(gòu)作為一個整體來使用，所以客戶端不必知道某個節(jié)點(diǎn)是什么就能夠使用它。
組合模式，又叫部分整體模式，將對象組合成樹形結(jié)構(gòu)以表示"部分-整體"的層次結(jié)構(gòu)，使得用戶對單個對象和組合對象的使用具有一致性。什么是部分-整體的層次結(jié)構(gòu)呢？它是既包含對象的組合又包含作為葉節(jié)點(diǎn)的單個對象的一種層次結(jié)構(gòu)。每個組合體包含的其它節(jié)點(diǎn)，可以是葉節(jié)點(diǎn)或者是其它組合體，這種關(guān)系在這個層次結(jié)構(gòu)中遞歸重復(fù)，因為每個組合或者葉節(jié)點(diǎn)具有相同的類型。下圖是運(yùn)行時組合對象結(jié)構(gòu)的一個例子：
組合模式的靜態(tài)結(jié)構(gòu)下類圖所示：
Component 定義了 Leaf 類和 Composite 類的共同操作，組合模式使得客戶端可以統(tǒng)一處理 Leaf 和 Composite 對象。 Leaf 和 Composite 的主要區(qū)別在于 Leaf 節(jié)點(diǎn)不包含同類型的子節(jié)點(diǎn)，而 Composite 則包含。 Composite 通過 add:Component 和 remove:Component 管理子節(jié)點(diǎn)。
在使用組合模式時，其葉子和樹枝的聲明都是實(shí)現(xiàn)類，而不是接口，違反了依賴倒置原則。
在 Cocoa 中， UIView 被組織成一個組合結(jié)構(gòu)，每個 UIView 的實(shí)例可以包含 UIView 的其它實(shí)例，形成統(tǒng)一的樹形結(jié)構(gòu)。讓客戶端對單個 UIView 對象和 UIView 的組合統(tǒng)一對待。
窗口中的 UIView 在內(nèi)部形成視圖的樹形結(jié)構(gòu)。層次結(jié)構(gòu)的根部是一個窗口（ UIWindow 對象）及其內(nèi)容視圖，一個填充窗口內(nèi)容矩形的透明視圖。添加到內(nèi)容視圖的視圖成為它的子視圖，并且它們成為添加到它們的任何視圖的父視圖。除了內(nèi)容視圖，一個視圖有一個（并且只有一個）父視圖 和零或任意數(shù)量的子視圖?？梢詫⒋私Y(jié)構(gòu)視為包含： 父視圖包含其子視圖 。
視圖層次結(jié)構(gòu)是一種結(jié)構(gòu)體系結(jié)構(gòu)，它在繪圖和事件處理中都起作用。一個視圖有兩個邊界矩形，它的框架和它的邊界，這會影響視圖的圖形操作是如何發(fā)生的。框架是外部邊界；它在其父視圖的坐標(biāo)系中定位視圖，定義其大小，并將繪圖剪輯到視圖的邊緣。bounds，內(nèi)部邊界矩形，定義了視圖自身繪制的表面的內(nèi)部坐標(biāo)系。
當(dāng)窗口系統(tǒng)要求窗口準(zhǔn)備顯示時，父視圖被要求在其子視圖之前呈現(xiàn)自己。當(dāng)向視圖發(fā)送一些消息時——例如，請求視圖重繪自身的消息——該消息被傳播到子視圖。因此，可以將視圖層次結(jié)構(gòu)的一個分支視為統(tǒng)一視圖。
組合模式的主要意圖是讓樹形結(jié)構(gòu)中的每個節(jié)點(diǎn)具有相同的抽象接口。這樣整個結(jié)構(gòu)可以作為一個統(tǒng)一的抽象結(jié)構(gòu)使用，而不暴露其內(nèi)部表示。對每個節(jié)點(diǎn)的任何操作，可以通過協(xié)議或抽象基類中的相同接口來進(jìn)行。在 Cocoa 中，UIView 視圖被組合成一個組合結(jié)構(gòu)，思考一個問題，使用樹型結(jié)構(gòu)使得對應(yīng)視圖的數(shù)據(jù)被組合成一個組合結(jié)構(gòu)與其一一對應(yīng)實(shí)現(xiàn)動態(tài)渲染...
代理模式是一種消息傳遞方式，一個完整的代理模式包括：委托對象、代理對象和協(xié)議。
協(xié)議：用來指定代理雙方可以做什么，必須做什么。
委托對象：根據(jù)指定的協(xié)議，指定代理去完成什么功能。
代理對象：根據(jù)指定的協(xié)議，完成委托方需要實(shí)現(xiàn)的功能。
從上圖中可以看到三方之間的關(guān)系，在實(shí)際應(yīng)用中通過協(xié)議來規(guī)定代理雙方的行為，協(xié)議中的內(nèi)容一般都是方法列表，當(dāng)然也可以定義屬性。
協(xié)議是公共的定義，如果只是某個類使用，我們常做的就是寫在某個類中。如果是多個類都是用同一個協(xié)議，建議創(chuàng)建一個Protocol文件，在這個文件中定義協(xié)議。遵循的協(xié)議可以被繼承，例如我們常用的 UITableView ，由于繼承自 UIScrollView 的緣故，所以也將 UIScrollViewDelegate 繼承了過來，我們可以通過代理方法獲取 UITableView 偏移量等狀態(tài)參數(shù)。
協(xié)議只能定義公用的一套接口，類似于一個約束代理雙方的作用。但不能提供具體的實(shí)現(xiàn)方法，實(shí)現(xiàn)方法需要代理對象去實(shí)現(xiàn)。協(xié)議可以繼承其他協(xié)議，并且可以繼承多個協(xié)議，在iOS中對象是不支持多繼承的，而協(xié)議可以多繼承。
協(xié)議有兩個修飾符 @optional 和 @required ，創(chuàng)建一個協(xié)議如果沒有聲明，默認(rèn)是 @required 狀態(tài)的。這兩個修飾符只是約定代理是否強(qiáng)制需要遵守協(xié)議，如果 @required 狀態(tài)的方法代理沒有遵守，會報一個黃色的警告，只是起一個約束的作用，沒有其他功能。
無論是 @optional 還是 @required ，在委托方調(diào)用代理方法時都需要做一個判斷，判斷代理是否實(shí)現(xiàn)當(dāng)前方法，否則會導(dǎo)致崩潰。
在iOS中代理的本質(zhì)就是代理對象內(nèi)存的傳遞和操作，我們在委托類設(shè)置代理對象后，實(shí)際上只是用一個id類型的指針將代理對象進(jìn)行了一個弱引用。委托方讓代理方執(zhí)行操作，實(shí)際上是在委托類中向這個id類型指針指向的對象發(fā)送消息，而這個id類型指針指向的對象，就是代理對象。
通過上面這張圖我們發(fā)現(xiàn)，其實(shí)委托方的代理屬性本質(zhì)上就是代理對象自身，設(shè)置委托代理就是代理屬性指針指向代理對象，相當(dāng)于代理對象只是在委托方中調(diào)用自己的方法，如果方法沒有實(shí)現(xiàn)就會導(dǎo)致崩潰。從崩潰的信息上來看，就可以看出來是代理方?jīng)]有實(shí)現(xiàn)協(xié)議中的方法導(dǎo)致的崩潰。
而協(xié)議只是一種語法，是聲明委托方中的代理屬性可以調(diào)用協(xié)議中聲明的方法，而協(xié)議中方法的實(shí)現(xiàn)還是有代理方完成，而協(xié)議方和委托方都不知道代理方有沒有完成，也不需要知道怎么完成。
由于代理對象使用強(qiáng)引用指針，引用創(chuàng)建的委托方對象，并且成為委托對象的代理。這就會導(dǎo)致委托對象的delegate屬性強(qiáng)引用代理對象，導(dǎo)致循環(huán)引用的問題，最終兩個對象都無法正常釋放。
我們將委托對象的delegate屬性，設(shè)置為弱引用屬性。
weak 和 assign 是一種“非擁有關(guān)系”的指針，通過這兩種修飾符修飾的指針變量，都不會改變被引用對象的引用計數(shù)。但是在一個對象被釋放后， weak 會自動將指針指向 nil ，而 assign 則不會。在iOS中，向 nil 發(fā)送消息時不會導(dǎo)致崩潰的，所以 assign 就會導(dǎo)致野指針的錯誤 unrecognized selector sent to instance 。
所以我們?nèi)绻揎棿韺傩?，還是用 weak 修飾，比較安全。
選擇理由：新浪微博頁眉頁腳部分是經(jīng)典的ios風(fēng)格，在復(fù)雜的結(jié)構(gòu)里也穿插著標(biāo)簽式導(dǎo)航的變體等其他形式，還有復(fù)雜多樣的列表模式，在社交類APP里比較典型。
使用平臺：iphone7
下圖（左圖）是新浪微博的首頁，頁眉是ios典型的導(dǎo)航欄，標(biāo)題在中間，按鈕分布在左右兩邊，因為是首頁，不需要返回按鈕。微博在這里放置了一個叫做“好友關(guān)注動態(tài)”的頁面入口，用更多元的方式為用戶推薦好友。
用的是舵式導(dǎo)航，置于中間突出位置的是發(fā)布按鈕，點(diǎn)擊后從底部飛出6個按鈕，用戶可以選擇需要的發(fā)布方式。而原來的發(fā)布按鈕“+”號，順時針旋轉(zhuǎn)變成了X號，點(diǎn)擊X號又逆時針變回“+”號，同時頁面回到動態(tài)列表。在這個用戶最順手的位置做了這樣的交互，方便用戶快速地在發(fā)布和瀏覽之間快速切換。這兩個行為方式在社交類APP里是最核心的行為。
如上圖所示的首頁，有一個ios風(fēng)格的內(nèi)嵌式搜索框。剛進(jìn)入首頁時候是沒有的，當(dāng)頁面刷新或下拉之后就會出現(xiàn)。因為用戶無論是刷新或者下拉之后再返回，都是因為沒有找到或者錯過了自己想要的內(nèi)容，這個時候提供搜索給用戶，可以讓用戶自己檢索想要的內(nèi)容。
左邊這個是經(jīng)典的ios風(fēng)格下拉框——帶小三角的圓角矩形。右邊這個做了一些改變：(1)當(dāng)分組很多的時候，下拉框可以上下滾動，顯示更多的內(nèi)容。如果用tab導(dǎo)航的話，由于分組的名字是由用戶起的，字段長度差異可能會比較大，會顯得比較凌亂，而且首頁的元素已經(jīng)夠多了，再用tab導(dǎo)航的話內(nèi)容區(qū)域就更小了。下拉框則可以在不需要時候收起，節(jié)約空間。(2)在下拉框的底部有一個“編輯我的分組”按鈕。這樣做的優(yōu)點(diǎn)在于不需要頻繁地跳轉(zhuǎn)到另一個頁面，可以直接快速的切換分組，只有在要對分組進(jìn)行編輯時，才會跳轉(zhuǎn)到新的頁面，在新的頁面用戶可以更專注于編輯分組，而不用擔(dān)心誤操作，畢竟下拉框空間有限，不方便直接編輯。再說回左圖，有個小問題，就是圖標(biāo)用了雷達(dá)的圖標(biāo)。用戶點(diǎn)開會發(fā)現(xiàn)除了雷達(dá)還有其他的2個功能，所以用雷達(dá)的圖標(biāo)代表所有的功能會有歧義，它正確的意思不是“雷達(dá)”而是“雷達(dá)等功能”。不喜歡用“雷達(dá)”的用戶，也會比較難發(fā)現(xiàn)“掃一掃”和“打車”的功能。（現(xiàn)在最新版本的微博里右上角只有“掃一掃”和“打車”，并且默認(rèn)顯示掃一掃這個比較常用的功能）
微博中，下拉刷新和頁面加載用的都是這樣的菊花形加載，這種加載方式只表示狀態(tài)，沒有進(jìn)度顯示，如果用戶長時間的等待的話，會感到不耐煩，不知何時才會加載完。但下拉刷新和頁面加載都屬于短時間的加載。在網(wǎng)絡(luò)正常的情況下幾秒之內(nèi)就能完成加載。所以不需要顯示進(jìn)度，只需讓用戶明白正在加載即可。
微博的列表從整體的結(jié)構(gòu)來說是以垂直列表為主，穿插著小圖輪播式的“好友關(guān)注”和“相關(guān)文章”。但是往細(xì)了說，根據(jù)微博內(nèi)容的不同，呈現(xiàn)的結(jié)構(gòu)也稍有區(qū)別，這些設(shè)計模式同樣也出現(xiàn)在其他社交類應(yīng)用里：
1）純文字微博
除此以外微博還有很多類型的單元格，都是在文字后插入其他的內(nèi)容，例如圖片、視頻、鏈接等。
2）圖片微博
文字后插入圖片的形式是微博乃至大部分的社交APP里最常見的一種模式。如下圖所示的是插有圖片的微博。根據(jù)圖片的數(shù)量不同，布局上會有些變化。只有一張圖片時，按實(shí)際比例展示成縮略圖，優(yōu)點(diǎn)是展示出圖片最真實(shí)的比例效果，缺點(diǎn)是當(dāng)圖片是豎圖的時候布局不是特別好看。圖片大于一張時會變成網(wǎng)格的布局，優(yōu)點(diǎn)是在有限的空間里羅列盡可能多的內(nèi)容，尺寸統(tǒng)一的方形圖片和較小的間距，看起來比較有品質(zhì)。有些愛玩的網(wǎng)友會利用這個特點(diǎn)進(jìn)行自定義的設(shè)計，例如把9張局部的圖拼成一張大圖，更有趣味性和視覺沖擊力。
值得一提的是，當(dāng)圖片為4張時，正好形成一個四宮格。這樣就不會導(dǎo)致第二行只有一張圖片了。不過在有些app里還做了更好的處理，就是把4宮格單張縮略圖的尺寸比9宮格的單張尺寸做得略大一點(diǎn)。這樣排版上會看起來更飽滿。
3）視頻微博
除了圖片以外，插入視頻也是非常常見的一種模式。如下圖左圖所示，微博的視頻用一個相同的大圖比例呈現(xiàn)，圖片上會有一個播放按鈕。但其實(shí)當(dāng)視頻拖動到頁面中間時，視頻會自動以無聲的方式播放并顯示進(jìn)度。優(yōu)點(diǎn)是可以讓用戶實(shí)時地看到視頻內(nèi)容，比較生動。
4）文章微博
上圖右圖所示的是發(fā)布文章所生成的微博，會以一張較大的封面圖加上一行標(biāo)題（圖下方）的形式呈現(xiàn)。這種形式在一些電商的社區(qū)也是常常會看到，例如淘寶微淘里的“熱文”。單張大圖以統(tǒng)一的比例呈現(xiàn)，與單圖微博（左上圖）不同的是，它更有感染力，看起來更有檔次，讓人產(chǎn)生一種內(nèi)容很專業(yè)的感覺。因為在信息量如此之大的微博（包括其他社區(qū)），用戶往往是匆匆的瀏覽，如果不增強(qiáng)感染力，很難讓用戶駐足，甚至去瀏覽較長的內(nèi)容。標(biāo)題都在圖片之下，可見圖片才是吸引用戶的首要元素。不過微博這里的設(shè)計，標(biāo)題的存在感似乎太弱了一些。和圖片的整體性有點(diǎn)欠缺，這樣容易讓用戶產(chǎn)生只有一張大圖的錯覺而錯過文章。
5）其他鏈接
除了以上所述的幾種主流的單元格模式以外，有些微博在文末也會插入如下圖所示的其他鏈接，可以是文章，也可以是商品、音樂等其他內(nèi)容。以圖片+標(biāo)題等內(nèi)容的形式呈現(xiàn)。比起純文字來更生動，還可以知道鏈接的屬性，例如音樂的話上面會有一個播放的圖標(biāo)之類的，缺點(diǎn)是感染力不夠，優(yōu)點(diǎn)是不會占太多空間，在有限的空間里給用途提供足夠多的信息。
6）小圖輪播的推薦列表
下圖是微信的好友關(guān)注，其實(shí)不止是好友關(guān)注，還有推薦的文章等，都會以這種形式穿插在微博列表里，目的是向用戶推薦好友或文章，以促進(jìn)活躍度及強(qiáng)化社交。同時又不能影響用戶正常瀏覽微博，所以用這種形式可以在有限的空間里推薦足夠多的好友或文章，或其他信息給用戶。缺點(diǎn)是在用戶快速瀏覽時容易忽略。
1）下圖左圖是微博一級導(dǎo)航下的第二個tab——消息。同首頁一樣，標(biāo)準(zhǔn)的ios風(fēng)格導(dǎo)航欄和內(nèi)嵌式搜索，一進(jìn)來的時候搜索是隱藏的，下拉才會顯示。
頁面內(nèi)是標(biāo)準(zhǔn)的垂直列表。這種形式的優(yōu)點(diǎn)是簡潔清晰，冷靜高效。用戶到這里來往往是主動尋找一些內(nèi)容，不像在首頁常常是瀏覽的。所以這里不需要像首頁那么復(fù)雜詳細(xì)的列表，只需要簡潔清晰的列表即可。根據(jù)用戶從左至右、從上至下的閱讀習(xí)慣，左邊一排呈現(xiàn)的是圖標(biāo)或頭像，用戶可以一目了然。而“@我的”、“評論”、“贊”三個核心的社交功能圖標(biāo)置頂，之后的內(nèi)容按時間由近及遠(yuǎn)排序，讓用戶可以隨時見到最新的消息。
上圖消息列表有2種單元格。一種是帶箭頭的二級列表，進(jìn)去以后是子列表。這種形式的列表缺點(diǎn)是中間空白太多，有點(diǎn)浪費(fèi)空間，而且不適用于層級太深，容易造成用戶的厭倦。所以微博在這里只用作二級列表，再進(jìn)去就是最后一層列表——微博列表，層級很淺。
另一種是沒有箭頭的列表，進(jìn)去以后是對話框列表。優(yōu)點(diǎn)是顯示了一部分內(nèi)容信息，用戶可以快速的做出判斷是否有興趣查看，提高了使用效率。根據(jù)ios的操作習(xí)慣，左滑可以進(jìn)行刪除。缺點(diǎn)是呈現(xiàn)的內(nèi)容太多不能再放置其他操作，比如箭頭、控件等。所以這種形式最適合用于這種消息列表。
2）上圖（右圖）是“我”的界面。“我”與“消息”的界面一樣，是一個標(biāo)準(zhǔn)的垂直列表頁。由于這里只是功能的陳列，不像消息列表所要顯示時間等信息，所以這里每個單元格的高度都不高，剛剛好容納一行標(biāo)題。“新的好友”、“我的相冊”、“草稿箱”這些原始的功能層級都不深，而“微博錢包”、“微博運(yùn)動”、“粉絲服務(wù)”、“粉絲頭條”這些擴(kuò)展的功能進(jìn)去以后都是一個獨(dú)立功能的首頁。所以這里的內(nèi)容層級都比較淺，適合這種帶箭頭的列表，可以直達(dá)目標(biāo)頁面；四個擴(kuò)展功能后面還有灰色的小字用來引導(dǎo)用戶；根據(jù)具體頁面的類型還進(jìn)行了分隔。所以整個頁面看起來簡潔清晰，冷靜高效。
最后，這兩個頁面時都有一個共通的缺點(diǎn)，就是只有標(biāo)題的單元格和有補(bǔ)充信息的單元格放在一起，布局上疏密明顯，只有標(biāo)題的單元格看起來很單薄，標(biāo)題右邊空蕩蕩的。而與其他信息的單元格對比之下就覺得密密麻麻的。
下圖（左起第一張）是微博的“發(fā)現(xiàn)”頁面。頭部是ios經(jīng)典的導(dǎo)航欄搜索。下面是輪播banner，這里用了輪播是為了在有限的空間里多呈現(xiàn)一些廣告內(nèi)容。再往下有兩行入口圖標(biāo)，然后是微博列表。
微博列表模塊的開頭部分有個導(dǎo)航標(biāo)簽式的導(dǎo)航。如果頁面上滑到了微博列表頭部的位置，或者點(diǎn)擊某個標(biāo)簽，這條標(biāo)簽式導(dǎo)航就會吸到頁面頂部，變成標(biāo)簽式導(dǎo)航樣式的分段式導(dǎo)航，見縫插針插進(jìn)了導(dǎo)航欄。這是因為每個標(biāo)簽下面的內(nèi)容信息量很大，還要分出第二層級，也就是吸到頂部以后
該導(dǎo)航下面出現(xiàn)的一行標(biāo)簽(見右圖)。但是分段式導(dǎo)航的標(biāo)簽不宜太多，最好2-3個，微博用了4個，但所幸都是2個字的，看起來不算太擁擠，因為還有返回按鈕，如果太擁擠的話，第一個標(biāo)簽離返回太近也會有歧議。布局上也會顯得頭部太重。
如右上圖所示，“熱門”、“榜單”、“視頻”這三個板塊都是微博內(nèi)容，標(biāo)簽多于5個，所以做成了滾動式標(biāo)簽。
這個設(shè)計的優(yōu)點(diǎn)在于靈活的運(yùn)用了標(biāo)簽式導(dǎo)航的變化，讓用戶在沒有明顯的跳轉(zhuǎn)的情況下，順利的切換，不影響用戶閱讀的同時，承載了更大的內(nèi)容量。缺點(diǎn)在于標(biāo)簽不宜太多，例如“熱門”下的標(biāo)簽
有三十多個，后面的標(biāo)簽點(diǎn)擊率會很低。并且如果不是根據(jù)用戶的偏好進(jìn)行排序的話，很有可能用戶并不喜歡前面的內(nèi)容，而喜歡在最后面，但他未必知道后面會有，也未必有耐心瀏覽到最后。
而最后的“頭條”是用戶可以自己定制的新聞內(nèi)容，所以只放了4個優(yōu)先級最高的，最后一個“更多”點(diǎn)擊后進(jìn)入“全部頻道”（見上圖右圖），可以調(diào)整優(yōu)先級，或者選擇想去的頻道。與底部導(dǎo)航欄一樣的是，關(guān)閉按鈕還是在底部，這樣方便用戶快速地回到頭條頁面。缺點(diǎn)同樣也是標(biāo)簽過多容易造成用戶的困惑。還有，不是在原標(biāo)簽下直接展開的，而是滑出一個浮層，所以可能會有點(diǎn)跳出感。但比起滾動式標(biāo)簽還是好一點(diǎn)，因為這種網(wǎng)格式布局的標(biāo)簽列表，把每一個標(biāo)簽都平等清晰的呈現(xiàn)給用戶，便于用戶快速的選擇，而不用反復(fù)操作滑動去找不確定是否會有的標(biāo)簽。
1）下圖是“我”里的“我的贊”。頁眉也是典型的ios風(fēng)格。標(biāo)題在中間，右邊是ios風(fēng)格的“更多”（安卓是豎著的，之后分析安卓的app時候會有圖），左側(cè)是返回，并且?guī)в猩弦患壍臉?biāo)簽，即“我”。這頁的標(biāo)簽式導(dǎo)航是一個典型的標(biāo)簽式導(dǎo)航，并且一直置頂。無論頁面如何滾動，它一直都在，用戶可以便捷的再不同類目之間切換。
2）點(diǎn)擊三個點(diǎn)的“更多”按鈕從底部浮現(xiàn)選項，可以選擇“刷新”或“返回首頁”。這里只有2項，其實(shí)也可以做成2個按鈕放在右上角。之所以這樣做，好處首先是給用戶更大的點(diǎn)擊空間，避免誤操作。還有就是頁眉的布局不至于太擠。缺點(diǎn)就是需要多點(diǎn)一步。并且在上面點(diǎn)擊后從底部浮出浮層的話用戶的操作幅度有點(diǎn)大。但這和首頁的下拉框是有區(qū)別的，下拉框主要是同級頁面間的切換或者功能的切換。而這里是顯示更多操作，所以也不適合用下拉框。
在數(shù)學(xué)和邏輯學(xué)中，單例定義為” 有且僅有一個元素的集合 “，在無論什么情況下，獲取到的都是同一個值。在程序中，單例模式保證一個類僅有一個實(shí)例，并提供一個訪問它的全局訪問點(diǎn)。這個方法應(yīng)該是類方法，阻止所有想要生成對象的訪問，避免一個全局使用的類頻繁地創(chuàng)建和銷毀。
static uniqueInstance 是 Singleton 中的唯一實(shí)例， static sharedInstance 將它返回給客戶端。通常， shareInstance 會檢查 uniqueInstance 是否已經(jīng)被實(shí)例化，如果沒有，會生成一個實(shí)例然后返回 uniqueInstance 。
沒有接口，不能繼承，與單一職責(zé)原則沖突，一個類應(yīng)該只關(guān)心內(nèi)部邏輯，而不關(guān)心外面怎么樣來實(shí)例化。
只要應(yīng)用程序需要集中式的類來協(xié)調(diào)其服務(wù)，這個類就應(yīng)該生成單一的實(shí)例，而不是多個實(shí)例。
代理模式：完成委托方的任務(wù)，需要聲明代理對象和指定代理，相對于block，在需要傳遞參數(shù)的傳值時優(yōu)先考慮代理。
代理是一對一的關(guān)系（1個對象只能通知1個對象發(fā)生了什么事）。
應(yīng)用場景：不同類之間的傳值與回調(diào)。
觀察者模式(通知機(jī)制,KVO機(jī)制）：觀察者模式本質(zhì)上是一種發(fā)布-訂閱模型,用以消除具有不同行為的對象之間的耦合，通過這一模式，不同對象可以協(xié)同工作。
通知是一對多的關(guān)系（1個通知可以發(fā)送給多個通知接受對象）。
應(yīng)用場景：監(jiān)聽設(shè)備狀態(tài)，自定義鍵盤時監(jiān)聽鍵盤的彈出和隱藏。
單例模式：可以保證App在程序運(yùn)行中，一個類只有唯一個實(shí)例。
系統(tǒng)中的單例：UIApplication(應(yīng)用程序?qū)嵗?、NSNotificationCenter(消息中心)、NSFileManager(文件管理)、NSUserDefaults(應(yīng)用程序設(shè)置)、NSURLCache(請求緩存)等。
應(yīng)用場景：功能集中管理的模塊可以封裝為單例，方便外界調(diào)用。
策略模式：定義了一系列的算法，并將每一個算法封裝起來，而且使它們還可以相互替換。策略模式讓算法獨(dú)立于使用它的客戶而獨(dú)立變化。
MVC(Model View Controller)：
model：數(shù)據(jù)層
view：視圖層，負(fù)責(zé)頁面展示
Controller：控制視圖層與數(shù)據(jù)層的關(guān)聯(lián)，
MVVM(model view viewModel):
Model: 數(shù)據(jù)層，不包含邏輯
View：與用戶直接交互，只需處理觸發(fā)事件后的轉(zhuǎn)發(fā)，和告訴他如何顯示
ViewModel：跟蹤view的事件，處理model層傳遞的數(shù)據(jù)；公開方法、屬性，讓view保持最新的狀態(tài)
iOS開發(fā)就是為裝有iOS系統(tǒng)的設(shè)備完成應(yīng)用軟件或游戲軟件的開發(fā)，ios開發(fā)的設(shè)計模式有代理模式、觀察者模式、MVC模式、單例模式、策略模式和工廠模式。
