在发展日新月异的移动互联网时代，数据扮演着极其重要的角色。埋点作为一种最简单最直接的用户行为统计方式，能够全面精确的采集用户的使用习惯以及各功能点的迭代反馈等等，有了这些数据才能更好的驱动产品的决策设计和新业务场景的规划。本文旨在提出一种轻量级非侵入式的埋点方案，其主要有以下三方面优势

• 支持动态下发埋点配置

• 物理隔离埋点代码和业务代码

• 插件式的埋点功能实现

该方案通过维护一个JSON文件来指定埋点所在的类和方法，继而利用AOP的方式在对应的类和方法执行时动态嵌入埋点代码。对于需要逻辑判断来确定埋点值的场景，提供hook方法的入参，以及所在类的属性值读取，根据相应的状态值设置不同的埋点

埋点配置

埋点配置JSON表中包含需要hook的类名class和具体的事件event信息，event中包括hook的方法和对应的埋点值。如下所示

{
    "version": "0.1.0",
    "tracking": [
        {
            "class": "RJMainViewController",
            "event": {
                "rj_main_tracking": [
                    "tripTypeViewChangedWithIndex:",
                    "tripLabClickWithLabKey:"
                ],
                "user_fp_slide_click": "clickNavLeftBtn",
                "user_fp_reflocate_click": "clickLocationBtn"
            }
        },
        {
            "class": "RJTripHistoryViewModel",
            "event": {
                "user_mytrip_show": "tableView:didSelectRowAtIndexPath:"
            }
        },
        {
            "class": "RJTripViewController",
            "event": {
                "rj_trip_tracking": "callServiceEvent"
            }
        }
    ]
}

简单来说就是本来埋点需要手动在该方法写入埋点代码来记录埋点值，现在通过AOP的方式物理隔离埋点代码和业务代码，避免埋点的逻辑侵入污染业务逻辑。埋点包括固定埋点和需要逻辑判断的场景化埋点，固定埋点如下所示

{
    "class": "RJTripHistoryViewModel",
    "event": {
        "user_mytrip_show": "tableView:didSelectRowAtIndexPath:"
    }
}

RJTripHistoryViewModel为类名，tableView:didSelectRowAtIndexPath:为需要hook的该类中的方法，而user_mytrip_show则是具体的埋点值，也就是当RJTripHistoryViewModel中的tableView:didSelectRowAtIndexPath:方法执行的时候记录埋点值user_mytrip_show

{
    "class": "RJTripViewController",
    "event": {
        "rj_trip_tracking": "callServiceEvent"
    }
},

对于场景化埋点，则需要提供一个impl类来提供相应的逻辑判断。比如上述配置表中的rj_trip_tracking为场景埋点的实现类，在该类中根据状态量返回对应的埋点值，即当callServiceEvent方法执行时会去找rj_trip_tracking这个埋点impl同名类，取该类返回的埋点值记录埋点。需要注意到是event中的key值既可以作为埋点值也可以作为impl的类名，埋点库会首先判断是否存在对应的类，存在即认为是impl实现类，从该类中取具体的埋点值。反之，则认为是固定埋点值

配置表中的类名和方法名需要对应，在hook的时候会去匹配，如果发现类中不存在对应的方法，则会自动触发断言

固定埋点

对于固定的埋点，只需要在对应的方法执行时直接记录埋点，利用Aspects来hook指定的类和方法，代码如下所示

[class aspect_hookSelector:sel withOptions:AspectPositionBefore usingBlock:^(id<AspectInfo> info) {
    [events enumerateObjectsUsingBlock:^(NSString *name, NSUInteger idx, BOOL *stop) {
        NSLog(@"<RJEventTracking> - %@", ename);
    }];
} error:&error];

为了便于检测无效的埋点，还需对hook的类和方法进行匹配校验，若类中没有对应的方法，则抛出断言

+ (void)checkValidWithClass:(NSString *)class method:(NSString *)method {
    SEL sel       = NSSelectorFromString(method);
    Class c       = NSClassFromString(class);
    BOOL respond  = [c respondsToSelector:sel] || [c instancesRespondToSelector:sel];
    NSString *err = [NSString stringWithFormat:@"<RJEventTracking> - no specified method: %@ found on class: %@, please check", method, class];
    
    NSAssert(respond, err);
}

场景埋点

场景化埋点主要为同一事件但是在多种状态或逻辑下不同埋点的情况，比如同是联系客服的操作，在各种订单类型以及订单状态下所设置的埋点是不同的。这个情况下，埋点库通过提供一个protocol由埋点impl类来实现，根据不同的逻辑判断，返回对应的埋点值

@protocol RJEventTracking <NSObject>

- (NSString *)trackingMethod:(NSString *)method instance:(id)instance arguments:(NSArray *)arguments;

@end

比如上文的rj_trip_tracking类需要遵循RJEventTracking协议，并根据相关逻辑判断返回对应的埋点值

埋点实现类的类名需要与埋点配置JSON中的event里的key保持一致，因为埋点库会通过检测是否有同名的类来实现插件式的埋点规则。另外，一个impl可以对应多个method方法

状态判断

根据状态量来确定埋点值。还是联系客服埋点的例子，根据订单种类和订单状态来返回对应的埋点值，首先定义JSON表中同名的impl类，并遵循RJEventTracking协议

#import "RJEventTracking.h"
 
NS_ASSUME_NONNULL_BEGIN
 
@interface rj_trip_tracking : NSObject <RJEventTracking>
 
@end
 
NS_ASSUME_NONNULL_END

在.m文件中实现自定义埋点的协议方法trackingMethod:instance:arguments:

#import "rj_trip_tracking.h"
 
@implementation rj_trip_tracking
 
- (NSString *)trackingMethod:(NSString *)method instance:(id)instance arguments:(NSArray *)arguments {
    id dataManager        = [instance property:@"dataManager"];
    NSInteger orderStatus = [[dataManager property:@"orderStatus"] integerValue];
    NSInteger orderType   = [[dataManager property:@"orderType"] integerValue];
 
    if ([method isEqualToString:@"callServiceEvent"]) {
        if (orderType == 1) {       
            if (orderStatus == 1) { 
                return @"user_inbook_psgservice_click";
            } else if (orderStatus == 2) {
                return @"user_finishbook_psgservice_click";
            }
        } else {
            return @"user_psgservice_click";
        }
    }
    return nil;
}
 
@end

在协议方法中，可以获取当前的实例（在这个示例下为RJTripViewController）和入参数组。订单的类型和状态是存储在RJTripViewController中的dataManager属性中的，所以可以通过埋点库封装好的property:方法来获取属性值，并根据属性值返回对应的埋点名称

@interface NSObject (RJEventTracking)
 
- (id)property:(NSString *)property;
 
@end

属性值读取的实现为

- (id)property:(NSString *)property {
    return [NSObject runMethodWithObject:self selector:property arguments:nil];
}

其中的原理很简单，就是将getter方法封装到NSInvocation中并invoke读取返回值即可

+ (id)runMethodWithObject:(id)object selector:(NSString *)selector arguments:(NSArray *)arguments {
    if (!object) return nil;
    
    if (arguments && [arguments isKindOfClass:NSArray.class] == NO) {
        arguments = @[arguments];
    }
    SEL sel = NSSelectorFromString(selector);
        
    NSMethodSignature *signature = [object methodSignatureForSelector:sel];
    if (!signature) {
        return nil;
    }
    NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:signature];
    invocation.selector      = sel;
    invocation.arguments     = arguments;
    [invocation invokeWithTarget:object];
    
    return invocation.returnValue_obj;
}

入参判断

需要根据JSON中设置的所hook方法的入参来确定埋点名称的情况。比如在订单列表中点击全部，进行中，待支付，待评价，已完成等菜单项时分别埋点。被hook的方法为tripLabClickWithLabKey:其参数为UILabel，原先代码中通过Label的tag判断是点击的哪个子项，同样，我们也可以获取到Label的入参然后据此判断。由于参数只有一个，所以可以直接取arguments第一个值

#import "rj_main_tracking.h"
#import <UIKit/UIKit.h>
 
static NSString *order_types[5] = { @"user_order_all_click",   @"user_order_ongoing_click",
                                    @"user_order_unpay_click", @"user_order_unmark_click",
                                    @"user_order_finish_click" };
@implementation rj_main_tracking
 
- (NSString *)trackingMethod:(NSString *)method instance:(id)instance arguments:(NSArray *)arguments {
    if ([method isEqualToString:@"tripLabClickWithLabKey:"]) {
        UILabel *label = arguments[0];
        if (!label || label.tag > 4) {
            return nil;
        }
        return order_types[label.tag];
    } else if ([method isEqualToString:@"tripTypeViewChangedWithIndex:"]) {
        return @"xx_ryan_jin";
    }
}
 
@end

通过AOP来hook方法时，可以获取到当前hook方法所对应的实例对象和入参，在调用协议方法时，直接传给协议实现类

方法调用

和读取属性值类似，也是在不同场景下同一事件不同埋点名称的情况，但获取的状态量不是当前实例对象的，而是某个方法的返回值，这种情况下可以通过埋点库提供的方法调用函数来实现

@interface NSObject (RJEventTracking)
 
- (id)performSelector:(NSString *)selector arguments:(nullable NSArray *)arguments;
 
@end

比如获取某个页面的视图类型，而这个视图类型存储于单例对象中

[RJViewTypeModel sharedInstance].viewType

该场景下则根据viewType的类型，来返回相应的埋点名称

- (NSString *)trackingMethod:(NSString *)method instance:(id)instance arguments:(NSArray *)arguments {
    NSString *labKey   = [instance property:@"labKey"];
    id viewTypeModel   = [NSClassFromString(@"RJViewTypeModel") performSelector:@"sharedInstance"
                                                                      arguments:nil];
    NSInteger viewType = [[viewTypeModel property:@"viewType"] integerValue];
     
    if (viewType == 0) { 
        if ([labKey isEqualToString:@"rj_view_begin_add"]) {
            return @"user_fp_book_on_click";
        }
        if ([labKey isEqualToString:@"rj_view_end_add"]) {
            return @"user_fp_book_off_click";
        }
    }
    if (viewType == 1) { 
        if ([labKey isEqualToString:@"rj_view_begin_add"]) {
            return @"user_fr_on_click";
        }
        if ([labKey isEqualToString:@"rj_view_end_add"]) {
            return @"user_fr_off_click";
        }
    }
    return nil;
}

逻辑判断

需要额外添加逻辑判断的场景，比如在订单详情页需要统计用户进入页面的查看行为，但是详情页的类型需要在网络请求后才能获取，而且该网络请求会定时触发，所以埋点hook的方法会走多次，该情况下，需要添加一个属性用来标记是否已记录埋点 。故而埋点库需要提供动态添加属性的功能

@interface NSObject (RJEventTracking)
 
- (id)extraProperty:(NSString *)property;
 
- (void)addExtraProperty:(NSString *)property defaultValue:(id)value;
 
@end

在埋点实现impl类里面，添加额外的属性来标记是否已记录过埋点

@implementation user_orderdetail_show
 
- (NSString *)trackingMethod:(NSString *)method instance:(id)instance arguments:(NSArray *)arguments {
    if ([instance extraProperty:@"isRecorded"]) {
        return nil;
    }
    [instance addExtraProperty:@"isRecorded" defaultValue:@(YES)];
     
    return @"user_orderdetail_show";
}
 
@end

使用addExtraProperty:defaultValue:来给当前实例动态添加属性，而extraProperty:方法则用来获取实例的某个额外属性。如果isRecorded返回YES代表已经记录过该埋点，返回nil值来忽略该次埋点

上面示例中添加的isRecorded属性是因为埋点的需求，和业务逻辑无关，所以比较合理的方式是在埋点的插件impl类中添加，避免影响业务代码

埋点库动态添加属性的原理也很简单，利用runtime的objc_setAssociatedObject和objc_getAssociatedObject方法来绑定属性到实例对象

- (id)extraProperty:(NSString *)property {
    return objc_getAssociatedObject(self, NSSelectorFromString(property));
}

- (void)addExtraProperty:(NSString *)property defaultValue:(id)value {
    objc_setAssociatedObject(self, NSSelectorFromString(property), value, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

动态下发

埋点JSON配置表可以由服务器提供接口，客户端在每次启动时通过接口获取最新埋点配置表，从而达到动态下发的目的，客户端拿到JSON后，读取埋点信息并生效

[RJEventTracking loadConfiguration:[[NSBundle mainBundle] pathForResource:@"RJUserTracking" ofType:@"json"]];

读取的代码如下所示，主要逻辑为遍历埋点中的类和hook的方法，并检测是固定埋点还是场景化埋点，对于场景化埋点的情况查询是否有对应的埋点impl实现类。当然，还需检测JSON配置表的合法性，每个类和其中的方法是否匹配

+ (void)loadConfiguration:(NSString *)path {
    NSData *data = [NSData dataWithContentsOfFile:path];
    if (!data) {
        return;
    }
    NSDictionary *dict = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableLeaves error:nil];
    NSString *version  = dict[@"version"];
    NSArray *ts        = dict[@"tracking"];
    [ts enumerateObjectsUsingBlock:^(NSDictionary *obj, NSUInteger idx, BOOL *stop) {
        Class class              = NSClassFromString(obj[@"class"]);
        NSDictionary *ed         = obj[@"event"];
        NSMutableDictionary *td  = [NSMutableDictionary dictionaryWithCapacity:0];
        [ed enumerateKeysAndObjectsUsingBlock:^(NSString *key, id obj, BOOL *stop) {
            NSMutableArray *tArr = [NSMutableArray arrayWithCapacity:0];
            [tArr addObjectsFromArray:[obj isKindOfClass:[NSArray class]] ? obj : @[obj]];
            [tArr enumerateObjectsUsingBlock:^(NSString *m, NSUInteger idx, BOOL *stop) {
                if ([td.allKeys containsObject:m]) {
                    NSMutableArray *ms         = [td[m] mutableCopy];
                    if (![ms containsObject:key]) [ms addObject:key];
                    td[m] = ms;
                } else {
                    td[m] = @[key];
                }
            }];
        }];
        [td enumerateKeysAndObjectsUsingBlock:^(NSString *kmethod, NSArray <NSString *> *tArr, BOOL *stop) {
            SEL sel        = NSSelectorFromString(kmethod);
            NSError *error = nil;
            [self checkValidWithClass:obj[@"class"] method:kmethod];
            [class aspect_hookSelector:sel withOptions:AspectPositionBefore usingBlock:^(id<AspectInfo> info) {
                [tArr enumerateObjectsUsingBlock:^(NSString *name, NSUInteger idx, BOOL *stop) {
                    NSString *ename       = name;
                    id<RJEventTracking> t = [NSClassFromString(name) new];
                    if (t && [t respondsToSelector:@selector(trackingMethod:instance:arguments:)]) {
                        ename = [t trackingMethod:kmethod instance:info.instance
                                                         arguments:info.arguments];
                    }
                    if ([ename length]) {
                        NSLog(@"<RJEventTracking> - %@", ename);
                    }
                }];
            } error:&error];
            [self checkHookStatusWithClass:obj[@"class"] method:kmethod error:error];
        }];
    }];
}

最后附上源码地址: https://github.com/rjinxx/RJEventTracking,

pod 'RJEventTracking'

在使用RJEventTracking的过程中中有遇到什么问题或者优化建议欢迎留言PR，谢谢。

转自：https://www.jianshu.com/p/cdf61602316e

因为项目有个界面要模仿高德地图路径规划滑动效果，因此写了demo，并简单说下分析过程

高德地图效果演示:

demo效果演示:

Demo地址:https://github.com/fangjinfeng/MySampleCode/tree/master/FJFBlogProjectDemo

一. 分析

• 首先，我们可以看出这个滚动的视图应该是UIScrollView或者UIScrollView的子类(比如:UITableView);

• 其次，从高德地图里的视图一开始的滑动，可以看出这个滑动是平稳的滑动，没有加速和减速，因此这里不可能是UIScrollView的滚动效果，因为UIScrollView的滚动效果是由一个加减速的过程，因此一开始滑动，应该是通过滑动手势UIPanGestureRecognizer，来移动UIScrollView的y值来移动

• 接着滑动到指定位置之后，UIScrollView的y值固定不动，然后UIScrollView的内容进行滚动。这里就涉及到滑动手势UIPanGestureRecognizer的滑动，还有UIScrollView内部的滚动的处理。高德地图的演示效果里面，一开始滑动视图向上移动，移动到指定的点之后，立马就变成视图的滚动，这里可以分析，UIScrollView既支持手势的滑动又支持视图的滚动，只是通过条件来判断限制两者的执行逻辑。

• 同时我们可以看到，如果一开始向上拉动视图力度大一点，视图会直接滚动到指定位置，如果力度小，就恢复到原来位置，因此这里需要依据手势滑动的加速度来进行判断处理。

• 而当你滑动到中间位置的时候，也需要依据最后滑动的位置来判断应该动画滚动到上方还是下方。

• 最后滑动的时候上方的视图和滑动视图本身有背景颜色的渐变效果，这里需要依据滑动距离来判断。

二.代码分析:

首先由于滚动视图(demo里面是UITableView)需要支持手势滑动和内部滚动，因此需要写一个类FJBaseTableView继承自UITableView，然后在FJBaseTableView的实现里面重写如下方法：

// 当有 多个手势 都可以 响应
- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer {

    return YES;
}

来支持响应多个手势。

• 然后给滚动视图tableView添加滑动手势，当tableView从底部滑动到顶部指定位置时，应该限制tableView内部的视图滚动。

- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
    if (self.tableView.frame.origin.y > _scrollViewStartPositionY) {
        [scrollView setContentOffset:CGPointMake(0, 0)];
    }
}

这里的_scrollViewStartPositionY是顶部指定位置。

• 接着看下手势滑动的处理逻辑:

#pragma mark - 手势处理
- (void)handlePanGesture:(UIPanGestureRecognizer *)sender {
    
    if (sender.state == UIGestureRecognizerStateBegan) {
        
        _beganPoint = [sender locationInView:sender.view.superview];
        _curPoint = sender.view.center;
        _topTipContainerViewCurrentY = _topContainerView.frame.origin.y;
        _previousOffsetY = self.tableView.contentOffset.y;
        
    } else if(sender.state == UIGestureRecognizerStateChanged) {
        
        CGPoint point = [sender locationInView:sender.view.superview];
        
        CGFloat offsetY = _previousOffsetY - self.tableView.contentOffset.y;
        NSInteger y_offset = point.y - _beganPoint.y - offsetY;
        
        if (sender.view.frame.origin.y >= _scrollViewStartPositionY || (self.tableView.contentOffset.y == 0 && self.tableView.contentSize.height > self.tableView.frame.size.height)) {
            sender.view.center = CGPointMake(_curPoint.x, _curPoint.y + y_offset);
            [self updateViewControlsWithSlideOffset:y_offset];
        }
        
        if (sender.view.frame.origin.y > _scrollViewLimitMaxY) {
            sender.view.y = _scrollViewLimitMaxY;
            [self updateViewControlsWithSlideUp:NO];
        }
        else if(sender.view.frame.origin.y < _scrollViewStartPositionY) {
            
            sender.view.y = _scrollViewStartPositionY;
             [self updateViewControlsWithSlideUp:YES];
        }
    } else if(sender.state == UIGestureRecognizerStateEnded) {
        
        if (sender.view.frame.origin.y <= _scrollViewStartPositionY || sender.view.frame.origin.y > _scrollViewLimitMaxY) {
            if (sender.view.frame.origin.y <= _scrollViewStartPositionY) {
                [self updateViewControlsWithSlideUp:YES];
            }
            if (sender.view.frame.origin.y > _scrollViewLimitMaxY) {
                [self updateViewControlsWithSlideUp:NO];
            }
            return;
        }
        // 滑动速度处理
        CGPoint velocity = [sender velocityInView:self.view];
        CGFloat speed = 350;
        if (velocity.y < - speed) {
            // 快速向上
            [self tableViewMoveToTop];
            return;
        } else if (velocity.y > speed) {
            // 快速向下
            [self tableViewMoveToBottom];
            return;
        }
        
        // 滑动临界值
        CGFloat criticalValue = _scrollViewLimitMaxY/2.0;
        if (sender.view.frame.origin.y <= criticalValue) {
            [self tableViewMoveToTop];
        } else {
            [self tableViewMoveToBottom];
        }
    }
}

这里几个点需要注意:

1. _beganPoint、_curPoint两个参数是用来计算手势滑动距离然后调整scrollView的滑动距离。而_previousOffsetY是用来记录滑动之前tableView的内部视图的偏移距离，因为当tableView滑动到顶部指定位置后，tableView开始滚动，这时候tableView向下滑动是先移动了tableView内部的滚动距离，然后才是滑动距离，因此需要将这部分值先记录，然后去除掉，才是tableView向下真正需要滑动的距离。

CGFloat offsetY = _previousOffsetY - self.tableView.contentOffset.y;
 NSInteger y_offset = point.y - _beganPoint.y - offsetY;

2.滑动过程中，顶部视图的移动和渐变处理,这里先依据滑动的距离算出tableView滑动距离与tableView最大滑动距离的比值，然后再算出顶部视图需要移动的距离和背景的透明度。

- (void)updateViewControlsWhenSliding {
    if (self.tableView.frame.origin.y > _scrollViewStartPositionY && self.tableView.frame.origin.y < _scrollViewLimitMaxY) {
        
        CGFloat offsetLimitDistance = _scrollViewLimitMaxY - _scrollViewStartPositionY;
        CGFloat offsetDistance = self.tableView.frame.origin.y - _scrollViewStartPositionY;
        if (offsetDistance > 0 && offsetDistance < offsetLimitDistance) {
            CGFloat topViewHeight = [FJFTopContainerView viewHeight];
            CGFloat topViewHeightOffset =  offsetDistance * (topViewHeight / offsetLimitDistance);
            CGFloat viewAlpha = offsetDistance / offsetLimitDistance;
            _topContainerView.y = topViewHeightOffset - topViewHeight;
            _topContainerView.alpha = viewAlpha;       
         }
    }
}

3.滑动速度处理，依据velocityInView函数获取速度值，然后依据当前速度值大小和正负和设定的速度值比较来判断是否需要向上或向下移动。

// 滑动速度处理
CGPoint velocity = [sender velocityInView:self.view];
CGFloat speed = 350;
if (velocity.y < - speed) {
     // 快速向上
      [self tableViewMoveToTop];
      return;
} else if (velocity.y > speed) {
    // 快速向下
    [self tableViewMoveToBottom];
    return;
 }

4.滑动临界值处理，判断最后滑动位置与底部指定位置一半，两个值的大小来判断滑动的方向。

// 滑动临界值
CGFloat criticalValue = _scrollViewLimitMaxY/2.0;
if (sender.view.frame.origin.y <= criticalValue) {
    [self tableViewMoveToTop];
} else {
    [self tableViewMoveToBottom];
 }

三.总结

这里最主要就是介绍了分析的思路，来找出可靠的实现方法，具体逻辑，详见demo

转自：https://www.jianshu.com/p/14dd820393fa

用法

1. 在Application中进行初始化

public class SkinApplication extends Application {

	public void onCreate() {

		super.onCreate();

		// Must call init first 

		SkinManager.getInstance().init(this);

		SkinManager.getInstance().load();

	}

}

2. 在布局文件中标识需要换肤的View

...

xmlns:skin="http://schemas.android.com/android/skin"

...

  <TextView

     ...

     skin:enable="true" 

     ... />

3. 继承BaseActivity或者BaseFragmentActivity作为BaseActivity进行开发

4. 从.skin文件中设置皮肤

String SKIN_NAME = "BlackFantacy.skin";

String SKIN_DIR = Environment.getExternalStorageDirectory() + File.separator + SKIN_NAME;

File skin = new File(SKIN_DIR);

SkinManager.getInstance().load(skin.getAbsolutePath(),

				new ILoaderListener() {

					@Override

					public void onStart() {

					}



					@Override

					public void onSuccess() {

					}



					@Override

					public void onFailed() {

					}

				});

5. 重设默认皮肤

SkinManager.getInstance().restoreDefaultTheme();

6. 对代码中创建的View的换肤支持

主要由IDynamicNewView接口实现该功能，在BaseActivity，BaseFragmentActivity和BaseFragment中已经实现该接口.

public interface IDynamicNewView {

	void dynamicAddView(View view, List<DynamicAttr> pDAttrs);

}

**用法：**动态创建View后，调用dynamicAddView方法注册该View至皮肤映射表即可(如下).详见sample工程

	private void dynamicAddTitleView() {

		TextView textView = new TextView(getActivity());

		textView.setText("Small Article (动态new的View)");

		RelativeLayout.LayoutParams param = new RelativeLayout.LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);

		param.addRule(RelativeLayout.CENTER_IN_PARENT);

		textView.setLayoutParams(param);

		textView.setTextColor(getActivity().getResources().getColor(R.color.color_title_bar_text));

		textView.setTextSize(20);

		titleBarLayout.addView(textView);

		

		List<DynamicAttr> mDynamicAttr = new ArrayList<DynamicAttr>();

		mDynamicAttr.add(new DynamicAttr(AttrFactory.TEXT_COLOR, R.color.color_title_bar_text));

		dynamicAddView(textView, mDynamicAttr);

	}

7. 皮肤包是什么？如何生成？

• 皮肤包（后缀名为.skin）的本质是一个apk文件，该apk文件不包含代码，只包含资源文件
• 在皮肤包工程中（示例工程为skin/BlackFantacy）添加需要换肤的同名的资源文件，直接编译生成apk文件，再更改后缀名为.skinj即可（防止用户点击安装）
• 使用gradle的同学，buildandroid-skin-loader-skin工程后即可在skin-package目录下取皮肤包（修改脚本中def skinName = "BlackFantacy.skin"换成自己想要的皮肤名）

代码下载:Android-Skin-Loader-master.zip

一.渲染机制

CPU将计算好的需要显示的内容提交给GPU，GPU渲染完成后将渲染结果放入帧缓冲区，随后视频控制器会按照Vsync(垂直脉冲)信号逐行读取帧缓冲区的数据，经过可能的数模转换传递给显示器进行显示。

二.GPU屏幕渲染两种方式

1.On-Screen Rendering:当前屏幕渲染

指GPU的渲染操作是在当前用于显示的屏幕缓冲区中进行。

2.Off-Screen Rendering:离屏渲染

指GPU在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作。

三.两种渲染方式比较

相比于当前屏幕渲染，离屏渲染的代价很高，主要体现在以下两个方面:

1.创建新缓冲区

要想进行离屏渲染，首先需要创建一个新的缓冲区。

2.上下文切换

离屏渲染的整个过程，需要多次进行上下文切换：先从当前屏幕(On-Screen)到离屏(Off-Screen);等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕。而上下文环境的切换回导致GPU产生空闲，而GPU拥有大量的并行计算的处理单元，这些处理单元都空闲，会产生巨大的浪费。

四.特殊的离屏渲染:CPU渲染

如果重写了drawRect方法，并且使用任何Core Graphics 的技术进行了绘制操作，就涉及到CPU渲染。整个渲染过程由CPU在App内同步完成，渲染得到的bitmap(位图)最后再交由GPU用于显示。

CoreGraphic通常是线程安全的，所以可以进行一步绘制，显示的时候再回主线程，一个简单异步绘制内容如下:

- (void)display {
   dispatch_async(backgroundQueue, ^{
       CGContextRef ctx = CGBitmapContextCreate(...);
       // draw in context...
       CGImageRef img = CGBitmapContextCreateImage(ctx);
       CFRelease(ctx);
       dispatch_async(mainQueue, ^{
           layer.contents = img;
       });
   });
}

五.为什么产生离屏渲染

离屏渲染产生的原因主要有两方面:

1.在VSync(垂直脉冲)信号作用下，视频控制器每隔16.67ms就会去帧缓冲区(当前屏幕缓冲区)读取渲染后的数据；但是有些效果被认为不能直接呈现于屏幕前，而需要在别的地方做额外的处理，进行预合成。

比如图层属性的混合体再没有预合成之前不能直接在屏幕中绘制，所以就需要屏幕外渲染。屏幕外渲染并不意味着软件绘制，但是它意味着图层必须在被显示之前必须在一个屏幕外上下文中被渲染（不论CPU还是GPU）。

举个🌰：

UIView *AView = [[UIView alloc] initWithFrame:CGRectMake(100, 100, 200, 200)];
AView.backgroundColor = [UIColor redColor];
AView.alpha = 0.5;
[self.view addSubview:AView];
    
UIView *BView = [[UIView alloc] initWithFrame:CGRectMake(50, 50, 100, 100)];
BView.backgroundColor = [UIColor blackColor];
BView.alpha = 0.5;
[AView addSubview:BView];

效果图:

如上代码所示:

AView 视图包含BView视图，AView视图是红色，透明度为0.5；BView视图为黑色，透明度也为0.5，那么在渲染阶段，就会对AView和BView图层重叠的部分进行混合操作，但是这个过程并不适合直接显示在屏幕上，因此需要开辟屏幕外的缓存，对这两个图层进行屏幕外的渲染，然后将渲染的结果写回到当前屏幕缓存区。

这里有些人会有疑问，那如果能保证图层在16.67ms里完成渲染，视频控制器去读取的时候能读取到渲染完成的数据，不就可以了。

理论上，确实可以这样理解，但是图层之间的混合、渲染这个过程所耗费的时间是不固定的，跟多个维度相关，比如图层数量、重叠区域、GPU处理器性能等，因此底层设计的时候，应该是将不能够直接呈现在屏幕上的效果，都通过离屏渲染来操作。

2.有些视图渲染后的纹理需要被多次复用，但屏幕内的渲染缓冲区是实时更新的，所以需要通过开辟屏幕外的渲染缓冲区，将视图的内容渲染成纹理并缓存，然后再需要的时候在调入屏幕缓冲区，可以避免多次渲染的开销。

典型的例子就是光栅化。光栅化就是通过把视图的内容渲染成纹理并缓存，等到下次调用的时候直接去缓存的取出纹理，但是更新内容时候，会启用离屏渲染，所以更新的代价比较大，只能用于静态内容；而且如果光栅化的元素100ms没有被使用，也将被移除，故而不常用元素的光栅化并不会优化显示。

注意：光栅化的元素，总大小限制为2.5倍的屏幕。

六.如何检测离屏渲染

1.模拟器

模拟器在工作栏上面的Debug -> Color Off-Screen Rendered

2.真机

真机在工作栏上面的Debug -> View Debugging -> Rendering -> Color Off-Screen Rendered Yellow

七.引起离屏渲染操作和怎样优化

关于这方面的资料，可以参考文章：

离屏渲染优化详解：实例示范+性能测试

iOS-离屏渲染详解

如果想更深入的了解，可以了解下OpenGL、Metal、计算机图形学这方面的知识。

八.延伸阅读

离屏渲染优化详解：实例示范+性能测试

iOS-离屏渲染详解

Metal【1】—— 概述

iOS开发-视图渲染与性能优化

链接：https://www.jianshu.com/p/aa8dc1a61c91

毫无疑问，协议是SWIFT总体设计的主要部分-并且可以提供一种很好的方法来创建抽象、分离关注点和提高系统或功能的整体灵活性。通过不强烈地将类型绑定在一起，而是通过更抽象的接口连接代码库的各个部分，我们通常会得到一个更加解耦的体系结构，它允许我们孤立地迭代每个单独的特性。

然而，虽然协议在许多不同的情况下都是一个很好的工具，但它们也有各自的缺点和权衡。本周，让我们来看看其中的一些特性，并探索几种在SWIFT中抽象代码的替代方法-看看它们与使用协议相比如何。

使用闭包的单个需求

使用协议抽象代码的优点之一是它允许我们对多个代码进行分组。所需在一起。例如，PersistedValue协议可能需要两个save和一个load方法-这两种方法都使我们能够在所有这些值之间强制执行一定程度的一致性，并编写用于保存和加载数据的共享实用程序。

然而，并不是所有的抽象都涉及多个需求，并且非常常见的协议只有一个方法或属性-比如这个：

protocol ModelProvider {
    associatedtype Model: ModelProtocol
    func provideModel() -> Model
}

假设上面的ModelProvider协议用于抽象我们在代码库中加载和提供模型的方式。它使用关联类型，以便让每个实现以非常类型安全的方式声明它提供的模型类型，这是很棒的，因为它使我们能够编写通用代码来执行常见任务，例如为给定模型呈现详细视图：

class DetailViewController<Model: ModelProtocol>: UIViewController {
    private let modelProvider: AnyModelProvider<Model>

    init<T: ModelProvider>(modelProvider: T) where T.Model == Model {
        // We wrap the injected provider in an AnyModelProvider
        // instance to be able to store a reference to it.
        self.modelProvider = AnyModelProvider(modelProvider)
        super.init(nibName: nil, bundle: nil)
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()

        let model = modelProvider.provideModel()
        ...
    }
    
    ...
}

虽然上面的代码可以工作，但它说明了使用具有关联类型的协议的缺点之一-我们不能将引用存储到ModelProvider直接。相反，我们必须首先执行类型擦除将我们的协议引用转换成一个具体的类型，这两种类型都会使我们的代码混乱，并要求我们实现其他类型，以便能够使用我们的协议。

因为我们所处理的协议只有一个要求，所以问题是-我们真的需要吗？毕竟，我们ModelProvider协议没有添加任何额外的分组或结构，因此让我们取消它的唯一要求，将其转化为闭包-然后可以直接注入，如下所示：

class DetailViewController<Model: ModelProtocol>: UIViewController {
    private let modelProvider: () -> Model

    init(modelProvider: @escaping () -> Model) {
        self.modelProvider = modelProvider
        super.init(nibName: nil, bundle: nil)
    }

    override func viewDidLoad() {
        super.viewDidLoad()

        let model = modelProvider()
        ...
    }
    
    ...
}

通过直接注入我们需要的功能，而不是要求类型符合协议，我们还大大提高了代码的灵活性-因为我们现在可以自由地注入任何东西，从空闲函数到内联定义的闭包，再到实例方法。我们也不再需要执行任何类型删除，留给我们的代码要简单得多。

使用泛型类型

虽然闭包和函数是建模单个需求抽象的好方法，但是如果我们开始添加额外的需求，那么使用它们可能会变得有点混乱。例如，假设我们希望扩展上面的内容DetailViewController也支持书签和删除模型。如果我们坚持基于闭包的方法，我们最终会得到这样的结果：

class DetailViewController<Model: ModelProtocol>: UIViewController {
    private let modelProvider: () -> Model
    private let modelBookmarker: (Model) -> Void
    private let modelDeleter: (Model) -> Void

    init(modelProvider: @escaping () -> Model,
         modelBookmarker: @escaping (Model) -> Void,
         modelDeleter: @escaping (Model) -> Void) {
        self.modelProvider = modelProvider
        self.modelBookmarker = modelBookmarker
        self.modelDeleter = modelDeleter
        
        super.init(nibName: nil, bundle: nil)
    }
    
    ...
}

上述设置不仅要求我们跟踪多个独立闭包，而且还会出现大量重复的闭包。“模型”前缀-(使用“三人规则”)告诉我们，我们这里有一些结构性问题。而我们能回到将上述所有闭包封装到一个协议中去，这再次要求我们执行类型擦除，并失去我们在开始使用闭包时获得的一些灵活性。

相反，让我们使用泛型类型将我们的需求组合在一起-这两种类型都允许我们保留使用闭包的灵活性，同时在代码中添加一些额外的结构：

struct ModelHandling<Model: ModelProtocol> {
    var provide: () -> Model
    var bookmark: (Model) -> Void
    var delete: (Model) -> Void
}

因为上面是一个具体的类型，所以它不需要任何形式的类型擦除(实际上，它看起来非常类似于我们在使用带关联类型的协议时经常被迫编写的类型擦除包装)。因此，就像闭包一样，它可以直接使用和存储-如下所示：

class DetailViewController<Model: ModelProtocol>: UIViewController {
    private let modelHandler: ModelHandling<Model>
    private lazy var model = modelHandler.provide()

    init(modelHandler: ModelHandling<Model>) {
        self.modelHandler = modelHandler
        super.init(nibName: nil, bundle: nil)
    }

    @objc private func bookmarkButtonTapped() {
        modelHandler.bookmark(model)
    }
    
    @objc private func deleteButtonTapped() {
        modelHandler.delete(model)
        dismiss(animated: true)
    }
    
    ...
}

而具有关联类型的协议在定义更高级别的需求时非常有用(就像标准库的Equatable和Collection)，当这样的协议需要直接使用时，使用独立闭包或泛型类型通常可以给我们相同的封装级别，但通过一个简单得多的抽象。

使用枚举分离要求

在设计任何类型的抽象时，一个常见的挑战是不要。“过于抽象”通过添加太多的需求。例如，现在假设我们正在开发一个应用程序，它允许用户使用多种媒体-比如文章、播客、视频等等-我们希望为所有这些不同的格式创建一个共享的抽象。如果我们再次从面向协议的方法开始，我们可能会得到这样的结果：

protocol Media {
    var id: UUID { get }
    var title: String { get }
    var description: String { get }
    var text: String? { get }
    var url: URL? { get }
    var duration: TimeInterval? { get }
    var resolution: Resolution? { get }
}

由于上面的协议需要与所有不同类型的媒体一起工作，我们最终得到了多个仅与某些格式相关的属性。例如，Article类型没有任何概念持续时间或分辨力-留给我们一些我们必须实现的属性，因为我们的协议要求我们：

struct Article: Media {
    let id: UUID
    var title: String
    var description: String
    var text: String?
    var url: URL? { return nil }
    var duration: TimeInterval? { return nil }
    var resolution: Resolution? { return nil }
}

上面的设置不仅要求我们在符合标准的类型中添加不必要的样板，还可能是歧义的来源-因为我们无法强制规定一篇文章实际上包含文本，或者应该支持URL、持续时间或解析的类型实际上携带了该数据-因为所有这些属性都是选项。

我们可以通过多种方法解决上述问题，从将协议拆分为多个协议开始，每个方法都具有提高专业化程度-像这样：

protocol Media {
    var id: UUID { get }
    var title: String { get }
    var description: String { get }
}

protocol ReadableMedia: Media {
    var text: String { get }
}

protocol PlayableMedia: Media {
    var url: URL { get }
    var duration: TimeInterval { get }
    var resolution: Resolution? { get }
}

以上所述无疑是一种改进，因为它将使我们能够拥有以下类型Article符合ReadableMedia，和可玩类型(如Audio和Video)符合PlayableMedia-减少歧义和样板，因为每种类型都可以选择哪一种专门版本的Media它想要遵守的。

但是，由于上述协议都是关于数据的，因此使用实际数据类型相反，这既可以减少重复实现的需要，也可以让我们通过单一的具体类型来处理任何媒体格式：

struct Media {
    let id: UUID
    var title: String
    var description: String
    var content: Content
}

上面的结构现在只包含我们所有媒体格式之间共享的数据，除了content属性-这就是我们将用于专门化的内容。但这一次，而不是Content一个协议，让我们使用枚举-它将使我们能够通过关联的值为每种格式定义一组量身定做的属性：

extension Media {
    enum Content {
        case article(text: String)
        case audio(Playable)
        case video(Playable, resolution: Resolution)
    }
    
    struct Playable {
        var url: URL
        var duration: TimeInterval
    }
}

选项已经消失，我们现在已经在共享抽象和启用特定于格式的专门化之间取得了很好的平衡。枚举的美妙之处还在于，它使我们能够表达数据变化，而不必使用泛型或协议-只要我们预先知道变体的数量，一切都可以封装在相同的具体类型中。

类和继承

另一种方法在SWIFT中可能不像在其他语言中那么流行，但仍然值得考虑，那就是使用通过继承专门化的类来创建抽象。例如，而不是使用Content为了实现上述媒体格式，我们可以使用Media基类，然后将其子类化，以添加特定于格式的属性，如下所示：

class Media {
    let id: UUID
    var title: String
    var description: String

    init(id: UUID, title: String, description: String) {
        self.id = id
        self.title = title
        self.description = description
    }
}

class PlayableMedia: Media {
    var url: URL
    var duration: TimeInterval

    init(id: UUID,
         title: String,
         description: String,
         url: URL,
         duration: TimeInterval) {
        self.url = url
        self.duration = duration
        super.init(id: id, title: title, description: description)
    }
}

然而，尽管从结构的角度来看，上述方法是完全有意义的-但它也有一些不利之处。首先，由于类还不支持按成员划分的初始化器，所以我们必须自己定义所有初始化器-我们还必须通过调用super.init..但也许更重要的是，课程是参考类型，这意味着在共享时，我们必须小心避免执行任何意外的突变。Media跨代码库的实例。

但这并不意味着SWIFT中没有有效的继承用例。例如，在“在未来的引擎盖下&斯威夫特的承诺”，继承提供了一种公开只读的好方法。Future类型到api用户-同时仍然允许通过Promise子类：

class Future<Value> {
    fileprivate var result: Result<Value, Error>? {
        didSet { result.map(report) }
    }
    
    ...
}

class Promise<Value>: Future<Value> {
    func resolve(with value: Value) {
        result = .success(value)
    }

    func reject(with error: Error) {
        result = .failure(error)
    }
}

func loadCachedData() -> Future<Data> {
    let promise = Promise<Data>()
    cache.load { promise.resolve(with: $0) }
    return promise
}

使用上面的设置，我们可以让同一个实例在不同的上下文中公开不同的API集，当我们只允许其中一个上下文对给定的对象进行变异时，这是非常有用的。在使用泛型代码时尤其如此，因为如果我们尝试使用一个协议来实现相同的目标，我们将再次遇到关联类型问题。

结语

在可预见的将来，协议是很棒的，并且很可能仍然是在SWIFT中定义抽象的最常用的方式。然而，这并不意味着使用协议永远是最好的解决方案-有时会超越流行的范围“面向协议的编程”MARRA可以产生更简单、更健壮的代码-特别是当我们想要定义的协议要求我们使用关联类型的时候。

链接：https://www.jianshu.com/p/74d511140089

ETH钱包部分：

功能有：

1、创建钱包

2、通过助记词导入钱包

3、通过KeyStore导入钱包

4、通过私钥导入钱包

5、查询余额

6、查询以太坊系代币余额

7、转账

BTC钱包部分：

功能：

1、创建钱包

2、通过私钥导入钱包

3、通过助记词导入钱包

4、查询余额

5、查询交易记录

6、发起交易

项目连接：

ETH钱包Demo：https://github.com/Ccct/CCTEthereum/

BTC钱包Demo：https://github.com/Ccct/CCTBTC

前言

此文源于前几日工作中遇到的一个问题，并跟同事就init方法进行了相关讨论。相关代码如下：

Person *myPerson = [Person alloc];
NSMethodSignature *signature = [NSMethodSignature signatureWithObjCTypes:"@16@0:8"];
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:signature];
invocation.target = myPerson;
invocation.selector = @selector(initPerson);
[invocation invoke];
__unsafe_unretained id retValue;
[invocation getReturnValue:&retValue];

正常来说，这段代码运行起来没有任何问题。然而，当Person的initPerson方法返回nil或者返回子类对象时，上述代码就会EXC_BAD_ACCESS。但如果我们把initPerson方法前缀改成其他（比如:createPerson），就不会crash。为了查清原因，便对init方法进行了一次探索（说探索多少有些夸张）。

通过符号断点及反汇编等调试手段，发现在initPerson方法结束的时候，person对象调用了一次release，而上述示例代码执行完，ARC为了抵消[Person alloc]这步操作，会对myPerson进行一次release。也就是说，过渡释放引起了crash。

那么接下来，我们就看下init方法结束的时候，为什么要调用那次看似多余的release？

原因分析

在clang文档中找到这么两个东西：__attribute__((ns_consumes_self))、__attribute((ns_returns_retained))。

据文档描述，前者的作用是将ownership从主调方转移到被调方；而后者的作用是把ownership从被调方转移到主调方。具体原理如下：

0x1. __attribute__((ns_consumes_self))

若某个方法被标记这个特性，调用方会在方法调用前对receiver进行一次retain(也可能会被编译器优化掉)，而被调方会在方法结束的时候对self进行一次release。比如下面代码

// 主调方
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
   Person *myPerson = [[Person alloc] init];
   [myPerson noninitPerson]; // 以非init方法来测试
   return YES;
}

// 被调方
@interface Person : NSObject
- (void)noninitPerson __attribute__((ns_consumes_self));
@end

@implementation Person
- (void)noninitPerson {
}
@end

通过Hopper反汇编，伪代码如下：

// 主调方
bool -[AppDelegate application:didFinishLaunchingWithOptions:](void * self, void * _cmd, void * arg2, void * arg3) {
    var_28 = [[Person alloc] init];
    rax = [var_28 retain]; // 调用前retain
    [rax noninitPerson];   // 开始调用
    objc_storeStrong(var_28, 0x0);
    return rax;
}

// 被调方
void -[Person noninitPerson](void * self, void * _cmd {
    objc_storeStrong(self, 0x0); // 调用完被调方负责release
    return;
}

而init开头的方法会被隐式地标记这个特性，文档中有描述：

The implicit self parameter of a method may be marked as consumed by adding __ attribute __((ns_consumes_self)) to the method declaration. Methods in theinitfamily are treated as if they were implicitly marked with this attribute.

0x2. __attribute__((ns_returns_retained))

若方法标记这个特性，表示主调方希望得到一个retainCount+1的对象，即被调方可能会进行一次retain将所有权移交给主调方，主调方会进行一次release(可能会被编译器优化掉)来负责释放。

伪代码如下：

// 主调方
var_28 = [[Person alloc] init];
rax = [var_28 running];
[rax release]; // 主调方负责释放

// 被调方
void * -[Person running](void * self, void * _cmd) {
    rax = [self retain]; // 若这里返回一个新分配的对象，则无需retain
    return rax;
}

同样地，init开头的方法也会被标记这个特性，文档里亦有体现：

Methods in the alloc, copy, init, mutableCopy, and new families are implicitly marked __ attribute __((ns_returns_retained)).

这么多的retain、release，多少有些凌乱，既然已知init方法会被标记__attribute__((ns_returns_retained))和__attribute__((ns_consumes_self))，那我们干脆看下init方法反汇编后的代码：

// 主调方
bool -[AppDelegate application:didFinishLaunchingWithOptions:](void * self, void * _cmd, void * arg2, void * arg3) {
    var_28 = [[Person alloc] init];
    objc_storeStrong(var_28, 0x0);
    // 优化掉了一对retain/release
    return rax;
}

// 被调方
void * -[Person init](void * self, void * _cmd) {
    // 忽略一些无关指令
    var_18 = [self retain]; // 对应__attribute__((ns_returns_retained))
    objc_storeStrong(self, 0x0); // 对应__attribute__((ns_consumes_self))
    rax = var_18;
    return rax;
}

到这里，我们基本了解了init方法原理，那么离文章开头那段代码crash又如何解释呢？我们对代码稍作修改，让init方法返回nil，再看下：

// 主调方
bool -[AppDelegate application:didFinishLaunchingWithOptions:](void * self, void * _cmd, void * arg2, void * arg3) {
    var_28 = [[Person alloc] init];
    objc_storeStrong(var_28, 0x0);
    return rax;
}

// 被调方
void * -[Person init](void * self, void * _cmd) {
    // 因为返回nil，所以这里的retain不存在了，而下面的self依然要消费掉
    objc_storeStrong(self, 0x0); // 对应__attribute__((ns_consumes_self))
    return 0x0;
}

至此，过度释放的原因也就清楚了，那么该怎么解决呢？

解决方案

回到文章开头，再看下代码，不难发现，我们只要模仿ARC在init方法调用前插入个retain，并在主调方快结束的时候再插入个release即可。

Person *myPerson = [Person alloc];
NSMethodSignature *signature = [NSMethodSignature signatureWithObjCTypes:"@16@0:8"];
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:signature];
invocation.target = myPerson;
invocation.selector = @selector(initPerson);
CFBridgingRetain(myPerson); // 代替ARC将owneship将传递给被调方
[invocation invoke];

__unsafe_unretained id retValue;
[invocation getReturnValue:&retValue];

CFBridgingRelease((__bridge CFTypeRef)retValue); // 代替ARC来释放ns_returns_retained结果

如果init方法返回nil，即retValue=nil，则CFBridgingRelease不会生效，上面插的那个CFBridgingRetain也就完美抵消掉了init方法结束时的release。

链接：https://www.jianshu.com/p/51adf5b44588

视频超过三十秒后再接受 无数据

Charles教程汇总

1.  简介

●    Charles，一款代理抓包工具，可以分析和排查网络相关的问题

●    支持移动（安卓、iOS）设备

●    以下使用文档，以安卓设备为准，iOS设置大同小异

2.  Charles安装

●    安装包官方下载：http://www.charlesproxy.com/documentation/

○    官方版为试用版，启动时有10s等待时间，每隔30min会提示关闭，重新打开后可以继续使用30min

3.  Charles代理配置使用

1)   打开Charles 

2)   查看本地IP

3)   手机连接WiFi（此WiFi需要和电脑在同一网段内，公司内直接连接cheetahmobile即可）

4)   设置手机代理

a)   长按cheetahmobile无线网络

b)   选择修改网络

c)   勾选高级选项，将代理设置为手动，填入步骤2获取的IP地址，代理服务器端口默认为8888

d)   手机中打开应用，产生网络请求，电脑端同意连接

e)   如在公司外使用，先将电脑未连接VPN之前的IP设置为手机的代理服务器地址，手机连接电脑之后

5）Access
Control

这个功能可以管理目前连接到你电脑上的设备（包括添加，删除，导入导出配置文件等，另外，Charles还提供了能够让所有设备无须询问直接连接电脑的方式：添加一个0.0.0.0/0的IP即可）

有时可能会遇到手机连接到电脑之后，无访问许可请求，此时可以去access
Control中手动进行添加

对Charles有大量使用需求的同学，时间久了之后，access
control里可能会有很多IP，建议大家在每次的测试开始前，清理IP池，将本次要测试的手机添加到自己的访问名单（使用Charles过程中，需要修改网络请求数据和host，如果不维护IP池，可能会干扰你自己或者别人的测试）

4.  修改默认的8888端口号

●    测试过程中，默认代理填入的端口号为8888，设备之间经常借调，会导致其他人依旧连接你的代理

●    可以手动修改默认的8888端口号

1)   打开设置面板

2)   修改默认的端口号保存即可

5.  设置本地（电脑端）不走Charles代理

●    本地走代理部分情况下会导致上网慢（如有针对情况下限速），且电脑端产生的请求较多，容易刷屏

1)   Proxy--Proxy
Setting… 

2)  
定位到Windows和Mozilla FireFox下

3)   将下方的复选框取消勾选后保存

4)   以后再次启动Charles后，电脑端的所有请求就不会被Charles抓包 

6.  设置关注的域名

●    抓包域名比较多情况下，容易刷屏，可以将需要测试的域名添加到关注列表，方便查看

1)   产生的网络请求中，选中后右键选择Focus

2)   再次产生改请求的情况下就会在前面，而未关注的域名就会被分配到Other
Hosts下

7.  域名重定向（A-->B）

●    测试过程中客，可能会将户端A域名的请求访问到B域名上

1)   找到需要重定向（A）的域名，右键选择Map Remote...

2)   填入对应域名的信息后保存（A-->B）

3)   客户端再次请求，下发的域名变为B

8.  域名重定向（A-->本地文件）

●    测试过程中，需要看客户端对服务端数据的容错，如果服务端没有给脏数据，则需要本地模拟脏数据

●    需要对一个字段进行多次校验工作，服务端配置麻烦可以采用本地方式

1)   将正常访问的域名的response数据，复制保存到本地（格式无所谓，txt、json都可以）

2)   选择域名，右键访问的链接，选择Map Local

3)   在Local Path路径中，将本地保存的数据选中

4)   客户端再次请求时，访问的数据即为本地数据

9.  查看已配置的重定向设置

●    查看和取消Map Local和Map Remote已经设置的重定向

1)   点击菜单中的Tools

2)   需要取消重定向设置，将已配置的数据删除或者选择Enable
Map Local开关即可

10. 设置限速

●    查看网络加载慢情况下，客户端的容错及反馈情况

1)   打开限速设置窗口

2)   限速可以针对选定的域名，也可以针对生效

3)   也可以参照Facebook开源的方案进行设置

a)   限速提供了通用的方案，比如Custom，3G等方案

b)   可以手动设置解决方案 

海外项目，建议参照Facebook的ATC解决方案来模拟

●    Facebook
ATC提供了将近10种类型的网络参数设置，包含了发达国家，发展中国家，郊区、市区等网络情况

11. https解密抓包

●    安全起见，公司部分域名采用了https的方式，https是加密，常规情况下无法抓到包请求

1)   开启Charles

2)   电脑端安装Charles证书

a)  
Help--SSL
Proxying--install Charles Root Certificate

b)   安装证书

c)   证书安装到“受新人的发布者”下

3)   手机端安装电脑证书

a)   手机访问域名：http://www.charlesproxy.com/getssl/

b)  
部分浏览器如果提示证书下载失败，就换个浏览器，目前QQ浏览器亲测有效

c)   安装证书，证书名字随便写

d)   安装证书需要设置锁屏密码

4)   安装成功后，Charles客户端开启对应的域名SSL

5)   设置对应域名的网络连接，https默认端口为443

6)   设置成功后，访问域名，即可查看解密后的请求状况

12. 重复请求

●    对于一些客户端不容易触发的请求，可以通过charles中repeat功能进行重复请求，简单方便

1)   选中请求的URL，右键选择Repeat

2)   即可查看请求的结果

13. 对接口进行压力测试

1)   选中要进行压测的接口，右键选择Repeat Advanced…

2)   填入重复执行的次数和并发数

a)   Itreations：循环次数

b)   Concurrency：并发次数

c)   Delays，请求与请求之间的间隔时间

●    并发代表是统一时间内请求多少次，比如设置循环6次，每次并发3条，则会分2次，每次并发3条去向服务端进行请求（需要注意的是，如果循环次数不是并发次数的整数倍，则不会触发所有的请求，如设置循环次数为10，并发条数为3，那么最终只会发起9次请求）

3)   查看测试结果

14. 修改请求参数之Edit

●    验证不同请求参数下，接口是否返回对应的数据

○    比如发魔方数据，限制了MCC为460以内的生效，那就可以改MCC为非460，看是否还能请求到对应的开关信息

1)   选中对应请求，选择Edit

2)   修改参数请求参数后点Execute

3)   重新请求后，请求参数中就包含了对应的参数

15. 修改请求参数之Rewrite 

●    客户端的云端开关，大多是通过魔方下发，不同的MCC，语言和aid会下发不同的数据，客户端如果要拉取不同的配置时，需要修改这些参数。修改MCC和aid还需要在root的设备上使用三方工具，随着Android版本的升级，部分参数甚至无法修改

●    广告和新闻的数据，会区分国际进行投放，有时甚至只会针对特定的国家（如印度新闻）投放，客户端为了测试这些功能，需要借助VPN或者debug版本

●    与MCC和aid修改器说再见

1)   打开Rewrite设置

2)   添加一条配置信息

a)   打开Enable Rewite功能开关

b)   添加一条配置信息

c)   Location中，添加域名的详细信息

3)   对域名添加对应的规则

a)  修改URL中的请求参数，比如MCC，aid等，Type选择：Modify
Query Param

b)  修改URL中的地域，比如添加某个国家的IP，Type选择：Add
Header

❖   举个栗子：

➢   例子1：客户端需要请求只针对MCC为310且aid尾号为1的用户下发的魔方云端配置

1.   配置魔方域名

2.   Type选择：Modify Query Param，并填写对应的参数

3.   打开开关，客户端再次发生请求

➢   例子2：客户端需求请求只针对印度IP下发的picks广告数据

1.   配置对应域名的数据

2.   新增一个请求参数

3.   再次请求对应链接

➢   例子3：客户端需要请求只针对英国IP下发的新闻数据

1.   配置对应域名的数据

2.   选择Type为Add Header

3.   客户端再去触发请求，抓包查看X-Forwarded-For已修改为2.101.8.8

16. session的操作

                    Charles支持同时打开多个session，但新发起的网络请求，只会在最后建议的session中进行记录

                    Charles还支持将session进行保存，在需要的时候可以将session作为Charles的日志提供给其他需要的人进行查看

17. 两种数据查看方式：structur和sequence

18. 复制和保存请求内容

            
1.     在某个请求上右键选择“copy
URL”，可以将本次请求的完整URL复制出来

            
2.     在某个请求上右键选择“copy
response”，可以将本次返回数据的完整内容复制出来

            
3.     在某个请求上右键选择“save
response”，可以将本次返回数据的完整内容以文件的形式保存在本地

19. 选择内容查看方式

            
1.     在某个请求上右键选择“view
response as”并进一步选择需要的数据查看方式（有时候返回的内容，Charles不能直接提供json的查看方式，可以用这个功能来强行查看josn格式）

            
2.     同理，可以在某个请求上右键选择“view
request as”并进一步选择需要的数据查看方式

     20.对添加ignore的域名取消忽略

            
1.     忽略对应的域名

            
2.     进入Proxy--Recording Settings，进入Exclude取消remove即可

// SomeViewController.m



- (void)fetchData {



    HHTCPSocketRequest *request = [HHTCPSocketRequest requestWithURL:aTCPUrl parameters:someParams header:someHeader];

    HHTCPSocketTask *task = [[HHTCPSocketClient sharedInstance] dataTaskWithRequest:request completionHandler:^(NSError *error, id result) {

        if (error) {

            //handle error

        } else {

            //handle result

        }

    }

    [task resume];

}

//HHTCPSocketClient.m



@interface HHTCPSocketClient()<HHTCPSocketDelegate>



@property (nonatomic, strong) HHTCPSocket *socket;



//任务派发表 以序列号为键保存所有已发出但还未收到响应的Request 待收到响应后再根据序列号一一分发

@property (nonatomic, strong) NSMutableDictionary<NSNumber *, HHTCPSocketTask *> *dispatchTable;



...其他逻辑 略

@end



@implementation HHTCPSocketClient



...其他逻辑 略



#pragma mark - Interface(Public)



//新建数据请求任务 调用方通过此接口定义Request的收到响应后的处理逻辑

- (HHTCPSocketTask *)dataTaskWithRequest:(HHTCPSocketRequest *)request completionHandler:(HHNetworkTaskCompletionHander)completionHandler {



    __block NSNumber *taskIdentifier;

    //1\. 根据Request新建Task

    HHTCPSocketTask *task = [HHTCPSocketTask taskWithRequest:request completionHandler:^(NSError *error, id result) {



        //4\. Request已收到响应 从派发表中删除

        dispatch_semaphore_wait(lock, DISPATCH_TIME_FOREVER);

        [self.dispatchTable removeObjectForKey:taskIdentifier];

        dispatch_semaphore_signal(lock);



        !completionHandler ?: completionHandler(error, result);

    }];

    //2\. 设置Task.client为HHTCPSocketClient 后续会通过Task.client向Socket中写入数据

    task.client = self;

    taskIdentifier = task.taskIdentifier;



    //3\. 将Task保存到派发表中

    dispatch_semaphore_wait(lock, DISPATCH_TIME_FOREVER);

    [self.dispatchTable setObject:task forKey:taskIdentifier];

    dispatch_semaphore_signal(lock);



    return task;

}



- (NSNumber *)dispatchTask:(HHTCPSocketTask *)task {

    if (task == nil) { return @-1; }



    [task resume];// 通过task.resume接口发起请求 task.resume会调用task.client.resumeTask方法 task.client就是HHTCPSocketClient

    return task.taskIdentifier;

}



#pragma mark - Interface(Friend)



//最终向Socket中写入Request.data的地方 此接口只提供给HHTCPSocketTask使用 对外不可见

- (void)resumeTask:(HHTCPSocketTask *)task {



    // 向Socket中写入Request格式化好的数据

    if (self.socket.isConnected) {

        [self.socket writeData:task.request.requestData];

    } else {



        NSError *error;

        if (self.isNetworkReachable) {

            error = HHError(HHNetworkErrorNotice, HHNetworkTaskErrorTimeOut);

        } else {

            error = HHError(HHNetworkErrorNotice, HHNetworkTaskErrorCannotConnectedToInternet);

        }

        [task completeWithResponseData:nil error:error];

    }

}



@end

//HHTCPSocketTask.m



@interface HHTCPSocketTask ()



- (void)setClient:(id)client;//此接口仅提供给上面的HHTCPSocketClient使用 对外不可见



@end



//对外接口 调用方通过通过此接口发起Request

- (void)resume {

    ...其他逻辑 略



    //通知client将task.request的数据写入Socket

    [self.client resumeTask:self];

}

//HHTCPSocketClient.m



@interface HHTCPSocketClient()<HHTCPSocketDelegate>



//保存所有收到的服务端数据 等待解析

@property (nonatomic, strong) NSMutableData *buffer;

...其他逻辑 略

@end



#pragma mark - HHTCPSocketDelegate



//从Socket从读取到数据

- (void)socket:(HHTCPSocket *)sock didReadData:(NSData *)data {

    [self.buffer appendData:data]; //1\. 保存读取到的二进制数据



    [self readBuffer];//2\. 根据协议解析二进制数据

}



#pragma mark - Parse



//递归截取Response报文 因为读取到的数据可能已经"粘包" 所以需要递归

- (void)readBuffer {

    if (self.isReading) { return; }



    self.isReading = YES;

    NSData *responseData = [self getParsedResponseData];//1\. 从已读取到的二进制中截取单个Response报文数据

    [self dispatchResponse:responseData];//2\. 将Response报文派发给对应的Task

    self.isReading = NO;



    if (responseData.length == 0) { return; }

    [self readBuffer]; //3\. 递归解析

}



//根据定义的协议从buffer中截取出单个Response报文

- (NSData *)getParsedResponseData {



    NSData *totalReceivedData = self.buffer;

    //1\. 每个Response报文必有的16个字节(url+serNum+respCode+contentLen)

    uint32_t responseHeaderLength = [HHTCPSocketResponseParser responseHeaderLength];

    if (totalReceivedData.length < responseHeaderLength) { return nil; }



    //2\. 根据定义的协议读取出Response.content的长度

    NSData *responseData;

    uint32_t responseContentLength = [HHTCPSocketResponseParser responseContentLengthFromData:totalReceivedData];

    //3\. Response.content的长度加上必有的16个字节即为整个Response报文的长度

    uint32_t responseLength = responseHeaderLength + responseContentLength;

    if (totalReceivedData.length < responseLength) { return nil; }



    //4\. 根据上面解析出的responseLength截取出单个Response报文

    responseData = [totalReceivedData subdataWithRange:NSMakeRange(0, responseLength)];

    self.buffer = [[totalReceivedData subdataWithRange:NSMakeRange(responseLength, totalReceivedData.length - responseLength)] mutableCopy];

    return responseData;

}



//将Response报文解析Response 然后交由对应的Task进行派发

- (void)dispatchResponse:(NSData *)responseData {

    HHTCPSocketResponse *response = [HHTCPSocketResponse responseWithData:responseData];

    if (response == nil) { return; }



    if (response.url > TCP_max_notification) {/** 请求响应 */



        HHTCPSocketTask *task = self.dispatchTable[@(response.serNum)];

        [task completeWithResponse:response error:nil];

    } else {/** 推送或心跳 略 */

        ...

    }

}

//HHTCPSocketClient.m



- (void)dispatchResponse:(NSData *)responseData {

    HHTCPSocketResponse *response = [HHTCPSocketResponse responseWithData:responseData];

    if (response == nil) { return; }



    if (response.url > TCP_max_notification) {/** 请求响应 略*/

        //...

    } else if (response.url == TCP_heatbeat) {/** 心跳 略 */

        //...

    } else {/** 推送 */

        [self dispatchRemoteNotification:response];

    }

}



//各种推送 自行处理

- (void)dispatchRemoteNotification:(HHTCPSocketResponse *)notification {



    switch (notification.url) {

        case TCP_notification_xxx: ...

        case TCP_notification_yyy: ...

        case TCP_notification_zzz: ...

        default:break;

    }

}

//HHTCPSocketTask.m



#pragma mark - Interface



- (void)cancel {

    if (![self canResponse]) { return; }



    self.state = HHTCPSocketTaskStateCanceled;

    [self completeWithResult:nil error:[self taskErrorWithResponeCode:HHNetworkTaskErrorCanceled]];

}



- (void)resume {

    if (self.state != HHTCPSocketTaskStateSuspended) { return; }



    //发起Request的同时也启动一个timer timer超时直接返回错误并忽略后续的Response

    self.timer = [NSTimer scheduledTimerWithTimeInterval:self.request.timeoutInterval target:self selector:@selector(requestTimeout) userInfo:nil repeats:NO];

    [[NSRunLoop mainRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];



    self.state = HHTCPSocketTaskStateRunning;

    [self.client resumeTask:self];

}



#pragma mark - Action



- (void)requestTimeout {

    if (![self canResponse]) { return; }



    self.state = HHTCPSocketTaskStateCompleted;

    [self completeWithResult:nil error:[self taskErrorWithResponeCode:HHNetworkTaskErrorTimeOut]];

}



#pragma mark - Utils



- (BOOL)canResponse {

    return self.state <= HHTCPSocketTaskStateRunning;

}

心跳

目前为止, 我们已经有了一个简单的TCP客户端, 它可以发送数据请求, 接收数据响应, 还能处理服务端推送. 最后, 我们做一下收尾工作: 心跳

单向的心跳就不说了, 这里我们给到一张Ping-Pong的简易图:

//HHTCPSocketHeartbeat



static NSUInteger maxMissTime = 3;

@implementation HHTCPSocketHeartbeat



+ (instancetype)heartbeatWithClient:(id)client timeoutHandler:(void (^)(void))timeoutHandler {



    HHTCPSocketHeartbeat *heartbeat = [HHTCPSocketHeartbeat new];

    heartbeat.client = client;

    heartbeat.missTime = -1;

    heartbeat.timeoutHandler = timeoutHandler;

    return heartbeat;

}



- (void)start {



    [self stop];

    self.timer = [NSTimer timerWithTimeInterval:60 target:self selector:@selector(sendHeatbeat) userInfo:nil repeats:YES];

    [[NSRunLoop mainRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];

}



- (void)stop {

    [self.timer invalidate];

}



- (void)reset {

    self.missTime = -1;

    [self start];

}



- (void)sendHeatbeat {



    self.missTime += 1;

    if (self.missTime >= maxMissTime && self.timeoutHandler != nil) {//心跳超时 执行超时回调

        self.timeoutHandler();

        self.missTime = -1;

    }



    HHTCPSocketRequest *request = [HHTCPSocketRequest requestWithURL:TCP_heatbeat parameters:@{@"ackNum": @(TCP_heatbeat)} header:nil];

    [self.client dispatchDataTaskWithRequest:request completionHandler:nil];

}



- (void)handleServerAckNum:(uint32_t)ackNum {

    if (ackNum == TCP_heatbeat) {//服务端返回的心跳回应Pong 不用处理

        self.missTime = -1;

        return;

    }



    //服务端发起的Ping 需要回应

    HHTCPSocketRequest *request = [HHTCPSocketRequest requestWithURL:TCP_heatbeat parameters:@{@"ackNum": @(ackNum)} header:nil];

    [self.client dispatchDataTaskWithRequest:request completionHandler:nil];

}



@end

//HHTCPSocketClient.m



- (void)configuration {



    self.heatbeat = [HHTCPSocketHeartbeat heartbeatWithClient:self timeoutHandler:^{//客户端心跳超时回调 

        //  [self reconnect];

        SocketLog(@"heartbeat timeout");

    }];

}



#pragma mark - HHTCPSocketDelegate



- (void)socket:(HHTCPSocket *)sock didConnectToHost:(NSString *)host port:(uint16_t)port {

    [self.heatbeat reset];//连接成功 客户端心跳启动

}



- (void)socketDidDisconnect:(HHTCPSocket *)sock error:(NSError *)error {

    [self.heatbeat stop];//连接断开 客户端心跳停止

}



- (void)socket:(HHTCPSocket *)sock didReadData:(NSData *)data {

    [self.heatbeat reset];//收到服务端数据 说明连接有效 重置心跳

    //...其他 略

}



//获取到服务端Response

- (void)dispatchResponse:(NSData *)responseData {

    HHTCPSocketResponse *response = [HHTCPSocketResponse responseWithData:responseData];

    if (response == nil) { return; }



    if (response.url == TCP_heatbeat) {/** 心跳 */

        [self.heatbeat handleServerAckNum:response.serNum];//回复服务端心跳请求 如果有必要的话

    } 

}

TCP概述

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC793定义. 在因特网协议族中，TCP属于传输层, 位于网络层之上，应用层之下.

需要注意的是, TCP只是协议声明, 仅对外声明协议提供的功能, 但本身并不进行任何实现. 因此, 在介绍通信协议时, 通常我们还会提及另一个术语: Socket.
Socket并不是一种协议, 而是一组接口(即API). 协议的实现方通过Socket对外提供具体的功能调用. TCP协议的实现方提供的接口就是TCPSocket, UDP协议的实现方提供的接口就是UDPSocket...

通常, 协议的使用方并不直接面对协议的实现方, 而是通过对应的Socket使用协议提供的功能. 因此, 即使以后协议的底层实现进行了任何改动, 但由于对外的接口Socket不变, 使用方也不需要做出任何变更.

TCP协议基于IP协议, 而IP协议属于不可靠协议, 要在一个不可靠协议的的基础上实现一个可靠的数据传输协议是困难且复杂的, TCP的定义者也并不指望所有程序员都能自行实现一遍TCP协议. 所以, 与其说本文是在介绍TCP编程, 倒不如说是介绍TCPSocket编程.

建立通讯连接

通过Socket建立TCP连接是非常简单的, 连接方(客户端)只需要提供被连接方(服务端)的IP地址和端口号去调用连接接口即可, 被连接方接受连接的话, 接口会返回成功, 否则返回失败, 至于底层的握手细节, 双方完全不用关心. 但考虑到网络波动, 前后台切换, 服务器重启等等可能导致的连接主动/被动断开的情况, 客户端这边我会加上必要的重连处理. 主要代码如下:

//HHTCPSocket.h



@class HHTCPSocket;

@protocol HHTCPSocketDelegate <NSObject>



@optional

- (void)socket:(HHTCPSocket *)sock didConnectToHost:(NSString *)host port:(uint16_t)port; //连接成功



- (void)socketCanNotConnectToService:(HHTCPSocket *)sock; //重连失败

- (void)socketDidDisconnect:(HHTCPSocket *)sock error:(NSError *)error; //连接失败并开始重连



@end



@interface HHTCPSocket : NSObject



@property (nonatomic, weak) id<HHTCPSocketDelegate> delegate;

@property (nonatomic, assign) NSUInteger maxRetryTime; //最大重连次数



- (instancetype)initWithService:(HHTCPSocketService *)service; //service提供ip地址和端口号



- (void)close;

- (void)connect; //连接

- (void)reconnect; //重连

- (BOOL)isConnected;



@end

//HHTCPSocket.m



@implementation HHTCPSocket



- (instancetype)initWithService:(HHTCPSocketService *)service {

    if (self = [super init]) {

        self.service = service ?: [HHTCPSocketService defaultService];



        //1\. 初始化Socket

        const char *delegateQueueLabel = [[NSString stringWithFormat:@"%p_socketDelegateQueue", self] cStringUsingEncoding:NSUTF8StringEncoding];

        self.reconnectTime = self.maxRetryTime;

        self.delegateQueue = dispatch_queue_create(delegateQueueLabel, DISPATCH_QUEUE_SERIAL);

        self.socket = [[GCDAsyncSocket alloc] initWithDelegate:self delegateQueue:self.delegateQueue];



        //2\. 初始化Socket连接线程

        self.machPort = [NSMachPort port];

        self.keepRuning = YES;

        self.socket.IPv4PreferredOverIPv6 = NO; //支持ipv6

        [NSThread detachNewThreadSelector:@selector(configSocketThread) toTarget:self withObject:nil];



        //3\. 处理网络波动/前后台切换

        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(didReceivedNetworkChangedNotification:) name:kRealReachabilityChangedNotification object:nil];

        [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(didReceivedAppBecomeActiveNotification:) name:UIApplicationDidBecomeActiveNotification object:nil];

    }

    return self;

}



- (void)dealloc {

    [[NSNotificationCenter defaultCenter] removeObserver:self];

}



#pragma mark - Interface



- (void)connect {

    if (self.isConnecting || !self.isNetworkReachable) { return; }

    self.isConnecting = YES;



    [self disconnect];



    //去Socket连接线程进行连接 避免阻塞UI

    BOOL isFirstTimeConnect = (self.reconnectTime == self.maxRetryTime);

    int64_t delayTime = isFirstTimeConnect ? 0 : (arc4random() % 3) + 1;

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayTime * NSEC_PER_SEC)), dispatch_get_global_queue(2, 0), ^{

        [self performSelector:@selector(connectOnSocketThread) onThread:self.socketThread withObject:nil waitUntilDone:YES];

    });

}



- (void)reconnect {



    self.reconnectTime = self.maxRetryTime;

    [self connect];

}



- (void)disconnect {

    if (!self.socket.isConnected) { return; }



    [self.socket setDelegate:nil delegateQueue:nil];

    [self.socket disconnect];

}



- (BOOL)isConnected {

    return self.socket.isConnected;

}



#pragma mark - GCDAsyncSocketDelegate



- (void)socket:(GCDAsyncSocket *)sock didConnectToHost:(NSString *)host port:(uint16_t)port {

    //连接成功 通知代理方

    if ([self.delegate respondsToSelector:@selector(socket:didConnectToHost:port:)]) {

        [self.delegate socket:self didConnectToHost:host port:port];

    }



    self.reconnectTime = self.maxRetryTime;

}



- (void)socketDidDisconnect:(GCDAsyncSocket *)sock withError:(NSError *)error {



    if ([self.delegate respondsToSelector:@selector(socketDidDisconnect:error:)]) {

        [self.delegate socketDidDisconnect:self error:error];

    }

    [self tryToReconnect];//连接失败 尝试重连

}



#pragma mark - Action



- (void)configSocketThread {



    if (self.socketThread == nil) {

        self.socketThread = [NSThread currentThread];

        [[NSRunLoop currentRunLoop] addPort:self.machPort forMode:NSDefaultRunLoopMode];

    }

    while (self.keepRuning) {

        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];

    }



    [[NSRunLoop currentRunLoop] removePort:self.machPort forMode:NSDefaultRunLoopMode];

    [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantPast]];

    [self.socketThread cancel];

    self.socket = nil;

    self.machPort = nil;

    self.socketThread = nil;

    self.delegateQueue = nil;

}



- (void)connectOnSocketThread {//实际的调用连接操作在这里



    [self.socket setDelegate:self delegateQueue:self.delegateQueue];

    [self.socket connectToHost:self.service.host onPort:self.service.port error:nil];

    self.isConnecting = NO;

}



#pragma mark - Notification



- (void)didReceivedNetworkChangedNotification:(NSNotification *)notif {

    [self reconnectIfNeed];

}



- (void)didReceivedAppBecomeActiveNotification:(NSNotification *)notif {

    [self reconnectIfNeed];

}



#pragma mark - Utils



- (void)tryToReconnect {

    if (self.isConnecting || !self.isNetworkReachable) { return; }



    self.reconnectTime -= 1;

    if (self.reconnectTime >= 0) {

        [self connect];

    } else if ([self.delegate respondsToSelector:@selector(socketCanNotConnectToService:)]) {

        [self.delegate socketCanNotConnectToService:self];

    }

}



- (NSUInteger)maxRetryTime {

    return _maxRetryTime > 0 ? _maxRetryTime : 5;

}



@end

这边因为需要添加重连操作, 所以我在GCDAsyncSocket的基础上又封装了一下, 但总体代码不多, 应该比较好理解. 这里需要注意的是GCDAsyncSocket的连接接口(connectToHost: onPort: error:)是同步调用的, 慢网情况下可能会阻塞线程一段时间, 所以这里我单开了一个线程来做连接操作.

连接建立以后, 就可以读写数据了, 写数据的接口如下:

- (void)writeData:(NSData *)data {

    if (!self.isConnected || data.length == 0) { return; }



    [self.socket writeData:data withTimeout:-1 tag:socketTag];

}

 //连接成功...

 while (1) {



        Error *error;

        Data *readData = [socket readToLength:1024 error:&error];//同步 读不到数据就阻塞

        if (error) { return; }



        [self handleData:readData];//同步异步皆可 多为异步

}

具体到我们的代码中, 则是这个样子:

// HHTCPSocket.h



@protocol HHTCPSocketDelegate <NSObject>

//...其他回调方法

- (void)socket:(HHTCPSocket *)sock didReadData:(NSData *)data;//读取到数据回调方法

@end

// HHTCPSocket.m



- (void)socket:(GCDAsyncSocket *)sock didConnectToHost:(NSString *)host port:(uint16_t)port {

    //Socket连接成功 开始读数据

    [self.socket readDataWithTimeout:-1 tag:socketTag];

}



- (void)socket:(GCDAsyncSocket *)sock didWriteDataWithTag:(long)tag {

    //Socket写数据成功 继续读取数据

    [self.socket readDataWithTimeout:-1 tag:socketTag];

}



- (void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag {



    //从Socket中读到数据 交由调用方处理

    if ([self.delegate respondsToSelector:@selector(socket:didReadData:)]) {

        [self.delegate socket:self didReadData:data];

    }

    [self.socket readDataWithTimeout:-1 tag:socketTag];//继续读取数据

}

现在我们已经可以通过Socket建立一条会自动重连的TCP连接, 然后还可以通过Socket从连接中读写数据, 接下来要做的就是定义一套自己的通讯协议了.

定义通讯协议

• 为什么需要定义通讯协议

TCP协议定义了连接双方以字节流而不是报文段的方式进行数据传输, 这意味着任何应用层报文(image/text/html...)想要通过TCP进行传输都必须先转化成二进制数据. 另外, TCP实现出于传输效率考虑, 往往会在连接两端各自开辟一个发送数据缓冲区和一个接收数据缓冲区. 因此, 有时应用层通过Socket向连接中写入数据时, 数据其实并没有立即被发送, 而是被放入缓冲区等待合适的时机才会真正的发送. 理想情况下, TCP进行传输数据的流程可能像这样:

但实际情况中, 因为Nagle算法/网络拥堵/拥塞控制/接收方读取太慢等等各种原因, 数据很有可能会在发送缓冲区/接收缓冲区被累积. 所以, 上面的流程更可能是这样:

或者这样:

上面的图都假设应用层报文不到一个MSS(一个MSS一般为1460字节, 这对大部分非文件请求来说都足够了), 当报文超过一个MSS时, TCP底层实现会对报文进行拆分后多次传输, 这会稍微复杂些(不想画图了), 但最后导致的问题是一致的, 解决方案也是一致的.

从上面的图容易看出, 无论数据在发送缓冲区还是接收缓冲区被累积, 对于接收方程序来说都是一样的: 多个应用层报文不分彼此粘作一串导致数据无法还原(粘包).

得益于TCP协议是可靠的传输协议(可靠意味着TCP实现会保证数据不会丢包, 也不会乱序), 粘包的问题很好处理. 我们只需要在发送方给每段数据都附上一份描述信息(描述信息主要包括数据的长度, 解析格式等等), 接收方就可以根据描述信息从一串数据流中分割出单独的每段应用层报文了.

被传输数据和数据的描述一起构成了一段应用层报文, 这里我们称实际想传输的数据为报文有效载荷, 而数据的描述信息为报文头部. 此时, 数据的传输流程就成了这样:

• 定义一个简单的通讯协议

自定义通讯协议时, 往往和项目业务直接挂钩, 所以这块其实没什么好写的. 但为了继续接下来的讨论, 这里我会给到一个非常简单的Demo版协议, 它长这样:

//HHTCPSocketRequest.h



/** URL类型肯定都是后台定义的 直接copy过来即可 命名用后台的 方便调试时比对 */

typedef enum : NSUInteger {

    TCP_heatbeat = 0x00000001,

    TCP_notification_xxx = 0x00000002,

    TCP_notification_yyy = 0x00000003,

    TCP_notification_zzz = 0x00000004,



    /* ========== */

    TCP_max_notification = 0x00000400,

    /* ========== */



    TCP_login = 0x00000401,

    TCP_weibo_list_public = 0x00000402,

    TCP_weibo_list_followed = 0x00000403,

    TCP_weibo_like = 0x00000404

} HHTCPSocketRequestURL;



+ (instancetype)requestWithURL:(HHTCPSocketRequestURL)url parameters:(NSDictionary *)parameters header:(NSDictionary *)header;

//HHTCPSocketRequest.m



+ (instancetype)requestWithURL:(HHTCPSocketRequestURL)url parameters:(NSDictionary *)parameters header:(NSDictionary *)header {



    NSData *content = [parameters yy_modelToJSONData];

    uint32_t requestIdentifier = [self currentRequestIdentifier];



    HHTCPSocketRequest *request = [HHTCPSocketRequest new];

    request.requestIdentifier = @(requestIdentifier);

    [request.formattedData appendData:[HHDataFormatter msgTypeDataFromInteger:url]];/** 请求URL */

    [request.formattedData appendData:[HHDataFormatter msgSerialNumberDataFromInteger:requestIdentifier]];/** 请求序列号 */

    [request.formattedData appendData:[HHDataFormatter msgContentLengthDataFromInteger:(uint32_t)content.length]];/** 请求内容长度 */



    if (content != nil) { [request.formattedData appendData:content]; }/** 请求内容 */

    return request;

}



+ (uint32_t)currentRequestIdentifier {



    static uint32_t currentRequestIdentifier;

    static dispatch_semaphore_t lock;

    static dispatch_once_t onceToken;

    dispatch_once(&onceToken, ^{



        currentRequestIdentifier = TCP_max_notification;

        lock = dispatch_semaphore_create(1);

    });



    dispatch_semaphore_wait(lock, DISPATCH_TIME_FOREVER);

    if (currentRequestIdentifier + 1 == 0xffffffff) {

        currentRequestIdentifier = TCP_max_notification;

    }

    currentRequestIdentifier += 1;

    dispatch_semaphore_signal(lock);



    return currentRequestIdentifier;

}

//HHTCPSocketResponse.h



@interface HHTCPSocketResponse : NSObject



+ (instancetype)responseWithData:(NSData *)data;



- (HHTCPSocketRequestURL)url;



- (NSData *)content;

- (uint32_t)serNum;

- (uint32_t)statusCode;

@end

//HHTCPSocketResponse.m



+ (instancetype)responseWithData:(NSData *)data {

    if (data.length < [HHTCPSocketResponseParser responseHeaderLength]) {

        return nil;

    }



    HHTCPSocketResponse *response = [HHTCPSocketResponse new];

    response.data = data;

    return response;

}



- (HHTCPSocketRequestURL)url {

    if (_url == 0) {

        _url = [HHTCPSocketResponseParser responseURLFromData:self.data];

    }

    return _url;

}



- (uint32_t)serNum {

    if (_serNum == 0) {

        _serNum = [HHTCPSocketResponseParser responseSerialNumberFromData:self.data];

    }

    return _serNum;

}



- (uint32_t)statusCode {

    if (_statusCode == 0) {

        _statusCode = [HHTCPSocketResponseParser responseCodeFromData:self.data];

    }

    return _statusCode;

}



- (NSData *)content {

    return [HHTCPSocketResponseParser responseContentFromData:self.data];

}



@end

//HHTCPSocketTask.h



typedef enum : NSUInteger {

    HHTCPSocketTaskStateSuspended = 0,

    HHTCPSocketTaskStateRunning = 1,

    HHTCPSocketTaskStateCanceled = 2,

    HHTCPSocketTaskStateCompleted = 3

} HHTCPSocketTaskState;



@interface HHTCPSocketTask : NSObject



- (void)cancel;

- (void)resume;



- (HHTCPSocketTaskState)state;

- (NSNumber *)taskIdentifier;



@end

//HHTCPSocketTask.m



//保存Request和completionHandler Request用于将调用方数据写入Socket completionHandler用于将Response交付给调用方

+ (instancetype)taskWithRequest:(HHTCPSocketRequest *)request completionHandler:(HHNetworkTaskCompletionHander)completionHandler {



    HHTCPSocketTask *task = [HHTCPSocketTask new];

    task.request = request;

    task.completionHandler = completionHandler;

    task.state = HHTCPSocketTaskStateSuspended;

    ...其他 略

    return task;

}



//处理服务端返回的Response Socket读取到相应的Response报文数据后会调用此接口

- (void)completeWithResponse:(HHTCPSocketResponse *)response error:(NSError *)error {

    if (![self canResponse]) { return; }



    NSDictionary *result;

    if (error == nil) {



        if (response == nil) {

            error = [self taskErrorWithResponeCode:HHTCPSocketResponseCodeUnkonwn];

        } else {



            error = [self taskErrorWithResponeCode:response.statusCode];

            result = [NSJSONSerialization JSONObjectWithData:response.content options:0 error:nil];

        }

    }



    [self completeWithResult:result error:error];

}



//将处理后的数据交付给调用方

- (void)completeWithResult:(id)result error:(NSError *)error {



    ...其他 略

    dispatch_async(dispatch_get_main_queue(), ^{



        !self.completionHandler ?: self.completionHandler(error, result);

        self.completionHandler = nil;

    });

}

1. 一个程序至少有一个进程,一个进程至少有一个线程

2. 线程的划分尺度小于进程，使得多线程程序的并发性高

3. 另外，进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率

4. 线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制 

5. 从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别

------------

1.IE6或更低版本最多20个cookie

2.IE7和之后的版本最后可以有50个cookie。

3.Firefox最多50个cookie

4.chrome和Safari没有做硬性限制

IE和Opera 会清理近期最少使用的cookie，Firefox会随机清理cookie。

优点：极高的扩展性和可用性

1.通过良好的编程，控制保存在cookie中的session对象的大小。

2.通过加密和安全传输技术（SSL），减少cookie被破解的可能性。

3.只在cookie中存放不敏感数据，即使被盗也不会有重大损失。

4.控制cookie的生命期，使之不会永远有效。偷盗者很可能拿到一个过期的cookie。

缺点：

1.`Cookie`数量和长度的限制。每个domain最多只能有20条cookie，每个cookie长度不能超过4KB，否则会被截掉。

2.安全性问题。如果cookie被人拦截了，那人就可以取得所有的session信息。即使加密也与事无补，因为拦截者并不需要知道cookie的意义，他只要原样转发cookie就可以达到目的了。

3.有些状态不可能保存在客户端。例如，为了防止重复提交表单，我们需要在服务器端保存一个计数器。如果我们把这个计数器保存在客户端，那么它起不到任何作用。

本文链接：https://blog.csdn.net/kincaid_z/article/details/116530326

待完善

 IE 盒子模型、标准 W3C 盒子模型；IE的content部分包含了 border 和 padding;

new操作符具体干了什么呢?

1. 创建一个空对象，并且 this 变量引用该对象，同时还继承了该函数的原型

2. 属性和方法被加入到 this 引用的对象中

3. 新创建的对象由 this 所引用，并且最后隐式的返回 this

JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。它是基于JavaScript的一个子集。数据格式简单, 易于读写, 占用带宽小

内存泄漏指任何对象在您不再拥有或需要它之后仍然存在。

垃圾回收器定期扫描对象，并计算引用了每个对象的其他对象的数量。如果一个对象的引用数量为 0（没有其他对象引用过该对象），或对该对象的惟一引用是循环的，那么该对象的内存即可回收。

1. setTimeout 的第一个参数使用字符串而非函数的话，会引发内存泄漏。

2. 闭包

3. 控制台日志

4. 循环（在两个对象彼此引用且彼此保留时，就会产生一个循环）

一个页面从输入 URL 到页面加载显示完成，这个过程中都发生了什么？

分为4个步骤：

1. 当发送一个 URL 请求时，不管这个 URL 是 Web 页面的 URL 还是 Web 页面上每个资源的 URL，浏览器都会开启一个线程来处理这个请求，同时在远程 DNS 服务器上启动一个 DNS 查询。这能使浏览器获得请求对应的 IP 地址。

2. 浏览器与远程 Web 服务器通过 TCP 三次握手协商来建立一个 TCP/IP 连接。该握手包括一个同步报文，一个同步-应答报文和一个应答报文，这三个报文在 浏览器和服务器之间传递。该握手首先由客户端尝试建立起通信，而后服务器应答并接受客户端的请求，最后由客户端发出该请求已经被接受的报文。

3. 一旦 TCP/IP 连接建立，浏览器会通过该连接向远程服务器发送 HTTP 的 GET 请求。远程服务器找到资源并使用 HTTP 响应返回该资源，值为 200 的 HTTP 响应状态表示一个正确的响应。

4. 此时，Web 服务器提供资源服务，客户端开始下载资源。

GET：一般用于信息获取，使用URL传递参数，对所发送信息的数量也有限制，一般在2000个字符

POST：一般用于修改服务器上的资源，对所发送的信息没有限制

Ajax 同步和异步的区别:

1. 同步：提交请求 -> 等待服务器处理 -> 处理完毕返回，这个期间客户端浏览器不能干任何事

2. 异步：请求通过事件触发 -> 服务器处理（这是浏览器仍然可以作其他事情）-> 处理完毕

js数组去重

[1,1,2,2,3,3,3,3].filter(function(elem, index, self) {

///结果是true的时候返回后面的值

    return index == self.indexOf(elem);

})

1. XSS

2. sql注入

3. CSRF：是跨站请求伪造，很明显根据刚刚的解释，他的核心也就是请求伪造，通过伪造身份提交POST和GET请求来进行跨域的攻击

完成CSRF需要两个步骤：

1. 登陆受信任的网站A，在本地生成 COOKIE

2. 在不登出A的情况下，或者本地 COOKIE 没有过期的情况下，访问危险网站B。

2.HTTP 报文的组成部分

请求报文

1.请求行:http方法、页面地址、协议、版本

2.请求头:key、value告诉服务端需要内容，注意什么类型

3.空行:告诉服务端请求头已经结束

4.请求体

响应报文

1.状态行:协议、版本、状态码

2.响应头

3.空行

4.响应体:文档部分

• TCP/IP 四层协议: 应用层、传输层、网络互连层和主机到网络层. http对应应用层
• ISO 七层模型: 物理层, 数据链路层, 网络层, 传输层, 会话层, 表示层, 应用层.  http对应应用

流行的一些东西：

1. Node.js

2. Mongodb

3. npm

4. MVVM

5. MEAN

6. three.js

7. React

本文链接：https://blog.csdn.net/kincaid_z/article/details/116530326

很简单一个问题,0.1+0.2,我们肉眼可见的算出来等于0.3,但js是一个神奇的语言,我们在控制台输入0.1+0.2等于0.30000000000000004,为什么会这样尼,我百度了了一下,原因如下:

JavaScript 中所有数字包括整数和小数都只有一种类型 — Number。它的实现遵循 IEEE 754 标准，使用 64 位固定长度来表示，也就是标准的 double 双精度浮点数（相关的还有float 32位单精度）。0.1的二进制表示的是一个无限循环小数，该版本的 JS 采用的是浮点数标准需要对这种无限循环的二进制进行截取，从而导致了精度丢失，造成了0.1不再是0.1，截取之后0.1变成了 0.100…001，0.2变成了0.200…002。所以两者相加的数大于0.3。

原因就是这么个奇葩,做需求的时候涉及到数字计算,那就得解决它老人家这个毛病,解决这个问题,我一般会封装成一个文件,到后面需要的地方可以模块化引入,并使用

1.判断obj是否为一个整数

export const  isInteger = (obj) => {
    return Math.floor(obj) === obj //向下取整就是为了让整数部分截取下来不变
}

2.将一个浮点数转成整数，返回整数和倍数

比如:3.14 -->314，倍数是 100 ,floatNum {number} 小数,返回一个对象, {times:100, num: 314}

export const toInteger = (floatNum) => {
    var ret = {times: 1, num: 0};
    if (isInteger(floatNum)) {
        ret.num = floatNum;
        return ret
    }
    //1.//转字符串
    var strfi = floatNum + '';  
    //2.//拿到小数点为
    var dotPos = strfi.indexOf('.');  
    //3. //截取需要的长度
    var len = strfi.substr(dotPos + 1).length;
    //4.倍数就是长度的幂
    var times = Math.pow(10, len);
    var intNum = parseInt(floatNum * times , 10);
    ret.times = times;
    ret.num = intNum;
    return ret
}

3.把小数放大为整数（乘），进行算术运算，再缩小为小数（除）

1. 参数:a {number} 运算数1
2. b:{number} 运算数2,
3. op {string} 运算类型，有加减乘除（add/subtract/multiply/divide)

export const operation = (a, b, op) => {
    var o1 = toInteger(a);
    var o2 = toInteger(b);
    var n1 = o1.num;
    var n2 = o2.num;
    var t1 = o1.times;
    var t2 = o2.times;
    var max = t1 > t2 ? t1 : t2;
    var result = null;
    switch (op) {
        case 'add':
            if (t1 === t2) { // 两个小数位数相同
                result = n1 + n2
            } else if (t1 > t2) { // o1 小数位 大于 o2
                result = n1 + n2 * (t1 / t2)
            } else { // o1 小数位 小于 o2
                result = n1 * (t2 / t1) + n2
            }
            return result / max;
        case 'subtract':
            if (t1 === t2) {
                result = n1 - n2
            } else if (t1 > t2) {
                result = n1 - n2 * (t1 / t2)
            } else {
                result = n1 * (t2 / t1) - n2
            }
            return result / max;
        case 'multiply':
            result = (n1 * n2) / (t1 * t2);
            return result;
        case 'divide':
            result = (n1 / n2) * (t2 / t1);
            return result
    }
}

作者：晨鹤
链接：https://juejin.cn/post/6957336568046714917
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

作者：Android_开发者
链接：https://juejin.cn/post/6959416526562656292
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1. KVO Crash 的常见原因

KVO（Key Value Observing） 翻译过来就是键值对观察，是 iOS 观察者模式的一种实现。KVO 允许一个对象监听另一个对象特定属性的改变，并在改变时接收到事件。但是 KVO API 的设计，我个人觉得不是很合理。被观察者需要做的工作太多，日常使用时稍不注意就会导致崩溃。

KVO 日常使用造成崩溃的原因通常有以下几个：

1. KVO 添加次数和移除次数不匹配：

• 移除了未注册的观察者，导致崩溃。

• 重复移除多次，移除次数多于添加次数，导致崩溃。

• 重复添加多次，虽然不会崩溃，但是发生改变时，也同时会被观察多次。

2. 被观察者提前被释放，被观察者在 dealloc 时仍然注册着 KVO，导致崩溃。 例如：被观察者是局部变量的情况（iOS 10 及之前会崩溃）。

3. 添加了观察者，但未实现 observeValueForKeyPath:ofObject:change:context: 方法，导致崩溃。

4. 添加或者移除时 keypath == nil，导致崩溃。

2. KVO 防止 Crash 常见方案

为了避免上面提到的使用 KVO 造成崩溃的问题，于是出现了很多关于 KVO 的第三方库，比如最出名的就是 FaceBook 开源的第三方库 facebook / KVOController。

FBKVOController 对 KVO 机制进行了额外的一层封装，框架不但可以自动帮我们移除观察者，还提供了 block 或者 selector 的方式供我们进行观察处理。不可否认的是，FBKVOController 为我们的开发提供了很大的便利性。但是相对而言，这种方式对项目代码的侵入性比较大，必须依靠编码规范来强制约束团队人员使用这种方式。

那么有没有一种对项目代码侵入性小，同时还能有效防护 KVO 崩溃的防护机制呢？

网上有很多类似的方案可以参考一下。

方案一：大白健康系统 -- iOS APP运行时 Crash 自动修复系统

1. 首先为 NSObject 建立一个分类，利用 Method Swizzling，实现自定义的 BMP_addObserver:forKeyPath:options:context:、BMP_removeObserver:forKeyPath:、BMP_removeObserver:forKeyPath:context:、BMPKVO_dealloc 方法，用来替换系统原生的添加移除观察者方法的实现。

2. 然后在观察者和被观察者之间建立一个 KVODelegate 对象，两者之间通过 KVODelegate 对象 建立联系。然后在添加和移除操作时，将 KVO 的相关信息例如 observer、keyPath、options、context 保存为 KVOInfo 对象，并添加到 KVODelegate 对象 中对应 的 关系哈希表 中，对应原有的添加观察者。关系哈希表的数据结构：{keypath : [KVOInfo 对象1, KVOInfo 对象2, ... ]}

3. 在添加和移除操作的时候，利用 KVODelegate 对象 做转发，把真正的观察者变为 KVODelegate 对象，而当被观察者的特定属性发生了改变，再由 KVODelegate 对象 分发到原有的观察者上。

那么，BayMax 系统是如何避免 KVO 崩溃的呢?

1. 添加观察者时：通过关系哈希表判断是否重复添加，只添加一次。

2. 移除观察者时：通过关系哈希表是否已经进行过移除操作，避免多次移除。

3. 观察键值改变时：同样通过关系哈希表判断，将改变操作分发到原有的观察者上。

另外，为了避免被观察者提前被释放，被观察者在 dealloc 时仍然注册着 KVO 导致崩溃。BayMax 系统还利用 Method Swizzling 实现了自定义的 dealloc，在系统 dealloc 调用之前，将多余的观察者移除掉。

方案二： ValiantCat / XXShield（第三方框架）

XXShield 实现方案和 BayMax 系统类似。也是利用一个 Proxy 对象用来做转发， 真正的观察者是 Proxy，被观察者出现了通知信息，由 Proxy 做分发。不过不同点是 Proxy 里面保存的内容没有前者多。只保存了 _observed（被观察者） 和关系哈希表，这个关系哈希表中只维护了 keyPath 和 observer 的关系。

关系哈希表的数据结构：{keypath : [observer1, observer2 , ...](NSHashTable)} 。

XXShield 在 dealloc 中也做了类似将多余观察者移除掉的操作，是通过关系数据结构和 _observed ，然后调用原生移除观察者操作实现的。

方案三： JackLee18 / JKCrashProtect（第三方框架）

JKCrashProtect 相对于前两个方案来讲，看上去更加的简洁明了。他的不同点在于没有使用 delegate。而是直接在分类中建立了一个关系哈希表，用来保存 {keypath : [observer1, observer2 , ...](NSHashTable)} 的关系。

添加的时候，如果关系哈希表中与 keyPath 对应的已经有了相关的观察者，就不再进行添加。同样移除观察者的时候，也在哈希表中进行查找，如果存在 observer、keyPath 的信息，就移除掉，否则就不进行移除操作。

不过，这个框架并没有对被观察者在 dealloc 时仍然注册着 KVO ，造成崩溃的情况进行处理。

3. 我的 KVO 防护实现

参考了这几个方法的实现后，分别实现了一下之后，最终还是选择了 方案一、方案二 这两种方案的实现思路。

1. 我使用了 YSCKVOProxy 对象，在 YSCKVOProxy 对象 中使用 {keypath : [observer1, observer2 , ...](NSHashTable)} 结构的 关系哈希表 进行 observer、keyPath 之间的维护。

2. 然后利用 YSCKVOProxy 对象 对添加、移除、观察方法进行分发处理。

3. 在分类中自定义了 dealloc 的实现，移除了多余的观察者。

• 代码如下所示：

#import "NSObject+KVODefender.h"
#import "NSObject+MethodSwizzling.h"
#import <objc/runtime.h>

// 判断是否是系统类
static inline BOOL IsSystemClass(Class cls){
    BOOL isSystem = NO;
    NSString *className = NSStringFromClass(cls);
    if ([className hasPrefix:@"NS"] || [className hasPrefix:@"__NS"] || [className hasPrefix:@"OS_xpc"]) {
        isSystem = YES;
        return isSystem;
    }
    NSBundle *mainBundle = [NSBundle bundleForClass:cls];
    if (mainBundle == [NSBundle mainBundle]) {
        isSystem = NO;
    }else{
        isSystem = YES;
    }
    return isSystem;
}


#pragma mark - YSCKVOProxy 相关

@interface YSCKVOProxy : NSObject

// 获取所有被观察的 keyPaths
- (NSArray *)getAllKeyPaths;

@end

@implementation YSCKVOProxy
{
    // 关系数据表结构：{keypath : [observer1, observer2 , ...](NSHashTable)}
    @private
    NSMutableDictionary<NSString *, NSHashTable<NSObject *> *> *_kvoInfoMap;
}

- (instancetype)init {
    self = [super init];
    if (self) {
        _kvoInfoMap = [NSMutableDictionary dictionary];
    }
    return self;
}

// 添加 KVO 信息操作, 添加成功返回 YES
- (BOOL)addInfoToMapWithObserver:(NSObject *)observer
                      forKeyPath:(NSString *)keyPath
                         options:(NSKeyValueObservingOptions)options
                         context:(void *)context {
    
    @synchronized (self) {
        if (!observer || !keyPath ||
            ([keyPath isKindOfClass:[NSString class]] && keyPath.length <= 0)) {
            return NO;
        }
        
        NSHashTable<NSObject *> *info = _kvoInfoMap[keyPath];
        if (info.count == 0) {
            info = [[NSHashTable alloc] initWithOptions:(NSPointerFunctionsWeakMemory) capacity:0];
            [info addObject:observer];

            _kvoInfoMap[keyPath] = info;
            
            return YES;
        }
        
        if (![info containsObject:observer]) {
            [info addObject:observer];
        }
        
        return NO;
    }
}

// 移除 KVO 信息操作, 添加成功返回 YES
- (BOOL)removeInfoInMapWithObserver:(NSObject *)observer
                         forKeyPath:(NSString *)keyPath {
    
    @synchronized (self) {
        if (!observer || !keyPath ||
            ([keyPath isKindOfClass:[NSString class]] && keyPath.length <= 0)) {
            return NO;
        }
        
        NSHashTable<NSObject *> *info = _kvoInfoMap[keyPath];
        
        if (info.count == 0) {
            return NO;
        }
        
        [info removeObject:observer];
        
        if (info.count == 0) {
            [_kvoInfoMap removeObjectForKey:keyPath];
            
            return YES;
        }
        
        return NO;
    }
}

// 添加 KVO 信息操作, 添加成功返回 YES
- (BOOL)removeInfoInMapWithObserver:(NSObject *)observer
                         forKeyPath:(NSString *)keyPath
                            context:(void *)context {
    @synchronized (self) {
        if (!observer || !keyPath ||
            ([keyPath isKindOfClass:[NSString class]] && keyPath.length <= 0)) {
            return NO;
        }
    
        NSHashTable<NSObject *> *info = _kvoInfoMap[keyPath];
    
        if (info.count == 0) {
            return NO;
        }
    
        [info removeObject:observer];
    
        if (info.count == 0) {
            [_kvoInfoMap removeObjectForKey:keyPath];
            
            return YES;
        }
    
        return NO;
    }
}

// 实际观察者 yscKVOProxy 进行监听，并分发
- (void)observeValueForKeyPath:(NSString *)keyPath
                      ofObject:(id)object
                        change:(NSDictionary<NSKeyValueChangeKey,id> *)change
                       context:(void *)context {

    NSHashTable<NSObject *> *info = _kvoInfoMap[keyPath];
    
    for (NSObject *observer in info) {
        @try {
            [observer observeValueForKeyPath:keyPath ofObject:object change:change context:context];
        } @catch (NSException *exception) {
            NSString *reason = [NSString stringWithFormat:@"KVO Warning : %@",[exception description]];
            NSLog(@"%@",reason);
        }
    }
}

// 获取所有被观察的 keyPaths
- (NSArray *)getAllKeyPaths {
    NSArray <NSString *>*keyPaths = _kvoInfoMap.allKeys;
    return keyPaths;
}

@end


#pragma mark - NSObject+KVODefender 分类

@implementation NSObject (KVODefender)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        
        // 拦截 `addObserver:forKeyPath:options:context:` 方法，替换自定义实现
        [NSObject yscDefenderSwizzlingInstanceMethod: @selector(addObserver:forKeyPath:options:context:)
                                          withMethod: @selector(ysc_addObserver:forKeyPath:options:context:)
                                           withClass: [NSObject class]];
        
        // 拦截 `removeObserver:forKeyPath:` 方法，替换自定义实现
        [NSObject yscDefenderSwizzlingInstanceMethod: @selector(removeObserver:forKeyPath:)
                                          withMethod: @selector(ysc_removeObserver:forKeyPath:)
                                           withClass: [NSObject class]];
        
        // 拦截 `removeObserver:forKeyPath:context:` 方法，替换自定义实现
        [NSObject yscDefenderSwizzlingInstanceMethod: @selector(removeObserver:forKeyPath:context:)
                                          withMethod: @selector(ysc_removeObserver:forKeyPath:context:)
                                           withClass: [NSObject class]];
        
        // 拦截 `dealloc` 方法，替换自定义实现
        [NSObject yscDefenderSwizzlingInstanceMethod: NSSelectorFromString(@"dealloc")
                                          withMethod: @selector(ysc_kvodealloc)
                                           withClass: [NSObject class]];
    });
}

static void *YSCKVOProxyKey = &YSCKVOProxyKey;
static NSString *const KVODefenderValue = @"YSC_KVODefender";
static void *KVODefenderKey = &KVODefenderKey;

// YSCKVOProxy setter 方法
- (void)setYscKVOProxy:(YSCKVOProxy *)yscKVOProxy {
    objc_setAssociatedObject(self, YSCKVOProxyKey, yscKVOProxy, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

// YSCKVOProxy getter 方法
- (YSCKVOProxy *)yscKVOProxy {
    id yscKVOProxy = objc_getAssociatedObject(self, YSCKVOProxyKey);
    if (yscKVOProxy == nil) {
        yscKVOProxy = [[YSCKVOProxy alloc] init];
        self.yscKVOProxy = yscKVOProxy;
    }
    return yscKVOProxy;
}

// 自定义 addObserver:forKeyPath:options:context: 实现方法
- (void)ysc_addObserver:(NSObject *)observer
             forKeyPath:(NSString *)keyPath
                options:(NSKeyValueObservingOptions)options
                context:(void *)context {
    
    if (!IsSystemClass(self.class)) {
        objc_setAssociatedObject(self, KVODefenderKey, KVODefenderValue, OBJC_ASSOCIATION_RETAIN);
        if ([self.yscKVOProxy addInfoToMapWithObserver:observer forKeyPath:keyPath options:options context:context]) {
            // 如果添加 KVO 信息操作成功，则调用系统添加方法
            [self ysc_addObserver:self.yscKVOProxy forKeyPath:keyPath options:options context:context];
        } else {
            // 添加 KVO 信息操作失败：重复添加
            NSString *className = (NSStringFromClass(self.class) == nil) ? @"" : NSStringFromClass(self.class);
            NSString *reason = [NSString stringWithFormat:@"KVO Warning : Repeated additions to the observer:%@ for the key path:'%@' from %@",
                                observer, keyPath, className];
            NSLog(@"%@",reason);
        }
    } else {
        [self ysc_addObserver:observer forKeyPath:keyPath options:options context:context];
    }
}

// 自定义 removeObserver:forKeyPath:context: 实现方法
- (void)ysc_removeObserver:(NSObject *)observer
                forKeyPath:(NSString *)keyPath
                   context:(void *)context {
    
    if (!IsSystemClass(self.class)) {
        if ([self.yscKVOProxy removeInfoInMapWithObserver:observer forKeyPath:keyPath context:context]) {
            // 如果移除 KVO 信息操作成功，则调用系统移除方法
            [self ysc_removeObserver:self.yscKVOProxy forKeyPath:keyPath context:context];
        } else {
            // 移除 KVO 信息操作失败：移除了未注册的观察者
            NSString *className = NSStringFromClass(self.class) == nil ? @"" : NSStringFromClass(self.class);
            NSString *reason = [NSString stringWithFormat:@"KVO Warning : Cannot remove an observer %@ for the key path '%@' from %@ , because it is not registered as an observer", observer, keyPath, className];
            NSLog(@"%@",reason);
        }
    } else {
        [self ysc_removeObserver:observer forKeyPath:keyPath context:context];
    }
}

// 自定义 removeObserver:forKeyPath: 实现方法
- (void)ysc_removeObserver:(NSObject *)observer
                forKeyPath:(NSString *)keyPath {
    
    if (!IsSystemClass(self.class)) {
        if ([self.yscKVOProxy removeInfoInMapWithObserver:observer forKeyPath:keyPath]) {
            // 如果移除 KVO 信息操作成功，则调用系统移除方法
            [self ysc_removeObserver:self.yscKVOProxy forKeyPath:keyPath];
        } else {
            // 移除 KVO 信息操作失败：移除了未注册的观察者
            NSString *className = NSStringFromClass(self.class) == nil ? @"" : NSStringFromClass(self.class);
            NSString *reason = [NSString stringWithFormat:@"KVO Warning : Cannot remove an observer %@ for the key path '%@' from %@ , because it is not registered as an observer", observer, keyPath, className];
            NSLog(@"%@",reason);
        }
    } else {
        [self ysc_removeObserver:observer forKeyPath:keyPath];
    }
    
}

// 自定义 dealloc 实现方法
- (void)ysc_kvodealloc {
    @autoreleasepool {
        if (!IsSystemClass(self.class)) {
            NSString *value = (NSString *)objc_getAssociatedObject(self, KVODefenderKey);
            if ([value isEqualToString:KVODefenderValue]) {
                NSArray *keyPaths =  [self.yscKVOProxy getAllKeyPaths];
                // 被观察者在 dealloc 时仍然注册着 KVO
                if (keyPaths.count > 0) {
                    NSString *reason = [NSString stringWithFormat:@"KVO Warning : An instance %@ was deallocated while key value observers were still registered with it. The Keypaths is:'%@'", self, [keyPaths componentsJoinedByString:@","]];
                    NSLog(@"%@",reason);
                }
                
                // 移除多余的观察者
                for (NSString *keyPath in keyPaths) {
                    [self ysc_removeObserver:self.yscKVOProxy forKeyPath:keyPath];
                }
            }
        }
    }
    
    
    [self ysc_kvodealloc];
}

@end

4. 测试 KVO 防护效果

这里提供一下相关崩溃的测试代码：

/********************* KVOCrashObject.h 文件 *********************/
#import <Foundation/Foundation.h>

@interface KVOCrashObject : NSObject

@property (nonatomic, copy) NSString *name;

@end

/********************* KVOCrashObject.m 文件 *********************/
#import "KVOCrashObject.h"

@implementation KVOCrashObject

@end

/********************* ViewController.m 文件 *********************/
#import "ViewController.h"
#import "KVOCrashObject.h"

@interface ViewController ()

@property (nonatomic, strong) KVOCrashObject *objc;

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view.
    
    self.objc = [[KVOCrashObject alloc] init];
}

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {

//    1.1 移除了未注册的观察者，导致崩溃
     [self testKVOCrash11];

//    1.2 重复移除多次，移除次数多于添加次数，导致崩溃
//    [self testKVOCrash12];

//    1.3 重复添加多次，虽然不会崩溃，但是发生改变时，也同时会被观察多次。
//    [self testKVOCrash13];

//    2. 被观察者 dealloc 时仍然注册着 KVO，导致崩溃
//    [self testKVOCrash2];

//    3. 观察者没有实现 -observeValueForKeyPath:ofObject:change:context:导致崩溃
//    [self testKVOCrash3];
    
//    4. 添加或者移除时 keypath == nil，导致崩溃。
//    [self testKVOCrash4];
}

/**
 1.1 移除了未注册的观察者，导致崩溃
 */
- (void)testKVOCrash11 {
    // 崩溃日志：Cannot remove an observer XXX for the key path "xxx" from XXX because it is not registered as an observer.
    [self.objc removeObserver:self forKeyPath:@"name"];
}

/**
 1.2 重复移除多次，移除次数多于添加次数，导致崩溃
 */
- (void)testKVOCrash12 {
    // 崩溃日志：Cannot remove an observer XXX for the key path "xxx" from XXX because it is not registered as an observer.
    [self.objc addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:NULL];
    self.objc.name = @"0";
    [self.objc removeObserver:self forKeyPath:@"name"];
    [self.objc removeObserver:self forKeyPath:@"name"];
}

/**
 1.3 重复添加多次，虽然不会崩溃，但是发生改变时，也同时会被观察多次。
 */
- (void)testKVOCrash13 {
    [self.objc addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:NULL];
    [self.objc addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:NULL];
    self.objc.name = @"0";
}

/**
 2. 被观察者 dealloc 时仍然注册着 KVO，导致崩溃
 */
- (void)testKVOCrash2 {
    // 崩溃日志：An instance xxx of class xxx was deallocated while key value observers were still registered with it.
    // iOS 10 及以下会导致崩溃，iOS 11 之后就不会崩溃了
    KVOCrashObject *obj = [[KVOCrashObject alloc] init];
    [obj addObserver: self
          forKeyPath: @"name"
             options: NSKeyValueObservingOptionNew
             context: nil];
}

/**
 3. 观察者没有实现 -observeValueForKeyPath:ofObject:change:context:导致崩溃
 */
- (void)testKVOCrash3 {
    // 崩溃日志：An -observeValueForKeyPath:ofObject:change:context: message was received but not handled.
    KVOCrashObject *obj = [[KVOCrashObject alloc] init];
    
    [self addObserver: obj
           forKeyPath: @"title"
              options: NSKeyValueObservingOptionNew
              context: nil];

    self.title = @"111";
}

/**
 4. 添加或者移除时 keypath == nil，导致崩溃。
 */
- (void)testKVOCrash4 {
    // 崩溃日志： -[__NSCFConstantString characterAtIndex:]: Range or index out of bounds
    KVOCrashObject *obj = [[KVOCrashObject alloc] init];
    
    [self addObserver: obj
           forKeyPath: @""
              options: NSKeyValueObservingOptionNew
              context: nil];
    
//    [self removeObserver:obj forKeyPath:@""];
}


- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary*)change context:(void *)context {

    NSLog(@"object = %@, keyPath = %@", object, keyPath);
}

@end

可以将示例项目 NSObject+KVODefender.m 中的 + (void)load; 方法注释掉或打开进行防护前后的测试。

经测试可以发现，成功的拦截了这几种因为 KVO 使用不当导致的崩溃。

链接：https://www.jianshu.com/p/e3713d309283

在代码库中建立可靠的结构通常是必不可少的，以便更容易使用。然而，实现一个既足够严格以防止错误和问题的结构 - 以及对现有功能足够灵活的结构以及我们想要的任何未来变化 - 都可能非常棘手。

对于模型代码而言尤其如此，模型代码通常由许多不同的功能使用，每个功能都有自己的一组要求。本周，让我们来看看构建核心模型的数据的几种不同技术，以及如何改进该结构对我们的其余代码库产生重大积极影响。

形成层次结构

在项目开始时，模型通常可以保持非常简单。由于我们尚未实现许多功能，因此我们的模型很可能不需要包含太多数据。然而，随着我们的代码库的增长，我们的模型经常发生变化 - 并且很容易达到一个简单的模型最终成为各种相关数据的“全能”的程度。

例如，假设我们正在构建一个电子邮件客户端，它使用Message模型来跟踪每条消息。最初，该模型可能只包含给定消息的主题行和正文，但此后逐渐增长为包含各种其他数据：

struct Message {
    var subject: String
    var body: String
    let date: Date
    var tags: [Tag]
    var replySent: Bool
    let senderName: String
    let senderImage: UIImage?
    let senderAddress: String
}

虽然为了呈现消息需要所有上述数据，但是直接将其保留在Message类型本身中会使事情变得有点混乱 - 并且很可能使消息更难以使用，尤其是当我们创建新实例时 - 撰写新邮件时或编写单元测试时。

缓解上述问题的一种方法是将数据分解为多个专用类型 - 然后我们可以使用它们来形成模型层次结构。例如，我们可能会将有关消息发送者的所有数据提取到Person结构中，并将所有元数据（例如消息的标记和日期）提取到Metadata类型中，如下所示：

struct Person {
    var name: String
    var image: UIImage?
    var address: String
}

extension Message {
    struct Metadata {
        let date: Date
        var tags: [Tag]
        var replySent: Bool
    }
}

现在，有了上述内容，我们可以为我们的Message类型提供一个更清晰的结构 - 因为每个数据不直接作为消息本身的一部分现在包含在更具上下文的专用类型中：

struct Message {
    var subject: String
    var body: String
    var metadata: Metadata
    let sender: Person
}

上述方法的另一个好处是，我们现在可以更容易地在不同的上下文中重用部分数据。例如，我们可以使用我们的新Person类型来实现联系人列表等功能，或者允许用户定义组 - 因为该数据不再直接绑定到该Message类型。

减少重复

除了用于更好地组织我们的代码之外，可靠的结构还可以帮助减少项目中的重复。假设我们的电子邮件应用程序使用事件驱动的方法来处理不同的用户操作 - 使用如下所示的Event枚举：

enum Event {
    case add(Message)
    case update(Message)
    case delete(Message)
    case move(Message, to: Folder)
}

使用枚举来定义各种代码需要处理的有限事件列表，这是在应用程序中建立更清晰数据流的好方法 - 但是我们当前的实现要求每个案例都包含Message事件所针对的事件 - 领先在Event类型本身内复制，以及在我们想要从事件的消息中提取信息时。

由于每个事件的操作都是对消息执行的，所以让我们将两者分开，并创建一个更简单的枚举类型，它将包含我们的所有操作：

enum Action {
    case add
    case update
    case delete
    case move(to: Folder)
}

然后，让我们再次形成一个层次结构 - 这一次通过重构我们的Event类型成为一个包含a Action和Message它将被应用于的包装器- 如下所示：

struct Event {
    let message: Message
    let action: Action
}

上述方法为我们提供了两全其美 - 处理事件现在只需要切换事件Action，现在可以使用message属性直接从事件的消息中提取数据。

递归结构

到目前为止，我们已经形成了层次结构，其中每个孩子和父母都是完全独立的类型 - 但这并不总是最优雅，或最方便的解决方案。假设我们正在开发一个显示各种内容的应用程序，例如文本和图像，并且我们再次使用枚举来定义每个内容 - 如下所示：

enum Content {
    case text(String)
    case image(UIImage)
    case video(Video)
}

现在让我们说我们希望让用户能够形成一组内容 - 例如，通过创建收藏列表，或使用文件夹来组织内容。最初的想法可能是寻找一个专用Group类型，它包含组的名称和属于它的内容：

struct Group {
    var name: String
    var content: [Content]
}

然而，尽管上述内容看起来优雅且结构合理，但在这种情况下它有一些缺点。通过引入一种新的专用类型，我们将需要单独处理各个内容组 - 使得构建列表之类的内容变得更加困难 - 而且我们也无法轻松支持嵌套组。

因为在这种情况下，一个组只不过是构造内容的另一种方式，所以让它改为Content枚举本身的第一类成员，只需为它添加一个新的例子 - 就像这样：

enum Content {
    case text(String)
    case image(UIImage)
    case video(Video)
    case group(name: String, content: [Content])
}

我们上面基本上做的是创建Content一个递归数据结构。这种方法的优点在于我们现在可以重用我们用于处理内容的大部分相同代码来处理组，并且我们可以自动支持任意数量的嵌套组。

例如，以下是我们如何处理显示内容列表的表视图的单元格选择：

extension ListViewController: UITableViewDelegate {
    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        let content = contentList[indexPath.row]

        switch content {
        case .text(let string):
            navigator.showText(string)
        case .image(let image):
            navigator.showImage(image)
        case .video(let video):
            navigator.openPlayer(for: video)
        case .group(let name, let content):
            navigator.openList(withTitle: name, content: content)
        }
    }
}

上面我们使用导航器模式导航到新目的地。您可以在“Swift中的导航”中找到更多相关信息。

由于Content现在是递归的，因此navigator.openList在处理组时调用现在只需创建一个ListViewController包含该组内容列表的新实例，使用户能够轻松地创建和导航任何内容层次结构，而我们只需要很少的努力。

专业模特

虽然能够重用代码通常是件好事，但有时最好创建一个更专业的新版本的模型，而不是尝试在非常不同的上下文中重用它。

回到之前的电子邮件应用程序示例，假设我们希望用户能够保存部分撰写的邮件草稿。而不是让该功能处理完整的Message实例，这需要不能用于草稿的数据 - 例如发件人的姓名或收到邮件的日期 - 让我们创建一个更简单的Draft类型，我们将嵌套在Message其他上下文中：

extension Message {
    struct Draft {
        var subject: String?
        var body: String?
        var recipients: [Person]
    }
}

这样，我们可以自由地将某些属性作为选项，并减少加载和保存草稿时我们需要处理的数据量 - 而不会影响我们处理正确消息的任何代码。

结论

虽然哪种模型结构最适合每种情况，但在很大程度上取决于所需的数据类型以及数据的使用方式 - 在能够重用代码和不创建模型之间取得平衡太复杂，往往是关键。

形成清晰的层次结构 - 无论是使用专用类型还是通过创建递归数据结构 - 同时仍然偶尔为特定用例创建模型的专用版本，可以在我们的模型代码中形成更清晰的结构 - 并且像往常一样，常量重构和小改进通常是达到目的的方式。

链接：https://www.jianshu.com/p/06e7d171dd99

App 的性能问题虽然不会导致 App不可用，但依然会影响到用户体验。如果这个性能问题不断累积，达到临界点以后，问题就会爆发出来。这时，影响到的就不仅仅是用户了，还有负责App开发的你。

线下性能监控

其中线下监控使用的还是Instruments，Instruments功能很强大，下图是Instruments的各种性能检测工具。

最新版本的Instruments 10还有以下两大优势：

1.Instruments基于os_signpost 架构，可以支持所有平台。

2.Instruments由于标准界面（Standard UI）和分析核心（Analysis Core）技术，使得我们可以非常方便地进行自定义性能监测工具的开发。当你想要给Instruments内置的工具换个交互界面，或者新创建一个工具的时候，都可以通过自定义工具这个功能来实现。

从整体架构来看，Instruments 包括Standard UI 和 Analysis Core 两个组件，它的所有工具都是基于这两个组件开发的。而且，你如果要开发自定义的性能分析工具的话，完全基于这两个组件就可以实现。

开发一款自定义Instruments工具，主要包括以下这几个步骤：

1.在Xcode中，点击File > New > Project；

2.在弹出的Project模板选择界面，将其设置为macOS；

3.选择 Instruments Package，点击后即可开始自定义工具的开发了。如下图所示。

经过上面的三步之后，会在新创建的工程里面生成一个.instrpkg 文件，接下来的开发过程主要就是对这个文件的配置工作了。这些配置工作中最主要的是要完成Standard UI 和 Analysis Core 的配置。

上面这些内容，就是你在开发一个自定义Instruments工具时，需要完成的编码工作了。可以看到，Instruments 10版本的自定义工具开发还是比较简单的。与此同时，苹果公司还提供了大量的代码片段，帮助你进行个性化的配置。你可以点击这个链接，查看官方指南中的详细教程。

再说一下，线上性能监控

对于线上性能监控，我们需要先明白两个原则：
1、监控代码不要侵入到业务代码中；
2、采用性能消耗最小的监控方案。

接下来我们从CPU使用率、FPS的帧率和内存这三个方面，说一下线上性能监控

CPU使用率的线上监控方法

App作为进程运行起来后会有多个线程，每个线程对CPU 的使用率不同。各个线程对CPU使用率的总和，就是当前App对CPU 的使用率。明白了这一点以后，我们也就摸清楚了对CPU使用率进行线上监控的思路。

在iOS系统中，你可以在 usr/include/mach/thread_info.h 里看到线程基本信息的结构体，其中的cpu_usage 就是 CPU使用率。结构体的完整代码如下所示：

struct thread_basic_info {
  time_value_t    user_time;     // 用户运行时长
  time_value_t    system_time;   // 系统运行时长
  integer_t       cpu_usage;     // CPU 使用率
  policy_t        policy;        // 调度策略
  integer_t       run_state;     // 运行状态
  integer_t       flags;         // 各种标记
  integer_t       suspend_count; // 暂停线程的计数
  integer_t       sleep_time;    // 休眠的时间
};

因为每个线程都会有这个 thread_basic_info 结构体，所以接下来的事情就好办了，你只需要定时（比如，将定时间隔设置为2s）去遍历每个线程，累加每个线程的 cpu_usage 字段的值，就能够得到当前App所在进程的 CPU 使用率了。实现代码如下：

- (integer_t)cpuUsage {
    thread_act_array_t threads; //int 组成的数组比如 thread[1] = 5635
    mach_msg_type_number_t threadCount = 0; //mach_msg_type_number_t 是 int 类型
    const task_t thisTask = mach_task_self();
    //根据当前 task 获取所有线程
    kern_return_t kr = task_threads(thisTask, &threads, &threadCount);
    
    if (kr != KERN_SUCCESS) {
        return 0;
    }
    
    integer_t cpuUsage = 0;
    // 遍历所有线程
    for (int i = 0; i < threadCount; i++) {
        
        thread_info_data_t threadInfo;
        thread_basic_info_t threadBaseInfo;
        mach_msg_type_number_t threadInfoCount = THREAD_INFO_MAX;
        
        if (thread_info((thread_act_t)threads[i], THREAD_BASIC_INFO, (thread_info_t)threadInfo, &threadInfoCount) == KERN_SUCCESS) {
            // 获取 CPU 使用率
            threadBaseInfo = (thread_basic_info_t)threadInfo;
            if (!(threadBaseInfo->flags & TH_FLAGS_IDLE)) {
                cpuUsage += threadBaseInfo->cpu_usage;
            }
        }
    }
    assert(vm_deallocate(mach_task_self(), (vm_address_t)threads, threadCount * sizeof(thread_t)) == KERN_SUCCESS);
    return cpuUsage;
}

在上面这段代码中，task_threads 方法能够取到当前进程中的线程总数 threadCount 和所有线程的数组 threads。

接下来，我们就可以通过遍历这个数组来获取单个线程的基本信息。其中，线程基本信息的结构体是 thread_basic_info_t，这个结构体里就包含了我们需要的 CPU 使用率的字段 cpu_usage。然后，我们累加这个字段就能够获取到当前的整体 CPU 使用率。

接下来我们说说关于FPS的监控

FPS 线上监控方法

FPS 是指图像连续在显示设备上出现的频率。FPS低，表示App不够流畅，还需要进行优化。

但是，和前面对CPU使用率和内存使用量的监控不同，iOS系统中没有一个专门的结构体，用来记录与FPS相关的数据。但是，对FPS的监控也可以比较简单的实现：通过注册 CADisplayLink 得到屏幕的同步刷新率，记录每次刷新时间，然后就可以得到 FPS。具体的实现代码如下：

- (void)startMonitoring {
    if (_link) {
        [_link removeFromRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
        [_link invalidate];
        _link = nil;
    }
    _link = [CADisplayLink displayLinkWithTarget:self selector:@selector(fpsDisplayLinkAction:)];
    [_link addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
}

- (void)fpsDisplayLinkAction:(CADisplayLink *)link {
    if (_lastTime == 0) {
        _lastTime = link.timestamp;
        return;
    }
    
    self.count++;
    NSTimeInterval delta = link.timestamp - _lastTime;
    if (delta < 1) return;
    _lastTime = link.timestamp;
    _fps = _count / delta;
    NSLog(@"count = %d, delta = %f,_lastTime = %f, _fps = %.0f",_count, delta, _lastTime, _fps);
    self.count = 0;
}

struct task_vm_info {
  mach_vm_size_t  virtual_size;       // 虚拟内存大小
  integer_t region_count;             // 内存区域的数量
  integer_t page_size;
  mach_vm_size_t  resident_size;      // 驻留内存大小
  mach_vm_size_t  resident_size_peak; // 驻留内存峰值

  ...

  /* added for rev1 */
  mach_vm_size_t  phys_footprint;     // 物理内存

  ...

- (unsigned long)memoryUsage {    
    task_vm_info_data_t vmInfo;
    mach_msg_type_number_t count = TASK_VM_INFO_COUNT;
    kern_return_t result = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t) &vmInfo, &count);
    if (result != KERN_SUCCESS)
        return 0;
    return vmInfo.phys_footprint;
}

客户端的整个Connect流程，用一张图来概括总结一下吧：

if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey))

//监听端口起点

- (BOOL)acceptOnPort:(uint16_t)port error:(NSError **)errPtr

{

     return [self acceptOnInterface:nil port:port error:errPtr];

}



- (BOOL)acceptOnInterface:(NSString *)inInterface port:(uint16_t)port error:(NSError **)errPtr

{

     LogTrace();



     // Just in-case interface parameter is immutable.

    //防止参数被修改

     NSString *interface = [inInterface copy];



     __block BOOL result = NO;

     __block NSError *err = nil;



     // CreateSocket Block

     // This block will be invoked within the dispatch block below.

     //创建socket的Block

     int(^createSocket)(int, NSData*) = ^int (int domain, NSData *interfaceAddr) {



        //创建TCP的socket

          int socketFD = socket(domain, SOCK_STREAM, 0);



          //一系列错误判断

          ...

          // Bind socket

        //用本地地址去绑定

          status = bind(socketFD, (const struct sockaddr *)[interfaceAddr bytes], (socklen_t)[interfaceAddr length]);



          //监听这个socket

        //第二个参数是这个端口下维护的socket请求队列，最多容纳的用户请求数。

          status = listen(socketFD, 1024);

          return socketFD;

     };



     // Create dispatch block and run on socketQueue



     dispatch_block_t block = ^{ @autoreleasepool {



         //一系列错误判断

          ...



        //判断ipv4 ipv6是否支持

          ...



        //得到本机的IPV4 IPV6的地址

          [self getInterfaceAddress4:&interface4 address6:&interface6 fromDescription:interface port:port];

          ...



        //判断可以用IPV4还是6进行请求

          ...



          // Create accept sources

          //创建接受连接被触发的source

          if (enableIPv4)

          {

            //接受连接的source

               accept4Source = dispatch_source_create(DISPATCH_SOURCE_TYPE_READ, socket4FD, 0, socketQueue);



            //事件句柄

               dispatch_source_set_event_handler(accept4Source, ^{ @autoreleasepool {



                //拿到数据，连接数

                    unsigned long numPendingConnections = dispatch_source_get_data(acceptSource);



                    LogVerbose(@"numPendingConnections: %lu", numPendingConnections);



                //循环去接受这些socket的事件(一次触发可能有多个连接)

                    while ([strongSelf doAccept:socketFD] && (++i < numPendingConnections));



               }});



               //取消句柄

               dispatch_source_set_cancel_handler(accept4Source, ^{

                //...

                //关闭socket

                    close(socketFD);



               });



            //开启source

               dispatch_resume(accept4Source);

          }



        //ipv6一样

          ...



    //在scoketQueue中同步做这些初始化。

     if (dispatch_get_specific(IsOnSocketQueueOrTargetQueueKey))

          block();

     else

          dispatch_sync(socketQueue, block);



     //...错误判断

     //返回结果

     return result;

}

//连接接受的方法

- (BOOL)doAccept:(int)parentSocketFD

{

     LogTrace();



     int socketType;

     int childSocketFD;

     NSData *childSocketAddress;



    //IPV4

     if (parentSocketFD == socket4FD)

     {

          socketType = 0;



          struct sockaddr_in addr;

          socklen_t addrLen = sizeof(addr);

          //调用接受，得到接受的子socket

          childSocketFD = accept(parentSocketFD, (struct sockaddr *)&addr, &addrLen);

          //NO说明没有连接

          if (childSocketFD == -1)

          {

               LogWarn(@"Accept failed with error: %@", [self errnoError]);

               return NO;

          }

          //子socket的地址数据

          childSocketAddress = [NSData dataWithBytes:&addr length:addrLen];

     }

    //一样

     else if (parentSocketFD == socket6FD)

     {

          ...

     }

    //unix domin socket 一样

     else // if (parentSocketFD == socketUN)

     {

          ...

     }



     //socket 配置项的设置... 和connect一样



    //响应代理

     if (delegateQueue)

     {

          __strong id theDelegate = delegate;

          //代理队列中调用

          dispatch_async(delegateQueue, ^{ @autoreleasepool {



               // Query delegate for custom socket queue



               dispatch_queue_t childSocketQueue = NULL;



            //判断是否实现了为socket 生成一个新的SocketQueue，是的话拿到新queue

               if ([theDelegate respondsToSelector:@selector(newSocketQueueForConnectionFromAddress:onSocket:)])

               {

                    childSocketQueue = [theDelegate newSocketQueueForConnectionFromAddress:childSocketAddress

                                                                                  onSocket:self];

               }



               // Create GCDAsyncSocket instance for accepted socket

               //新创建一个本类实例，给接受的socket

               GCDAsyncSocket *acceptedSocket = [[[self class] alloc] initWithDelegate:theDelegate

                                                                                       delegateQueue:delegateQueue

                                                                                          socketQueue:childSocketQueue];

               //IPV4 6 un

               if (socketType == 0)

                    acceptedSocket->socket4FD = childSocketFD;

               else if (socketType == 1)

                    acceptedSocket->socket6FD = childSocketFD;

               else

                    acceptedSocket->socketUN = childSocketFD;

               //标记开始 并且已经连接

               acceptedSocket->flags = (kSocketStarted | kConnected);



               // Setup read and write sources for accepted socket

               //初始化读写source

               dispatch_async(acceptedSocket->socketQueue, ^{ @autoreleasepool {



                    [acceptedSocket setupReadAndWriteSourcesForNewlyConnectedSocket:childSocketFD];

               }});



            //判断代理是否实现了didAcceptNewSocket方法，把我们新创建的socket返回出去

               if ([theDelegate respondsToSelector:@selector(socket:didAcceptNewSocket:)])

               {

                    [theDelegate socket:self didAcceptNewSocket:acceptedSocket];

               }



          }});

     }

     return YES;

}