前言：Chuck是Android OkHttp客户端的一个简单的应用内HTTP检查器。Chuck拦截并持久化应用程序中的所有HTTP请求和响应，并提供用于检查其内容的UI。

使用Chuck的应用程序将显示一个通知，显示正在进行的HTTP活动的摘要。点击通知启动完整的Chuck UI。应用程序可以选择性地抑制通知，并直接从自己的界面中启动Chuck UI。HTTP交互及其内容可以通过共享意图导出。

主要的Chuck活动是在它自己的任务中启动的，允许它与使用Android7.x多窗口支持的主机应用程序UI一起显示。

警告：使用此拦截器时生成和存储的数据可能包含敏感信息，如授权或Cookie头，以及请求和响应主体的内容。它用于开发过程中，而不是发布版本或其他生产部署中。

如果你使用OkHttp作为网络请求库，那么这个Chuck库可以帮助你拦截留存所有的HTTP请求和相应信息。同时也提供UI来显示拦截的信息

效果如下：

安装
配置：

dependencies {
debugCompile 'com.readystatesoftware.chuck:library:1.0.4'
releaseCompile 'com.readystatesoftware.chuck:library-no-op:1.0.4'
}

在您的应用程序代码中，创建一个ChuckInterceptor实例（您需要为它提供一个上下文，因为Android）并在构建OkHttp客户端时将其添加为拦截器：

OkHttpClient client = new OkHttpClient.Builder()
.addInterceptor(new ChuckInterceptor(context))
.build();

就这样！Chuck现在将记录OkHttp客户端进行的所有HTTP交互。您可以选择通过在拦截器实例上调用showNotification（false）来禁用通知，并使用Chuck.getLaunchIntent（）中的意图直接在应用程序中启动Chuck UI。

Github地址：https://github.com/jgilfelt/chuck

下载地址：chuck-master.zip

PreviewSeekBar

其实大家用PC优酷看视频的时候，鼠标放到进度条撒花姑娘就可以预览到所指向的帧画面。



一个叫[Ruben Sousa](https://medium.com/@rubensousa)的哥们做出了一个库并开源。

效果如下L：

使用说明：

dependencies {
    compile 'com.github.rubensousa:previewseekbar:0.3'
}

<com.github.rubensousa.previewseekbar.PreviewSeekBarLayout
      android:id="@+id/previewSeekBarLayout"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"
      android:orientation="vertical">
      <FrameLayout
          android:id="@+id/previewFrameLayout"
          android:layout_width="@dimen/video_preview_width"
          android:layout_height="@dimen/video_preview_height">
          <View
              android:id="@+id/videoView"
              android:layout_width="match_parent"
              android:layout_height="match_parent"
              android:layout_gravity="start"
              android:background="@color/colorPrimary" />
      </FrameLayout>
      <com.github.rubensousa.previewseekbar.PreviewSeekBar
          android:id="@+id/previewSeekBar"
          android:layout_width="match_parent"
          android:layout_height="wrap_content"
          android:layout_below="@id/previewFrameLayout"
          android:layout_marginTop="25dp"
          android:max="800" />
</com.github.rubensousa.previewseekbar.PreviewSeekBarLayout>

// setOnSeekBarChangeListener was overridden to do the same as below
seekBar.addOnSeekBarChangeListener(this);

@Override
public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) {
    // I can't help anymore
}

Github地址：https://github.com/rubensousa/PreviewSeekBar

下载地址：Store-feature-rx2.zip

Store

Store是一个异步数据加载和缓存数据的库。

实现一个 Disk Cache 需要以下几个步骤：

在 Retrofit 的 API 下

@GET("/v1/events")
Single getEventsResponseBody();
两点需要注意，一是要用 Single，而是要用 ResponseBody

创建 fetcher

private fun fetcher(): Single {
return service.getEventsResponseBody().map({ it.source() })
}

private fun provideStore(): Store {
return StoreBuilder.parsedWithKey()
.fetcher { fetcher() }
.persister(FileSystemPersister.create(FileSystemFactory.create(filesDir)) { key -> key })
.parser(JacksonParserFactory.createSourceParser(Events::class.java))
.open()
}

使用 Store

store.get("cache_key") // get or fetch

Github地址：https://github.com/NYTimes/Store

下载地址：Store-feature-rx2.zip

StyleableToast

这也是一个Toast增强库。

• 设置背景颜色的吐司。
• 设置吐司和存档的圆角半径不同的形状。
• 设置吐司给你所有的透明固体或透明的吐司。
• 设置笔划宽度和中风颜色在你的吐司。
• 设置一个图标旁边的面包文本。

• 你的图标上设置一个旋转的动画效果(见下面的例子01) 从Api 16 +工作

效果如下：

使用

1，在app/build.gradle文件中添加如下代码：

compile 'com.muddzdev:styleabletoast:1.0.6'

2，布局文件：main.xml就是几个按钮就不贴出来了，直接上一个是动态刷新的那个布局和飞行模式：
飞行模式：ic_airplanemode_inactive_black_24dp.xml

<vector xmlns:android="http://schemas.android.com/apk/res/android"
android:width="24dp"
android:height="24dp"
android:viewportWidth="24.0"
android:viewportHeight="24.0">
<path
android:fillColor="#ffffff"
android:pathData="M13,9V3.5c0,-0.83 -0.67,-1.5 -1.5,-1.5S10,2.67 10,3.5v3.68l7.83,7.83L21,16v-2l-8,-5zM3,5.27l4.99,4.99L2,14v2l8,-2.5V19l-2,1.5V22l3.5,-1 3.5,1v-1.5L13,19v-3.73L18.73,21 20,19.73 4.27,4 3,5.27z"/>
</vector>

动态刷新: ic_autorenew_black_24dp.xml

<vector xmlns:android="http://schemas.android.com/apk/res/android"
android:width="24dp"
android:height="24dp"
android:viewportWidth="24.0"
android:viewportHeight="24.0">
<path
android:fillColor="#fff"
android:pathData="M12,6v3l4,-4 -4,-4v3c-4.42,0 -8,3.58 -8,8 0,1.57 0.46,3.03 1.24,4.26L6.7,14.8c-0.45,-0.83 -0.7,-1.79 -0.7,-2.8 0,-3.31 2.69,-6 6,-6zM18.76,7.74L17.3,9.2c0.44,0.84 0.7,1.79 0.7,2.8 0,3.31 -2.69,6 -6,6v-3l-4,4 4,4v-3c4.42,0 8,-3.58 8,-8 0,-1.57 -0.46,-3.03 -1.24,-4.26z"/>
</vector>

3，使用方式：
1>在styles.xml文件中添加样式：

<style name="StyleableToast">

<item name="android:textColor">@color/red</item>
<item name="android:colorBackground">@color/gray</item>
<!--<item name="android:fontFamily">fonts/dosis.otf"</item>-->
<item name="android:textStyle">bold</item>
<!--<item name="android:strokeWidth">2</item>-->
<!--<item name="android:strokeColor">@color/colorPrimary</item>-->
<!--<item name="android:radius">@dimen/toastRadius</item>-->
<item name="android:alpha">255</item>
<item name="android:icon">@drawable/ic_file_download</item>
</style>

使用：

case R.id.btn_toast_style_05 :
StyleableToast.makeText(this, "Picture saved in gallery", Toast.LENGTH_LONG, R.style.StyleableToast).show();
break;

2>，使用code:

private StyleableToast st;

case R.id.btn_toast_style_01 :
st = new StyleableToast(this, "加载中...", Toast.LENGTH_LONG);
st.setBackgroundColor(Color.parseColor("#ff5a5f"));
st.setTextColor(Color.WHITE);
st.setIcon(R.drawable.ic_autorenew_black_24dp);
st.spinIcon();
st.setMaxAlpha();
st.show();
break;

3> .Builder

private StyleableToast stBuilder;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

initView();

stBuilder = new StyleableToast.Builder(this,"已关闭飞行模式")
.withBackgroundColor(Color.parseColor("#865aff"))
.withIcon(R.drawable.ic_airplanemode_inactive_black_24dp)
.withMaxAlpha()
.build();
}
...
case R.id.btn_toast_style_02 :
stBuilder.show();
break;

Github地址：https://github.com/Muddz/StyleableToast

下载地址：StyleableToast-master.zip

Toasty

这是一个自定义Toast的库。

效果图：

1. 添加这个在你的Project的 build.gradle 文件（ 不是 你的Module的 build.gradle 文件）：

allprojects {
repositories {
...
maven { url "https://jitpack.io" }
}
}

依赖
添加到你的Module的build.gradle文件：

dependencies {
...
compile 'com.github.GrenderG:Toasty:1.2.5'
}

配置
这一步是可选的，但如果你想要，你可以配置一些Toasty参数。把这个地方放在你的应用程序中

Toasty.Config.getInstance()
.setErrorColor(@ColorInt int errorColor) // optional
.setInfoColor(@ColorInt int infoColor) // optional
.setSuccessColor(@ColorInt int successColor) // optional
.setWarningColor(@ColorInt int warningColor) // optional
.setTextColor(@ColorInt int textColor) // optional
.tintIcon(boolean tintIcon) // optional (apply textColor also to the icon)
.setToastTypeface(@NonNull Typeface typeface) // optional
.setTextSize(int sizeInSp) // optional
.apply(); // required
To display an error Toast:

Toasty.error(yourContext, "This is an error toast.", Toast.LENGTH_SHORT, true).show();
To display a success Toast:

Toasty.success(yourContext, "Success!", Toast.LENGTH_SHORT, true).show();
To display an info Toast:

Toasty.info(yourContext, "Here is some info for you.", Toast.LENGTH_SHORT, true).show();
To display a warning Toast:

Toasty.warning(yourContext, "Beware of the dog.", Toast.LENGTH_SHORT, true).show();
To display the usual Toast:

Toasty.normal(yourContext, "Normal toast w/o icon").show();
To display the usual Toast with icon:

Toasty.normal(yourContext, "Normal toast w/ icon", yourIconDrawable).show();
You can also create your custom Toasts with the custom() method:

Toasty.custom(yourContext, "I'm a custom Toast", yourIconDrawable, tintColor, duration, withIcon,
shouldTint).show();

Github地址：https://github.com/GrenderG/Toasty

下载地址：Toasty-master.zip

Lottie

效果图如下：

本文主要介绍动画开源库 Lottie 在 Android 中的使用。

前言

在日常APP开发中，为了提升用户感官舒适度等原因，我们会在APP中加入适量动画。
而传统手写动画方式往往存在诸多问题:

• 动画复杂而实现困难




• 图片素材占用体积过大




• 不同Native平台都需各自实现，开发成本高




• 不同Native平台实现的最终效果不一致




• 后期视觉联调差异化大

难道就没有一种简便且高效的方案来减缓或解决上述问题吗？

答: 有的，那就是本文要介绍的主角 Lottie。

一、Lottie 是什么？

Lottie是Airbnb开源的一个面向IOS、Android、React Native的动画库，可以解析用 Adobe After Effects 制作动画后通过 Bodymovin 插件导出的 Json 数据文件并在移动端原生渲染。

通俗点说，它是一款动画开源库，通过解析特定的Json文件或Json文本，可直接在移动端上渲染出复杂的动画效果。

二、Lottie 能干什么?

它可以简便高效的实现复杂动画，替代传统低效的手写动画方式。

动画展示:

上方的动画是通过Lottie直接实现的。

如果我们使用手写代码方式实现，可以说是很难！

而通过 Lottie 实现时，需要的仅是一个Json文件或一段Json文本，并通过简洁的代码集成即可。

集成代码可能精简到如下模样:

1

2

3

4

5

6

7

<com.airbnb.lottie.LottieAnimationView

    android:id="@+id/animation_view"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"  

    app:lottie_rawRes="@raw/anim_lottie"

    app:lottie_loop="true"

    app:lottie_autoPlay="true" />

三、为什么使用 Lottie?

• 简便，开发成本低
  相对于传统方式，动画不再是全部手写，所需做得只是嵌入XML并配置动画属性，集成快，开发时间少，开发成本低。




• 不同 Native 平台效果基本一致
  渲染交由Lottie引擎内部实现，无需开发者处理平台差异，多平台共用同一个动画配置文件，效果一致性高。




• 占用包体积小
  Lottie配置文件由Json文本串构成，相对于图片，占用体积更小。




• 动画效果不失真
  传统图片拉伸或压缩导致失真，而Lottie为矢量图展示，不会出现失真情况。




• 动画效果可以云端控制
  由于Lottie动画基于Json文件或文本解析，因此可以实现云端下发，实现动态加载，动态控制动画样式。

四、如何使用 Lottie？

Lottie 仅支持用 Gradle 构建配置，最低支持安卓版本 16。

1. 添加依赖到 build.gradle

1

2

3

4

5

6

7

dependencies {

    implementation 'com.airbnb.android:lottie:2.5.4'

}

或

dependencies {

    implementation "com.airbnb.android:lottie:${全局版本变量}"

}

2. 添加 Adobe After Effects 导出的动画 Json 文件

通常由视觉工程师确认动效后通过AE导出, 我们只需将该Json文件保存至 /raw 或 /assets文件夹下。

3. XML中嵌入基本布局

1

2

3

4

<com.airbnb.lottie.LottieAnimationView

    android:id="@+id/animation_view"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"/>

4. 加载播放动画，两类方式可选

① XML中静态配置, 举例:

1

2

3

4

5

6

7

8

9

10

11

12

13

<com.airbnb.lottie.LottieAnimationView

    android:id="@+id/animation_view"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"  

       

    //加载方式如下2种任选其一

    app:lottie_rawRes="@raw/hello_world"

    app:lottie_fileName="hello_world.json"

	

    //循环播放

    app:lottie_loop="true"

    //加载完毕后自动播放

    app:lottie_autoPlay="true" />

② 代码动态配置, 举例:

如下代码会在后台异步加载动画文件，并在加载完成后开始渲染动画。

1

2

3

4

LottieAnimationView animationView = ...;

animationView.setAnimation(R.raw.hello_world);

animationView.loop(true);

animationView.playAnimation();

五、其他拓展使用

1. 直接解析Json文本串加载动画

1

2

3

4

5

6

7

8

9

10

JsonReader jsonReader = new JsonReader(new StringReader(jsonStr));

lottieView.setAnimation(jsonReader);

lottieView.playAnimation();

或

Cancellable cancellable = LottieComposition.Factory.fromJsonString(jsonStr, composition -> {

            lottieView.setComposition(composition);

            lottieView.playAnimation();

        });

//必要时取消进行中的异步操作

cancellable.cancel();

2. 配合网络下载，实现下载Json配置并动态加载

1

2

3

4

5

6

7

8

9

10

11

12

13

Call<ResponseBody> call = RetrofitComponent.fetchLottieConfig();//伪代码

call.enqueue(new Callback<ResponseBody>() {

            @Override

            public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) {

                //String json = response.body().string();

                //交由Lottie处理...

            }



            @Override

            public void onFailure(Call<ResponseBody> call, Throwable t) {

                //do something.

            }

        });

3. 动画加载监听器

根据业务需要进行动画过程监听:

1

2

3

4

5

6

7

8

9

10

11

animationView.addAnimatorUpdateListener((animation) -> {

    	// do something.

});

animationView.playAnimation();

...

if (animationView.isAnimating()) {

	// do something.

}

...

animationView.setProgress(0.5f);

...

4. LottieDrawable 的使用

1

2

3

4

5

6

7

8

LottieDrawable drawable = new LottieDrawable();

LottieComposition.Factory.fromAssetFileName(getApplicationContext(), "lottie_pin_jump.json", composition -> {

            drawable.setComposition(composition);

            //目前显示为静态图

            ivLottie.setImageDrawable(drawable);

            //调用start()开始播放动画

            drawable.start();

        });

六、需要考虑的问题

1. 由于是依赖于AE做的动画，估计以后不只是要求视觉设计师精通AE，连前端开发都需要了解AE


2. Lottie 对 Json 文件的支持待完善，目前存在部分AE导出成 Json 文件无法渲染或渲染不佳


3. 支持的功能存在限制

Github地址：https://github.com/airbnb/lottie-android

下载地址：lottie-android-master.zip

1. 初始化，添加定时器前先移除

[self.timer invalidate];
self.timer = nil;
self.timer = [NSTimer scheduledTimerWithTimeInterval:2.f target:self selector:@selector(lookforCard:) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];

2. 释放timer

[self.timer invalidate];
self.timer = nil;

3. NSTimer不释放原因

• 原因是 Timer 添加到 Runloop 的时候，会被 Runloop 强引用；然后 Timer 又会有一个对 Target 的强引用（也就是 self ）

注意target参数的描述：
The object to which to send the message specified by aSelector when the timer fires. The timer maintains a strong reference to target until it (the timer) is invalidated.
注意：文档中写的很清楚，timer对target会有一个强引用，直到timer is invalidated。也就是说，在timer调用 invalidate方法之前，timer对target一直都有一个强引用。这也是为什么控制器的dealloc 方法不会被调用的原因。
方法的文档介绍：
The receiver retains aTimer. To remove a timer from all run loop modes on which it is installed, send an invalidate message to the timer.
也就是说，runLoop会对timer有强引用，因此，timer修饰符是weak，timer还是不能释放，timer的target也就不能释放。

4. 解决办法

• viewWillDisappear或viewDidDisappear中 invalidate
  这种方式是可以释放掉的，但如果我只是想在离开此页时要释放，进入下一页时不要释放，场景就不适用了

- (void)viewWillDisappear:(BOOL)animated
- (void)viewDidDisappear:(BOOL)animated

• 添加一个NSTimer的分类，把target指给[NSTimer class]，事件由加方法接收，然后把事件通过block传递出来

@interface NSTimer (Block)

+ (instancetype)scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void(^)(NSTimer *timer))block;

@end

@implementation NSTimer (Block)

+ (instancetype)scheduledTimerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void(^)(NSTimer *timer))block{
    NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:interval target:self selector:@selector(trigger:) userInfo:[block copy] repeats:repeats];
    return timer;
}

+ (void)trigger:(NSTimer *)timer{
    void(^block)(NSTimer *timer) = [timer userInfo];
    if (block) {
        block(timer);
    }
}

@end

• 使用示例

@interface SecondViewController ()

@property (nonatomic, strong) NSTimer *timer;

@end

@implementation SecondViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    __weak typeof(self) weakSelf = self;
    self.timer = [NSTimer scheduledTimerWithTimeInterval:0.5 repeats:YES block:^(NSTimer * _Nonnull timer) {
        [weakSelf doSomeThing];
    }];
    [[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];
}

- (void)dealloc {
    [self.timer invalidate];
}

@end

5. invalidate方法注意事项

invalidate方法的介绍：
（1）This method is the only way to remove a timer from an NSRunLoop object. The NSRunLoop object removes its strong reference to the timer, either just before the invalidate method returns or at some later point.
（2）You must send this message from the thread on which the timer was installed. If you send this message from another thread, the input source associated with the timer may not be removed from its run loop, which could prevent the thread from exiting properly.
两点：
（1）invalidate方法是唯一能从runloop中移除timer的方式，调用invalidate方法后，runloop会移除对timer的强引用
（2）timer的添加和timer的移除（invalidate）需要在同一个线程中，否则timer可能不能正确的移除，线程不能正确退出

附：我的博客地址

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

KeyWords
AutoLayout UIStackView

背景

随着需求的迭代，项目中在列表的同一个区域新增业务标签貌似成了每个产品经理的“特殊嗜好”。如下图中的区域

（其实本人的项目中在箭头区域大概有7个类似的标签，当然在业务上不会同时出现，能同时出现的时候最多会有四个），随着标签的增加，势必会造成繁重的视图维护工作，再加上要控制优先级之类的，估计头都大了，好在apple给咱们提供了强大的视图管理：UIStackView。我們可以透过它轻易的定义好在 UIStackView 中元件的布局，不需对于所有元件进行 AutoLayout 的约束设置，UIStackView会处理大部分的工作。

正文

apple官方文档对UIStackView的描述是：用于在列或行中布置视图集合

UIStackView要点

UIStackView是在iOS 9中引入的， 是Cocoa Touch中UI控件分类的最新成员。
通过UIStackView，你可以利用 AutoLayout 的強大功能，创建用户视图，可以动态适应设备方向，屏幕大小和可用空间任何变化的用户界面。UIStackView 管理其 arrangeSubviews 属性中所有视图的布局。這些视图基于它們在 arrangeSubviews 阵列中的順序，沿著 UIStackView 的 axis 排列。最终精确的布局依赖于 UIStackView 的 axis、distribution、alignment、spacing 以及其他属性。

我们只需要负责 UIStackView 的位置和尺寸，然后 UIStackView 就会管理其內容的布局和尺寸。

注意：放到 StackView ≠ 完成 AutoLayout

所以你还必須設定 StackView 的位置和尺寸（可選）才算是完成。StackView 只有為其 arrangeSubviews 做佈局

虽然堆栈视图允许您直接布局其内容而不直接使用“自动布局”，但仍需要使用“自动布局”来定位堆栈视图本身。通常，这意味着定位堆叠视图的至少两个相邻边缘以限定其位置。如果没有其他约束，系统将根据其内容计算堆栈视图的大小。

1、沿着堆栈视图的轴，其拟合大小等于所有排列视图的大小加上视图之间的空间的总和。

2、垂直于堆栈视图的轴，其拟合大小等于最大排列视图的大小。

3、如果堆栈视图的属性设置为，则堆栈视图的拟合大小会增加，以包含边距的空间。layoutMarginsRelativeArrangement

您可以提供其他约束来指定堆栈视图的高度，宽度或两者。在这些情况下，堆栈视图会调整其排列视图的布局和大小以填充指定区域。确切的布局根据堆栈视图的属性而有所不同。有关堆栈视图如何处理其内容的额外空间或空间不足的完整说明，请参阅和枚举。UIStackViewDistribution 、UIStackViewAlignment

您还可以基于其第一个或最后一个基线定位堆栈视图，而不是使用顶部，底部或中心Y位置。与堆栈视图的拟合大小一样，这些基线是根据堆栈视图的内容计算的。

1、水平堆栈视图返回其和方法的最高视图。如果最高视图也是堆栈视图，则返回调用结果或嵌套堆栈视图。

2、垂直堆栈视图返回其第一个排列的视图以及其最后排列的视图。如果这些视图中的任何一个也是堆栈视图，则它返回调用的结果或嵌套堆栈视图。

创建一个StackView

UILabel * main = [[UILabel alloc]init];
main.text = @"Learn More";
main.font = [UIFont boldSystemFontOfSize:28];
main.translatesAutoresizingMaskIntoConstraints = false;
main.backgroundColor = [UIColor redColor];
    
UILabel * sub = [[UILabel alloc]init];
sub.translatesAutoresizingMaskIntoConstraints = false;
sub.numberOfLines = 0;
sub.text = @"[self.collectionView.topAnchor constraintEqualToAnchor:self.view.topAnchor constant:40].active = true";
sub.font = [UIFont systemFontOfSize:18];
sub.backgroundColor = [UIColor greenColor];

UILabel * third = [[UILabel alloc]init];
third.translatesAutoresizingMaskIntoConstraints = false;
third.numberOfLines = 0;
third.text = @"Object_C";
third.font = [UIFont systemFontOfSize:18];
third.backgroundColor = [UIColor brownColor];

UIStackView * stackView = [[UIStackView alloc]initWithArrangedSubviews:@[main,sub,third]];
stackView.translatesAutoresizingMaskIntoConstraints = false;
stackView.axis = UILayoutConstraintAxisVertical;
stackView.distribution = UIStackViewDistributionFillProportionally;
stackView.alignment = UIStackViewAlignmentFill;
stackView.spacing = 10;

[stackView.topAnchor constraintEqualToAnchor:self.view.topAnchor constant:100].active = true;
[stackView.leadingAnchor constraintEqualToAnchor:self.view.leadingAnchor constant:12].active = true;
[stackView.trailingAnchor constraintEqualToAnchor:self.view.trailingAnchor constant:-12].active = true;

效果图如下：

这样一个简单的堆叠视图就创建出来了，然后咱们沿着这段代码逐一分解下

Axis

配置视图的轴线，简单说就是 UIStackView 整体的排列方式（行或列）

• UILayoutConstraintAxisVertical

• UILayoutConstraintAxisHorizontal

Distribution

确定沿堆栈轴排列的视图的布局

這个属性算是比较难以理解的属性，所以我下面一样用特殊的图形來表示，希望大家能理解。

• UIStackViewDistributionFill

 如同前面的 Fill 类似，一樣是把自身的范围給占满。

• UIStackViewDistributionFillEqually
  StackView 会平均分配各個子视图的配置，例如下面的 StackView 垂直排列时，高度则会为其子视图最高的高度。反之，水平排列则取其子视图最寬的寬度。
  

• UIStackViewDistributionFillProportionally
  你可能会觉得此属性与 Fill 属性沒有差异，但兩者的差异在于 Fill 会根据自身的尺寸來決定在 StackView 中的尺寸，而 Fill Proportionally 則是會根据 StackView 的寬或高按比例分配給其中的子视图。
  

• UIStackViewDistributionEqualSpacing
  此属性简单來說就会根据 StackView 剩余可用空間的尺寸，來分配 StackView 子视图间的间隔。

• UIStackViewDistributionEqualCentering
  此属性与上面的 Equal Spacing 意思类似，只是它是以其子视图中心點的中心与中心距離是相同來做為配置。

若說明得還不夠清楚可以看看這篇文章，了解當中的差异。
Alignment
确定垂直于堆栈轴的排列视图的布局

• 在 Axis 为 Vertical 下，各个状态下的对齐方式：

• 在 Axis 為 Horizontal 下，各个状态下的对齐方式：

Spacing

這個属性就不用多加以赘述了，就是可以自定义 StackView 的間隔大小，但是这边要注意，如果你沒有限制 StackView 的尺寸，那么就會加長或加寬 StackView。但是如果你有限制 StackView 的尺寸，那麼就會在限制尺寸下增加间隔（可能會造成跑版或失敗）。

baselineRelativeArrangement

该属性确定视图之间的垂直间距是否从基线测量。

layoutMarginsRelativeArrangement

该属性确定堆栈视图是否相对于其布局边距布置其排列的视图

注意

详情参考

从堆栈视图中删除子视图时，堆栈视图也会将其从数组中删除

从数组中删除视图不会将其作为子视图删除。堆栈视图不再管理视图的大小和位置，但视图仍然是视图层次结构的一部分，并且如果可见，则在屏幕上呈现

无论何时添加，删除或插入视图，或者每当其中一个已排列的子视图的属性发生更改时，堆栈视图都会自动更新其布局（比如hidden，更改布局方向...）

后记

堆栈视图为我们执行的自动布局计算会带来性能成本。在大多数情况下，它可以忽略不计。但是当堆栈视图嵌套超过两层时，可能会变得明显。
为了安全起见，请避免使用深层嵌套的堆栈视图，尤其是在可重用的视图（如表和集合视图单元格）中。

链接：https://www.jianshu.com/p/7920d287c13b

导读：你想知道Swift内部对象是如何创建的吗？方法以及函数调用又是如何实现的吗？成员变量的访问以及对象内存布局又是怎样的吗？这些问题都会在这篇文章中得到解答。为了更好的让大家理解这些内部实现，我会将源代码翻译为用C语言表示的伪代码来实现。

Objective-C语言是一门以C语言为基础的面向对象编程语言，其提供的运行时(Runtime)机制使得它也可以被认为是一种动态语言。运行时的特征之一就是对象方法的调用是在程序运行时才被确定和执行的。系统提供的开放接口使得我们可以在程序运行的时候执行方法替换以便实现一些诸如系统监控、对象行为改变、Hook等等的操作处理。然而这种开放性也存在着安全的隐患，我们可以借助Runtime在AOP层面上做一些额外的操作，而这些额外的操作因为无法进行管控， 所以有可能会输出未知的结果。

可能是苹果意识到了这个问题，所以在推出的Swift语言中Runtime的能力得到了限制，甚至可以说是取消了这个能力，这就使得Swift成为了一门静态语言。Swift语言中对象的方法调用机制和OC语言完全不同，Swift语言的对象方法调用基本上是在编译链接时刻就被确定的，可以看做是一种硬编码形式的调用实现。

Swfit中的对象方法调用机制加快了程序的运行速度，同时减少了程序包体积的大小。但是从另外一个层面来看当编译链接优化功能开启时反而又会出现包体积增大的情况。Swift在编译链接期间采用的是空间换时间的优化策略，是以提高运行速度为主要优化考虑点。具体这些我会在后面详细谈到。

通过程序运行时汇编代码分析Swift中的对象方法调用，发现其在Debug模式下和Release模式下的实现差异巨大。其原因是在Release模式下还同时会把编译链接优化选项打开。因此更加确切的说是在编译链接优化选项开启与否的情况下二者的实现差异巨大。

在这之前先介绍一下OC和Swift两种语言对象方法调用的一般实现。

OC类的对象方法调用

对于OC语言来说对象方法调用的实现机制有很多文章都进行了深入的介绍。所有OC类中定义的方法函数的实现都隐藏了两个参数：一个是对象本身，一个是对象方法的名称。每次对象方法调用都会至少传递对象和对象方法名称作为开始的两个参数，方法的调用过程都会通过一个被称为消息发送的C函数objc_msgSend来完成。objc_msgSend函数是OC对象方法调用的总引擎，这个函数内部会根据第一个参数中对象所保存的类结构信息以及第二个参数中的方法名来找到最终要调用的方法函数的地址并执行函数调用。这也是OC语言Runtime的实现机制，同时也是OC语言对多态的支持实现。整个流程就如下表述：

Swift类的对象创建和销毁

在Swift中可以定义两种类：一种是从NSObject或者派生类派生的类，一类是从系统Swift基类SwiftObject派生的类。对于后者来说如果在定义类时没有指定基类则默认会从基类SwiftObject派生。SwiftObject是一个隐藏的基类，不会在源代码中体现。

Swift类对象的内存布局和OC类对象的内存布局相似。二者对象的最开始部分都有一个isa成员变量指向类的描述信息。Swift类的描述信息结构继承自OC类的描述信息，但是并没有完全使用里面定义的属性，对于方法的调用则主要是使用其中扩展了一个所谓的虚函数表的区域，关于这部分会在后续中详细介绍。

Swift类的对象实例都是在堆内存中创建，这和OC语言的对象实例创建方式相似。系统会为类提供一个默认的init构造函数，如果想自定义构造函数则需要重写和重载init函数。一个Swift类的对象实例的构建分为两部分：首先是进行堆内存的分配，然后才是调用init构造函数。在源代码编写中不会像OC语言那样明确的分为alloc和init两个分离的调用步骤，而是直接采用:类名(初始化参数)这种方式来完成对象实例的创建。在编译时系统会为每个类的初始化方法生成一个:模块名.类名.__allocating_init(类名,初始化参数)的函数，这个函数的伪代码实现如下：

//假设定义了一个CA类。
class CA {
   init(_ a:Int){}
}

//编译生成的对象内存分配创建和初始化函数代码
CA * XXX.CA.__allocating_init(swift_class  classCA,  int a)
{
    CA *obj = swift_allocObject(classCA);  //分配内存。
    obj->init(a);  //调用初始化函数。
}

//编译时还会生成对象的析构和内存销毁函数代码
XXX.CA.__deallocating_deinit(CA *obj)
{
   obj->deinit()  //调用析构函数
   swift_deallocClassInstance(obj);  //销毁对象分配的内存。
}

其中的swift_class 就是从objc_class派生出来，用于描述类信息的结构体。

Swift对象的生命周期也和OC对象的生命周期一样是通过引用计数来进行控制的。当对象初次创建时引用计数被设置为1，每次进行对象赋值操作都会调用swift_retain函数来增加引用计数，而每次对象不再被访问时都会调用swift_release函数来减少引用计数。当引用计数变为0后就会调用编译时为每个类生成的析构和销毁函数：模块名.类名.__deallocating_deinit(对象)。这个函数的定义实现在前面有说明。

这就是Swift对象的创建和销毁以及生命周期的管理过程，这些C函数都是在编译链接时插入到代码中并形成机器代码的，整个过程对源代码透明。下面的例子展示了对象创建和销毁的过程。

////////Swift源代码

let obj1:CA = CA(20);
let obj2 = obj1

///////C伪代码

CA *obj1 = XXX.CA. __allocating_init(classCA, 20);
CA *obj2 = obj1;
swift_retain(obj1);
swift_release(obj1);
swift_release(obj2);

swift_release函数内部会在引用计数为0时调用模块名.类名.__deallocating_deinit(对象)函数进行对象的析构和销毁。这个函数的指针保存在swift类描述信息结构体中，以便swift_release函数内部能够访问得到。

Swift类的对象方法调用

Swift语言中对象的方法调用的实现机制和C++语言中对虚函数调用的机制是非常相似的。(需要注意的是我这里所说的调用实现只是在编译链接优化选项开关在关闭的时候是这样的,在优化开关打开时这个结论并不正确)。

Swift语言中类定义的方法可以分为三种：OC类的派生类并且重写了基类的方法、extension中定义的方法、类中定义的常规方法。针对这三种方法定义和实现，系统采用的处理和调用机制是完全不一样的。

OC类的派生类并且重写了基类的方法

如果在Swift中的使用了OC类，比如还在使用的UIViewController、UIView等等。并且还重写了基类的方法，比如一定会重写UIViewController的viewDidLoad方法。对于这些类的重写的方法定义信息还是会保存在类的Class结构体中，而在调用上还是采用OC语言的Runtime机制来实现，即通过objc_msgSend来调用。而如果在OC派生类中定义了一个新的方法的话则实现和调用机制就不会再采用OC的Runtime机制来完成了，比如说在UIView的派生类中定义了一个新方法foo，那么这个新方法的调用和实现将与OC的Runtime机制没有任何关系了！ 它的处理和实现机制会变成我下面要说到的第三种方式。下面的Swift源代码以及C伪代码实现说明了这个情况：

////////Swift源代码

//类定义
class MyUIView:UIView {
    open func foo(){}   //常规方法
    override func layoutSubviews() {}  //重写OC方法
}

func main(){
  let obj = MyUIView()
  obj.layoutSubviews()   //调用OC类重写的方法
  obj.foo()   //调用常规的方法。
}

////////C伪代码

//...........................................运行时定义部分

//OC类的方法结构体
struct method_t {
    SEL name;
    IMP imp;
};

//Swift类描述
struct swift_class {
    ...   //其他的属性，因为这里不关心就不列出了。
    struct method_t  methods[1];
    ...   //其他的属性，因为这里不关心就不列出了。
    //虚函数表刚好在结构体的第0x50的偏移位置。
    IMP vtable[1];
};


//...........................................源代码中类的定义和方法的定义和实现部分

//类定义
struct MyUIView {
      struct swift_class *isa;
}

//类的方法函数的实现
void layoutSubviews(id self, SEL _cmd){}
void foo(){}  //Swift类的常规方法中和源代码的参数保持一致。

//类的描述信息构建，这些都是在编译代码时就明确了并且保存在数据段中。
struct swift_class classMyUIView;
classMyUIView.methods[0] = {"layoutSubviews", &layoutSubviews};
classMyUIView.vtable[0] = {&foo};


//...........................................源代码中程序运行的部分

void main(){
  MyUIView *obj = MyUIView.__allocating_init(classMyUIView);
  obj->isa = &classMyUIView;
  //OC类重写的方法layoutSubviews调用还是用objc_msgSend来实现
  objc_msgSend(obj, @selector(layoutSubviews);
  //Swift方法调用时对象参数被放到x20寄存器中
  asm("mov x20, obj");
  //Swift的方法foo调用采用间接调用实现
  obj->isa->vtable[0]();
}

extension中定义的方法

如果是在Swift类的extension中定义的方法(重写OC基类的方法除外)。那么针对这个方法的调用总是会在编译时就决定，也就是说在调用这类对象方法时，方法调用指令中的函数地址将会以硬编码的形式存在。在extension中定义的方法无法在运行时做任何的替换和改变！而且方法函数的符号信息都不会保存到类的描述信息中去。这也就解释了在Swift中派生类无法重写一个基类中extension定义的方法的原因了。因为extension中的方法调用是硬编码完成，无法支持多态！下面的Swift源代码以及C伪代码实现说明了这个情况：

////////Swift源代码

//类定义
class CA {
    open func foo(){}
}

//类的extension定义
extension CA {
   open func extfoo(){}
}

func main() {
  let obj = CA()
  obj.foo()
  obj.extfoo()
}

////////C伪代码

//...........................................运行时定义部分


//Swift类描述。
struct  swift_class {
    ...   //其他的属性，因为这里不关心就不列出了。
   //虚函数表刚好在结构体的第0x50的偏移位置。
    IMP vtable[1];
};


//...........................................源代码中类的定义和方法的定义和实现部分


//类定义
struct CA {
      struct  swift_class *isa;
}

//类的方法函数的实现定义
void foo(){}
//类的extension的方法函数实现定义
void extfoo(){}

//类的描述信息构建，这些都是在编译代码时就明确了并且保存在数据段中。
//extension中定义的函数不会保存到虚函数表中。
struct swift_class classCA;
classCA.vtable[0] = {&foo};


//...........................................源代码中程序运行的部分

void main(){
  CA *obj =  CA.__allocating_init(classCA)
  obj->isa = &classCA;
  asm("mov x20, obj");
  //Swift中常规方法foo调用采用间接调用实现
  obj->isa->vtable[0]();
  //Swift中extension方法extfoo调用直接硬编码调用，而不是间接调用实现
  extfoo();
}

需要注意的是extension中是可以重写OC基类的方法，但是不能重写Swift类中的定义的方法。具体原因根据上面的解释就非常清楚了。

类中定义的常规方法

如果是在Swift中定义的常规方法，方法的调用机制和C++中的虚函数的调用机制是非常相似的。Swift为每个类都建立了一个被称之为虚表的数组结构，这个数组会保存着类中所有定义的常规成员方法函数的地址。每个Swift类对象实例的内存布局中的第一个数据成员和OC对象相似，保存有一个类似isa的数据成员。isa中保存着Swift类的描述信息。对于Swift类的类描述结构苹果并未公开(也许有我并不知道)，类的虚函数表保存在类描述结构的第0x50个字节的偏移处，每个虚表条目中保存着一个常规方法的函数地址指针。每一个对象方法调用的源代码在编译时就会转化为从虚表中取对应偏移位置的函数地址来实现间接的函数调用。下面是对于常规方法的调用Swift语言源代码和C语言伪代码实现:

////////Swift源代码

//基类定义
class CA {
  open func foo1(_ a:Int){}
  open func foo1(_ a:Int, _ b:Int){}
  open func foo2(){}
}

//扩展
extension CA{
  open func extfoo(){} 
}

//派生类定义
class CB:CA{
  open func foo3(){}
  override open func foo1(_ a:Int){}
}

func testfunc(_ obj:CA){
  obj.foo1(10)
}

func main() {
  let objA = A()
  objA.foo1(10)
  objA.foo1(10,20)
  objA.foo2()
  objA.extfoo()

  let objB = B()
  objB.foo1(10)
  objB.foo1(10,20)
  objB.foo2()
  objB.foo3()
  objB.extfoo()

  testfunc(objA)
  testfunc(objB)
}

////////C伪代码

//...........................................运行时定义部分

//Swift类描述。
struct swift_class {
    ...   //其他的属性，因为这里不关心就不列出了
    //虚函数表刚好在结构体的第0x50的偏移位置。
    IMP vtable[0];
};


//...........................................源代码中类的定义和方法的定义和实现部分


//基类定义
struct CA {
      struct swift_class *isa;
};

//派生类定义
struct CB {
   struct swift_class *isa;
};

//基类CA的方法函数的实现，这里对所有方法名都进行修饰命名
void _$s3XXX2CAC4foo1yySiF(int a){}   //CA类中的foo1
void _$s3XXX2CAC4foo1yySi_SitF(int a, int b){} //CA类中的两个参数的foo1
void _$s3XXX2CAC4foo2yyF(){}   //CA类中的foo2
void _$s3XXX2CAC6extfooyyF(){} //CA类中的extfoo函数  

//派生类CB的方法函数的实现。
void _$s3XXX2CBC4foo1yySiF(int a){}   //CB类中的foo1,重写了基类的方法,但是名字不一样了。
void _$s3XXX2CBC4foo3yyF(){}             //CB类中的foo3

 //构造基类的描述信息以及虚函数表
struct swift_class classCA;
classCA.vtable[3] = {&_$s3XXX2CAC4foo1yySiF, &_$s3XXX2CAC4foo1yySi_SitF, &_$s3XXX2CAC4foo2yyF};

//构造派生类的描述信息以及虚函数表，注意这里虚函数表会将基类的函数也添加进来而且排列在前面。
struct swift_class classCB;
classCB.vtable[4] = {&_$s3XXX2CBC4foo1yySiF, &_$s3XXX2CAC4foo1yySi_SitF, &_$s3XXX2CAC4foo2yyF, &_$s3XXX2CBC4foo3yyF};

void testfunc(A *obj){
   obj->isa->vtable[0](10);   //间接调用实现多态的能力。
}


//...........................................源代码中程序运行的部分

void main(){
   CA *objA = CA.__allocating_init(classCA);
   objA->isa = &classCA;
   asm("mov x20, objA")
   objA->isa->vtable[0](10);
   objA->isa->vtable[1](10,20);
   objA->isa->vtable[2]();
   _$s3XXX2CAC6extfooyyF()

  CB *objB = CB.__allocating_init(classCB);
  objB->isa = &classCB;
  asm("mov x20, objB");
  objB->isa->vtable[0](10);
  objB->isa->vtable[1](10,20);
  objB->isa->vtable[2]();
  objB->isa->vtable[3]();
   _$s3XXX2CAC6extfooyyF();

  testfunc(objA);
  testfunc(objB);

}

从上面的代码中可以看出一些特点：

1、Swift类的常规方法中不会再有两个隐藏的参数了，而是和字面定义保持一致。那么问题就来了，方法调用时对象如何被引用和传递呢？在其他语言中一般情况下对象总是会作为方法的第一个参数，在编译阶段生成的机器码中，将对象存放在x0这个寄存器中(本文以arm64体系结构为例)。而Swift则不同，对象不再作为第一个参数来进行传递了，而是在编译阶段生成的机器码中，将对象存放在x20这个寄存器中(本文以arm64体系结构为例)。这样设计的一个目的使得代码更加安全。

2、每一个方法调用都是通过读取方法在虚表中的索引获取到了方法函数的真实地址，然后再执行间接调用。在这个过程虚表索引的值是在编译时就确定了，因此不再需要通过方法名来在运行时动态的去查找真实的地址来实现函数调用了。虽然索引的位置在编译时确定的，但是基类和派生类虚表中相同索引处的函数的地址确可以不一致，当派生类重写了父类的某个方法时，因为会分别生成两个类的虚表，在相同索引位置保存不同的函数地址来实现多态的能力。

3、每个方法函数名字都和源代码中不一样了，原因在于在编译链接是系统对所有的方法名称进行了重命名处理，这个处理称为命名修饰。之所以这样做是为了解决方法重载和运算符重载的问题。因为源代码中重载的方法函数名称都一样只是参数和返回类型不一样，因此无法简单的通过名字进行区分，而只能对名字进行修饰重命名。另外一个原因是Swift还提供了命名空间的概念，也就是使得可以支持不同模块之间是可以存在相同名称的方法或者函数。因为整个重命名中是会带上模块名称的。下面就是Swift中对类的对象方法的重命名修饰规则：
_$s<模块名长度><模块名><类名长度><类名>C<方法名长度><方法名>yy<参数类型1>_<参数类型2>_<参数类型N>F

就比如上面的CA类中的foo1两个同名函数在编译链接时刻就会被分别重命名为：

//这里面的XXX就是你工程模块的名称。
void _$s3XXX2CAC4foo1yySiF(int a){}   //CA类中的foo1
void _$s3XXX2CAC4foo1yySi_SitF(int a, int b){} //CA类中的两个参数的foo1

下面这张图就清晰的描述了Swift类的对象方法调用以及类描述信息。

Swift类中成员变量的访问

虽然说OC类和Swift类的对象内存布局非常相似，每个对象实例的开始部分都是一个isa数据成员指向类的描述信息，而类中定义的属性或者变量则一般会根据定义的顺序依次排列在isa的后面。OC类还会为所有成员变量，生成一张变量表信息，变量表的每个条目记录着每个成员变量在对象内存中的偏移量。这样在访问对象的属性时会通过偏移表中的偏移量来读取偏移信息，然后再根据偏移量来读取或设置对象的成员变量数据。在每个OC类的get和set两个属性方法的实现中，对于属性在类中的偏移量值的获取都是通过硬编码来完成，也就是说是在编译链接时刻决定的。

对于Swift来说，对成员变量的访问得到更加的简化。系统会对每个成员变量生成get/set两个函数来实现成员变量的访问。系统不会再为类的成员变量生成变量偏移信息表，因此对于成员变量的访问就是直接在编译链接时确定成员变量在对象的偏移位置，这个偏移位置是硬编码来确定的。下面展示Swift源代码和C伪代码对数据成员访问的实现：

////////Swift源代码

class CA
{
   var a:Int = 10
   var b:Int = 20
}

void main()
{
    let obj = CA()
    obj.b = obj.a
}

////////C伪代码

//...........................................运行时定义部分

//Swift类描述。
struct swift_class {
    ...   //其他的属性，因为这里不关心就不列出了
    //虚函数表刚好在结构体的第0x50的偏移位置。
    IMP vtable[4];
};


//...........................................源代码中类的定义和方法的定义和实现部分

//CA类的结构体定义也是CA类对象在内存中的布局。
struct CA
{
   struct swift_class *isa;
   long  reserve;   //这里的值目前总是2
   int a;
   int b;
};

//类CA的方法函数的实现。
int getA(){
    struct CA *obj = x20;   //取x20寄存器的值，也就是对象的值。
    return obj->a;
}
void setA(int a){
 struct CA *obj = x20;   //取x20寄存器的值，也就是对象的值。
 obj->a = a;
}
int getB(){
    struct CA *obj = x20;   //取x20寄存器的值，也就是对象的值。
    return obj->b;
}
void setB(int b){
 struct CA *obj = x20;   //取x20寄存器的值，也就是对象的值。
 obj->b = b;
}

struct swift_class classCA;
classCA.vtable[4] = {&getA,&setA,&getB, &setB};


//...........................................源代码中程序运行的部分

void main(){
   CA *obj =  CA.__allocating_init(classCA);
   obj->isa = &classCA;
   obj->reserve = 2;
   obj->a = 10;
   obj->b = 20;
   asm("mov x20, obj");
   obj->isa->vtable[3](obj->isa->vtable[0]());  // obj.b = obj.a的实现
}

从上面的代码可以看出，Swift类会为每个定义的成员变量都生成一对get/set方法并保存到虚函数表中。所有对对象成员变量的方法的代码都会转化为通过虚函数表来执行get/set相对应的方法。 下面是Swift类中成员变量的实现和内存结构布局图：

结构体中的方法

在Swift结构体中也可以定义方法，因为结构体的内存结构中并没有地方保存结构体的信息(不存在isa数据成员)，因此结构体中的方法是不支持多态的，同时结构体中的所有方法调用都是在编译时硬编码来实现的。这也解释了为什么结构体不支持派生，以及结构体中的方法不支持override关键字的原因。

类的方法以及全局函数

Swift类中定义的类方法和全局函数一样，因为不存在对象作为参数，因此在调用此类函数时也不会存在将对象保存到x20寄存器中这么一说。同时源代码中定义的函数的参数在编译时也不会插入附加的参数。Swift语言会对所有符号进行重命名修饰，类方法和全局函数也不例外。这也就使得全局函数和类方法也支持名称相同但是参数不同的函数定义。简单的说就是类方法和全局函数就像C语言的普通函数一样被实现和定义，所有对类方法和全局函数的调用都是在编译链接时刻硬编码为函数地址调用来处理的。

OC调用Swift类中的方法

如果应用程序是通过OC和Swift两种语言混合开发完成的。那就一定会存在着OC语言代码调用Swift语言代码以及相反调用的情况。对于Swift语言调用OC的代码的处理方法是系统会为工程建立一个桥声明头文件:项目工程名-Bridging-Header.h，所有Swift需要调用的OC语言方法都需要在这个头文件中声明。而对于OC语言调用Swift语言来说，则有一定的限制。因为Swift和OC的函数调用ABI规则不相同，OC语言只能创建Swift中从NSObject类中派生类对象，而方法调用则只能调用原NSObject类以及派生类中的所有方法以及被声明为@objc关键字的Swift对象方法。如果需要在OC语言中调用Swift语言定义的类和方法，则需要在OC语言文件中添加:#import "项目名-Swift.h"。当某个Swift方法被声明为@objc关键字时，在编译时刻会生成两个函数，一个是本体函数供Swift内部调用，另外一个是跳板函数(trampoline)是供OC语言进行调用的。这个跳板函数信息会记录在OC类的运行时类结构中，跳板函数的实现会对参数的传递规则进行转换：把x0寄存器的值赋值给x20寄存器，然后把其他参数依次转化为Swift的函数参数传递规则要求，最后再执行本地函数调用。整个过程的实现如下：

////////Swift源代码

//Swift类定义
class MyUIView:UIView {
  @objc    
  open func foo(){}
}

func main() {
  let obj = MyUIView()
  obj.foo()
}

//////// OC源代码
#import "工程-Swift.h"

void main() {
  MyUIView *obj = [MyUIView new];
  [obj foo];
}

////////C伪代码

//...........................................运行时定义部分

//OC类的方法结构体
struct method_t {
    SEL name;
    IMP imp;
};

//Swift类描述
struct swift_class {
    ...   //其他的属性，因为这里不关心就不列出了。
    struct method_t  methods[1];
    ...   //其他的属性，因为这里不关心就不列出了。
    //虚函数表刚好在结构体的第0x50的偏移位置。
    IMP vtable[1];
};

//...........................................源代码中类的定义和方法的定义和实现部分

//类定义
struct MyUIView {
      struct swift_class *isa;
}

//类的方法函数的实现

//本体函数foo的实现
void foo(){}
//跳板函数的实现
void trampoline_foo(id self, SEL _cmd){
     asm("mov x20, x0");
     self->isa->vtable[0](); //这里调用本体函数foo
}

//类的描述信息构建，这些都是在编译代码时就明确了并且保存在数据段中。
struct swift_class classMyUIView;
classMyUIView.methods[0] = {"foo", &trampoline_foo};
classMyUIView.vtable[0] = {&foo};


//...........................................源代码中程序运行的部分

//Swift代码部分
void main()
{
  MyUIView *obj = MyUIView.__allocating_init(classMyUIView);
  obj->isa = &classMyUIView;
   asm("mov x20, obj");
   //Swift方法foo的调用采用间接调用实现。
   obj->isa->vtable[0]();
}

//OC代码部分
void main()
{
  MyUIView *obj = objc_msgSend(objc_msgSend(classMyUIView, "alloc"), "init");
  obj->isa = &classMyUIView;
  //OC语言对foo的调用还是用objc_msgSend来执行调用。
  //因为objc_msgSend最终会找到methods中的方法结构并调用trampoline_foo 
  //而trampoline_foo内部则直接调用foo来实现真实的调用。
  objc_msgSend(obj, @selector(foo));
}

下面的图形展示了Swift中带@objc关键字的方法实现，以及OC语言调用Swift对象方法的实现：

Swift类方法的运行时替换实现的可行性

从上面的介绍中我们已经了解到了Swift类的常规方法定义和调用实现的机制，同样了解到Swift对象实例的开头部分也有和OC类似的isa数据，用来指向类的信息结构。一个令人高兴的事情就是Swift类的结构定义部分是存放在可读写的数据段中，这似乎给了我们一个提示是说可以在运行时通过修改一个Swift类的虚函数表的内容来达到运行时对象行为改变的能力。要实现这种机制有三个难点需要解决：

1、一个是Swift对内存和指针的操作进行了极大的封装，同时Swift中也不再支持简单直接的对内存进行操作的机制了。这样就使得我们很难像OC那样直接修改类结构的内存信息来进行运行时的更新处理，因为Swift不再公开运行时的相关接口了。虽然可以将方法函数名称赋值给某个变量，但是这个变量的值并非是类方法函数的真实地址，而是一个包装函数的地址。

2、第二个就是Swift中的类方法调用和参数传递的ABI规则和其他语言不一致。在OC类的对象方法中，对象是作为方法函数的第一个参数传递的。在机器指令层面以arm64体系结构为例，对象是保存在x0寄存器作为参数进行传递。而在Swift的对象方法中这个规则变为对象不再作为第一个参数传递了，而是统一改为通过寄存器x20来进行传递。需要明确的是这个规则不会针对普通的Swift函数。因此当我们想将一个普通的函数来替换类定义的对象方法实现时就几乎变得不太可能了，除非借助一些OC到Swift的桥的技术和跳板技术来实现这个功能也许能够成功。

当然我们也可以通过为类定义一个extension方法，然后将这个extension方法函数的指针来替换掉虚函数表中类的某个原始方法的函数指针地址，这样能够解决对象作为参数传递的寄存器的问题。但是这里仍然需要面临两个问题：一是如何获取得到extension中的方法函数的地址，二是在替换完成后如何能在合适的时机调用原始的方法。

3、第三是Swift语言将不再支持内嵌汇编代码了，所以我们很难在Swift中通过汇编来写一些跳板程序了。

因为Swift具有比较强的静态语言的特性，外加上函数调用的规则特点使得我们很难在运行时进行对象方法行为的改变。还有一个非常大的因素是当编译链接优化开关打开时，上述的对象方法调用规则还将进一步被打破，这样就导致我们在运行时进行对象方法行为的替换变得几乎不可能或者不可行。

编译链接优化开启后的Swift方法定义和调用

一个不幸的事实是，当我们开启了编译链接的优化选项后，Swift的对象方法的调用机制做了非常大的改进。最主要的就是进一步弱化了通过虚函数表来进行间接方法调用的实现，而是大量的改用了一些内联的方式来处理方法函数调用。同时对多态的支持也采用了一些别的策略。具体用了如下一些策略：

1、大量的将函数实现换成了内联函数模式，也就是对于大部分类中定义的源代码比较少的方法函数都统一换成内联。这样对象方法的调用将不再通过虚函数表来间接调用，而是简单粗暴的将函数的调用改为直接将内联函数生成的机器码进行拷贝处理。这样的一个好处就是由于没有函数调用的跳转指令，而是直接执行方法中定义的指令，从而极大的加速了程序的运行速度。另外一个就是使得整个程序更加安全，因为此时函数的实现逻辑已经散布到各处了，除非恶意修改者改动了所有的指令，否则都只会影响局部程序的运行。内联的一个的缺点就是使得整个程序的体积会增大很多。比如下面的类代码在优化模式下的Swift语言源代码和C语言伪代码实现：

////////Swift源代码

//类定义
class CA {
  open func foo(_ a:Int, _ b:Int) ->Int {
    return a + b
  }

func main() {
  let obj = CA()
  let a = obj.foo(10,20)
  let b = obj.foo(a, 40)
}

////////C伪代码


//...........................................运行时定义部分


//Swift类描述。
struct swift_class {
    ...   //其他的属性，因为这里不关心就不列出了
    //这里也没有虚表的信息。
};

//...........................................源代码中类的定义和方法的定义和实现部分


//类定义
struct CA {
      struct swift_class *isa;
};

//这里没有方法实现，因为短方法被内联了。

struct swift_class classCA;


//...........................................源代码中程序运行的部分


void main() {
  CA *obj =  CA.__allocating_init(classCA);
  obj->isa = &classCA;
  int a = 10 + 20;  //代码被内联优化
  int b = a + 40;   //代码被内联优化
}

2、就是对多态的支持，也可能不是通过虚函数来处理了，而是通过类型判断采用条件语句来实现方法的调用。就比如下面Swift语言源代码和C语言伪代码：

////////Swift源代码

//基类
class CA{
   @inline(never)
   open func foo(){}
}

//派生类
class CB:CA{
@inline(never)
override open func foo(){}
}

//全局函数接收对象作为参数
@inline(never)
func testfunc(_ obj:CA){
    obj.foo()
}


func main() {
  //对象的创建以及方法调用
  let objA = CA()
  let objB = CB()
  testfunc(objA)
  testfunc(objB)
}

////////C伪代码

//...........................................运行时定义部分


//Swift类描述
struct swift_class {
    ...   //其他的属性，因为这里不关心就不列出了
    //这里也没有虚表的信息。
};


//...........................................源代码中类的定义和方法的定义和实现部分

//类定义
struct CA {
      struct swift_class *isa;
};

struct CB {
   struct swift_class *isa;
};

//Swift类的方法的实现
//基类CA的foo方法实现
void fooForA(){}
//派生类CB的foo方法实现
void fooForB(){}
//全局函数方法的实现
void testfunc(CA *obj)
{
    //这里并不是通过虚表来进行间接调用而实现多态，而是直接硬编码通过类型判断来进行函数调用从而实现多态的能力。
    asm("mov x20, obj");
    if (obj->isa == &classCA)
         fooForA();
    else if (obj->isa == &classCB)
        fooForB();
}

//类的描述信息构建，这些都是在编译代码时就明确了并且保存在数据段中。
struct swift_class classCA;
struct swift_class classCB;

//...........................................源代码中程序运行的部分

void main() {
  //对象实例创建以及方法调用的代码。
  CA *objA = CA.__allocating_init(classCA);
  objA->isa = &classCA;
  CB *objB = CB.__allocating_init(classCB);
  objB->isa = &classCB;
  testfunc(objA);
  testfunc(objB);
}

也许你会觉得这不是一个最优的解决方案，而且如果当再次出现一个派生类时，还会继续增加条件分支的判断。 这是一个多么低级的优化啊！但是为什么还是要这么做呢？个人觉得还是性能和包大小的问题。对于性能来说如果我们通过间接调用的形式可能需要增加更多的指令以及进行间接的寻址处理和指令跳转，而如果采用简单的类型判断则只需要更少的指令就可以解决多态调用的问题了，这样性能就会得到提升。至于第二个包大小的问题这里有必要重点说一下。

编译链接优化的一个非常重要的能力就是减少程序的体积，其中一个点即是链接时如果发现某个一个函数没有被任何地方调用或者引用，链接器就会把这个函数的实现代码整体删除掉。这也是符合逻辑以及正确的优化方式。回过头来Swift函数调用的虚函数表方式，因为根据虚函数表的定义需要把一个类的所有方法函数地址都存放到类的虚函数表中，而不管类中的函数是否有被调用或者使用。而通过虚函数表的形式间接调用时是无法在编译链接时明确哪个函数是否会被调用的，所以当采用虚函数表时就不得不把类中的所有方法的实现都链接到可执行程序中去，这样就有可能无形中增加了程序的体积。而前面提供的当编译链接优化打开后，系统尽可能的对对象的方法调用改为内联，同时对多态的支持改为根据类型来进行条件判断处理，这样就可以减少对虚函数表的使用，一者加快了程序运行速度，二者删除了程序中那些永远不会调用的代码从而减少程序包的体积。但是这种减少包体积的行为又因为内联的引入也许反而增加了程序包的体积。而这二者之间的平衡对于链接优化器是如何决策的我们就不得而知了。

综上所述，在编译器优化模式下虚函数调用的间接模式改变为直接模式了，所以我们几乎很难在运行时通过修改虚表来实现方法调用的替换。而且Swift本身又不再支持运行时从方法名到方法实现地址的映射处理，所有的机制都是在编译时静态决定了。正是因为Swift语言的特性，使得原本在OC中可以做的很多事情在Swift中都难以实现，尤其是一些公司的无痕埋点日志系统的建设，APM的建设，以及各种监控系统的建设，以及模拟系统的建设都将失效，或者说需要寻找另外一些途径去做这些事情。对于这些来说，您准备好了吗？

链接：https://www.jianshu.com/p/158574ab8809

前言

你是否因为多任务的依赖而头疼？你是否被一个个嵌套的block回调弄得晕头转向？
快来投入Promises的怀抱吧。

正文

回调任务是很正常的现象，比如说购买一个商品，需要下单，然后等后台返回。
单一任务，通常只需要一个block，非常清晰；
以上面的下单为例，传给网络层一个block，购买完成之后回调即可。

但是出现多个任务的时候，逻辑就开始有分支，同样以购买商品为例，在下单完成后，需要和SDK发起支付，然后根据支付结果再进行一些提示：
任务1是下单，执行完回调error指针（或者状态码）表示完成状态，同时待会下单信息，此时产生一个分支，成功继续下一步，失败执行错误block；
然后是执行任务2购买，执行异步的支付，根据支付结果又会产生一个分支。

当连续的任务超过2个之后，分支会导致代码逻辑非常混乱。

简单画一个流程图来分析，上述的逻辑变得复杂的原因是因为每一级的block需要处理下一级block的失败情况，导致逻辑分支的增多。

其实所有的失败处理都是类似的：打日志、提示用户，可以放在一起统一处理。
然后把任务一、任务二等串行执行，流程就非常清晰。

Promises就是用来辅助实现这样设计的库。
实现的代码效果如下：

- (void)workflow {
    [[[[self order:@"order_id"] then:^id _Nullable(NSString * _Nullable value) {
        return [self pay:value];
    }] then:^id _Nullable(id  _Nullable value) {
        return [self check:value];
    }] catch:^(NSError * _Nonnull error) {
        NSLog(@"error: %@", error);
    }];
}

Promises的使用

Promises库的引入非常简单，可以使用CocoaPod，Podfile如下：

pod 'PromisesObjC'

也可以到GitHub手动下载。

按照Promise设计模式的规范，每一个Promise应该有三种状态：pending(等待)、fulfilled(完成)、rejected(失败)；
对应到Promises分别是：

[FBLPromise pendingPromise]; // pending等待
[FBLPromise resolvedWith:@"anyString"]; // fulfilled完成
[FBLPromise resolvedWith:[NSError new]]; // rejected失败

实际使用中，我们更多使用的Promises库已经提供好的便捷函数：

启动一个异步任务 ：

[FBLPromise onQueue:dispatch_get_main_queue()
                  async:^(FBLPromiseFulfillBlock fulfill,
                          FBLPromiseRejectBlock reject) {
                      BOOL success = arc4random() % 2;
                      if (success) {
                          fulfill(@"success");
                      }
                      else {
                          reject([NSError errorWithDomain:@"learn_promises_error" code:-1 userInfo:nil]);
                      }
                  }];

或者简单使用do方法：

[FBLPromise do:^id _Nullable{
        BOOL success = random() % 2;
        if (success) {
            return @"success";
        }
        else {
            return [NSError errorWithDomain:@"learn_promises_error" code:-1 userInfo:nil];
        }
    }];

不管是async方法还是do方法，他们的返回值都是创建一个Promise对象，可以在Promise对象后面挂一个then方法，表示这个Promise执行完毕之后，要继续执行的任务：

[[[FBLPromise do:^id _Nullable{
        BOOL success = arc4random() % 2;
        return success ? @"do_success" : [NSError errorWithDomain:@"learn_promises_do_error" code:-1 userInfo:nil];
    }] then:^id _Nullable(id  _Nullable value) {
        BOOL success = arc4random() % 2;
        return success ? @"then_success" : [NSError errorWithDomain:@"learn_promises_then_error" code:-1 userInfo:nil];
    }] catch:^(NSError * _Nonnull error) {
        NSLog(@"error: %@", error);
    }];

上面的catch方法表示统一的error处理。
promise在完成任务之后，如果满足下面的条件会调用then的方法：
1、直接调用fulfill；
2、在do方法中返回一个值（不能为error）；
3、在then方法中返回一个值；

调用reject方法或者返回一个NSError对象，都会转到catch方法处理。

用上面的do、then、catch方法组合，就完成多个异步任务的依赖执行：

- (void)workflow {
    [[[[self order:@"order_id"] then:^id _Nullable(NSString * _Nullable value) {
        return [self pay:value];
    }] then:^id _Nullable(id  _Nullable value) {
        return [self check:value];
    }] catch:^(NSError * _Nonnull error) {
        NSLog(@"error: %@", error);
    }];
}

- (FBLPromise<NSString *> *)order:(NSString *)orderParam {
    return [FBLPromise do:^id _Nullable{
        return @"order_success";
    }];
}

- (FBLPromise<NSString *> *)pay:(NSString *)payParam {
    return  [FBLPromise do:^id _Nullable{
        BOOL success = arc4random() % 2;
        return success ? @"pay_success" : [NSError errorWithDomain:@"pay_error" code:-1 userInfo:nil];
    }];
}

- (FBLPromise<NSString *> *)check:(NSString *)checkParam {
    return  [FBLPromise do:^id _Nullable{
        return @"check success";
    }];
}

Promises还提供了很多附加特性，以All和Any为例：
All是所有Promise都fulfill才算完成；
Any是任何一个Promise完成都会执行fulfill；

- (void)testAllAndAny {
    NSMutableArray *arr = [NSMutableArray new];
    [arr addObject:[self work1]];
    [arr addObject:[self work2]];
    
    [[[FBLPromise all:arr] then:^id _Nullable(NSArray * _Nullable value) {
        NSLog(@"then, value:%@", value);
        return value;
    }] catch:^(NSError * _Nonnull error) {
        NSLog(@"all error:%@", error);
    }];
    
    [[[FBLPromise any:arr] then:^id _Nullable(NSArray * _Nullable value) {
        NSLog(@"then, value:%@", value);
        return value;
    }] catch:^(NSError * _Nonnull error) {
        NSLog(@"any error:%@", error);
    }];
}

- (FBLPromise<NSString *> *)work1 {
    return [FBLPromise do:^id _Nullable{
        BOOL success = arc4random() % 2;
        return success ? @"work1 success" : [NSError errorWithDomain:@"work1_error" code:-1 userInfo:nil];
    }];
}

- (FBLPromise<NSNumber *> *)work2 {
    return  [FBLPromise do:^id _Nullable{
        BOOL success = arc4random() % 2;
        return success ? @"work2 success" : [NSError errorWithDomain:@"work2_error" code:-1 userInfo:nil];
    }];
}

Promises原理解析

Promises库的设计很简单，基于Promise设计模式和iOS的GCD来实现。
整个库由Promise.m/.h和他的Catagory组成。Catagory都是附加特性，基于Promise.m/.h提供的方法做扩展，所以这里重点解析下Promise.m/h。
Promise类public头文件只有寥寥数个方法：

// 静态方法
[FBLPromise pendingPromise]; // pending等待
[FBLPromise resolvedWith:@"anyString"]; // fulfilled完成
[FBLPromise resolvedWith:[NSError new]]; // rejected失败
// 实例方法
- (void)fulfill:(nullable Value)value; // 完成一个promise
- (void)reject:(NSError *)error;// rejected一个promise

重点在于private.h提供的两个方法：

/**
 对一个promise添加fulfill和reject的回调
 */
- (void)observeOnQueue:(dispatch_queue_t)queue
               fulfill:(FBLPromiseOnFulfillBlock)onFulfill
                reject:(FBLPromiseOnRejectBlock)onReject NS_SWIFT_UNAVAILABLE("");

/**
创建一个promise，并设置fulfill、reject方法为传进来的block
 */
- (FBLPromise *)chainOnQueue:(dispatch_queue_t)queue
              chainedFulfill:(FBLPromiseChainedFulfillBlock)chainedFulfill
               chainedReject:(FBLPromiseChainedRejectBlock)chainedReject NS_SWIFT_UNAVAILABLE("");

observeOnQueue方法是promise的实例方法，根据promise当前的状态，如果是fulfilled或者rejected状态则会dispatch_group_async到下一次执行对应的onFulfill和onReject回调；如果是pending状态则会创建_observers数组，往_observers数组中添加一个block回调，当promise执行完毕的时候，根据state选择onFulfill或者onReject回调。

chainOnQueue方法同样是promise的实例方法，返回的是一个FBLPromise的对象（状态是pending）。
方法首先创建的是promise对象，接着创建了resolver的回调，然后调用observeOnQueue方法。
当self（也是一个promise）执行完毕后，会根据fulfill、reject回调类型接着执行chainedFulfill、chainedReject；
最后将结果抛给resolver执行，resolver会根据返回值value进行判断，如果仍是promise则递归执行，否则直接调用fulfill方法。
fulfill方法则会判断value是否为NSError，如果是NSError则转为reject，否则将状态改为Fulfilled，并且通知observer数组。

- (FBLPromise *)chainOnQueue:(dispatch_queue_t)queue
              chainedFulfill:(FBLPromiseChainedFulfillBlock)chainedFulfill
               chainedReject:(FBLPromiseChainedRejectBlock)chainedReject {
  NSParameterAssert(queue);

  FBLPromise *promise = [[FBLPromise alloc] initPending];
  __auto_type resolver = ^(id __nullable value) {
    if ([value isKindOfClass:[FBLPromise class]]) {
      [(FBLPromise *)value observeOnQueue:queue
          fulfill:^(id __nullable value) {
            [promise fulfill:value];
          }
          reject:^(NSError *error) {
            [promise reject:error];
          }];
    } else {
      [promise fulfill:value];
    }
  };
  [self observeOnQueue:queue
      fulfill:^(id __nullable value) {
        value = chainedFulfill ? chainedFulfill(value) : value;
        resolver(value);
      }
      reject:^(NSError *error) {
        id value = chainedReject ? chainedReject(error) : error;
        resolver(value);
      }];
  return promise;
}

Promises中的dispatch_group_enter() 和 dispatch_group_leave() 是成对使用，但是和平时使用GCD不同，这里并没有用到dispath_group_notify方法。
在刚开始看Promises源码时，产生过一个疑问，为什么所有Promises的操作要放在同一个group内？

+ (dispatch_group_t)dispatchGroup {
  static dispatch_group_t gDispatchGroup;
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{
    gDispatchGroup = dispatch_group_create();
  });
  return gDispatchGroup;
}

直到发现FBLWaitForPromisesWithTimeout方法，里面有一个dispatch_group_wait方法（等待group中所有block执行完毕，或者在指定时间结束后回调）。
dispatch_group_wait方法与dispath_group_notify方法类似，只是多了一个超时时间，如果调用dispatch_group_wait(DISPATCH_TIME_FOREVER)则和dispath_group_notify方法一样。

总结

附加的特性有很多，类似Retry、Delay等，但实际使用中Promise用do、then、catch、async等少数几个已经可以满足需求。
能够实现Promise设计模式的库比较多，Promises是性能和接口调用清晰度都比较不错的。
使用设计模式可以简化逻辑代码，同时也使得代码的健壮性更强。

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

大多数现代应用程序的共同点是，它们需要对各种形式的数据进行编码或解码。无论是通过网络下载的JSON数据，还是本地存储的模型的某种形式的序列化表示 - 能够可靠地编码和解码不同的数据对于或多或少的任何Swift代码库都是必不可少的。

这是Swift的Codable API在作为Swift 4.0的一部分引入时如此重要的新功能的一个重要原因 - 从那时起它已经发展成为几种不同类型的编码和解码的标准，强大的机制 - 在Apple的平台，以及服务器端Swift。

使Codable如此出色的原因在于它与Swift工具链紧密集成，使编译器能够自动合成编码和解码各种值所需的大量代码。但是，有时我们确实需要自定义序列化时我们的值的表示方式 - 所以本周，我们来看看我们可以通过几种不同的方式调整我们的Codable实现来做到这一点。

改变钥匙

让我们从一种基本方法开始，我们可以自定义类型的编码和解码方式 - 通过修改用作序列化表示的一部分的键。假设我们正在开发一个用于阅读文章的应用程序，我们的核心数据模型之一如下所示：

struct Article: Codable {
    var url: URL
    var title: String
    var body: String
}

我们的模型当前使用完全自动合成的Codable实现，这意味着它的所有序列化键都将匹配其属性的名称。但是，我们将解码Article值的数据（例如从服务器下载的JSON）可能使用稍微不同的命名约定，导致默认解码失败。

谢天谢地，这很容易修复。我们需要做的就是自定义Codable在解码（或编码）我们Article类型的实例时将使用的键是在其中定义CodingKeys枚举 - 并将自定义原始值分配给匹配我们希望自定义的键的案例 - 像这样：

extension Article {
    enum CodingKeys: String, CodingKey {
        case url = "source_link"
        case title = "content_name"
        case body
    }
}

执行上述操作后，我们可以继续利用编译器生成的默认实现进行实际的编码工作，同时仍然允许我们更改将用于序列化的键的名称。

虽然上述技术非常适合我们想要使用完全自定义的键名称，但如果我们只想让Codable使用snake_case我们的属性名称版本（例如backgroundColor转入background_color） - 那么我们可以简单地改变我们的JSON解码器keyDecodingStrategy：

var decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase

上述两个API的优点在于它们使我们能够解决Swift模型与用于表示它们的数据之间的不匹配问题，而无需我们修改属性的名称。

忽略键

虽然能够自定义编码密钥的名称非常有用，但有时我们可能希望完全忽略某些密钥。例如，我们现在说我们正在制作一个笔记记录应用程序 - 并且我们允许用户将各种笔记组合在一起形成一个NoteCollection，其中可以包括本地草稿：

struct NoteCollection: Codable {
    var name: String
    var notes: [Note]
    var localDrafts = [Note]()
}

然而，尽管成为localDrafts我们NoteCollection模型的一部分真的很方便- 但是我们说在序列化或反序列化这样的集合时我们不希望包含这些草稿。这样做的原因可能是每次启动应用程序时给用户一个干净的名单，或者因为我们的服务器不支持草稿。

幸运的是，这也可以轻松完成，而无需更改实际的Codable实现NoteCollection。如果我们CodingKeys像之前一样定义枚举，并且只是省略localDrafts- 那么在编码或解码NoteCollection值时不会考虑该属性：

extension NoteCollection {
    enum CodingKeys: CodingKey {
        case name
        case notes
    }
}

为了使上述工作，我们省略的属性必须具有默认值 - localDrafts在这种情况下已经具有。

创建匹配结构

到目前为止，我们只调整了一个类型的编码键 - 虽然我们通常可以做到这一点，但有时我们需要在Codable自定义方面更进一步。

假设我们正在构建一个包含货币转换功能的应用程序，并且我们将给定货币的当前汇率作为JSON数据下载，如下所示：

{
    "currency": "PLN",
    "rates": {
        "USD": 3.76,
        "EUR": 4.24,
        "SEK": 0.41
    }
}

在我们的Swift代码中，我们希望将这些JSON响应转换为CurrencyConversion实例 - 每个实例包含一个ExchangeRate条目数组- 每种货币对应一个：

struct CurrencyConversion {
    var currency: Currency
    var exchangeRates: [ExchangeRate]
}

struct ExchangeRate {
    let currency: Currency
    let rate: Double
}

但是，如果我们只是继续使上述两个模型都符合Codable，我们再次得出我们的Swift代码和我们想要解码的JSON数据之间的不匹配。但这一次，它不仅仅是关键名称的问题 - 结构上存在根本区别。

当然，我们可以修改我们的Swift模型的结构以完全匹配我们的JSON数据的结构 - 但这并不总是实用的。虽然拥有正确的序列化代码很重要，但拥有适合我们实际代码库的模型结构同样重要。

相反，让我们创建一个新的专用类型 - 它将充当我们的JSON数据中使用的格式与Swift代码结构之间的桥梁。在该类型中，我们将能够封装将汇率的JSON字典转换为ExchangeRate模型数组所需的所有逻辑- 如下所示：

private extension ExchangeRate {
    struct List: Decodable {
        let values: [ExchangeRate]

        init(from decoder: Decoder) throws {
            let container = try decoder.singleValueContainer()
            let dictionary = try container.decode([String : Double].self)

            values = dictionary.map { key, value in
                ExchangeRate(currency: Currency(key), rate: value)
            }
        }
    }
}

使用上面的类型，我们现在可以定义一个私有属性，该属性与用于其数据的JSON密钥匹配 - 并且我们的exchangeRates属性只是充当该私有属性的面向公众的代理：

struct CurrencyConversion: Decodable {
    var currency: Currency
    var exchangeRates: [ExchangeRate] {
        return rates.values
    }

    private var rates: ExchangeRate.List
}

上述工作的原因是因为在编码或解码值时从不考虑计算属性。

当我们想要使Swift代码与使用非常不同结构的JSON API兼容时，上述技术可以成为一个很好的工具 - 再次无需Codable从头开始实现。

转变价值观

在解码时，尤其是在使用我们无法控制的外部JSON API时，一个非常常见的问题是，类型的编码方式与Swift的严格类型系统不兼容。例如，我们要解码的JSON数据可能使用字符串来表示整数或其他类型的数字。

让我们看看一种可以让我们处理这些值的方法，再次以一种自包含的方式，不需要我们编写完全自定义的Codable实现。

我们在这里要做的就是将字符串值转换为另一种类型 - 让我们Int以此为例。我们首先定义一个协议，让我们将任何类型标记为StringRepresentable- 意味着它可以从字符串表示转换为字符串表示：

protocol StringRepresentable: CustomStringConvertible {
    init?(_ string: String)
}

extension Int: StringRepresentable {}

我们将上述协议基于CustomStringConvertible标准库，因为它已经包含了将值描述为字符串的属性要求。有关将协议定义为其他协议的特殊方法的更多信息，请查看“Swift中的专业协议”。

接下来，让我们创建另一个专用类型 - 这次是任何可以由字符串支持的值- 并且它包含解码和编码字符串值所需的所有代码：

struct StringBacked: Codable {
    var value: Value

    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let string = try container.decode(String.self)

        guard let value = Value(string) else {
            throw DecodingError.dataCorruptedError(
                in: container,
                debugDescription: """
                Failed to convert an instance of \(Value.self) from "\(string)"
                """
            )
        }

        self.value = value
    }

    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        try container.encode(value.description)
    }
}

就像我们之前为我们的JSON兼容的底层存储创建私有属性一样，我们现在可以对编码时由字符串后端的任何属性执行相同的操作 - 同时仍然将该数据暴露给我们的其余Swift代码类型。这是一个为Video类型的numberOfLikes属性做这样的例子：

struct Video: Codable {
    var title: String
    var description: String
    var url: URL
    var thumbnailImageURL: URL

    var numberOfLikes: Int {
        get { return likes.value }
        set { likes.value = newValue }
    }

    private var likes: StringBacked
}

在必须为属性手动定义setter和getter的复杂性以及必须回退到完全自定义Codable实现的复杂性之间肯定存在权衡- 但对于类似上述Video结构的类型，其仅具有需要的一个属性使用私有支持属性进行自定义可能是一个很好的选择。

结论

虽然编译器能够自动合成所有Codable不需要任何形式定制的一致性，但真正太棒了- 我们能够在需要时自定义事物同样非常棒。

更妙的是，这样做往往并不真正需要我们赞成手工执行的彻底抛弃自动生成的代码-这是很多次可能只是稍微调整一个类型的编码或解码的方式，同时还让编译器做大部分繁重的工作。

链接：https://www.jianshu.com/p/62162d01d1df

前言

Pod库是很重要的组成部分，大部分第三方库都是通过CocoaPod的方式引入和管理，同时项目中的部分功能也可以用Pod库来做模块化。
本文是对CocoaPod的一些探究。
XS项目中的Pod库是很重要的组成部分，目前阅读器模块正在进行SDK化，需要用Pod库来管理，同时未来会做一些模块化的功能，同样需要用Pod库来处理。
本文对CocoaPods的一些内容进行探究。

正文

CocoaPods是为iOS工程提供第三方依赖库管理的工具，用CocoaPods可以更方便地管理第三方库：把依赖库统一放在Pods工程中，同时让主工程依赖Pods工程。Pods工程的target是libPods-targetName.a静态库，主工程会依赖这个.a静态库。 （下面会详细剖析这个处理过程）

CocoaPods相比手动引入framework或者子工程依赖的方式，有两个便捷之处：

所有Pod库集中管理，版本更新只需Podfile配置文件；
依赖关系的自动解析；
同时CocoaPods的使用流程很简单：（假设已经安装CocoaPods）
1、在xcodeproj所在目录下，新建Podfile文件；

2、描述依赖信息，以demo为例，有AFNetworking和SDWebImage两个第三方库：

target 'LearnPod' do
        pod 'AFNetworking'
        pod 'SDWebImage'
end

3、打开命令行，执行pod install ；

4、打开生成xcworkspace，就可以继续开发；

一、Podfile的写法

1、普通的写法；
pod 'AFNetworking' 或者 pod 'AFNetworking', '3.2.1'，前者是下载最新版本，后者是下载指定版本。

2、指向本地的代码分支；

pod 'AFNetworking', :path => '/Users/loyinglin/Documents/Learn/AFNetworking'

指向的本地目录要带有podspec文件。

3、指定远端的代码分支；

pod 'AFNetworking', :git => 'https://github.com/AFNetworking/AFNetworking.git', :branch => 'master'

指向的repo仓库要带有podspec文件。

4、针对特定的configurations用不同的依赖库

`pod 'AFNetworking', :configurations => ['Release']`

如上，只有Release的configurations生效；（同理，可以设置Debug）

5、一些其他的feature

优化pod install速度，可以进行依赖打平：将pod库的依赖库明确的写在Podfile，主端已经提供对应的工具。

`require "bd_pod_extentions"`

`bytedanceAnalyzeSpeed(true)`

`bd_use_app('toutiao','thirdParty','public')`

post install的脚本，修改安装后的Pod库工程中的target设置；同理，可以修改其他属性的设置。

post_install do |installer_representation|
    installer_representation.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'`
        end
   end
end

类似的还有pre_install的脚本；（但是install之前可能都没有pods_project，所以用处也比较少；具体的参数意义可自查，以pods_project为例）

puts只有在添加--verbose参数可以看到，Pod::UI.puts则是全文可见。

pre_install do |installer|
    puts "pre install hook"
    Pod::UI.puts "pre install hook puts"
end

Podfile还可以设置一些警告提示的去除，第一行是去掉pod install时候的警告信息，第二行是去掉build时候的警告信息。

# 去掉pod install时候的警告信息
install! 'cocoapods', :warn_for_multiple_pod_sources => false
inhibit_all_warnings

二、Pods目录

Pods目录是pod install之后CocoaPod生成的目录。

目录的组成部分：

1、Pods.xcodeproj，Pods库的工程；每个Pod库会对应其中某个target，每个target都会打包出来一个.a文件；
2、依赖库的文件目录；以SDWebImage为例，会有个SDWebImage目录存放文件；
3、manifest.lock，Pods目录中的Pod库版本信息；每次pod install的时候会检查manifest.lock和Podfile.lock的版本是否一致，不一致的则会更新；
4、Target Support Files、Headers、Local Podspecs目录等；Target Support Files里面是一些target的工程设置xcconifg以及脚本等，Headers里面有Public和Private的头文件目录，Local Podspecs是存放从本地Pod库install时的podspec；

三、CocoaPods的其他重要部分

1.Podfile.lock文件

pod install会解析依赖并生成Podfile.lock文件；如果Podfile.lock存在时执行pod install，则不会修改已经install的pod库。（注意，pod update则会忽视Podfile.lock进行依赖解析，最后重新install所有的Pod库，生成新的Podfile.lock）
在多人开发的项目中，Pods目录由于体积较大，往往不会放在Git仓库中，Podfile.lock文件则建议添加到Git仓库。当其他人修改Podfile时，pod install生成新的Podfile.lock文件也会同步到Git。这样能保证拉下来的版本库是其他人一致的。

实际开发中，也会通过依赖打平来避免多人协作的Pod版本不一致问题。
pod install的时候，Pods目录下生成一个Manifest.lock文件，内容与.lock文件完全一致；在每次build工程的时候，会检查这两个文件是否一致。

2、Pod库的podspec文件
在每个Pod库的仓库中，都会有一个podspec文件，描述Pod库的版本、依赖等信息。
如下，是一个普通的Pod库的podspec：

3、Pod库依赖解析

CocoaPod的依赖管理相对第三方库手动管理更加便捷。
在手动管理第三方库中，如果库A集成了库F，库B也集成了库F ，就会遇到库F符号冲突的问题，需要将库A/B和库F的代码分开，手动添加库F；后续如果库A/B版本有更新，也需要手动去处理。
而在CocoaPod依赖解析中，可以把每个Pod库都看成一个节点，Pod库的依赖是它的子节点； 依赖解析的过程，就是在一个有向图中找到一个拓扑序列。
一个合法的Podfile描述的应该是一个有向无环图，可以通过拓扑排序的方式，得到一个AOV网。
按照这个拓扑序列中的顶点次序，可以依次install所有的Pod库并且保证其依赖的库已经install。

有时候会陷入循环依赖的怪圈，就是因为在有向图中出现环，则无法通过算法得到一个拓扑排序。

四、Pods工程和主工程的关系

在实际的开发过程，容易知道Pods工程是先编译，编译完再执行主工程的编译；因为主工程的Linked Libraries里面有libPods-LearnPod.a的文件。（LearnPod是target的名字，下面的示例图都是用LearnPod作为target名）

那么Pod库中的target编译顺序是如何决定？
打开workspace，选择Pods工程。从上图分析我们知道，主工程最终需要的是libPods-LearnPod.a这一个静态库文件。
我们通常打包，最终名字都是target的名字；而静态库通常会在前面加上lib的前缀。所以libPods-LearnPod.a这个静态库的target名字应该是Pods-LearnPod。
从下图我们也可以确定，确实是在前面添加了lib的前缀。

看看Pods-LearnPod的Build Phases选项，从target依赖中可以看到其他两个target。

分析至此，我们可以知道这里的编译顺序是AFNetworking、SDWebImage、Pods-LearnPod、LeanPod（主工程target）。
接下来我们分析编译过程。AFNetworking因为没有依赖，所以编译的时候只需要知道自己的.h/.m文件。

对于Pods-LearnPod，其有两个依赖，分别是AFNetworking和SDWebImage；所以在Header Search Paths中需要设置这两个库的Public头文件地址。

编译的结果是3个.a文件（libPods-LearnPod.a、libAFNetworking.a、libSDWebImage.a），只有libPods-LearnPod.a是主工程的编译依赖。那么libPods-LearnPod.a是否为多个.a文件的集合？

从libPods-LearnPod.a的大小，我们可以知道libPods-LearnPod不是多个.a的集合，仅仅是作为主工程的一个依赖，使得Pod库工程能先于主工程编译。
那么，主工程编译的时候如何去找到AFNetworking的头文件和.a文件？
从主工程的Search Paths我们可以看到，Header是有说明具体的位置；
同时Library也有相对应的Paths，在对应的位置放着libAFNetworking.a文件；

这些信息是CocoaPod生成的一份xcconfig，里面的HEADER_SEARCH_PATHS和LIBRARY_SEARCH_PATHS会指明这两个地址。

对于资源文件，CocoaPods 提供了一个名为 Pods-resources.sh 的 bash 脚本，该脚本在每次项目编译的时候都会执行，将第三方库的各种资源文件复制到目标目录中。
CocoaPods 通过一个名为 Pods.xcconfig 的文件来在编译时设置所有的依赖和参数。
在编译之前会检查pod的版本是否发生变化（manifest和.lock文件对比），以及执行一些自定义的脚本。
Pod库的子target在指定armv7和arm64两个架构的时候，会分别编译生成armv7和arm64的.a文件；然后再进行一次合并操作，得到一个.a文件。
编译完成后进行链接，在armv7和arm64都指定时，会分别进行链接，最后合并得到可执行文件。
得到可执行文件后，会进行asset、storyboard等资源文件的处理；还会执行pod的脚本，把pod的资源复制过来。
全部准备就绪，就会生成符号表，包括.a文件里面的符号。
最后进行签名、校验，得到.app文件。

五、常用Pod指令

pod install，最常用的指令；
pod update，更新repo并重新解析依赖；
pod install --repo-update，类似pod update；
pod install --no-repo-update，忽略Pod库更新，直接用本地repo进行install；
pod update --no-repo-update，类似pod install；
pod update AFNetworking，更新指定库；

以上所有指令都可以添加 --verbose ，查看更详细的信息；
xcconfig在新增configuration之后，需要重新pod install，并修改xcconfig。

转自：https://www.jianshu.com/p/07ddbd829efc

我们改进了新数据类型的观察能力。

在上一章中，我们构建了一个名为的struct / class混合类型 Var。今天我们将继续实验。

Var类包含一个结构，我们可以利用关键路径寻找到的结构。如果我们有一个people内部的阵列Var，我们希望采取先Person出数组，那么我们得到另一个Var与 Person。更新它Person会修改原始数组，这样我们就会给出Var引用语义。但是如果我们需要的话，我们仍然可以获得结构的复制行为：我们可以将结构值取出Var并具有本地副本。

我们也深入观察。只要有任何变化，根变量就会知道它。我们仍然有一个有点笨拙的API，因为我们Var使用observe闭包初始化，这意味着我们只能在初始化时在根级别添加一个观察者。我们想用一种addObserver方法改进这个API，并且如果我们想要观察根结构或任何其他属性，请使用它。

添加观察者

我们从初始化程序中删除观察者闭包并设置一个新addObserver方法。因为我们将大量使用观察者闭包，所以我们可以为它创建一个类型别名：

final class Var {
  // ... 
  init(initialValue: A) {
      var value: A = initialValue {
          didSet {

          }
      }
      _get = { value }
      _set = { newValue in value = newValue }
  }

  typealias Observer = (A) -> ()
  func addObserver(_ observer: @escaping Observer) {

  }
  // ... }

以前，我们将一个观察者闭包连接到初始化器中的struct值，但现在我们无法访问那里的观察者。我们需要将所有观察者存储在一个地方，从一个空数组开始，然后连接观察者和结构值：

final class Var {
    // ... 
    init(initialValue: A) {
        var observers: [Observer] = []
        var value: A = initialValue {
            didSet {
                for o in observers {
                    o(value)
                }
            }
        }
        _get = { value }
        _set = { newValue in value = newValue }
    }
    // ... }

现在我们仍然需要一种方法来向数组中添加一个观察者。我们重申我们做与技巧get，并set与转addObserver成一个属性，而不是一个方法：

final class Var {
    let addObserver: (_ observer: @escaping Observer) -> ()

    // ...

    init(initialValue: A) {
        var observers: [Observer] = []
        var value: A = initialValue {
            didSet {
                for o in observers {
                    o(value)
                }
            }
        }
        _get = { value }
        _set = { newValue in value = newValue }
        addObserver = { observer in observers.append(observer) }
    }
    // ... }

在我们可以使用之前addObserver，我们必须将它设置在我们的其他私有初始化程序中。为此，我们将从外部传入一个闭包，以便我们可以在下标实现中定义闭包：

fileprivate init(get: @escaping () -> A, set: @escaping (A) -> (), addObserver: @escaping (@escaping Observer) -> ()) {
    _get = get
    _set = set
    self.addObserver = addObserver
}

在键路径下标中，我们现在必须定义一个addObserver 闭包，它接受一个观察者并用类型的值调用这个观察者 B。我们只有类型的值A，但我们也可以self在这个闭包中观察并使用关键路径来获取B收到的A：

subscript(keyPath: WritableKeyPath) -> Var {
    return Var(get: {
        self.value[keyPath: keyPath]
    }, set: { newValue in
        self.value[keyPath: keyPath] = newValue
    }, addObserver: { observer in
        self.addObserver { newValue in
            observer(newValue[keyPath: keyPath])
        }
    })
}

无论我们嵌套我们Var的深度多少，观察者总是被添加到根Var，因为一个孩子Var通过观察者直到它到达observers根的数组Var。这意味着只要根值发生变化就会调用观察者 - 换句话说：即使属性本身未更改，也可能会调用特定属性的观察者。

我们还在addObserver集合的下标中传递了一个类似的闭包：

extension Var where A: MutableCollection {
    subscript(index: A.Index) -> Var {
        return Var(get: {
            self.value[index]
        }, set: { newValue in
            self.value[index] = newValue
        }, addObserver: { observer in
            self.addObserver { newValue in
                observer(newValue[index])
            }
        })
    }
}

让我们看看这是如何工作的：

let peopleVar: Var<[Person]> = Var(initialValue: people)
peopleVar.addObserver { p in
    print("peoplevar changed: \(p)")
}
let vc = PersonViewController(person: peopleVar[0])
vc.update()

这会将peopleVar更改打印到控制台。但是，我们现在也可以添加一个观察者到Var的PersonViewController，这将打印与新的一个额外的行Person值：

final class PersonViewController {
    let person: Var

    init(person: Var) {
        self.person = person
        self.person.addObserver { newPerson in
            print(newPerson)
        }
    }

    func update() {
        person.value.last = "changed"
    }
}

删除观察者

我们现在可以添加观察者，但我们无法删除它们。如果视图控制器因为其观察者仍然在那里而消失，这就成了问题。

我们可以采取类似于反应性图书馆工作方式的方法。添加观察者时，将返回不透明对象。通过保持对该对象的引用，我们保持观察者活着。当我们丢弃对象时，观察者将被删除。

我们使用一个名为的辅助类，Disposable它接受一个在对象取消时调用的dispose函数：

final class Disposable {
    private let dispose: () -> ()
    init(_ dispose: @escaping () -> ()) {
        self.dispose = dispose
    }
    deinit {
        dispose()
    }
}

我们更新签名addObserver返回Disposable：

final class Var {
    private let _get: () -> A
    private let _set: (A) -> ()
    let addObserver: (_ observer: @escaping Observer) -> Disposable

    // ... }

如果我们想要删除观察者，我们必须改变观察者商店的数据结构。数组不再有效，因为无法比较函数以找到要删除的数组。相反，我们可以使用由唯一整数键入的字典：

final class Var {
    // ...

    init(initialValue: A) {
        var observers: [Int:Observer] = [:]
        // ...
    }
    // ... }

生成这些整数的一种很酷的方法是使用Swift的惰性集合。我们创建一个范围从0到无穷大的迭代器，每次我们需要一个id时，我们可以调用next()这个迭代器。这返回一个可选项，但是我们可以强制解包它，因为我们知道它不能是nil：

final class Var {
    // ...

    init(initialValue: A) {
        var observers: [Int:Observer] = [:]
        // ...
        var freshInt = (0...).makeIterator()
        addObserver = { observer in
            let id = freshInt.next()!
            observers[id] = observer
            // ...
        }
    }
    // ... }

我们现在将观察者存储在字典中。当我们不再使用它们时，剩下要做的就是丢弃观察者。我们返回一个Disposable 带有dispose函数的函数，该函数从字典中删除观察者：

final class Var {
    // ...

    init(initialValue: A) {
        var observers: [Int:Observer] = [:]
        // ...
        var freshInt = (0...).makeIterator()
        addObserver = { observer in
            let id = freshInt.next()!
            observers[id] = observer
            return Disposable { observers[id] = nil }
        }
    }
    // ... }

最后，我们必须addObserver在私有初始化程序中修复签名，它仍然声明返回void而不是Disposable：

fileprivate init(get: @escaping () -> A, set: @escaping (A) -> (), addObserver: @escaping (@escaping Observer) -> Disposable) { /*...*/ }

现在我们的代码再次编译，但是我们确实得到了一个编译器警告我们忽略Disposable了视图控制器中返回的事实。这就解释了为什么我们不再使用更改的Person值获取print语句，因为我们应该保留对观察者的引用以 Disposable使其保持活动状态：

final class PersonViewController {
    let person: Var
    let disposable: Any?

    init(person: Var) {
        self.person = person
        disposable = self.person.addObserver { newPerson in
            print(newPerson)
        }
    }

    func update() {
        person.value.last = "changed"
    }
}

我们现在保留观察者，我们在更新后得到了print语句Person。重申这里发生的事情：视图控制器被释放的那一刻，它的属性被清除，Disposabledeinits，并且这通过将其id设置为来调用将观察者带出字典的代码nil。

注意：如果我们想self在观察者中使用，我们必须使它成为弱引用，以避免创建引用循环。

比较新旧价值观

我们实现的一个重要方面是观察者不仅在观察到的Var变化时触发，而且在整个数据结构发生任何变化时触发。

如果PersonViewController想要确定它已经Person 改变了，它应该能够将新值与旧值进行比较。因此，我们将更改Observer类型别名以提供新值和旧值

typealias Observer = (A, A) -> ()

这意味着使用新版本和旧版本调用观察者 A。为了明确这一点，我们应该将值包装在一个结构中，并在两个字段中描述它们是什么，但我们正在跳过该部分。

我们在里面调用观察者的地方Var，我们现在也必须传递旧值：

init(initialValue: A) {
    // ...
    var value: A = initialValue {
        didSet {
            for o in observers.values {
                o(value, oldValue)
            }
        }
    }
    // ... }

subscript(keyPath: WritableKeyPath) -> Var {
    return Var(get: {
        self.value[keyPath: keyPath]
    }, set: { newValue in
        self.value[keyPath: keyPath] = newValue
    }, addObserver: { observer in
        self.addObserver { newValue, oldValue in
            observer(newValue[keyPath: keyPath], oldValue[keyPath: keyPath])
        }
    })
}

而在MutableCollection标，我们也应该通过旧值观察员：

extension Var where A: MutableCollection {
    subscript(index: A.Index) -> Var {
        return Var(get: {
            self.value[index]
        }, set: { newValue in
            self.value[index] = newValue
        }, addObserver: { observer in
            self.addObserver { newValue, oldValue in
                observer(newValue[index], oldValue[index])
            }
        })
    }
}

观察者PersonViewController可以比较新旧版本，看看它的模型是否确实改变了：

final class PersonViewController {
    // ...
    init(person: Var) {
        self.person = person
        disposable = self.person.addObserver { newPerson, oldPerson in
            guard newPerson != oldPerson else { return }
            print(newPerson)
        }
    }
    // ... }

最后，我们需要修复观察者peopleVar：

peopleVar.addObserver { newPeople, oldPeople in
    print("peoplevar changed: \(newPeople)")
}

通过对视图控制器中的人进行更改，我们测试视图控制器的观察者忽略它：

peopleVar[1].value.first = "Test"

讨论

我们将反应式编程与观察变化的能力和面向对象的编程结合起来。

在这段代码中还有一个令人惊讶的等待。我们将第一个Person从数组移交给视图控制器。如果我们然后删除people数组的第一个元素，视图控制器突然有一个不同的 Person：

peopleVar.value.removeFirst()

keywords

NSDataDetector NSRegularExpression NSTextCheckingResult

在日常开发场景中经常会遇到，在一段文本中检测一些半结构化的信息，比如：日期、地址段、链接、电话号码、交通信息、航班号、奇怪的格式化了的数字、甚至是相对的指示语等等。

如果这些需求在一个项目中出现，在不知道NSDataDetector这个类之前，可能要头皮发麻，之后开始自己编制一些正则，再加上国际化的需求，可能对编制好的正则需要大量的单元测试用例的介入。（估计好多小盆友要被这些东西整自闭了...）

幸运的是，对于 Cocoa 开发者来说，有一个简单的解决方案：NSDataDetector。

关于NSDataDetector

NSDataDetector 是 NSRegularExpression 的子类，而不只是一个 ICU 的模式匹配，它可以检测半结构化的信息：日期，地址，链接，电话号码和交通信息。

它以惊人的准确度完成这一切。NSDataDetector 可以匹配航班号，地址段，奇怪的格式化了的数字，甚至是相对的指示语，如 “下周六五点”。

你可以把它看成是一个有着复杂的令人难以置信的正则表达式匹配，可以从自然语言提取信息（尽管实际的实现细节可能比这个复杂得多）。

NSDataDetector 对象用一个需要检查的信息的位掩码类型来初始化，然后传入一个需要匹配的字符串。像 NSRegularExpression 一样，在一个字符串中找到的每个匹配是用 NSTextCheckingResult 来表示的，它有诸如字符范围和匹配类型的详细信息。然而，NSDataDetector 的特定类型也可以包含元数据，如地址或日期组件。

当然你也可以结合 YYKit 中的YYLabel进行文本的高亮展示，并且添加点击事件(以下是我项目中需要匹配文本中的手机号码)：

当初始化 NSDataDetector 的时候，确保只指定你感兴趣的类型。每当增加一个需要检查的类型，随着而来的是不小的性能损失为代价。

数据检测器匹配类型

NSDataDetector 的各种 NSTextCheckingTypes 匹配，及其相关属性表：

其他的一些注意事项可以自行参考 Mattt 的文章NSDataDetector自行进行查阅。

好了，大家可以进行尝试一下，在你的应用程序里充分利用 NSDataDetector 解锁那些已经隐藏在众目睽睽下的结构化信息吧。

参考自： https://developer.apple.com/documentation/foundation/nsregularexpression

https://developer.apple.com/documentation/foundation/nstextcheckingresult

https://nshipster.com/nsdatadetector

转自：https://www.jianshu.com/p/91daa300da26

需求

解析文件中的音视频流以解码同步并将视频渲染到屏幕上,音频通过扬声器输出.对于仅仅需要单纯播放一个视频文件可直接使用AVFoundation中上层播放器,这里是用最底层的方式实现,可获取原始音视频帧数据.

实现原理

本文主要分为三大块,解析模块使用FFmpeg parse文件中的音视频流,解码模块使用FFmpeg或苹果原生解码器解码音视频,渲染模块使用OpenGL将视频流渲染到屏幕,使用Audio Queue Player将音频以扬声器形式输出.

本文以解码一个.MOV媒体文件为例, 该文件中包含H.264编码的视频数据, AAC编码的音频数据,首先要通过FFmpeg去parse文件中的音视频流信息,parse出来的结果保存在AVPacket结构体中,然后分别提取音视频帧数据,音频帧通过FFmpeg解码器或苹果原生框架中的Audio Converter进行解码,视频通过FFmpeg或苹果原生框架VideoToolbox中的解码器可将数据解码,解码后的音频数据格式为PCM,解码后的视频数据格式为YUV原始数据,根据时间戳对音视频数据进行同步,最后将PCM数据音频传给Audio Queue以实现音频的播放,将YUV视频原始数据封装为CMSampleBufferRef数据结构并传给OpenGL以将视频渲染到屏幕上,至此一个完整拉取文件视频流的操作完成.

注意: 通过网址拉取一个RTMP流进行解码播放的流程与拉取文件流基本相同, 只是需要通过socket接收音视频数据后再完成解码及后续流程.

简易流程

Parse

• 创建AVFormatContext上下文对象: AVFormatContext *avformat_alloc_context(void);

• 从文件中获取上下文对象并赋值给指定对象: int avformat_open_input(AVFormatContext **ps, const char *url, AVInputFormat *fmt, AVDictionary **options)

• 读取文件中的流信息: int avformat_find_stream_info(AVFormatContext *ic, AVDictionary **options);

• 获取文件中音视频流: m_formatContext->streams[audio/video index]e

• 开始parse以获取文件中视频帧帧: int av_read_frame(AVFormatContext *s, AVPacket *pkt);

• 如果是视频帧通过av_bitstream_filter_filter生成sps,pps等关键信息.

• 读取到的AVPacket即包含文件中所有的音视频压缩数据.

解码

通过FFmpeg解码

• 获取文件流的解码器上下文: formatContext->streams[a/v index]->codec;

• 通过解码器上下文找到解码器: AVCodec *avcodec_find_decoder(enum AVCodecID id);

• 打开解码器: int avcodec_open2(AVCodecContext *avctx, const AVCodec *codec, AVDictionary **options);

• 将文件中音视频数据发送给解码器: int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt);

• 循环接收解码后的音视频数据: int avcodec_receive_frame(AVCodecContext *avctx, AVFrame *frame);

• 如果是音频数据可能需要重新采样以便转成设备支持的格式播放.(借助SwrContext)

通过VideoToolbox解码视频

• 将从FFmpeg中parse到的extra data中分离提取中NALU头关键信息sps,pps等

• 通过上面提取的关键信息创建视频描述信息:CMVideoFormatDescriptionRef, CMVideoFormatDescriptionCreateFromH264ParameterSets / CMVideoFormatDescriptionCreateFromHEVCParameterSets

• 创建解码器:VTDecompressionSessionCreate,并指定一系列相关参数.

• 将压缩数据放入CMBlockBufferRef中:CMBlockBufferCreateWithMemoryBlock

• 开始解码: VTDecompressionSessionDecodeFrame

• 在回调中接收解码后的视频数据

通过AudioConvert解码音频

• 通过原始数据与解码后数据格式的ASBD结构体创建解码器: AudioConverterNewSpecific

• 指定解码器类型AudioClassDescription

• 开始解码: AudioConverterFillComplexBuffer

• 注意: 解码的前提是每次需要有1024个采样点才能完成一次解码操作.

同步

因为这里解码的是本地文件中的音视频, 也就是说只要本地文件中音视频的时间戳打的完全正确,我们解码出来的数据是可以直接播放以实现同步的效果.而我们要做的仅仅是保证音视频解码后同时渲染.

注意: 比如通过一个RTMP地址拉取的流因为存在网络原因可能造成某个时间段数据丢失,造成音视频不同步,所以需要有一套机制来纠正时间戳.大体机制即为视频追赶音频,后面会有文件专门介绍,这里不作过多说明.

渲染

通过上面的步骤获取到的视频原始数据即可通过封装好的OpenGL ES直接渲染到屏幕上,苹果原生框架中也有GLKViewController可以完成屏幕渲染.音频这里通过Audio Queue接收音频帧数据以完成播放.

文件结构

快速使用

使用FFmpeg解码

首先根据文件地址初始化FFmpeg以实现parse音视频流.然后利用FFmpeg中的解码器解码音视频数据,这里需要注意的是,我们将从读取到的第一个I帧开始作为起点,以实现音视频同步.解码后的音频要先装入传输队列中,因为audio queue player设计模式是不断从传输队列中取数据以实现播放.视频数据即可直接进行渲染.

- (void)startRenderAVByFFmpegWithFileName:(NSString *)fileName {
    NSString *path = [[NSBundle mainBundle] pathForResource:fileName ofType:@"MOV"];
    
    XDXAVParseHandler *parseHandler = [[XDXAVParseHandler alloc] initWithPath:path];
    
    XDXFFmpegVideoDecoder *videoDecoder = [[XDXFFmpegVideoDecoder alloc] initWithFormatContext:[parseHandler getFormatContext] videoStreamIndex:[parseHandler getVideoStreamIndex]];
    videoDecoder.delegate = self;
    
    XDXFFmpegAudioDecoder *audioDecoder = [[XDXFFmpegAudioDecoder alloc] initWithFormatContext:[parseHandler getFormatContext] audioStreamIndex:[parseHandler getAudioStreamIndex]];
    audioDecoder.delegate = self;
    
    static BOOL isFindIDR = NO;
    
    [parseHandler startParseGetAVPackeWithCompletionHandler:^(BOOL isVideoFrame, BOOL isFinish, AVPacket packet) {
        if (isFinish) {
            isFindIDR = NO;
            [videoDecoder stopDecoder];
            [audioDecoder stopDecoder];
            dispatch_async(dispatch_get_main_queue(), ^{
                self.startWorkBtn.hidden = NO;
            });
            return;
        }
        
        if (isVideoFrame) { // Video
            if (packet.flags == 1 && isFindIDR == NO) {
                isFindIDR = YES;
            }
            
            if (!isFindIDR) {
                return;
            }
            
            [videoDecoder startDecodeVideoDataWithAVPacket:packet];
        }else {             // Audio
            [audioDecoder startDecodeAudioDataWithAVPacket:packet];
        }
    }];
}

-(void)getDecodeVideoDataByFFmpeg:(CMSampleBufferRef)sampleBuffer {
    CVPixelBufferRef pix = CMSampleBufferGetImageBuffer(sampleBuffer);
    [self.previewView displayPixelBuffer:pix];
}

- (void)getDecodeAudioDataByFFmpeg:(void *)data size:(int)size pts:(int64_t)pts isFirstFrame:(BOOL)isFirstFrame {
//    NSLog(@"demon test - %d",size);
    // Put audio data from audio file into audio data queue
    [self addBufferToWorkQueueWithAudioData:data size:size pts:pts];

    // control rate
    usleep(14.5*1000);
}

使用原生框架解码

首先根据文件地址初始化FFmpeg以实现parse音视频流.这里首先根据文件中实际的音频流数据构造ASBD结构体以初始化音频解码器,然后将解码后的音视频数据分别渲染即可.这里需要注意的是,如果要拉取的文件视频是H.265编码格式的,解码出来的数据的因为含有B帧所以时间戳是乱序的,我们需要借助一个链表对其排序,然后再将排序后的数据渲染到屏幕上.

- (void)startRenderAVByOriginWithFileName:(NSString *)fileName {
    NSString *path = [[NSBundle mainBundle] pathForResource:fileName ofType:@"MOV"];
    XDXAVParseHandler *parseHandler = [[XDXAVParseHandler alloc] initWithPath:path];
    
    XDXVideoDecoder *videoDecoder = [[XDXVideoDecoder alloc] init];
    videoDecoder.delegate = self;

    // Origin file aac format
    AudioStreamBasicDescription audioFormat = {
        .mSampleRate         = 48000,
        .mFormatID           = kAudioFormatMPEG4AAC,
        .mChannelsPerFrame   = 2,
        .mFramesPerPacket    = 1024,
    };
    
    XDXAduioDecoder *audioDecoder = [[XDXAduioDecoder alloc] initWithSourceFormat:audioFormat
                                                                     destFormatID:kAudioFormatLinearPCM
                                                                       sampleRate:48000
                                                              isUseHardwareDecode:YES];
    
    [parseHandler startParseWithCompletionHandler:^(BOOL isVideoFrame, BOOL isFinish, struct XDXParseVideoDataInfo *videoInfo, struct XDXParseAudioDataInfo *audioInfo) {
        if (isFinish) {
            [videoDecoder stopDecoder];
            [audioDecoder freeDecoder];
            
            dispatch_async(dispatch_get_main_queue(), ^{
                self.startWorkBtn.hidden = NO;
            });
            return;
        }
        
        if (isVideoFrame) {
            [videoDecoder startDecodeVideoData:videoInfo];
        }else {
            [audioDecoder decodeAudioWithSourceBuffer:audioInfo->data
                                     sourceBufferSize:audioInfo->dataSize
                                      completeHandler:^(AudioBufferList * _Nonnull destBufferList, UInt32 outputPackets, AudioStreamPacketDescription * _Nonnull outputPacketDescriptions) {
                                          // Put audio data from audio file into audio data queue
                                          [self addBufferToWorkQueueWithAudioData:destBufferList->mBuffers->mData size:destBufferList->mBuffers->mDataByteSize pts:audioInfo->pts];

                                          // control rate
                                          usleep(16.8*1000);
                                      }];
        }
    }];
}

- (void)getVideoDecodeDataCallback:(CMSampleBufferRef)sampleBuffer isFirstFrame:(BOOL)isFirstFrame {
    if (self.hasBFrame) {
        // Note : the first frame not need to sort.
        if (isFirstFrame) {
            CVPixelBufferRef pix = CMSampleBufferGetImageBuffer(sampleBuffer);
            [self.previewView displayPixelBuffer:pix];
            return;
        }
        
        [self.sortHandler addDataToLinkList:sampleBuffer];
    }else {
        CVPixelBufferRef pix = CMSampleBufferGetImageBuffer(sampleBuffer);
        [self.previewView displayPixelBuffer:pix];
    }
}

#pragma mark - Sort Callback
- (void)getSortedVideoNode:(CMSampleBufferRef)sampleBuffer {
    int64_t pts = (int64_t)(CMTimeGetSeconds(CMSampleBufferGetPresentationTimeStamp(sampleBuffer)) * 1000);
    static int64_t lastpts = 0;
//    NSLog(@"Test marigin - %lld",pts - lastpts);
    lastpts = pts;
    
    [self.previewView displayPixelBuffer:CMSampleBufferGetImageBuffer(sampleBuffer)];
}

具体实现

本文中每一部分的具体实现均有详细介绍, 如需帮助请参考阅读前提中附带的链接地址.

注意

因为不同文件中压缩的音视频数据格式不同,这里仅仅兼容部分格式,可自定义进行扩展.

转自：https://www.jianshu.com/p/854a1bb47173

//第一种：字面量
 var o1 = {name: 'o1'};
 var o2 = new Object({name: 'o2'});
//第二种  通过构造函数
 var M = function (name) { this.name = name; };
 var o3 = new M('o3');
//第三种  Object.create
 var p = {name: 'p'};
 var o4 = Object.create(p);

1，构造函数
fn Animal(){
this.name = 'name'
}
2，ES6class的声明
class Animal2 {
//↓↓构造函数
constructor(){
this.name=name
}
}
实例化类
console.log(new Animal(),new Animal2())

fn parent1（）{
this.name= 'parent1'
}
parent1.prototype.say(){
console.log('hello')
}
fn child1() {
parent1.call(this)
this.type='child1'
}

fn parent2(){
this.name= 'parent2'
this.play=[1,2,3]
}
fn child2() {
this.type='child2'
}
child2.prototype = new parent2()
  var s1 = new Child2();
  var s2 = new Child2();
   s1.play.push(4);

fn parent3(){
this.name= 'parent3'
this.play=[1,2,3]
}
fn child3() {
parent3.call(this)
this.type='child2'
}
child3.prototype = new parent3()
 var s3 = new Child3();
 var s4 = new Child3();
 s3.play.push(4);
console.log(s3.play,s4.play)

fn parent4(){
this.name= 'parent4'
this.play=[1,2,3]
}
fn child4() {
parent4.call(this)
this.type='child4'


}
child4.prototype = parent4.prototype
 var s5 = new Child4();
 var s6 = new Child4();
console.log(s5 instance child4,s5 instance parent4)//true true
console.log(s5.constructor)//parent4
缺点：区分不了s5是child4还是parent4的实例
//优化方式
fn parent5(){
this.name= 'parent5'
this.play=[1,2,3]
}
fn child5() {
parent5.call(this)
this.type='child5'
}
child5.prototype = Object.creat(parent5.prototype)
//此时还是找不到  创建一下constructor可解决
child5.prototype.constructor = child5
 var s7 = new Child5();
console.log(s7 instance child4,s7 instance parent4)//true true
console.log(s7.constructor)//child5

DOM事件的级别

DOM0

element.onclick=function(){}

DOM1

未制定事件相关的标准

DOM2

element.add('click',fn,false)/ie . atench

DOM3

el.add('keyup',fn,false)增加了其他事件除了click

DOM事件的模型：捕获和冒泡

DOM事件流

三个j阶段

捕获 。 目标阶段 。 冒泡阶段

事件捕获的具体流程

window=>document=>html=>body=>.....目标

冒泡则相反

event对象的常见应用

event.preventDefalut . 阻止默认行为

event.stopPropagation . 阻止冒泡

event.stoplmmediatePropagation . 事件响应优先级

事件代理

event.currentTarget 当前绑定的事件的对象

event.target 返回触发事件的元素

currentTarget在事件流的捕获，冒泡阶段。只有当事件流处在冒泡阶段的时候，两个的指向才是一样的， 而当处于捕获和冒泡阶段的时候，

target指向被单击的对象

currentTarget指向当前事件活动的对象（一般为父级）。

自定义事件

let eve = new Event('eveName')/new CustomEvent可以加参数Obj

//注册

ev.addEventListener('eveName',fn)

//触发

ev.dispatchEvent(eve)

HTTP

http协议包括 ：通用头域、请求消息、响应消息和主体信息。

特点

简单快速

每个资源得url是固定得

灵活

无连接

连接一次就会断掉

无状态

服务端不记录客户端连接得身份

报文得组成部分

请求报文

请求行

http方法

页面地址

http协议以及http版本

请求头

key value值告诉服务端我要哪些内容

空行

隔断

请求体

数据

响应报文

状态行

协议 状态吗

响应头

key value

空行

隔断

相应体

数据

http方法

get 获取资源

post 传输资源

put 更新资源

delete 删除资源

HEAD 获取报文首部

POST和GET区别（记住以下三个以上1，3，4，6，9）

HTTP状态码

持久链接

http1.1版本支持

管线化

1. 管线化得特点和原理
2. 请求和响应打包返回
3. 持续连接完成后进行的且需要1.1版本的支持
4. 管线化只有get和head可以进行 post有限制
5. 管线化默认chrome和firefox默认不开启，初次连接的时候可能不支持，需要服务端的支持

基础方法

1:浮动（延伸BFC）

清除浮动后 浮动元素周边的元素处理的好的话 。 兼容性比较好

2:绝对定位

配合js的话 快捷

缺点：脱离文档流

3:flex

比较完美的方案 。 解决以上的缺点

4:表格布局

兼容性特别好 ie

缺点：。。

5:网格布局 gride

新的标准

代码最简化哈

拔高延续

1:如过去掉高度已知 。 哪个不在好用？

第三和第四能用

2:竖起来

3:两栏布局

你在下单时，要给后台发请求，后台通过拿到的参数请求微信后台去生成订单并同时返给你一个路径mweb_url，这个路径就是用来调起微信应用发起支付操作的。（这里要说明的就是由于h5支付不能主动回调，所以需要个主动查询的操作，这时会需要你又一个确认界面来进行主动查询订单状态。这里是个坑一会儿再说），调起支付界面之后进行支付操作，期间你什么都不用管，因为这都是微信的事。你需要的就是在你付完钱之后查看你的钱买你要的东西到底有没有成功（你要是不加的话，谁知道成功没，估计顾客会打死你，付完钱就茫然了，不知道到底钱到哪去了→_→）

普通函数中的this:

1. this总是代表它的直接调用者, 例如 obj.func ,那么func中的this就是obj

2.在默认情况(非严格模式下,未使用 'use strict'),没找到直接调用者,则this指的是 window

3.在严格模式下,没有直接调用者的函数中的this是 undefined

4.使用call,apply,bind(ES5新增)绑定的,this指的是 绑定的对象

箭头函数中的this

默认指向在定义它时,它所处的对象,而不是执行时的对象, 定义它的时候,可能环境是window（即继承父级的this）;

下面通过一些例子来研究一下 this的一些使用场景

call

call(null, arr[0], arr[1], arr[2], arr[3], arr[4])//89

1 dom有元素 页面不渲染

首页 scoped 不加 导致引入的tab分类无法加载图片

原因未知 此处感觉不太球对 瞎吉儿改的

2:懒加载问题

3.vue router

repalce push go

4css使图片置灰

-webkit-filter: grayscale(100%); -moz-filter: grayscale(100%); -ms-filter: grayscale(100%); -o-filter: grayscale(100%); filter: grayscale(100%); filter: gray;

获取字符串长度 str.length

分割字符串 str.split()

拼接字符串 str1+str2 或 str1.concat(str2)

替换字符串 str.replace(“玩游戏”,”好好学习”)

提取子字符串 str.slice(start, end)或str.substring(start,end)或myStr.substr(start,length)

切换字符串大小写 str.toLowerCase()和str.toUpperCase()

比较字符串 str1.localeCompare(str2)

匹配字符串 str.match(pattern)或pattern.exec(str)或str.search(pattern)

根据位置查字符 str.charAt(index)

根据位置字符Unicode编码 str.charCodeAt(index)

根据字符查位置 str.indexOf(“you”)从左，myStr.lastIndexOf(“you”)从尾 或str.search(‘you’)

原始数据类型转字符串 String(数据) 或利用加号

字符串转原始数据类型 数字Number(”) // 0 布尔Boolean(”) // 0

自己构建属性和方法 String.prototype.属性或方法= function(参数){代码}

----------

箭头函数需要注意的地方

*当要求动态上下文的时候，就不能够使用箭头函数，也就是this的固定化。

1、在使用=>定义函数的时候，this的指向是定义时所在的对象，而不是使用时所在的对象；

2、不能够用作构造函数，这就是说，不能够使用new命令，否则就会抛出一个错误；

3、不能够使用arguments对象；

4、不能使用yield命令；

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

let和const

 *let是更完美的var，不是全局变量，具有块级函数作用域,大多数情况不会发生变量提升。const定义常量值，不能够重新赋值，如果值是一个对象，可以改变对象里边的属性值。

1、let声明的变量具有块级作用域

2、let声明的变量不能通过window.变量名进行访问

3、形如for(let x..)的循环是每次迭代都为x创建新的绑定

依次输出的问题

1:立即执行函数

2:闭包

3:let

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

Set数据结构

*es6方法,Set本身是一个构造函数，它类似于数组，但是成员值都是唯一的。

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

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

promise 案例较多 。 建议看代码

http://www.cnblogs.com/fengxiongZz/p/8191503.html

常用api

moveTo(x0,y0)：把当前画笔（ictx）移动到（x0,y0）这个位置。

lineTo(x1,y1):从当前位置(x0,y0)处到（x1，y1）画一条直线。

beginPath()：开启一条路径或者重置当前路径。

closePath():从当前点回到路径起始点，也就是上一个beginPath的位置,回避和路径。

stroke():绘制。必须加了这个函数才会画图，所以这个一定要放在最后。

绘制一个圆形

/获取Canvas对象(画布)

var canvas = document.getElementById("myCanvas");

//简单地检测当前浏览器是否支持Canvas对象，以免在一些不支持html5的浏览器中提示语法错误

if(canvas.getContext){

//获取对应的CanvasRenderingContext2D对象(画笔)

var ctx = canvas.getContext("2d");

//开始一个新的绘制路径

ctx.beginPath();

//设置弧线的颜色为蓝色

ctx.strokeStyle = "blue";

var circle = {

x : 100, //圆心的x轴坐标值

y : 100, //圆心的y轴坐标值

r : 50 //圆的半径

};

//沿着坐标点(100,100)为圆心、半径为50px的圆的顺时针方向绘制弧线

ctx.arc(circle.x, circle.y, circle.r, 0, Math.PI / 2, false);

//按照指定的路径绘制弧线

ctx.stroke();

}

------

深拷贝

深拷贝就是指完全的拷贝一个对象，即使嵌套了对象，两者也相互分离，修改一个对象的属性，也不会影响另一个

1:不仅可拷贝数组还能拷贝对象（但不能拷贝函数）

var arr = ['old', 1, true, ['old1', 'old2'], {old: 1}] var new_arr = JSON.parse(JSON.stringify(arr)) console.log(new_arr);

2:下面是深拷贝一个通用方法，实现思路：拷贝的时候判断属性值的类型，如果是对象，继续递归调用深拷贝函数

var deepCopy = function(obj) {

// 只拷贝对象

if (typeof obj !== 'object') return;

// 根据obj的类型判断是新建一个数组还是一个对象

var newObj = obj instanceof Array ? [] : {};

for (var key in obj) {

// 遍历obj,并且判断是obj的属性才拷贝

if (obj.hasOwnProperty(key)) {

// 判断属性值的类型，如果是对象递归调用深拷贝

newObj[key] = typeof obj[key] === 'object' ? deepCopy(obj[key]) : obj[key];

}

}

return newObj;

}

浅拷贝

数组的浅拷贝，可用concat、slice返回一个新数组的特性来实现拷贝for in

var arr = ['old', 1, true, null, undefined];

var new_arr = arr.concat(); // 或者var new_arr = arr.slice()也是一样的效果;

new_arr[0] = 'new';

console.log(arr); // ["old", 1, true, null, undefined]

console.log(new_arr); // ["new", 1, true, null, undefined]

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

数组常用的方法

map此方法是将数组中的每个元素调用一个提供的函数，结果作为一个新的数组返回，并没有改变原来的数组

let arr = [1, 2, 3, 4, 5]

    let newArr = arr.map(x => x*2)

    //arr= [1, 2, 3, 4, 5]   原数组保持不变

    //newArr = [2, 4, 6, 8, 10] 返回新数组

forEach此方法是将数组中的每个元素执行传进提供的函数，没有返回值，直接改变原数组，注意和map方法区分

let arr = [1, 2, 3, 4, 5]

   num.forEach(x => x*2)

    // arr = [2, 4, 6, 8, 10]  数组改变,注意和map区分

filter()此方法是将所有元素进行判断，将满足条件的元素作为一个新的数组返回

let arr = [1, 2, 3, 4, 5]

     const isBigEnough => value => value >= 3

     let newArr = arr.filter(isBigEnough )

     //newNum = [3, 4, 5] 满足条件的元素返回为一个新的数组

reduce()此方法是所有元素调用返回函数，返回值为最后结果,传入的值必须是函数类型：

let arr = [1, 2, 3, 4, 5]

    const add = (a, b) => a + b

    let sum = arr.reduce(add)

    //sum = 15  相当于累加的效果

    与之相对应的还有一个 Array.reduceRight() 方法，区别是这个是从右向左操作的

push/pop

push:数组后面添加新元素，改变数组的长度

pop：数组删除最后一个元素 。 也改变长度

shift/unshift

shift：删除第一个元素 。 改变数组的长度

unshift：将一个或多个添加到数组开头 。 返回数组长度

isArray：返回bool

cancat：合并数组

toString：数组转字符串

join（"--"）:数组转字符串 。 间隔可以设置

splice（开始位置，删除个数，元素）万能方法 增删改

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

判断是不是数组的方法

var arr = [1,2,3,1];

var arr2 = [{ abac : 1, abc : 2 }];

function isArrayFn(value){

if (typeof Array.isArray === "function") {

//判断是否支持isArray ie8之前不支持

return Array.isArray(value);

}else{

return Object.prototype.toString.call(value) === "[object Array]";

}

}

alert(isArrayFn(arr));// true

alert(isArrayFn(arr2));// true

项目中有一个控制器里的图片服务器那边没有进行压缩 所以使用SDWebImage显示在collectionView/tableView的时候有时会crash（及时没有反复进几次就会crash了）。网上查了很多资料，大致总结有一下几种方法：

1、每次加载高清图片时清空memcache

[[SDImageCache sharedImageCache] setValue:nil forKey:@"memCache"];

但是这种方法会产生一个效果：当滑动tableView的时候 cell消失在屏幕中再滑回来图片会从新加载。

2.取消解压缩

[SDImageCache sharedImageCache].shouldDecompressImages = NO；
[SDWebImageDownloader sharedDownloader].shouldDecompressImages = NO;

之所以产生crash的原因，是因为在SDWebImage里的这个方法decodedImageWithImage在加载高清图片是占用了大量内存。所以上面的两行代码就禁止调用了这个方法，那么问题来了，那这个方法存在的意义又是什么呢？

因为我们对图片的展示大部分是在tableviews/collectionview里 其实decodedImageWithImage方法是对图片进行解压缩并且缓存起来，以提高流畅度。但是加载高分辨率的图片就会起到适得其反的效果。所以在加载高分辨率图片的地方调用以上两个方法，其他地方仍然保持为YES就可以了。如果再限制图片内存缓存最高限制就更安全了

3.对图片进行等比例压缩(需修改源码)

这里面对图片的处理是直接按照原大小进行的，如果分辨率很大这里导致占用了大量内存。所以我们需要在这里对图片做一次等比的压缩。

在UIImage+MultiFormat这个类里面添加如下压缩方法

+(UIImage *)compressImageWith:(UIImage *)image{
float imageWidth = image.size.width;
float imageHeight = image.size.height;
float width = 640;
float height = image.size.height/(image.size.width/width);
float widthScale = imageWidth /width;
float heightScale = imageHeight /height;
// 创建一个bitmap的context
// 并把它设置成为当前正在使用的context
UIGraphicsBeginImageContext(CGSizeMake(width, height));
if (widthScale > heightScale) {
[image drawInRect:CGRectMake(0, 0, imageWidth /heightScale , height)];
}
else {
image drawInRect:CGRectMake(0, 0, width , imageHeight /widthScale)];
}
// 从当前context中创建一个改变大小后的图片
UIImage *newImage = UIGraphicsGetImageFromCurrentImageContext();
// 使当前的context出堆栈
UIGraphicsEndImageContext();
return newImage;
}

在上图箭头位置这样调用

image = [[UIImage alloc] initWithData:data];
if (data.length/1024 > 128) {
image = [self compressImageWith:image];
}

到了这里还需要进行最后一步。就是在SDWebImageDownloaderOperation的connectionDidFinishLoading方法里面的：

UIImage *image = [UIImage sd_imageWithData:self.imageData];
//将等比压缩过的image在赋在转成data赋给self.imageData
NSData *data = UIImageJPEGRepresentation(image, 1);
self.imageData = [NSMutableData dataWithData:data];

但是我在尝试这个方法的时候只这样操作的话还是会crash，所以还是要配合下面这个方法使用，所以那个郁闷啊！！！！大家也可以尝试一下

[[SDImageCache sharedImageCache] setValue:nil forKey:@"memCache"];
最终我是选择了第二种。欢迎补充！

链接：https://www.jianshu.com/p/7013919c03eb

通知栏分本地通知和apns推送通知

情况1：App进入后台没有超过150秒左右，接收消息没有通知栏提示，这种情况要配置本地通知，先注册本地通知（系统方法），然后再看下文档介绍： 如何实现本地通知

情况2：不是本地通知，App退到后台超过150秒左右，接收消息没有通知栏提示，这个情况属于apns推送。

如果没有配置apns推送，先按照文档配置： APNS推送配置
如果配置过了apns推送，那么在初始化SDK方法之后调用下这个方法试下：

- (void)applicationDidEnterBackground:(UIApplication *)application
{
    [[EMClient sharedClient] applicationDidEnterBackground:application];
}

- (void)applicationWillEnterForeground:(UIApplication *)application
{
    [[EMClient sharedClient] applicationWillEnterForeground:application];
}

MLang 动态化多语言框架

MLang 是 MultiLanguage 的简写，是一款动态化的多语言框架。

设计优雅

•  语言包存储格式为 xml 格式，和 res 下的 strings.xml 一致
•  零依赖，完全使用系统 api 和系统的 xml 解析器
•  不持有 context，无内存泄漏
•  静态方法 + 单例模式，一处安装，到处使用

动态化语言包

•  动态下发语言包
•  语言包的增加、升级、删除
•  语言包内部任意字符串的增加、升级、删除
•  自定义语言包的存储路径

完全兼容

•  跟随系统语言
•  时间格式跟随系统的 24 小时制
•  处理各种语言的时区、时间格式化问题
•  处理各种语言的复数格式化问题
•  处理各种语言的阅读顺序问题（从左到右、从右到左）

1. 使用

使用字符串

// 本地和云端都存在的字符串

MyLang.getString("local_string", R.string.local_string)



// 云端存在 remote_string_only

// 但本地没有 R.string.remote_string_only，用 R.string.fallback_string 代替

MyLang.getString("remote_string_only", R.string.fallback_string)

使用语言包

//应用一种语言（这里自动处理了语言包的升级、语言包内部字符串的升级）

MyLang.getInstance().applyLanguage(Context, LocaleInfo, force=true, init=false);



//删除一种语言

MyLang.getInstance().deleteLanguage(Context, LocaleInfo);

LocaleInfo 可以在以下地方找到

//1. 所有云端的语言包

MyLang.getInstance().remoteLanguages



//2. 所有下载到本地、可用的语言包

MyLang.getInstance().languages



//3. 所有非官方的语言包

MyLang.getInstance().unofficialLanguages



//4. 除内置支持的语言外，另外安装的云端的语言包

MyLang.getInstance().otherLanguages

2. 安装

2.1. 引入

//build.gradle

allprojects {

    repositories {

        google()

        jcenter()

        maven { url "https://github.com/LinXueyuanStdio/MLang/raw/main/dist/" }

    }

}



//app/build.gradle

implementation 'com.timecat.component:MLang:2.0.2'

2.2. 在 Application 中初始化，并监听系统语言的更改（如果跟随系统语言的话）：

public class MyApplication extends Application {

    @SuppressLint("StaticFieldLeak")

    public static volatile Context applicationContext;

    public static volatile Handler applicationHandler;



    @Override

    public void onCreate() {

        super.onCreate();

        applicationContext = this;

        applicationHandler = new Handler(applicationContext.getMainLooper());

        MyLang.init(applicationContext);

    }



    @Override

    public void onConfigurationChanged(@NonNull Configuration newConfig) {

        super.onConfigurationChanged(newConfig);

        MyLang.onConfigurationChanged(newConfig);

    }

}

其中建议自己新建一个静态类 MyLang 来代理 MLang。 这样有两个好处：

1. 隔绝 MLang 的 api 变化，提高兼容性和稳定性。
2. 使用更简洁。MLang 不持有 context，但每次获取字符串为空时，需要 context 来兜底，获取本地的字符串。在自己的 MyLang 默认提供 application Context，可以不用到处提供 context，更简洁。

public class MyLang {

    private static File filesDir;

    private static LangAction action;

    public static void init(@NonNull Context applicationContext) {

        filesDir = applicationContext.getCacheDir();

        action = new MyLangAction();

        getInstance();

    }

    public static MLang getInstance() {

        return MLang.getInstance(MyApplication.applicationContext, filesDir, action);

    }

    public static void onConfigurationChanged(@NonNull Configuration newConfig) {

        getInstance().onDeviceConfigurationChange(getContext(), newConfig);

    }

}

3. 设计

3.1. 单例模式接收 3 个参数，context，fileDir，action

1. context：MLang 内部不持有该 context。该 context 用于注册时区广播（根据时区来格式化字符串中的时间）、 判断系统当前时间是否 24 小时制等等。
2. filesDir：持久化语言包文件的存储地址。语言包文件是 xml 格式，和 res 下的 strings.xml 一样。
3. action：action 包含了应用语言包、切换语言等等需要的所有回调，即 LangAction 接口。

MLang.getInstance(context, filesDir, action);

3.2. LangAction 接口定义了 2 个东西

1. 当前语言的设置存储。 MLang 根据语言 id (string) 来识别当前语言。语言 id 需要持久化。 所以设计了下面两个方法，可以自行决定持久化的方式（SharedPreferences、MMKV、SQLite等等）。

   void saveLanguageKeyInLocal(String language);
   
   @Nullable String loadLanguageKeyInLocal();

2. 必要的网络接口。

   void langpack_getDifference(String lang_pack, String lang_code, int from_version, @NonNull final LangAction.GetDifferenceCallback callback)
   
   void langpack_getLanguages(@NonNull final LangAction.GetLanguagesCallback callback)
   
   void langpack_getLangPack(String lang_code, @NonNull final LangAction.GetLangPackCallback callback)

LangAction 的注释如下：

public interface LangAction {

    /**

     * SharedPreferences preferences = Utilities.getGlobalMainSettings();

     * SharedPreferences.Editor editor = preferences.edit();

     * editor.putString("language", language);

     * editor.commit();

     * @param language localeInfo.getKey() 语言 id

     */

    void saveLanguageKeyInLocal(String language);



    /**

     * SharedPreferences preferences = Utilities.getGlobalMainSettings();

     * String lang = preferences.getString("language", null);

     * @return @Nullable lang 语言 id

     */

    String loadLanguageKeyInLocal();



    /**

     * 在其他线程网络请求，在主线程或UI线程调用callback

     * 这里设计成这样，是因为这个方法里支持异步执行

     * 您需要在合适的时机手动调用 callback，且只能调用一次

     * @param lang_pack 语言包名字

     * @param lang_code 语言包版本名称

     * @param from_version 语言包版本号

     * @param callback @NonNull 在主线程或UI线程调用

     */

    void langpack_getDifference(String lang_pack, String lang_code, int from_version, GetDifferenceCallback callback);



    /**

     * 在其他线程网络请求，在主线程或UI线程调用callback

     * 这里设计成这样，是因为这个方法里支持异步执行

     * 您需要在合适的时机手动调用 callback，且只能调用一次

     * @param callback @NonNull 在主线程或UI线程调用

     */

    void langpack_getLanguages(GetLanguagesCallback callback);



    /**

     * 在其他线程网络请求，在主线程或UI线程调用callback

     * 这里设计成这样，是因为这个方法里支持异步执行

     * 您需要在合适的时机手动调用 callback，且只能调用一次

     * @param lang_code 语言包版本名称

     * @param callback @NonNull 在主线程或UI线程调用

     */

    void langpack_getLangPack(String lang_code, GetLangPackCallback callback);



    interface GetLanguagesCallback {

        /**

         * 必须在UI线程或者主线程调用

         * 所有可用的语言包

         * @param languageList 语言包列表

         */

        void onLoad(List<LangPackLanguage> languageList);

    }



    interface GetDifferenceCallback {

        /**

         * 必须在UI线程或者主线程调用

         * 如果服务端没有实现增量分发的功能，可以用完整的语言包代替

         * @param languageList 增量的语言包

         */

        void onLoad(LangPackDifference languageList);

    }



    interface GetLangPackCallback {

        /**

         * 必须在UI线程或者主线程调用

         * @param languageList 完整的语言包

         */

        void onLoad(LangPackDifference languageList);

    }



}

实现LangAction的一个示例如下：

public class MyLangAction implements LangAction {

   @Override

   public static void saveLanguageKeyInLocal(String language) {

       SharedPreferences preferences = getContext().getSharedPreferences("language_locale", Context.MODE_PRIVATE);

       SharedPreferences.Editor editor = preferences.edit();

       editor.putString("language", language);

       editor.apply();

   }



   @Override

   @Nullable

   public static String loadLanguageKeyInLocal() {

       SharedPreferences preferences = getContext().getSharedPreferences("language_locale", Context.MODE_PRIVATE);

       return preferences.getString("language", null);

   }

   @Override

   public void langpack_getDifference(String lang_pack, String lang_code, int from_version, @NonNull final LangAction.GetDifferenceCallback callback) {

       Server.request_langpack_getDifference(lang_pack, lang_code, from_version, new Server.GetDifferenceCallback() {

           @Override

           public void onNext(final LangPackDifference difference) {

               callback.onLoad(difference);

           }

       });

   }



   @Override

   public void langpack_getLanguages(@NonNull final LangAction.GetLanguagesCallback callback) {

       Server.request_langpack_getLanguages(new Server.GetLanguagesCallback() {

           @Override

           public void onNext(final List<LangPackLanguage> languageList) {

               callback.onLoad(languageList);

           }

       });

   }



   @Override

   public void langpack_getLangPack(String lang_code, @NonNull final LangAction.GetLangPackCallback callback) {

       Server.request_langpack_getLangPack(lang_code, new Server.GetLangPackCallback() {

           @Override

           public void onNext(final LangPackDifference difference) {

               callback.onLoad(difference);

           }

       });

   }

}

3.3. 服务器语言包的结构

模拟的服务器数据

语言包实体

• LangPackLanguage(name, version, ...)

语言包的数据

• LangPackDifference(name, version, List, ...)
• LangPackString(key: String, value: String)

public class Server {

    public static LangPackLanguage chineseLanguage() {

        LangPackLanguage langPackLanguage = new LangPackLanguage();

        langPackLanguage.name = "chinese";

        langPackLanguage.native_name = "简体中文";

        langPackLanguage.lang_code = "zh";

        langPackLanguage.base_lang_code = "zh";

        return langPackLanguage;

    }

    public static LangPackDifference chinesePackDifference() {

        LangPackDifference difference = new LangPackDifference();

        difference.lang_code = "zh";

        difference.from_version = 0;

        difference.version = 1;

        difference.strings = chineseStrings();

        return difference;

    }

    public static ArrayList<LangPackString> chineseStrings() {

        ArrayList<LangPackString> list = new ArrayList<>();

        list.add(new LangPackString("LanguageName", "中文简体"));

        list.add(new LangPackString("LanguageNameInEnglish", "Chinese"));

        list.add(new LangPackString("local_string", "中文的云端字符串"));

        list.add(new LangPackString("remote_string_only", "本地缺失，云端存在的字符串"));

        return list;

    }

}

4. 进阶配置

MLang.isRTL = false; //是否从右到左阅读（默认 false）

MLang.is24HourFormat = false; //是否 24 小时制（默认 false） 

MLang.USE_CLOUD_STRINGS = true; //是否使用云端字符串（默认 true）

代码下载:MLang-main.zip

SnakeViewMaker

SnakeViewMaker 是一个模仿即刻App里用户头像拖动效果的工具类。

调用方法：

1.创建 SnakeViewMaker；

    SnakeViewMaker snakeViewMaker = new SnakeViewMaker(MainActivity.this);

2.绑定

    snakeViewMaker

    .addTargetView(imageView)                                  // 绑定目标View

    .attachToRootLayout((ViewGroup) findViewById(R.id.root));  // 绑定Activity/Fragment的根布局

3.其他相关API

    snakeViewMaker.detachSnake();                // 解除绑定

    snakeViewMaker.updateSnakeImage();           // 当目标View的视图发生变化时，调用此方法用以更新Snake视图状态

    snakeViewMaker.interceptTouchEvent(true);    // Snake拖动过程中是否需要屏蔽其他onTouch事件，默认屏蔽

    snakeViewMaker.setVisibility(View.VISIBLE);  // 控制可见性

    snakeViewMaker.setClickable(true);           // 控制可点击

    snakeViewMaker.setEnabled(true);             // 控制可触摸

注意事项

1.目前不支持LinearLayout根布局

2.加载本地图片可直接调用。网络图片需要在图片加载完成后才能调用，不然可能出现绑定不成功的情况

例如，用glide加载网络图片时，调用时机如下：

    snakeViewMaker = new SnakeViewMaker(MainActivity.this);

    Glide.with(this).load(url).asBitmap()

                    .into(new BitmapImageViewTarget(imageView) {

                        @Override

                        protected void setResource(Bitmap resource) {

                            super.setResource(resource);

                            snakeViewMaker.addTargetView(imageView)

                                    .attachToRootLayout((ViewGroup) findViewById(R.id.root));

                        }

                    });

代码下载:SnakeViewMaker-master.zip

public class DragViewGroup extends RelativeLayout {



    ViewDragHelper mDragHelper;



    public DragViewGroup(Context context) {

        this(context, null);

    }



    public DragViewGroup(Context context, AttributeSet attrs) {

        this(context, attrs, 0);

    }



    public DragViewGroup(Context context, AttributeSet attrs, int defStyleAttr) {

        super(context, attrs, defStyleAttr);

        mDragHelper = ViewDragHelper.create(this, 1.0f, new ViewDragCallback());

    }

    ...

}

复制代码

private static class ViewDragCallback extends ViewDragHelper.Callback {

    @Override

    public boolean tryCaptureView(@NonNull View child, int pointerId) {

        // 决定child是否可以被拖拽，具体见下文源码分析

        return true;

    }



    @Override

    public int clampViewPositionHorizontal(@NonNull View child, int left, int dx) {

        // 可决定child横向的偏移计算，见下文

        return left;

    }



    @Override

    public int clampViewPositionVertical(@NonNull View child, int top, int dy) {

        // 可决定child竖向的偏移计算，见下文

        return top;

    }

}

复制代码

public class DragViewGroup extends RelativeLayout {

    ...

    @Override

    public boolean onInterceptHoverEvent(MotionEvent event) {

        return mDragHelper.shouldInterceptTouchEvent(event);

    }



    @SuppressLint("ClickableViewAccessibility")

    @Override

    public boolean onTouchEvent(MotionEvent event) {

        mDragHelper.processTouchEvent(event);

        return true;

    }

    ...

}

复制代码

<com.blog.a.drag.DragViewGroup

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    > 

    <TextView

        android:layout_width="70dp"

        android:layout_height="70dp"

        android:text="可拖拽"

        android:gravity="center"

        android:textColor="#fff"

        android:background="#6495ED"

        />

</com.blog.a.drag.DragViewGroup>

复制代码

    public boolean onTouchEvent(MotionEvent event) {

        mDragHelper.processTouchEvent(event);

        return true;

    }

复制代码

    case MotionEvent.ACTION_DOWN: {

        final float x = ev.getX();

        final float y = ev.getY();

        final int pointerId = ev.getPointerId(0);

        final View toCapture = findTopChildUnder((int) x, (int) y);



        saveInitialMotion(x, y, pointerId);



        tryCaptureViewForDrag(toCapture, pointerId);

        // mTrackingEdges默认是0，可通过ViewDragHelper#setEdgeTrackingEnabled(int)

        // 来设置，用来控制触碰边缘回调onEdgeTouched

        final int edgesTouched = mInitialEdgesTouched[pointerId];

        if ((edgesTouched & mTrackingEdges) != 0) {

            mCallback.onEdgeTouched(edgesTouched & mTrackingEdges, pointerId);

        }

        break;

    }

复制代码

    public View findTopChildUnder(int x, int y) {

        final int childCount = mParentView.getChildCount();

        for (int i = childCount - 1; i >= 0; i--) {

            final View child = mParentView.getChildAt(mCallback.getOrderedChildIndex(i));

            if (x >= child.getLeft() && x < child.getRight()

                    && y >= child.getTop() && y < child.getBottom()) {

                return child;

            }

        }

        return null;

    }

复制代码

    private void saveInitialMotion(float x, float y, int pointerId) {

        ensureMotionHistorySizeForId(pointerId);

        mInitialMotionX[pointerId] = mLastMotionX[pointerId] = x;

        mInitialMotionY[pointerId] = mLastMotionY[pointerId] = y;

        mInitialEdgesTouched[pointerId] = getEdgesTouched((int) x, (int) y);

        mPointersDown |= 1 << pointerId;

    }

复制代码

    boolean tryCaptureViewForDrag(View toCapture, int pointerId) {

        if (toCapture == mCapturedView && mActivePointerId == pointerId) {

            // Already done!

            return true;

        }

        if (toCapture != null && mCallback.tryCaptureView(toCapture, pointerId)) {

            mActivePointerId = pointerId;

            captureChildView(toCapture, pointerId);

            return true;

        }

        return false;

    }

复制代码

    public void captureChildView(@NonNull View childView, int activePointerId) {

        if (childView.getParent() != mParentView) {

            throw new IllegalArgumentException("captureChildView: parameter must be a descendant "

                    + "of the ViewDragHelper's tracked parent view (" + mParentView + ")");

        }



        mCapturedView = childView;

        mActivePointerId = activePointerId;

        mCallback.onViewCaptured(childView, activePointerId);

        setDragState(STATE_DRAGGING);

    }

复制代码

    case MotionEvent.ACTION_POINTER_DOWN: {

        final int pointerId = ev.getPointerId(actionIndex);

        final float x = ev.getX(actionIndex);

        final float y = ev.getY(actionIndex);



        saveInitialMotion(x, y, pointerId);

        // A ViewDragHelper can only manipulate one view at a time.

        if (mDragState == STATE_IDLE) {

            // If we're idle we can do anything! Treat it like a normal down event.

            final View toCapture = findTopChildUnder((int) x, (int) y);

            tryCaptureViewForDrag(toCapture, pointerId);



            final int edgesTouched = mInitialEdgesTouched[pointerId];

            if ((edgesTouched & mTrackingEdges) != 0) {

                mCallback.onEdgeTouched(edgesTouched & mTrackingEdges, pointerId);

            }

        } else if (isCapturedViewUnder((int) x, (int) y)) {

            tryCaptureViewForDrag(mCapturedView, pointerId);

        }

        break;

    }

复制代码

    case MotionEvent.ACTION_MOVE: {

        if (mDragState == STATE_DRAGGING) {

            // If pointer is invalid then skip the ACTION_MOVE.

            if (!isValidPointerForActionMove(mActivePointerId)) break;



            final int index = ev.findPointerIndex(mActivePointerId);

            final float x = ev.getX(index);

            final float y = ev.getY(index);

            final int idx = (int) (x - mLastMotionX[mActivePointerId]);

            final int idy = (int) (y - mLastMotionY[mActivePointerId]);



            dragTo(mCapturedView.getLeft() + idx, mCapturedView.getTop() + idy, idx, idy);



            saveLastMotion(ev);

        } else {

            // Check to see if any pointer is now over a draggable view.

            ...

        }

        break;

    }

复制代码

    private void dragTo(int left, int top, int dx, int dy) {

        int clampedX = left;

        int clampedY = top;

        final int oldLeft = mCapturedView.getLeft();

        final int oldTop = mCapturedView.getTop();

        if (dx != 0) {

            clampedX = mCallback.clampViewPositionHorizontal(mCapturedView, left, dx);

            ViewCompat.offsetLeftAndRight(mCapturedView, clampedX - oldLeft);

        }

        if (dy != 0) {

            clampedY = mCallback.clampViewPositionVertical(mCapturedView, top, dy);

            ViewCompat.offsetTopAndBottom(mCapturedView, clampedY - oldTop);

        }



        if (dx != 0 || dy != 0) {

            final int clampedDx = clampedX - oldLeft;

            final int clampedDy = clampedY - oldTop;

            mCallback.onViewPositionChanged(mCapturedView, clampedX, clampedY,

                    clampedDx, clampedDy);

        }

    }

复制代码

    case MotionEvent.ACTION_MOVE: {

        if (mDragState == STATE_DRAGGING) {

            // If pointer is invalid then skip the ACTION_MOVE.

            ...

        } else {

            // Check to see if any pointer is now over a draggable view.

            final int pointerCount = ev.getPointerCount();

            for (int i = 0; i < pointerCount; i++) {

                final int pointerId = ev.getPointerId(i);



                // If pointer is invalid then skip the ACTION_MOVE.

                if (!isValidPointerForActionMove(pointerId)) continue;



                final float x = ev.getX(i);

                final float y = ev.getY(i);

                final float dx = x - mInitialMotionX[pointerId];

                final float dy = y - mInitialMotionY[pointerId];



                reportNewEdgeDrags(dx, dy, pointerId);

                if (mDragState == STATE_DRAGGING) {

                    // Callback might have started an edge drag.

                    break;

                }



                final View toCapture = findTopChildUnder((int) x, (int) y);

                if (checkTouchSlop(toCapture, dx, dy)

                        && tryCaptureViewForDrag(toCapture, pointerId)) {

                    break;

                }

            }

            saveLastMotion(ev);

        }

        break;

    }

复制代码

    case MotionEvent.ACTION_POINTER_UP: {

        final int pointerId = ev.getPointerId(actionIndex);

        // 判断当前触摸点是否是正在拖动视图的触摸点

        if (mDragState == STATE_DRAGGING && pointerId == mActivePointerId) {

            // 检查是否有其他有效触摸点

            int newActivePointer = INVALID_POINTER;

            final int pointerCount = ev.getPointerCount();

            // 遍历ev内触摸点

            for (int i = 0; i < pointerCount; i++) {

                final int id = ev.getPointerId(i);

                if (id == mActivePointerId) {

                    // This one's going away, skip.

                    continue;

                }



                final float x = ev.getX(i);

                final float y = ev.getY(i);

                // 如果在视图上，并且可拖动，则标记找到了

                if (findTopChildUnder((int) x, (int) y) == mCapturedView

                        && tryCaptureViewForDrag(mCapturedView, id)) {

                    newActivePointer = mActivePointerId;

                    break;

                }

            }



            if (newActivePointer == INVALID_POINTER) {

                // 如果没有发现其他触摸点在拖拽视图view，则释放掉就可以了

                releaseViewForPointerUp();

            }

        }

        // 清理当前up掉的触摸点数据

        clearMotionHistory(pointerId);

        break;

    }

复制代码

    case MotionEvent.ACTION_UP: {

        if (mDragState == STATE_DRAGGING) {

            releaseViewForPointerUp();

        }

        cancel();

        break;

    }

复制代码

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