組件化

1.組件化有什么好處？

• 業(yè)務(wù)分層、解耦，使代碼變得可維護(hù)；

• 有效的拆分、組織日益龐大的工程代碼，使工程目錄變得可維護(hù)；

• 便于各業(yè)務(wù)功能拆分、抽離，實(shí)現(xiàn)真正的功能復(fù)用；

• 業(yè)務(wù)隔離，跨團(tuán)隊(duì)開(kāi)發(fā)代碼控制和版本風(fēng)險(xiǎn)控制的實(shí)現(xiàn)；

• 模塊化對(duì)代碼的封裝性、合理性都有一定的要求，提升開(kāi)發(fā)同學(xué)的設(shè)計(jì)能力；

• 在維護(hù)好各級(jí)組件的情況下，隨意組合滿足不同客戶需求；（只需要將之前的多個(gè)業(yè)務(wù)組件模塊在新的主App中進(jìn)行組裝即可快速迭代出下一個(gè)全新App）

2.你是如何組件化解耦的？

• 分層

  基礎(chǔ)功能組件：按功能分庫(kù)，不涉及產(chǎn)品業(yè)務(wù)需求，跟庫(kù)Library類似，通過(guò)良好的接口拱上層業(yè)務(wù)組件調(diào)用；不寫(xiě)入產(chǎn)品定制邏輯，通過(guò)擴(kuò)展接口完成定制；

  基礎(chǔ)UI組件：各個(gè)業(yè)務(wù)模塊依賴使用，但需要保持好定制擴(kuò)展的設(shè)計(jì)

  業(yè)務(wù)組件：業(yè)務(wù)功能間相對(duì)獨(dú)立，相互間沒(méi)有Model共享的依賴；業(yè)務(wù)之間的頁(yè)面調(diào)用只能通過(guò)UIBus進(jìn)行跳轉(zhuǎn)；業(yè)務(wù)之間的邏輯Action調(diào)用只能通過(guò)服務(wù)提供；

• 中間件：target-action，url-block，protocol-class

3.為什么CTMediator方案優(yōu)于基于Router的方案？

Router的缺點(diǎn)：

• 在組件化的實(shí)施過(guò)程中，注冊(cè)URL并不是充分必要條件。組件是不需要向組件管理器注冊(cè)URL的，注冊(cè)了URL之后，會(huì)造成不必要的內(nèi)存常駐。注冊(cè)URL的目的其實(shí)是一個(gè)服務(wù)發(fā)現(xiàn)的過(guò)程，在iOS領(lǐng)域中，服務(wù)發(fā)現(xiàn)的方式是不需要通過(guò)主動(dòng)注冊(cè)的，使用runtime就可以了。另外，注冊(cè)部分的代碼的維護(hù)是一個(gè)相對(duì)麻煩的事情，每一次支持新調(diào)用時(shí)，都要去維護(hù)一次注冊(cè)列表。如果有調(diào)用被棄用了，是經(jīng)常會(huì)忘記刪項(xiàng)目的。runtime由于不存在注冊(cè)過(guò)程，那就也不會(huì)產(chǎn)生維護(hù)的操作，維護(hù)成本就降低了。 由于通過(guò)runtime做到了服務(wù)的自動(dòng)發(fā)現(xiàn)，拓展調(diào)用接口的任務(wù)就僅在于各自的模塊，任何一次新接口添加，新業(yè)務(wù)添加，都不必去主工程做操作，十分透明。

• 在iOS領(lǐng)域里，一定是組件化的中間件為openURL提供服務(wù)，而不是openURL方式為組件化提供服務(wù)。如果在給App實(shí)施組件化方案的過(guò)程中是基于openURL的方案的話，有一個(gè)致命缺陷：非常規(guī)對(duì)象(不能被字符串化到URL中的對(duì)象，例如UIImage)無(wú)法參與本地組件間調(diào)度。
  在本地調(diào)用中使用URL的方式其實(shí)是不必要的，如果業(yè)務(wù)工程師在本地間調(diào)度時(shí)需要給出URL，那么就不可避免要提供params，在調(diào)用時(shí)要提供哪些params是業(yè)務(wù)工程師很容易懵逼的地方。

• 為了支持傳遞非常規(guī)參數(shù)，蘑菇街的方案采用了protocol，這個(gè)會(huì)侵入業(yè)務(wù)。由于業(yè)務(wù)中的某個(gè)對(duì)象需要被調(diào)用，因此必須要符合某個(gè)可被調(diào)用的protocol，然而這個(gè)protocol又不存在于當(dāng)前業(yè)務(wù)領(lǐng)域，于是當(dāng)前業(yè)務(wù)就不得不依賴public Protocol。這對(duì)于將來(lái)的業(yè)務(wù)遷移是有非常大的影響的。

CTMediator的優(yōu)點(diǎn)：

• 調(diào)用時(shí)，區(qū)分了本地應(yīng)用調(diào)用和遠(yuǎn)程應(yīng)用調(diào)用。本地應(yīng)用調(diào)用為遠(yuǎn)程應(yīng)用調(diào)用提供服務(wù)。

• 組件僅通過(guò)Action暴露可調(diào)用接口，模塊與模塊之間的接口被固化在了Target-Action這一層，避免了實(shí)施組件化的改造過(guò)程中，對(duì)Business的侵入，同時(shí)也提高了組件化接口的可維護(hù)性。

• 方便傳遞各種類型的參數(shù)。

4.基于CTMediator的組件化方案，有哪些核心組成？

• CTMediator中間件：集成就可以了

• 模塊Target_%@：模塊的實(shí)現(xiàn)及提供對(duì)外的方法調(diào)用Action_methodName，需要傳參數(shù)時(shí)，都統(tǒng)一以NSDictionary*的形式傳入。

• CTMediator+%@擴(kuò)展：擴(kuò)展里聲明了模塊業(yè)務(wù)的對(duì)外接口，參數(shù)明確，這樣外部調(diào)用者可以很容易理解如何調(diào)用接口。

持續(xù)集成

1.你在項(xiàng)目中使用過(guò)什么持續(xù)集成方式？

• Fastlane：一套用Ruby寫(xiě)的自動(dòng)化工具集，可用于iOS和Android的打包、發(fā)布，節(jié)省了大量時(shí)間。Fastlane配置比較簡(jiǎn)單，主要編寫(xiě)集成的lane，然后在命令行操作即可

• Jenkins：Jenkins比較受歡迎，插件眾多，但對(duì)新手來(lái)說(shuō)配置可能稍微麻煩點(diǎn)。

2.jenkins怎么備份恢復(fù)

• 只需要拷貝主home下面的 .jenkins打個(gè)包，下次要恢復(fù)就用這個(gè)覆蓋，所有的東西就都一模一樣了。其實(shí)就是配置的東西都在這里面，插件的話有個(gè)Plugin的文件夾下面就是所有的插件的東西。

3.jenkins你都用了哪些插件？

• Keychains and Provisioning Profiles Management：管理本地的keychain和iOS證書(shū)的插件

• Xcode integration：用于Xcode構(gòu)建

• GIT plugin/SVN：代碼管理插件

項(xiàng)目架構(gòu)

1.MVC、MVP、MVVM模式

MVC（Model、View、Controller）

MVC是比較直觀的架構(gòu)模式，最核心的就是通過(guò)Controller層來(lái)進(jìn)行調(diào)控，首先看一下官方提供的MVC示意圖：

mvc

• Model和View永遠(yuǎn)不能相互通信，只能通過(guò)Controller傳遞

• Controller可以直接與Model對(duì)話（讀寫(xiě)調(diào)用Model），Model通過(guò)NOtification和KVO機(jī)制與Controller間接通信

Controller可以直接與View對(duì)話，通過(guò)IBoutlet直接操作View，IBoutlet直接對(duì)應(yīng)View的控件（例如創(chuàng)建一個(gè)Button：需聲明一個(gè) IBOutlet UIButton * btn），View通過(guò)action向Controller報(bào)告時(shí)間的發(fā)生(用戶點(diǎn)擊了按鈕)。Controller是View的直接數(shù)據(jù)源

• 優(yōu)點(diǎn)：對(duì)于混亂的項(xiàng)目組織方式，有了一個(gè)明確的組織方式。通過(guò)Controller來(lái)掌控全局，同時(shí)將View展示和Model的變化分開(kāi)

• 缺點(diǎn)：愈發(fā)笨重的Controller，隨著業(yè)務(wù)邏輯的增加，大量的代碼放進(jìn)Controller，導(dǎo)致Controller越來(lái)越臃腫，堆積成千上萬(wàn)行代碼，后期維護(hù)起來(lái)費(fèi)時(shí)費(fèi)力

MVP（Model、View、Presenter）

MVP模式是MVC模式的一個(gè)演化版本，其中Model與MVC模式中Model層沒(méi)有太大區(qū)別，主要提供數(shù)據(jù)存儲(chǔ)功能，一般都是用來(lái)封裝網(wǎng)絡(luò)獲取的json數(shù)據(jù)；View與MVC中的View層有一些差別，MVP中的View層可以是viewController、view等控件；Presenter層則是作為Model和View的中介，從Model層獲取數(shù)據(jù)之后傳給View。

mvp

從上圖可以看出，從MVC模式中增加了Presenter層，將UIViewController中復(fù)雜的業(yè)務(wù)邏輯、網(wǎng)絡(luò)請(qǐng)求等剝離出來(lái)。

• 優(yōu)點(diǎn) 模型和視圖完全分離，可以做到修改視圖而不影響模型；更高效的使用模型，View不依賴Model，可以說(shuō)VIew能做到對(duì)業(yè)務(wù)邏輯完全分離

• 缺點(diǎn) Presenter中除了處理業(yè)務(wù)邏輯以外，還要處理View-Model兩層的協(xié)調(diào)，也會(huì)導(dǎo)致Presenter層的臃腫

MVVM（Model、Controller/View、ViewModel）

在MVVM中，view和ViewCOntroller聯(lián)系在一起，我們把它們視為一個(gè)組件，view和ViewController都不能直接引用model，而是引用是視圖模型即ViewModel。
viewModel是一個(gè)用來(lái)放置用戶輸入驗(yàn)證邏輯、視圖顯示邏輯、網(wǎng)絡(luò)請(qǐng)求等業(yè)務(wù)邏輯的地方，這樣的設(shè)計(jì)模式，會(huì)輕微增加代碼量，但是會(huì)減少代碼的復(fù)雜性

• 優(yōu)點(diǎn) VIew可以獨(dú)立于Model的變化和修改，一個(gè)ViewModel可以綁定到不同的View上，降低耦合，增加重用

• 缺點(diǎn) 過(guò)于簡(jiǎn)單的項(xiàng)目不適用、大型的項(xiàng)目視圖狀態(tài)較多時(shí)構(gòu)建和維護(hù)成本太大

合理的運(yùn)用架構(gòu)模式有利于項(xiàng)目、團(tuán)隊(duì)開(kāi)發(fā)工作，但是到底選擇哪個(gè)設(shè)計(jì)模式，哪種設(shè)計(jì)模式更好，就像本文開(kāi)頭所說(shuō)，不同的設(shè)計(jì)模式，只是讓不同的場(chǎng)景有了更多的選擇方案。根據(jù)項(xiàng)目場(chǎng)景和開(kāi)發(fā)需求，選擇最合適的解決方案。

2.關(guān)于RAC你有怎樣運(yùn)用到解決不同API依賴關(guān)系

• 信號(hào)的依賴：使用場(chǎng)景是當(dāng)信號(hào)A執(zhí)行完才會(huì)執(zhí)行信號(hào)B,和請(qǐng)求的依賴很類似,例如請(qǐng)求A請(qǐng)求完畢才執(zhí)行請(qǐng)求B,我們需要注意信號(hào)A必須要執(zhí)行發(fā)送完成信號(hào),否則信號(hào)B無(wú)法執(zhí)行

  //這相當(dāng)于網(wǎng)絡(luò)請(qǐng)求中的依賴,必須先執(zhí)行完信號(hào)A才會(huì)執(zhí)行信號(hào)B
  //經(jīng)常用作一個(gè)請(qǐng)求執(zhí)行完畢后,才會(huì)執(zhí)行另一個(gè)請(qǐng)求
  //注意信號(hào)A必須要執(zhí)行發(fā)送完成信號(hào),否則信號(hào)B無(wú)法執(zhí)行
  RACSignal * concatSignal = [self.signalA concat:self.signalB]
  //這里我們是對(duì)這個(gè)拼接信號(hào)進(jìn)行訂閱
  [concatSignal subscribeNext:^(id x) {
      NSLog(@"%@",x);
  }];
  

3.@weakify和我們宏定義的WeakSelf有什么區(qū)別？

@weakify 可以多參數(shù)使用

4.微服務(wù)架構(gòu)設(shè)想。

微服務(wù)架構(gòu)具有以下優(yōu)勢(shì)：

• 1.靈活和獨(dú)立的可擴(kuò)展性

  靈活擴(kuò)展是微服務(wù)架構(gòu)的主要優(yōu)勢(shì)之一。與單片架構(gòu)不同，每個(gè)模塊都可以水平擴(kuò)展并獨(dú)立于其他模塊。因此，微服務(wù)架構(gòu)非常適合大型項(xiàng)目。

• 2.獨(dú)立技術(shù)堆棧

  在微服務(wù)架構(gòu)中，軟件工程師有機(jī)會(huì)使用各種工具和技術(shù)構(gòu)建APP。代碼可以用不同的編程語(yǔ)言編寫(xiě)，這為APP開(kāi)發(fā)過(guò)程增加了更多的靈活性。

• 3.更好的故障隔離

  如果一個(gè)服務(wù)失敗，它不會(huì)影響其他服務(wù)的功能。與其他體系結(jié)構(gòu)樣式相比，在微服務(wù)中，系統(tǒng)繼續(xù)工作，單片模式下的問(wèn)題會(huì)影響整個(gè)APP。

• 4.易于部署和集成

  雖然即使是小代碼更改的情況下，開(kāi)發(fā)人員也必須再次部署APP，但在微服務(wù)架構(gòu)中，部署變得更快更輕松。

  由于所有服務(wù)都是圍繞單一業(yè)務(wù)流程構(gòu)建的，因此程序員不必修改和重新部署整個(gè)APP，只需要您需要的區(qū)域。因此，改進(jìn)產(chǎn)品也比較簡(jiǎn)單。

  微服務(wù)可以通過(guò)全自動(dòng)部署機(jī)制獨(dú)立部署。此外，通過(guò)使用開(kāi)源持續(xù)集成工具，開(kāi)發(fā)人員大大簡(jiǎn)化了與第三方服務(wù)的集成。

• 5.容易理解

  微服務(wù)體系結(jié)構(gòu)的另一個(gè)優(yōu)點(diǎn)是很容易理解系統(tǒng)是如何工作的以及它是如何開(kāi)發(fā)的。當(dāng)一個(gè)新的團(tuán)隊(duì)成員來(lái)到這個(gè)項(xiàng)目并且必須快速鉆研它時(shí)，這特別有用。

那么在iOS中如何借鑒這種思想去構(gòu)建我們的App呢？是需要我們開(kāi)發(fā)者自己去不斷探索的

性能優(yōu)化

1.造成tableView卡頓的原因有哪些？

• 1.最常用的就是cell的重用， 注冊(cè)重用標(biāo)識(shí)符

  如果不重用cell時(shí)，每當(dāng)一個(gè)cell顯示到屏幕上時(shí)，就會(huì)重新創(chuàng)建一個(gè)新的cell

  如果有很多數(shù)據(jù)的時(shí)候，就會(huì)堆積很多cell。

  如果重用cell，為cell創(chuàng)建一個(gè)ID，每當(dāng)需要顯示cell 的時(shí)候，都會(huì)先去緩沖池中尋找可循環(huán)利用的cell，如果沒(méi)有再重新創(chuàng)建cell

• 2.避免cell的重新布局

  cell的布局填充等操作 比較耗時(shí)，一般創(chuàng)建時(shí)就布局好

  如可以將cell單獨(dú)放到一個(gè)自定義類，初始化時(shí)就布局好

• 3.提前計(jì)算并緩存cell的屬性及內(nèi)容

  當(dāng)我們創(chuàng)建cell的數(shù)據(jù)源方法時(shí)，編譯器并不是先創(chuàng)建cell 再定cell的高度

  而是先根據(jù)內(nèi)容一次確定每一個(gè)cell的高度，高度確定后，再創(chuàng)建要顯示的cell，滾動(dòng)時(shí)，每當(dāng)cell進(jìn)入憑虛都會(huì)計(jì)算高度，提前估算高度告訴編譯器，編譯器知道高度后，緊接著就會(huì)創(chuàng)建cell，這時(shí)再調(diào)用高度的具體計(jì)算方法，這樣可以方式浪費(fèi)時(shí)間去計(jì)算顯示以外的cell

• 4.減少cell中控件的數(shù)量

  盡量使cell得布局大致相同，不同風(fēng)格的cell可以使用不用的重用標(biāo)識(shí)符，初始化時(shí)添加控件，

  不適用的可以先隱藏

• 5.不要使用ClearColor，無(wú)背景色，透明度也不要設(shè)置為0

  渲染耗時(shí)比較長(zhǎng)

• 6.使用局部更新

  如果只是更新某組的話，使用reloadSection進(jìn)行局部更

• 7.加載網(wǎng)絡(luò)數(shù)據(jù)，下載圖片，使用異步加載，并緩存

• 8.少使用addView 給cell動(dòng)態(tài)添加view

• 9.按需加載cell，cell滾動(dòng)很快時(shí)，只加載范圍內(nèi)的cell

• 10.不要實(shí)現(xiàn)無(wú)用的代理方法，tableView只遵守兩個(gè)協(xié)議

• 11.緩存行高：estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同時(shí)存在，這兩者同時(shí)存在才會(huì)出現(xiàn)“竄動(dòng)”的bug。所以我的建議是：只要是固定行高就寫(xiě)預(yù)估行高來(lái)減少行高調(diào)用次數(shù)提升性能。如果是動(dòng)態(tài)行高就不要寫(xiě)預(yù)估方法了，用一個(gè)行高的緩存字典來(lái)減少代碼的調(diào)用次數(shù)即可

• 12.不要做多余的繪制工作。在實(shí)現(xiàn)drawRect:的時(shí)候，它的rect參數(shù)就是需要繪制的區(qū)域，這個(gè)區(qū)域之外的不需要進(jìn)行繪制。例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判斷是否需要繪制image和text，然后再調(diào)用繪制方法。

• 13.預(yù)渲染圖像。當(dāng)新的圖像出現(xiàn)時(shí)，仍然會(huì)有短暫的停頓現(xiàn)象。解決的辦法就是在bitmap context里先將其畫(huà)一遍，導(dǎo)出成UIImage對(duì)象，然后再繪制到屏幕；

• 14.使用正確的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)數(shù)據(jù)。

2.如何提升 tableview 的流暢度？

• 本質(zhì)上是降低 CPU、GPU 的工作，從這兩個(gè)大的方面去提升性能。

  CPU：對(duì)象的創(chuàng)建和銷毀、對(duì)象屬性的調(diào)整、布局計(jì)算、文本的計(jì)算和排版、圖片的格式轉(zhuǎn)換和解碼、圖像的繪制

  GPU：紋理的渲染

• 卡頓優(yōu)化在 CPU 層面

  盡量用輕量級(jí)的對(duì)象，比如用不到事件處理的地方，可以考慮使用 CALayer 取代 UIView

  不要頻繁地調(diào)用 UIView 的相關(guān)屬性，比如 frame、bounds、transform 等屬性，盡量減少不必要的修改

  盡量提前計(jì)算好布局，在有需要時(shí)一次性調(diào)整對(duì)應(yīng)的屬性，不要多次修改屬性

  Autolayout 會(huì)比直接設(shè)置 frame 消耗更多的 CPU 資源

  圖片的 size 最好剛好跟 UIImageView 的 size 保持一致

  控制一下線程的最大并發(fā)數(shù)量

  盡量把耗時(shí)的操作放到子線程

  文本處理（尺寸計(jì)算、繪制）

  圖片處理（解碼、繪制）

• 卡頓優(yōu)化在 GPU層面

  盡量避免短時(shí)間內(nèi)大量圖片的顯示，盡可能將多張圖片合成一張進(jìn)行顯示

  GPU能處理的最大紋理尺寸是 4096x4096，一旦超過(guò)這個(gè)尺寸，就會(huì)占用 CPU 資源進(jìn)行處理，所以紋理盡量不要超過(guò)這個(gè)尺寸

  盡量減少視圖數(shù)量和層次

  減少透明的視圖（alpha<1），不透明的就設(shè)置 opaque 為 YES

  盡量避免出現(xiàn)離屏渲染

• iOS 保持界面流暢的技巧

  1.預(yù)排版，提前計(jì)算

  在接收到服務(wù)端返回的數(shù)據(jù)后，盡量將 CoreText 排版的結(jié)果、單個(gè)控件的高度、cell 整體的高度提前計(jì)算好，將其存儲(chǔ)在模型的屬性中。需要使用時(shí)，直接從模型中往外取，避免了計(jì)算的過(guò)程。

  盡量少用 UILabel，可以使用 CALayer 。避免使用 AutoLayout 的自動(dòng)布局技術(shù)，采取純代碼的方式

  2.預(yù)渲染，提前繪制

  例如圓形的圖標(biāo)可以提前在，在接收到網(wǎng)絡(luò)返回?cái)?shù)據(jù)時(shí)，在后臺(tái)線程進(jìn)行處理，直接存儲(chǔ)在模型數(shù)據(jù)里，回到主線程后直接調(diào)用就可以了

  避免使用 CALayer 的 Border、corner、shadow、mask 等技術(shù)，這些都會(huì)觸發(fā)離屏渲染。

  3.異步繪制

  4.全局并發(fā)線程

  5.高效的圖片異步加載

3.APP啟動(dòng)時(shí)間應(yīng)從哪些方面優(yōu)化？

App啟動(dòng)時(shí)間可以通過(guò)xcode提供的工具來(lái)度量，在Xcode的Product->Scheme-->Edit Scheme->Run->Auguments中，將環(huán)境變量DYLD_PRINT_STATISTICS設(shè)為YES，優(yōu)化需以下方面入手

• dylib loading time

  核心思想是減少dylibs的引用

  合并現(xiàn)有的dylibs（最好是6個(gè)以內(nèi)）

  使用靜態(tài)庫(kù)

• rebase/binding time

  核心思想是減少DATA塊內(nèi)的指針

  減少Object C元數(shù)據(jù)量，減少Objc類數(shù)量，減少實(shí)例變量和函數(shù)（與面向?qū)ο笤O(shè)計(jì)思想沖突）

  減少c++虛函數(shù)

  多使用Swift結(jié)構(gòu)體（推薦使用swift）

• ObjC setup time

  核心思想同上，這部分內(nèi)容基本上在上一階段優(yōu)化過(guò)后就不會(huì)太過(guò)耗時(shí)

  initializer time

• 使用initialize替代load方法

  減少使用c/c++的attribute((constructor))；推薦使用dispatch_once() pthread_once() std:once()等方法

  推薦使用swift

  不要在初始化中調(diào)用dlopen()方法，因?yàn)榧虞d過(guò)程是單線程，無(wú)鎖，如果調(diào)用dlopen則會(huì)變成多線程，會(huì)開(kāi)啟鎖的消耗，同時(shí)有可能死鎖

  不要在初始化中創(chuàng)建線程

4.如何降低APP包的大小

降低包大小需要從兩方面著手

• 可執(zhí)行文件

  編譯器優(yōu)化：Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default 設(shè)置為 YES，去掉異常支持，Enable C++ Exceptions、Enable Objective-C Exceptions 設(shè)置為 NO， Other C Flags 添加 -fno-exceptions
  利用 AppCode 檢測(cè)未使用的代碼：菜單欄 -> Code -> Inspect Code

  編寫(xiě)LLVM插件檢測(cè)出重復(fù)代碼、未被調(diào)用的代碼

• 資源（圖片、音頻、視頻 等）

  優(yōu)化的方式可以對(duì)資源進(jìn)行無(wú)損的壓縮

  去除沒(méi)有用到的資源： https://github.com/tinymind/LSUnusedResources

5.如何檢測(cè)離屏渲染與優(yōu)化

• 檢測(cè)，通過(guò)勾選Xcode的Debug->View Debugging-->Rendering->Run->Color Offscreen-Rendered Yellow項(xiàng)。

• 優(yōu)化，如陰影，在繪制時(shí)添加陰影的路徑

6.怎么檢測(cè)圖層混合

1、模擬器debug中color blended layers紅色區(qū)域表示圖層發(fā)生了混合

2、Instrument-選中Core Animation-勾選Color Blended Layers

避免圖層混合：

• 確保控件的opaque屬性設(shè)置為true，確保backgroundColor和父視圖顏色一致且不透明

• 如無(wú)特殊需要，不要設(shè)置低于1的alpha值

• 確保UIImage沒(méi)有alpha通道

UILabel圖層混合解決方法：

iOS8以后設(shè)置背景色為非透明色并且設(shè)置label.layer.masksToBounds=YES讓label只會(huì)渲染她的實(shí)際size區(qū)域，就能解決UILabel的圖層混合問(wèn)題

iOS8 之前只要設(shè)置背景色為非透明的就行

為什么設(shè)置了背景色但是在iOS8上仍然出現(xiàn)了圖層混合呢？

UILabel在iOS8前后的變化，在iOS8以前，UILabel使用的是CALayer作為底圖層，而在iOS8開(kāi)始，UILabel的底圖層變成了_UILabelLayer，繪制文本也有所改變。在背景色的四周多了一圈透明的邊，而這一圈透明的邊明顯超出了圖層的矩形區(qū)域，設(shè)置圖層的masksToBounds為YES時(shí)，圖層將會(huì)沿著B(niǎo)ounds進(jìn)行裁剪 圖層混合問(wèn)題解決了

7.日常如何檢查內(nèi)存泄露？

• 目前我知道的方式有以下幾種

  Memory Leaks

  Alloctions

  Analyse

  Debug Memory Graph

  MLeaksFinder

• 泄露的內(nèi)存主要有以下兩種：

  Laek Memory 這種是忘記 Release 操作所泄露的內(nèi)存。

  Abandon Memory 這種是循環(huán)引用，無(wú)法釋放掉的內(nèi)存。