引言

過年之后相信有一部分的人，早已磨刀霍霍向大廠。勢(shì)必要大展拳腳，必將在大廠內(nèi)創(chuàng)出一片天地。但是，想必大家都知道：最近幾年的最嚴(yán)重的互聯(lián)網(wǎng)寒冬來臨，各位兄弟都會(huì)說“江湖再見”。耳邊總是充刺著流言蜚語，這個(gè)地方裁員了，這個(gè)地方縮減HC。弄得人心慌慌。年后將是一片血雨腥風(fēng)，程序界的江湖將在這一天精彩斑斕。

但我們要知道，寒冬之中，什么是最珍貴，就讓鄙人告訴你：人才。只要有過硬的技術(shù)和裝備，在逆風(fēng)直下的情況下，咱們也能迎難而上，打他個(gè)戳手不及。不是“李云龍”大哥說：“過狹路相逢勇者勝.”

最近幾天看了朋友，到處廝殺，經(jīng)過一番斗爭(zhēng)，最終奪下頭籌獲得多家大廠的offo。

承蒙兄弟抬愛，感情深厚。拿出《iOS中高級(jí)面試寶典》贈(zèng)與小弟參悟。經(jīng)過小弟我的反復(fù)參悟和整理，現(xiàn)在共享出來，希望與大家一起學(xué)習(xí)參悟。小弟我先說一下，面試雖然有技巧，但咋們絕不是吹噓與偽造之輩，因先當(dāng)花點(diǎn)時(shí)間靜心閉關(guān)修煉，帶到出關(guān)之日，必進(jìn)大廠，薪資翻倍，豈不快哉！！！

參悟規(guī)則

作為一名優(yōu)秀的程序員，肯定是不會(huì)浪費(fèi)時(shí)間在一個(gè) ：

一：沒有晉升，沒有職業(yè)發(fā)展的公司

二：也不會(huì)停留在某一個(gè)技術(shù)層面不前進(jìn)的公司

三：我愿付出真心，你卻不愿有待我的公司

本博客的知識(shí)點(diǎn)較多，花點(diǎn)時(shí)間一個(gè)個(gè)理解并記憶后，自然也就融會(huì)貫通，無所畏懼。面試iOS也就分分鐘
本寶典為了便于記憶，快速達(dá)到應(yīng)試狀態(tài)，類似于復(fù)習(xí)知識(shí)大綱。知識(shí)點(diǎn)會(huì)盡量的精簡(jiǎn)與提煉知識(shí)脈絡(luò)，并不去展開深入細(xì)節(jié)，面面俱到。有興趣或者有疑問的兄弟可以自行谷歌下對(duì)應(yīng)知識(shí)點(diǎn)的詳細(xì)內(nèi)容。

1、swift和oc的區(qū)別

(1) Swit沒有地址指針的概念

(2)泛型

(3)類型嚴(yán)謹(jǐn)對(duì)比oc的動(dòng)態(tài)綁定

2、編譯連接

• id和instancetype的區(qū)別

• instancetype只能故返回值編譯時(shí)判斷真實(shí)類型,不符合發(fā)警告

• 特殊情況:關(guān)聯(lián)類型返回方法如類方法lloc或new開頭實(shí)例方法中,以autorelease,init,retain,或self開頭

3、synthesize & denamic

1:通過@sythesize

指令告訴編譯器在編譯期間產(chǎn)生getter/setter方法。

2:通過@dynamic指令，自己實(shí)現(xiàn)方法。

有些存取是在運(yùn)行時(shí)動(dòng)態(tài)創(chuàng)建的，如在CoreData的NSManagedObject類使

4、在項(xiàng)目開發(fā)中常用的開發(fā)工具有哪些?

• instrument

• beyondCompare

• git

5、UlTableView & UlCollection

• UlCollectionView是iOS6新引進(jìn)的API,用于展示集合視圖，布局更加靈活，其用法類似于UITableView。

• 而UICollectionView、UlCollectionViewCell與UITableView、UITableViewCell在用法上有相似的也有不同的，
  下面是一些基本的使用方法:對(duì)UITableView,僅需要UITableViewDataSource,UITableViewDelegate這兩個(gè)協(xié)議

• 使用UlCollectionView需要實(shí)現(xiàn)：UICollectionViewDataSource,UlCollectionViewDelegate,
  UlCollectionViewDelegateFlowLayout這三個(gè)協(xié)議.

• 這是因?yàn)閁lCollectionViewDelegateFlowL ayou實(shí)際上是UCollectionViewDelegate的一個(gè)子協(xié)議，它繼承了
  UlCollectionViewDelegate,它的作用是提供一些定義UlCollectionView布局模式的函數(shù)

6、NSProxy & NSObject

NSObjetct:

• NSObject協(xié)議組對(duì)所有的Object -C下的objects都生效。如果objects遵從該協(xié)議，就會(huì)波看作是first -class
  objects (- 級(jí)類)。另外， 遵從該協(xié)議的objects的retain, release, autorelease等 方法也服從objects的管理和在
  Foundation中定義的釋放方法。- -些容器中的對(duì)象也可以管理這些

• objects,比如說NSArray和NSDictionary定義的對(duì)象。Cocoa的根類也遵循該協(xié)議，所以所有繼承NSObjects的
  objects都有遵循該協(xié)議的特性。

• NSProXY:NSProxy是一個(gè)虛基類，它為一些表現(xiàn)的像是其它對(duì)象替身或者并不存在的對(duì)象定義一套API。 -般
  的，發(fā)送給代理的消息被轉(zhuǎn)發(fā)給一個(gè)真實(shí)的對(duì)象或者代理本身load(或者將本身轉(zhuǎn)換成)一個(gè)真實(shí)的對(duì)象。

• NSProxy的基類可以被用來透明的轉(zhuǎn)發(fā)消息或者耗費(fèi)巨大的對(duì)象的lazy初始化。

7、Object & Swift

• Obejective-C復(fù)雜的語法，更加簡(jiǎn)單易用、有未來，讓許多開發(fā)者心動(dòng)不已.

• 蘋果宣稱Swift的特點(diǎn)是:快速、現(xiàn)代、安全、互動(dòng)，而且明顯優(yōu)于Objective-C語言
  可以使用現(xiàn)有的Cocoa和Cocoa Touch框架
  Swift取消了Objective C的指針及其他不安全訪問的使用

• 舍棄Objective C早期應(yīng)用Smalltalk的語法，全面改為句點(diǎn)表示法提供了類似Java的名字空間(namespace)、
  泛型(generic)、運(yùn)算對(duì)象重載(operator overloading) Swift 被簡(jiǎn)單的形容為“沒有C的Objective-C" (Objective- C without theC)為蘋果開發(fā)工具帶來了Xcode

• Playgrounds功能，該功能提供強(qiáng)大的互動(dòng)效果，能讓Swift源代碼在撰寫過程中實(shí)時(shí)顯示出其運(yùn)行結(jié)果;
  基于C和Objective-C,而卻沒有C的一些兼容約束; 采用了安全的編程模式;界面基于Cocoa和Cocoa Touch框架;保留Smaltalk的動(dòng)態(tài)特性

8、傳值通知&推送通知(本地&遠(yuǎn)程)

傳值通知:類似通知，代理，Block實(shí)現(xiàn)值得傳遞

推送通知:推送到用戶手機(jī)對(duì)應(yīng)的App上(主要是不再前臺(tái)的情況)本地通知。

local notfication,用于基于時(shí)間行為的通知，比如有關(guān)日歷或者todo列表的小應(yīng)用。另外，應(yīng)用如果在后臺(tái)執(zhí)
行，iOS允許它在受限的時(shí)間內(nèi)運(yùn)行，它也會(huì)發(fā)現(xiàn)本地通知有用。比如，一個(gè)應(yīng)用，在后臺(tái)運(yùn)行，向應(yīng)用的服
務(wù)器端獲取消息，當(dāng)消息到達(dá)時(shí)，比如下載更新版本的提示消息，通過本地通知機(jī)制通知用戶。

本地通知是UILocalNotification的實(shí)例，主要有三類屬性:

scheduled time,時(shí)間周期，用來指定iOS系統(tǒng)發(fā)送通知的8期和時(shí)間;
ntilication type,通知類型，包括警告信息、動(dòng)作按鈕的標(biāo)題、應(yīng)用圖標(biāo)上的badge (數(shù)字標(biāo)記)和播放的聲音:

自定義數(shù)據(jù)，本地通知可以包含一個(gè)dictionary類型的本地?cái)?shù)據(jù)。

對(duì)本地通知的數(shù)量限制，iOS最 多允許最近本地通知數(shù)量是64個(gè)，超過限制的本地通知將被iOS忽略。遠(yuǎn)程通知(需要服務(wù)器)
流程大概是這樣的

1.生成CerticateSigningRequest. certSigningRequest文件2.將CertilicateSigningRequest.certSigningRequest上傳進(jìn)developer,導(dǎo)出.cer文件3.利用CSR導(dǎo)出P12文件4.需要準(zhǔn)備下設(shè)備token值(無空格)5.使用OpenSSL合成服務(wù)器所使用的推送證書

一般使用極光推送，步驟是一樣的， 只是我們使用的服務(wù)器是極光的，不需要自己大服務(wù)器!

9、第三方庫&第三方平臺(tái)

第三方庫:

一般是指大牛封裝好的一一個(gè)框架(庫) ，或者第三方給我們提供的一個(gè)庫，這里比較籠統(tǒng)*第三方平
臺(tái):指第三方提供的-些服務(wù)，其實(shí)很多方面跟第三方庫是一樣的，但是還是存在一些區(qū)別。

區(qū)別:庫: AFN, ASI, Alomofire, MJRefresh, MJExtension, MBProgressHUD平臺(tái):極光，百度，友盟，Mob,環(huán)信

imageName和mageWithContextOfFile的區(qū)別?哪個(gè)性能高

(1)用imageNamed的方式加載時(shí)，圖片使用完畢后緩存到內(nèi)存中，內(nèi)存消耗多，加載速度快。即使生成的
對(duì)象被autoReleasePool釋放了，這份緩存也不釋放，如果圖像比較大，或者圖像比較多，用這種方式會(huì)消耗
很大的內(nèi)存。
imageNamed采用了緩存機(jī)制，如果緩存中已加載了圖片，直接從緩存讀就行了，每次就不用再去讀文件了，
效率會(huì)更高。

(2) ImageWithContextOfile加載， 圖片是不會(huì)緩存的，加載速度慢。

(3)大量使用imageNamed方式會(huì)在不需要緩存的地方額外增加開銷CPU的時(shí)間當(dāng)應(yīng)用程字需要加載- -張比較
大的圖片并且使用一次性，那么其實(shí)是沒有必要去緩存這個(gè)圖片的，用imageWithContentsOfile是 最為經(jīng)濟(jì)
的方式，這樣不會(huì)因?yàn)閁llmage元素較多情況下，CPU會(huì)被逐個(gè)分散在不必要緩存上浪費(fèi)過多時(shí)間

10、NSCache & NSDcitionary

NSCache與可變集合有幾點(diǎn)不同:

NSCache類結(jié)合了各種自動(dòng)刪除策略，以確保不會(huì)占用過多的系統(tǒng)內(nèi)存。如果其它應(yīng)用需要內(nèi)存時(shí)，系統(tǒng)自
動(dòng)執(zhí)行這些策略。當(dāng)調(diào)用這些策略時(shí)，會(huì)從緩存中刪除一些對(duì)象，以最大限度減少內(nèi)存的占用。

• NSCache是線程安全的，我們可以在不同的線程中添加、刪除和查詢緩存中的對(duì)象，而不需要鎖定緩存區(qū)域。

• 不像NSMutableDictionary對(duì)象，- 一個(gè)緩存對(duì)象不會(huì)拷貝key對(duì)象。

• NSCache和NSDictionary類似，不同的是系統(tǒng)回收內(nèi)存的時(shí)候它會(huì)自動(dòng)刪掉它的內(nèi)容。

(1)可以存儲(chǔ)(當(dāng)然是使用內(nèi)存)

(2)保持強(qiáng)應(yīng)用，無視垃圾回收. =>這-點(diǎn)同NSMutableDictionary(3)有固定客戶.

11、UlView的setNeedsDisplay和setNeedsLayout方法

• 在Mac OS中NSWindow的父類是NSResponder,而在iOS中UIWindow的父類是UIVIew。程序一般只有一一個(gè)窗口但是會(huì)又很多視圖

• UlView的作用: 描畫和動(dòng)畫，視圖負(fù)責(zé)對(duì)其所屬的矩形區(qū)域描畫、布局和子視圖管理、事件處理、可以接收觸摸事件、事件信息的載體、等等。

• UIViewController負(fù)責(zé)創(chuàng)建其管理的視圖及在低內(nèi)存的時(shí)候?qū)⑺麄儚膬?nèi)存中移除。還為標(biāo)準(zhǔn)的系統(tǒng)行為進(jìn)行響應(yīng)。

• layOutSubViews可以在自己定制的視圖中重載這個(gè)方法，用來調(diào)整子視圖的尺寸和位置。

• UIView的setNeedsDisplay(需 要重新顯示，繪制和setNeedsLayout(需要重新布局)方法。首先兩個(gè)方法都是異步執(zhí)行的。而setNeedsDisplay會(huì)調(diào)用自動(dòng)調(diào)用drawRect方法，這樣可以拿到UIGraphicsGetCurrentContext,就可以畫畫了。而setNeedslayout會(huì)默認(rèn)調(diào)用layoutSubViews,就可以處理子視圖中的一些數(shù)據(jù)。

綜上所述setNeedsDisplay方便繪圖，而layoutSubViews方便出來數(shù)據(jù)setNeedDisplay告知視圖它發(fā)生了改變,需要重新繪制自身，就相當(dāng)于刷新界面

12、UILayer & UiView

• UlView是iOS系統(tǒng)中界面元素的基礎(chǔ)，所有的界面元素都繼承自它。它本身完全是由CoreAnimation來實(shí)現(xiàn)的(Mac下似乎不是這樣)。它真正的繪圖部分，是由一個(gè)叫CAL ayer (Core Animation Layer)的類來管理。UIView本身，更像是-個(gè)CAL ayer的管理器，訪問它的跟繪圖和跟坐標(biāo)有關(guān)的屬性，例如frame, bounds等等，實(shí)際 上內(nèi)部都是在訪問它所包含的CAL ayer的相關(guān)屬性。

• UIView有個(gè)重要屬性layer,可以返回它的主CAL ayer實(shí)例。

• UIView的CAL ayer類似UIView的子View樹形結(jié)構(gòu)，也可以向它的layer上添加子layer,來完成某些特殊的表示。即CALayer層是可以嵌套的。

• UIView的ayer樹形在系統(tǒng)內(nèi)部，被維護(hù)著三份opy。分別是邏輯樹，這里是代碼可以操縱的;動(dòng)畫樹，是一個(gè)中間層，系統(tǒng)就在這一層上更改屬性，進(jìn)行各種渲染操作;顯示樹，其內(nèi)容就是當(dāng)前正被顯示在屏幕上得內(nèi)容。

動(dòng)畫的運(yùn)作: 對(duì)UMiew的sublayer(非主Layer)屬性進(jìn)行更改，系統(tǒng)將自動(dòng)進(jìn)行動(dòng)畫生成，動(dòng)畫持續(xù)時(shí)間的缺省值似乎是0.5秒。

坐標(biāo)系統(tǒng): CAL ayer的坐標(biāo)系統(tǒng)比UIView多了-個(gè)anchorPoint屬性,使用CGPoint結(jié)構(gòu)表示，值域是0~1,是個(gè)比例值。

渲染: 當(dāng)更新層，改變不能立即顯示在屏幕上。當(dāng)所有的層都準(zhǔn)備好時(shí)，可以調(diào)用setNeedsDisplay方法來重繪顯示。

變換: 要在一個(gè)層中添加- -個(gè)3D或仿射變換，可以分別設(shè)置層的transform或fineTranstorm屬性。

變形: Quartz Core的渲染能力，使二維圖像可以被自由操縱，就好像是三維的。圖像可以在一個(gè)三維坐標(biāo)系中以任意角度被旋轉(zhuǎn)，縮放和傾斜。CATranstform3D的一套方法提供了一些魔術(shù)般的變換效果。

13、layoutSubViews & drawRects

layoutSubviews在以下情況下會(huì)波調(diào)用(視圖位置變化是觸發(fā)):

1、init初始化不會(huì)觸發(fā)layoutSubviews。2、addSubview會(huì)觸發(fā)layoutSubviews。3、設(shè)置Vview的Frame會(huì)觸發(fā)layoutSubviews,當(dāng)然前提是frame的值設(shè)置前后發(fā)生了變化。4、滾動(dòng)一個(gè)UISCrollView會(huì)觸發(fā)layoutSubviews。5、旋轉(zhuǎn)Screen會(huì)觸發(fā)父UIView上的layoutSubviews事件。6、改變一個(gè)UIView大小的時(shí)候也會(huì)觸發(fā)父UIView上的layoutSubviews事件。7、直接調(diào)用setLayoutSubviews。

drawRect在以下情況下會(huì)被調(diào)用:

1、如果在UIView初始化時(shí)沒有設(shè)置rect大小，將直接導(dǎo)致drawRect不被自動(dòng)調(diào)用。drawRect 掉用是在Controller->loadView,Controller->viewDidLoad兩方法之后掉用的.所以不用擔(dān)心在控制器中，這些View的drawRect就開始畫了.這樣可以在控制器中設(shè)置-些值給View(如果這些View draw的時(shí)候需要用到某些變量值).

2、該方法在調(diào)用sizeToFit后被調(diào)用，所以可以先調(diào)用sizeToFt計(jì)算出size。然后系統(tǒng)自動(dòng)調(diào)用drawRect:方法。

3、通過設(shè)置contentMode屬性直為UIViewContentModeRedraw。那么將在每次設(shè)置或更改rame的時(shí)候自動(dòng)調(diào)用dr awRect。

4、直接調(diào)用setNeedsDisplay, 或者setNeedsDisplaylnRect:觸發(fā)drawRect,但是有個(gè)前提條件是rect不能為0。

drawRect方法使用注意點(diǎn):

1、若使用UIView繪圖，只能在drawRect:方法中獲取相應(yīng)的contextRef并繪圖。如果在其他方法中獲取將獲取到一個(gè)invalidate的ref并且不能用于畫圖。

drawRect: 方法不能手動(dòng)顯示調(diào)用，必須通過調(diào)用setNeedsDisplay或者setNeedsDisplaynRect,讓系統(tǒng)自動(dòng)調(diào)該方法。

2、若使用calayer繪圖，只能在drawInContext: 中(類 似魚drawRect)繪制，或者在delegate中的相應(yīng)方法繪制。同樣也是調(diào)用setNeedDisplay等間接調(diào)用以上方法

3、若要實(shí)時(shí)畫圖，不能使HgestureRecognizer,只能使用touchbegan等方法來掉用setNeedsDisplay實(shí)時(shí)刷新屏幕

14、UDID & UUID

UDID是Unique Device ldentifer的縮寫中文意思是設(shè)備唯一標(biāo)識(shí)

在很多需要限制一臺(tái)設(shè)備一個(gè)賬號(hào)的應(yīng)用中經(jīng)常會(huì)用到，在Symbian時(shí)代,我們是使用IMEI作為設(shè)備的唯一標(biāo)識(shí)的,可惜的是Apple官方不允許開發(fā)者獲得設(shè)備的IMEI.

lUlDevice currentDevicel uniqueldentie]

但是我們需要注意的一點(diǎn)是,對(duì)于已越獄了的設(shè)備,UDID并不是唯一的 使用Cydia插件UDIDFaker,可以為每一個(gè)應(yīng)用分配不同的UDID.所以UDID作為標(biāo)識(shí)唯一設(shè)備的用途已經(jīng)不大了。

UUID是Universally Unique ldentifier的縮寫，中文意思是通用唯一識(shí)別碼由網(wǎng)上資料顯示,UUID是一個(gè)軟件建構(gòu)的標(biāo)準(zhǔn)，也是被開源軟件基金會(huì)(Open Software Foundation,OSF)的組織在分布式計(jì)算環(huán)境(DistributedComputing Enviroment,DCE)領(lǐng)域的一部份.UUID的目的,是 讓分布式系統(tǒng)中的所有元素都能有唯一的辨識(shí)資訊,而不需要透過中央控制端來做辨識(shí)資訊的指定。

15、CPU & GPU

CPU:中央處理器(英 文Central ProcessingUnit)是一臺(tái)計(jì)算機(jī)的運(yùn)算核心和控制核心。CPU、內(nèi)部存儲(chǔ)器和輸入輸出設(shè)備是電子計(jì)算機(jī)三大核心部件。其功能主要是解釋計(jì)算機(jī)指令以及處理計(jì)算機(jī)軟件中的數(shù)據(jù)。

GPU:英文全稱Graphic Processing Unit,中文翻譯為“圖形處理器”。一個(gè)專門的圖形核心處理器。GPU是顯示卡的“大腦”，決定了該顯卡的檔次和大部分性能，同時(shí)也是2D顯示卡和3D顯示卡的區(qū)別依據(jù)。2D顯示芯片在處理3D圖像和特效時(shí)主要依賴CPU的處理能力，稱為“軟加速”。3D顯示芯片是將三維圖像和特效處理功能集中在顯示芯片內(nèi)，也即所謂的"硬件加速"功能

結(jié)語

由于寶典內(nèi)容過多，我就不一一介紹，就先寫到這里的吧！大家不用著急慢慢來。給大家看看目錄吧！

每個(gè)大廠的面試并不是很容易對(duì)付，很多的技術(shù)領(lǐng)域并沒有真正的答案，看自己能給出讓人滿意的回答，最終還靠自己去實(shí)踐、研究。知識(shí)方面的深度與廣度都該在同一條路上，升華自己。如不嫌棄我自己有個(gè)私人群：551346706，進(jìn)群可以在群文件里面獲取這篇面試題的全部答案，學(xué)習(xí)資料，iOS相關(guān)方面的電子書。群里純技術(shù)交流！

總結(jié)

以上是生活随笔為你收集整理的中高级iOS大厂面试宝典，进厂率80%，金三银四将是你的新起点的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。