<h1>1歪架、你在實際開發(fā)中矫夷，有哪些手機架構(gòu)與性能調(diào)試經(jīng)驗</h1>

1 > 剛接手公司的舊項目時葛闷，模塊特別多，而且?guī)缀跛械拇a都寫在控制器里面双藕，比如UI控件代碼淑趾、網(wǎng)絡請求代碼、數(shù)據(jù)存儲代碼
2> 接下來采取MVC模式進行封裝忧陪、重構(gòu):
a> 自定義UI控件封裝內(nèi)部的業(yè)務邏輯
b> 封裝網(wǎng)絡請求工具類(降低耦合)
c> 封裝數(shù)據(jù)存儲工具類

<h1>2扣泊、BAD_ACCESS在什么情況下出現(xiàn)？</h1>

這種問題是經(jīng)常遇到的嘶摊，在開發(fā)時經(jīng)常會出現(xiàn)BAD_ACCESS延蟹。
原因是訪問了野指針，比如訪問已經(jīng)釋放對象的成員變量或者發(fā)消息叶堆、死循環(huán)等阱飘。

<h1>3、如何調(diào)試BAD_ACCESS錯誤蹂空？</h1>

出現(xiàn)BAD_ACCESS錯誤俯萌，通常是訪問了野指針，比如訪問了已經(jīng)釋放了的對象上枕「牢酰快速定位問題的步驟有：
1.    重寫對象的respondsToSelector方法，先找到出現(xiàn)EXECBADACCESS前訪問的最后一個object
2.    設(shè)置Enable Zombie Objects
3.    設(shè)置全局斷點快速定位問題代碼所在行辨萍，接收所有的異常
4.    Xcode7已經(jīng)集成了BAD_ACCESS捕獲功能：Address Sanitizer棋恼，與步驟2一樣設(shè)置
5.    analyze也行（不一定管用）

<h1>4返弹、什么時候會報 unrecognized selector 異常？</h1>

當調(diào)用對象（子類爪飘，各級父類）中不含有對應方法的時候义起，并且依舊沒有給出“消息轉(zhuǎn)發(fā)”的具體方案的時候，程序在運行時會crash并拋出 unrecognized selector 異常

objective-c 中的每個方法在運行時會被轉(zhuǎn)為消息發(fā)送objc_msgSend(reciver, selector)

例如 [person say]就會被轉(zhuǎn)化為 objc_msgSend(person, @selector(say))

運行時會根據(jù)對象(reciever) 的isa 指針找到該對象所對應的類师崎，然后會依次在對應的類默终，父類，爺爺類犁罩，根類中找對應的方法

下面只講述對象方法的解析過程：

第一步：+ (BOOL)resolveInstanceMethod:(SEL)sel實現(xiàn)方法齐蔽，指定是否動態(tài)添加方法。若返回NO床估，則進入下一步含滴，若返回YES，則通過class_addMethod函數(shù)動態(tài)地添加方法，消息得到處理，此流程完畢捂刺。
第二步：在第一步返回的是NO時，就會進入- (id)forwardingTargetForSelector:(SEL)aSelector方法碑韵，這是運行時給我們的第二次機會，用于指定哪個對象響應這個selector缎脾。不能指定為self泼诱。若返回nil，表示沒有響應者赊锚，則會進入第三步。若返回某個對象屉栓，則會調(diào)用該對象的方法舷蒲。
第三步：若第二步返回的是nil，則我們首先要通過- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector指定方法簽名友多，若返回nil牲平，則表示不處理。若返回方法簽名域滥，則會進入下一步纵柿。
第四步：當?shù)谌椒祷胤椒ǚ椒ê灻螅蜁{(diào)用- (void)forwardInvocation:(NSInvocation *)anInvocation方法启绰，我們可以通過anInvocation對象做很多處理昂儒，比如修改實現(xiàn)方法，修改響應對象等
第五步：若沒有實現(xiàn)- (void)forwardInvocation:(NSInvocation *)anInvocation方法委可，那么會進入- (void)doesNotRecognizeSelector:(SEL)aSelector方法渊跋。若我們沒有實現(xiàn)這個方法，那么就會crash，然后提示打不到響應的方法拾酝。到此燕少，動態(tài)解析的流程就結(jié)束了。

<h1>5蒿囤、有哪些常見的 Crash 場景客们？</h1>

訪問了僵尸對象
訪問了不存在的方法
數(shù)組越界
在定時器下一次回調(diào)前將定時器釋放,會Crash

<h1>6、lldb（gdb）常用的調(diào)試命令材诽？</h1>

?    p 輸出基本類型//p (int)[[[self view] subviews] count]
?    po 用于輸出 Objective-C 對象//po [self view]
?    expr 可以在調(diào)試時動態(tài)執(zhí)行指定表達式底挫，并將結(jié)果打印出來。常用于在調(diào)試過程中修改變量的值岳守。//源代碼中 a = 1 凄敢；expr a=2 輸出結(jié)果：(int) $0 = 2

<h1>7、如果一個函數(shù)10次中有7次正確湿痢，3次錯誤涝缝，問題可能出現(xiàn)在哪里？</h1>

這樣的問題通過應聘者的分析譬重，可以知道應聘者的功底如何拒逮。很多人的回答會是很簡單的，沒有從多方面去分析臀规。這樣的問題也是很有意義的滩援，在項目開發(fā)中所產(chǎn)生的bug，有的時候會出現(xiàn)這樣的情況塔嬉，而代碼量比較大且業(yè)務比較復雜時玩徊，通過其他工具并不能分析出來是什么bug，但是我們卻可以根據(jù)出現(xiàn)的頻率推測谨究。筆者把這個問題當作測試部反饋過來的bug描述問題來分析一下恩袱。
參考答案：
從問題描述可知，bug不會必現(xiàn)的胶哲，因此無法直接定位出錯之處畔塔。從以下角度出現(xiàn)來分析可能出錯之處：
1.    因出錯并不是崩潰，因此沒有錯誤日志可看鸯屿。第一步就是分析函數(shù)中的所有分支澈吨，是否在語法上存在可能缺少條件的問題。所以寄摆，檢查所有的分支谅辣，確保每個分支執(zhí)行的結(jié)果的正確的
2.    檢測函數(shù)的參數(shù)，保證必傳參數(shù)不能為空婶恼，若為空應該拋出異常屈藐。因此榔组，用斷言檢測參數(shù)的正確性是很重要的。
3.    檢測函數(shù)中每個分支所調(diào)用的函數(shù)返回結(jié)果是正確的联逻，其實就是一個遞歸的過程（步驟1搓扯、2）

<h1>8、你一般是如何調(diào)試Bug的包归？</h1>

個問題看起來很籠統(tǒng)锨推，但又一針見血。通過應聘者的回答公壤，可很直觀地看出這個應聘者的處理bug的能力换可，以及其解決問題的思維。
參考答案：
Bug分為測試中的Bug和線上的Bug：
?    線上Bug：項目使用了友盟統(tǒng)計厦幅，因此會有崩潰日志沾鳄，通過解析dYSM可以直接定位到大部分bug崩潰之處。解決線上bug需要從主干拉一個新的分支确憨，解決bug并測試通過后译荞，再合并到主干，然后上線休弃。若是多團隊開發(fā)吞歼，可以將fix bug分支與其他團隊最近要上線的分支集成，然后集成測試再上線塔猾。
?    測試Bug：根據(jù)測試所反饋的bug描述篙骡，若語義不清晰，則直接找到提bug人丈甸，操作給開發(fā)人員看糯俗，最好是可以bug復現(xiàn)。解決bug時睦擂，若能根據(jù)描述直接定位bug出錯之處叶骨，則好處理；若無法直觀定位祈匙，則根據(jù)bug類型分幾種處理方式，比如崩潰的bug可以通過instruments來檢測天揖、數(shù)據(jù)顯示錯誤的bug夺欲，則需要閱讀代碼一步步查看邏輯哪里寫錯。
對于開發(fā)中出現(xiàn)的崩潰或者數(shù)據(jù)顯示不正常今膊，那就需要根據(jù)經(jīng)驗或者相關(guān)工具來檢測可能出錯之處些阅。當然，團隊內(nèi)溝通解決是最好的斑唬。

<h1>9市埋、你一般是怎么用 Instruments 的黎泣？</h1>

這個問題也就是考察下你經(jīng)驗如何了, Instruments里面工具很多,也沒必要逐一說明,挑幾個常用的說下就好
參考答案:

Time Profiler:性能分析
Zombies:檢查是否訪問了僵尸對象,但是這個工具只能從上往下檢查,不智能
Allocations:用來檢查內(nèi)存,寫算法的那批人也用這個來檢查
Leaks:檢查內(nèi)存,看是否有內(nèi)存泄露

<h1>10、你一般是如何調(diào)試 Bug 的缤谎？</h1>

查看異常報告
配置相關(guān)環(huán)境抒倚，重現(xiàn)bug
代碼檢查
用測試案例來捕獲bug
可以請同事一同來審查問題，有些時候當局者迷坷澡，旁觀者清托呕。

<h1>11、如何對iOS設(shè)備進行性能測試?</h1>

Profile-> Instruments ->Time Profiler 進行性能測試频敛！

測試iOS版的 App 注意事項分享以下幾點：

1.app使用過程中项郊，接聽電話≌遄可以測試不同的通話時間的長短着降，對于通話結(jié)束后，原先打開的app的響應拗军，比如是否停留在原先界面任洞，繼續(xù)操作時的相應速度等。

2.app使用過程中食绿，有推送消息時侈咕，對app的使用影響

3.設(shè)備在充電時，app的響應以及操作流暢度

4.設(shè)備在不同電量時(低于10%器紧，50%耀销，95%)，app的響應以及操作流暢度

5.意外斷電時铲汪，app數(shù)據(jù)丟失情況

6.網(wǎng)絡環(huán)境變化時熊尉，app的應對情況如何：是否有適當提示?從有網(wǎng)絡環(huán)境到無網(wǎng)絡環(huán)境時，app的反饋如何?從無網(wǎng)絡環(huán)境回到有網(wǎng)絡環(huán)境時掌腰，是否能自動加載數(shù)據(jù)狰住，多久才能開始加載數(shù)據(jù)

7.多點觸摸的情況

8.跟其他app之間互相切換時的響應

9.進程關(guān)閉再重新打開的反饋

10.IOS系統(tǒng)語言環(huán)境變化時