最近被朋友問到的問題酪劫，總結了一下問題分享出來(鶸的分享通常都是一本正經(jīng)地胡說八道??)，問題之間基本上沒什么關聯(lián)灼擂，也沒有順序嫉入，純粹就是總結一下最近被問到的問題。
怎么看待視圖圓角的性能優(yōu)化璧尸？
視圖圓角的性能優(yōu)化并不是什么新鮮的東西咒林，不知道為什么最近兩年特別火，我在網(wǎng)上也看了很多篇這方面的文章爷光，感覺挺失望的垫竞，每篇文章的內(nèi)容基本上都是千篇一律，內(nèi)容基本上都是說蛀序，設置視圖的圓角(視圖設置圓角不一定會引起離屏渲染欢瞪，這里默認是會離屏渲染的情況)會引發(fā)GPU做離屏渲染的操作，GPU的使用率會大大增加徐裸，因此可能會出現(xiàn)屏幕掉幀的情況遣鼓，所以要避免GPU的離屏渲染，轉交給CPU處理重贺。每次看到這些內(nèi)容的時候我都想問骑祟，難道轉交給CPU之后，離屏渲染的工作就消失了嗎气笙？我不是太明白為什么每篇文章基本上都是呼吁把離屏渲染轉交給CPU來完成次企，難道轉交給CPU來做就不會有性能問題？離屏渲染的工作潜圃，不是GPU就是CPU來完成缸棵，這本來就是一個折中的選擇，下面通過分析一個簡單的頁面來看看這種選擇(以下分析當提到CPU處理時谭期，忽略多線程優(yōu)化堵第，均在主線程處理)吧凉。
首先我們需要簡單地分析這個頁面的資源分布情況。CPU的基本工作：創(chuàng)建視圖型诚，視圖布局客燕，文本繪制，圖片解壓加載狰贯；GPU的基本工作：頭像視圖的離屏渲染也搓，渲雜整個頁面。按照這樣的分布涵紊，假設當前頁面的CPU占用率是60%傍妒，而GPU占用率是25%，而屏幕并沒有掉幀但處于掉幀的邊緣摸柄，在這種情況下把GPU離屏渲染的工作轉交給CPU來完成后颤练，CPU的占用率可能達到了70%，而GPU的占用率只有20%驱负，原本處于掉幀的邊緣的狀況被打破了嗦玖，因為CPU的壓力過大導致出現(xiàn)屏幕掉幀的情況，所以跃脊，面對這樣的情況宇挫，我們還是堅持要把離屏渲染的工作轉交給CPU來完成？當然酪术，這樣的假設可能很極端器瘪，實際情況可能要好得多，即使真的把離屏渲染的工作轉交給CPU來完成也不會出現(xiàn)掉幀(即使因為CPU而掉幀绘雁，還可以通過異步處理的方式進行優(yōu)化)橡疼，但是這樣的資源分配真的合理嗎？
要不要將GPU離屏渲染的工作轉交給CPU來完成庐舟，是需要根據(jù)實際情況折中選擇的欣除，對于怎么選擇，我個人的標準是继阻，首先要看當前頁面是動態(tài)還是靜態(tài)耻涛，如果只是一個靜態(tài)頁面，那就不需要去考慮性能優(yōu)化的問題瘟檩；如果是一個動態(tài)頁面抹缕，要看這個頁面在程序中的位置，如果只是一個無關緊要且使用率低的頁面墨辛，也可以不去考慮掉幀問題卓研；如果是一個很關鍵且使用率高的頁面，就需要先測試當前頁面的性能瓶頸在于GPU還是CPU(怎么測試？網(wǎng)上有挺多這方面的資料奏赘，動手查一下吧)寥闪，分析當前頁面的資源分布情況，如果只是GPU的壓力大磨淌，可以將部分GPU的工作轉交給CPU來完成疲憋，如果是GPU和CPU的壓力都很大，那么就需要你進行折中選擇的時候了梁只，面對這種選擇缚柳，我不認為會有一份明確的指南告訴你怎么做是對的，也不可能存在這樣的指南搪锣，因為任何的折中選擇都是權衡后的選擇秋忙，是否可以快速作出正確的選擇，我覺得這個時候就需要吃經(jīng)驗了构舟，盡管如此灰追，還是有一些經(jīng)驗可以作為參考(本文不展開講，以后可能會寫詳細的優(yōu)化文章)狗超。
考慮當前頁面是否有很多且需要快速響應的CPU任務(如：點擊事件弹澎，必須在主線程處理的UI任務等)，如果是努咐，選擇其它方式優(yōu)化GPU或者選擇CPU并行處理的方式裁奇；考慮你自己或你的團隊是否有能力駕馭并行處理(如果沒有，還是串行處理吧)麦撵；考慮實現(xiàn)成本和價值(實現(xiàn)成本高的，你可能沒這時間溃肪，價值低的免胃，實現(xiàn)了也沒太多意義)；
怎么看待性能優(yōu)化惫撰？
性能優(yōu)化越來越流行羔沙，隨著iOS開發(fā)越來越成熟和穩(wěn)定，性能優(yōu)化更是被提到了日程厨钻，網(wǎng)上也出現(xiàn)了各式各樣的性能優(yōu)化技術文扼雏。就像上面所說的那樣，性能優(yōu)化是折中選擇夯膀，做性能優(yōu)化有很多好處诗充，可以得升用戶體驗，可以更充分地利用資源等诱建，但在你打算做性能優(yōu)化時蝴蜓，你不得不去考慮一些問題。
是否可以做性能優(yōu)化？當你將要做的性能優(yōu)化會一定程度上破壞程序架構或沖突時茎匠，你要怎么選擇(當然是選擇做性能優(yōu)化咯格仲，因為大部分的程序都沒有架構設計這種東西??)；
是否需要做性能優(yōu)化诵冒？需不需要做性能優(yōu)化凯肋，個人的標準是：基礎，關鍵的模塊的性能優(yōu)化是需要且必要的(什么是基礎汽馋，關鍵的模塊侮东？舉個例子，UILabel在iOS8以前的底圖層是CALayer惭蟋，在iOS8以后的底圖層是_UILabelLayer苗桂，這是蘋果對UILabel文本繪制的優(yōu)化)，但對于業(yè)務層告组，特別是展示層的性能優(yōu)化煤伟，看模塊是否為迭代，增量式開發(fā)(一般情況下木缝，以迭代便锨，增量的方式來完成和完善功能的模塊都會有一個明確的戰(zhàn)略目標，會趨向穩(wěn)定)我碟，如果不是放案，建議不要花時間優(yōu)化這個模塊(除非你真的很有空，因為業(yè)務層的很多模塊是產(chǎn)品一拍腦門想出來的矫俺，產(chǎn)品本身就沒有明確的戰(zhàn)略目標和方向吱殉，所以這個版本有，下次迭代可能就不要了)厘托。
你的團隊是否有能力做性能優(yōu)化友雳？即使可以做，需要做性能優(yōu)化铅匹，最后還要看團隊的實際情況押赊，因為整個程序的優(yōu)化由一個人來完成太困難了，優(yōu)化所需的時間成本太高了包斑，而且還可能會出現(xiàn)流礁，你做好的優(yōu)化被你的同事隨便就改了(多半的理由是：“那樣寫太麻煩，這樣寫直接調(diào)用多方便罗丰，還能一改整個項目都改了”神帅，是，一改整個項目都改了萌抵，一改整個項目都崩了)枕稀。
性能優(yōu)化是折中選擇，做不做性能優(yōu)化也是折中選擇，這些選擇的標準也會隨著你經(jīng)驗的增加萎坷，知識面的擴充凹联，所在團隊及角色的變化而有所不同。
怎么看待設計模式哆档？
上周末有一個朋友很沮喪地跟我說：“我花了兩個月看完了GOF23蔽挠，但這些東西真的是然并卵，完全想不到有什么例子瓜浸，更想不到要怎么用”澳淑。可能有很多人看了設計模式之后都有同樣的感受插佛，這些概念看上去好像挺有道理杠巡，但在實際開發(fā)中怎么應用？學習設計模式對自身有什么幫助雇寇？在討論這些問題之前氢拥，我們先通過一些簡單的例子來看看系統(tǒng)中的設計模式。
首先我們來看看觸摸事件的整個過程(詳細過程可以點這里)锨侯，當觸摸事件從硬件系統(tǒng)發(fā)送到當前Application之后嫩海，Application的主要操作分為兩步，查找第一響應者囚痴，查找可以處理事件的響應者叁怪。
查找第一響應者，首先向Window對象發(fā)送hitTest消息深滚，Window對象接收到消息后就開始進行自身的檢測奕谭，通過pointInside方法來判斷觸摸點是否在本地坐標系上(忽略像userInteractionEnabled等判斷)，如果在痴荐，就向它的子視圖對象發(fā)送hitTest消息展箱，子視圖對象再重復這一過程，直到最后一個符合條件的子視圖對象蹬昌，并返回這個子視圖對象。
查找可以處理事件的響應者攀隔，通過上一步獲取到第一響應者皂贩，向第一響應者發(fā)送事件處理的消息，把相應的事件傳遞過去昆汹，第一響應者開始檢測自身是否可以處理事件明刷，若不能處理事件，就向下一個響應者發(fā)送事件處理的消息满粗，并把事件傳遞過去辈末，若能處理事件，則處理事件并結束本次觸摸事件，重復這一過程挤聘，直到有響者可以處理事件或放棄本次觸摸事件轰枝。
當你去研究觸摸事件的整個過程時，可能需要花上一些時間才能了解整個過程组去，才會發(fā)現(xiàn)整個過程分為兩步鞍陨，才大概了解到每一步的一些關鍵細節(jié)。當你了解了整個過程之后从隆，可能又會產(chǎn)生一些疑問诚撵，為什么查找第一響應者和查找可以處理事件的響應者的過程是這樣？整個過程看上去很繁瑣键闺，這樣處理方式有什么好處寿烟？
OK！我們現(xiàn)在換一種方式辛燥，站在設計模式的角度來看觸摸事件的整個過程(不會展開講每一個模式的細節(jié)筛武，只講述正式定義，詳細內(nèi)容會在設計模式的篇章里講述)购桑。
整個過程的第一步是查找第一響應者畅铭，查找第一響應者利用了視圖層次結構來完成，看到視圖層次結構我們自然想到的是組合模式(Composite Pattern)勃蜘，大部分系統(tǒng)都是以組合模式來實現(xiàn)視圖層次結構的硕噩，iOS也不例外。組合模式的正式定義：將對象組合成樹形結構來表現(xiàn)“整體/部分”層次結構(例如缭贡，視圖層次結構)炉擅，Composite使得用戶對單個對象和組合對象的使用具有一致性。組合模式使得Application對象不知道也不關心當前的UIWindow對象是單個對象還是組合對象(Window是否有子視圖)阳惹，這對于Application對象來說是透明的谍失，以UIWindow對象為最高層組件的對象結構(視圖層次結構)可以在程序運行時動態(tài)改變，但這些改變并不會響影Application的代碼莹汤，因為Application對象對UIWindow對象的所有假定都基于UIWindow抽象的概念接口快鱼，而這些假定或者說Application對象對UIWindow對象的操作在編譯時就已經(jīng)固定下來。這樣的設計使得Application對象與UIWindow對象既可以保持穩(wěn)定的交互纲岭，又可以在程序運行時動態(tài)改變以UIWindow對象為最高層組件的對象結構抹竹，既保證了穩(wěn)定性又提供了靈活性。所以止潮，當Application對象向UIWindow對象發(fā)送hitTest消息時窃判，UIWindow對象根據(jù)運行時的對象結構完成相應操作(遞歸結構)。
提供對象結構很重要喇闸，因為它展示了對象之間如何協(xié)作袄琳，而提供類結構同樣很重要询件，對象結構中的每一個對象都是某一個類的實例，客戶(Application對象)對服務器對象(UIWindow對象)作出的所有假定都是基于這個對象的類的抽象(類的接口)唆樊。
第二步是查找可以處理事件的響應者宛琅，查找是順著響應鏈(響應鏈由一組響應者組成)來完成的，iOS中響應鏈是以職責鏈模式(Chain Of Responsibility Pattern)來實現(xiàn)窗轩。職責鏈模式的正式定義：使多個對象都有機會處理請求夯秃，從而避免請求的發(fā)送者和接收者之間的耦合關系。將這些對象連成一條鏈痢艺，并沿著這條鏈傳遞請求仓洼，直到有一個對象處理它為止。第一步獲取到的是職責鏈(響應鏈)中的第一個接收者(Handler堤舒，第一響應者)色建，客戶向第一個接收者發(fā)送事件處理的消息，消息沿著鏈轉發(fā)舌缤，若當前接收者不能處理事件箕戳，就將消息傳遞給下一個接收者或者叫隱式接收者(Successor，即響應鏈中的nextResponder)国撵。
在職責鏈模式中陵吸，既然沒有一個明確的接收者，那么消息就不能保證一定會被處理介牙。若有接收者可以處理事件壮虫，則本次消息傳遞結束，若沒有接收者可以處理事件环础，則本次事件被放棄處理囚似。與組合模式一樣，職責鏈模式同樣提供了穩(wěn)定性和靈活性线得。Application對象與第一響應者(FirstResponder饶唤，即職責鏈中的Handler)的交互在編譯時已經(jīng)固定，而響應鏈的對象結構則在運行時動態(tài)地改變贯钩。
觸摸事件的處理應用了組合模式和職責鏈模式募狂，接下來我們再看一個應用職責鏈模式的例子，Objective-C的消息機制(假定讀者知道消息機制的流程)角雷。
當我們向一個對象發(fā)送消息時祸穷，通過這個對象的isa指針來獲取該對象所對應的類對象(或元類對象)，再通過配對類對象(或元類對象)方法列表中的SEL來獲取相應的IMP谓罗，若在當前類對象(或元類對象)的方法列表中可以找到與SEL配對的IMP，則返回相應的IMP并結束本次消息的查找季二，若不能在當前類對象(或元類對象)的方法列表中找到與SEL配對的IMP檩咱，則把查找消息傳遞給SuperClass揭措，從SuperClass的方法列表中繼續(xù)查找與SEL配對的IMP，重復這一過程刻蚯，直到有類對象(或元類對象)處理消息或最終拋出doesNotRecognizeSelector異常绊含。
職責鏈是根據(jù)類結構的繼承關系在運行時動態(tài)決定的，或者說職責鏈是類對象和元類對象所構成的對象結構(Objective-C作為一門原型語言炊汹，類和元類本身也是對象)躬充，Handler就是當前對象所對應的類對象(或元類對象)，Successor就是SuperClass讨便，沿著這條職責鏈來查找消息充甚。為什么說Objective-C是動態(tài)語言？Objective-C的動態(tài)性體現(xiàn)在很多方面霸褒，用鏈表來實現(xiàn)方法列表使得可以在運行時動態(tài)添加方法伴找，用isa指針指向的類對象(或元類對象)使得可以在運行時改變指向(KVO，為什么KVO的實現(xiàn)是創(chuàng)建當前類的子類來實現(xiàn)監(jiān)聽而不是用hook的方式废菱？因為直接hook會影響其它同類對象的操作)技矮。用職責鏈模式實現(xiàn)消息查找路徑使得可以在運行時動態(tài)地改變路徑的對象結構，也為最終因找不到方法而進行消息轉發(fā)提供了基礎殊轴。
例子不再一一列舉衰倦，留給有興趣的讀者自己去研究。無論是系統(tǒng)框架還是優(yōu)秀的第三方庫旁理，或多或少都應用了設計模式來實現(xiàn)樊零，雖然每個模式在應用時都會根據(jù)實際情況作出一定的調(diào)整或變種，但在結構上韧拒，所需要注要和考慮的細節(jié)上基本是一致的淹接，當你對這些模式有所了解時，就可以幫助你更好地理解你所研究的框架或架構叛溢，就可以使你更快地知道哪些是要點塑悼，哪些是重點。這是對于你研究系統(tǒng)框架或優(yōu)秀的第三方庫時的幫助楷掉，除此以外厢蒜，學習這些設計模式還為你的思考提供了另一個方向，提升了你的編程思想和程序的穩(wěn)定性烹植，可擴展性等斑鸦。應用設計模式有很多優(yōu)點，但同時也存在著一些缺點草雕。一般情況下巷屿，你所做的基本抽象都是從問題域中來的，當你完成問題分析開始設計程序時墩虹，常常會在這些基本抽象或關鍵抽象上進行更高層的抽象嘱巾，會創(chuàng)建新的類和對象來協(xié)作憨琳，這些額外的類和對象會增加程序設計的復雜度，還會降低效率等旬昭，而且當你的程序充滿了設計模式時篙螟，你還將面臨著另一個問題，是否過度設計问拘？
除了設計模式遍略，還有一些設計原則可以你幫助解決設計上的問題，但需要注意的是骤坐，設計原則只是指引绪杏，并非一定要照著來做，而且在實際開發(fā)當中也不太可能這樣做(至少國內(nèi)的IT公司好像大部分是這樣子的)或油。例如單一功能原則寞忿，它規(guī)定一個類應該只有一個發(fā)生變化的原因，但這個原則會大大增加你的程序設計復雜度顶岸。細化對象的粒度是一個分類過程腔彰，應該通過多次迭代來完成，而不是一開始就花大量的時間去分析與設計(通常情況下你都沒有時間去做設計和考慮)辖佣，這跟做性能優(yōu)化一樣霹抛，避免對未來的發(fā)展做過多的預測，除非你所面對的模塊有很明確的戰(zhàn)略目標(扯蛋吧卷谈，在開發(fā)過程中不來改需求已經(jīng)很慶幸了)杯拐，或者你所在的團隊有這些明確的規(guī)定。
學習完設計模式后要面臨的最大問題是世蔗，怎么在實際開發(fā)中應用端逼，相信很多人都有這個的疑問，為什么面對實際問題時會無從下手污淋？其實不管你是否有學習過設計模式顶滩，在你的日常開發(fā)當中總會用到一個模式－策略模式(Strategy Pattern)。策略模式的正式定義：定義一系列的算法寸爆，把它們一個個封裝起來礁鲁，并且使它們可相互替換。本模式使得算法可獨立于使用它的客戶而變化赁豆〗龃迹看到這個定義你想到了什么？舉個例子魔种，UICollectionView根據(jù)你所傳遞的UICollectionViewLayout進行布局析二，通過改變UICollectionViewLayout來改變布局，UICollectionViewLayout就是模式中的Strategy节预，UICollectionView就是模式中的Context叶摄。再看一個更常見的例子漆改，代理回調(diào)，代理回調(diào)中的協(xié)議就是Strategy的接口准谚，引入?yún)f(xié)議的類就是Strategy，而被代理的對象就是Context(例如去扣，TableView還是那個TableView柱衔，但TableView的協(xié)議每次都有不同的實現(xiàn)，TableView根據(jù)所提供的協(xié)議實現(xiàn)來展示最終的效果)愉棱。
回到怎么應用這個問題唆铐，我個人的看法是，很多人在學設計模式時忽略了設計模式的基礎是面向?qū)ο蟊蓟珿OF23對設計模式的定義是艾岂，對被用來在特定情景下解決一般設計問題的類和相互通信的對象的描述。如果你本身還不知道怎么用面向?qū)ο髞矸治龊头纸鈫栴}朋其，還不清楚什么是對象模型王浴，什么是類，什么是對象梅猿，怎么分類氓辣，你連基本的切入點和依據(jù)都沒有，你怎么可能知道在實際開發(fā)中該如何應用設計模式袱蚓，即使真的應用了钞啸，也只是套了個結構而已。
面向?qū)ο蟮膯栴}喇潘，在此不展開討論体斩，因為這些知識或者說這些關于編程思想上的東西，并不是一兩篇技術文就可以講述清楚颖低，就可以傳達給你的絮吵，如果讀者有興趣，可以看一下《面向?qū)ο蠓治雠c設計》這本書枫甲，不管你目前是什么水平源武，或許你都可以在這本書里有所收獲。如果讀者想學設計模式想幻，建議選Head First《設計模式》作為入門粱栖，GOF23作為拓展，《設計模式沉思錄》作為應用后的思考脏毯，雖然我也很想支持國貨闹究，但真的不建議選《大話設計》作為入門(雖然銷量很高)，因為跟Head First《設計模式》相比食店，《大話設計》傳遞的是思考什么(相當于給你指了一條路渣淤，然后告訴你沿著這條路走就是了赏寇，這樣就固化了你思想)，而Head First《設計模式》傳遞的是如何思考(相當于告訴你什么是路价认，怎么區(qū)分路嗅定，根據(jù)你自己的想法來選擇走什么路，這就給了你創(chuàng)造的空間)用踩，這在思維引導上差得真的不是一點半點渠退。
個人感覺做程序設計要比做性能優(yōu)化更看團隊的情況，因為你需要考慮團隊成員的水平脐彩，怎么協(xié)作碎乃，面對有限的開發(fā)時間怎么分配任務，怎么折中選擇實現(xiàn)等惠奸，有時候會有些有心無力的感覺梅誓。
最后
如果你看到這里還沒開噴，我也只能說聲謝謝佛南」ｊ看到這里你可能想說，文中的內(nèi)容講得太籠統(tǒng)了嗅回，這本來就不是專門針對某一塊技術來寫的帖愧怜。
最后想說的是，沒有葵花寶典(即使有也不練啊??)妈拌，也不要想著有人出來教你一套獨孤九劍拥坛。如果你想學習某一塊技術，建議找相關的專題書來看尘分，因為專題書所帶給你的全面性和專業(yè)性猜惋，不是網(wǎng)上一兩篇文章能給的。建議少用Objective-C的Runtime培愁，多思考怎么從設計上解決當前遇到的問題著摔。建議不要片面去追求底層技術的待刨根問底(我們要有刨根問底的精神，但不要片面追求)定续，除非你真的很有興趣和公司需要你這么發(fā)展谍咆，不然還是全面一點發(fā)展好，因為就像《面向?qū)ο蠓治雠c設計》這本書里面講的私股，有很多程序員都是拿著一門面向?qū)ο蟮恼Z言當作面向過程的語言來使用摹察。
