Table view 是 iOS 应用程序中非常通用的组件。许多代码和 table view 都有直接或间接的关系，随便举几个例子，比如提供数据、更新 table view，控制它的行为以及响应选择事件。在这篇文章中，我们将会展示保持 table view 相关代码的整洁和良好组织的技术。

UITableViewController vs. UIViewController

Apple 提供了 UITableViewController 作为 table views 专属的 view controller 类。Table view controllers 实现了一些非常有用的特性，来帮你避免一遍又一遍地写那些死板的代码！但是话又说回来，table view controller 只限于管理一个全屏展示的 table view。大多数情况下，这就是你想要的，但如果不是，还有其他方法来解决这个问题，就像下面我们展示的那样。

Table View Controllers 的特性

Table view controllers 会在第一次显示 table view 的时候帮你加载其数据。另外，它还会帮你切换 table view 的编辑模式、响应键盘通知、以及一些小任务，比如闪现侧边的滑动提示条和清除选中时的背景色。为了让这些特性生效，当你在子类中覆写类似 viewWillAppear: 或者 viewDidAppear: 等事件方法时，需要调用 super 版本。

Table view controllers 相对于标准 view controllers 的一个特别的好处是它支持 Apple 实现的“下拉刷新”。目前，文档中唯一的使用 UIRefreshControl 的方式就是通过 table view controller ，虽然通过努力在其他地方也能让它工作（见此处），但很可能在下一次 iOS 更新的时候就不行了。

这些要素加一起，为我们提供了大部分 Apple 所定义的标准 table view 交互行为，如果你的应用恰好符合这些标准，那么直接使用 table view controllers 来避免写那些死板的代码是个很好的方法。

Table View Controllers 的限制

Table view controllers 的 view 属性永远都是一个 table view。如果你稍后决定在 table view 旁边显示一些东西（比如一个地图），如果不依赖于那些奇怪的 hacks，估计就没什么办法了。

如果你是用代码或 .xib 文件来定义的界面，那么迁移到一个标准 view controller 将会非常简单。但是如果你使用了 storyboards，那么这个过程要多包含几个步骤。除非重新创建，否则你并不能在 storyboards 中将 table view controller 改成一个标准的 view controller。这意味着你必须将所有内容拷贝到新的 view controller，然后再重新连接一遍。

最后，你需要把迁移后丢失的 table view controller 的特性给补回来。大多数都是 viewWillAppear: 或 viewDidAppear: 中简单的一条语句。切换编辑模式需要实现一个 action 方法，用来切换 table view 的 editing 属性。大多数工作来自重新创建对键盘的支持。

在选择这条路之前，其实还有一个更轻松的选择，它可以通过分离我们需要关心的功能（关注点分离），让你获得额外的好处：

使用 Child View Controllers

和完全抛弃 table view controller 不同，你还可以将它作为 child view controller 添加到其他 view controller 中（关于此话题的文章）。这样，parent view controller 在管理其他的你需要的新加的界面元素的同时，table view controller 还可以继续管理它的 table view。

- (void)addPhotoDetailsTableView
{
    DetailsViewController *details = [[DetailsViewController alloc] init];
    details.photo = self.photo;
    details.delegate = self;
    [self addChildViewController:details];
    CGRect frame = self.view.bounds;
    frame.origin.y = 110;
    details.view.frame = frame;
    [self.view addSubview:details.view];
    [details didMoveToParentViewController:self];
}

如果你使用这个解决方案，你就必须在 child view controller 和 parent view controller 之间建立消息传递的渠道。比如，如果用户选择了一个 table view 中的 cell，parent view controller 需要知道这个事件来推入其他 view controller。根据使用习惯，通常最清晰的方式是为这个 table view controller 定义一个 delegate protocol，然后到 parent view controller 中去实现。

@protocol DetailsViewControllerDelegate
- (void)didSelectPhotoAttributeWithKey:(NSString *)key;
@end

@interface PhotoViewController () 
@end

@implementation PhotoViewController
// ...
- (void)didSelectPhotoAttributeWithKey:(NSString *)key
{
    DetailViewController *controller = [[DetailViewController alloc] init];
    controller.key = key;
    [self.navigationController pushViewController:controller animated:YES];
}
@end

就像你看到的那样，这种结构为 view controller 之间的消息传递带来了额外的开销，但是作为回报，代码封装和分离非常清晰，有更好的复用性。根据实际情况的不同，这既可能让事情变得更简单，也可能会更复杂，需要读者自行斟酌和决定。

分离关注点（Separating Concerns）

当处理 table views 的时候，有许多各种各样的任务，这些任务穿梭于 models，controllers 和 views 之间。为了避免让 view controllers 做所有的事，我们将尽可能地把这些任务划分到合适的地方，这样有利于阅读、维护和测试。

这里描述的技术是文章更轻量的 View Controllers 中的概念的延伸，请参考这篇文章来理解如何重构 data source 和 model 的逻辑。结合 table views，我们来具体看看如何在 view controllers 和 views 之间分离关注点。

搭建 Model 对象和 Cells 之间的桥梁

有时我们需要将想显示的 model 层中的数据传到 view 层中去显示。由于我们同时也希望让 model 和 view 之间明确分离，所以通常把这个任务转移到 table view 的 data source 中去处理：

- (UITableViewCell *)tableView:(UITableView *)tableView
         cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    PhotoCell *cell = [tableView dequeueReusableCellWithIdentifier:@"PhotoCell"];
    Photo *photo = [self itemAtIndexPath:indexPath];
    cell.photoTitleLabel.text = photo.name;
    NSString* date = [self.dateFormatter stringFromDate:photo.creationDate];
    cell.photoDateLabel.text = date;
}

但是这样的代码会让 data source 变得混乱，因为它向 data source 暴露了 cell 的设计。最好分解出来，放到 cell 类的一个 category 中。

@implementation PhotoCell (ConfigureForPhoto)

- (void)configureForPhoto:(Photo *)photo
{
    self.photoTitleLabel.text = photo.name;
    NSString* date = [self.dateFormatter stringFromDate:photo.creationDate];
    self.photoDateLabel.text = date;
}

@end

有了上述代码后，我们的 data source 方法就变得简单了。

- (UITableViewCell *)tableView:(UITableView *)tableView
         cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    PhotoCell *cell = [tableView dequeueReusableCellWithIdentifier:PhotoCellIdentifier];
    [cell configureForPhoto:[self itemAtIndexPath:indexPath]];
    return cell;
}

在我们的示例代码中，table view 的 data source 已经分解到单独的类中了，它用一个设置 cell 的 block 来初始化。这时，这个 block 就变得这样简单了：

TableViewCellConfigureBlock block = ^(PhotoCell *cell, Photo *photo) {
    [cell configureForPhoto:photo];
};

让 Cells 可复用

有时多种 model 对象需要用同一类型的 cell 来表示，这种情况下，我们可以进一步让 cell 可以复用。首先，我们给 cell 定义一个 protocol，需要用这个 cell 显示的对象必须遵循这个 protocol。然后简单修改 category 中的设置方法，让它可以接受遵循这个 protocol 的任何对象。这些简单的步骤让 cell 和任何特殊的 model 对象之间得以解耦，让它可适应不同的数据类型。

在 Cell 内部控制 Cell 的状态

如果你想自定义 table views 默认的高亮或选择行为，你可以实现两个 delegate 方法，把点击的 cell 修改成我们想要的样子。例如：

- (void)tableView:(UITableView *)tableView
        didHighlightRowAtIndexPath:(NSIndexPath *)indexPath
{
    PhotoCell *cell = [tableView cellForRowAtIndexPath:indexPath];
    cell.photoTitleLabel.shadowColor = [UIColor darkGrayColor];
    cell.photoTitleLabel.shadowOffset = CGSizeMake(3, 3);
}

- (void)tableView:(UITableView *)tableView
        didUnhighlightRowAtIndexPath:(NSIndexPath *)indexPath
{
    PhotoCell *cell = [tableView cellForRowAtIndexPath:indexPath];
    cell.photoTitleLabel.shadowColor = nil;
}

然而，这两个 delegate 方法的实现又基于了 view controller 知晓 cell 实现的具体细节。如果我们想替换或重新设计 cell，我们必须改写 delegate 代码。View 的实现细节和 delegate 的实现交织在一起了。我们应该把这些细节移到 cell 自身中去。

@implementation PhotoCell
// ...
- (void)setHighlighted:(BOOL)highlighted animated:(BOOL)animated
{
    [super setHighlighted:highlighted animated:animated];
    if (highlighted) {
        self.photoTitleLabel.shadowColor = [UIColor darkGrayColor];
        self.photoTitleLabel.shadowOffset = CGSizeMake(3, 3);
    } else {
        self.photoTitleLabel.shadowColor = nil;
    }
}
@end

总的来说，我们在努力把 view 层和 controller 层的实现细节分离开。delegate 肯定得清楚一个 view 该显示什么状态，但是它不应该了解如何修改 view 结构或者给某些 subviews 设置某些属性以获得正确的状态。所有这些逻辑都应该封装到 view 内部，然后给外部提供一个简单的 API。

控制多个 Cell 类型

如果一个 table view 里面有多种类型的 cell，data source 方法很快就难以控制了。在我们示例程序中，photo details table 有两种不同类型的 cell：一种用于显示几个星，另一种用来显示一个键值对。为了划分处理不同 cell 类型的代码，data source 方法简单地通过判断 cell 的类型，把任务派发给其他指定的方法。

- (UITableViewCell *)tableView:(UITableView *)tableView
         cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    NSString *key = self.keys[(NSUInteger) indexPath.row];
    id value = [self.photo valueForKey:key];
    UITableViewCell *cell;
    if ([key isEqual:PhotoRatingKey]) {
        cell = [self cellForRating:value indexPath:indexPath];
    } else {
        cell = [self detailCellForKey:key value:value];
    }
    return cell;
}

- (RatingCell *)cellForRating:(NSNumber *)rating
                    indexPath:(NSIndexPath *)indexPath
{
    // ...
}

- (UITableViewCell *)detailCellForKey:(NSString *)key
                                value:(id)value
{
    // ...
}

编辑 Table View

Table view 提供了易于使用的编辑特性，允许你对 cell 进行删除或重新排序。这些事件都可以让 table view 的 data source 通过 delegate 方法得到通知。因此，通常我们能在这些 delegate 方法中看到对数据的进行修改的操作。

修改数据很明显是属于 model 层的任务。Model 应该为诸如删除或重新排序等操作暴露一个 API，然后我们可以在 data source 方法中调用它。这样，controller 就可以扮演 view 和 model 之间的协调者，而不需要知道 model 层的实现细节。并且还有额外的好处，model 的逻辑也变得更容易测试，因为它不再和 view controllers 的任务混杂在一起了。

总结

Table view controllers（以及其他的 controller 对象！）应该在 model 和 view 对象之间扮演协调者和调解者的角色。它不应该关心明显属于 view 层或 model 层的任务。你应该始终记住这点，这样 delegate 和 data source 方法会变得更小巧，最多包含一些简单的样板代码。

这不仅减少了 table view controllers 那样的大小和复杂性，而且还把业务逻辑和 view 的逻辑放到了更合适的地方。Controller 层的里里外外的实现细节都被封装成了简单的 API，最终，它变得更加容易理解，也更利于团队协作。

转自：https://www.jianshu.com/p/22df7a214b49

在这篇文章中，我们将研究如何将 Core Image 应用到实时视频上去。我们会看两个例子：首先，我们把这个效果加到相机拍摄的影片上去。之后，我们会将这个影响作用于拍摄好的视频文件。它也可以做到离线渲染，它会把渲染结果返回给视频，而不是直接显示在屏幕上。两个例子的完整源代码，请点击这里。

总览

当涉及到处理视频的时候，性能就会变得非常重要。而且了解黑箱下的原理 —— 也就是 Core Image 是如何工作的 —— 也很重要，这样我们才能达到足够的性能。在 GPU 上面做尽可能多的工作，并且最大限度的减少 GPU 和 CPU 之间的数据传送是非常重要的。之后的例子中，我们将看看这个细节。

想对 Core Image 有个初步认识的话，可以读读 Warren 的这篇文章 Core Image 介绍。我们将使用 Swift 的函数式 API 中介绍的基于 CIFilter 的 API 封装。想要了解更多关于 AVFoundation 的知识，可以看看本期话题中 Adriaan 的文章，还有话题 #21 中的 iOS 上的相机捕捉。

优化资源的 OpenGL ES

CPU 和 GPU 都可以运行 Core Image，我们将会在 下面 详细介绍这两个的细节。在这个例子中，我们要使用 GPU，我们做如下几样事情。

我们首先创建一个自定义的 UIView，它允许我们把 Core Image 的结果直接渲染成 OpenGL。我们可以新建一个 GLKView 并且用一个 EAGLContext 来初始化它。我们需要指定 OpenGL ES 2 作为渲染 API，在这两个例子中，我们要自己触发 drawing 事件 (而不是在 -drawRect: 中触发)，所以在初始化 GLKView 的时候，我们将 enableSetNeedsDisplay 设置为 false。之后我们有可用新图像的时候，我们需要主动去调用 -display。

在这个视图里，我们保持一个对 CIContext 的引用，它提供一个桥梁来连接我们的 Core Image 对象和 OpenGL 上下文。我们创建一次就可以一直使用它。这个上下文允许 Core Image 在后台做优化，比如缓存和重用纹理之类的资源等。重要的是这个上下文我们一直在重复使用。

上下文中有一个方法，-drawImage:inRect:fromRect:，作用是绘制出来一个 CIImage。如果你想画出来一个完整的图像，最容易的方法是使用图像的 extent。但是请注意，这可能是无限大的，所以一定要事先裁剪或者提供有限大小的矩形。一个警告：因为我们处理的是 Core Image，绘制的目标以像素为单位，而不是点。由于大部分新的 iOS 设备配备 Retina 屏幕，我们在绘制的时候需要考虑这一点。如果我们想填充整个视图，最简单的办法是获取视图边界，并且按照屏幕的 scale 来缩放图片 (Retina 屏幕的 scale 是 2)。

完整的代码示例在这里：CoreImageView.swift

从相机获取像素数据

对于 AVFoundation 如何工作的概述，请看 Adriaan 的文章 和 Matteo 的文章 iOS 上的相机捕捉。对于我们而言，我们想从镜头获得 raw 格式的数据。我们可以通过创建一个 AVCaptureDeviceInput 对象来选定一个摄像头。使用 AVCaptureSession，我们可以把它连接到一个 AVCaptureVideoDataOutput。这个 data output 对象有一个遵守 AVCaptureVideoDataOutputSampleBufferDelegate 协议的代理对象。这个代理每一帧将接收到一个消息：

func captureOutput(captureOutput: AVCaptureOutput!,
                   didOutputSampleBuffer: CMSampleBuffer!,
                   fromConnection: AVCaptureConnection!) {

我们将用它来驱动我们的图像渲染。在我们的示例代码中，我们已经将配置，初始化以及代理对象都打包到了一个叫做 CaptureBufferSource 的简单接口中去。我们可以使用前置或者后置摄像头以及一个回调来初始化它。对于每个样本缓存区，这个回调都会被调用，并且参数是缓冲区和对应摄像头的 transform：

source = CaptureBufferSource(position: AVCaptureDevicePosition.Front) {
   (buffer, transform) in
   ...
}

我们需要对相机返回的数据进行变换。无论你如何转动 iPhone，相机的像素数据的方向总是相同的。在我们的例子中，我们将 UI 锁定在竖直方向，我们希望屏幕上显示的图像符合照相机拍摄时的方向，为此我们需要后置摄像头拍摄出的图片旋转 -π/2。前置摄像头需要旋转 -π/2 并且加一个镜像效果。我们可以用一个 CGAffineTransform 来表达这种变换。请注意如果 UI 是不同的方向 (比如横屏)，我们的变换也将是不同的。还要注意，这种变换的代价其实是非常小的，因为它是在 Core Image渲染管线中完成的。

接着，要把 CMSampleBuffer转换成 CIImage，我们首先需要将它转换成一个 CVPixelBuffer。我们可以写一个方便的初始化方法来为我们做这件事：

extension CIImage {
    convenience init(buffer: CMSampleBuffer) {
        self.init(CVPixelBuffer: CMSampleBufferGetImageBuffer(buffer))
    }
}

现在我们可以用三个步骤来处理我们的图像。首先，把我们的 CMSampleBuffer 转换成 CIImage，并且应用一个形变，使图像旋转到正确的方向。接下来，我们用一个 CIFilter 滤镜来得到一个新的 CIImage 输出。我们使用了 Florian 的文章 提到的创建滤镜的方式。在这个例子中，我们使用色调调整滤镜，并且传入一个依赖于时间而变化的调整角度。最终，我们使用之前定义的 View，通过 CIContext 来渲染 CIImage。这个流程非常简单，看起来是这样的：

source = CaptureBufferSource(position: AVCaptureDevicePosition.Front) {
  [unowned self] (buffer, transform) in
    let input = CIImage(buffer: buffer).imageByApplyingTransform(transform)
    let filter = hueAdjust(self.angleForCurrentTime)
    self.coreImageView?.image = filter(input)
}

当你运行它时，你可能会因为如此低的 CPU 使用率感到吃惊。这其中的奥秘是 GPU 做了几乎所有的工作。尽管我们创建了一个 CIImage，应用了一个滤镜，并输出一个 CIImage，最终输出的结果是一个 promise：直到实际渲染才会去进行计算。一个 CIImage 对象可以是黑箱里的很多东西，它可以是 GPU 算出来的像素数据，也可以是如何创建像素数据的一个说明 (比如使用一个滤镜生成器)，或者它也可以是直接从 OpenGL 纹理中创建出来的图像。

从影片中获取像素数据

我们可以做的另一件事是通过 Core Image 把这个滤镜加到一个视频中。和实时拍摄不同，我们现在从影片的每一帧中生成像素缓冲区，在这里我们将采用略有不同的方法。对于相机，它会推送每一帧给我们，但是对于已有的影片，我们使用拉取的方式：通过 display link，我们可以向 AVFoundation 请求在某个特定时间的一帧。

display link 对象负责在每帧需要绘制的时候给我们发送消息，这个消息是按照显示器的刷新频率同步进行发送的。这通常用来做 自定义动画，但也可以用来播放和操作视频。我们要做的第一件事就是创建一个 AVPlayer和一个视频输出：

player = AVPlayer(URL: url)
videoOutput = AVPlayerItemVideoOutput(pixelBufferAttributes: pixelBufferDict)
player.currentItem.addOutput(videoOutput)

接下来，我们要创建 display link。方法很简单，只要创建一个 CADisplayLink 对象，并将其添加到 run loop。

let displayLink = CADisplayLink(target: self, selector: "displayLinkDidRefresh:")
displayLink.addToRunLoop(NSRunLoop.mainRunLoop(), forMode: NSRunLoopCommonModes)

现在，唯一剩下的就是在 displayLinkDidRefresh: 调用的时候获取视频每一帧。首先，我们获取当前的时间，并且将它转换成当前播放项目里的时间比。然后我们询问 videoOutput，如果当前时间有一个可用的新的像素缓存区，我们把它复制一下并且调用回调方法：

func displayLinkDidRefresh(link: CADisplayLink) {
    let itemTime = videoOutput.itemTimeForHostTime(CACurrentMediaTime())
    if videoOutput.hasNewPixelBufferForItemTime(itemTime) {
        let pixelBuffer = videoOutput.copyPixelBufferForItemTime(itemTime, itemTimeForDisplay: nil)
        consumer(pixelBuffer)
    }
}

我们从一个视频输出获得的像素缓冲是一个 CVPixelBuffer，我们可以把它直接转换成 CIImage。正如上面的例子，我们会加上一个滤镜。在这个例子里，我们将组合多个滤镜：我们使用一个万花筒的效果，然后用渐变遮罩把原始图像和过滤图像相结合，这个操作是非常轻量级的。

创意地使用滤镜

大家都知道流行的照片效果。虽然我们可以将这些应用到视频，但 Core Image 还可以做得更多。

Core Image 里所谓的滤镜有不同的类别。其中一些是传统的类型，输入一张图片并且输出一张新的图片。但有些需要两个 (或者更多) 的输入图像并且混合生成一张新的图像。另外甚至有完全不输入图片，而是基于参数的生成图像的滤镜。

通过混合这些不同的类型，我们可以创建意想不到的效果。

混合图片

在这个例子中，我们使用这些东西：

上面的例子可以将图像的一个圆形区域像素化。

它也可以创建交互，我们可以使用触摸事件来改变所产生的圆的位置。

Core Image Filter Reference 按类别列出了所有可用的滤镜。请注意，有一部分只能用在 OS X。

生成器和渐变滤镜可以不需要输入就能生成图像。它们很少自己单独使用，但是作为蒙版的时候会非常强大，就像我们例子中的 CIBlendWithMask 那样。

混合操作和 CIBlendWithAlphaMask 还有 CIBlendWithMask 允许将两个图像合并成一个。

CPU vs. GPU

我们在话题 #3 的文章，绘制像素到屏幕上里，介绍了 iOS 和 OS X 的图形栈。需要注意的是 CPU 和 GPU 的概念，以及两者之间数据的移动方式。

在处理实时视频的时候，我们面临着性能的挑战。

首先，我们需要能在每一帧的时间内处理完所有的图像数据。我们的样本中采用 24 帧每秒的视频，这意味着我们有 41 毫秒 (1/24 秒) 的时间来解码，处理以及渲染每一帧中的百万像素。

其次，我们需要能够从 CPU 或者 GPU 上面得到这些数据。我们从视频文件读取的字节数最终会到达 CPU 里。但是这个数据还需要移动到 GPU 上，以便在显示器上可见。

避免转移

一个非常致命的问题是，在渲染管线中，代码可能会把图像数据在 CPU 和 GPU 之间来回移动好几次。确保像素数据仅在一个方向移动是很重要的，应该保证数据只从 CPU 移动到 GPU，如果能让数据完全只在 GPU 上那就更好。

如果我们想渲染 24 fps 的视频，我们有 41 毫秒；如果我们渲染 60 fps 的视频，我们只有 16 毫秒，如果我们不小心从 GPU 下载了一个像素缓冲到 CPU 里，然后再上传回 GPU，对于一张全屏的 iPhone 6 图像来说，我们在每个方向将要移动 3.8 MB 的数据，这将使帧率无法达标。

当我们使用 CVPixelBuffer 时，我们希望这样的流程：

CVPixelBuffer 是基于 CPU 的 (见下文)，我们用 CIImage 来包装它。构建滤镜链不会移动任何数据；它只是建立了一个流程。一旦我们绘制图像，我们使用了基于 EAGL 上下文的 Core Image 上下文，而这个 EAGL 上下文也是 GLKView 进行图像显示所使用的上下文。EAGL 上下文是基于 GPU 的。请注意，我们是如何只穿越 GPU-CPU 边界一次的，这是至关重要的部分。

工作和目标

Core Image 的图形上下文可以通过两种方式创建：使用 EAGLContext 的 GPU 上下文，或者是基于 CPU 的上下文。

这个定义了 Core Image 工作的地方，也就是像素数据将被处理的地方。与工作区域无关，基于 GPU 和基于 CPU 的图形上下文都可以通过执行 createCGImage(…)，render(, toBitmap, …) 和 render(, toCVPixelBuffer, …)，以及相关的命令来向 CPU 进行渲染。

重要的是要理解如何在 CPU 和 GPU 之间移动像素数据，或者是让数据保持在 CPU 或者 GPU 里。将数据移过这个边界是需要很大的代价的。

缓冲区和图像

在我们的例子中，我们使用了几个不同的缓冲区和图像。这可能有点混乱。这样做的原因很简单，不同的框架对于这些“图像”有不同的用途。下面有一个快速总览，以显示哪些是以基于 CPU 或者基于 GPU 的：

结论

Core Image 是操纵实时视频的一大利器。只要你适当的配置下，性能将会是强劲的 —— 只要确保 CPU 和 GPU 之间没有数据的转移。创意地使用滤镜，你可以实现一些非常炫酷的效果，神马简单色调，褐色滤镜都弱爆啦。所有的这些代码都很容易抽象出来，深入了解下不同的对象的作用区域 (GPU 还是 CPU) 可以帮助你提高代码的性能。

转自：https://www.jianshu.com/p/6c4118290a56

本文是GCD多线程编程中dispatch_semaphore内容的小结，通过本文，你可以了解到：

1、信号量的基本概念与基本使用
2、信号量在线程同步与资源加锁方面的应用
3、信号量释放时的小陷阱

今天我来讲解一下dispatch_semaphore在我们平常开发中的一些基本概念与基本使用，dispatch_semaphore俗称信号量，也称为信号锁，在多线程编程中主要用于控制多线程下访问资源的数量，比如系统有两个资源可以使用，但同时有三个线程要访问，所以只能允许两个线程访问，第三个应当等待资源被释放后再访问，这时我们就可以使用dispatch_semaphore。

与dispatch_semaphore相关的共有3个方法，分别是dispatch_semaphore_create,dispatch_semaphore_wait,dispatch_semaphore_signal下面我们逐一了解一下这三个方法。

测试代码在这

semaphore的三个方法

dispatch_semaphore_create

/*!
 * @function dispatch_semaphore_create
 *
 * @abstract
 * Creates new counting semaphore with an initial value.
 *
 * @discussion
 * Passing zero for the value is useful for when two threads need to reconcile
 * the completion of a particular event. Passing a value greater than zero is
 * useful for managing a finite pool of resources, where the pool size is equal
 * to the value.
 *
 * @param value
 * The starting value for the semaphore. Passing a value less than zero will
 * cause NULL to be returned.
 *
 * @result
 * The newly created semaphore, or NULL on failure.
 */
API_AVAILABLE(macos(10.6), ios(4.0))
DISPATCH_EXPORT DISPATCH_MALLOC DISPATCH_RETURNS_RETAINED DISPATCH_WARN_RESULT
DISPATCH_NOTHROW
dispatch_semaphore_t
dispatch_semaphore_create(long value);

dispatch_semaphore_create方法用于创建一个带有初始值的信号量dispatch_semaphore_t。

对于这个方法的参数信号量的初始值，这里有2种情况：

1、信号量初始值为0时：这种情况主要用于两个线程需要协调特定事件的完成时，即线程同步。
2、信号量初始值为大于0时：这种情况主要用于管理有限的资源池，其中池大小等于这个值，即资源加锁。
上面的2种情况（线程同步、资源加锁），我们在后续的使用篇中会详细讲解。

dispatch_semaphore_wait

/*!
 * @function dispatch_semaphore_wait
 *
 * @abstract
 * Wait (decrement) for a semaphore.
 *
 * @discussion
 * Decrement the counting semaphore. If the resulting value is less than zero,
 * this function waits for a signal to occur before returning.
 *
 * @param dsema
 * The semaphore. The result of passing NULL in this parameter is undefined.
 *
 * @param timeout
 * When to timeout (see dispatch_time). As a convenience, there are the
 * DISPATCH_TIME_NOW and DISPATCH_TIME_FOREVER constants.
 *
 * @result
 * Returns zero on success, or non-zero if the timeout occurred.
 */
API_AVAILABLE(macos(10.6), ios(4.0))
DISPATCH_EXPORT DISPATCH_NONNULL_ALL DISPATCH_NOTHROW
long
dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);

dispatch_semaphore_wait这个方法主要用于等待或减少信号量，每次调用这个方法，信号量的值都会减一，然后根据减一后的信号量的值的大小，来决定这个方法的使用情况，所以这个方法的使用同样也分为2种情况：

1、当减一后的值小于0时，这个方法会一直等待，即阻塞当前线程，直到信号量+1或者直到超时。
2、当减一后的值大于或等于0时，这个方法会直接返回，不会阻塞当前线程。
上面2种方式，放到我们日常的开发中就是下面2种使用情况：

· 当我们只需要同步线程时，我们可以使用dispatch_semaphore_create(0)初始化信号量为0，然后使用dispatch_semaphore_wait方法让信号量减一,这时就属于第一种减一后小于0的情况，这时就会阻塞当前线程，直到另一个线程调用dispatch_semaphore_signal这个让信号量加1的方法后，当前线程才会被唤醒，然后执行当前线程中的代码，这时就起到一个线程同步的作用。

· 当我们需要对资源加锁，控制同时能访问资源的最大数量（假设为n）时，我们就需要使用dispatch_semaphore_create(n)方法来初始化信号量为n，然后使用dispatch_semaphore_wait方法将信号量减一，然后访问我们的资源，然后使用dispatch_semaphore_signal方法将信号量加一。如果有n个线程来访问这个资源，当这n个资源访问都还没有结束时，就会阻塞当前线程，第n+1个线程的访问就必须等待，直到前n个的某一个的资源访问结束，这就是我们很常见的资源加锁的情况。

dispatch_semaphore_signal

/*!
 * @function dispatch_semaphore_signal
 *
 * @abstract
 * Signal (increment) a semaphore.
 *
 * @discussion
 * Increment the counting semaphore. If the previous value was less than zero,
 * this function wakes a waiting thread before returning.
 *
 * @param dsema The counting semaphore.
 * The result of passing NULL in this parameter is undefined.
 *
 * @result
 * This function returns non-zero if a thread is woken. Otherwise, zero is
 * returned.
 */
API_AVAILABLE(macos(10.6), ios(4.0))
DISPATCH_EXPORT DISPATCH_NONNULL_ALL DISPATCH_NOTHROW
long
dispatch_semaphore_signal(dispatch_semaphore_t dsema);

dispatch_semaphore_signal方法用于让信号量的值加一，然后直接返回。如果先前信号量的值小于0，那么这个方法还会唤醒先前等待的线程。

semaphore使用篇

线程同步

这种情况在我们的开发中也是挺常见的，当主线程中有一个异步网络任务，我们需要等这个网络请求成功拿到数据后，才能继续做后面的处理，这时我们就可以使用信号量这种方式来进行线程同步。

我们首先看看完整测试代码：

- (IBAction)threadSyncTask:(UIButton *)sender {
    
    NSLog(@"threadSyncTask start --- thread:%@",[NSThread currentThread]);
    
    //1.创建一个初始值为0的信号量
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
    
    //2.定制一个异步任务
    //开启一个异步网络请求
    NSLog(@"开启一个异步网络请求");
    NSURLSession *session = [NSURLSession sharedSession];
    NSURL *url =
    [NSURL URLWithString:[@"https://www.baidu.com/" stringByAddingPercentEncodingWithAllowedCharacters:[NSCharacterSet URLQueryAllowedCharacterSet]]];
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
    request.HTTPMethod = @"GET";
    
    NSURLSessionDataTask *dataTask = [session dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
        if (error) {
            NSLog(@"%@", [error localizedDescription]);
        }
        if (data) {
            NSDictionary *dict = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableContainers error:nil];
            NSLog(@"%@", dict);
        }
        NSLog(@"异步网络任务完成---%@",[NSThread currentThread]);
        //4.调用signal方法，让信号量+1,然后唤醒先前被阻塞的线程
        NSLog(@"调用dispatch_semaphore_signal方法");
        dispatch_semaphore_signal(semaphore);
    }];
    [dataTask resume];
    
    //3.调用wait方法让信号量-1，这时信号量小于0，这个方法会阻塞当前线程，直到信号量等于0时，唤醒当前线程
    NSLog(@"调用dispatch_semaphore_wait方法");
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    
    NSLog(@"threadSyncTask end --- thread:%@",[NSThread currentThread]);
}

运行之后的log如下：

2019-04-27 17:24:27.050077+0800 GCD(四) dispatch_semaphore[34482:6102243] threadSyncTask end --- thread:<NSThread: 0x6000028aa7c0>{number = 1, name = main}
2019-04-27 17:24:27.050227+0800 GCD(四) dispatch_semaphore[34482:6102243] 开启一个异步网络请求
2019-04-27 17:24:27.050571+0800 GCD(四) dispatch_semaphore[34482:6102243] 调用dispatch_semaphore_wait方法
2019-04-27 17:24:27.105069+0800 GCD(四) dispatch_semaphore[34482:6105851] (null)
2019-04-27 17:24:27.105262+0800 GCD(四) dispatch_semaphore[34482:6105851] 异步网络任务完成---<NSThread: 0x6000028c6ec0>{number = 6, name = (null)}
2019-04-27 17:24:27.105401+0800 GCD(四) dispatch_semaphore[34482:6105851] 调用dispatch_semaphore_signal方法
2019-04-27 17:24:27.105550+0800 GCD(四) dispatch_semaphore[34482:6102243] threadSyncTask end --- thread:<NSThread: 0x6000028aa7c0>{number = 1, name = main}

从log中我们可以看出，wait方法会阻塞主线程，直到异步任务完成调用signal方法，才会继续回到主线程执行后面的任务。

资源加锁

当一个资源可以被多个线程读取修改时，就会很容易出现多线程访问修改数据出现结果不一致甚至崩溃的问题。为了处理这个问题，我们通常使用的办法，就是使用NSLock，@synchronized给这个资源加锁，让它在同一时间只允许一个线程访问资源。其实信号量也可以当做一个锁来使用，而且比NSLock还有@synchronized代价更低一些,接下来我们来看看它的基本使用

第一步，定义2个宏，将wait与signal方法包起来，方便下面的使用

#ifndef ZED_LOCK
#define ZED_LOCK(lock) dispatch_semaphore_wait(lock, DISPATCH_TIME_FOREVER);
#endif

#ifndef ZED_UNLOCK
#define ZED_UNLOCK(lock) dispatch_semaphore_signal(lock);
#endif

第二步，声明与创建共享资源与信号锁

/* 需要加锁的资源 **/
@property (nonatomic, strong) NSMutableDictionary *dict;

/* 信号锁 **/
@property (nonatomic, strong) dispatch_semaphore_t lock;

//创建共享资源
self.dict = [NSMutableDictionary dictionary];
//初始化信号量,设置初始值为1
self.lock = dispatch_semaphore_create(1);

第三步，在即将使用共享资源的地方添加ZED_LOCK宏，进行信号量减一操作,在共享资源使用完成的时候添加ZED_UNLOCK，进行信号量加一操作。

- (IBAction)resourceLockTask:(UIButton *)sender {
    
    NSLog(@"resourceLockTask start --- thread:%@",[NSThread currentThread]);
    
    //使用异步执行并发任务会开辟新的线程的特性，来模拟开辟多个线程访问贡献资源的场景
    
    for (int i = 0; i < 3; i++) {
        
        NSLog(@"异步添加任务:%d",i);
        
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
            
            ZED_LOCK(self.lock);
            //模拟对共享资源处理的耗时
            [NSThread sleepForTimeInterval:1];
            NSLog(@"i:%d --- thread:%@ --- 将要处理共享资源",i,[NSThread currentThread]);
            [self.dict setObject:@"semaphore" forKey:@"key"];
            NSLog(@"i:%d --- thread:%@ --- 共享资源处理完成",i,[NSThread currentThread]);
            ZED_UNLOCK(self.lock);
            
        });
    }
    
    NSLog(@"resourceLockTask end --- thread:%@",[NSThread currentThread]);
}

在这一步中，我们使用异步执行并发任务会开辟新的线程的特性，来模拟开辟多个线程访问贡献资源的场景，同时使用了线程休眠的API来模拟对共享资源处理的耗时。这里我们开辟了3个线程来并发访问这个共享资源，代码运行的log如下：

2019-04-27 18:36:25.275060+0800 GCD(四) dispatch_semaphore[35944:6315957] resourceLockTask start --- thread:<NSThread: 0x60000130e940>{number = 1, name = main}
2019-04-27 18:36:25.275312+0800 GCD(四) dispatch_semaphore[35944:6315957] 异步添加任务:0
2019-04-27 18:36:25.275508+0800 GCD(四) dispatch_semaphore[35944:6315957] 异步添加任务:1
2019-04-27 18:36:25.275680+0800 GCD(四) dispatch_semaphore[35944:6315957] 异步添加任务:2
2019-04-27 18:36:25.275891+0800 GCD(四) dispatch_semaphore[35944:6315957] resourceLockTask end --- thread:<NSThread: 0x60000130e940>{number = 1, name = main}
2019-04-27 18:36:26.276757+0800 GCD(四) dispatch_semaphore[35944:6316211] i:0 --- thread:<NSThread: 0x6000013575c0>{number = 3, name = (null)} --- 将要处理共享资源
2019-04-27 18:36:26.277004+0800 GCD(四) dispatch_semaphore[35944:6316211] i:0 --- thread:<NSThread: 0x6000013575c0>{number = 3, name = (null)} --- 共享资源处理完成
2019-04-27 18:36:27.282099+0800 GCD(四) dispatch_semaphore[35944:6316212] i:1 --- thread:<NSThread: 0x600001357800>{number = 4, name = (null)} --- 将要处理共享资源
2019-04-27 18:36:27.282357+0800 GCD(四) dispatch_semaphore[35944:6316212] i:1 --- thread:<NSThread: 0x600001357800>{number = 4, name = (null)} --- 共享资源处理完成
2019-04-27 18:36:28.283769+0800 GCD(四) dispatch_semaphore[35944:6316214] i:2 --- thread:<NSThread: 0x600001369280>{number = 5, name = (null)} --- 将要处理共享资源
2019-04-27 18:36:28.284041+0800 GCD(四) dispatch_semaphore[35944:6316214] i:2 --- thread:<NSThread: 0x600001369280>{number = 5, name = (null)} --- 共享资源处理完成

从多次log中我们可以看出：

添加信号锁之后，每个线程对于共享资源的操作都是有序的，并不会出现2个线程同时访问锁中的代码区域。

我把上面的实现代码简化一下，方便分析这种锁的实现原理：

//step_1
    ZED_LOCK(self.lock);
    //step_2
    NSLog(@"执行任务");
    //step_3
    ZED_UNLOCK(self.lock);

1、信号量初始化的值为1，当一个线程过来执行step_1的代码时，会调用信号量的值减一的方法，这时，信号量的值为0，它会直接返回，然后执行step_2的代码去完成去共享资源的访问，然后再使用step_3中的signal方法让信号量加一，信号量的值又会回归到初始值1。这就是一个线程过来访问的调用流程。

2、当线程1过来执行到step_2的时候，这时又有一个线程2它也从step_1处来调用这段代码，由于线程1已经调用过step_1的wait方法将信号量的值减一，这时信号量的值为0。同时线程2进入然后调用了step_1的wait方法又将信号量的值减一，这时的信号量的值为-1，由于信号量的值小于0时会阻塞当前线程（线程2），所以，线程2就会一直等待，直到线程1执行完step_3中的方法，将信号量加一，才会唤醒线程2，继续执行下面的代码。这就是为什么信号量可以对共享资源加锁的原因，如果我们可以允许n个线程同时访问，我们就需要在初始化这个信号量时把信号量的值设为n，这样就限制了访问共享资源的线程数。

通过上面的分析，我们可以知道，如果我们使用信号量来进行线程同步时，我们需要把信号量的初始值设为0，如果要对资源加锁，限制同时只有n个线程可以访问的时候，我们就需要把信号量的初始值设为n。

semaphore的释放

在我们平常的开发过程中，如果对semaphore使用不当，就会在它释放的时候遇到奔溃问题。

首先我们来看2个例子：

- (IBAction)crashScene1:(UIButton *)sender {
    
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
    
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    
    //在使用过程中将semaphore置为nil
    semaphore = nil;
}

- (IBAction)crashScene2:(UIButton *)sender {
    
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
    
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    
    //在使用过程中对semaphore进行重新赋值
    semaphore = dispatch_semaphore_create(3);
}

我们打开测试代码，找到semaphore对应的target，然后运行一下代码，然后点击后面2个按钮调用一下上面的代码，然后我们可以发现，代码在运行到semaphore = nil;与semaphore = dispatch_semaphore_create(3);时奔溃了。然后我们使用lldb的bt命令查看一下调用栈。

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x0000000111c31309 libdispatch.dylib`_dispatch_semaphore_dispose + 59
    frame #1: 0x0000000111c2fb06 libdispatch.dylib`_dispatch_dispose + 97
  * frame #2: 0x000000010efb113b GCD(四) dispatch_semaphore`-[ZEDDispatchSemaphoreViewController crashScene1:](self=0x00007fdcfdf0add0, _cmd="crashScene1:", sender=0x00007fdcfdd0a3d0) at ZEDDispatchSemaphoreViewController.m:117
    frame #3: 0x0000000113198ecb UIKitCore`-[UIApplication sendAction:to:from:forEvent:] + 83
    frame #4: 0x0000000112bd40bd UIKitCore`-[UIControl sendAction:to:forEvent:] + 67
    frame #5: 0x0000000112bd43da UIKitCore`-[UIControl _sendActionsForEvents:withEvent:] + 450
    frame #6: 0x0000000112bd331e UIKitCore`-[UIControl touchesEnded:withEvent:] + 583
    frame #7: 0x00000001131d40a4 UIKitCore`-[UIWindow _sendTouchesForEvent:] + 2729
    frame #8: 0x00000001131d57a0 UIKitCore`-[UIWindow sendEvent:] + 4080
    frame #9: 0x00000001131b3394 UIKitCore`-[UIApplication sendEvent:] + 352
    frame #10: 0x00000001132885a9 UIKitCore`__dispatchPreprocessedEventFromEventQueue + 3054
    frame #11: 0x000000011328b1cb UIKitCore`__handleEventQueueInternal + 5948
    frame #12: 0x0000000110297721 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
    frame #13: 0x0000000110296f93 CoreFoundation`__CFRunLoopDoSources0 + 243
    frame #14: 0x000000011029163f CoreFoundation`__CFRunLoopRun + 1263
    frame #15: 0x0000000110290e11 CoreFoundation`CFRunLoopRunSpecific + 625
    frame #16: 0x00000001189281dd GraphicsServices`GSEventRunModal + 62
    frame #17: 0x000000011319781d UIKitCore`UIApplicationMain + 140
    frame #18: 0x000000010efb06a0 GCD(四) dispatch_semaphore`main(argc=1, argv=0x00007ffee0c4efc8) at main.m:14
    frame #19: 0x0000000111ca6575 libdyld.dylib`start + 1
    frame #20: 0x0000000111ca6575 libdyld.dylib`start + 1
(lldb)

从上面的调用栈我们可以看出，奔溃的地方都处于libdispatch库调用dispatch_semaphore_dispose方法释放信号量的时候，为什么在信号量使用过程中对信号量进行重新赋值或置空操作会crash呢，这个我们就需要从GCD的源码层面来分析了，GCD的源码库libdispatch在苹果的开源代码库可以下载，我在自己的Github也放了一份libdispatch-187.10版本的，下面的源码分析都是基于这个版本的。

首先我们来看一下dispatch_semaphore_t的结构体dispatch_semaphore_s的结构体定义

struct dispatch_semaphore_s {
    DISPATCH_STRUCT_HEADER(dispatch_semaphore_s, dispatch_semaphore_vtable_s);
    long dsema_value; //当前的信号值
    long dsema_orig;  //初始化的信号值
    size_t dsema_sent_ksignals;
#if USE_MACH_SEM && USE_POSIX_SEM
#error "Too many supported semaphore types"
#elif USE_MACH_SEM
    semaphore_t dsema_port; //当前mach_port_t信号
    semaphore_t dsema_waiter_port; //休眠时mach_port_t信号
#elif USE_POSIX_SEM
    sem_t dsema_sem;
#else
#error "No supported semaphore type"
#endif
    size_t dsema_group_waiters;
    struct dispatch_sema_notify_s *dsema_notify_head;//链表头部
    struct dispatch_sema_notify_s *dsema_notify_tail;//链表尾部
};

这里我们需要关注2个值的变化，dsema_value与dsema_orig,它们分别代表当前的信号值与初始化时的信号值。

当我们调用dispatch_semaphore_create方法创建信号量时，这个方法内部会把传入的参数存储到dsema_value(当前的value)和dsema_orig(初始value)中，条件是value的值必须大于或等于0。

dispatch_semaphore_t
dispatch_semaphore_create(long value)
{
    dispatch_semaphore_t dsema;

    // If the internal value is negative, then the absolute of the value is
    // equal to the number of waiting threads. Therefore it is bogus to
    // initialize the semaphore with a negative value.
    if (value < 0) {//初始值不能小于0
        return NULL;
    }

    dsema = calloc(1, sizeof(struct dispatch_semaphore_s));//申请信号量的内存

    if (fastpath(dsema)) {//信号量初始化赋值
        dsema->do_vtable = &_dispatch_semaphore_vtable;
        dsema->do_next = DISPATCH_OBJECT_LISTLESS;
        dsema->do_ref_cnt = 1;
        dsema->do_xref_cnt = 1;
        dsema->do_targetq = dispatch_get_global_queue(
                DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
        dsema->dsema_value = value;//当前的值
        dsema->dsema_orig = value;//初始值
#if USE_POSIX_SEM
        int ret = sem_init(&dsema->dsema_sem, 0, 0);//内存空间映射
        DISPATCH_SEMAPHORE_VERIFY_RET(ret);
#endif
    }

    return dsema;
}

然后调用dispatch_semaphore_wait与dispatch_semaphore_signal时会对dsema_value做加一或减一操作。当我们对信号量置空或者重新赋值操作时，会调用dispatch_semaphore_dispose释放信号量，我们来看看对应的源码

static void
_dispatch_semaphore_dispose(dispatch_semaphore_t dsema)
{
    if (dsema->dsema_value < dsema->dsema_orig) {//当前的信号值如果小于初始值就会crash
        DISPATCH_CLIENT_CRASH(
                "Semaphore/group object deallocated while in use");
    }

#if USE_MACH_SEM
    kern_return_t kr;
    if (dsema->dsema_port) {
        kr = semaphore_destroy(mach_task_self(), dsema->dsema_port);
        DISPATCH_SEMAPHORE_VERIFY_KR(kr);
    }
    if (dsema->dsema_waiter_port) {
        kr = semaphore_destroy(mach_task_self(), dsema->dsema_waiter_port);
        DISPATCH_SEMAPHORE_VERIFY_KR(kr);
    }
#elif USE_POSIX_SEM
    int ret = sem_destroy(&dsema->dsema_sem);
    DISPATCH_SEMAPHORE_VERIFY_RET(ret);
#endif

    _dispatch_dispose(dsema);
}

从源码中我们可以看出，当dsema_value小于dsema_orig时，即信号量还在使用时，会直接调用DISPATCH_CLIENT_CRASH让APP奔溃。

所以，我们在使用信号量的时候，不能在它还在使用的时候，进行赋值或者置空的操作。

如果文中有错误的地方，或者与你的想法相悖的地方，请在评论区告知我，我会继续改进，如果你觉得这个篇文章总结的还不错，麻烦动动小手，给我的文章与Git代码样例点个✨

链接：https://www.jianshu.com/p/7981e3357fe9

Clang Attributes是Clang提供的一种源码注解，方便开发者向编译器表达某种要求，参与控制如Static Analyzer、Name Mangling、Code Generation等过程，一般以attribute(xxx)的形式出现在代码中；为方便使用，一些常用属性也被Cocoa定义成宏，比如在系统头文件中经常出现的NS_CLASS_AVAILABLE_IOS(9_0)就是attribute(availability(...))这个属性的简单写法。

※unavailable
#define UNAVAILABLE_ATTRIBUTE __attribute__((unavailable))

可以加在方法声明的后面，告诉编译器该方法不可用

Swift中

@available(*, unavailable)

func foo() {}

@available(iOS, unavailable, message="you can't call this")

func foo2() {}

※availability

#define NS_DEPRECATED_IOS(_iosIntro,_iosDep,...) CF_DEPRECATED_IOS(_iosIntro,_iosDep,__VA_ARGS__)

展开看

#define CF_DEPRECATED_IOS(_iosIntro, _iosDep, ...) __attribute__((availability(ios,introduced=_iosIntro,deprecated=_iosDep,message="" __VA_ARGS__)))

再展开看

__attribute__((availability(ios,introduced=2_0,deprecated=7_0,message=""__VA_ARGS__)))

iOS即是iOS平台

introduced从哪个版本开始使用

deprecated从哪个版本开始弃用

message警告的信息

其实还可以再加一个参数例子：

void f(void) __attribute__((availability(macosx,introduced=10.4,deprecated=10.6,obsoleted=10.7)));

obsoleted完全禁止使用的版本

NS_AVAILABLE_IOS(7_0) iOS7.0或之后才能使用

NS_DEPRECATED_IOS(2_0,6_0) iOS2.0开始使用6.0废弃

Swift中：

@available(iOS 6.0, *)

public var minimumScaleFactor: CGFloat

@available(OSX, introduced=10.4, deprecated=10.6, obsoleted=10.10)

@available(iOS, introduced=5.0, deprecated=7.0)

func foo3() {}

※objc_subclassing_restricted

一句话就是使用这个属性可以定义一个不可被继承的类

__attribute__((objc_subclassing_restricted))

@interface Eunuch : NSObject

@end

@interface Child : Eunuch//如果继承它会报错

@end

在Swift中对原来的很多attribute的支持现在还缺失中，为了达到类似的目的，我们可以使用一个final关键词

※objc_requires_super

使用这个属性标志子类继承这个方法时需要调用super，否则给出编译警告，来让父类中有一些关键代码是在被继承重写后必须执行

#define NS_REQUIRES_SUPER __attribute__((objc_requires_super))

在Switf中也还是可以用final的方法来达到这个目的

Swift equivalent to __attribute((objc_requires_super))?(stackoverflow)

关于Swift中的final的详细讲解

※overloadable

用于C函数，可以定义若干个相同函数名，但参数不同的方法，调用时编译器会自动根据参数选择函数去调用

__attribute__((overloadable))

void logAnything(id obj) {

NSLog(@"%@", obj);

}

__attribute__((overloadable)) void logAnything(int number) {

NSLog(@"%@", @(number));

}

__attribute__((overloadable)) void logAnything(CGRect rect) {

NSLog(@"%@", NSStringFromCGRect(rect));

}

// Tests

logAnything(@[@"1", @"2"]);

logAnything(233);

logAnything(CGRectMake(1, 2, 3, 4));

有兴趣的可以写一个自定义的Log免去用NSLog要写@""等格式的麻烦

※cleanup

__attribute__((cleanup(...)))，用于修饰一个变量，在它的作用域结束时可以自动执行一个指定的方法,个人感觉这个真的很方便

一个对象可以这样用，那么block实际也是一个对象，这样就可以写一个宏，实际上就是ReactiveCocoa中神奇的@onExit

#define onExit\

__strong void(^block)(void) __attribute__((cleanup(blockCleanUp), unused)) = ^

有时候我们需要用到锁这个东西，或者一些CoreFoundation的对象有时候最后需要释放，用这个宏就很方便了

为了好看用这个宏的时候加个@就加个释放池就可以了

sunnyxx这篇博客讲的很清楚

Swift中：可以用defer

还有一些format, const, noreturn, aligned , packed, objc_boxable, constructor / destructor, enable_if, objc_runtime_name可以看这两篇文章：

神奇的attribute

Clang Attributes黑魔法小记

链接：https://www.jianshu.com/p/33d7d0596028

闲话说完，这里先贴上 3.0 版本的 GitHub 链接：ReactiveHttp

3.0 版本的技术栈已更新为了 Kotlin + Jetpack + Coroutines + Retrofit，已托管到 jitpack.io，感兴趣的读者可以直接远程导入依赖

allprojects {
   	repositories {
       maven { url 'https://jitpack.io' }
    }
  }
	
  dependencies {
      implementation 'com.github.leavesC:ReactiveHttp:latest_version'
  }

二、能给你带来什么

ReactiveHttp 能够给你带来什么？

• 更现代化的技术栈。Kotlin + Jetpack + Retrofit 现在应该是大多数 Android 开发者选用的最基础组件了，Kotlin 协程会相对比较少人接触，但我觉得协程也是未来的主流方向之一，毕竟连 Retrofit 也原生支持 Kotlin 协程了，本库会更加符合大多数开发者的现实需求
• 极简的设计理念。ReactiveHttp 目前仅包含十二个 Kotlin 文件，设计上遵循约定大于配置的理念，大多数配置项都可以通过方法复写的形式来实现自定义
• 极简的使用方式。只需要持有一个 RemoteDataSource 对象，开发者就可以在任意地方发起异步请求和同步请求了。此外，进行网络请求 Callback 自然是必不可少的，ReactiveHttp 提供了多个事件回调：onStart、onSuccess、onSuccessIO、onFailed、onFailToast、onCancelled、onFinally 等，按需声明即可，甚至可以完全不用实现
• 支持通用性的自动化行为。对于网络请求来说，像 showLoading、dismissLoading、showToast 等行为是具有通用性的，我们肯定不希望每个网络请求都要来手动调用方法触发以上操作，而是希望能够在发起网络请求的过程中自动完成。ReactiveHttp 就提供了自动完成以上通用性 UI 行为的功能 ，且每个操作均和生命周期相绑定，避免了常见的内存泄漏和 NPE 问题，并提供了交由外部使用者来自定义各种其它行为的入口
• 极低的接入成本。ReactiveHttp 并不强制要求外部必须继承于任何 BaseViewModel 或者是 BaseActivity/BaseFragment，外部只要通过实现 IUIActionEventObserver、IViewModelActionEvent 两个接口即可享受 ReactiveHttp 带来的各个益处。当然，如果你不需要 ReactiveHttp 的自动化行为的话，也可以不实现任何接口
• 支持多个（两个/三个）接口同时并发请求，在网络请求成功时同步回调，所以理论上多个接口的总耗时就取决于耗时最长的那个接口，从而缩短用户的等待时间，提升用户体验

ReactiveHttp 不能带给你什么？

• ReactiveHttp 本身的应用领域是专注于接口请求的，所以对于接口的返回值形式带有强制约束，且没有封装文件下载、文件上传等功能
• 肯定有，但还没想到

ReactiveHttp 目前已经在我司项目上稳定运行一年多了，在这过程中我也是在逐步优化，使其能够更加适用于外部不同环境的需求，到目前为止我觉得也是已经足够稳定了，希望对你有所帮助 😇😇

三、架构说明

现在应该有百分之九十以上的 Android 客户端的网络请求是直接或间接依靠 OkHttp 来完成的吧？本文所说的网络请求框架就是指在 OkHttp 之上所做的一层封装。原生的 OkHttp 在使用上并不方便，甚至可以说是有点繁琐。Retrofit 在易用性上有所提升，但是如果直接使用的话也并不算多简洁。所以我们往往都是会根据项目架构自己来对 OkHttp 或者 Retrofit 进行多一层封装，ReactiveHttp 的实现出发点即是如此

此外，现在大多数项目都引用到了 Jetpack 这一套组件来实现 MVVM 架构的吧？ReactiveHttp 将 Jetpack 和 Retrofit 关联了起来，使得网络请求过程更加符合“响应式”概念，并提供了更加可靠的生命周期安全性和自动化行为

一般的网络请求框架是只专注于完成网络请求并透传出结果，ReactiveHttp 不太一样，ReactiveHttp 在这个基础上还实现了将网络请求和 ViewModel 以及 Activity/Fragment 相绑定的功能，ReactiveHttp 希望做到的是能够尽量完成大多数的通用行为，且每个层次均不强依赖于特定父类

Google 官方曾推出过一份最佳应用架构指南。当中，每个组件仅依赖于其下一级的组件。ViewModel 是关注点分离原则的一个具体实现，是作为用户数据的承载体和处理者而存在的，Activity/Fragment 仅依赖于 ViewModel，ViewModel 就用于响应界面层的输入和驱动界面层变化，Repository 用于为 ViewModel 提供一个单一的数据来源及数据存储域，Repository 可以同时依赖于持久性数据模型和远程服务器数据源

ReactiveHttp 的设计思想类似于 Google 推荐的最佳应用架构指南

• BaseRemoteDataSource 作为数据提供者处于最下层，只用于向上层提供数据，提供了多个同步请求和异步请求方法，和 BaseReactiveViewModel 之间依靠 IUIActionEvent 接口来联系
• BaseReactiveViewModel 作为用户数据的承载体和处理者，包含了多个和网络请求事件相关的 LiveData 用于驱动界面层的 UI 变化，和 BaseReactiveActivity 之间依靠 IViewModelActionEvent 接口来联系
• BaseReactiveActivity 包含与系统和用户交互的逻辑，其负责响应 BaseReactiveViewModel 中的数据变化，提供了和 BaseReactiveViewModel 进行绑定的方法

上文有说到，ReactiveHttp 提供了在网络请求过程中自动完成 showLoading、dismissLoading、showToast 等行为的能力。首先，BaseRemoteDataSource 在网络请求过程中会通过 IUIActionEvent 接口来通知 BaseReactiveViewModel 需要触发的行为，从而连锁触发 ShowLoadingLiveData、DismissLoadingLiveData、ShowToastLiveData 值的变化，BaseReactiveActivity 就通过监听 LiveData 值的变化来完成 UI 层操作

四、惯常做法

以下步骤应该是大部分应用目前进行网络请求时的惯常做法了

服务端返回给移动端的数据使用具有特定格式的 Json 来进行通信，用整数 status 来标明本次请求是否成功，在失败时则直接 showToast(msg)，data则需要用泛型来声明了，最终就对应移动端的一个泛型类，类似于 HttpWrapBean

{
    "status":200,
    "msg":"success",
    "data":""
}

data class HttpWrapBean(val status: Int, val msg: String, val data: T)

interface ApiService {

    @POST("api1")
    fun api1(): ObservableInt>>
    
    @GET("api2")
    fun api2(): Call>

}

然后在 interface 中声明 Api 接口，这也是使用 Retrofit 的惯常用法。根据项目中的实际情况，开发者可能是使用 Call 或者 Observable 作为每个接口返回值的最外层的数据包装类，然后再使用 HttpWrapBean 来作为具体数据类的包装类

然后项目中使用的是 RxJava，那么就需要像以下这样来完成网络请

val retrofit = Retrofit.Builder()
        .baseUrl("https://xxx.com")
        .addConverterFactory(GsonConverterFactory.create())
        .addCallAdapterFactory(RxJava2CallAdapterFactory.create())
        .build()
    val service = retrofit.create(ApiService::class.java)
    val call: ObservableInt>> = service.api1()
    call.subscribe(object : ConsumerInt>> {
        override fun accept(userBean: HttpWrapBean?) {
           
        }

    }, object : Consumer {
        override fun accept(t: Throwable?) {
            
        }
    })

五、简单入门

ReactiveHttp 在使用上会比上面给出的例子简单很多，下面就来看下通过 ReactiveHttp 如何完成网络请求

ReactiveHttp 需要知道网络请求的结果，但不知道外部会使用什么字段名来标识 HttpWrapBean 中的三个值，所以需要外部实现 IHttpWrapBean 接口来进行标明。例如，你可以这样来实现：

data class HttpWrapBean(val status: Int, val msg: String, val data: T) : IHttpWrapBean {

    override val httpCode: Int
        get() = status

    override val httpMsg: String
        get() = msg

    override val httpData: T
        get() = data

    //网络请求是否成功
    override val httpIsSuccess: Boolean
        get() = status == 200

}

用suspend来修饰接口方法，且不需要其它的外层包装类。suspend是 kotlin 协程引入的，当用该关键字修饰接口方法时，Retrofit 内部就会使用协程的方式来完成该网络请求

interface ApiService {

    @GET("config/district")
    suspend fun getProvince(): HttpWrapBean>

}

ReactiveHttp 提供了 RemoteExtendDataSource 交由外部来继承实现。RemoteExtendDataSource 包含了所有的网络请求方法，外部仅需要根据实际情况来实现三个必要的字段和方法即可

• releaseUrl。即应用的 BaseUrl
• createRetrofit。用于创建 Retrofit，开发者可以在这里自定义 OkHttpClient
• showToast。当网络请求失败时，通过该方法来向用户提示失败原因

例如，你可以像以下这样来实现你自己项目的专属 DataSource，当中就包含了开发者整个项目的全局网络请求配置

class SelfRemoteDataSource(iActionEvent: IUIActionEvent?) : RemoteExtendDataSource(iActionEvent, ApiService::class.java) {

    companion object {

        private val httpClient: OkHttpClient by lazy {
            createHttpClient()
        }

        private fun createHttpClient(): OkHttpClient {
            val builder = OkHttpClient.Builder()
                    .readTimeout(1000L, TimeUnit.MILLISECONDS)
                    .writeTimeout(1000L, TimeUnit.MILLISECONDS)
                    .connectTimeout(1000L, TimeUnit.MILLISECONDS)
                    .retryOnConnectionFailure(true)
                    .addInterceptor(FilterInterceptor())
                    .addInterceptor(MonitorInterceptor(MainApplication.context))
            return builder.build()
        }

    }

    /**
     * 由子类实现此字段以便获取 release 环境下的接口 BaseUrl
     */
    override val releaseUrl: String
        get() = "https://restapi.amap.com/v3/"

    /**
     * 允许子类自己来实现创建 Retrofit 的逻辑
     * 外部无需缓存 Retrofit 实例，ReactiveHttp 内部已做好缓存处理
     * 但外部需要自己判断是否需要对 OKHttpClient 进行缓存
     * @param baseUrl
     */
    override fun createRetrofit(baseUrl: String): Retrofit {
        return Retrofit.Builder()
                .client(httpClient)
                .baseUrl(baseUrl)
                .addConverterFactory(GsonConverterFactory.create())
                .build()
    }

    override fun showToast(msg: String) {
        Toast.makeText(MainApplication.context, msg, Toast.LENGTH_SHORT).show()
    }

}

之后，我们就可以依靠 SelfRemoteDataSource 在任意地方发起网络请求了，按需声明 Callback 方法。此外，由于使用到了扩展函数，所以 SelfRemoteDataSource 中可以直接调用 ApiService 中的接口方法，无需特意引用和导包

六、进阶使用

上述在使用 SelfRemoteDataSource 发起网络请求时虽然调用的是 enqueueLoading 方法，但实际上并不会弹出 loading 框，因为完成 ShowLoading、DismissLoading、ShowToast 等 UI 行为是需要 RemoteDataSource、ViewModel 和 Activity 这三者一起进行配合的，即 SelfRemoteDataSource 需要和其它两者关联上，将需要触发的 UI 行为反馈给 Activity

这可以通过直接继承于 BaseReactiveActivity 和 BaseReactiveViewModel 来实现，也可以通过实现相应接口来完成关联。当然，如果你不需要 ReactiveHttp 的各个自动化行为的话，也可以不做以下任何改动

总的来说，ReactiveHttp 具有极低的接入成本

1、BaseReactiveActivity

BaseReactiveActivity 是 ReactiveHttp 提供的一个默认 BaseActivity，其实现了 IUIActionEventObserver 接口，用于提供一些默认参数和默认行为，例如 CoroutineScope 和 showLoading。但在大多数情况下，我们自己的项目是不会去继承外部 Activity 的，而是会有一个自己实现的全局统一的 BaseActivity，所以如果你不想继承 BaseReactiveActivity 的话，可以自己来实现 IUIActionEventObserver 接口，就像以下这样

@SuppressLint("Registered")
abstract class BaseActivity : AppCompatActivity(), IUIActionEventObserver {

    protected inline fun  getViewModel(
        factory: ViewModelProvider.Factory? = null,
        noinline initializer: (VM.(lifecycleOwner: LifecycleOwner) -> Unit)? = null
    ): Lazy where VM : ViewModel, VM : IViewModelActionEvent {
        return getViewModel(VM::class.java, factory, initializer)
    }

    override val lifecycleSupportedScope: CoroutineScope
        get() = lifecycleScope

    override val lContext: Context?
        get() = this

    override val lLifecycleOwner: LifecycleOwner
        get() = this

    private var loadDialog: ProgressDialog? = null

    override fun showLoading(job: Job?) {
        dismissLoading()
        loadDialog = ProgressDialog(lContext).apply {
            setCancelable(true)
            setCanceledOnTouchOutside(false)
            //用于实现当弹窗销毁的时候同时取消网络请求
//            setOnDismissListener {
//                job?.cancel()
//            }
            show()
        }
    }

    override fun dismissLoading() {
        loadDialog?.takeIf { it.isShowing }?.dismiss()
        loadDialog = nul
}

2、BaseReactiveViewModel

类似地，BaseReactiveViewModel 是 ReactiveHttp 提供的一个默认的 BaseViewModel，其实现了 IViewModelActionEvent 接口，用于接收 RemoteDataSource 发起的 UI 层行为。如果你不希望继承于 BaseReactiveViewModel 的话，可以自己来实现 IViewModelActionEvent 接口，就像以下这样

open class BaseViewModel : ViewModel(), IViewModelActionEvent {

    override val lifecycleSupportedScope: CoroutineScope
        get() = viewModelScope

    override val showLoadingEventLD = MutableLiveData()

    override val dismissLoadingEventLD = MutableLiveData()

    override val showToastEventLD = MutableLiveData()

    override val finishViewEventLD = MutableLiveData()

}

3、关联上

完成以上两步后，开发者就可以像如下所示这样将 RemoteDataSource、ViewModel 和 Activity 这三者给关联起来。WeatherActivity 通过 getViewModel 方法来完成 WeatherViewModel 的初始化和内部多个 UILiveData 的绑定，并在 lambda 表达式中完成对 WeatherViewModel 内部和具体业务相关的 DataLiveData 的数据监听，至此所有自动化行为就都已经绑定上了

class WeatherViewModel : BaseReactiveViewModel() {

    private val remoteDataSource by lazy {
        SelfRemoteDataSource(this)
    }

    val forecastsBeanLiveData = MutableLiveData()

    fun getWeather(city: String) {
        remoteDataSource.enqueue({
            getWeather(city)
        }) {
            onSuccess {
                if (it.isNotEmpty()) {
                    forecastsBeanLiveData.value = it[0]
                }
            }
        }
    }

}

class WeatherActivity : BaseReactiveActivity() {

    private val weatherViewModel by getViewModel {
        forecastsBeanLiveData.observe(this@WeatherActivity, {
            showWeather(it)
        })
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_weather)
        weatherViewModel.getWeather("adCode")
    }

    private fun showWeather(forecastsBean: ForecastsBean) {

    }

}

七、其它

1、BaseRemoteDataSource

RemoteExtendDataSource 提供了许多个可以进行复写的方法，既可用于配置 OkHttp 的各个网络请求参数，也用于交由外部进行流程控制。例如，你可以这样来实现自己项目的 BaseRemoteDataSource

class BaseRemoteDataSource(iActionEvent: IUIActionEvent?) : RemoteExtendDataSource(iActionEvent, ApiService::class.java) {

    companion object {

        private val httpClient: OkHttpClient by lazy {
            createHttpClient()
        }

        private fun createHttpClient(): OkHttpClient {
            val builder = OkHttpClient.Builder()
                    .readTimeout(1000L, TimeUnit.MILLISECONDS)
                    .writeTimeout(1000L, TimeUnit.MILLISECONDS)
                    .connectTimeout(1000L, TimeUnit.MILLISECONDS)
                    .retryOnConnectionFailure(true)
                    .addInterceptor(FilterInterceptor())
                    .addInterceptor(MonitorInterceptor(MainApplication.context))
            return builder.build()
        }
    }

    /**
     * 由子类实现此字段以便获取 release 环境下的接口 BaseUrl
     */
    override val releaseUrl: String
        get() = HttpConfig.BASE_URL_MAP

    /**
     * 允许子类自己来实现创建 Retrofit 的逻辑
     * 外部无需缓存 Retrofit 实例，ReactiveHttp 内部已做好缓存处理
     * 但外部需要自己判断是否需要对 OKHttpClient 进行缓存
     * @param baseUrl
     */
    override fun createRetrofit(baseUrl: String): Retrofit {
        return Retrofit.Builder()
                .client(httpClient)
                .baseUrl(baseUrl)
                .addConverterFactory(GsonConverterFactory.create())
                .build()
    }

    /**
     * 如果外部想要对 Throwable 进行特殊处理，则可以重写此方法，用于改变 Exception 类型
     * 例如，在 token 失效时接口一般是会返回特定一个 httpCode 用于表明移动端需要去更新 token 了
     * 此时外部就可以实现一个 BaseException 的子类 TokenInvalidException 并在此处返回
     * 从而做到接口异常原因强提醒的效果，而不用去纠结 httpCode 到底是多少
     */
    override fun generateBaseException(throwable: Throwable): BaseHttpException {
        return if (throwable is BaseHttpException) {
            throwable
        } else {
            LocalBadException(throwable)
        }
    }

    /**
     * 用于由外部中转控制当抛出异常时是否走 onFail 回调，当返回 true 时则回调，否则不回调
     * @param httpException
     */
    override fun exceptionHandle(httpException: BaseHttpException): Boolean {
        return true
    }

    /**
     * 用于将网络请求过程中的异常反馈给外部，以便记录
     * @param throwable
     */
    override fun exceptionRecord(throwable: Throwable) {
        Log.e("SelfRemoteDataSource", throwable.message ?: "")
    }

    /**
     * 用于对 BaseException 进行格式化，以便在请求失败时 Toast 提示错误信息
     * @param httpException
     */
    override fun exceptionFormat(httpException: BaseHttpException): String {
        return when (httpException.realException) {
            null -> {
                httpException.errorMessage
            }
            is ConnectException, is SocketTimeoutException, is UnknownHostException -> {
                "连接超时，请检查您的网络设置"
            }
            else -> {
                "请求过程抛出异常：" + httpException.errorMessage
            }
        }
    }

    override fun showToast(msg: String) {
        Toast.makeText(MainApplication.context, msg, Toast.LENGTH_SHORT).show()
    }

}

此外，开发者可以直接在自己的 BaseViewModel 中声明一个 BaseRemoteDataSource 变量实例，所有子 ViewModel 都全局统一使用同一份 DataSource 配置。如果有某些特定接口需要使用不同的 BaseUrl 的话，也可以再多声明一个 BaseRemoteDataSource

open class BaseViewModel : BaseReactiveViewModel() {

    /**
     * 正常来说单个项目中应该只有一个 RemoteDataSource 实现类，即全局使用同一份配置
     * 但父类也应该允许子类使用一个独有的 RemoteDataSource，即允许子类复写此字段
     */
    protected open val remoteDataSource by lazy {
        BaseRemoteDataSource(this)
    }

}

2、BaseHttpException

BaseHttpException 是 ReactiveHttp 对网络请求过程中发生的各类异常情况的包装类，任何透传到外部的异常信息均会被封装为 BaseHttpException 类型。BaseHttpException 有两个默认子类，分别用于表示服务器异常和本地异

/**
 * @param errorCode        服务器返回的错误码 或者是 HttpConfig 中定义的本地错误码
 * @param errorMessage     服务器返回的异常信息 或者是 请求过程中抛出的信息，是最原始的异常信息
 * @param realException    用于当 code 是本地错误码时，存储真实的运行时异常
 */
open class BaseHttpException(val errorCode: Int, val errorMessage: String, val realException: Throwable?) : Exception(errorMessage) {

    companion object {

        /**
         * 此变量用于表示在网络请求过程过程中抛出了异常
         */
        const val CODE_ERROR_LOCAL_UNKNOWN = -1024520

    }

    /**
     * 是否是由于服务器返回的 code != successCode 导致的异常
     */
    val isServerCodeBadException: Boolean
        get() = this is ServerCodeBadException

    /**
     * 是否是由于网络请求过程中抛出的异常（例如：服务器返回的 Json 解析失败）
     */
    val isLocalBadException: Boolean
        get() = this is LocalBadException

}

/**
 * API 请求成功了，但 code != successCode
 * @param errorCode
 * @param errorMessage
 */
class ServerCodeBadException(errorCode: Int, errorMessage: String) : BaseHttpException(errorCode, errorMessage, null) {

    constructor(bean: IHttpWrapBean<*>) : this(bean.httpCode, bean.httpMsg)

}

/**
 * 请求过程抛出异常
 * @param throwable
 */
class LocalBadException(throwable: Throwable) : BaseHttpException(CODE_ERROR_LOCAL_UNKNOWN, throwable.message?: "", throwable)

有时候开发者需要对某些异常情况进行特殊处理，此时就可以来实现自己的 BaseHttpException 子类。例如，在 token 失效时接口一般是会返回特定一个 httpCode 用于表明移动端需要去更新 token 了，此时开发者就可以实现一个 BaseHttpException 的子类 TokenInvalidException 并在 BaseRemoteDataSource 中进行返回，从而做到接口异常原因强提醒的效果，而不用去纠结 httpCode 到底是多少

class TokenInvalidException : BaseHttpException(CODE_TOKEN_INVALID, "token已失效", null)

open class BaseRemoteDataSource(iActionEvent: IUIActionEvent?) : RemoteExtendDataSource(iActionEvent, ApiService::class.java) {

    companion object {

        private val httpClient: OkHttpClient by lazy {
            createHttpClient()
        }

        private fun createHttpClient(): OkHttpClient {
            val builder = OkHttpClient.Builder()
                    .readTimeout(1000L, TimeUnit.MILLISECONDS)
                    .writeTimeout(1000L, TimeUnit.MILLISECONDS)
                    .connectTimeout(1000L, TimeUnit.MILLISECONDS)
                    .retryOnConnectionFailure(true)
                    .addInterceptor(FilterInterceptor())
                    .addInterceptor(MonitorInterceptor(MainApplication.context))
            return builder.build()
        }
    }

    /**
     * 由子类实现此字段以便获取 release 环境下的接口 BaseUrl
     */
    override val releaseUrl: String
        get() = "https://restapi.amap.com/v3/"

    /**
     * 允许子类自己来实现创建 Retrofit 的逻辑
     * 外部无需缓存 Retrofit 实例，ReactiveHttp 内部已做好缓存处理
     * 但外部需要自己判断是否需要对 OKHttpClient 进行缓存
     * @param baseUrl
     */
    override fun createRetrofit(baseUrl: String): Retrofit {
        return Retrofit.Builder()
                .client(httpClient)
                .baseUrl(baseUrl)
                .addConverterFactory(GsonConverterFactory.create())
                .build()
    }

    /**
     * 如果外部想要对 Throwable 进行特殊处理，则可以重写此方法，用于改变 Exception 类型
     * 例如，在 token 失效时接口一般是会返回特定一个 httpCode 用于表明移动端需要去更新 token 了
     * 此时外部就可以实现一个 BaseException 的子类 TokenInvalidException 并在此处返回
     * 从而做到接口异常原因强提醒的效果，而不用去纠结 httpCode 到底是多少
     */
    override fun generateBaseException(throwable: Throwable): BaseHttpException {
        if (throwable is ServerCodeBadException && throwable.errorCode == BaseHttpException.CODE_TOKEN_INVALID) {
            return TokenInvalidException()
        }
        return if (throwable is BaseHttpException) {
            throwable
        } else {
            LocalBadException(throwable)
        }
    }

    /**
     * 用于由外部中转控制当抛出异常时是否走 onFail 回调，当返回 true 时则回调，否则不回调
     * @param httpException
     */
    override fun exceptionHandle(httpException: BaseHttpException): Boolean {
        return httpException !is TokenInvalidException
    }

    override fun showToast(msg: String) {
        Toast.makeText(MainApplication.context, msg, Toast.LENGTH_SHORT).show()
    }
 }

写码写累了不如来看看这些奇奇怪怪的css，腰不酸腿不疼，一阵轻松加愉快（还能偷我表情包）

子元素的绝对定位原点在哪？

用了那么久的定位，有注意过子元素的绝对定位原点，是在盒子模型的哪一处，在 padding、border 还是 content？

实践出真知。既然不确定那就实操个例子看看。

<div class="father">
 father
 <div class="child">child</div>
</div>

body {
 background-color: rgb(20, 19, 19);
}

.father {
 width: 300px;
 height: 300px;
 margin: 40px;
 border: 20px solid rgb(202, 30, 30);
 padding: 40px;
 position: relative;
 background-color: #eee;
}

.child {
 width: 50px;
 height: 50px;
 position: absolute;
 top: 0;
 left: 0;
 background-color: rgb(228, 207, 17);
}

在 Chrome 90 的版本下的表现。

<body>
 I am body
 <div class="absolute">I am absoluted</div>
</body>

html {
 background-color: #fff;
}

body {
 height: 50vh;
 background-color: #ddd;
}
.absolute {
 width: 120px;
 height: 50px;
 position: absolute;
 bottom: 0;
 left: 0;
 background-color: rgb(0, 0, 0);
 color: #fff;
}

从结果上看，绝对定位的元素并不是相对于 body 进行定位的，也不是根据 html 标签，此时的 html 的宽高等同于 body 的宽高，而是根据浏览器视口进行定位的。

所有父元素position 的属性是static 的时候，绝对定位的元素会被包含在初始包含块中，初始包含块有着和浏览器视口一样的大小，所以从表现上来看，就是绝对定位的元素是根据浏览器视口定位。

如果把top和left去掉，那么位置依旧是他原来文档流的位置，只是不占空间了，后面的元素会窜上来。

通过 HTML 结构控制层叠上下文

在使用定位属性时，必不可少的使用 z-index 属性，使用 z-index 属性会创建一个层叠上下文。z-index 值不会在整个文档中进行比较，而只会在该层叠上下文中进行比较。

<div class="bar"></div>
<div class="container">
 <div class="bottom-box-1">
  <div class="top-box"></div>
 </div>
</div>
<div class="container">
 <div class="box-container">
  <div class="bottom-box-2"></div>
  <div class="top-box"></div>
 </div>
</div>

body {
 display: flex;
 justify-content: center;
 align-items: center;
 height: 90vh;
}
.bar {
 position: absolute;
 top: 65vh;
 z-index: 2;
 width: 100vw;
 height: 20px;
 background: #8bbe6e;
}

.top-box {
 position: absolute;
 z-index: 3;
 top: 50%;
 left: 50%;
 transform: translate(-50%, -50%);
 width: 50%;
 height: 50%;
 background: #626078;
 filter: brightness(60%);
}

.bottom-box-1 {
 position: absolute;
 top: 45%;
 z-index: 1;
 transition: top 1s;
 width: 40px;
 height: 40px;
 background: #626078;
}

.container:hover .bottom-box-1 {
 top: 72%;
}

.box-container {
 position: absolute;
 top: 45%;
 transition: top 1s;
}

.bottom-box-2 {
 position: relative;
 z-index: 1;
 width: 40px;
 height: 40px;
 background: #626078;
}

.container {
 border: 2px dashed #626078;
 height: 80%;
 width: 100px;
 margin: 20px;
 padding: 10px;
 display: flex;
 flex-direction: column;
 align-items: center;
 text-align: center;
}

.container:hover .box-container {
 top: 72%;
}

鼠标分别移入两个虚线框内，我们发现，第二个例子 bar 穿过了两个正方形。

这两者的区别就在于 HTML 结构，在第一个例子中，小正方形在大正方形的里面，大正方形在移动的时候，小正方形也随之移动，但是因为大正方形对决定位且有 z-index 属性不为 auto，因此创建了一个层叠上下文，这导致大正方形内的所有元素都是在这个层叠上下文里层叠。

那么第二个例子是怎么解决的呢？

第二个例子的技巧在于引入了一个新的 div 来包裹这两个正方形，这个新的 div 只负责移动。而里面的大小正方形和 bar 处于同一个层叠上下文中。这样子就可以产生 bar 从两个正方形中穿过的效果。

还没懂的来看图来看图：

总结一下创建层叠上下文的几种情况（别怪我枯燥，就是这么多）：

• 文档根元素<html>;


• position 值为 relative（相对定位）或 absolute（绝对定位）且 z-index 值不为 auto 的元素;


• position 值为 fixed（固定定位）或 sticky（粘滞定位）的元素;


• flex (flexbox) 容器的子元素，且 z-index 值不为 auto;


• grid 容器的子元素，且 z-index 值不为 auto;


• opacity 属性值小于 1 的元素;


• mix-blend-mode 属性值不为 normal 的元素;


• 以下任意属性值不为 none 的元素：
  
  
  
  • transform
  
  
  • filter
  
  
  • perspective
  
  
  • clip-path
  
  
  • mask / mask-image / mask-border
  
  
  
  


• isolation 属性值为 isolate 的元素；


• -webkit-overflow-scrolling 属性值为 touch 的元素；


• will-change 值设定了任一属性而该属性在 non-initial 值时会创建层叠上下文的元素


• contain 属性值为 layout、paint 或包含它们其中之一的合成值（比如 contain: strict、contain: content）的元素;

好了，你学废了嘛~

当定位遇到 Transform

transform 下 absolute 宽度被限制

以前，我们设置 absolute 元素宽度 100%, 则都会参照第一个非static值的position祖先元素计算，没有就window. 现在，=-=，需要把transform也考虑在内了。

默认情况下我们设置 absolute 的宽度 100%，会根据第一个不是static的祖先元素计算，没有就找视口宽度。现在也考虑 CSS3 的 transform 属性了。

<div class="relative">
        <div class="transform">
            <div class="absolute">i am in transform</div>
        </div>
    </div>
    <div class="relative">
        <div class="no-transform">
            <div class="absolute">i am not in transform</div>
        </div>
    </div>

.relative {
 position: relative;
 width: 400px;
 height: 100px;
 background-color: rgb(233, 233, 233);
}

.transform {
 transform: rotate(0);
 width: 200px;
}

.no-transform {
 width: 200px;
}

.absolute {
 position: absolute;
 width: 100%;
 height: 100px;
 background-color: rgb(137, 174, 255);
}

可以看到绝对定位的宽度是相对 transform 的大小计算了。

transform 对 fixed 的限制

身为大聪明的你，加了一行position:fixed安心上线，结果预览机一瞅，没生效？？

position:fixed 正常情况下可以让元素不跟随滚动条滚动，这种行为也无法通过 relative/absolute 来限制。但是遇到 transform，他就被打败了，降级成 absolute。

<div class="demo">
        <div class="box">
            <div class="fixed">
                <p>没有transform</p>
                <img src="https://gitee.com/zukunft/MDImage/raw/master/img/20210516172759.jpg" alt="">
            </div>
        </div>

        <div class="relative box">
            <div class="fixed">
                <p> 有relative</p>
                <img src="https://gitee.com/zukunft/MDImage/raw/master/img/20210516172759.jpg" alt="">
            </div>
        </div>
        <div class="transform box">
            <div class="fixed">
                <p>有transform</p>
                <img src="https://gitee.com/zukunft/MDImage/raw/master/img/20210516172759.jpg" alt="">
            </div>
        </div>
    </div>

.box {
  height: 250px;
}

.demo {
  height: 9999px;
}


.fixed {
  position: fixed;
}

.relative {
  position: relative;
}

.transform {
  transform: scale(1);
}

诶，神奇不，滚起来了，就只有被transform包裹的元素会被滚走。
根据W3C的定义，transform属性值会使元素成为一个包含块，它的后代包括absolute元素，fixed元素受限在其 padding box 区域。所以滚动的时候，transform元素被滚走，其子元素也跟随tranform滚走。

关于包含块

上面提到了包含块，那到底如何形成的包含块，包含块又是个啥子

在 MDN 中的解释

The size and position of an element are often impacted by its containing block. Percentage values that are applied to the width, height, padding, margin, and offset properties of an absolutely positioned element (i.e., which has its positionset to absolute or fixed) are computed from the element's containing block.

即一个元素的尺寸和位置受到它的**包含块(containing block)**的影响。对于一些属性，例如 width, height, padding, margin，绝对定位元素的偏移值 （比如 position 被设置为 absolute 或 fixed），当我们设置百分比值的时候，它的这些值计算，就是通过该元素的包含块的值来计算的。

通常情况下，包含块就是这个元素最近的祖先块元素的内容区域，但实际可能不是；

我们可以通过 position 的属性来确定它的包含块；

1. 如果 position 属性为 static 、 relative 或 sticky，包含块可能由它的最近的祖先块元素（比如说 inline-block, block 或 list-item 元素）的内容区的边缘组成，也可能会建立格式化上下文(比如说 table container,flex container, grid container, 或者是 block container 自身)


2. 如果 position 属性为 **absolute** ，包含块就是由它的最近的 position 的值不是 static （也就是值为fixed, absolute, relative 或 sticky）的祖先元素的内边距区的边缘组成。


3. 如果 position 属性是 fixed，在连续媒体的情况下(continuous media)包含块是 viewport ,在分页媒体(paged media)下的情况下包含块是分页区域(page area)。


4. 如果 position 属性是 absolute 或 fixed，包含块也可能是由满足以下条件的最近父级元素的内边距区的边缘组成的：
   
   
   
   1. transform 或 perspective的值不是 none
   
   
   2. will-change 的值是 transform 或 perspective
   
   
   3. filter的值不是 none 或 will-change 的值是 filter(只在 Firefox 下生效).
   
   
   4. contain 的值是 paint (例如: contain: paint;)
   
   
   
   

需要注意的是根元素(<html>)所在的包含块是一个被称为初始包含块的矩形。他的尺寸是视口 viewport (for continuous media) 或分页媒体 page media (for paged media).

如果所有的父元素都没有显式地定义position属性，那么所有的父元素默认情况下 position 属性都是static。结果，绝对定位元素会被包含在初始包含块中；这个初始块容器有着和浏览器视口一样的尺寸，并且<html>元素也被包含在这个容器里面。简单来说，绝对定位元素会被放在<html>元素的外面，并且根据浏览器视口来定位。

总结

遇到奇奇怪怪的css问题不要慌~硬调不是好办法不如来我这瞅瞅~~ 万一就解决了呢✿✿ヽ(°▽°)ノ✿

链接：https://juejin.cn/post/6963235293587750943

前段时间协助完成作家的盘点活动，设计大大给的视觉稿如下图。最初拿到稿子时，以为是一个简单的常规活动，实际在完成这个活动的过程中有一点点小波折，自己也在这个过程中学习到了关于垂直排版的知识点，下面来跟大家描述做这个活动的心路历程，一起探索垂直排版的奥秘~

p标签示例代码如下：

<p class="text-vertical">爱交流，也爱独处</p>

.text-vertical {
  writing-mode: vertical-rl;
}

一顿页面基础布局下来，可以看到页面效果和设计稿还是有差异😔，具体如下图的红色框线内；设计稿中红色框线内的数字是“直立向上”展示的

感觉页面还原的展示也无伤大雅，于是拿着对比图找设计大大沟通；但是设计大大还是比较坚持视觉稿上的数字展示效果，以便更好传达活动内的关键信息（用户不需要旋转手机 or 侧头即可快速看清数据

text-orientation: upright 可以将垂直排版的（设置了 writing-mode，且值不为 horizontal-tb）内容均直立向上展示

在之前的示例基础上，添加 text-orientation: upright 即可实现将数字直立向上展示，面效果可以看下方图片中红色线框内数字

p标签示例代码见下方：

<p class="text-vertical">999篇日记，12356万字</p>
.text-vertical {
    writing-mode: vertical-rl;
    text-orientation: upright;
    -webkit-text-orientation: upright;
  }

调整完成后，活动大体完成，活动进入测试阶段；活动提测后，测试随口提了一句“这个日期看着有一点点不方便”

虽然测试只是随口一说，但我就放在了心上，思考有没有可能优化一下这个日期显示呢？念念不忘，必有回响，偶然发现 text-combine-upright 的属性可以解决此类竖排横向合并

<p class="text-vertical">
  <span class="upright-combine">10</span>月
  <span class="upright-combine">1</span>日时光日记上线
</p>

.text-vertical {
   writing-mode: vertical-rl;
   text-orientation: upright;
}
.upright-combine {
   /* for IE11+ */
  -ms-text-combine-horizontal: all;
  /* for Chrome/Firefox */
  text-combine-upright: all;
  /* for Safari */
  -webkit-text-combine: horizontal;
}

.upright-combine {
  /* for IE11+ */
  -ms-text-combine-horizontal: all;
  text-combine-upright: all;
  /* forSafari */
  -webkit-text-combine: horizontal;
}

function text2html(element) {
  var treeWalker = document.createTreeWalker(element, NodeFilter.SHOW_TEXT);
  var node;
  let list = []
  while ((node = treeWalker.nextNode())) {
    list.push(node)
  }
  // 纯文本节点数组遍历
  list.forEach(function(node) {
    // 纯文本节点切割，替换为span标签
    var replaceArr = node.textContent.split('').map(function(str) {
      var newSpan = document.createElement('span');
      newSpan.textContent = str;
      return newSpan;
    });
    node.replaceWith.apply(node, replaceArr);
  })
}

// 数字半转全 0-9 对应 半角对应48-57，全角对应65296-65305
function ToDBC(txtstring) {
    var newNumber = "";
    for(var i = 0; i < txtstring.length; i++) {
        if(txtstring.charCodeAt(i) <= 57 && txtstring.charCodeAt(i) >= 48) {
            newNumber = newNumber + String.fromCharCode(txtstring.charCodeAt(i)+65248);
        } else {
            newNumber = newNumber + txtstring.substring(i, i+1);
        }
    }
    return newNumber;
}

话不多，先看效果：

 回归老本行，继续分享简单有趣的CSS创意特效，放松放松心情~

实现过程（完整源码在最后）：

1 老样子，定义基本样式：

*{
             margin: 0;
            padding: 0;
            box-sizing: border-box;
            font-family: 'fangsong';
        }
        body{
            height: 100vh;
            display: flex;
            align-items: center;
            justify-content: center;
            background-color: rgb(0, 0, 0);
        }

font-family: 'fangsong'; 仿宋字体。 display: flex; align-items: center; justify-content: center; flex布局，让按钮在屏幕居中。

2.定义基本标签：

        
            aurora
            
            
            
            
            
        
            aurora
            
            
            
            
        
        
            aurora
            
            
            
            
        

3个a标签就对应3个按钮，每个按钮里4个span就是环绕按钮的4条边。 且都有个公共的选择器 .item 和 只属于自己的选择器。

3.定义每个按钮的基本样式：

    .item{
            position: relative;
            margin: 50px;
            width: 300px;
            height: 80px;
            text-align: center;
            line-height: 80px;
            text-transform: uppercase;
            text-decoration: none;
            font-size: 35px;
            letter-spacing: 5px;
            color: aqua;
            overflow: hidden;
            -webkit-box-reflect: below 1px linear-gradient( transparent,rgba(6, 133, 133,0.3));
        }

.item:hover{
            background-color: aqua;
            box-shadow:0 0 5px aqua,
            0 0 75px aqua,
            0 0 155px aqua;
            color: black;
        }

    .item span:nth-of-type(1){
            position: absolute;
            left: -100%; 
            width: 100%;
            height: 3px;
            background-image: linear-gradient(to left,aqua ,transparent);
            animation: shang 1s linear infinite;
        }
        @keyframes shang{
            0%{
                left:-100%;
            }
            50%,100%{
                left:100%;
            }
        }

.item span:nth-of-type(2) {
  position: absolute;
  top: -100%;
  right: 0;
  width: 3px;
  height: 100%;
  background-image: linear-gradient(to top, aqua, transparent);
  animation: you 1s linear infinite;
  animation-delay: 0.25s;
}
@keyframes you {
  0% {
    top: -100%;
  }
  50%,
  100% {
    top: 100%;
  }
}
.item span:nth-of-type(3) {
  position: absolute;
  right: -100%;
  bottom: 0;
  width: 100%;
  height: 3px;
  background-image: linear-gradient(to right, aqua, transparent);
  animation: xia 1s linear infinite;
  animation-delay: 0.5s;
}
@keyframes xia {
  0% {
    right: -100%;
  }
  50%,
  100% {
    right: 100%;
  }
}
.item span:nth-of-type(4) {
  position: absolute;
  bottom: -100%;
  left: 0;
  width: 3px;
  height: 100%;
  background-image: linear-gradient(to bottom, aqua, transparent);
  animation: zuo 1s linear infinite;
  animation-delay: 0.75s;
}
@keyframes zuo {
  0% {
    bottom: -100%;
  }
  50%,
  100% {
    bottom: 100%;
  }
}

    .item1{
            filter: hue-rotate(100deg);
        }
        .item3{
            filter: hue-rotate(250deg);
        }

<!DOCTYPE html>
<html lang="zh-CN">

<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>Document</title>
	<style>
		* {
			margin: 0;
			padding: 0;
			box-sizing: border-box;
			font-family: 'fangsong';
		}

		body {
			height: 100vh;
			display: flex;
			align-items: center;
			justify-content: center;
			background-color: rgb(0, 0, 0);
		}

		.item {
			position: relative;
			margin: 50px;
			width: 300px;
			height: 80px;
			text-align: center;
			line-height: 80px;
			text-transform: uppercase;
			text-decoration: none;
			font-size: 35px;
			letter-spacing: 5px;
			color: aqua;
			overflow: hidden;
			-webkit-box-reflect: below 1px linear-gradient(transparent, rgba(6, 133, 133, 0.3));
		}

		.item:hover {
			background-color: aqua;
			box-shadow: 0 0 5px aqua,
				0 0 75px aqua,
				0 0 155px aqua;
			color: black;
		}

		.item span:nth-of-type(1) {
			position: absolute;
			left: -100%;
			width: 100%;
			height: 3px;
			background-image: linear-gradient(to left, aqua, transparent);
			animation: shang 1s linear infinite;
		}

		@keyframes shang {
			0% {
				left: -100%;
			}

			50%,
			100% {
				left: 100%;
			}
		}

		.item span:nth-of-type(2) {
			position: absolute;
			top: -100%;
			right: 0;
			width: 3px;
			height: 100%;
			background-image: linear-gradient(to top, aqua, transparent);
			animation: you 1s linear infinite;
			animation-delay: 0.25s;
		}

		@keyframes you {
			0% {
				top: -100%;
			}

			50%,
			100% {
				top: 100%;
			}
		}

		.item span:nth-of-type(3) {
			position: absolute;
			right: -100%;
			bottom: 0;
			width: 100%;
			height: 3px;
			background-image: linear-gradient(to right, aqua, transparent);
			animation: xia 1s linear infinite;
			animation-delay: 0.5s;
		}

		@keyframes xia {
			0% {
				right: -100%;
			}

			50%,
			100% {
				right: 100%;
			}
		}

		.item span:nth-of-type(4) {
			position: absolute;
			bottom: -100%;
			left: 0;
			width: 3px;
			height: 100%;
			background-image: linear-gradient(to bottom, aqua, transparent);
			animation: zuo 1s linear infinite;
			animation-delay: 0.75s;
		}

		@keyframes zuo {
			0% {
				bottom: -100%;
			}

			50%,
			100% {
				bottom: 100%;
			}
		}

		.item1 {
			filter: hue-rotate(100deg);
		}

		.item3 {
			filter: hue-rotate(250deg);
		}
	</style>
</head>

<body>

	<a href="#" class="item item1">
		aurora
		<span></span>
		<span></span>
		<span></span>
		<span></span>
	</a>
	<a href="#" class="item item2">
		aurora
		<span></span>
		<span></span>
		<span></span>
		<span></span>
	</a>
	<a href="#" class="item item3">
		aurora
		<span></span>
		<span></span>
		<span></span>
		<span></span>
	</a>

</body>

</html>

原文：https://juejin.cn/post/6966482130020859912

近几年 TypeScript 和 JavaScript 一直在稳步发展。我们在过去写代码时养成了一些习惯，而有些习惯却没有什么意义。以下是我们都应该改正的 10 个坏习惯。

1.不使用 strict 模式

• 这种习惯看起来是什么样的

没有用严格模式编写 tsconfig.json。

{
  "compilerOptions": {
    "target": "ES2015",
    "module": "commonjs"
  }
}

• 应该怎样

只需启用 strict 模式即可：

{

  "compilerOptions": {

    "target": "ES2015",

    "module": "commonjs",

    "strict": true

  }

}

• 为什么会有这种坏习惯

在现有代码库中引入更严格的规则需要花费时间。

• 为什么不该这样做

更严格的规则使将来维护代码时更加容易，使你节省大量的时间。

2. 用 ||定义默认值

• 这种习惯看起来是什么样的

使用旧的 ||处理后备的默认值：

function createBlogPost (text: string, author: string, date?: Date) {

  return {

    text: text,

    author: author,

    date: date || new Date()

  }

}

function createBlogPost (text: string, author: string, date: Date = new Date())

  return {

    text: text,

    author: author,

    date: date

  }

}

async function loadProducts(): Promise<Product[]> {
  const response = await fetch('https://api.mysite.com/products')
  const products: any = await response.json()
  return products
}

async function loadProducts(): Promise<Product[]> {

  const response = await fetch('https://api.mysite.com/products')

  const products: unknown = await response.json()

  return products as Product[]

}

async function loadProducts(): Promise<Product[]> {

  const response = await fetch('https://api.mysite.com/products')

  const products: unknown = await response.json()

  return products as Product[]

}

function isArrayOfProducts (obj: unknown): obj is Product[] {

  return Array.isArray(obj) && obj.every(isProduct)

}



function isProduct (obj: unknown): obj is Product {

  return obj != null

    && typeof (obj as Product).id === 'string'

}



async function loadProducts(): Promise<Product[]> {

  const response = await fetch('https://api.mysite.com/products')

  const products: unknown = await response.json()

  if (!isArrayOfProducts(products)) {

    throw new TypeError('Received malformed products API response')

  }

  return products

}

interface User {

  id: string

  firstName: string

  lastName: string

  email: string

}



test('createEmailText returns text that greats the user by first name', () => {

  const user: User = {

    firstName: 'John'

  } as any

  

  expect(createEmailText(user)).toContain(user.firstName)

}

interface User {

  id: string

  firstName: string

  lastName: string

  email: string

}



class MockUser implements User {

  id = 'id'

  firstName = 'John'

  lastName = 'Doe'

  email = 'john@doe.com'

}



test('createEmailText returns text that greats the user by first name', () => {

  const user = new MockUser()



  expect(createEmailText(user)).toContain(user.firstName)

}

interface Product {

  id: string

  type: 'digital' | 'physical'

  weightInKg?: number

  sizeInMb?: number

}

interface Product {

  id: string

  type: 'digital' | 'physical'

}



interface DigitalProduct extends Product {

  type: 'digital'

  sizeInMb: number

}



interface PhysicalProduct extends Product {

  type: 'physical'

  weightInKg: number

}

function head<T> (arr: T[]): T | undefined {

  return arr[0]

}

function head<Element> (arr: Element[]): Element | undefined {

  return arr[0]

}

function createNewMessagesResponse (countOfNewMessages?: number) {

  if (countOfNewMessages) {

    return `You have ${countOfNewMessages} new messages`

  }

  return 'Error: Could not retrieve number of new messages'

}

function createNewMessagesResponse (countOfNewMessages?: number) {

  if (countOfNewMessages !== undefined) {

    return `You have ${countOfNewMessages} new messages`

  }

  return 'Error: Could not retrieve number of new messages'

}

function createNewMessagesResponse (countOfNewMessages?: number) {

  if (!!countOfNewMessages) {

    return `You have ${countOfNewMessages} new messages`

  }

  return 'Error: Could not retrieve number of new messages'

}

function createNewMessagesResponse (countOfNewMessages?: number) {

  if (countOfNewMessages !== undefined) {

    return `You have ${countOfNewMessages} new messages`

  }

  return 'Error: Could not retrieve number of new messages'

}

function createNewMessagesResponse (countOfNewMessages?: number) {

  if (countOfNewMessages != null) {

    return `You have ${countOfNewMessages} new messages`

  }

  return 'Error: Could not retrieve number of new messages'

}

function createNewMessagesResponse (countOfNewMessages?: number) {

  if (countOfNewMessages !== undefined) {

    return `You have ${countOfNewMessages} new messages`

  }

  return 'Error: Could not retrieve number of new messages'

}

• 不知道如何准确的定义出类型，TS 报错了，用 any 能解决，便用 any 了
• 觉得定义类型浪费时间，项目经理催的紧，工期紧张，any 更方便

;(<any>window).obj = {}(
  // 或
  window as any
).obj = {}

interface Window {
  obj: {}
}

interface Window {
  obj: {}
}

const a: {
  b: string
  c?: {
    d: string
  }
} = {
  b: "123",
}

console.log((<any>a).c.d) // 错误，这样访问会报错，应使用可选链
console.log(a.c!.d) // 错误，ts 不会将错误抛出，但实际访问也会报错

const a = {
  c: undefined,
}

const b = a?.c?.d

"use strict"

var _a$c

const a = {
  c: undefined,
}
const b =
  a === null || a === void 0
    ? void 0
    : (_a$c = a.c) === null || _a$c === void 0
    ? void 0
    : _a$c.d

const obj: {
  a: 1 | 2
  b: string | number
} = {
  a: 1,
  b: "1.2"
}

if (obj.a === 1) {
  const [left, right] = (obj.b as string).split(".")
}
// 如果你偷懒，那可能又变成了这样的情况
if (obj.a === 1) {
  const [left, right] = (obj.b as any).split(".")
}

const obj: {
  a: 1
  b: string
} | {
  a: 2
  b: number
} = {
  a: 1,
  b: "1.2"
}
// 你会发现这样定义了以后，不需要再次进行断言限定 obj.b 的范围
if (obj.a === 1) {
  const [left, right] = obj.b.split(".") // 校验通过
}

const { a, b } = props // 错误，a 和 b 的类型关系丢失

type X = xxxx // 某种类型
function check(params): params is X

interface Window {
    wx?: {
        xxxx: Function
    }
    webviewnative?: {
        xxxx: Function
    }
}

if (typeof window.wx !== 'undefined') {
    window.wx.xxxx()
} else {
    // not in wx
}

function checkIsWxNativeAPICanUse(win: Window): win is { wx: Exclude<Window['wx'], undefined> } & Window {

    return typeof window.wx !== 'undefined'

}

// 使用

if (checkIsWxNativeAPICanUse(window)) {

    window.wx.xxxx()

}

问题

在项目中,选择照片或拍照的功能很长见,由于我之前采用系统自带的UIimagePickViewController遇到一点问题:

1、使用拍照功能,进行截取时(allowEditing = YES)时,拍照完成的图片无法拖动,没有办法进行选择性的截取图片
2、如果使用选择相册功能,进入裁剪界面,图片是可以拖动的,唯独拍照之后进入裁剪界面无法拖动
3、微信头像更换拍照好像也无法拖动,初步推测可能使用的系统自带的裁剪界面
所以想来仔细研究一下UIImagePickViewController的属性和使用方法

UIImagePickViewController

UIImagePickerController是iOS系统提供的和系统的相册和相机交互的一个类,可以用来获取相册的照片,也可以调用系统的相机拍摄照片或者视频。该类的继承结构是:

UIImagePickerController-->UINavigationController-->UIViewController-->UIResponder-->NSObject

官方文档中对于该类的说明是:

该类只支持竖屏模式，为了保证该类被原样使用，它不支持子类，并且它的视图层次是私有的不能被修改，只支持自定义cameraOverlayView属性来展示更多信息以及和用户的交互。

由于该类继承自UINavgationController,所以在使用过程中一般实现UIImagePickerControllerDelegate和UINavigationControllerDelegate这两个代理，可以利用navgation的push 和pop操作自定义界面实现更复杂的交互效果。

下面具体分析该类的一些方法和属性.

UIImagePickViewController之常用属性

@property (nullable, nonatomic, weak) id <UINavigationControllerDelegate, UIImagePickerControllerDelegate> delegate;

该对象的代理需要实现UINavigationControllerDelegate和UIImagePickerControllerDelegate协议，nullable是xcode6.3之后引入的nullability annotations特性，主要用于在OC和swift之间的转换。这一特性主要包含两个新的类型注释nullable和nonnull，用于表示对象是否可以是NULL或nil

@property (nonatomic) UIImagePickerControllerSourceType sourceType; // default value is UIImagePickerControllerSourceTypePhotoLibrary.

sourceType用于指定要访问的系统的媒体类型。UIImagePickerControllerSourceType支持以下3种枚举类型，默认值是图片库

typedef NS_ENUM(NSInteger, UIImagePickerControllerSourceType) { UIImagePickerControllerSourceTypePhotoLibrary,//照片库模式。图像选取控制器以该模式显示时会浏览系统照片库的根目录。 UIImagePickerControllerSourceTypeCamera, //相机模式，图像选取控制器以该模式显示时可以进行拍照或摄像。 UIImagePickerControllerSourceTypeSavedPhotosAlbum //相机胶卷模式，图像选取控制器以该模式显示时会浏览相机胶卷目录。};

1、PhotoLibrary代表系统照片应用对应的相薄，包含照片流和其它自定义的相册
2、PhotosAlbum则对应系统照片应用的照片，包含用设备拍摄的所有照片流。
3、Camera则代表相机的摄像头。

@property (nonatomic, copy) NSArray<NSString *> *mediaTypes;

mediaTypes用于设置相机支持的功能，拍照或者是视频，返回值类型可以是kUTTypeMovie视频和kUTTypeImage拍照

1、kUTTypeMovie包含

const CFStringRef kUTTypeAudiovisualContent ;抽象的声音视频
const CFStringRef kUTTypeMovie ;抽象的媒体格式（声音和视频）
const CFStringRef kUTTypeVideo ;只有视频没有声音
const CFStringRef kUTTypeAudio ;只有声音没有视频
const CFStringRef kUTTypeQuickTimeMovie ;
const CFStringRef kUTTypeMPEG ;
const CFStringRef kUTTypeMPEG4 ;
const CFStringRef kUTTypeMP3 ;
const CFStringRef kUTTypeMPEG4Audio ;
const CFStringRef kUTTypeAppleProtectedMPEG4Audio;

2、kUTTypeImage包含

const CFStringRef kUTTypeImage ;抽象的图片类型
const CFStringRef kUTTypeJPEG ;
const CFStringRef kUTTypeJPEG2000 ;
const CFStringRef kUTTypeTIFF ;
const CFStringRef kUTTypePICT ;
const CFStringRef kUTTypeGIF ;
const CFStringRef kUTTypePNG ;
const CFStringRef kUTTypeQuickTimeImage ;
const CFStringRef kUTTypeAppleICNS const CFStringRef kUTTypeBMP;
const CFStringRef kUTTypeICO;

@property (nonatomic) BOOL showsCameraControls NS_AVAILABLE_IOS(3_1);
@property (nonatomic) BOOL allowsEditing NS_AVAILABLE_IOS(3_1); // replacement for -allowsImageEditing; default value is NO.
@property (nonatomic) BOOL allowsImageEditing NS_DEPRECATED_IOS(2_0, 3_1);

1、showsCameraControls用于指定拍照时下方的工具栏是否显示
2、allowImageEditing在iOS3.1就已废弃，取而代之的是allowEditing,
3、allowEditing表示拍完照片或者从相册选完照片后，是否跳转到编辑模式对图片裁剪，只有在showsCameraControls为YES时才有效果。

@property (nonatomic) UIImagePickerControllerCameraCaptureMode cameraCaptureMode NS_AVAILABLE_IOS(4_0); // default is UIImagePickerControllerCameraCaptureModePhoto
@property (nonatomic) UIImagePickerControllerCameraDevice cameraDevice NS_AVAILABLE_IOS(4_0); // default is UIImagePickerControllerCameraDeviceRear
@property (nonatomic) UIImagePickerControllerCameraFlashMode cameraFlashMode 
@property (nonatomic) CGAffineTransform cameraViewTransform NS_AVAILABLE_IOS(3_1); // set the transform of the preview view.
@property (nullable, nonatomic,strong) __kindof UIView *cameraOverlayView NS_AVAILABLE_IOS(3_1); // set a view to overlay the preview view.

当sourceType是camera的时候，这几个属性有效，否则抛出异常。

· cameraCaptureMode捕捉模式指定的是相机是拍摄照片还是视频,它的枚举类型如下:

NS_ENUM(NSInteger, UIImagePickerControllerCameraCaptureMode) { 
    UIImagePickerControllerCameraCaptureModePhoto,//photo 
    UIImagePickerControllerCameraCaptureModeVideo//video
};

· cameraDevice指定拍摄的摄像头位置，是使用前置摄像头还是后置摄像头,它的枚举类型有:

typedef NS_ENUM(NSInteger, UIImagePickerControllerCameraDevice) { 
    UIImagePickerControllerCameraDeviceRear,//后摄像头(默认) 
    UIImagePickerControllerCameraDeviceFront//前摄像头
};

· cameraFlashMode用于指定闪光灯模式，它的枚举类型如下:

typedef NS_ENUM(NSInteger, UIImagePickerControllerCameraFlashMode) { 
    UIImagePickerControllerCameraFlashModeOff = -1,//关闭闪关灯 
    UIImagePickerControllerCameraFlashModeAuto = 0,//自动 
    UIImagePickerControllerCameraFlashModeOn = 1//开启闪关灯
};

· cameraViewTransform该结构体可以用于指定拍摄时View的一些形变属性，如旋转缩放等。当showsCameraControls为NO，系统的工具栏隐藏时，我们可以自定义背景View赋值给cameraOverlayView添加到拍摄时的预览视图之上。

@property(nonatomic) NSTimeInterval videoMaximumDuration NS_AVAILABLE_IOS(3_1); // default value is 10 minutes.
@property(nonatomic) UIImagePickerControllerQualityType videoQuality NS_AVAILABLE_IOS(3_1);

· videoMaximumDuration用于设置视频拍摄模式下最大拍摄时长，默认值是10分钟。
· videoQuality表示拍摄的视频质量设置，默认是Medium即表示中等质量。 videoQuality支持的枚举类型如下:

typedef NS_ENUM(NSInteger, UIImagePickerControllerQualityType) { 
    UIImagePickerControllerQualityTypeHigh = 0, // 高清模式 
    UIImagePickerControllerQualityTypeMedium = 1, //中等质量，适于WIFI传播
    UIImagePickerControllerQualityTypeLow = 2, //低等质量，适于蜂窝网络传输 
    UIImagePickerControllerQualityType640x480 NS_ENUM_AVAILABLE_IOS(4_0) = 3, // VGA 质量 
    UIImagePickerControllerQualityTypeIFrame1280x720 NS_ENUM_AVAILABLE_IOS(5_0) = 4,//1280*720的分辨率 
    UIImagePickerControllerQualityTypeIFrame960x540 NS_ENUM_AVAILABLE_IOS(5_0) = 5,//960*540分辨率
};

UIImagePickViewController之类方法

@interface UIImagePickerController : UINavigationController <NSCoding>
+ (BOOL)isSourceTypeAvailable:(UIImagePickerControllerSourceType)sourceType; // returns YES if source is available (i.e. camera present)
+ (nullable NSArray<NSString *> *)availableMediaTypesForSourceType:(UIImagePickerControllerSourceType)sourceType; // returns array of available media types (i.e. kUTTypeImage)
+ (BOOL)isCameraDeviceAvailable:(UIImagePickerControllerCameraDevice)cameraDevice NS_AVAILABLE_IOS(4_0); // returns YES if camera device is available 
+ (BOOL)isFlashAvailableForCameraDevice:(UIImagePickerControllerCameraDevice)cameraDevice NS_AVAILABLE_IOS(4_0); // returns YES if camera device supports flash and torch.
+ (nullable NSArray<NSNumber *> *)availableCaptureModesForCameraDevice:(UIImagePickerControllerCameraDevice)cameraDevice NS_AVAILABLE_IOS(4_0);

isSourceTypeAvailable用于判断当前设备是否支持指定的sourceType，可以是照片库/相册/相机.
isCameraDeviceAvailable判断当前设备是否支持前置摄像头或者后置摄像头
isFlashAvailableForCameraDevice是否支持前置摄像头闪光灯或者后置摄像头闪光灯
availableMediaTypesForSourceType方法返回所特定的媒体如相册/图片库/相机所支持的媒体类型数组,元素值可以是kUTTypeImage类型或者kUTTypeMovie类型的静态字符串，所以是NSString类型的数组
availableCaptureModesForCameraDevice返回特定的摄像头(前置摄像头/后置摄像头)所支持的拍摄模式数值数组，元素值可以是UIImagePickerControllerCameraCaptureMode枚举里面的video或者photo,所以是NSNumber类型的数组

UIImagePickViewController之对象方法

- (void)takePicture NS_AVAILABLE_IOS(3_1);
- (BOOL)startVideoCapture NS_AVAILABLE_IOS(4_0);
- (void)stopVideoCapture NS_AVAILABLE_IOS(4_0);

1、takePicture可以用来实现照片的连续拍摄，需要自己自定义拍摄的背景视图来赋值给cameraOverlayView，结合自定义overlayView实现多张照片的采集，在收到代理的didFinishPickingMediaWithInfo方法之后可以启动额外的捕捉。
2、startVideoCapture用来判断当前是否可以开始录制视频，当视频正在拍摄中，设备不支持视频拍摄，磁盘空间不足等情况，该方法会返回NO.该方法结合自定义overlayView可以拍摄多部视频
3、stopVideoCapture当你调用此方法停止视频拍摄时，它会调用代理的imagePickerController：didFinishPickingMediaWithInfo：方法

UIImagePickViewController之代理方法

@protocol UIImagePickerControllerDelegate<NSObject>
@optional
- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingImage:(UIImage *)image editingInfo:(nullable NSDictionary<NSString *,id> *)editingInfo NS_DEPRECATED_IOS(2_0, 3_0);
- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary<NSString *,id> *)info;
- (void)imagePickerControllerDidCancel:(UIImagePickerController *)picker;
@end

1、imagePickerController:didFinishPickingImage:editingInfo:在iOS3.0中已废弃，不再使用。
2、当用户取消选取的内容时会调用DidCancel方法，默认实现销毁弹出的视图。
3、当完成内容的选取时会调用didFinishPickingMediaWithInfo方法，默认info字典的key值可以是以下类型:

UIKIT_EXTERN NSString *const UIImagePickerControllerMediaType; //指定用户选择的媒体类型
UIKIT_EXTERN NSString *const UIImagePickerControllerOriginalImage; // 原始图片
UIKIT_EXTERN NSString *const UIImagePickerControllerEditedImage; // 修改后的图片
UIKIT_EXTERN NSString *const UIImagePickerControllerCropRect; // 裁剪尺寸
UIKIT_EXTERN NSString *const UIImagePickerControllerMediaURL; // 媒体的URL
UIKIT_EXTERN NSString *const UIImagePickerControllerReferenceURL NS_AVAILABLE_IOS(4_1); // 原件的URL
UIKIT_EXTERN NSString *const UIImagePickerControllerMediaMetadata //当数据来源是相机的时候获取到的静态图像元数据，可以使用phtoho框架进行处理

UIImagePickViewController之C语言函数(保存图片或视频)

UIKIT_EXTERN void UIImageWriteToSavedPhotosAlbum(UIImage *image, __nullable id completionTarget, __nullable SEL completionSelector, void * __nullable contextInfo);
UIKIT_EXTERN BOOL UIVideoAtPathIsCompatibleWithSavedPhotosAlbum(NSString *videoPath) NS_AVAILABLE_IOS(3_1);
UIKIT_EXTERN void UISaveVideoAtPathToSavedPhotosAlbum(NSString *videoPath, __nullable id completionTarget, __nullable SEL completionSelector, void * __nullable contextInfo) NS_AVAILABLE_IOS(3_1);

1、UIImageWriteToSavedPhotosAlbum用来保存照片到相册，seletor应该设置为- (void)image:(UIImage )image didFinishSavingWithError:(NSError )error contextInfo:(void )contextInfo;当照片保存到相册完成时，会调用该方法通知你。
2、UIVideoAtPathIsCompatibleWithSavedPhotosAlbum会返回布尔类型的值判断该路径下的视频能否保存到相册，视频需要先存储到沙盒文件再保存到相册，而照片是可以直接从代理完成的回调info字典里面获取到。
3、UISaveVideoAtPathToSavedPhotosAlbum用来保存视频到相册，seletor应该设置为- (void)video:(NSString )videoPath didFinishSavingWithError:(NSError )error contextInfo:(void )contextInfo;当视频保存到相册或出错时会调用该方法通知你。
这三个方法一般是在代理的完成方法didFinishPickingMediaWithInfo里面配合使用。
以上便是系统UIImagePickViewController的所有属性和方法的简单介绍

问题解决方案

由于使用设置allowEditing = YES属性后,开启摄像头拍照后直接进入系统自定义的裁剪界面,但是在这个界面,从摄像头拍摄过来的照片无法拖动裁剪,仅仅从相册选择过来的照片是可以拖动进行裁剪的,那么我们就决定裁剪界面不使用系统自带的,而自定义一个裁剪界面.

在UIImagePickViewController的代理方法里

#pragma UIImagePickerController Delegate
- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info
{
  UIImage *portraitImg = [info objectForKey:@"UIImagePickerControllerOriginalImage"]; 
  YYImageClipViewController *imgClipVC = [[YYImageClipViewController alloc] initWithImage:portraitImg cropFrame:CGRectMake(0, 100.0f, self.view.frame.size.width, self.view.frame.size.width) limitScaleRatio:3.0]; 
  imgClipVC.delegate = self;
  [picker pushViewController:imgClipVC animated:NO];
}

- (void)imagePickerControllerDidCancel:(UIImagePickerController *)picker
{ 
  [picker dismissViewControllerAnimated:YES completion:nil];
}

HZImageCropperViewController是我自定义的一个裁剪界面,通过这个控制器的两个代理方法,得到裁剪后的照片

- (void)imageClip:(YYImageClipViewController *)clipViewController didFinished:(UIImage *)editedImage 
{ 
  //保存图片
  NSString *imageFilePath = [UIImage saveImage:editedImage]; 
  //上传七牛服务器 
  [self upImageFilePath:imageFilePath]; 
  //隐藏裁剪界面 
  [clipViewController dismissViewControllerAnimated:YES completion:nil];
}

- (void)imageClipDidCancel:(YYImageClipViewController *)clipViewController
{
   [clipViewController dismissViewControllerAnimated:YES completion:nil];
}

下面附上一个demo,里面包含裁剪界面的源代码,可供大家参考
自定义裁剪界面demo

转自：https://www.jianshu.com/p/9474ca73e269

逻辑图

终端代码及源码

clang 命令行及源码.zip

一、我们要做什么

我们的目的是想要通过TypeScript的类型声明式语法，编程实现一个斐波那契数列算法。换句话说，类似于用现有的机器码到指令集、二进制到十进制、汇编语言到高级编程语言的过程，让类型定义语法也可以实现编程。

最终我们要实现的斐波那契数列代码是这样的？

const fib = (n: number): number => n <= 1 ? n : fib(n - 1) + fib(n - 2);

for (let i = 0; i < 10; i++) {
  console.log(i, fib(i));
}

运行结果如下：

程序完全没问题，完结撒花！

开玩笑的，上面是只一个用了TypeScript类型定义的JavaScript写法，我们其实真正想这样做↓↓↓, 也就是使用TS Type解决FIbonacci

import { Fib, Add } from './fib-type';

type one = Fib<1>;
type zero = Fib<0>;
type Two = Add<one, one>;
type Five = Add<Two, Add<Two, one>>;
type Fib5 = Fib<Five>;
type Fib9 = Fib<9>;
type r0 = Fib<Zero>; // type r0= 0
type r1 = Fib<One>; // type r1 = 1
type r2 = Fib<Two>; // type r2 = 1
type r3 = Fib<3>; // type r3 = 2
type r4 = Fib<4>; // type r4 = 3
type r5 = Fib<5>; // type r5 = 5
type r6 = Fib<6>; // type r6 = 8
type r9 = Fib<9>; // type r9 = 34
type sum = Add<r9, r6>; // type sum = 42

二、我们该怎么做

要想实现斐波那契数列，参考一开始的代码，有基本的比较, 加法, 循环语法, 所以我们也需要使用类型系统依次实现这三种功能

2.1 加法的实现

为了实现加法, 需要先实现一些工具类型

// 元组长度
type Length<T extends any[]> = T['length'];
type one = 1

// 使用extends实现数字相等的比较
type a111 = 0 extends one ? true : false // type a111 = false
type a112 = 1 extends one ? true : false // type a112 = true

range的实现是递归实现的

// 伪代码
function range(n, list=[]){
  if(n<=0) return list.length
  return range(n-1, [1, ...list])
}

TypeScript的限制, 没有循环, 只能用递归代替循环, 后面会有几个类似的写法, 记住一点：递归有几个出口, 对象就有几个 key, 每个 key 就是一个条件

// 创建指定长度的元组, 用第二个参数携带返回值
type Range<T extends Number = 0, P extends any[] = []> = {
  0: Range<T, [any, ...P]>;
  1: P;
}[Length<P> extends T ? 1 : 0];

// 拼接两个元组
type Concat<T extends any[], P extends any[]> = [...T, ...P];

type t1 = Range<3>;
// type t1 = [any, any, any]

type Zero = Length<Range<0>>;
//   type Zero = 0
type Ten = Length<Range<10>>;
// type Ten = 10

type Five = Length<Range<5>>;
// type Five = 5

type One = Length<Range<1>>;

有了上面的工具语法，那么实现加法就比较容易了, 只需要求两个元组合并后的长度

type Add<T extends number, P extends number> = Length<
    Concat<Range<T>, Range<P>>
  >;
  type Two = Add<One, One>;
  //   type Two = 2
  type Three = Add<One, Two>;
  // type Three = 3

有了加法，该如何实现减法呢？一般减法和除法都比加法难, 所以我们需要更多的工具类型函数

2.2 工具函数

2.2.1 实现一些基本工具类型

• Shift：删除第一个元素
• Append：在元组末尾插入元素
• IsEmpty / NotEmpty：判断列表为空

// 去除元组第一个元素 [1,2,3] -> [2,3]
type Shift<T extends any[]> = ((...t: T) => any) extends (
  _: any,
  ...Shift: infer P
) => any
  ? P
  : [];

type pp = Shift<[number, boolean,string, Object]>
// type pp = [boolean, string, Object]

// 向元组中追加
type Append<T extends any[], E = any> = [...T, E];
type IsEmpty<T extends any[]> = Length<T> extends 0 ? true : false;
type NotEmpty<T extends any[]> = IsEmpty<T> extends true ? false : true;
type t4 = IsEmpty<Range<0>>;
// type t4 = true

type t5 = IsEmpty<Range<1>>;
// type t5 = false

// 逻辑操作
type And<T extends boolean, P extends boolean> = T extends false
  ? false
  : P extends false
  ? false
  : true;
type t6 = And<true, true>;
// type t6 = true

type t7 = And<true, false>;
// type t7 = false

type t8 = And<false, false>;
// type t8 = false

type t9 = And<false, true>;
// type t9 = false

function dfs (a, b){
    if(a.length && b.length){
        a.pop()
        b.pop()
        return dfs(a,b)
    }else if(a.length){
        a >= b
    }else if (b.length){
        b > a
    }
}

// 元组的小于等于   T <= P, 同时去除一个元素, 长度先到0的比较小
type LessEqList<T extends any[], P extends any[]> = {
  0: LessEqList<Shift<T>, Shift<P>>;
  1: true;
  2: false;
}[And<NotEmpty<T>, NotEmpty<P>> extends true
  ? 0
  : IsEmpty<T> extends true
  ? 1
  : 2];


// 数字的小于等于
type LessEq<T extends number, P extends number> = LessEqList<Range<T>, Range<P>>;

type t10 = LessEq<Zero, One>;
// type t10 = true
type t11 = LessEq<One, Zero>;
// type t11 = false

type t12 = LessEq<One, One>;
// type t12 = true

// 伪代码
const a = [1, 2, 3];
const b = [4, 5];
const c = [];
while (b.length !== a.length) {
  a.pop();
  c.push(1);
}// c.length === a.length - b.lengthconsole.log(c.length);

// 元组的减法 T - P, 同时去除一个元素, 长度到0时, 剩下的就是结果, 这里使用第三个参数来携带结果, 每次做一次减法, 向第三个列表里面追加
type SubList<T extends any[], P extends any[], R extends any[] = []> = {
  0: Length<R>;
  1: SubList<Shift<T>, P, Apped<R>>;
}[Length<T> extends Length<P> ? 0 : 1];
type t13 = SubList<Range<10>, Range<5>>;
// type t13 = 5

// 集合大小不能为负数, 默认大减小
// 数字的减法
type Sub<T extends number, P extends number> = {
  0: Sub<P, T>;
  1: SubList<Range<T>, Range<P>>;
}[LessEq<T, P> extends true ? 0 : 1];

type t14 = Sub<One, Zero>;
//   type t14 = 1
type t15 = Sub<Ten, Five>;
// type t15 = 5

const fib = (n: number): number => n <= 1 ? n : fib(n - 1) + fib(n - 2);

export type Fib<T extends number> = {
  0: T;
  1: Add<Fib<Sub<T, One>>, Fib<Sub<T, Two>>>;
}[LessEq<T, One> extends true ? 0 : 1];

type r0 = Fib<Zero>;
// type r10= 0
type r1 = Fib<One>;
// type r1 = 1

type r2 = Fib<Two>;
// type r2 = 1

type r3 = Fib<3>;
// type r3 = 2

type r4 = Fib<4>;
// type r4 = 3

type r5 = Fib<5>;
//type r5 = 5

type r6 = Fib<6>;
//   type r6 = 8

ts作为一门新技术，这两年是越来越火，经过了一段时间的学习和理解之后，写了这篇文章，通过记录ts的核心知识点来带大家轻松掌握typescript，希望能够打动屏幕面前的你。

Typescript基础语法

TypeScript支持与JavaScript几乎相同的数据类型，此外还提供了实用的枚举类型方便我们使用。接下来我们简单介绍一下这几种类型的用法.

基础类型

// 布尔类型
let isFlag:boolean = true

// 数值类型
let myNumber:number = 24

// 字符串类型
let str:string = 'ykk'

// 数组类型, 有两种表示方式,第一种可以在元素类型后面接上[]，表示由此类型元素组成的一个数组
let arr:number[] = [1,2,3]
//当数组存在不同类型时
let arr1: (number | string)[] = [1, '2', 3]

// 数组类型, 使用数组泛型(有关泛型后面会详细分析)
let arr:Array<number> = [4,5,6]

// 元组类型, 允许表示一个已知元素数量和类型的数组，各元素的类型不必相同
let yuan: [string, number];
// 初始化yuan
yuan = ['yuan', 12]; // 正确
yuan = [12, 'yuan']; // 错误

// 枚举类型, 可以为一组数值赋予友好的名字
enum ActionType { online, offline, deleted }
let action:ActionType = ActionType.offline    // 1

// any, 表示任意类型, 可以绕过类型检查器对这些值进行检查
let color:any = 1
color = 'red'

// void类型, 当一个函数没有返回值时，通常会设置其返回值类型是 void
function getName(): void {
    console.log("This is my name");
}

// object类型, 表示非原始类型，也就是除number，string，boolean，symbol，null或undefined之外的类型
let obj:object;
obj = {num: 1}

// 对象类型也可以写成
const t = {
    name:string,
    age:number
} = {
    name:'ykk',
    age:18
}

// 函数类型也属于一种对象类型(该实例返回值必须是number类型)
const getTt:() => number = () => {
    return 123;
}

//never类型(永远不会执行never之后的逻辑)
function errorEmitter(): never {
    throw new Error();
    console.log(123)
}

接口（Interface）

interface Person {
    name: string;
    age: number;
    phone: number;
}

let man:Person = {
    name: 'ykk',
    age: 18,
    phone: 13711111111
}

类型检查器不会去检查属性的顺序，只要相应的属性存在并且类型也是对的就可以。其次我们还可以定义可选属性和只读属性。 可选属性表示了接口里的某些属性不是必需的,所以可以定义也可以不定义。·可读属性·使得接口中的某些属性只能读取而不能赋值,如下：

interface Person {
  name: string;
  age?: number;
  readonly phone: number;
}

在实际场景中, 我们往往还会遇到不确定属性名和属性值类型的情况, 这个时候我们可以利用索引签名来设置额外的属性和类型, 如下：

interface Person {
  name: string;
  [propName: string]: any; //这里表示除了有name之外还可以有其他的任何属性，但是属性名必须是string类型，属性值任意类型都可以
}

当然接口也可以进行继承

//此时human这个interface就拥有Person的所有属性，并且在调用的时候也必须满足Proson的要求，否则就会报错
interface human extends Person {
    weight:55
}

类

和js的class一致, typescript的类有公共(public)，私有(private)与受保护(protected)的访问类型。

public 在TypeScript里，成员都默认为 public,表示允许它在定义类的外部被调用


private 表示它能在定义的类内使用，不能在该类的外部使用


protected 和private类似, 但是protected允许在类内及继承的子类中使用

class Person {
        public name:string = 'ykk';
        private age:number = 18;
        protected weight:number = 55;
        constructor(){

        }
    }
    
    class Man extends Person {
        public say(){
            return this.weight
        }
    }
    
    let p = new Person()
    let m = new Man()
    console.log(p.name) //ykk
    console.log(p.age) //报错age是private属性
    console.log(m.say()) //55

class Person {
    private _food: string = 'apple'
    get food() {
        return this._food
    }
    set food(name: string) {
        this._food = name
    }
}
let p = new Person()
console.log(p.food) //apple
p.food="cookie" //这里重新设置food

class Demo {
    private static instance: Demo;
    peivate contructor(public name:string){}
    
    static getInstance(){
        if(!this.instance){
            this.instance = new Demo('ykk')
        }
        return this.instance;
    }
}

const demo1 = Demo.getInstance();
const demo2 = Demo.getInstance();
console.log(demo1.name)
console.log(demo2.name)

abstract class MyAbstract {
    constructor(public name: string) {}
    say(): void {
        console.log('say name: ' + this.name);
    }
    abstract sayBye(): void; // 必须在派生类中实现
}

class SubMyAbstract extends MyAbstract {
    constructor() {
        super('ykk'); // 在派生类的构造函数中必须调用 super()
    }
    sayBye(): void {
        console.log('bye');
    }
    getOther(): void {
        console.log('loading...');
    }
}

let department: MyAbstract; // 允许创建一个对抽象类型的引用
department = new SubMyAbstract(); // 允许对一个抽象子类进行实例化和赋值
department.say();
department.sayBye();

department = new MyAbstract(); // 错误: 不能创建一个抽象类的实例
department.getOther(); // 错误: 方法在声明的抽象类中不存在

interface person1 {
  name: string;
  age: number;
}

interface person2 {
  hby: string;
  age: number;
}
let man：person1 | person2

let man：person1 | person2;
man = {
    name: 'ykk',
    age: 18,
    hby: 'basketball'
}
//使用as直接断言，告诉ts在哪里去找
if((me as person1).name) {
  console.log((me as person1).name); 
}

if((me as person1).name) {
  console.log((me as person2).hby); 
}
//使用in
  if(('name' in me)) {
    console.log(me.name); 
  }
  
  if('hby' in me) {
    console.log(me.hby); 
  }
  //使用typeof
 function add(one:number|string,two:number|string){
     if(typeof one=="string"||typeof two=="string"){
         retrun `${one}${two}`
     }
     retrun one+two
 }
 //使用instanceof
  class a{
      num:1
  }
function b(obj:object|a){
    if(obj instanceof a){
        retrun obj.num
    }
}

//定义是用尖括号表示一个变量
function iSay<T>(arg: T): T {
    return arg;
}
// 调用的时候去声明类型
let come = iSay<number>(123);

//传入一个数组
function say<T>(arr:T[]){
    ...
};
say<number>([11,22,33]);

//传入多个泛型
function say<T, F>(name:T, age:F){
    ...
};
say<string, number>('ykk', 18);

class say<T>{
    constructor(name:T){
        ...
    }
}
var t = new say<string>("1")

class say<T extends number|string>{
    constructor(one:T){
        ...
    }
}
var t = new say<string>("1") //这时候表示泛型只能是number类型或者string类型其中的一种，否则会报错

    name:string,
    age:number,
    get:boolean
}
var p = {
    name:'ykk',
    age:18,
    get:false
}
function add<T extends keyof persons>(key:T):persons[T]{
    return p[key]
}
//如此一来我们便能知道返回值的准确类型了
var p1 = add('name')
console.log(p1) //ykk

namespace Main{
    class circle {
        ...
    }
    
    class rect {
        ...
    }
    
    //如果想要导出给外部使用，需要导出
    export class san{
        ...
    }
}
//这样在全局只会有一个Main供我们使用了

//定义一个全局类型, 并编写相应的逻辑让ts识别相应的js语法
declare var superagent;
...

在做socket编程时，如果是做tcp连接，那就不可避免的会遇到粘包与半包的问题。

粘包 就是多组数据被一并接收了,粘在了一起，无法做划分；

半包 就是有数据接收不完整，无法处理。

要解决粘包、半包的问题，一般在设计数据(消息)格式时会约定好一个字段专门用于描述数据包的长度，这样就使数据有了边界，依靠这个边界，就能把每组数据划分出来，数据不完整时也能获知数据的缺失。

(当然也可以把数据设计成定长数据，但这样不够灵活；或者用\n,\r这类字符作为数据划分依据，但不直观、不明确，同时也不灵活)

举个栗子：

消息＝消息头＋消息体。消息头用于描述消息本身的基本信息，消息体则为消息的具体内容

如上图所示，假如我们的一个消息是这么定义的

消息头 ＝ msgId(4B)+version(2B)+len(4B),共占用10字节

消息体 =  len中描述的16字节长

所以这条消息的长度就是 26字节

可以看到，要想知道一条完整数据的边界，关键就是消息头中的len字段

假如我们现在接收到的数据是这样的：

这个情况下即包含了粘包，也出现了半包的情况，三个数据包粘在了一起，最后一个数据包没有接收完全，出现了半包的情况，看看代码如何处理

- (void)onSocket:(AsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag 
{ 
  while (_readBuf.length >= 10)//因为头部固定10个字节，数据长度至少要大于10个字节，我们才能得到完整的消息描述信息 
  { 
    NSData *head = [_readBuf subdataWithRange:NSMakeRange(0, 10)];//取得头部数据 
    NSData *lengthData = [head subdataWithRange:NSMakeRange(6, 4)];//取得长度数据 
    NSInteger length = [[[NSString alloc] initWithData:lengthData encoding:NSUTF8StringEncoding] integerValue];//得出内容长度 
    NSInteger complateDataLength = length + 10;//算出一个包完整的长度(内容长度＋头长度) 
    if (_readBuf.length >= complateDataLength)//如果缓存中数据够一个整包的长度 
    { 
      NSData *data = [_readBuf subdataWithRange:NSMakeRange(0, complateDataLength)];//截取一个包的长度(处理粘包) 
      [self handleTcpResponseData:data];//处理包数据 
      //从缓存中截掉处理完的数据,继续循环 
      _readBuf = [NSMutableData dataWithData:[_readBuf subdataWithRange:NSMakeRange(complateDataLength, _readBuf.length - complateDataLength)]]; 
    } 
    else//如果缓存中的数据长度不够一个包的长度，则包不完整(处理半包，继续读取) 
    { 
      [_socket readDataWithTimeout:-1 buffer:_readBuf bufferOffset:_readBuf.length tag:0];//继续读取数据 
      return; 
    } 
  } 
  //缓存中数据都处理完了，继续读取新数据 
  [_socket readDataWithTimeout:-1 buffer:_readBuf bufferOffset:_readBuf.length tag:0];//继续读取数据 
}

摘自：https://www.jb51.net/article/105278.htm

Socket的基本概念

1.定义

网络上两个程序通过一个双向通信连接实现数据交互，这种双向通信的连接叫做Socket（套接字）。

2.本质

网络模型中应用层与TCP/IP协议族通信的中间软件抽象层，是它的一组编程接口（API），也即对TCP/IP的封装。TCP/IP也要提供可供程序员做网络开发所用的接口，即Socket编程接口。

3.要素

Socket是网络通信的基石，是支持TCP/IP协议的网络通信的基本操作单元，包含进行网络通信的必须的五种信息：

• 连接使用的协议
• 本地主机的IP地址
• 本地进程的协议端口
• 远程主机的IP地址
• 远程进程的协议端口

1. 数据流方式

- (IBAction)connectToServer:(id)sender {
    // 1.与服务器通过三次握手建立连接
    NSString *host = @"192.168.1.58";
    int port = 1212;
    
    //创建一个socket对象
    _socket = [[GCDAsyncSocket alloc] initWithDelegate:self
                                         delegateQueue:dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)];
    
    NSError *error = nil;
    
    // 开始连接
    [_socket connectToHost:host
                    onPort:port
                     error:&error];
    
    if (error) {
        NSLog(@"%@",error);
    }
}


#pragma mark - Socket代理方法
// 连接成功
- (void)socket:(GCDAsyncSocket *)sock
didConnectToHost:(NSString *)host
          port:(uint16_t)port {
    NSLog(@"%s",__func__);
}


// 断开连接
- (void)socketDidDisconnect:(GCDAsyncSocket *)sock
                  withError:(NSError *)err {
    if (err) {
        NSLog(@"连接失败");
    } else {
        NSLog(@"正常断开");
    }
}


// 发送数据
- (void)socket:(GCDAsyncSocket *)sock
didWriteDataWithTag:(long)tag {
    
    NSLog(@"%s",__func__);
    
    //发送完数据手动读取，-1不设置超时
    [sock readDataWithTimeout:-1
                          tag:tag];
}

// 读取数据
-(void)socket:(GCDAsyncSocket *)sock
  didReadData:(NSData *)data
      withTag:(long)tag {
    
    NSString *receiverStr = [[NSString alloc] initWithData:data
                                                  encoding:NSUTF8StringEncoding];
    
    NSLog(@"%s %@",__func__,receiverStr);
}

2.基于第三方开源库CocoaAsyncSocket

2.1客户端通过地址和端口号与服务端建立Socket连接，并写入相关数据。

- (void)connectToServerWithCommand:(NSString *)command
{
    _socket = [[GCDAsyncSocket alloc] initWithDelegate:self delegateQueue:dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)];
    [_socket setUserData:command];
    
    NSError *error = nil;
    [_socket connectToHost:WIFI_DIRECT_HOST onPort:WIFI_DIRECT_PORT error:&error];
    if (error) {
        NSLog(@"__connect error:%@",error.userInfo);
    }
    
    [_socket writeData:[command dataUsingEncoding:NSUTF8StringEncoding] withTimeout:10.0f tag:6];
}

2.2 实现CocoaAsyncSocket的代理方法

#pragma mark - Socket Delegate

- (void)socket:(GCDAsyncSocket *)sock didConnectToHost:(NSString *)host port:(uint16_t)port
{
    NSLog(@"Socket连接成功：%s",__func__);
}

-(void)socketDidDisconnect:(GCDAsyncSocket *)sock withError:(NSError *)err{
    if (err) {
        NSLog(@"连接失败");
    }else{
        NSLog(@"正常断开");
    }
    
    if ([sock.userData isEqualToString:[NSString stringWithFormat:@"%d",SOCKET_CONNECT_SERVER]])
    {
        //服务器掉线 重新连接
        [self connectToServerWithCommand:@"battery"];
    }else
    {
        return;
    }
}

-(void)socket:(GCDAsyncSocket *)sock didWriteDataWithTag:(long)tag {
    NSLog(@"数据发送成功：%s",__func__);
    //发送完数据手动读取，-1不设置超时
    [sock readDataWithTimeout:-1 tag:tag];
}

-(void)socket:(GCDAsyncSocket *)sock didReadData:(NSData *)data withTag:(long)tag {
    NSString *receiverStr = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
    NSLog(@"读取数据：%s %@",__func__,receiverStr);
}

摘自：https://www.jianshu.com/p/8e599ca5dfe8

WebSocket是什么

WebSocket协议是 基于TCP 的一种网络协议。
它实现了浏览器与服务器全双工(full-duplex)通信——允许服务器主动发送信息给客户端。

WebSocket基本原理

帧协议：

0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+

• fin（1 bit）：指示该帧是否构成该消息的最终帧。大多数情况下，消息适合于一个单一的帧，这一点总是默认设置的。实验表明，Firefox 在 32K 之后创建了第二个帧。

• rsv1，rsv2，rsv3（1 bit each）：必须为0，除非扩展里协商定义了非零值的含义。如果收到一个非零值，并且协商的扩展中没有一个定义这个非零值的含义，那么接收端必须抛出失败连接。

• opcode（4bits）：展示了帧表示什么。以下值目前正在使用：
  0x00：这个帧继续前面的有效载荷。
  0x01：此帧包含文本数据。
  0x02：这个帧包含二进制数据。
  0x08：这个帧终止连接。
  0x09：这个帧是一个 ping 。
  0x0a：这个帧是一个 pong 。
  （正如你所看到的，有足够的值未被使用，它们已被保留供将来使用）。
• payload：最可能被掩盖的实际数据。它的长度是 payload_len 的长度。
• masking-key（32 bits）：从客户端发送到服务器的所有帧都被帧中包含的 32 位值掩盖。
• 0-125 表示有效载荷的长度。 126 表示以下两个字节表示长度，127 表示接下来的 8 个字节表示长度。所以有效负载的长度在 〜7bit，16bit 和 64bit 括号内。
• payload_len（7 bits）：有效载荷的长度。 WebSocket 的帧有以下长度括号：
• mask（1 bit）：指示连接是否掩盖。就目前而言，从客户端到服务器的每条消息都必须掩盖，如果规范没有掩盖，规范就会终止连接。

其他特点包括：
（1）建立在 TCP 协议之上，服务器端的实现比较容易。
（2）与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

要求服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息。(也可以采用HTTP/2)

iOS端实现WebSocket连接的参考方案

SocketRocket

SocketRocket是facebook封装的websocket开源库，采用纯Objective-C编写。
使用者需要自己实现心跳机制，以及适配断网重连等情况。

SocketIO

SocketIO将WebSocket、AJAX和其它的通信方式全部封装成了统一的通信接口，也就是说，我们在使用SocketIO时，不用担心兼容问题，底层会自动选用最佳的通信方式。因此说，WebSocket是SocketIO的一个子集。

前言

随着时代的发展，业内曾经提出过很多性能优化相关的标准和规范，从最初2007年雅虎提出34条军规，到2020年google开始推广Web Vitals，优化技术已经有将近20多年的发展历史，如下图所示：

Web Vitals

Google在2020年推出了一个名为Web Vitals的新概念，着重评估一组页面访问体验钟的一部分关键指标，目的在于简化网络性能。每个指标代表页面体验的一个关键方面：加载、交互和视觉稳定性。

Web Vitals在感知的性能，交互性和令人愉悦的方面，可作为用户体验的简化基准。在考虑页面性能时，应该首先关注这一套较小的指标。

此外，Web Vitals代表了访问者在访问您的页面时首先在其视口中看到的内容，即首屏内容。他们首先看到的内容最终会影响他们对页面性能的看法。

首先，专注于这三个指标，可以使您获得可感知的和实际的性能可观的收益，然后再深入研究其他优化。

加载

所谓加载，就是进入页面时，页面内容的载入过程。比如，当你打开一些网站时，你会发现，有的网站首页上的文字、图片出现很缓慢，而有的则很快，这个内容出现的过程就是加载。加载缓慢严重消耗用户的耐心，会让用户离开页面。

这里我们拿淘宝首页的network信息观察一些指标：

当鼠标悬浮在具体的色块上，我们可以看到具体的指标详情。如下图所示，资源下载之前经历了0.46ms的排队（Queueing），DNS查找24.79ms（DNS Lookup)、建立TCP连接(Initial connection)、还有https的网站SSL证书验证的时间37.04ms（SSL），最后发送请求再到资源返回也要经历110.71ms（TTFB）。

下面我们再来纵向看瀑布图，主要看2点：

1. 资源之间的联系：如果下载发生了阻塞，很多资源的下载就会是串行处理的。如果是并行的，就可以加快下载过程。


2. 关键时间节点：我们可以看到图中有红蓝两个颜色的两根线，蓝色的是DOM完成的加载时间，红色是页面中所有声明的资源加载完成的时间。

关键指标

那么这么多指标，到底哪些是最值得我们关注的呢？下面我来总结一下：

1. 
   

   白屏时间（FP，First Paint）：也叫首次绘制时间，对于应用页面，首次出现视觉上不同于跳转之前内容的时间点，或者说是页面发生第一次绘制的时间点，它的标准时间是 300ms。如果白屏时间过长，用户会认为我们的页面不可用，或者可用性差。如果超过一定时间（如 1s），用户注意力就会转移到其他页面。

   
   


2. 
   

   首屏时间（FCP，First Contentful Paint）：也叫首次有内容绘制时间，对于所有的网页应用，这是一个非常重要的指标。它是指从浏览器输入地址并回车后，到首屏内容渲染完毕的时间。这期间不需要滚动鼠标或者下拉页面，否则无效。也就是说，它是浏览器完成渲染DOM中第一部分内容（可能是文本、图像或其它任何元素）的时间点，此时用户应该在视觉上有直观的感受。

   
   


3. 
   

   首次有意义绘制（FMP，First Meaningful Paint）：指页面关键元素的渲染时间。这个概念并没有标准化定义，因为关键元素可以由开发者自行定义究竟什么是“有意义”的内容，只有开发者或者产品经理自己了解。

   
   


4. 
   

   速度指数（Speed Index）：指的是网页以多快的速度展示内容，标准时间是4s。

   
   


5. 
   

   总下载时间（Load）：页面所有资源加载完成所需要的时间。一般可以统计 window.onload，得到同步加载的资源全部加载完的耗时。如果页面中存在较多异步渲染，那么可以将异步渲染全部完成的时间作为总下载时间。

   
   


6. 
   

   TTFB（Time To First Byte）：是指网络请求被发起到从服务器接收到地一个字节的这段时间。其中包含了TCP连接时间、发送HTTP请求时间和获得相应消息第一个字节的时间。

   
   

   TTFB这个参数比较重要，因为它可以给用户最直观的感受，如果TTFB很慢，说明资源一直没有返回，增加白屏时间，如果TTFB很快，资源回来之后就可以进行快速的解析和渲染。

   
   

   那么影响TTFB的因素有哪些？

   
   
   
   
   1. 后台处理能力，服务器响应到底有多快
   
   
   2. 资源请求的网络状况，网络是否有延迟

首屏时间 vs 白屏时间

首屏时间 = 白屏时间 + 渲染时间。在加载性能指标方面，相比于白屏时间，首屏时间更重要。为什么？

从重要性角度看，打开页面后，第一眼看到的内容一般都非常关键，比如电商的头图、商品价格、购买按钮等。这些内容即便在最恶劣的网络环境下，我们也要确保用户能看得到。

从体验完整性角度看，进入页面后先是白屏，随着第一个字符加载，到首屏内容显示结束，我们才会认为加载完毕，用户可以使用了。白屏加载完成后，仅仅意味着页面内容开始加载，但我们还是没法完成诸如下单购买等实际操作，首屏时间结束后则可以。

DOMContentLoaded和Load事件的区别

其实从这两个事件的命名就能体会到，DOMContentLoaded 指的是文档中 DOM 加载内容加载完毕的时间，也就是说 HTML 结构已经是完整的了。但是我们知道，很多页面都包含图片、特殊字体、视频、音频等其他资源，由于这些资源由网络请求获取，需要额外的网络请求，因此DOM内容如加载完毕时，这些资源还没有请求或渲染完成。当页面上所有资源加载完成后，Load 事件才会被触发。

因此，在时间线上，Load 事件往往会落后于 DOMContentLoaded 事件。

交互/响应

所谓交互，就是用户点击网站或 App 的某个功能，页面给出的回应，也就是浏览器的响应时间。比如我们点击了一个“点赞”按钮，立刻给出了点赞数加一的展示，这就是交互体验好，反之如果很长时间都没回应，这就是交互体验不好。

关于交互指标，有的公司用 FID 指标 （First Input Delay，首次输入延迟）， 指标必须尽量小于 100ms，如果过长会给人页面卡顿的感觉。还有的公司使用 PSI（Perceptual Speed Index，视觉变化率），衡量标准是小于20%。

一般来说，主要包括以下几个指标：

1. 
   

   交互动作的反馈时间：也叫用户可交互时间，就是用户可以与应用进行加护的时间，一般来讲，我们认为是 DOMReady 的时间，因为我们通常会在这时绑定事件操作。如果页面中设计交互的脚本没有下载完成，那么当然没有达到所谓的用户可交互时间。那么如何定义 DOMReady 时间呢？这里我推荐大家看司徒正美的文章《何谓DOMReady》。

   
   


2. 
   

   刷新率（FPS，Frame Per Second）：也叫帧率，标准的刷新率指标是60帧/s，它可以决定画面是否足够流畅。

   
   


3. 
   

   异步请求的完成时间：所有的异步请求能在1s中内请求回来。

   
   

关于帧率，我们可以用chorme Devtools来查看，打开控制台，点击快捷键command/ctrl+shift+P，弹出下面的弹窗，输入frame，点击FPS一栏，就会在页面左上角看到图2所示的监控台，显示网页交互过程中每一帧的绘制频率。

不同帧率的体验

• 帧率能够达到 50 ～ 60 FPS 的动画将会相当流畅，让人倍感舒适；


• 帧率在 30 ～ 50 FPS 之间的动画，因各人敏感程度不同，舒适度因人而异；


• 帧率在 30 FPS 以下的动画，让人感觉到明显的卡顿和不适感；


• 帧率波动很大的动画，亦会使人感觉到卡顿

现在网上很多关于浏览器reflow的文章都说给要少用offsetTop, offsetLeft 等获取布局信息的。因为这些属性需要触发一次浏览器的的Layout。也就是说在一帧内（16ms）会多了一次layout。如果Layout的次数太多，就会导致掉帧。

视觉稳定性

视觉稳定性指标CLS（Cumulative Layout Shift），也就是布局偏移量，它是指页面从一帧切换到另外一帧时，视线中不稳定元素的偏移情况。

比如，你想要购买的商品正在参加抢购活动，而且时间快要到了。在你正要点击页面链接购买的时候，原来的位置插入了一条 9.9 元包邮的商品广告。结果会怎样？你点成了那个广告商品。如果等你再返回购买的时候，你心仪商品的抢购活动结束了，你是不是很气？所以，CLS也非常重要。

一个好的CLS分数是75%以上的用户小于0.1，如图所示：

布局偏移的具体内容

布局偏移是由 Layout Instability API 定义的。这个API会在任意时间上报 layout-shift 的条目，当一个可见元素在两帧之间，改变了它的起始位置（默认的 writing mode 下指的是top和left属性）。这些元素被当成不稳定元素。

需要注意的是，布局偏移只发生在已经存在的元素改变起始位置的时候。如果一个新的元素被添加到dom上，或者已存在的元素改变它的尺寸，除非改变了其他元素的起始位置，否则都不算布局偏移。

布局偏移主要包含以下几项：

1. 
   

   布局偏移分数：布局偏移的分数是两个度量的乘积：影响分数(impact fraction)和距离分数(distance fraction)。如果是一个很大的元素移动了较小的距离，实际影响并不大，所以分数需要依赖两个度量。

   
   


2. 
   

   影响分数：影响分数测试的是两帧之间，不稳定元素在视图上的影响范围。

   
   


3. 
   

   距离分数：距离分数测试的是两帧之间，不稳定元素在视图上移动的距离（水平和纵向取最大值）。如果有多个不稳定元素，也是取其中最大的一个。

   
   


4. 
   

   动画和过渡：动画和过渡，如果做得好，对用户而言是一个不错的更新内容的方式，这样不会给用户“惊喜”。突然出现的或者预料之外的内容，会给用户一个很差的体验。但如果是一个动画或者过渡，用户可以很清楚的知道发生了什么，在状态变化的时候可以很好的引导用户。

   
   

   CSS中的 transform 属性可以让你在使用动画的时候不会产生布局偏移。

   
   
   
   
   • 用 transform:scale() 来替换 width 和 height 属性
   
   
   • 用 transform:translate() 来替换 top, left, bottom, right 属性
   
   
   
   

CLS是平时开发很少关注的点，页面视觉稳定性对很多web开发而言，可能没有加载性能那么关注度高，但对用户而言，这确实是很困扰的一点。平时开发中，尽可能的提醒自己，不管是产品交互图出来之后，或者是UI的视觉稿出来之后，如果出现了布局偏移的情况，都可以提出这方面的意见。开发过程中也尽可能的遵循上面提到的一些优化点，给用户一个稳定的视觉体验。

RAIL测量模型

RAIL模型是2015年google提出的一个可以量化的测量标准，通过RAIL模型可以指导性能优化的目标，让良好的用户体验成为可能。

1. 
   

   Response 响应：是指用户操作网页的时候浏览器给到用户的反馈时间，其中处理事件应在50ms以内完成。

   
   

   为什么是50ms？谷歌向向用户发起调研，将用户的反馈分成了几个组，经过研究得出用户能接受的反馈时间是100ms。

   
   

   那么为什么我们要设置在50ms以内，因为100ms是用户输入到反馈的时间，但是浏览器处理反馈也需要时间，所以留给开发者优化处理事件的时间在50ms以内。如下图所示：

优质的图片可以有效吸引用户，给用户良好的体验，所以随着互联网的发展，越来越多的产品开始使用图片来提升产品体验。相较于页面其他元素，图片的体积不容忽视。下图是截止 2019 年 6 月 HTTP Archive[1] 上统计的网站上各类资源加载的体积：

1.1. 雪碧图

图片可以合并么？当然。最为常用的图片合并场景就是雪碧图（Sprite）^[3]。

在网站上通常会有很多小的图标，不经优化的话，最直接的方式就是将这些小图标保存为一个个独立的图片文件，然后通过 CSS 将对应元素的背景图片设置为对应的图标图片。这么做的一个重要问题在于，页面加载时可能会同时请求非常多的小图标图片，这就会受到浏览器并发 HTTP 请求数的限制。我见过一个没有使用雪碧图的页面，首页加载时需要发送 20+ 请求来加载图标。将图标合并为一张大图可以实现「20+ → 1」的巨大缩减。

雪碧图的核心原理在于设置不同的背景偏移量，大致包含两点：

• 不同的图标元素都会将 background-url 设置为合并后的雪碧图的 uri；


• 不同的图标通过设置对应的 background-position 来展示大图中对应的图标部分。

你可以用 Photoshop 这类工具自己制作雪碧图。当然比较推荐的还是将雪碧图的生成集成到前端自动化构建工具中，例如在 webpack 中使用 webpack-spritesmith，或者在 gulp 中使用 gulp.spritesmith。它们两者都是基于于 spritesmith 这个库，你也可以自己将这个库集成到你喜欢的构建工具中。

1.2. 懒加载

我们知道，一般来说我们访问一个页面，浏览器加载的整个页面其实是要比可视区域大很多的，也是什么我们会提出“首屏”的概念。这就导致其实很多图片是不在首屏中的，如果我们都加载的话，相当于是加载了用户不一定会看到图片。而图片体积一般都不小，这显然是一种流量的浪费。这种场景在一些带图片的长列表或者配图的博客中经常会遇到。

解决的核心思路就是图片懒加载 —— 尽量只加载用户正在浏览或者即将会浏览到的图片。实现上来说最简单的就是通过监听页面滚动，判断图片是否进入视野，从而真正去加载图片：

function loadIfNeeded($img) {
    const bounding = $img..getBoundingClientRect();
    if (
        getComputedStyle($img).display !== 'none'
        && bounding.top <= window.innerHeight
        && bounding.bottom >= 0
    ) {
        $img.src = $img.dataset.src;
        $img.classList.remove('lazy');
    }
}

// 这里使用了 throttle，你可以实现自己的 throttle，也可以使用 lodash
const lazy = throttle(function () {
    const $imgList = document.querySelectorAll('.lazy');
    if ($imgList.length === 0) {
        document.removeEventListener('scroll', lazy);
        window.removeEventListener('resize', lazy);
        window.removeEventListener('orientationchange', lazy);
        return;
    }
    $imgList.forEach(loadIfNeeded);
}, 200);

document.addEventListener('scroll', lazy);
window.addEventListener('resize', lazy);
window.addEventListener('orientationchange', lazy);

对于页面上的元素只需要将原本的 src 值设置到 data-src 中即可，而 src 可以设置为一个统一的占位图。注意，由于页面滚动、缩放和横竖方向（移动端）都可能会改变可视区域，因此添加了三个监听。

当然，这是最传统的方法，现代浏览器还提供了一个更先进的 Intersection Observer API^[4] 来做这个事，它可以通过更高效的方式来监听元素是否进入视口。考虑兼容性问题，在生产环境中建议使用对应的 polyfill。

如果想使用懒加载，还可以借助一些已有的工具库，例如 aFarkas/lazysizes、verlok/lazyload、tuupola/lazyload 等。

在使用懒加载时也有一些注意点：

• 首屏可以不需要懒加载，对首屏图片也使用懒加载会延迟图片的展示。


• 设置合理的占位图，避免图片加载后的页面“抖动”。


• 虽然目前基本所有用户都不会禁用 JavaScript，但还是建议做一些 JavaScript 不可用时的 backup。

对于占位图这块可以再补充一点。为了更好的用户体验，我们可以使用一个基于原图生成的体积小、清晰度低的图片作为占位图。这样一来不会增加太大的体积，二来会有很好的用户体验。LQIP (Low Quality Image Placeholders)^[5] 就是这种技术。目前也已经有了 LQIP 和 SQIP(SVG-based LQIP) 的自动化工具可以直接使用。

如果你想了解更多关于图片懒加载的内容，这里有一篇更详尽的图片懒加载指南^[6]。

1.3. CSS 中的图片懒加载

除了对于 <img> 元素的图片进行来加载，在 CSS 中使用的图片一样可以懒加载，最常见的场景就是 background-url 

.login {
    background-url: url(/static/img/login.png);
}

对于上面这个样式规则，如果不应用到具体的元素，浏览器不会去下载该图片。所以你可以通过切换 className 的方式，放心得进行 CSS 中图片的懒加载。

1.4. 内联 base64

还有一种方式是将图片转为 base64 字符串，并将其内联到页面中返回，即将原 url 的值替换为 base64。这样，当浏览器解析到这个的图片 url 时，就不会去请求并下载图片，直接解析 base64 字符串即可。

但是这种方式的一个缺点在于相同的图片，相比使用二进制，变成 base64 后体积会增大 33%。而全部内联进页面后，也意味着原本可能并行加载的图片信息，都会被放在页面请求中（像当于是串行了）。同时这种方式也不利于复用独立的文件缓存。所以，使用 base64 需要权衡，常用于首屏加载 CRP 或者骨架图上的一些小图标。

2. 减小图片大小

2.1. 使用合适的图片格式

使用合适的图片格式不仅能帮助你减少不必要的请求流量，同时还可能提供更好的图片体验。

图片格式是一个比较大的话题，选择合适的格式^[7]有利于性能优化。这里我们简单总结一些。

1) 使用 WebP：

考虑在网站上使用 WebP 格式^[8]。在有损与无损压缩上，它的表现都会优于传统（JPEG/PNG）格式。WebP 无损压缩比 PNG 的体积小 26%，webP 的有损压缩比同质量的 JPEG 格式体积小 25-34%。同时 WebP 也支持透明度。下面提供了一种兼容性较好的写法。

<picture>
    <source type="image/webp" srcset="/static/img/perf.webp">
    <source type="image/jpeg" srcset="/static/img/perf.jpg">
    <img src="/static/img/perf.jpg">
</picture>

2) 使用 SVG 应对矢量图场景：

在一些需要缩放与高保真的情况，或者用作图标的场景下，使用 SVG 这种矢量图非常不错。有时使用 SVG 格式会比相同的 PNG 或 JPEG 更小。

3) 使用 video 替代 GIF：

在兼容性允许的情况下考虑，可以在想要动图效果时使用视频，通过静音（muted）的 video 来代替 GIF。相同的效果下，GIF 比视频（MPEG-4）大 5～20 倍。Smashing Magazine 上有篇文章^[9]详细介绍使用方式。

4) 渐进式 JPEG：

基线 JPEG (baseline JPEG) 会从上往下逐步呈现，类似下面这种：

而另一种渐进式 JPEG (progressive JPEG)[10] 则会从模糊到逐渐清晰，使人的感受上会更加平滑。

<img srcset="small.jpg 480w, large.jpg 1080w" sizes="50w" src="large.jpg" >