iOS 如何優化項目

時間  2019-11-16
標籤 ios 如何 優化 項目 欄目 iOS 简体版
原文   原文鏈接

前言

在項目業務趨於穩定的時候，開發完迭代需求後，咱們可能會無所適從，進入一段空白期，可是對於攻城獅來講閒暇不是件好事，因此咱們可能總想學點什麼，卻又沒有頭緒。這個時候咱們就能夠考慮完善和優化咱們的項目了。從中能夠運用到一些底層RunLoop或者Runtime的知識，熟能生巧老是沒錯的😬html

1. 結構與架構

1.1 結構

這裏說的結構大概有兩點：1.文件目錄分類 2.第三方庫管理ios

1.1.1 文件目錄分類

爲了方便管理，最好將Xcode中的項目展現目錄與實際的存儲目錄保持一致
此外，通常按業務模塊分類,一級目錄能夠按照MVC格式，也能夠按照業務模塊劃分
用最廣泛的Model View Controller架構舉例laravel

    1. 以一個基礎的電商項目來解釋，4個tabbarItem對應着四大模塊，首頁、分類、購物車、我的中心，往下每一個還能夠細分爲MVC+Session層
    1. 按項目架構來分

      最外層爲Model、View、Controller、Session層,內部纔是業務模塊
      這一塊無需多言，二者配合使用便可

1.1.2 第三方庫

我的建議：時間容許的話本身多造造輪子，風險可控，好維護git

如非必要，儘可能不要直接使用已經編譯好的三方庫(framework/.a)，最好本身去編譯三方庫(安全要求)程序員

管理方面有三種方式：github

  1. 手動管理
    手動維護各類第三方庫，適合於已經趨於穩定、極少Bug的三方庫
  2. CocoaPods
  3. Carthage

這裏更推薦使用Carthage,由於它對項目的侵入性最小，並且是去中心化管理，不須要等待漫長的pod update / install過程.不過各有各的好處,使用CocoaPods簡單粗暴,基本不須要額外設置什麼,看本身需求吧編程

1.2 項目架構

項目邏輯基本都圍繞了一條主線時，咱們採用MVC已經能夠很好的知足咱們的需求，可是當業務邏輯日漸複雜的時候，咱們單純的採用Model View Controller這種編程模式已經不能很好的將業務邏輯與代碼分離開，也就是解耦Decouple.
爲了更好的將ViewController解耦，產生了Model View ViewModel這種編程模式，ViewModel層其實作了一層Model與ViewController中間的橋接，有利有弊，該模式會產生不少膠水代碼，可是配合響應式編程框架(如 ReactiveCocoa或者RxSwift),能夠作到最大程度的解耦。，適合與本身實際項目業務複雜程度的模式纔是好的編程模式。後端

引伸 : <關於組件化編程>
若是項目業務很複雜、不少業務組件都通用，能夠採用組件化編程，經常使用的一種就是採用CocoaPods將項目業務模塊分拆成各類pod庫，使用什麼模塊直接集成就好,再配合MVVM和響應式編程框架(如 ReactiveCocoa或者RxSwift),能夠作到最大程度的解耦。數組

2. 崩潰&性能調優

當項目已經完成業務模塊上線後，咱們就能夠開始考慮關於如何提升App的用戶體驗，舉例一下幾個問題：緩存

1. 代碼規範，按期code review了嗎
2. 複雜列表的滾動時FPS能夠保持在60幀左右嗎？
3. 頁面加載渲染的耗時能不能進一步減少？
4. 網絡緩存有作嗎，UIWebView / WKWebView的經常使用靜態資源作緩存了嗎
5. App的啓動時間能夠在保持最小業務邏輯的同時再減少一點嗎？
複製代碼

2.1 UITest & UnitTest

當開發完新需求的時候，在提測以前咱們最好編寫下UITest和UnitTest,覆蓋主業務流程便可，能夠提升咱們的提測質量，減少一些可見的Bug，再加上冒煙用例,最大程度上提升咱們提測的質量(成爲KPI之王 - 😏)，並且上線以後這些單元測試和UITest組件的腳本能夠配合自動化測試按期進行迴歸測試，提升App的質量，減小崩潰率

2.2 NullSafe

絕大多數狀況下，咱們向NSNull對象發送消息，都會產生崩潰，NSNull對象常見於後臺返回數據中可能會有null字段，不少JSON庫都會轉成NSNull對象，以下狀況就會產生崩潰：

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

可是向nil對象發送消息則不會產生崩潰，這些能夠參考NullSafe中的處理方法，重寫
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector和- (void)forwardInvocation:(NSInvocation *)anInvocation這兩個方法將沒能力處理消息的方法簽名轉發給nil對象則不會產生崩潰
此外，常見的崩潰好比，NSArray取值越界，NSDictionary傳了nil對象，這些問題產生的崩潰可使用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
複製代碼

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

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

2.2 監控系統

目前大多數App都集成了第三方統計庫，常見的好比騰訊的Bugly、友盟的U-App等等，在這介紹下如何自建性能監控庫

可使用PLCrashReporter或者KSCrash庫解析崩潰日誌並符號化，再上傳至後臺，本身作收集加統計，順帶提一下，咱們使用了PLCrashReporter，後端使用了Laravel，很方便的開發了一套簡單的崩潰及各類性能參數收集的系統,因此若是要自建，能夠考慮這個組合

  • CPU、內存、FPS記錄及保存

    CPU、FPS、Memory佔用網上都有現成的方法獲取到這三個參數,這三個屬於性能監控，能夠定時記錄，好比10S記錄一次到本地文件中，每次打開App上傳昨天的日誌。這就要本身制定日誌上傳的策略了

  • 卡頓日誌收集

    用戶能感覺到的卡頓通常都是由於在主線程作了耗時操做，舉幾個會發生卡頓的例子：

    1. viewDidLoad中 for循環中初始化10000個UILabel實例
    2. cellForRow代理方法中手動休眠usleep(100*1000)

    如何監聽這些事件呢？查看下源代碼,核心方法CFRunLoopRun簡化後的邏輯以下：

int32_t __CFRunLoopRun()
{
    //通知即將進入runloop
    __CFRunLoopDoObservers(KCFRunLoopEntry);
     
    do
    {
        // 通知將要處理timer和source
        __CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
        __CFRunLoopDoObservers(kCFRunLoopBeforeSources);
         
        __CFRunLoopDoBlocks();  //處理非延遲的主線程調用
        __CFRunLoopDoSource0(); //處理UIEvent事件
         
        //GCD dispatch main queue
        CheckIfExistMessagesInMainDispatchQueue();
         
        // 即將進入休眠
        __CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);
         
        // 等待內核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();
         
        // 再次確保是否有同步的方法須要調用
        __CFRunLoopDoBlocks();
         
    } while (!stop && !timeout);
     
    //通知即將退出runloop
    __CFRunLoopDoObservers(CFRunLoopExit);
}

複製代碼

咱們能夠看到在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting等待時間過長便可斷定爲卡頓，具體怎麼算做卡頓，咱們都知道FPS爲一秒60幀左右最好，FPS即爲Frames Per Second，嚴格意義上一秒60幀算流暢，也就是一幀須要1s/60 = 16.6ms，考慮會有其餘的一些事件影響，能夠用連續幾回50ms或者單次耗時過長斷定爲卡頓。斷定爲卡頓以後，咱們可使用PLCrashReporter或者KSCrash生成日誌記錄，能夠存儲到本地
咱們可使用CFRunLoopObserverRef來實時獲取NSRunLoop狀態值的變化,一下爲一個樣例：

@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狀態觀察
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    observer = CFRunLoopObserverCreate(kCFAllocatorDefault,
                                       kCFRunLoopAllActivities,
                                       YES,
                                       0,
                                       &runLoopObserverCallBack,
                                       &context);
    CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
    
    // 在子線程監控時長
    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註冊本身的異常處理回調，發生崩潰時讓程序顯示的從容一點，不會直接閃退，能夠彈出本身的崩潰異常界面，能夠參考Bilibili的界面，好比說前方遇到高能反應之類，程序須要重啓之類的，不會讓用戶感受到很突兀得閃退了，也能夠在收到崩潰日誌後手動維護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. 獲取調用棧
    // 2. 處理異常
    
    // 3. App保活
    BOOL isContiune = TRUE; // 是否要保活
    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);
}
複製代碼

延伸：

監控系統不光侷限於性能、崩潰率，也能夠將統計策略延伸到網絡請求連通率或者一些業務層面，更好的把控App的質量

2.3 性能調優&App體驗優化

前面咱們介紹瞭如何有效地減小崩潰及優雅地處理崩潰，下面來看看解決性能問題須要注意幾點。

2.3.1 懶加載的利與弊

懶加載適用於一些可能不會加載的頁面，好比彈框、空數據頁面之類的，使用得當能夠避免內存暴漲，使用很差，好比在一定會彈出的頁面中使用懶加載可能會在增長頁面響應時間，因此使用懶加載必定要注意使用場景，避免產生反作用

2.3.2 避免使用重繪

重寫 drawRect 或者 drawReact:inContext方法會默認建立一個圖層上下文，圖形上下文所須要的內存爲圖層寬 * 圖層高 * 4字節，圖層每次進行重繪時都須要抹掉內存從新分配，會產生巨大的性能開銷
UIView類其實是對CALayer的封裝，關於UI層面的性能優化有不少東西，能夠看看iOS CoreAnimation 核心動畫高級編程中關於圖層性能的一章

2.3.3 App體驗優化

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

  • UITableViewCell 使用不當形成滑動卡頓
  • 大量cornerRadius和maskToBounds一塊兒使用形成的離屏渲染形成的性能問題
  • 網絡請求操做沒有任何狀態展現，好比加載框、按鈕置灰等
  • 網絡請求沒有進行緩存

這些問題只是App的細節，可是從細節入手才能更顯的專業~
咱們重點談談網絡請求優化：

2.3.3.1 手動維護DNS解析

用www.manoboo.com來舉例,經過域名訪問首先會尋找DNS解析服務器，而後纔會映射到本身的服務器IP上。咱們直接使用IP請求接口訪問網絡資源，能夠避免不少問題，可是有利有弊，須要本身維護DNS映射，在直接好比：

  1. 運營商DNS流量劫持，具體表如今你的H5網頁莫名其妙的被加了廣告(關於這個問題，也能夠作域名白名單，非本域名資源禁止請求，或者H5方面作處理)，也有
  2. DNS服務商(如萬網)解析出現故障形成的大批量用戶沒法正常使用App，按天計算。。
  3. DNS解析延遲太高形成的加載超時致使用戶體驗差

此時咱們能夠考慮本身手動作DNS解析,簡單點能夠在網絡請求時將URL中的域名替換掉，或者在Objective-C中實現NSURLProtocol(Swift中爲URLProtocol)的子類對應的方法，作全局替換URL
不過也有些弊端：

  1. 須要手動維護DNS解析表，解析出錯後須要一套容錯方案，保證接口的暢通
  2. HTTP請求能夠經過設置header中的host字段進行網絡請求，HTTPS請求還需額外配置，受限於篇幅緣由，詳細的弊端和解決方法能夠閱讀下這篇文章HTTPDNS在iOS中的實踐
2.3.3.2 網絡請求緩存優化

適用場景：一些更新頻率較低的場景：好比我的中心
關於網絡請求緩存，App端的網絡請求對面到後端更多的是增刪改查，這個方面須要和後端配合，是否資源改變即後端是否須要從新檢索或修改數據，這個時候咱們就須要一個value好比時間戳Last-Modified或者標識ETag來告知服務器本身當前的資源標記，目前經常使用的策略爲：
以時間戳Last-Modified爲例

  1. App端第一次請求接口，服務端返回成功，HTTP Status爲200，而且在返回的Header中用Last-Modified代表服務器中該資源最後被修改的時間
  2. App端第二次請求該接口，Header中傳遞本地緩存的Header中的Last-Modified,若是服務器端的資源並未發生變化，則會返回HTTP Status爲304，咱們直接可使用本地的緩存，傳輸流量更少，相對而言，用戶的等待時間會更短

注：
量化而非猜想，這是咱們開發過程當中的一個原則，當遇到性能問題時，咱們可使用instruments來測量實際運行過程當中的各個參數，找到問題所在（建議真機調試而不是模擬器，真機才能更高的還原性能問題）

instruments工具常見功能

點擊右上方加號還有更多工具+

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

結語

受限於篇幅緣由，有些點也是一律而過，iOS中如何優化一個項目，這是一門很深的學問，知識點範圍很廣，我也只是涉及到了一部分，學無止境嘛，完成工做的同時咱們也能夠作一個酷酷的程序員，學學Haskell去體驗下函數式編程思惟的樂趣，或者搞搞LLDB更好得作個Debugger
最後，很是感謝您閱讀這篇文章，若是個人文章產生了幫助，能夠給一個小小的紅心☺️，歡迎去個人小站www.manoboo.com拍磚啦，我會努力創做更好的文章

文中引用到的文章以下：

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

最後

給你們推薦一個優秀的iOS交流平臺，平臺裏的夥伴們都是很是優秀的iOS開發人員，咱們專一於技術的分享與技巧的交流，你們能夠在平臺上討論技術，交流學習。歡迎你們的加入（想要進入的可加小編微信1367798518）


做者：ManoBoo
連接
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程