常用的設(shè)計模式
?單例模式
?組合模式
?觀察者模式
?代理模式
?享元模式
?工廠方法模式
?抽象工廠模式
#MVC的理解
?數(shù)據(jù)管理者(M)、數(shù)據(jù)展示者(V)、數(shù)據(jù)加工者(C)
? M應(yīng)該做的事：
○給ViewController提供數(shù)據(jù)
○給ViewController存儲數(shù)據(jù)提供接口
○提供經(jīng)過抽象的業(yè)務(wù)基本組件，供Controller調(diào)度
? C應(yīng)該做的事：
○管理View
Container的生命周期
○負責生成所有的View實例，并放入View
Container
○監(jiān)聽來自View與業(yè)務(wù)有關(guān)的事件，通過與Model的合作，來完成對應(yīng)事件的業(yè)務(wù)。
? V應(yīng)該做的事：
○響應(yīng)與業(yè)務(wù)無關(guān)的事件，并因此引發(fā)動畫效果，點擊反饋（如果合適的話，盡量還是放在View去做）等。
○界面元素表達
#MVC和MVVM的區(qū)別
? MVVM是對胖模型進行的拆分，其本質(zhì)是給控制器減負，將一些弱業(yè)務(wù)邏輯放到VM中處理
? MVC是一切設(shè)計的基礎(chǔ)，所有新的設(shè)計模式都是基于MVC進行的改進
?補充：常見的設(shè)計模式有：MVC、MVCS、MVVM、viper
#TCP和UDP有什么區(qū)別？
? TCP是面向連接的，建立連接需要經(jīng)歷三次握手，保證數(shù)據(jù)正確性和數(shù)據(jù)順序
? UDP是非連接的協(xié)議，傳送數(shù)據(jù)受生成速度，傳輸帶寬等限制，可能造成丟包
? UDP一臺服務(wù)端可以同時向多個客戶端傳輸信息
? TCP報頭體積更大，對系統(tǒng)資源要求更多
#TCP的三次握手
?第一次握手：客戶端發(fā)送syn包到服務(wù)器，并進入syn_send狀態(tài)，等待服務(wù)器進行確認；
?第二次握手：服務(wù)器收到客戶端的syn包，必須確認客戶的SYN，同時自己也發(fā)送一個SYN包,即SYN + ACK包，此時服務(wù)器進入SYN_RECV狀態(tài);
?第三次握手：客戶收到服務(wù)器發(fā)送的SYN+ACK包之后，向服務(wù)器發(fā)送確認包,此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)，完成第三次握手。
#如何制作一個靜態(tài)庫/動態(tài)庫？他們的區(qū)別是什么？
? Xcode6支持制作靜態(tài)庫/動態(tài)庫framework
?無論是動態(tài)庫還是靜態(tài)庫都是區(qū)分真機和模擬器的
?靜態(tài)庫編譯靜態(tài)庫文件裝入程序空間，動態(tài)庫是文件動態(tài)裝入內(nèi)存
?動態(tài)庫執(zhí)行到相關(guān)函數(shù)才會被調(diào)用，節(jié)省空間
?蘋果一般不允許第三方動態(tài)庫，APP容易被拒
-一個lib包含了很多的架構(gòu)，會打到最后的包里么？
?不會，如果lib中有armv7,
armv7s, arm64, i386,x86_64架構(gòu)，而target architecture選擇了armv7s,arm64，那么只會從lib中l(wèi)ink指定的這兩個架構(gòu)的二進制代碼，其他架構(gòu)下的代碼不會link到最終可執(zhí)行文件中；反過來，一個lib需要在模擬器環(huán)境中正常link，也得包含i386架構(gòu)的指令
每一個設(shè)備都有屬于自己的CPU架構(gòu)
每一個靜態(tài)支持的架構(gòu)是固定
模擬器
4s-->5 : i386
5s-->6plus : x86_64
真機
3gs-->4s : armv7
5/5c :
armv7s,靜態(tài)庫只要支持了armv7,就可以跑在armv7s的架構(gòu)上
5s-->6plus : arm64
#常用命令總結(jié)：
//使用lipo -info命令，查看指定庫支持的架構(gòu)，比如UIKit框架
lipo -info
UIKit.framework/UIKit
//想看的更詳細的信息可以使用lipo -detailed_info
lipo -detailed_info
UIKit.framework/UIKit
//還可以使用file命令
file
UIKit.framework/UIKit
//合并MyLib-32.a和MyLib-64.a，可以使用lipo -create命令合并
lipo -create
MyLib-32.a MyLib-64.a -output MyLib.a
#支持64-bit后程序包會變大么？
?會，支持64-bit后，多了一個arm64架構(gòu)，理論上每個架構(gòu)一套指令，但相比原來會大多少還不好說
用過Core Data或者SQLite嗎？讀寫是分線程的嗎？遇到過死鎖沒？如何解決的？
?用過SQLite，使用FMDB框架
?丟給FMDatabaseQueue或者 添加互斥鎖（NSLock/@synchronized(鎖對象)）
請簡單的介紹下APNS發(fā)送系統(tǒng)消息的機制
? APNS優(yōu)勢：杜絕了類似安卓那種為了接受通知不停在后臺喚醒程序保持長連接的行為，由iOS系統(tǒng)和APNS進行長連接替代
? APNS的原理：
○應(yīng)用在通知中心注冊，由iOS系統(tǒng)向APNS請求返回設(shè)備令牌(device Token)
○應(yīng)用程序接收到設(shè)備令牌并發(fā)送給自己的后臺服務(wù)器
○服務(wù)器把要推送的內(nèi)容和設(shè)備發(fā)送給APNS
○ APNS根據(jù)設(shè)備令牌找到設(shè)備，再由iOS根據(jù)APPID把推送內(nèi)容展示
不用中間變量,用兩種方法交換A和B的值
?方法1：
A = A + B
B = A - B
A = A - B
?方法2：異或
A = A^B;
B = A^B;
A = A^B;
#開發(fā)常用的工具有哪些？
Xcode
你一般是怎么用Instruments的？
用于調(diào)試內(nèi)存泄露,循環(huán)引用
#你一般是如何調(diào)試Bug的？
一般情況,邏輯判斷,其次看堆棧,斷點調(diào)試 ,lldb
#如何實現(xiàn)單例，單例會有什么弊端？
單例是一種開發(fā)思想. 實現(xiàn)單利重寫構(gòu)造方法即可 ,對象會一直存在知道程序結(jié)束才銷毀
弊端?單例不可濫用 ,濫用單例會讓內(nèi)存龐大.
1、由于單利模式中沒有抽象層，因此單例類的擴展有很大的困難。
2、單例類的職責過重，在一定程度上違背了“單一職責原則”。
3、濫用單例將帶來一些負面問題，如為了節(jié)省資源將數(shù)據(jù)庫連接池對象設(shè)計為的單例類，可能會導(dǎo)致共享連接池對象的程序過多而出現(xiàn)連接池溢出；如果實例化的對象長時間不被利用，系統(tǒng)會認為是垃圾而被回收，這將導(dǎo)致對象狀態(tài)的丟失。
?節(jié)省內(nèi)存資源，一個應(yīng)用就一個對象
節(jié)省內(nèi)存資源?犧牲時間換空間 ?
APP上架后如何搜集錯誤信息？
用qq旗下的bugly當然友盟也有 只需要在app注冊即可
簡答描述下你所理解的敏捷開發(fā)
敏捷開發(fā)?
六大設(shè)計原則:
代理:解耦和, 開放封閉原則
觀察者模式:接口隔離原則，開放-封閉原則
MVC 對擴展開放-對修改封閉
單例 單一職責原則
策略模式 :敏捷原則：接口隔離原則；多用組合，少用繼承；針對接口編程，而非實現(xiàn)。
（六）工廠模式 易于替換，面向抽象編程，application只與抽象工廠和易變類的共性抽象類發(fā)生調(diào)用關(guān)系。 倒轉(zhuǎn)依賴原則?
