1. 結(jié)構(gòu)與架構(gòu)

1.1 結(jié)構(gòu)

這里說的結(jié)構(gòu)大概有兩點：1.文件目錄分類 2.第三方庫管理

1.1.1 文件目錄分類

為了方便管理，***將Xcode中的項目展示目錄與實際的存儲目錄保持一致

此外，一般按業(yè)務(wù)模塊分類,一級目錄可以按照MVC格式，也可以按照業(yè)務(wù)模塊劃分

用最普遍的Model View Controller架構(gòu)舉例

• 以一個基礎(chǔ)的電商項目來解釋，4個tabbarItem對應(yīng)著四大模塊，首頁、分類、購物車、個人中心，往下每個還可以細(xì)分為MVC+Session層

• 按項目架構(gòu)來分

  最外層為Model、View、Controller、Session層,內(nèi)部才是業(yè)務(wù)模塊

  這一塊無需多言，兩者配合使用即可

1.1.2 第三方庫

個人建議：時間允許的話自己多造造輪子，風(fēng)險可控，好維護

如非必要，盡量不要直接使用已經(jīng)編譯好的三方庫(framework/.a)，***自己去編譯三方庫(安全要求)

管理方面有三種方式：

• 手動管理

  手動維護各種第三方庫，適合于已經(jīng)趨于穩(wěn)定、極少Bug的三方庫

• CocoaPods

• Carthage

這里更推薦使用Carthage,因為它對項目的侵入性最小，而且是去中心化管理，不需要等待漫長的pod update / install過程.不過各有各的好處,使用CocoaPods簡單粗暴,基本不需要額外設(shè)置什么,看自己需求吧

1.2 項目架構(gòu)

項目邏輯基本都圍繞了一條主線時，我們采用MVC已經(jīng)可以很好的滿足我們的需求，但是當(dāng)業(yè)務(wù)邏輯日漸復(fù)雜的時候，我們單純的采用Model View Controller這種編程模式已經(jīng)不能很好的將業(yè)務(wù)邏輯與代碼分離開，也就是解耦Decouple.

為了更好的將ViewController解耦，產(chǎn)生了Model View ViewModel這種編程模式，ViewModel層其實做了一層Model與ViewController中間的橋接，有利有弊，該模式會產(chǎn)生很多膠水代碼，但是配合響應(yīng)式編程框架(如 ReactiveCocoa或者RxSwift),可以做到***程度的解耦。，適合與自己實際項目業(yè)務(wù)復(fù)雜程度的模式才是好的編程模式。

引申 : <關(guān)于組件化編程>

如果項目業(yè)務(wù)很復(fù)雜、很多業(yè)務(wù)組件都通用，可以采用組件化編程，常用的一種就是采用CocoaPods將項目業(yè)務(wù)模塊分拆成各種pod庫，使用什么模塊直接集成就好,再配合MVVM和響應(yīng)式編程框架(如 ReactiveCocoa或者RxSwift),可以做到***程度的解耦。

2. 崩潰&性能調(diào)優(yōu)

當(dāng)項目已經(jīng)完成業(yè)務(wù)模塊上線后，我們就可以開始考慮關(guān)于如何提高App的用戶體驗，舉例一下幾個問題：

1. 代碼規(guī)范，定期code review了嗎

2. 復(fù)雜列表的滾動時FPS可以保持在60幀左右嗎？

3. 頁面加載渲染的耗時能不能進一步減??？

4. 網(wǎng)絡(luò)緩存有做嗎，UIWebView / WKWebView的常用靜態(tài)資源做緩存了嗎

5. App的啟動時間可以在保持最小業(yè)務(wù)邏輯的同時再減小一點嗎？

2.1 UITest & UnitTest

當(dāng)開發(fā)完新需求的時候，在提測之前我們***編寫下UITest和UnitTest,覆蓋主業(yè)務(wù)流程即可，可以提高我們的提測質(zhì)量，減小一些可見的Bug，再加上冒煙用例,***程度上提高我們提測的質(zhì)量(成為KPI之王 - ????)，而且上線之后這些單元測試和UITest組件的腳本可以配合自動化測試定期進行回歸測試，提高App的質(zhì)量，減少崩潰率

2.2 NullSafe

絕大多數(shù)情況下，我們向NSNull對象發(fā)送消息，都會產(chǎn)生崩潰，NSNull對象常見于后臺返回數(shù)據(jù)中可能會有null字段，很多JSON庫都會轉(zhuǎn)成NSNull對象，如下情況就會產(chǎn)生崩潰：

id obj = [NSNull null]; 
NSLog(@"%@", [obj stringValue]); 

但是向nil對象發(fā)送消息則不會產(chǎn)生崩潰，這些可以參考NullSafe中的處理方法，重寫

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector和- (void)forwardInvocation:(NSInvocation *)anInvocation這兩個方法將沒能力處理消息的方法簽名轉(zhuǎn)發(fā)給nil對象則不會產(chǎn)生崩潰

此外，常見的崩潰比如，NSArray取值越界，NSDictionary傳了nil對象，這些問題產(chǎn)生的崩潰可以使用Runtime中的Method Swizzle,將原生的方法hook掉，如下：

@implementation NSMutableDictionary (NullSafe) 
  
- (void)swizzleMethod:(SEL)origSelector withMethod:(SEL)newSelector 
{ 
    Class class = [self class]; 
  
    Method originalMethod = class_getInstanceMethod(class, origSelector); 
    Method swizzledMethod = class_getInstanceMethod(class, newSelector); 
  
    BOOL didAddMethod = class_addMethod(class, 
                                        origSelector, 
                                        method_getImplementation(swizzledMethod), 
                                        method_getTypeEncoding(swizzledMethod)); 
    if (didAddMethod) { 
        class_replaceMethod(class, 
                            newSelector, 
                            method_getImplementation(originalMethod), 
                            method_getTypeEncoding(originalMethod)); 
    } else { 
        method_exchangeImplementations(originalMethod, swizzledMethod); 
    } 
} 
  
+ (void)load { 
    static dispatch_once_t onceToken; 
    dispatch_once(&onceToken, ^{ 
        id obj = [[self alloc] init]; 
        [obj swizzleMethod:@selector(setObject:forKey:) withMethod:@selector(safe_setObject:forKey:)]; 
  
    }); 
  
} 
  
- (void)safe_setObject:(id)value forKey:(NSString *)key { 
    if (value) { 
        [self safe_setObject:value forKey:key]; 
    }else { 
        NullSafeLogFormatter(@"[NSMutableDictionary setObject: forKey:], Object cannot be nil") 
    } 
} 
  
@end 

這種解決方法可以避免諸如數(shù)組取值越界、字典傳空值、removeObjectAtIndex等錯誤，如下的崩潰就可以避免：

id obj = nil; 
NSMutableDictionary *m_dict = [NSMutableDictionary dictionary]; 
[dict setObject:obj forKey:@"666"]; 

2.2 監(jiān)控系統(tǒng)

目前大多數(shù)App都集成了第三方統(tǒng)計庫，常見的比如騰訊的Bugly、友盟的U-App等等，在這介紹下如何自建性能監(jiān)控庫

可以使用PLCrashReporter或者KSCrash庫解析崩潰日志并符號化，再上傳至后臺，自己做收集加統(tǒng)計，順帶提一下，我們使用了PLCrashReporter，后端使用了Laravel，很方便的開發(fā)了一套簡單的崩潰及各種性能參數(shù)收集的系統(tǒng),所以如果要自建，可以考慮這個組合

• CPU、內(nèi)存、FPS記錄及保存

• 卡頓日志收集

  用戶能感受到的卡頓一般都是因為在主線程做了耗時操作，舉幾個會發(fā)生卡頓的例子：

1. viewDidLoad中 for循環(huán)中初始化10000個UILabel實例

2. cellForRow代理方法中手動休眠usleep(100*1000)

如何監(jiān)聽這些事件呢？查看下源代碼,核心方法CFRunLoopRun簡化后的邏輯如下：

    int32_t __CFRunLoopRun() 
{ 
    //通知即將進入runloop 
    __CFRunLoopDoObservers(KCFRunLoopEntry); 
  
    do 
    { 
        // 通知將要處理timer和source 
        __CFRunLoopDoObservers(kCFRunLoopBeforeTimers); 
        __CFRunLoopDoObservers(kCFRunLoopBeforeSources); 
  
        __CFRunLoopDoBlocks();  //處理非延遲的主線程調(diào)用 
        __CFRunLoopDoSource0(); //處理UIEvent事件 
  
        //GCD dispatch main queue 
        CheckIfExistMessagesInMainDispatchQueue(); 
  
        // 即將進入休眠 
        __CFRunLoopDoObservers(kCFRunLoopBeforeWaiting); 
  
        // 等待內(nèi)核mach_msg事件 
        mach_port_t wakeUpPort = SleepAndWaitForWakingUpPorts(); 
  
        // Zzz... 
  
        // 從等待中醒來 
        __CFRunLoopDoObservers(kCFRunLoopAfterWaiting); 
  
        // 處理因timer的喚醒 
        if (wakeUpPort == timerPort) 
            __CFRunLoopDoTimers(); 
  
        // 處理異步方法喚醒,如dispatch_async 
        else if (wakeUpPort == mainDispatchQueuePort) 
            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 
  
        // UI刷新,動畫顯示 
        else 
            __CFRunLoopDoSource1(); 
  
        // 再次確保是否有同步的方法需要調(diào)用 
        __CFRunLoopDoBlocks(); 
  
    } while (!stop && !timeout); 
  
    //通知即將退出runloop 
    __CFRunLoopDoObservers(CFRunLoopExit); 
} 

我們可以看到在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting等待時間過長即可判定為卡頓，具體怎么算作卡頓，我們都知道FPS為一秒60幀左右***，F(xiàn)PS即為Frames Per Second，嚴(yán)格意義上一秒60幀算流暢，也就是一幀需要1s/60 = 16.6ms，考慮會有其他的一些事件影響，可以用連續(xù)幾次50ms或者單次耗時過長判定為卡頓。判定為卡頓之后，我們可以使用PLCrashReporter或者KSCrash生成日志記錄，可以存儲到本地

我們可以使用CFRunLoopObserverRef來實時獲取NSRunLoop狀態(tài)值的變化,一下為一個樣例：

@interface LagCollectionTool () 
{ 
    int timeoutCount; 
    CFRunLoopObserverRef observer; 
    BOOL observeLag; 
@public 
    dispatch_semaphore_t semaphore; 
    CFRunLoopActivity activity; 
} 
  
@end 
  
  
@implementation LagCollectionTool 
  
+ (instancetype)shareInstance { 
    static dispatch_once_t onceToken; 
    static LagCollectionTool *tool = nil; 
    dispatch_once(&onceToken, ^{ 
        tool = [[LagCollectionTool alloc] init]; 
    }); 
    return tool; 
} 
  
- (void)lanuch { 
    if (observer) 
        return; 
  
    // 信號 
    semaphore = dispatch_semaphore_create(0); 
  
    // 注冊RunLoop狀態(tài)觀察 
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL}; 
    observer = CFRunLoopObserverCreate(kCFAllocatorDefault, 
                                       kCFRunLoopAllActivities, 
                                       YES, 
                                       0, 
                                       &runLoopObserverCallBack, 
                                       &context); 
    CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes); 
  
    // 在子線程監(jiān)控時長 
    dispatch_async(dispatch_get_global_queue(0, 0), ^{ 
        while (YES) 
        { 
            long st = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC)); 
            if (st != 0) 
            { 
                if (!observer) 
                { 
                    timeoutCount = 0; 
                    semaphore = 0; 
                    activity = 0; 
                    return; 
                } 
  
                if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting) 
                { 
                    timeoutCount++; 
                    //                    NSLog(@"%d", timeoutCount); 
                    if (timeoutCount < 5) 
                        continue; 
                    NSLog(@"----------------卡爆了！----------------"); 
  
                    PLCrashReporterConfig *config = [[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeBSD 
                                                                                       symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll]; 
                    PLCrashReporter *crashReporter = [[PLCrashReporter alloc] initWithConfiguration:config]; 
  
                    NSData *data = [crashReporter generateLiveReport]; 
                    PLCrashReport *reporter = [[PLCrashReport alloc] initWithData:data error:NULL]; 
                    NSString *report = [PLCrashReportTextFormatter stringValueForCrashReport:reporter 
                                                                              withTextFormat:PLCrashReportTextFormatiOS];                                                                                   
                    //上傳卡頓日志文件 
  
                } 
            } 
            timeoutCount = 0; 
        } 
    }); 
  
} 
  
static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) 
{ 
    LagCollectionTool *tool = (__bridge LagCollectionTool *)info; 
    tool->activity = activity; 
  
    dispatch_semaphore_t semaphore = tool->semaphore; 
    dispatch_semaphore_signal(semaphore); 
} 

通過使用NSSetUncaughtExceptionHandler注冊自己的異常處理回調(diào)，發(fā)生崩潰時讓程序顯示的從容一點，不會直接閃退，可以彈出自己的崩潰異常界面，可以參考Bilibili的界面，比如說前方遇到高能反應(yīng)之類，程序需要重啟之類的，不會讓用戶感覺到很突兀得閃退了，也可以在收到崩潰日志后手動維護Runloop，下面是一個樣例：

// 1. 注冊ExceptionHandler 
  
+ (void)installUncaughtExceptionHandler { 
    NSSetUncaughtExceptionHandler(&HandleException); 
  
    signal(SIGHUP, SignalHandler); 
    signal(SIGINT, SignalHandler); 
    signal(SIGQUIT, SignalHandler); 
  
    signal(SIGABRT, SignalHandler); 
    signal(SIGILL, SignalHandler); 
    signal(SIGSEGV, SignalHandler); 
    signal(SIGFPE, SignalHandler); 
    signal(SIGBUS, SignalHandler); 
    signal(SIGPIPE, SignalHandler); 
} 
  
// 2. 處理崩潰信息 
void SignalHandler(int signal) { 
    // 1. 獲取調(diào)用棧 
    // 2. 處理異常 
  
    // 3. App?；?/span> 
    BOOL isContiune = TRUE; // 是否要?；?/span> 
    CFRunLoopRef runLoop = CFRunLoopGetCurrent(); 
    CFArrayRef allModes = CFRunLoopCopyAllModes(runLoop); 
  
    while (isContiune) { 
        for (NSString *mode in (__bridge NSArray *)allModes) { 
            CFRunLoopRunInMode((CFStringRef)mode, 0.001, true); 
        } 
    } 
    CFRelease(allModes); 
    signal(SIGABRT, SIG_DFL); 
    signal(SIGILL, SIG_DFL); 
    signal(SIGSEGV, SIG_DFL); 
    signal(SIGFPE, SIG_DFL); 
    signal(SIGBUS, SIG_DFL); 
    signal(SIGPIPE, SIG_DFL); 
} 

延伸：

監(jiān)控系統(tǒng)不光局限于性能、崩潰率，也可以將統(tǒng)計策略延伸到網(wǎng)絡(luò)請求連通率或者一些業(yè)務(wù)層面，更好的把控App的質(zhì)量

2.3 性能調(diào)優(yōu)&App體驗優(yōu)化

前面我們介紹了如何有效地減少崩潰及優(yōu)雅地處理崩潰，下面來看看解決性能問題需要注意幾點。

2.3.1 懶加載的利與弊

懶加載適用于一些可能不會加載的頁面，比如彈框、空數(shù)據(jù)頁面之類的，使用得當(dāng)可以避免內(nèi)存暴漲，使用不好，比如在必定會彈出的頁面中使用懶加載可能會在增加頁面響應(yīng)時間，所以使用懶加載一定要注意使用場景，避免產(chǎn)生副作用

2.3.2 避免使用重繪

重寫 drawRect 或者 drawReact:inContext方法會默認(rèn)創(chuàng)建一個圖層上下文，圖形上下文所需要的內(nèi)存為圖層寬 * 圖層高 * 4字節(jié)，圖層每次進行重繪時都需要抹掉內(nèi)存重新分配，會產(chǎn)生巨大的性能開銷

UIView類實際上是對CALayer的封裝，關(guān)于UI層面的性能優(yōu)化有很多東西，可以看看iOS CoreAnimation 核心動畫高級編程中關(guān)于圖層性能的一章

2.3.3 App體驗優(yōu)化

談起App體驗優(yōu)化，其實這是個玄學(xué)，你需要在性能與體驗上找到一個平衡點，常見的糟糕的體驗包括：

• UITableViewCell 使用不當(dāng)造成滑動卡頓

• 大量cornerRadius和maskToBounds一起使用造成的離屏渲染造成的性能問題

• 網(wǎng)絡(luò)請求操作沒有任何狀態(tài)展示，比如加載框、按鈕置灰等

• 網(wǎng)絡(luò)請求沒有進行緩存

這些問題只是App的細(xì)節(jié)，但是從細(xì)節(jié)入手才能更顯的專業(yè)~

我們重點談?wù)劸W(wǎng)絡(luò)請求優(yōu)化：

2.3.3.1 手動維護DNS解析

用www.manoboo.com來舉例,通過域名訪問首先會尋找DNS解析服務(wù)器，然后才會映射到自己的服務(wù)器IP上。我們直接使用IP請求接口訪問網(wǎng)絡(luò)資源，可以避免很多問題，但是有利有弊，需要自己維護DNS映射，在直接比如：

1. 運營商DNS流量劫持，具體表現(xiàn)在你的H5網(wǎng)頁莫名其妙的被加了廣告(關(guān)于這個問題，也可以做域名白名單，非本域名資源禁止請求，或者H5方面做處理)，也有

2. DNS服務(wù)商(如萬網(wǎng))解析出現(xiàn)故障造成的大批量用戶無法正常使用App，按天計算。。

3. DNS解析延遲過高造成的加載超時導(dǎo)致用戶體驗差

此時我們可以考慮自己手動做DNS解析,簡單點可以在網(wǎng)絡(luò)請求時將URL中的域名替換掉，或者在Objective-C中實現(xiàn)NSURLProtocol(Swift中為URLProtocol)的子類對應(yīng)的方法，做全局替換URL

不過也有些弊端：

1. 需要手動維護DNS解析表，解析出錯后需要一套容錯方案，保證接口的暢通

2. HTTP請求可以通過設(shè)置header中的host字段進行網(wǎng)絡(luò)請求，HTTPS請求還需額外配置，受限于篇幅原因，詳細(xì)的弊端和解決方法可以閱讀下這篇文章HTTPDNS在iOS中的實踐

2.3.3.2 網(wǎng)絡(luò)請求緩存優(yōu)化

適用場景：一些更新頻率較低的場景：比如個人中心

關(guān)于網(wǎng)絡(luò)請求緩存，App端的網(wǎng)絡(luò)請求對面到后端更多的是增刪改查，這個方面需要和后端配合，是否資源改變即后端是否需要重新檢索或修改數(shù)據(jù)，這個時候我們就需要一個value比如時間戳Last-Modified或者標(biāo)識ETag來告知服務(wù)器自己當(dāng)前的資源標(biāo)記，目前常用的策略為：

以時間戳Last-Modified為例

1. App端***次請求接口，服務(wù)端返回成功，HTTP Status為200，并且在返回的Header中用Last-Modified表明服務(wù)器中該資源***被修改的時間

2. App端第二次請求該接口，Header中傳遞本地緩存的Header中的Last-Modified,如果服務(wù)器端的資源并未發(fā)生變化，則會返回HTTP Status為304，我們直接可以使用本地的緩存，傳輸流量更少，相對而言，用戶的等待時間會更短

注：

量化而非猜測，這是我們開發(fā)過程中的一個原則，當(dāng)遇到性能問題時，我們可以使用instruments來測量實際運行過程中的各個參數(shù)，找到問題所在（建議真機調(diào)試而不是模擬器，真機才能更高的還原性能問題）

instruments中工具都有各自的用處，比如可以使用Leask查看App運行過程中的內(nèi)存泄露，使用TimeProfiler查看App啟動耗時或者方法耗時,或者偷懶一點可以使用CACurrentMediaTime()兩次的差值計算方法耗時

結(jié)語

受限于篇幅原因，有些點也是一概而過，iOS中如何優(yōu)化一個項目，這是一門很深的學(xué)問，知識點范圍很廣，我也只是涉及到了一部分，學(xué)無止境嘛，完成工作的同時我們也可以做一個酷酷的程序員，學(xué)學(xué)Haskell去體驗下函數(shù)式編程思維的樂趣，或者搞搞LLDB更好得做個Debugger

***，非常感謝您閱讀這篇文章，如果我的文章產(chǎn)生了幫助，可以給一個小小的紅心??，歡迎去我的小站www.manoboo.com拍磚啦，我會努力創(chuàng)作更好的文章

文中引用到的文章如下：

CocoaChina - iOS 實時卡頓監(jiān)控

iOS Core Animation: Advanced Techniques 中文譯本

文中所涉及到的開源庫如下：

PLCrashReporter

KSCrash

MBNullSafe ManoBoo編寫的NullSafe庫，會進一步拓展功能