组件化
1.组件化有什么好处？
业务分层、解耦，使代码变得可维护；
有效的拆分、组织日益庞大的工程代码，使工程目录变得可维护；
便于各业务功能拆分、抽离，实现真正的功能复用；
业务隔离，跨团队开发代码控制和版本风险控制的实现；
模块化对代码的封装性、合理性都有一定的要求，提升开发同学的设计能力；
在维护好各级组件的情况下，随意组合满足不同客户需求；（只需要将之前的多个业务组件模块在新的主App中进行组装即可快速迭代出下一个全新App）
2.你是如何组件化解耦的？
-
分层
基础功能组件：按功能分库，不涉及产品业务需求，跟库Library类似，通过良好的接口拱上层业务组件调用；不写入产品定制逻辑，通过扩展接口完成定制；
基础UI组件：各个业务模块依赖使用，但需要保持好定制扩展的设计
业务组件：业务功能间相对独立，相互间没有Model共享的依赖；业务之间的页面调用只能通过UIBus进行跳转；业务之间的逻辑Action调用只能通过服务提供；
中间件：target-action，url-block，protocol-class
3.为什么CTMediator方案优于基于Router的方案？
Router的缺点：
在组件化的实施过程中，注册URL并不是充分必要条件。组件是不需要向组件管理器注册URL的，注册了URL之后，会造成不必要的内存常驻。注册URL的目的其实是一个服务发现的过程，在iOS领域中，服务发现的方式是不需要通过主动注册的，使用runtime就可以了。另外，注册部分的代码的维护是一个相对麻烦的事情，每一次支持新调用时，都要去维护一次注册列表。如果有调用被弃用了，是经常会忘记删项目的。runtime由于不存在注册过程，那就也不会产生维护的操作，维护成本就降低了。 由于通过runtime做到了服务的自动发现，拓展调用接口的任务就仅在于各自的模块，任何一次新接口添加，新业务添加，都不必去主工程做操作，十分透明。
在iOS领域里，一定是组件化的中间件为openURL提供服务，而不是openURL方式为组件化提供服务。如果在给App实施组件化方案的过程中是基于openURL的方案的话，有一个致命缺陷：非常规对象(不能被字符串化到URL中的对象，例如UIImage)无法参与本地组件间调度。
在本地调用中使用URL的方式其实是不必要的，如果业务工程师在本地间调度时需要给出URL，那么就不可避免要提供params，在调用时要提供哪些params是业务工程师很容易懵逼的地方。为了支持传递非常规参数，蘑菇街的方案采用了protocol，这个会侵入业务。由于业务中的某个对象需要被调用，因此必须要符合某个可被调用的protocol，然而这个protocol又不存在于当前业务领域，于是当前业务就不得不依赖public Protocol。这对于将来的业务迁移是有非常大的影响的。
CTMediator的优点：
调用时，区分了本地应用调用和远程应用调用。本地应用调用为远程应用调用提供服务。
组件仅通过Action暴露可调用接口，模块与模块之间的接口被固化在了Target-Action这一层，避免了实施组件化的改造过程中，对Business的侵入，同时也提高了组件化接口的可维护性。
方便传递各种类型的参数。
4.基于CTMediator的组件化方案，有哪些核心组成？
CTMediator中间件：集成就可以了
模块Target_%@：模块的实现及提供对外的方法调用Action_methodName，需要传参数时，都统一以NSDictionary*的形式传入。
CTMediator+%@扩展：扩展里声明了模块业务的对外接口，参数明确，这样外部调用者可以很容易理解如何调用接口。
持续集成
1.你在项目中使用过什么持续集成方式？
Fastlane：一套用Ruby写的自动化工具集，可用于iOS和Android的打包、发布，节省了大量时间。Fastlane配置比较简单，主要编写集成的lane，然后在命令行操作即可
Jenkins：Jenkins比较受欢迎，插件众多，但对新手来说配置可能稍微麻烦点。
2.jenkins怎么备份恢复
- 只需要拷贝主home下面的 .jenkins打个包，下次要恢复就用这个覆盖，所有的东西就都一模一样了。其实就是配置的东西都在这里面，插件的话有个Plugin的文件夹下面就是所有的插件的东西。
3.jenkins你都用了哪些插件？
Keychains and Provisioning Profiles Management：管理本地的keychain和iOS证书的插件
Xcode integration：用于Xcode构建
GIT plugin/SVN：代码管理插件
项目架构
1.MVC、MVP、MVVM模式
MVC（Model、View、Controller）
MVC是比较直观的架构模式，最核心的就是通过Controller层来进行调控，首先看一下官方提供的MVC示意图：
Model和View永远不能相互通信，只能通过Controller传递
Controller可以直接与Model对话（读写调用Model），Model通过NOtification和KVO机制与Controller间接通信
Controller可以直接与View对话，通过IBoutlet直接操作View，IBoutlet直接对应View的控件（例如创建一个Button：需声明一个 IBOutlet UIButton * btn），View通过action向Controller报告时间的发生(用户点击了按钮)。Controller是View的直接数据源
优点：对于混乱的项目组织方式，有了一个明确的组织方式。通过Controller来掌控全局，同时将View展示和Model的变化分开
缺点：愈发笨重的Controller，随着业务逻辑的增加，大量的代码放进Controller，导致Controller越来越臃肿，堆积成千上万行代码，后期维护起来费时费力
MVP（Model、View、Presenter）
MVP模式是MVC模式的一个演化版本，其中Model与MVC模式中Model层没有太大区别，主要提供数据存储功能，一般都是用来封装网络获取的json数据；View与MVC中的View层有一些差别，MVP中的View层可以是viewController、view等控件；Presenter层则是作为Model和View的中介，从Model层获取数据之后传给View。
从上图可以看出，从MVC模式中增加了Presenter层，将UIViewController中复杂的业务逻辑、网络请求等剥离出来。
优点 模型和视图完全分离，可以做到修改视图而不影响模型；更高效的使用模型，View不依赖Model，可以说VIew能做到对业务逻辑完全分离
缺点 Presenter中除了处理业务逻辑以外，还要处理View-Model两层的协调，也会导致Presenter层的臃肿
MVVM（Model、Controller/View、ViewModel）
在MVVM中，view和ViewCOntroller联系在一起，我们把它们视为一个组件，view和ViewController都不能直接引用model，而是引用是视图模型即ViewModel。
viewModel是一个用来放置用户输入验证逻辑、视图显示逻辑、网络请求等业务逻辑的地方，这样的设计模式，会轻微增加代码量，但是会减少代码的复杂性
优点 VIew可以独立于Model的变化和修改，一个ViewModel可以绑定到不同的View上，降低耦合，增加重用
缺点 过于简单的项目不适用、大型的项目视图状态较多时构建和维护成本太大
合理的运用架构模式有利于项目、团队开发工作，但是到底选择哪个设计模式，哪种设计模式更好，就像本文开头所说，不同的设计模式，只是让不同的场景有了更多的选择方案。根据项目场景和开发需求，选择最合适的解决方案。
2.关于RAC你有怎样运用到解决不同API依赖关系
-
信号的依赖：使用场景是当信号A执行完才会执行信号B,和请求的依赖很类似,例如请求A请求完毕才执行请求B,我们需要注意信号A必须要执行发送完成信号,否则信号B无法执行
//这相当于网络请求中的依赖,必须先执行完信号A才会执行信号B //经常用作一个请求执行完毕后,才会执行另一个请求 //注意信号A必须要执行发送完成信号,否则信号B无法执行 RACSignal * concatSignal = [self.signalA concat:self.signalB] //这里我们是对这个拼接信号进行订阅 [concatSignal subscribeNext:^(id x) { NSLog(@"%@",x); }];
3.@weakify和我们宏定义的WeakSelf有什么区别？
@weakify 可以多参数使用
4.微服务架构设想。
微服务架构具有以下优势：
-
1.灵活和独立的可扩展性
灵活扩展是微服务架构的主要优势之一。与单片架构不同，每个模块都可以水平扩展并独立于其他模块。因此，微服务架构非常适合大型项目。
-
2.独立技术堆栈
在微服务架构中，软件工程师有机会使用各种工具和技术构建APP。代码可以用不同的编程语言编写，这为APP开发过程增加了更多的灵活性。
-
3.更好的故障隔离
如果一个服务失败，它不会影响其他服务的功能。与其他体系结构样式相比，在微服务中，系统继续工作，单片模式下的问题会影响整个APP。
-
4.易于部署和集成
虽然即使是小代码更改的情况下，开发人员也必须再次部署APP，但在微服务架构中，部署变得更快更轻松。
由于所有服务都是围绕单一业务流程构建的，因此程序员不必修改和重新部署整个APP，只需要您需要的区域。因此，改进产品也比较简单。
微服务可以通过全自动部署机制独立部署。此外，通过使用开源持续集成工具，开发人员大大简化了与第三方服务的集成。
-
5.容易理解
微服务体系结构的另一个优点是很容易理解系统是如何工作的以及它是如何开发的。当一个新的团队成员来到这个项目并且必须快速钻研它时，这特别有用。
那么在iOS中如何借鉴这种思想去构建我们的App呢？是需要我们开发者自己去不断探索的
性能优化
1.造成tableView卡顿的原因有哪些？
-
1.最常用的就是cell的重用， 注册重用标识符
如果不重用cell时，每当一个cell显示到屏幕上时，就会重新创建一个新的cell
如果有很多数据的时候，就会堆积很多cell。
如果重用cell，为cell创建一个ID，每当需要显示cell 的时候，都会先去缓冲池中寻找可循环利用的cell，如果没有再重新创建cell
-
2.避免cell的重新布局
cell的布局填充等操作 比较耗时，一般创建时就布局好
如可以将cell单独放到一个自定义类，初始化时就布局好
-
3.提前计算并缓存cell的属性及内容
当我们创建cell的数据源方法时，编译器并不是先创建cell 再定cell的高度
而是先根据内容一次确定每一个cell的高度，高度确定后，再创建要显示的cell，滚动时，每当cell进入凭虚都会计算高度，提前估算高度告诉编译器，编译器知道高度后，紧接着就会创建cell，这时再调用高度的具体计算方法，这样可以方式浪费时间去计算显示以外的cell
-
4.减少cell中控件的数量
尽量使cell得布局大致相同，不同风格的cell可以使用不用的重用标识符，初始化时添加控件，
不适用的可以先隐藏
-
5.不要使用ClearColor，无背景色，透明度也不要设置为0
渲染耗时比较长
-
6.使用局部更新
如果只是更新某组的话，使用reloadSection进行局部更
7.加载网络数据，下载图片，使用异步加载，并缓存
8.少使用addView 给cell动态添加view
9.按需加载cell，cell滚动很快时，只加载范围内的cell
10.不要实现无用的代理方法，tableView只遵守两个协议
11.缓存行高：estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同时存在，这两者同时存在才会出现“窜动”的bug。所以我的建议是：只要是固定行高就写预估行高来减少行高调用次数提升性能。如果是动态行高就不要写预估方法了，用一个行高的缓存字典来减少代码的调用次数即可
12.不要做多余的绘制工作。在实现drawRect:的时候，它的rect参数就是需要绘制的区域，这个区域之外的不需要进行绘制。例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判断是否需要绘制image和text，然后再调用绘制方法。
13.预渲染图像。当新的图像出现时，仍然会有短暂的停顿现象。解决的办法就是在bitmap context里先将其画一遍，导出成UIImage对象，然后再绘制到屏幕；
14.使用正确的数据结构来存储数据。
2.如何提升 tableview 的流畅度？
-
本质上是降低 CPU、GPU 的工作，从这两个大的方面去提升性能。
CPU：对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制
GPU：纹理的渲染
-
卡顿优化在 CPU 层面
尽量用轻量级的对象，比如用不到事件处理的地方，可以考虑使用 CALayer 取代 UIView
不要频繁地调用 UIView 的相关属性，比如 frame、bounds、transform 等属性，尽量减少不必要的修改
尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性
Autolayout 会比直接设置 frame 消耗更多的 CPU 资源
图片的 size 最好刚好跟 UIImageView 的 size 保持一致
控制一下线程的最大并发数量
尽量把耗时的操作放到子线程
文本处理（尺寸计算、绘制）
图片处理（解码、绘制）
-
卡顿优化在 GPU层面
尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示
GPU能处理的最大纹理尺寸是 4096x4096，一旦超过这个尺寸，就会占用 CPU 资源进行处理，所以纹理尽量不要超过这个尺寸
尽量减少视图数量和层次
减少透明的视图（alpha<1），不透明的就设置 opaque 为 YES
尽量避免出现离屏渲染
-
iOS 保持界面流畅的技巧
1.预排版，提前计算
在接收到服务端返回的数据后，尽量将 CoreText 排版的结果、单个控件的高度、cell 整体的高度提前计算好，将其存储在模型的属性中。需要使用时，直接从模型中往外取，避免了计算的过程。
尽量少用 UILabel，可以使用 CALayer 。避免使用 AutoLayout 的自动布局技术，采取纯代码的方式
2.预渲染，提前绘制
例如圆形的图标可以提前在，在接收到网络返回数据时，在后台线程进行处理，直接存储在模型数据里，回到主线程后直接调用就可以了
避免使用 CALayer 的 Border、corner、shadow、mask 等技术，这些都会触发离屏渲染。
3.异步绘制
4.全局并发线程
5.高效的图片异步加载
3.APP启动时间应从哪些方面优化？
App启动时间可以通过xcode提供的工具来度量，在Xcode的Product->Scheme-->Edit Scheme->Run->Auguments中，将环境变量DYLD_PRINT_STATISTICS设为YES，优化需以下方面入手
-
dylib loading time
核心思想是减少dylibs的引用
合并现有的dylibs（最好是6个以内）
使用静态库
-
rebase/binding time
核心思想是减少DATA块内的指针
减少Object C元数据量，减少Objc类数量，减少实例变量和函数（与面向对象设计思想冲突）
减少c++虚函数
多使用Swift结构体（推荐使用swift）
-
ObjC setup time
核心思想同上，这部分内容基本上在上一阶段优化过后就不会太过耗时
initializer time
-
使用initialize替代load方法
减少使用c/c++的attribute((constructor))；推荐使用dispatch_once() pthread_once() std:once()等方法
推荐使用swift
不要在初始化中调用dlopen()方法，因为加载过程是单线程，无锁，如果调用dlopen则会变成多线程，会开启锁的消耗，同时有可能死锁
不要在初始化中创建线程
4.如何降低APP包的大小
降低包大小需要从两方面着手
-
可执行文件
编译器优化：Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default 设置为 YES，去掉异常支持，Enable C++ Exceptions、Enable Objective-C Exceptions 设置为 NO， Other C Flags 添加 -fno-exceptions
利用 AppCode 检测未使用的代码：菜单栏 -> Code -> Inspect Code编写LLVM插件检测出重复代码、未被调用的代码
-
资源（图片、音频、视频 等）
优化的方式可以对资源进行无损的压缩
5.如何检测离屏渲染与优化
检测，通过勾选Xcode的Debug->View Debugging-->Rendering->Run->Color Offscreen-Rendered Yellow项。
优化，如阴影，在绘制时添加阴影的路径
6.怎么检测图层混合
1、模拟器debug中color blended layers红色区域表示图层发生了混合
2、Instrument-选中Core Animation-勾选Color Blended Layers
避免图层混合：
确保控件的opaque属性设置为true，确保backgroundColor和父视图颜色一致且不透明
如无特殊需要，不要设置低于1的alpha值
确保UIImage没有alpha通道
UILabel图层混合解决方法：
iOS8以后设置背景色为非透明色并且设置label.layer.masksToBounds=YES让label只会渲染她的实际size区域，就能解决UILabel的图层混合问题
iOS8 之前只要设置背景色为非透明的就行
为什么设置了背景色但是在iOS8上仍然出现了图层混合呢？
UILabel在iOS8前后的变化，在iOS8以前，UILabel使用的是CALayer作为底图层，而在iOS8开始，UILabel的底图层变成了_UILabelLayer，绘制文本也有所改变。在背景色的四周多了一圈透明的边，而这一圈透明的边明显超出了图层的矩形区域，设置图层的masksToBounds为YES时，图层将会沿着Bounds进行裁剪 图层混合问题解决了
7.日常如何检查内存泄露？
-
目前我知道的方式有以下几种
Memory Leaks
Alloctions
Analyse
Debug Memory Graph
MLeaksFinder
-
泄露的内存主要有以下两种：
Laek Memory 这种是忘记 Release 操作所泄露的内存。
Abandon Memory 这种是循环引用，无法释放掉的内存。
