成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

iOS如何進行優化項目？

作者：ManoBoo
移動開發 開發
在項目業務趨于穩定的時候，開發完迭代需求后，我們可能會無所適從，進入一段空白期，但是對于攻城獅來說閑暇不是件好事，所以我們可能總想學點什么，卻又沒有頭緒。這個時候我們就可以考慮完善和優化我們的項目了。

1. 結構與架構

1.1 結構

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

1.1.1 文件目錄分類

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

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

用最普遍的Model View Controller架構舉例

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

  • 按項目架構來分

    最外層為Model、View、Controller、Session層,內部才是業務模塊

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

1.1.2 第三方庫

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

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

管理方面有三種方式：

  • 手動管理

    手動維護各種第三方庫，適合于已經趨于穩定、極少Bug的三方庫

  • CocoaPods

  • 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對象，如下情況就會產生崩潰：

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

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

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

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

  1. @implementation NSMutableDictionary (NullSafe) 
  2.   
  3. - (void)swizzleMethod:(SEL)origSelector withMethod:(SEL)newSelector 
  4. { 
  5.     Class class = [self class]; 
  6.   
  7.     Method originalMethod = class_getInstanceMethod(class, origSelector); 
  8.     Method swizzledMethod = class_getInstanceMethod(class, newSelector); 
  9.   
  10.     BOOL didAddMethod = class_addMethod(class, 
  11.                                         origSelector, 
  12.                                         method_getImplementation(swizzledMethod), 
  13.                                         method_getTypeEncoding(swizzledMethod)); 
  14.     if (didAddMethod) { 
  15.         class_replaceMethod(class, 
  16.                             newSelector, 
  17.                             method_getImplementation(originalMethod), 
  18.                             method_getTypeEncoding(originalMethod)); 
  19.     } else { 
  20.         method_exchangeImplementations(originalMethod, swizzledMethod); 
  21.     } 
  22. } 
  23.   
  24. + (void)load { 
  25.     static dispatch_once_t onceToken; 
  26.     dispatch_once(&onceToken, ^{ 
  27.         id obj = [[self alloc] init]; 
  28.         [obj swizzleMethod:@selector(setObject:forKey:) withMethod:@selector(safe_setObject:forKey:)]; 
  29.   
  30.     }); 
  31.   
  32. } 
  33.   
  34. - (void)safe_setObject:(id)value forKey:(NSString *)key { 
  35.     if (value) { 
  36.         [self safe_setObject:value forKey:key]; 
  37.     }else { 
  38.         NullSafeLogFormatter(@"[NSMutableDictionary setObject: forKey:], Object cannot be nil") 
  39.     } 
  40. } 
  41.   
  42. @end 

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

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

2.2 監控系統

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

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

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

 
1    `CPU`、`FPS`、`Memory占用`網上都有現成的方法獲取到這三個參數,這三個屬于性能監控，可以定時記錄，比如10S記錄一次到本地文件中，每次打開App上傳昨天的日志。這就要自己制定日志上傳的策略了

  • 卡頓日志收集

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

  1. viewDidLoad中 for循環中初始化10000個UILabel實例

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

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

  1.     int32_t __CFRunLoopRun() 
  2. { 
  3.     //通知即將進入runloop 
  4.     __CFRunLoopDoObservers(KCFRunLoopEntry); 
  5.   
  6.     do 
  7.     { 
  8.         // 通知將要處理timer和source 
  9.         __CFRunLoopDoObservers(kCFRunLoopBeforeTimers); 
  10.         __CFRunLoopDoObservers(kCFRunLoopBeforeSources); 
  11.   
  12.         __CFRunLoopDoBlocks();  //處理非延遲的主線程調用 
  13.         __CFRunLoopDoSource0(); //處理UIEvent事件 
  14.   
  15.         //GCD dispatch main queue 
  16.         CheckIfExistMessagesInMainDispatchQueue(); 
  17.   
  18.         // 即將進入休眠 
  19.         __CFRunLoopDoObservers(kCFRunLoopBeforeWaiting); 
  20.   
  21.         // 等待內核mach_msg事件 
  22.         mach_port_t wakeUpPort = SleepAndWaitForWakingUpPorts(); 
  23.   
  24.         // Zzz... 
  25.   
  26.         // 從等待中醒來 
  27.         __CFRunLoopDoObservers(kCFRunLoopAfterWaiting); 
  28.   
  29.         // 處理因timer的喚醒 
  30.         if (wakeUpPort == timerPort) 
  31.             __CFRunLoopDoTimers(); 
  32.   
  33.         // 處理異步方法喚醒,如dispatch_async 
  34.         else if (wakeUpPort == mainDispatchQueuePort) 
  35.             __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__() 
  36.   
  37.         // UI刷新,動畫顯示 
  38.         else 
  39.             __CFRunLoopDoSource1(); 
  40.   
  41.         // 再次確保是否有同步的方法需要調用 
  42.         __CFRunLoopDoBlocks(); 
  43.   
  44.     } while (!stop && !timeout); 
  45.   
  46.     //通知即將退出runloop 
  47.     __CFRunLoopDoObservers(CFRunLoopExit); 
  48. } 

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

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

  1. @interface LagCollectionTool () 
  2. { 
  3.     int timeoutCount; 
  4.     CFRunLoopObserverRef observer; 
  5.     BOOL observeLag; 
  6. @public 
  7.     dispatch_semaphore_t semaphore; 
  8.     CFRunLoopActivity activity; 
  9. } 
  10.   
  11. @end 
  12.   
  13.   
  14. @implementation LagCollectionTool 
  15.   
  16. + (instancetype)shareInstance { 
  17.     static dispatch_once_t onceToken; 
  18.     static LagCollectionTool *tool = nil; 
  19.     dispatch_once(&onceToken, ^{ 
  20.         tool = [[LagCollectionTool alloc] init]; 
  21.     }); 
  22.     return tool; 
  23. } 
  24.   
  25. - (void)lanuch { 
  26.     if (observer) 
  27.         return; 
  28.   
  29.     // 信號 
  30.     semaphore = dispatch_semaphore_create(0); 
  31.   
  32.     // 注冊RunLoop狀態觀察 
  33.     CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL}; 
  34.     observer = CFRunLoopObserverCreate(kCFAllocatorDefault, 
  35.                                        kCFRunLoopAllActivities, 
  36.                                        YES, 
  37.                                        0, 
  38.                                        &runLoopObserverCallBack, 
  39.                                        &context); 
  40.     CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes); 
  41.   
  42.     // 在子線程監控時長 
  43.     dispatch_async(dispatch_get_global_queue(0, 0), ^{ 
  44.         while (YES) 
  45.         { 
  46.             long st = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC)); 
  47.             if (st != 0) 
  48.             { 
  49.                 if (!observer) 
  50.                 { 
  51.                     timeoutCount = 0; 
  52.                     semaphore = 0; 
  53.                     activity = 0; 
  54.                     return; 
  55.                 } 
  56.   
  57.                 if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting) 
  58.                 { 
  59.                     timeoutCount++; 
  60.                     //                    NSLog(@"%d", timeoutCount); 
  61.                     if (timeoutCount < 5) 
  62.                         continue; 
  63.                     NSLog(@"----------------卡爆了！----------------"); 
  64.   
  65.                     PLCrashReporterConfig *config = [[PLCrashReporterConfig alloc] initWithSignalHandlerType:PLCrashReporterSignalHandlerTypeBSD 
  66.                                                                                        symbolicationStrategy:PLCrashReporterSymbolicationStrategyAll]; 
  67.                     PLCrashReporter *crashReporter = [[PLCrashReporter alloc] initWithConfiguration:config]; 
  68.   
  69.                     NSData *data = [crashReporter generateLiveReport]; 
  70.                     PLCrashReport *reporter = [[PLCrashReport alloc] initWithData:data error:NULL]; 
  71.                     NSString *report = [PLCrashReportTextFormatter stringValueForCrashReport:reporter 
  72.                                                                               withTextFormat:PLCrashReportTextFormatiOS];                                                                                   
  73.                     //上傳卡頓日志文件 
  74.   
  75.                 } 
  76.             } 
  77.             timeoutCount = 0; 
  78.         } 
  79.     }); 
  80.   
  81. } 
  82.   
  83. static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) 
  84. { 
  85.     LagCollectionTool *tool = (__bridge LagCollectionTool *)info; 
  86.     tool->activity = activity; 
  87.   
  88.     dispatch_semaphore_t semaphore = tool->semaphore; 
  89.     dispatch_semaphore_signal(semaphore); 
  90. } 

從容崩潰，上傳崩潰日志

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

  1. // 1. 注冊ExceptionHandler 
  2.   
  3. + (void)installUncaughtExceptionHandler { 
  4.     NSSetUncaughtExceptionHandler(&HandleException); 
  5.   
  6.     signal(SIGHUP, SignalHandler); 
  7.     signal(SIGINT, SignalHandler); 
  8.     signal(SIGQUIT, SignalHandler); 
  9.   
  10.     signal(SIGABRT, SignalHandler); 
  11.     signal(SIGILL, SignalHandler); 
  12.     signal(SIGSEGV, SignalHandler); 
  13.     signal(SIGFPE, SignalHandler); 
  14.     signal(SIGBUS, SignalHandler); 
  15.     signal(SIGPIPE, SignalHandler); 
  16. } 
  17.   
  18. // 2. 處理崩潰信息 
  19. void SignalHandler(int signal) { 
  20.     // 1. 獲取調用棧 
  21.     // 2. 處理異常 
  22.   
  23.     // 3. App保活 
  24.     BOOL isContiune = TRUE; // 是否要保活 
  25.     CFRunLoopRef runLoop = CFRunLoopGetCurrent(); 
  26.     CFArrayRef allModes = CFRunLoopCopyAllModes(runLoop); 
  27.   
  28.     while (isContiune) { 
  29.         for (NSString *mode in (__bridge NSArray *)allModes) { 
  30.             CFRunLoopRunInMode((CFStringRef)mode, 0.001, true); 
  31.         } 
  32.     } 
  33.     CFRelease(allModes); 
  34.     signal(SIGABRT, SIG_DFL); 
  35.     signal(SIGILL, SIG_DFL); 
  36.     signal(SIGSEGV, SIG_DFL); 
  37.     signal(SIGFPE, SIG_DFL); 
  38.     signal(SIGBUS, SIG_DFL); 
  39.     signal(SIGPIPE, SIG_DFL); 
  40. } 

延伸：

監控系統不光局限于性能、崩潰率，也可以將統計策略延伸到網絡請求連通率或者一些業務層面，更好的把控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拍磚啦，我會努力創作更好的文章

文中引用到的文章如下：

CocoaChina - iOS 實時卡頓監控

iOS Core Animation: Advanced Techniques 中文譯本

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

PLCrashReporter

KSCrash

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

責任編輯：張子龍 來源： 簡書
iOS結構優化項目
相關推薦

2011-06-22 09:43:28

項目經理

2020-02-12 08:50:05

Linux命令啟動時間

2009-12-16 17:50:58

Ruby on Rai

2011-07-06 08:46:30

2024-02-22 10:27:00

Python開發

2023-12-01 10:19:00

接口優化事務

2022-02-09 10:39:18

數字化轉型項目管理企業

2011-06-03 16:25:14

企業網站SEO

2011-09-06 10:00:19

Vista右鍵菜單

2011-06-29 10:06:23

Linux服務器優化

2011-09-08 18:01:57

2023-10-04 18:29:24

NFS小文件業務

2021-04-21 13:48:22

MySQL優化Redis

2024-12-27 09:21:58

2010-02-03 13:55:51

Python 代碼

2010-06-02 14:16:18

SVN版本控制

2010-07-22 10:58:49

batch Telne

2011-07-28 14:07:30

2010-09-13 10:45:04

2010-07-21 14:17:07

Linux telne
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 午夜影院在线观看版 | a级大片免费观看 | 欧美.com| 91视频进入| 亚洲综合视频一区 | 欧美乱操| 久久一区二区三区四区 | 国产精品麻 | a视频在线| 亚欧精品一区 | 欧美日韩精品在线一区 | 亚洲国产一区二区视频 | 欧美1区2区| 7777在线视频免费播放 | 91黄在线观看 | 亚洲激情综合网 | 爽爽免费视频 | 亚洲精品一区二区三区丝袜 | 欧美成人激情 | 在线观看亚洲专区 | 久久中文字幕在线 | 91久久精品视频 | 欧美日韩一区二区在线观看 | 亚洲欧美日韩一区二区 | 国产在线一区二区 | 国产精品久久久久久亚洲调教 | 欧美视频一区二区三区 | 国产一级特黄aaa大片评分 | 国产欧美久久一区二区三区 | 影视先锋av资源噜噜 | 精品久久久久久久久久 | 黄片毛片免费看 | 日韩理论电影在线观看 | 性国产丰满麻豆videosex | 7777在线 | 免费观看av| 亚洲高清在线观看 | 亚洲日本欧美日韩高观看 | 精品国产乱码久久久久久蜜退臀 | 99久久99 | 北条麻妃99精品青青久久 |