iOS面试题汇总（一）

2017-11-02 本文已影响30人 zgsddzwj

1. 并排两个label，宽度由内容决定。父级View宽度不够时，优先显示左边label的内容

遇到这种跟内容压缩、优先级有关的布局，就不得不提Autolayout中的两个重要的属性“Content CompressionResistance”和“Content Hugging”。
Content Compression Resistance = 不许挤我！
对，这个属性说白了就是“不许挤我”=。=这个属性的优先级（Priority）越高，越不“容易”被压缩。也就是说，当整体的空间装不下所有的View的时候，Content Compression Resistance优先级越高的，显示的内容越完整。
Content Hugging = 抱紧！
这个属性的优先级越高，整个View就要越“抱紧”View里面的内容。也就是View的大小不会随着父级View的扩大而扩大。
分析
根据要求，可以将约束分为两个部分：
整体空间足够时，两个label的宽度由内容决定，也就是说，label的“Content Hugging”优先级很高，而且没有固定的Width属性。
整体空间不够时，左边的label更不容易被压缩，也就是“Content Compression Resistance”优先级更高。
重点：
label不设置具体的宽度（width）属性，宽度由内容决定。
显示的优先级由“Content Compression Resistance”属性的高低决定。
关键代码
关键的代码如下：（label1是左边的label，label2是右边的）

 // label1: 位于左上角
    [_label1 mas_makeConstraints:^(MASConstraintMaker *make) {
        make.top.equalTo(_contentView1.mas_top).with.offset(5);
        make.left.equalTo(_contentView1.mas_left).with.offset(2);

        // 40高度
        make.height.equalTo(@40);
    }];

    // label2: 位于右上角
    [_label2 mas_makeConstraints:^(MASConstraintMaker *make) {
        //左边贴着label1
        make.left.equalTo(_label1.mas_right).with.offset(2);

        //上边贴着父view
        make.top.equalTo(_contentView1.mas_top).with.offset(5);

        //右边的间隔保持大于等于2，注意是lessThanOrEqual
        //这里的“lessThanOrEqualTo”放在从左往右的X轴上考虑会更好理解。
        //即：label2的右边界的X坐标值“小于等于”containView的右边界的X坐标值。
        make.right.lessThanOrEqualTo(_contentView1.mas_right).with.offset(-2);

        //只设置高度40
        make.height.equalTo(@40);
    }];

设置内容约束

 //设置label1的content hugging 为1000
    [_label1 setContentHuggingPriority:UILayoutPriorityRequired
                               forAxis:UILayoutConstraintAxisHorizontal];

    //设置label1的content compression 为1000
    [_label1 setContentCompressionResistancePriority:UILayoutPriorityRequired
                                             forAxis:UILayoutConstraintAxisHorizontal];

    //设置右边的label2的content hugging 为1000
    [_label2 setContentHuggingPriority:UILayoutPriorityRequired
                               forAxis:UILayoutConstraintAxisHorizontal];

    //设置右边的label2的content compression 为250
    [_label2 setContentCompressionResistancePriority:UILayoutPriorityDefaultLow
                                             forAxis:UILayoutConstraintAxisHorizontal];

参考：http://tutuge.me/2015/05/23/autolayout-example-with-masonry/

2.KVO、KVC的原理及其使用方法

KVC的原理：KVC是怎么访问属性的？

KVC在某种程度上提供了替代存取方法（访问器方法）的方案，不过存取方法终究是个好东西，以至于只要有可能，KVC也尽可能先尝试使用存取方法访问属性。当使用KVC访问属性时，它内部其实做了很多事：
1.首先查找有无<property>，set<property>，is<property>等property属性对应的存取方法，若有，则直接使用这些方法;
2.若无，则继续查找<property>，_get<property>，_set<property>等方法，若有就使用；
3.若查询不到以上任何存取方法，则尝试直接访问实例变量<property>，<property>；
4.若连该成员变量也访问不到，则会在下面方法中抛出异常。之所以提供这两个方法，就是让你在因访问不到该属性而程序即将崩掉前，供你重写，在内做些处理，防止程序直接崩掉。
valueForUndefinedKey:和setValue:forUndefinedKey:方法。

KVO的原理：KVO是怎么实现的？

当某个类的对象第一次被观察时，系统就会在运行期动态地创建该类的一个派生类，在这个派生类中重写基类中被观察属性的 setter 方法，在setter方法里使其具有通知机制。因此，要想KVO生效，必须直接或间接的通过setter方法访问属性（KVC的setValue就是间接方式）。直接访问成员变量KVO是不生效的。
同时派生类还重写了 class 方法以“欺骗”外部调用者它就是起初的那个类。然后系统将这个对象的 isa 指针指向这个新诞生的派生类，因此这个对象就成为该派生类的对象了，因而在该对象上对 setter 的调用就会调用重写的 setter，从而激活键值通知机制。此外，派生类还重写了 dealloc 方法来释放资源。

参考链接：http://www.jianshu.com/p/66bda10168f1

3.UITableView和UICollectionView的区别

UICollectionView默认没有表头, UITableView: 有表头和表尾;
UICollectionView的区里面是项Item， UITableView:区里面是单元格Cell
UICollectionView布局使用UICollectionViewLayOut的子类（UICollectionViewFlowLayOut 流式布局：流式布局的特点就是会自动根据屏幕的宽度适当的显示列数，如果屏幕款显示的列数可能就多，例如iphone 6s Plus, 如果屏幕相对较窄，显示的列数则较少，例如 iphone 4s）
UICollectionView和UITableView都是分区（段）的
UICollectionView可以简单的实现横向布局
UICollectionView无法设置cell分割线

关于UICollectionView的实现，网上一大片，我就不详细描述了。

4. synthesize 和 dynamic

synthesize默认生成getter、setter和对应的成员变量

@synthesize的作用
1、一个作用就是让编译器为你自动生成setter与getter方法。
2、还有一个作用，可以指定与属性对应的实例变量，
例如@synthesize str = xxx；那么self.myButton其实是操作的实例变量xxx，而不是_str了。
如果.m文件中写了@synthesize str;那么生成的实例变量就是str；如果没写@synthesize str;那么生成的实例变量就是_str。
(注意：_str这个实例变量是不存在的).
在老式的代码中，@property只能写在@interface @end中，@synthesize只能写在@implementation @end中，自从xcode 4.5及以后的版本中，@property就独揽了@property和@synthesize的功能。
@property (nonatomic, copy) NSString *str;这句话完成了3个功能：1）生成_str成员变量的get和set方法的声明；2）生成_str成员变量set和get方法的实现；3）生成一个_str的成员变量。(注意：这种方式生成的成员变量是private的)
@dynamic 告诉编译器：属性的 setter 与 getter 方法由用户自己实现，不自动生成。（当然对于 readonly 的属性只需提供 getter 即可）。假如一个属性被声明为 @dynamic var，然后你没有提供 @setter方法和 @getter 方法，编译的时候没问题，但是当程序运行到 instance.var = someVar，由于缺 setter 方法会导致程序崩溃；或者当运行到 someVar = var 时，由于缺 getter 方法同样会导致崩溃。编译时没问题，运行时才执行相应的方法，这就是所谓的动态绑定。

5.self.nameArray = [NSMutaleArray alloc] init]; 这句话会引起什么问题？

如果是在MRC下
上述代码，造成的问题是，在self.nameArray的时候相当于调用了set方法，引用计数＋1，后面alloc的时候，引用计数再次＋1。
在我们最后dealloc中release的时候，引用计数只减了一次，并没有完成全部释放，这样就造成了内存泄漏的问题。
解决方法：就是用“_”来初始化以及访问变量，这样就不会产生内存问题，虽不是什么高明的办法，但的确有效。

_nameArray = [NSMutaleArray alloc] init];

如果是在ARC（自动管理内存）的情况下虽然不存在上述问题，但从编码规范来考虑，还是注意点儿的好。

参考：iOS .（点语法）和_（下划线）的使用原则

6.assign 与weak的区别

assign适用于基本数据类型，weak是适用于NSObject对象，并且是一个弱引用。

assign其实也可以用来修饰对象。那么我们为什么不用它修饰对象呢？因为被assign修饰的对象（一般编译的时候会产生警告：Assigning retained object to unsafe property; object will be released after assignment）在释放之后，指针的地址还是存在的，也就是说指针并没有被置为nil，造成野指针。对象一般分配在堆上的某块内存，如果在后续的内存分配中，刚好分到了这块地址，程序就会崩溃掉。

那为什么可以用assign修饰基本数据类型？因为基础数据类型一般分配在栈上，栈的内存会由系统自己自动处理，不会造成野指针。
weak修饰的对象在释放之后，指针地址会被置为nil。所以现在一般弱引用就是用weak。weak使用场景：

在ARC下,在有可能出现循环引用的时候，往往要通过让其中一端使用weak来解决，比如: delegate代理属性，通常就会声明为weak。

自身已经对它进行一次强引用，没有必要再强引用一次时也会使用weak。比如：自定义 IBOutlet控件属性一般也使用weak，当然也可以使用strong。

7.为什么IBOutlet属性是weak的？

因为当我们将控件拖到Storyboard上，相当于新创建了一个对象，而这个对象是加到视图控制器的view上，view有一个subViews属性，这个属性是一个数组，里面是这个view的所有子view，而我们加的控件就位于这个数组中，那么说明，实际上我们的控件对象是属于view的，也就是说view对加到它上面的控件是强引用。当我们使用Outlet属性的时候，我们是在viewController里面使用，而这个Outlet属性是有view来进行强引用的，我们在viewController里面仅仅是对其使用，并没有必要拥有它，所以是weak的。
还有一种情况，你的xib中除了原先的view之外，又创建了一个viewB，这个时候viewB没有被任何人引用，和self.view也没有关系，也不在self.view.subviews中。那么你在IBOutlet链接这个viewB的时候就必须用strong，而不是weak了。
如果将weak改为strong，也是没有问题的，并不会造成强引用循环。当viewController的指针指向其他对象或者为nil，这个viewController销毁，那么对控件就少了一个强引用指针。然后它的view也随之销毁，那么subViews也不存在了，那么控件就又少了一个强引用指针，如果没有其他强引用，那么这个控件也会随之销毁。

8.NSNotificationCenter实现原理？

NSNotificatinonCenter是使用观察者模式来实现的用于跨层传递消息，用来降低耦合度。
NSNotificatinonCenter用来管理通知，将观察者注册到NSNotificatinonCenter的通知调度表中，然后发送通知时利用标识符name和object识别出调度表中的观察者，然后调用相应的观察者的方法，即传递消息（在Objective-C中对象调用方法，就是传递消息，消息有name或者selector，可以接受参数，而且可能有返回值），如果是基于block创建的通知就调用NSNotification的block。

9.如何理解iOS中事件的传递和响应机制

事件的传递与响应：
- 1、当一个事件发生后，事件会从父控件传给子控件，也就是说由UIApplication -> UIWindow -> UIView -> initial view,以上就是事件的传递，也就是寻找最合适的view的过程。
- 2、接下来是事件的响应。
  首先看initial view能否处理这个事件，如果不能则会将事件传递给其上级视图（inital view的superView）；如果上级视图仍然无法处理则会继续往上传递；一直传递到视图控制器view controller，首先判断视图控制器的根视图view是否能处理此事件；如果不能则接着判断该视图控制器能否处理此事件，如果还是不能则继续向上传递；（对于第二个图视图控制器本身还在另一个视图控制器中，则继续交给父视图控制器的根视图，如果根视图不能处理则交给父视图控制器处理）；一直到 window，如果window还是不能处理此事件则继续交给application处理，如果最后application还是不能处理此事件则将其丢弃
- 3、在事件的响应中，如果某个控件实现了touches...方法，则这个事件将由该控件来接受，如果调用了[supertouches….];就会将事件顺着响应者链条往上传递，传递给上一个响应者；接着就会调用上一个响应者的touches….方法
如何做到一个事件多个对象处理：
因为系统默认做法是把事件上抛给父控件，所以可以通过重写自己的touches方法和父控件的touches方法来达到一个事件多个对象处理的目的。

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
    // 1.自己先处理事件...
    NSLog(@"do somthing...");
    // 2.再调用系统的默认做法，再把事件交给上一个响应者处理
    [super touchesBegan:touches withEvent:event]; 
}

事件的传递和响应的区别：
事件的传递是从上到下（父控件到子控件），事件的响应是从下到上（顺着响应者链条向上传递：子控件到父控件。

参考：史上最详细的iOS之事件的传递和响应机制-原理篇

10.关于GCD中的串行，并行，同步，异步

串行，并行
- 系统会给每个应用自动分配两个队列：
  - 1.dispatch_get_main_queue() 串行队列处理UI，也可以叫串行主队列，这个队列会排在主线程中。
  - 2.dispatch_get_global_queue(优先级, 扩展)并行队列。
- 当然根据需求也可以自己主动创建队dispatch_queue_create(队列标签, 串行／并行)。

注意：串行 queue 每次只能执行一个任务,可以使用它来代替锁,保护共享资源或可变的数据结构,串行queue确保任务按可预测的顺序执行(这是比锁好的地方)

同步和异步
- 1.异步调度 dispatch_async : 把一个任务添加到某queue后就马上离开,而不管任务在那个queue里的执行状态
- 1. 同步调度 dispatch_sync : 把一个任务添加到某queue后,等这个任务完成,调用线程才继续执行.
  所以,异步调度和同步调度的区别不在于被添加的任务怎样执行,而在于调用线程是否等待任务执行完。
线程死锁

dispatch_sync(dispatch_get_main_queue(), ^{
    [self doSomething:@"A"];
});

这段代码会造成线程死锁，同步串行，因为是同步所以当任务添加进去后要等block里面的内容执行完了才能继续其他动作，而又因为是串行主线程，所以block里面的内容需要等添加任务的代码完成了之后才能进行，因此会出现相互等待造成线程死锁

关于GCD的使用，可以参考：iOS中GCD的使用小结

11.GCD和NSOperation的区别

NSThread:
–优点：NSThread 比其他两个轻量级，使用简单
–缺点：需要自己管理线程的生命周期、线程同步、加锁、睡眠以及唤醒等。线程同步对数据的加锁会有一定的系统开销
NSOperation：
–不需要关心线程管理，数据同步的事情，可以把精力放在自己需要执行的操作上
–NSOperation是面向对象的
GCD：
–Grand Central Dispatch是由苹果开发的一个多核编程的解决方案。iOS4.0+才能使用，是替代NSThread， NSOperation的高效和强大的技术
GCD是基于C语言的

GCD是底层的C语言构成的API，而NSOperationQueue及相关对象是Objc的对象。在GCD中，在队列中执行的是由block构成的任务，这是一个轻量级的数据结构；而Operation作为一个对象，为我们提供了更多的选择；

在NSOperationQueue中，我们可以随时取消已经设定要准备执行的任务(当然，已经开始的任务就无法阻止了)，而GCD没法停止已经加入queue的block(其实是有的，但需要许多复杂的代码)；

NSOperation能够方便地设置依赖关系，我们可以让一个Operation依赖于另一个Operation，这样的话尽管两个Operation处于同一个并行队列中，但前者会直到后者执行完毕后再执行；

我们能将KVO应用在NSOperation中，可以监听一个Operation是否完成或取消，这样子能比GCD更加有效地掌控我们执行的后台任务；
在NSOperation中，我们能够设置NSOperation的priority优先级，能够使同一个并行队列中的任务区分先后地执行，而在GCD中，我们只能区分不同任务队列的优先级，如果要区分block任务的优先级，也需要大量的复杂代码；

我们能够对NSOperation进行继承，在这之上添加成员变量与成员方法，提高整个代码的复用度，这比简单地将block任务排入执行队列更有自由度，能够在其之上添加更多自定制的功能。

参考文献：

12.关于UIWindowLevel你懂多少？

UIWindow在显示的时候会根据UIWindowLevel进行排序的，即Level高的将排在所有Level比他低的层级的前面。下面我们来看UIWindowLevel的定义：

UIKIT_EXTERN const UIWindowLevel UIWindowLevelNormal;
UIKIT_EXTERN const UIWindowLevel UIWindowLevelAlert;
UIKIT_EXTERN const UIWindowLevel UIWindowLevelStatusBar __TVOS_PROHIBITED;

IOS系统中定义了三个window层级，其中每一个层级又可以分好多子层级(从UIWindow的头文件中可以看到成员变量CGFloat _windowSublevel;)，不过系统并没有把则个属性开出来。UIWindow的默认级别是UIWindowLevelNormal。
我们打印输出这三个level的值分别如下：

2012-03-27 22:46:08.752 UIViewSample[395:f803] Normal window level: 0.000000
2012-03-27 22:46:08.754 UIViewSample[395:f803] Alert window level: 2000.000000
2012-03-27 22:46:08.755 UIViewSample[395:f803] Status window level: 1000.000000

这样印证了他们级别的高低顺序从小到大为Normal < StatusBar < Alert。

注意：当Level层级相同的时候，只有第一个设置为KeyWindow的显示出来，后面同级的再设置KeyWindow也不会显示。
UIWindow在显示的时候是不管KeyWindow是谁，都是Level优先的，即Level最高的始终显示在最前面

未完待续...

iOS面试题汇总（一）

猜你喜欢

热点阅读