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. 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中工具都有各自的用处，比如可以使用Leask查看App运行过程中的内存泄露，使用TimeProfiler查看App启动耗时或者方法耗时,或者偷懒一点可以使用CACurrentMediaTime()两次的差值计算方法耗时

结语

受限于篇幅原因，有些点也是一概而过，iOS中如何优化一个项目，这是一门很深的学问，知识点范围很广，我也只是涉及到了一部分，学无止境嘛，完成工作的同时我们也可以做一个酷酷的程序员，学学Haskell去体验下函数式编程思维的乐趣，或者搞搞LLDB更好得做个Debugger

最后，非常感谢您阅读这篇文章，如果我的文章产生了帮助，可以给一个小小的红心??，欢迎去我的小站www.manoboo.com拍砖啦，我会努力创作更好的文章

文中引用到的文章如下：

CocoaChina - iOS 实时卡顿监控

iOS Core Animation: Advanced Techniques 中文译本

文中所涉及到的开源库如下：

PLCrashReporter

KSCrash

MBNullSafe ManoBoo编写的NullSafe库，会进一步拓展功能

作者：ManoBoo

来源：51CTO