APP自动增量更新

抽取的Android自动更新库,目的是几行代码引入更新功能,含服务端代码,欢迎Star，欢迎Fork，谢谢～

目录

• 功能介绍
• 流程图
• 效果图与示例apk
• 如何引入
• 更新清单文件
• 简单使用
• 详细说明
• 差分包生成(服务端)
• 依赖
• License

功能介绍

•  支持全量更新apk,直接升级到最新版本
•  支持增量更新,只下载补丁包升级
•  设置仅在wifi环境下更新
•  支持外部注入网络框架(库默认使用okhttp)
•  支持前台或后台自动更新
•  支持基于版本的强制更新
•  支持对外定制更新提示和更新进度界面
•  含发布功能后台服务端github (Node.js实现)

流程图

效果图与示例apk

如何引入

Gradle引入

step 1

Add the JitPack repository to your build file

allprojects {
    repositories {
        ...
        maven { url 'https://jitpack.io' }
    }
}
dependencies {
    implementation 'com.github.itlwy:AppSmartUpdate:v1.0.7'
}

Step 2

Add the dependency

更新清单文件

该清单放置在静态服务器以供App访问，主要用于判断最新的版本，及要更新的版本资源信息等(示例见仓库根目录下的resources目录或直接访问后台代码 github)，清单由服务端程序发布apk时生成，详见后台示例:github

{
  "minVersion": 100, // app最低支持的版本代码(包含),低于此数值的app将强制更新
  "minAllowPatchVersion": 100, // 最低支持的差分版本(包含),低于此数值的app将采取全量更新,否则采用差量
  "newVersion": 101, // 当前最新版本代码
  "tip": "test update",	// 更新提示
  "size": 1956631,	// 最新apk文件大小
  "apkURL": "https://raw.githubusercontent.com/itlwy/AppSmartUpdate/master/resources/app/smart-update.apk", // 最新apk 绝对url地址，也可用相对地址，如下方的"patchURL"字段
  "hash": "ea97c8efa490a2eaf7d10b37e63dab0e", // 最新apk文件的md5值
  "patchInfo": {  // 差分包信息
    "v100": { // v100表示-版本代码100的apk需要下载的差分包
      "patchURL": "v100/100to101.patch", //差分包地址，相对此UpdateManifest.json文件的地址,也可用绝对地址
      "tip": "101 version", // 提示
      "hash": "ea97c8efa490a2eaf7d10b37e63dab0e", // 合成后apk(即版本代码101)的文件md5值
      "size": 1114810 // 差分包大小
    }
  }
}

简单使用

1.初始化

public class MyApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        //推荐在Application中初始化
        Config config = new Config.Builder()
                .isDebug(true)
                .build(this);
        UpdateManager.getInstance().init(config);
    }
}

2.调用

public class MainActivity extends AppCompatActivity implements View.OnClickListener {
 private Button mUpdateBtn;
    private String manifestJsonUrl = "https://raw.githubusercontent.com/itlwy/AppSmartUpdate/master/resources/UpdateManifest.json";
    private IUpdateCallback mCallback;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mUpdateBtn = (Button) findViewById(R.id.update_btn);
        mUpdateBtn.setOnClickListener(this);

    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.update_btn:
                UpdateManager.getInstance().update(this, manifestJsonUrl, null);
                break;

        }
    }
}

详细说明

注册通知回调

• 其他activity界面需要获知后台更新情况

public void register(IUpdateCallback callback) {...}

public void unRegister(IUpdateCallback callback) {...}

public interface IUpdateCallback {

    /**
     * 通知无新版本需要更新,运行在主线程
     */
    void noNewApp();

    /**
     * 自动更新准备开始时回调,运行在主线程，可做一些提示等
     */
    void beforeUpdate();

    /**
     * 自动更新的进度回调（分增量和全量更新）,运行在主线程
     *
     * @param percent     当前总进度百分比
     * @param totalLength 更新总大小(全量为apk大小,增量为全部补丁大小和)
     * @param patchIndex  当前更新的补丁索引(从1开始)
     * @param patchCount  需要更新的总补丁数(当为0时表示是增量更新)
     */
    void onProgress(int percent, long totalLength, int patchIndex, int patchCount);

    /**
     * 下载完成，准备更新,运行在主线程
     */
    void onCompleted();

    /**
     * 异常回调,运行在主线程
     *
     * @param error 异常信息
     */
    void onError(String error);

    /**
     * 用户取消了询问更新对话框
     */
    void onCancelUpdate();

    /**
     * 取消了更新进度对话框,压入后台自动更新,此时由通知栏通知进度
     */
    void onBackgroundTrigger();
}

网络框架注入

默认使用okhttp，也可由外部注入,只需实现如下的IHttpManager接口,然后通过new Config.Builder().httpManager(new OkhttpManager())注入即可

public interface IHttpManager {


    IResponse syncGet(@NonNull String url, @NonNull Map<String, String> params) throws IOException;

    /**
     * 异步get
     *
     * @param url      get请求地址
     * @param params   get参数
     * @param callBack 回调
     */
    void asyncGet(@NonNull String url, @NonNull Map<String, String> params, @NonNull Callback callBack);


    /**
     * 异步post
     *
     * @param url      post请求地址
     * @param params   post请求参数
     * @param callBack 回调
     */
    void asyncPost(@NonNull String url, @NonNull Map<String, String> params, @NonNull Callback callBack);

    /**
     * 下载
     *
     * @param url      下载地址
     * @param path     文件保存路径
     * @param fileName 文件名称
     * @param callback 回调
     */
    void download(@NonNull String url, @NonNull String path, @NonNull String fileName, @NonNull FileCallback callback);
}

定制更新交互界面

每个应用的风格都可能是不一样的，因此这里也支持自定义弹出的提示框和进度框，详细见如下代码示例：

1. 初始化config时需要将内部默认的弹框屏蔽掉

public class MyApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
         Config config = new Config.Builder()
                .isShowInternalDialog(false)
                .build(this);
        UpdateManager.getInstance().init(config);
    }
}

1. 自定义对话框，如下(详细代码在MainActivity.java里)：

public void registerUpdateCallbak() {
        mCallback = new IUpdateCallback() {
            @Override
            public void noNewApp() {
                Toast.makeText(MainActivity.this, "当前已是最新版本!", Toast.LENGTH_LONG).show();
            }

            @Override
            public void hasNewApp(AppUpdateModel appUpdateModel, UpdateManager updateManager, final int updateMethod) {
                AlertDialog.Builder builder = new AlertDialog.Builder(MainActivity.this);
                mDialog = builder.setTitle("自动更新提示")
                        .setMessage(appUpdateModel.getTip())
                        .setPositiveButton("更新", new DialogInterface.OnClickListener() {
                            @Override
                            public void onClick(DialogInterface dialog, int which) {
                                UpdateManager.getInstance().startUpdate(updateMethod);
                            }
                        })
                        .setNegativeButton("取消", new DialogInterface.OnClickListener() {
                            @Override
                            public void onClick(DialogInterface dialog, int which) {

                            }
                        }).create();
                mDialog.show();
            }

            @Override
            public void beforeUpdate() {
                // 更新开始
                mProgressDialog = new ProgressDialog(MainActivity.this);
                mProgressDialog.setTitle("更新中...");
                mProgressDialog.setProgressStyle(ProgressDialog.STYLE_HORIZONTAL);
                mProgressDialog.setMessage("正在玩命更新中...");
                mProgressDialog.setMax(100);
                mProgressDialog.setProgress(0);
                mProgressDialog.setOnCancelListener(new DialogInterface.OnCancelListener() {
                    @Override
                    public void onCancel(DialogInterface dialog) {
                        // 退到后台自动更新，进度由通知栏显示
                        if (UpdateManager.getInstance().isRunning()) {
                            UpdateManager.getInstance().onBackgroundTrigger();
                        }
                    }
                });
                mProgressDialog.show();
            }

            @Override
            public void onProgress(int percent, long totalLength, int patchIndex, int patchCount) {
                String tip;
                if (patchCount > 0) {
                    tip = String.format("正在下载补丁%d/%d", patchIndex, patchCount);
                } else {
                    tip = "正在下载更新中...";
                }
                mProgressDialog.setProgress(percent);
                mProgressDialog.setMessage(tip);
            }

            @Override
            public void onCompleted() {
                mProgressDialog.dismiss();
            }

            @Override
            public void onError(String error) {
                Toast.makeText(MainActivity.this, error, Toast.LENGTH_LONG).show();
                mProgressDialog.dismiss();
            }

            @Override
            public void onCancelUpdate() {

            }

            @Override
            public void onBackgroundTrigger() {
                Toast.makeText(MainActivity.this, "转为后台更新，进度由通知栏提示!", Toast.LENGTH_LONG).show();
            }
        };
        UpdateManager.getInstance().register(mCallback);
    }

差分包合成(jni)

此部分采用的差分工具为开源bsdiff，用于生成.patch补丁文件，采用jni方式封装一个.so库供java调用，详见"smartupdate"库里的main/cpp目录源码，过程比较简单，就是写个jni的方法来直接调用bsdiff库，目录结构如下：

main

    -cpp

        -bzip2

	-CMakeLists.txt

	-patchUtils.c

	-patchUtils.h

	-update-lib.cpp

因为bsdiff还依赖了bzip2，所以这里涉及多个源文件编译链接问题，需要在CMakeLists.txt稍作修改：

# 将当前 "./src/main/cpp" 目录下的所有源文件保存到 "NATIVE_SRC" 中，然后在 add_library 方法调用。
aux_source_directory( . NATIVE_SRC )
# 将 "./src/main/cpp/bzip2" 目录下的子目录bzip2保存到 "BZIP2_BASE" 中，然后在 add_library 方法调用。
aux_source_directory( ./bzip2 BZIP2_BASE )
# 将 BZIP2_BASE 增加到 NATIVE_SRC 中，这样目录的源文件也加入了编译列表中，当然也可以不加到 NATIVE_SRC，直接调用add_library。
list(APPEND NATIVE_SRC ${BZIP2_BASE})

add_library( # Sets the name of the library.
        update-lib
        # Sets the library as a shared library.
        SHARED
        # Provides a relative path to your source file(s).
        ${NATIVE_SRC})

差分包生成

服务端见github ，使用时将manifestJsonUrl改成部署的服务器地址即可，如下示例代码片段的注释处

public class MainActivity extends AppCompatActivity {
    private String manifestJsonUrl = "https://raw.githubusercontent.com/itlwy/AppSmartUpdate/master/resources/UpdateManifest.json";
//    private String manifestJsonUrl = "http://192.168.2.107:8000/app/UpdateManifest.json";
    ...
}

依赖

• okhttp : com.squareup.okhttp3:okhttp:3.11.0
• gson : com.google.code.gson:gson:2.8.0

说明

在介绍二维码的优化前，可以参考二维码基础原理了解二维码识别的相关知识。 作者相关博客Android二维码扫描优化

Contents 目录

• 概述
• 普通优化
  • 解码优化
  • 优化相机设置
• 难点
  • 灰色
  • 角度
  • 光照
• 优化
  • 尝试1
  • 尝试2
  • 尝试3
• 项目说明

概述

随着二维码的流行，几乎所有手持设备都支持二维码的扫描识别。对于大部分普通的情景下，使用zxing和zbar就可以很好的完成二维码的识别，但是如果碰到一些特殊的情景，zxing和zbar的识别率并不高。这些特殊的情景包括：

1. 二维码是灰色的
2. 大角度斜扫二维码
3. 由光源引发的摄像头干扰，比如手机扫描屏幕上的二维码会出现条纹或者噪点

普通优化

在介绍难点优化之前，先介绍网上常见的优化点。这些优化点同样被使用在了作者的项目中，具体包括：

解码优化

1. 减少解码格式
2. 解码算法优化
3. 减少解码数据
4. 解码库Zbar与Zxing融合

优化相机设置

1. 选择最佳预览尺寸/图片尺寸
2. 设置适合的相机放大倍数
3. 调整聚焦时间
4. 设置自动对焦区域
5. 调整合理扫描区域

以上普通优化均参考自智能设备上的二维码解码优化, 不过作者在实现过程中，对该链接所对应的项目实现做了一些修改，修改点包括：

1. 旋转android后置摄像头preview数据时，根据yuv NV21数据的特点进行旋转
2. 摄像头预览数据中，对应预览框的数据的截取，并非通过PlanarYUVLuminanceSource创建时提供的rect进行截取。而是通过opencv，将yuv数据转换成rgb之后，在进行截取
3. 摄像头最佳预览尺寸选取时，按照设备屏宽，屏高最接近的方式选取，并没有通过屏幕宽高比进行筛选。因为部分android手机，屏幕的宽高比和摄像头所支持最接近的size的宽高比并不一致（ps:比如nexus 4，屏幕宽高为720/1280, 但是摄像头支持的最接近屏幕宽高比的preview size，都要少几个像素，印象中，好像是 716/1276, 具体多少记不清了）
4. 支持用户双指对摄像头进行缩放，并未采用链接引用项目的zoom策略
5. 添加zbar结合zxing一起检测的代码

难点

整个二维码扫描识别过程中，个人认为最关键的一步在于图片的二值化处理。所谓二值化，可以简单理解为给定一个阈值，低于阈值的像素标记为白色，高于阈值的像素标记为黑色。一旦进行二值化后，图片形成黑白两色图，再利用二维码原理进行定位查询并识别解码并不困难。因此能否对一个图片进行正确的二值化极大影响二维码识别率。而以下特殊情况很大程度上会干扰扫描过程中二值化过程：

灰色二维码

如上图，某些二维码是灰色的，或者由于光照的情况下色调比较淡。灰色二维码识别难度在于背景往往比二维码的灰点色度更黑，当用手机对这类灰色二维码进行扫描时，总是或多或少会有一些非二维码的背景显示在扫描框中，而这部分背景由于色调比灰点深，这会造成zxing，或者zbar二值化过程中选择阈值受到干扰，从而无法识别二维码

大角度对二维码进行扫描识别

在这种情况下如果是纯黑色的二维码影响不会太大，但如果是灰色的二维码，就非常容易受到光照的印象。 由于是斜着扫二维码，那么对于摄像头来说，二维码的两边所带来的亮度是不同的。

如上图例子，如果是从左侧进行扫描二维码，那么左边由于距离摄像头更近，因此更亮，而右边由于距离摄像头更远，会比较暗，此时整个预览框进行二值化时，非常容易造成右边暗的部分，全部超过阈值而被判断为黑色，进而极大影响二维码的识别

由光源引发的摄像头干扰，比如手机扫描屏幕上的二维码会出现条纹或者噪点

如果二维码位于电脑屏幕中，或者位于其他投影设备里，或者当时处于白炽灯等灯光照耀的情况下，进行扫描，摄像头有时候会受到光源频率的干扰，从而形成条纹状。而某些情况下，当摄像头zoom到一定程度是，形成的早点也会对二维码识别造成极大干扰，如下图所示作者遇到的情况：

这类情况，如果二维码是黑色的还好，如果二维码是灰色的，则条纹会对二维码的识别起到很大的干扰，如上边右侧图像所示

优化

针对上述难点，作者尝试通过opencv对相机的preview数据进行预处理，从而提升二维码的扫描识别，作者进行过的尝试如下：

尝试1：通过opencv方法进行预览数据的降噪

作者本想通过opencv的各种降噪滤波算法(例如mediaBlur等)，去光照算法（例如RGB归一化等）等对camera预览数据进行处理。可能是作者对于opencv算法理解还不足，也可能是其他原因，测试下来效果都不太好。最好作者选择mediaBlur作为降噪算法进行保留，对于一些椒盐噪点的去除还挺有帮助

尝试2：缩小二值化阈值计算范围

考虑到灰色二维码之所以难以识别是因为背景的色调过暗，拉低了二值化阈值的计算，导致整个二维码的难以识别。因此作者将二值化阈值的计算区域缩小到预览框的2/5,然后再通过计算的阈值对整个预览区域的数据进行二值化。这个效果对于灰色二维码的识别提升很大。可惜的是，只对正面扫描的情况下有用，一旦斜着超过一定角度扫描灰色二维码，往往识别不出。

尝试3：分块对预览区进行二值化

考虑到斜扫二维码不好识别因为矩形预览区域各个部分的亮度不统一，因此作者下一步尝试是，将矩形预览框再次分成4个块，每个块取其靠近中心部分的1/5区域进行阈值计算，最后分块进行二值化后，拼接而成。具体如下示意图所示

之所以分块进行计算阈值，是考虑到不同区域的亮度是不同的，如果整体进行计算的话，会丢失部分有效信息。而之所以选取靠近中心的小部分进行阈值化计算，是因为用户行为通常会将二维码对准预览框的中心，因此中心部分，包含有效亮度信息更为精确，减少背景亮度对整体二值化的影响。这一步尝试之后，大大提升了特殊情景二维码的识别概率。至此，opencv预处理部分到此结束了。

项目说明

项目分成3个module

• app app module提供demo activity

• library_qrscan 二维码扫码核心功能，集成zxing，zbar，opencv预处理等功能

• library_opencv 该module作为隐藏module，setting配置并没有include它，是方便调试opencv功能。该module可以用于生成libProcessing.so，集成在library_qrscan module中。如果用户想使用该module，请按照以下做法：

1. 打开setting中配置，include该module
2. 下载opencv for android版本到本地目录，并解压
3. 修改library_opencv/src/main/jni/Android.mk 中 12行include对应本地opencv的mk路径
4. 删除library_qrscan/libs/armeabi-v7a/libProcessing.so

Matisse 是一个为Android精心设计的本地图像和视频选择器。你可以

• 在活动或片段中使用它

  
  

• 选择包含JPEG、PNG、GIF的图像和包含MPEG、MP4的视频

  
  

• 应用不同的主题，包括两个内置主题和自定义主题

  
  

• 不同的图像加载器

  
  

• 定义自定义筛选规则

  
  

Zhihu Style	Dracula Style	Preview

下载使用

Gradle:

repositories {

    jcenter()

}



dependencies {

    implementation 'com.zhihu.android:matisse:$latest_version'

}

混淆

如果用的是 Glide
添加规则:

-dontwarn com.squareup.picasso.**

如果用的是 Picasso 添加规则:

-dontwarn com.bumptech.glide.**

怎样使用他呢?

权限

• android.permission.READ_EXTERNAL_STORAGE
• android.permission.WRITE_EXTERNAL_STORAGE

所以，如果您的目标是android6.0+，那么您需要在下一步之前处理运行时权限请求。

Simple usage snippet

启动 MatisseActivity 从 活动的 Activity or Fragment:

Matisse.from(MainActivity.this)

        .choose(MimeType.allOf())

        .countable(true)

        .maxSelectable(9)

        .addFilter(new GifSizeFilter(320, 320, 5 * Filter.K * Filter.K))

        .gridExpectedSize(getResources().getDimensionPixelSize(R.dimen.grid_expected_size))

        .restrictOrientation(ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED)

        .thumbnailScale(0.85f)

        .imageEngine(new GlideEngine())

        .showPreview(false) // Default is `true`

        .forResult(REQUEST_CODE_CHOOSE);

主题

有两个内置的主题可以用来开始 MatisseActivity:

• R.style.Matisse_Zhihu (白天模式)
• R.style.Matisse_Dracula (夜间模式)

你也可以随心所欲地定义自己的主题。

接收结果

在 onActivityResult() 回调 Activity or Fragment:

List<Uri> mSelected;



@Override

protected void onActivityResult(int requestCode, int resultCode, Intent data) {

    super.onActivityResult(requestCode, resultCode, data);

    if (requestCode == REQUEST_CODE_CHOOSE && resultCode == RESULT_OK) {

        mSelected = Matisse.obtainResult(data);

        Log.d("Matisse", "mSelected: " + mSelected);

    }

}

github地址：https://github.com/zhihu/matisse
下载地址：matisse-master.zip

一个Android富文本类库，支持图文混排，支持编辑和预览，支持插入和删除图片。

实现的原理：

• 使用ScrollView作为最外层布局包含LineaLayout，里面填充TextView和ImageView。
• 删除的时候，根据光标的位置，删除TextView和ImageView，文本自动合并。
• 生成的数据为list集合，可自定义处理数据格式。

注意事项

• V1.4版本开放了图片点击事件接口和删除图片接口，具体使用方式可以参考后面的文档说明，也可以参考Demo实现。
• V1.6版本升级RxJava到2.2.3版本，RxAndroid到2.1.0版本。设置字体大小时需要带着单位，如app:rt_editor_text_size=”16sp”。
• V1.9.3及后续版本，xrichtext库中已去掉Glide依赖，开放接口可以自定义图片加载器。具体使用方式可以参考后面的文档说明，也可以参考Demo实现。
• Demo中图片选择器为知乎开源库Matisse，适配Android 7.0系统使用FileProvider获取图片路径。
• 开发环境更新为 AS 3.4.2 + Gradle 4.4 + compileSDK 28 + support library 28.0.0，导入项目报版本错误时，请手动修改为自己的版本。
• 请参考Demo的实现，进行了解本库。可以使用Gradle引入，也可以下载源码进行修改。
• 如有问题，欢迎提出。欢迎加入QQ群交流：745215148。

截图预览

使用方式

1. 作为module导入

把xrichtext作为一个module导入你的工程。

2. gradle依赖

allprojects {

    repositories {

        ...

        maven { url 'https://jitpack.io' }

    }

}



dependencies {

    implementation 'com.github.sendtion:XRichText:1.9.4'

}

如果出现support版本不一致问题，请排除XRichText中的support库，或者升级自己的support库为28.0.0版本。
使用方式：

implementation ('com.github.sendtion:XRichText:1.9.4') {

    exclude group: 'com.android.support'

}

具体使用

在xml布局中添加基于EditText编辑器（可编辑）

<com.sendtion.xrichtext.RichTextEditor

    android:id="@+id/et_new_content"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    app:rt_editor_text_line_space="6dp"

    app:rt_editor_image_height="500"

    app:rt_editor_image_bottom="10"

    app:rt_editor_text_init_hint="在这里输入内容"

    app:rt_editor_text_size="16sp"

    app:rt_editor_text_color="@color/grey_900"/>

在xml布局中添加基于TextView编辑器（不可编辑）

<com.sendtion.xrichtext.RichTextView

    android:id="@+id/tv_note_content"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    app:rt_view_text_line_space="6dp"

    app:rt_view_image_height="0"

    app:rt_view_image_bottom="10"

    app:rt_view_text_size="16sp"

    app:rt_view_text_color="@color/grey_900"/>

自定义属性

具体参考Demo

• RichTextView

  
  

  rt_view_image_height        图片高度，默认为0自适应，可以设置为固定数值，如500、800等
  
  rt_view_image_bottom        上下两张图片的间隔，默认10
  
  rt_view_text_size           文字大小，使用sp单位，如16sp
  
  rt_view_text_color          文字颜色，使用color资源文件
  
  rt_view_text_line_space     字体行距，跟TextView使用一样，比如6dp
  
  

• RichTextEditor

  
  

  rt_editor_image_height      图片高度，默认为500，可以设置为固定数值，如500、800等，0为自适应高度
  
  rt_editor_image_bottom      上下两张图片的间隔，默认10
  
  rt_editor_text_init_hint    默认提示文字，默认为“请输入内容”
  
  rt_editor_text_size         文字大小，使用sp单位，如16sp
  
  rt_editor_text_color        文字颜色，使用color资源文件
  
  rt_editor_text_line_space   字体行距，跟TextView使用一样，比如6dp
  
  

生成数据

我把数据保存为了html格式，生成字符串存储到了数据库。

String noteContent = getEditData();



private String getEditData() {

    List<RichTextEditor.EditData> editList = et_new_content.buildEditData();

    StringBuffer content = new StringBuffer();

    for (RichTextEditor.EditData itemData : editList) {

        if (itemData.inputStr != null) {

            content.append(itemData.inputStr);

        } else if (itemData.imagePath != null) {

            content.append("<img src=\"").append(itemData.imagePath).append("\"/>");

        }

    }

    return content.toString();

}

显示数据

et_new_content.post(new Runnable() {

     @Override

     public void run() {

         showEditData(content);

     }

 });



protected void showEditData(String content) {

    et_new_content.clearAllLayout();

    List<String> textList = StringUtils.cutStringByImgTag(content);

    for (int i = 0; i < textList.size(); i++) {

        String text = textList.get(i);

        if (text.contains("<img")) {

            String imagePath = StringUtils.getImgSrc(text);

            int width = ScreenUtils.getScreenWidth(this);

            int height = ScreenUtils.getScreenHeight(this);

            et_new_content.measure(0,0);

            Bitmap bitmap = ImageUtils.getSmallBitmap(imagePath, width, height);

            if (bitmap != null){

                et_new_content.addImageViewAtIndex(et_new_content.getLastIndex(), bitmap, imagePath);

            } else {

            et_new_content.addEditTextAtIndex(et_new_content.getLastIndex(), text);

            }

            et_new_content.addEditTextAtIndex(et_new_content.getLastIndex(), text);

        }

    }

}

图片点击事件

tv_note_content.setOnRtImageClickListener(new RichTextView.OnRtImageClickListener() {

    @Override

    public void onRtImageClick(String imagePath) {

        ArrayList<String> imageList = StringUtils.getTextFromHtml(myContent, true);

        int currentPosition = imageList.indexOf(imagePath);

        showToast("点击图片："+currentPosition+"："+imagePath);

        // TODO 点击图片预览

    }

});

图片加载器使用

请在Application中设置，经测试在首页初始化会出现问题。Demo仅供参考，具体实现根据您使用的图片加载器而变化。

XRichText.getInstance().setImageLoader(new IImageLoader() {

    @Override

    public void loadImage(String imagePath, ImageView imageView, int imageHeight) {

       //如果是网络图片

       if (imagePath.startsWith("http://") || imagePath.startsWith("https://")){

           Glide.with(getApplicationContext()).asBitmap().load(imagePath).dontAnimate()

                   .into(new SimpleTarget<Bitmap>() {

                       @Override

                       public void onResourceReady(@NonNull Bitmap resource, @Nullable Transition<? super Bitmap> transition) {

                           if (imageHeight > 0) {//固定高度

                               RelativeLayout.LayoutParams lp = new RelativeLayout.LayoutParams(

                                       FrameLayout.LayoutParams.MATCH_PARENT, imageHeight);//固定图片高度，记得设置裁剪剧中

                               lp.bottomMargin = 10;//图片的底边距

                               imageView.setLayoutParams(lp);

                               Glide.with(getApplicationContext()).asBitmap().load(imagePath).centerCrop()

                                       .placeholder(R.mipmap.img_load_fail).error(R.mipmap.img_load_fail).into(imageView);

                           } else {//自适应高度

                               Glide.with(getApplicationContext()).asBitmap().load(imagePath)

                                       .placeholder(R.mipmap.img_load_fail).error(R.mipmap.img_load_fail).into(new TransformationScale(imageView));

                           }

                       }

                   });

       } else { //如果是本地图片

           if (imageHeight > 0) {//固定高度

               RelativeLayout.LayoutParams lp = new RelativeLayout.LayoutParams(

                       FrameLayout.LayoutParams.MATCH_PARENT, imageHeight);//固定图片高度，记得设置裁剪剧中

               lp.bottomMargin = 10;//图片的底边距

               imageView.setLayoutParams(lp);



               Glide.with(getApplicationContext()).asBitmap().load(imagePath).centerCrop()

                       .placeholder(R.mipmap.img_load_fail).error(R.mipmap.img_load_fail).into(imageView);

           } else {//自适应高度

               Glide.with(getApplicationContext()).asBitmap().load(imagePath)

                       .placeholder(R.mipmap.img_load_fail).error(R.mipmap.img_load_fail).into(new TransformationScale(imageView));

           }

       }

    }

});

GitHub地址：https://github.com/sendtion/XRichText
下载地址：XRichText-master.zip

• 1.系统KVO的问题
• 2.FBKVOController优点
• 3.FBKVOController的架构设计图
• 4.FBKVOController源码详读
• 5.FBKVOController总结

一.系统KVO的问题

• 当观察者被销毁之前，需要手动移除观察者，否则会出现程序异常(向已经销毁的对象发送消息)；
• 可能会对同一个被监听的属性多次添加监听，这样我们会接收到多次监听的回调结果；
• 当观察者对多个对象的不同属性进行监听，处理监听结果时，需要在监听回调的方法中，作出大量的if判断；
• 当对同一个被监听的属性进行两次removeObserver时，会导致程序crash。这种情况通常出现在父类中有一个KVO，在父类的dealloc中remove一次，而在子类中再次remove。

二. FBKVOController优点

• 可以同时对一个对象的多个属性进行监听，写法简洁；
• 通知不会向已释放的观察者发送消息；
• 增加了block和自定义操作对NSKeyValueObserving回调的处理支持；
• 不需要在dealloc 方法中手动移除观察者，而且移除观察者不会抛出异常，当FBKVOController对象被释放时， 观察者被隐式移除；

三.FBKVOController架构设计图

四.FBKVOController源码详解

FBKVOController源码详解分四部分：

• 私有类_FBKVOInfo，
• 私有类_FBKVOSharedController
• FBKVOController，
• NSObject+FBKVOController的源码解读：

（一）FBKVOController

首先我们创建一个FBKVOController的实例对象时，有以下三种方法，一个类方法和两个对象方法，

//该方法是一个全能初始化的对象方法，其他初始化方法内部均调用该方法

//参数：observer是观察者，retainObserved：表示是否强引用被观察的对象

- (instancetype)initWithObserver:(nullable id)observer retainObserved:(BOOL)retainObserved 



//该初始化方法内部调用上一个初始化方法，默认强引用被观察的对象

- (instancetype)initWithObserver:(nullable id)observer;



//该初始化方法内部调用上一个初始化方法，默认强引用被观察的对象

+ (instancetype)controllerWithObserver:(nullable id)observer;

NS_DESIGNATED_INITIALIZER;

我们先来看全能初始化方法内部的实现，

• 该方法对三个实例变量_observer（观察者）
• _objectInfosMap（NSMapTable，被监听对象->被监听属性集合之间的映射关系）
• pthread_mutex_init（互斥锁）

//全能初始化方法

- (instancetype)initWithObserver:(nullable id)observer retainObserved:(BOOL)retainObserved

{

  self = [super init];

  if (nil != self) {



    //观察者

    _observer = observer;



//NSMapTable中的key可以为对象，而且可以对其中的key和value弱引用

NSPointerFunctionsOptions keyOptions = retainObserved ? NSPointerFunctionsStrongMemory|NSPointerFunctionsObjectPointerPersonality : NSPointerFunctionsWeakMemory|NSPointerFunctionsObjectPointerPersonality;

    _objectInfosMap = [[NSMapTable alloc] initWithKeyOptions:keyOptions valueOptions:NSPointerFunctionsStrongMemory|NSPointerFunctionsObjectPersonality capacity:0];



//对于静态分配的互斥量, 可以把它设置为PTHREAD_MUTEX_INITIALIZER

//对于动态分配的互斥量, 在申请内存(malloc)之后, 通过pthread_mutex_init进行初始化, 并且在释放内存(free)前需要调用pthread_mutex_destroy

    pthread_mutex_init(&_lock, NULL);

  }

  return self;

}

这里请先思考以下问题：

• 属性observer为何使用weak，它和哪个对象之间会导致循环引用问题，是如何导致循环引用问题的？
• 为何不使用字典来保存被监听对象和被监听属性集合之间的关系？
• NSDictionary的局限性有哪些？NSMapTable相对字典，有哪些优点？
• 互斥锁是为了保证哪些数据的线程安全？

带着这些问题我们来看FBKVOController内部是如何实现监听的，这里我们只看带Block回调的一个监听方法，其他几个方法和这个方法内部实现是相同的。下面的方法内部做了如下工作：

• 1.传入的参数keyPath，block为空时，程序闪退，同时报出误提示；
• 2.对传入参数为空的判读；
• 3.利用传入的参数创建_FBKVOInfo对象；
• 4.调用内部私有方法实现注册监听；

//观察者监听object中健值路径（keyPath）所对应属性的变化

- (void)observe:(nullable id)object keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(FBKVONotificationBlock)block

{

//NSAssert是一个预处理宏, 它可以让开发者比较便捷的捕获错误, 让程序闪退, 同时报出错误提示

  NSAssert(0 != keyPath.length && NULL != block, @"missing required parameters observe:%@ keyPath:%@ block:%p", object, keyPath, block);



//首先判断被监听的对象是否为空，被监听的健值路径是否为空，回调的block是否为空

  if (nil == object || 0 == keyPath.length || NULL == block) {

    return;

  }



  // 根据传进来的参数创建_FBKVOInfo对象，将这些参数封装到_FBKVOInfo对象中

  _FBKVOInfo *info = [[_FBKVOInfo alloc] initWithController:self keyPath:keyPath options:options block:block];



  // 监听对象object的属性信息（_FBKVOInfo对象）

  [self _observe:object info:info];

}

该私有方法内部并没有实现真正的注册监听，这里使用NSMapTable保存了被监听对象object-> _FBKVOInfo对象集合的关系，具体的监听是在_FBKVOSharedController类中实现的。观察者可以监听多个对象，而每个对象中可能有多个属性被监听

内部实现思路：

• 对当前线程访问的数据_objectInfosMap进行加锁；
• 根据被监听对象object到_objectInfosMap取出被监听的属性信息对象集合infos；
• 判断被监听的属性对象info是否存在集合中；
• 如果已经存在，则不需要再次添加监听，防止多次监听；
• 如果获取的集合infos为空，则建存放_FBKVOInfo对象的集合infos，保存映射关系：object->infos；
• 将被监听的信息_FBKVOInfo对象存到集合infos中；
• 解锁，其他线程可以访问该数据；
• 调用_FBKVOSharedController 的方法实现监听；

//该方法是内部私有方法

- (void)_observe:(id)object info:(_FBKVOInfo *)info

{

  //先加锁，访问_objectInfosMap

  pthread_mutex_lock(&_lock);



    //到_objectInfosMap中根据key(被监听的对象)获取被监听的属性信息集合

  NSMutableSet *infos = [_objectInfosMap objectForKey:object];



   //判断infos集合中是否存在被监听属性信息对象info

  _FBKVOInfo *existingInfo = [infos member:info];



    //被监听对象的属性已经存在，不需要再次监听，防止多次添加监听

  if (nil != existingInfo) {



  //解锁，其他线程可以再次访问_objectInfosMap中的数据

    pthread_mutex_unlock(&_lock);

    return;

  }



  //根据被监听对象在_objectInfosMap获取的被监听属性信息的集合为空

  if (nil == infos) {

    //懒加载创建存放_FBKVOInfo对象的set集合infos

    infos = [NSMutableSet set];



    //保存被监听对象和被监听属性信息的映射关系object->infos

    [_objectInfosMap setObject:infos forKey:object];

  }



  // 将被监听的信息_FBKVOInfo对象存到集合infos中

  [infos addObject:info];



  //解锁

  pthread_mutex_unlock(&_lock);



   //最终的监听方法是通过_FBKVOSharedController中的方法来实现

  //_FBKVOSharedController内部实现系统KVO方法

  [[_FBKVOSharedController sharedController] observe:object info:info];

}

（二）_FBKVOInfo

_FBKVOInfo私有类的内部很简单，没有任何业务逻辑，只是一个简单的Model，主要是将以下的实例变量封装到对象中，方便访问：

{

@public

//weak，防止循环引用

  __weak FBKVOController *_controller;

   //被监听属性的健值路径

  NSString *_keyPath;



//NSKeyValueObservingOptionNew：观察修改前的值

// NSKeyValueObservingOptionOld：观察修改后的值

//NSKeyValueObservingOptionInitial：观察最初的值（在注册观察服务时会调用一次触发方法）

//NSKeyValueObservingOptionPrior：分别在值修改前后触发方法（一次修改有两次触发）

  NSKeyValueObservingOptions _options;



//被监听属性值变化时的回调方法

  SEL _action;



//上下文信息（void * 任何类型）

  void *_context;

//被监听属性值变化时的回调block

  FBKVONotificationBlock _block;

//监听状态

  _FBKVOInfoState _state;

}

_FBKVOInfo私有类提供了一个全能初始化方法，来初始化以上实例变量。其他几个部分初始化方法内部均调用该全能初始化方法。

//全能初始化方法

- (instancetype)initWithController:(FBKVOController *)controller

                           keyPath:(NSString *)keyPath

                           options:(NSKeyValueObservingOptions)options

                             block:(nullable FBKVONotificationBlock)block

                            action:(nullable SEL)action

                           context:(nullable void *)context

{

  self = [super init];

  if (nil != self) {

    _controller = controller;

    _block = [block copy];

    _keyPath = [keyPath copy];

    _options = options;

    _action = action;

    _context = context;

  }

  return self;

}

优化判断对象相等性的效率：

• 1.首先判断hash值是否相等，若相等则进行第2步；若不等，则直接判断不等；hash值是对象判等的必要非充分条件；（即没它一定不行，有它不一定行）
• 2.在hash值相等的情况下，再进行对象判等, 作为判等的结果

//当重写hash方法时，我们可以将关键属性的hash值进行位或运算来作为hash值

- (NSUInteger)hash

{

  return [_keyPath hash];

}



/**

 对于基本类型, ==运算符比较的是值;

 对于对象类型, ==运算符比较的是对象的地址(即是否为同一对象)

 */

- (BOOL)isEqual:(id)object

{

    //判断对象是否为空，若为空，则不相等

  if (nil == object) {

    return NO;

  }



    //判断对象的地址是否相等，若相等，则为同一个对象（即是否为同一个对象）

  if (self == object) {

    return YES;

  }



    //判断是否是同一类型，这样可以提高判等的效率, 还可以避免隐式类型转换带来的潜在风险

  if (![object isKindOfClass:[self class]]) {

    return NO;

  }



    //对各个属性分别使用默认判等方法进行判断

    //返回所有属性判等的与结果

  return [_keyPath isEqualToString:((_FBKVOInfo *)object)->_keyPath];

}

//输出对象的调试信息

//description: 使用NSLog从控制台输出对象的信息

 //debugDescription:通过断点po打印输出对象的信息

- (NSString *)debugDescription

{

  NSMutableString *s = [NSMutableString stringWithFormat:@"<%@:%p keyPath:%@", NSStringFromClass([self class]), self, _keyPath];

  if (0 != _options) {

    [s appendFormat:@" options:%@", describe_options(_options)];

  }

  if (NULL != _action) {

    [s appendFormat:@" action:%@", NSStringFromSelector(_action)];

  }

  if (NULL != _context) {

    [s appendFormat:@" context:%p", _context];

  }

  if (NULL != _block) {

    [s appendFormat:@" block:%p", _block];

  }

  [s appendString:@">"];

  return s;

}

• 请分析如果将实例变量__weak FBKVOController *_controller前的 __weak去掉，它和_FBKVOInfo对象之间的循环引用环是如何形成的？

（三）_FBKVOSharedController

_FBKVOSharedController私有类内部实现了系统KVO的方法，用来接收和转发KVO的通知。接口中提供了监听和移除监听的方法。其接口如下：

@interface _FBKVOSharedController : NSObject



// 单例初始化方法

+ (instancetype)sharedController;



// 监听object的属性

- (void)observe:(id)object info:(nullable _FBKVOInfo *)info;



//移除对object中属性的监听

- (void)unobserve:(id)object info:(nullable _FBKVOInfo *)info;



// 移除对object中多个属性的监听

- (void)unobserve:(id)object infos:(nullable NSSet *)infos;



@end

_FBKVOSharedController私有类内部有两个私有成员变量，_infos是用来存放_FBKVOInfo对象，_infos可以对其中的成员变量弱引用，这也是为何使用NSHashTable，而不使用NSSet来存放_FBKVOInfo对象的原因。_mutex是互斥锁：

{

    //存放被监听属性的信息对象

  NSHashTable<_FBKVOInfo *> *_infos;

    //互斥锁

  pthread_mutex_t _mutex;

}

_FBKVOSharedController私有类的初始化方法，支持iOS 系统和Mac系统，初始化实例变量_infos，指定了_infos对存放在其中的成员变量弱引用，及判等性方式：

//提供全局的单例初始化方法，该单例对象的生命周期与程序的生命周期相同

+ (instancetype)sharedController

{

  static _FBKVOSharedController *_controller = nil;

  static dispatch_once_t onceToken;

  dispatch_once(&onceToken, ^{

    _controller = [[_FBKVOSharedController alloc] init];

  });

  return _controller;

}

//初始化成员变量_infos和_mutex

- (instancetype)init

{

  self = [super init];

  if (nil != self) {

    //初始化实例变量

    NSHashTable *infos = [NSHashTable alloc];



   // iOS 系统下：hashTable中的对象是弱引用，对象的判等方式：位移指针的hash值和直接判等

#ifdef __IPHONE_OS_VERSION_MIN_REQUIRED

    _infos = [infos initWithOptions:NSPointerFunctionsWeakMemory|NSPointerFunctionsObjectPointerPersonality capacity:0];



  //MAC系统下

#elif defined(__MAC_OS_X_VERSION_MIN_REQUIRED)

    if ([NSHashTable respondsToSelector:@selector(weakObjectsHashTable)]) {

      _infos = [infos initWithOptions:NSPointerFunctionsWeakMemory|NSPointerFunctionsObjectPointerPersonality capacity:0];

    } else {

      // silence deprecated warnings

#pragma clang diagnostic push

#pragma clang diagnostic ignored "-Wdeprecated-declarations"

      _infos = [infos initWithOptions:NSPointerFunctionsZeroingWeakMemory|NSPointerFunctionsObjectPointerPersonality capacity:0];

#pragma clang diagnostic pop

    }



#endif

      //初始化互斥锁

    pthread_mutex_init(&_mutex, NULL);

  }

  return self;

}



- (void)dealloc

{

    //对象被销毁时，销毁互斥锁

  pthread_mutex_destroy(&_mutex);

}

_FBKVOSharedController在这个方法中，调用系统KVO方法，将自己注册为观察者，思路如下：
1.首先将被监听的信息对象_FBKVOInfo保存到_infos中；
2.然后调用系统KVO方法将自己注册为被监听对象object的观察者；
3.最后修改监听的状态；当不再监听时，安全移除观察者；

//添加监听

- (void)observe:(id)object info:(nullable _FBKVOInfo *)info

{

    //被监听的属性信息_FBKVOInfo对象为空时，直接返回

  if (nil == info) {

    return;

  }



    // 加锁，防止多线程访问时，出现数据竞争

  pthread_mutex_lock(&_mutex);



   // 将被监听的属性信息info对象添加到_infos中，_infos对成员变量info是弱引用

  [_infos addObject:info];   



    //添加完成之后，解锁，其他线程可以访问

  pthread_mutex_unlock(&_mutex);



  // 添加监听

  [object addObserver:self forKeyPath:info->_keyPath options:info->_options context:(void *)info];



  //修改监听状态

  if (info->_state == _FBKVOInfoStateInitial) {



    info->_state = _FBKVOInfoStateObserving;



  } else if (info->_state == _FBKVOInfoStateNotObserving) {



      //不再监听时安全移除观察者

    // this could happen when `NSKeyValueObservingOptionInitial` is one of the NSKeyValueObservingOptions,

    // and the observer is unregistered within the callback block.

    // at this time the object has been registered as an observer (in Foundation KVO),

    // so we can safely unobserve it.

    [object removeObserver:self forKeyPath:info->_keyPath context:(void *)info];

  }

}

实现系统KVO监听回调的方法

//被监听属性更改时的回调

- (void)observeValueForKeyPath:(nullable NSString *)keyPath

                      ofObject:(nullable id)object

                        change:(nullable NSDictionary<NSString *, id> *)change

                       context:(nullable void *)context

{

  NSAssert(context, @"missing context keyPath:%@ object:%@ change:%@", keyPath, object, change);



  _FBKVOInfo *info;

  {

    pthread_mutex_lock(&_mutex);

  //确定_infos是否包含给定的对象context，若存在返回该对象，否则返回nil;

  //所使用的相等性比较取决于所选择的选项

  //例如，使用NSPointerFunctionsObjectPersonality选项将使用isEqual：方法来判断相等。

    info = [_infos member:(__bridge id)context];

    pthread_mutex_unlock(&_mutex);

  }



//通过上下文参数context传过来的被监听的_FBKVOInfo对象，已经存在_infos中

  if (nil != info) {



 //_FBKVOSharedController对象强引用FBKVOController对象，防止被提前释放

 //因为在_FBKVOInfo中，对FBKVOController对象是弱引用

    FBKVOController *controller = info->_controller;

    if (nil != controller) {



      //强引用观察者，在FBKVOController中，FBKVOController对象弱引用观察者observer，防止在使用时已经被释放

      id observer = controller.observer;

      if (nil != observer) {



        //使用自定义block回传监听结果

        if (info->_block) {



          NSDictionary<NSString *, id> *changeWithKeyPath = change;



          //将keyPath添加到字典中以便在观察多个keyPath时，能够清晰知道监听的是哪个keyPath

          if (keyPath) {

            NSMutableDictionary<NSString *, id> *mChange = [NSMutableDictionary dictionaryWithObject:keyPath forKey:FBKVONotificationKeyPathKey];

            [mChange addEntriesFromDictionary:change];

            changeWithKeyPath = [mChange copy];

          }

          info->_block(observer, object, changeWithKeyPath);



        } else if (info->_action) {

//使用自定义方法回传监听结果

#pragma clang diagnostic push

#pragma clang diagnostic ignored "-Warc-performSelector-leaks"

          [observer performSelector:info->_action withObject:change withObject:object];

#pragma clang diagnostic pop

        } else {

          //使用系统默认方法回传监听结果

          [observer observeValueForKeyPath:keyPath ofObject:object change:change context:info->_context];

        }

      }

    }

  }

}

_FBKVOSharedController实现了移除观察者的方法，思路如下：

• 1.首先从_infos中移除被监听的属性信息对象info；
• 2.然后根据监听状态，通过调用系统的方法，移除正在被监听的属性信息对象info；
• 3.最后修改监听状态；

- (void)unobserve:(id)object info:(nullable _FBKVOInfo *)info

{

  if (nil == info) {

    return;

  }



    //先从HashTable中移除被监听的属性信息对象

  pthread_mutex_lock(&_mutex);

  [_infos removeObject:info];

  pthread_mutex_unlock(&_mutex);



  // 当正在监听时，则移除监听

  if (info->_state == _FBKVOInfoStateObserving) {

    [object removeObserver:self forKeyPath:info->_keyPath context:(void *)info];

  }

    //修改被监听的状态

  info->_state = _FBKVOInfoStateNotObserving;

}

（四）NSObject+FBKVOController

NSObject+FBKVOController 分类比较简单，它主要通过runtime方法，以懒加载的形式给 NSObject ，创建并关联一个 FBKVOController 的对象。

@interface NSObject (FBKVOController)

@property (nonatomic, strong) FBKVOController *KVOController;

@property (nonatomic, strong) FBKVOController *KVOControllerNonRetaining;

@end

五.FBKVOController总结

FBKVOController是线程安全的，相对于系统的KVO而言，使用起来更方便，安全，简洁。

• 1.NSHashTable和NSMapTable的使用；
• 2.互斥锁pthread_mutex_t的使用
• 3.FBKVOController和Observer之间循环引用的形成和解决；
• 4.FBKVOController和_FBKVOInfo之间循环引用的形成和解决；

作者：Cooci

链接：https://www.jianshu.com/p/65e345a7aa21

 NSOperationQueue 控制串行执行、并发执行

NSOperationQueue 创建的自定义队列同时具有串行、并发功能，那么他的串行功能是如何实现的？

这里有个关键属性 maxConcurrentOperationCount，叫做最大并发操作数。用来控制一个特定队列中可以有多少个操作同时参与并发执行。

注意：这里 maxConcurrentOperationCount 控制的不是并发线程的数量，而是一个队列中同时能并发执行的最大操作数。而且一个操作也并非只能在一个线程中运行。

/**

 * 设置 MaxConcurrentOperationCount（最大并发操作数）

 */

- (void)setMaxConcurrentOperationCount {



    // 1.创建队列

    NSOperationQueue *queue = [[NSOperationQueue alloc] init];



    // 2.设置最大并发操作数

    queue.maxConcurrentOperationCount = 1; // 串行队列

// queue.maxConcurrentOperationCount = 2; // 并发队列

// queue.maxConcurrentOperationCount = 8; // 并发队列



    // 3.添加操作

    [queue addOperationWithBlock:^{

        for (int i = 0; i < 2; i++) {

            [NSThread sleepForTimeInterval:2]; // 模拟耗时操作

            NSLog(@"1---%@", [NSThread currentThread]); // 打印当前线程

        }

    }];

    [queue addOperationWithBlock:^{

        for (int i = 0; i < 2; i++) {

            [NSThread sleepForTimeInterval:2]; // 模拟耗时操作

            NSLog(@"2---%@", [NSThread currentThread]); // 打印当前线程

        }

    }];

    [queue addOperationWithBlock:^{

        for (int i = 0; i < 2; i++) {

            [NSThread sleepForTimeInterval:2]; // 模拟耗时操作

            NSLog(@"3---%@", [NSThread currentThread]); // 打印当前线程

        }

    }];

    [queue addOperationWithBlock:^{

        for (int i = 0; i < 2; i++) {

            [NSThread sleepForTimeInterval:2]; // 模拟耗时操作

            NSLog(@"4---%@", [NSThread currentThread]); // 打印当前线程

        }

    }];

}

/**

 * 操作依赖

 * 使用方法：addDependency:

 */

- (void)addDependency {



    // 1.创建队列

    NSOperationQueue *queue = [[NSOperationQueue alloc] init];



    // 2.创建操作

    NSBlockOperation *op1 = [NSBlockOperation blockOperationWithBlock:^{

        for (int i = 0; i < 2; i++) {

            [NSThread sleepForTimeInterval:2]; // 模拟耗时操作

            NSLog(@"1---%@", [NSThread currentThread]); // 打印当前线程

        }

    }];

    NSBlockOperation *op2 = [NSBlockOperation blockOperationWithBlock:^{

        for (int i = 0; i < 2; i++) {

            [NSThread sleepForTimeInterval:2]; // 模拟耗时操作

            NSLog(@"2---%@", [NSThread currentThread]); // 打印当前线程

        }

    }];



    // 3.添加依赖

    [op2 addDependency:op1]; // 让op2 依赖于 op1，则先执行op1，在执行op2



    // 4.添加操作到队列中

    [queue addOperation:op1];

    [queue addOperation:op2];

}

// 优先级的取值

typedef NS_ENUM(NSInteger, NSOperationQueuePriority) {

    NSOperationQueuePriorityVeryLow = -8L,

    NSOperationQueuePriorityLow = -4L,

    NSOperationQueuePriorityNormal = 0,

    NSOperationQueuePriorityHigh = 4,

    NSOperationQueuePriorityVeryHigh = 8

};

/**

 * 线程间通信

 */

- (void)communication {



    // 1.创建队列

    NSOperationQueue *queue = [[NSOperationQueue alloc]init];



    // 2.添加操作

    [queue addOperationWithBlock:^{

        // 异步进行耗时操作

        for (int i = 0; i < 2; i++) {

            [NSThread sleepForTimeInterval:2]; // 模拟耗时操作

            NSLog(@"1---%@", [NSThread currentThread]); // 打印当前线程

        }



        // 回到主线程

        [[NSOperationQueue mainQueue] addOperationWithBlock:^{

            // 进行一些 UI 刷新等操作

            for (int i = 0; i < 2; i++) {

                [NSThread sleepForTimeInterval:2]; // 模拟耗时操作

                NSLog(@"2---%@", [NSThread currentThread]); // 打印当前线程

            }

        }];

    }];

}

/**

 * 非线程安全：不使用 NSLock

 * 初始化火车票数量、卖票窗口(非线程安全)、并开始卖票

 */

- (void)initTicketStatusNotSave {

    NSLog(@"currentThread---%@",[NSThread currentThread]); // 打印当前线程



    self.ticketSurplusCount = 50;



    // 1.创建 queue1,queue1 代表北京火车票售卖窗口

    NSOperationQueue *queue1 = [[NSOperationQueue alloc] init];

    queue1.maxConcurrentOperationCount = 1;



    // 2.创建 queue2,queue2 代表上海火车票售卖窗口

    NSOperationQueue *queue2 = [[NSOperationQueue alloc] init];

    queue2.maxConcurrentOperationCount = 1;



    // 3.创建卖票操作 op1

    NSBlockOperation *op1 = [NSBlockOperation blockOperationWithBlock:^{

        [self saleTicketNotSafe];

    }];



    // 4.创建卖票操作 op2

    NSBlockOperation *op2 = [NSBlockOperation blockOperationWithBlock:^{

        [self saleTicketNotSafe];

    }];



    // 5.添加操作，开始卖票

    [queue1 addOperation:op1];

    [queue2 addOperation:op2];

}



/**

 * 售卖火车票(非线程安全)

 */

- (void)saleTicketNotSafe {

    while (1) {



        if (self.ticketSurplusCount > 0) {

            //如果还有票，继续售卖

            self.ticketSurplusCount--;

            NSLog(@"%@", [NSString stringWithFormat:@"剩余票数:%d 窗口:%@", self.ticketSurplusCount, [NSThread currentThread]]);

            [NSThread sleepForTimeInterval:0.2];

        } else {

            NSLog(@"所有火车票均已售完");

            break;

        }

    }

}

/**

 * 线程安全：使用 NSLock 加锁

 * 初始化火车票数量、卖票窗口(线程安全)、并开始卖票

 */



- (void)initTicketStatusSave {

    NSLog(@"currentThread---%@",[NSThread currentThread]); // 打印当前线程



    self.ticketSurplusCount = 50;



    self.lock = [[NSLock alloc] init];  // 初始化 NSLock 对象



    // 1.创建 queue1,queue1 代表北京火车票售卖窗口

    NSOperationQueue *queue1 = [[NSOperationQueue alloc] init];

    queue1.maxConcurrentOperationCount = 1;



    // 2.创建 queue2,queue2 代表上海火车票售卖窗口

    NSOperationQueue *queue2 = [[NSOperationQueue alloc] init];

    queue2.maxConcurrentOperationCount = 1;



    // 3.创建卖票操作 op1

    NSBlockOperation *op1 = [NSBlockOperation blockOperationWithBlock:^{

        [self saleTicketSafe];

    }];



    // 4.创建卖票操作 op2

    NSBlockOperation *op2 = [NSBlockOperation blockOperationWithBlock:^{

        [self saleTicketSafe];

    }];



    // 5.添加操作，开始卖票

    [queue1 addOperation:op1];

    [queue2 addOperation:op2];

}



/**

 * 售卖火车票(线程安全)

 */

- (void)saleTicketSafe {

    while (1) {



        // 加锁

        [self.lock lock];



        if (self.ticketSurplusCount > 0) {

            //如果还有票，继续售卖

            self.ticketSurplusCount--;

            NSLog(@"%@", [NSString stringWithFormat:@"剩余票数:%d 窗口:%@", self.ticketSurplusCount, [NSThread currentThread]]);

            [NSThread sleepForTimeInterval:0.2];

        }



        // 解锁

        [self.lock unlock];



        if (self.ticketSurplusCount <= 0) {

            NSLog(@"所有火车票均已售完");

            break;

        }

    }

}

📝缓存Cache

缓存是以键值对的形式进行数据的存储和检索，内部采用哈希表实现。当系统出现内存压力时则会释放掉部分缓存的键值对。 iOS系统提供了一套基于OC语言的高级缓存库NSCache，同时也提供一套基于C语言实现的缓存库libcache.dylib，其中NSCache是基于libcache.dylib实现的高级类库，并且这两个库都是线程安全的。 本文主要介绍基于C语言的缓存库的各种API函数。

头文件： #include <cache.h>, #include <cache_callbacks.h>
平台： iOS系统

一、缓存对象的创建和关闭

功能：创建或者销毁一个缓存对象。

函数签名：

int cache_create(const char *name, cache_attributes_t *attrs, cache_t **cache_out);
int cache_destroy(cache_t *cache);

参数：

name:[in] 创建缓存时用来指定缓存的字符串名称，不能为空。
attrs: [in] 设置缓存的属性。不能为空。
cache_out: [out] 返回创建的缓存对象。
return: [out] 成功操作返回0，否则返回非0

描述:

缓存对象是一个容器对象，其缓存的内容是一个个键值对，至于这些键值对是什么类型的数据，如何控制键值对的数据的生命周期，如何判断两个键是否是相同的键等等这些信息缓存对象本身是无法得知，因此需要我们明确的告诉缓存对象如何去操作这些键值信息。这也就是为什么在创建缓存对象时需要指定属性这个参数了。属性的参数类型是一个cache_attributes_t结构体。这个结构体的大部分数据成员都是函数指针，这些函数指针就是用来实现对键值进行操作的各种策略。

struct cache_attributes_s {
    uint32_t version;  //缓存对象的版本信息
    cache_key_hash_cb_t key_hash_cb;  //对键执行hash计算的函数，不能为空                         
    cache_key_is_equal_cb_t key_is_equal_cb;  //判断两个键是否相等的函数，不能为空                      
    
    cache_key_retain_cb_t  key_retain_cb;   //键加入缓存时调用，用于增加键的引用计数或者进行内存拷贝。
    cache_release_cb_t key_release_cb;  //键的释放处理函数，用于对键的内存管理使用。
    cache_release_cb_t value_release_cb;  //值的释放处理函数，用于对值的内存管理使用。                         
    
    cache_value_make_nonpurgeable_cb_t value_make_nonpurgeable_cb;   //当值的引用计数从0变为1时对值内存进行非purgeable的处理函数。
    cache_value_make_purgeable_cb_t value_make_purgeable_cb;  //当值的引用计数变为0时对值进行purgeable的处理函数。这个函数的作用是为了解决当内存吃紧时自动释放所分配的内存。    
    
    void *user_data;  //附加数据，这个附加数据会在所有的这些回调函数中出现。

    // Added in CACHE_ATTRIBUTES_VERSION_2
    cache_value_retain_cb_t value_retain_cb;   //值增加引用计数的函数，用于对值的内存管理使用。
};
typedef struct cache_attributes_s cache_attributes_t;

上述的各种回调函数的格式都在cache.h中有明确的定义，因此这里就不再展开介绍了。一般情况下我们通常都会将字符串或者整数来作为键使用，因此当你采用字符串或者整数作为键时，系统预置了一系列缓存对象属性的默认实现函数。这些函数的声明在cache_callbacks.h文件中

/*
 * Pre-defined callback functions.
 */

//用于键进行哈希计算的预置函数
CACHE_PUBLIC_API uintptr_t cache_key_hash_cb_cstring(void *key, void *unused);
CACHE_PUBLIC_API uintptr_t cache_key_hash_cb_integer(void *key, void *unused);
//用于键进行相等比较的预置函数
CACHE_PUBLIC_API bool cache_key_is_equal_cb_cstring(void *key1, void *key2, void *unused);
CACHE_PUBLIC_API bool cache_key_is_equal_cb_integer(void *key1, void *key2, void *unused);

//键值进行释放的函数，这函数默认实现就是调用free函数，因此如果采用这个函数进行释放处理则键值需要从堆中进行内存分配。
CACHE_PUBLIC_API void cache_release_cb_free(void *key_or_value, void *unused);

 //对值进行purgeable处理的预置函数。
CACHE_PUBLIC_API void cache_value_make_purgeable_cb(void *value, void *unused);
CACHE_PUBLIC_API bool cache_value_make_nonpurgeable_cb(void *value, void *unused);

示例代码：

//下面代码用于创建一个以字符串为键的缓存对象，其中的缓存对象的属性中的各个成员函数采用的是系统默认预定的函数。
 #include <cache.h>
 #include <cache_callbcaks.h>

 cache_t *im_cache;
 cache_attributes_t attrs = {
         .version = CACHE_ATTRIBUTES_VERSION_2,
         .key_hash_cb = cache_key_hash_cb_cstring,
         .key_is_equal_cb = cache_key_is_equal_cb_cstring,
         .key_retain_cb = my_copy_string,
         .key_release_cb = cache_release_cb_free,
         .value_release_cb = cache_release_cb_free,
  };
  cache_create("com.acme.im_cache", &attrs, &im_cache);

二、缓存对象中键值对的设置和获取以及删除

功能：用于处理键值对在缓存中的添加、获取和删除操作。
函数签名:

//将键值对添加到缓存，或者替换掉原有的键值对。
 int cache_set_and_retain(cache_t *cache, void *key, void *value, size_t cost);

//从缓存中根据键获取值
int cache_get_and_retain(cache_t *cache, void *key, void **value_out);

//将缓存中的值引用计数减1，当引用计数为0时则清理值分配的内存或者销毁值分配的内存。
int cache_release_value(cache_t *cache, void *value);

//从缓存中删除键值。
int cache_remove(cache_t *cache, void *key);

参数：
cache:[in] 缓存对象。
key:[in] 添加或者获取或者删除时的键。
cost:[in] 添加缓存时的成本代价，值越大键值在缓存中保留的时间就越长久。
value:[in] 添加时的值。
value_out: [out] 用于值获取时的输出。

描述：
1、cache_set_and_retain 函数用于将键值对放入缓存中，并指定cost值。当将一个键添加到缓存时，系统内部分别会调用缓存属性cache_attributes_t结构体中的key_retain_cb来实现对键的内存的管理，如果这个函数设置为NULL的话那就表明我们需要自己负责键的生命周期的管理。因为缓存对象内部是通过哈希表来进行数据的存储和检索的，所以在将键值对加入缓存时，还需要提供对键进哈希计算和比较的属性函数key_hash_cb，key_is_equal_cb。 而对于值来说，当值加入缓存时系统会将值的引用计数设置为1，如果我们想自行处理值在缓存中的内存保存则需要指定缓存属性中的value_retain_cb来实现。加入缓存中的值是可以为NULL的。最后的cost参数用于指定这个键值对的成本值，值越小在缓存中保留的时间就越少，反之亦然。

2、cache_get_and_retain函数用来根据键获取对应的值，如果缓存中没有保存对应的键值对，或者键值对被丢弃，或者值所分配的内存被清除则value_out返回NULL，并且函数返回特殊的值ENOENT。每调用一次值的获取，缓存对象都会增加值的引用计数。因此当我们不再需要访问返回的值时则需要调用手动调用cache_release_value函数来减少缓存对象中值的引用计数。而当值的引用计数变为0时则值分配的内存会设置为可清理(purgeable)或者被销毁掉。

3、cache_remove函数用于删除缓存中的键值对。当删除缓存中的键值对时，缓存对象会调用属性结构体中的key_release_cb函数进行键的内存销毁，以及如果值的引用计数变为0时则会调用value_release_cb函数进行值的内存销毁。

示例代码:

#include <cache.h>
#include <cache_callbacks.h>

void main()
{
    cache_attributes_t attr;
    attr.key_hash_cb = cache_key_hash_cb_cstring;
    attr.key_is_equal_cb = cache_key_is_equal_cb_cstring;
    attr.key_retain_cb =  NULL;
    attr.key_release_cb = cache_release_cb_free;
    attr.version = CACHE_ATTRIBUTES_VERSION_2;
    attr.user_data = NULL;
    attr.value_retain_cb = NULL;
    attr.value_release_cb = cache_release_cb_free;
    attr.value_make_purgeable_cb = cache_value_make_purgeable_cb;
    attr.value_make_nonpurgeable_cb = cache_value_make_nonpurgeable_cb;
    
    //创建缓存
    cache_t *cache = NULL;
    int ret = cache_create("com.test", &attr, &cache);
    
    //将键值对放入缓存
    char *key = malloc(4);
    strcpy(key, "key");
    char *val = malloc(4);
    strcpy(val, "val");
    ret = cache_set_and_retain(cache, key, val, 0);
    ret = cache_release_value(cache, val);
    //获取键值对，使用后要释放。
    char *val2 = NULL;
    ret = cache_get_and_retain(cache, key, (void**)&val2);
    ret = cache_release_value(cache, val2);
    
    //删除键值
    cache_remove(cache, key);
    
    //销毁缓存。
    cache_destroy(cache);
}

三、缓存中键值对的清理策略和值的访问策略

缓存的作用是会对保存在里面的键值对进行丢弃，这取决于当前内存的使用情况以及其他一些场景。在调用cache_set_and_retain将键值对添加到缓存时还会指定一个cost值，值越大被丢弃的可能性就越低。在上面的介绍中有说明缓存会对键值对中的值进行引用计数管理。当调用cache_set_and_retain时值引用计数将设置为1，调用cache_get_and_retain函数获取值时如果键值对在缓存中则会增加值的引用计数。而不需要访问和操作值时我们需要调用cache_release_value函数来将引用计数减1。当值的引用计数变为0时就会立即或者以后发生如下的事情：

1、如果我们在缓存的属性结构体中设置了value_make_purgeable_cb函数则会调用这个函数表明此时值是可以被清理的。被清理的意思是说为值分配的物理内存随时有可能会被回收。因此当值被设置为可被清理状态时就不能继续去直接访问值所分配的内存了。
2、如果在此之前键值对因为函数cache_remove的调用而被从缓存中删除，则会调用属性结构体中的value_release_cb函数来执行值内存的销毁处理。
3、如果因为系统内存的压力导致需要丢弃缓存中的键值对时，就会把值引用计数为0的键值对丢弃掉！注意：只有值引用计数为0时才会缓存被丢弃。

每次对缓存中的值的访问都需要通过cache_get_and_retain函数来执行，当调用cache_get_and_retain函数时会发生如下事情：

1、判断当前键值对是否在缓存中，如果不再则值返回NULL。
2、如果键值对在缓存中。并且值的引用计数为0，就会判断缓存的结构体属性中是否存在value_make_nonpurgeable_cb函数，如果存在则会调用value_make_nonpurgeable_cb函数将值的内存设置为不可清理，如果设置为不可清理返回为false则表明此时值的内存已经被清理了，这时候键值对将会从缓存中丢弃，并且cache_get_and_retain函数将返回值为NULL。当然如果value_make_nonpurgeable_cb函数为空则不会发生这一步。
3、增加值的引用计数，并返回值。

链接：https://www.jianshu.com/p/2f58f165bf1a

操作在底层会被编译为汇编代码之后不止一条指令，因此在执行的时候可能执行了一半就被调度系统打断，去执行别的代码，而我们的原子性的单条指令的执行是不会被打断的，所以保证了安全.

let sem = DispatchSemaphore(value: 1)

    

for index in 1...5 {

    DispatchQueue.global().async {

        sem.wait()

        print(index,Thread.current)

        sem.signal()

    }

}



输出结果：

1 <NSThread: 0x600003fa8200>{number = 3, name = (null)}

2 <NSThread: 0x600003f90140>{number = 4, name = (null)}

3 <NSThread: 0x600003f94200>{number = 5, name = (null)}

4 <NSThread: 0x600003fa0940>{number = 6, name = (null)}

5 <NSThread: 0x600003f94240>{number = 7, name = (null)}

int main(int argc, const char * argv[]) {

    NSString *obj = @"Iceberg";

    @synchronized(obj) {

        NSLog(@"Hello,world! => %@" , obj);

    }

}

int main(int argc, const char * argv[]) {

    

    NSString *obj = (NSString *)&__NSConstantStringImpl__var_folders_8l_rsj0hqpj42b9jsw81mc3xv_40000gn_T_block_main_54f70c_mi_0;

    

    {

        id _rethrow = 0;

        id _sync_obj = (id)obj;

        objc_sync_enter(_sync_obj);

        try {

                struct _SYNC_EXIT {

                    _SYNC_EXIT(id arg) : sync_exit(arg) {}

                    ~_SYNC_EXIT() {

                        objc_sync_exit(sync_exit);

                    }

                    id sync_exit;

                } _sync_exit(_sync_obj);



                NSLog((NSString *)&__NSConstantStringImpl__var_folders_8l_rsj0hqpj42b9jsw81mc3xv_40000gn_T_block_main_54f70c_mi_1 , obj);

                

            } catch (id e) {

                _rethrow = e;

            }

        

        {

            struct _FIN {

                _FIN(id reth) : rethrow(reth) {}

                ~_FIN() {

                    if (rethrow)

                        objc_exception_throw(rethrow);

                }

                id rethrow;

            } _fin_force_rethow(_rethrow);

        }

    }



}

int objc_sync_enter(id obj)

 {

  int result = OBJC_SYNC_SUCCESS;

 

  if (obj) {

  SyncData* data = id2data(obj, ACQUIRE);

  require_action_string(data != NULL, done, result = OBJC_SYNC_NOT_INITIALIZED, "id2data failed");

   

  result = recursive_mutex_lock(&data->mutex);

  require_noerr_string(result, done, "mutex_lock failed");

  } else {

  // @synchronized(nil) does nothing

  if (DebugNilSync) {

  _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");

  }

  objc_sync_nil();

  }

 

 done: 

  return result;

 }

NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

   

    static void (^RecursiveBlock)(int);

    RecursiveBlock = ^(int value) {

        [lock lock];

        if (value > 0) {

            NSLog(@"value:%d", value);

            RecursiveBlock(value - 1);

        }

        [lock unlock];

    };

    RecursiveBlock(2);

});



2016-08-19 14:43:12.327 ThreadLockControlDemo[1878:145003] value:2

2016-08-19 14:43:12.327 ThreadLockControlDemo[1878:145003] value:1

- (void) signal { 

    pthread_cond_signal(&_condition); 

} 

// 其实这个函数是通过宏来定义的，展开后就是这样 

- (void) lock { 

    int err = pthread_mutex_lock(&_mutex); 

}

// 简化版代码

- (id) initWithCondition: (NSInteger)value {

    if (nil != (self = [super init])) {

        _condition = [NSCondition new]

        _condition_value = value;

    }

    return self;

}

// 临界区结构对象

CRITICAL_SECTION g_cs;

// 共享资源

char g_cArray[10];

UINT ThreadProc10(LPVOID pParam)

{

    // 进入临界区

    EnterCriticalSection(&g_cs);

    // 对共享资源进行写入操作

    for (int i = 0; i < 10; i++)

    {

    g_cArray[i]  = a;

    Sleep(1);

    }

    // 离开临界区

    LeaveCriticalSection(&g_cs);

    return 0;

}

UINT ThreadProc11(LPVOID pParam)

{

    // 进入临界区

    EnterCriticalSection(&g_cs);

    // 对共享资源进行写入操作

    for (int i = 0; i < 10; i++)

    {

        g_cArray[10 - i - 1] = b;

        Sleep(1);

    }

    // 离开临界区

    LeaveCriticalSection(&g_cs);

    return 0;

}

……

void CSample08View::OnCriticalSection()

{

    // 初始化临界区

    InitializeCriticalSection(&g_cs);

    // 启动线程

    AfxBeginThread(ThreadProc10, NULL);

    AfxBeginThread(ThreadProc11, NULL);

    // 等待计算完毕

    Sleep(300);

    // 报告计算结果

    CString sResult = CString(g_cArray);

    AfxMessageBox(sResult);

}

int pthread_rwlock_rdlock(pthread_rwlock_t *rwptr);

int pthread_rwlock_wrlock(pthread_rwlock_t *rwptr);

int pthread_rwlock_unlock(pthread_rwlock_t *rwptr);

ReadWriteLock管理一组锁，一个是只读的锁，一个是写锁。读锁可以在没有写锁的时候被多个线程同时持有，写锁是独占的。

#include <pthread.h>      //多线程、读写锁所需头文件

pthread_rwlock_t  rwlock = PTHREAD_RWLOCK_INITIALIZER; //定义和初始化读写锁

 

写模式：

pthread_rwlock_wrlock(&rwlock);     //加写锁

写写写……

pthread_rwlock_unlock(&rwlock);     //解锁  



读模式：

pthread_rwlock_rdlock(&rwlock);      //加读锁

读读读……

pthread_rwlock_unlock(&rwlock);     //解锁 

• 用条件变量实现读写锁

这里用条件变量+互斥锁来实现。注意：条件变量必须和互斥锁一起使用，等待、释放的时候都需要加锁。

#include <pthread.h> //多线程、互斥锁所需头文件

 

pthread_mutex_t  mutex = PTHREAD_MUTEX_INITIALIZER;      //定义和初始化互斥锁

pthread_cond_t  cond = PTHREAD_COND_INITIALIZER;       //定义和初始化条件变量

 

 

写模式：

pthread_mutex_lock(&mutex);     //加锁

while(w != 0 || r > 0)

{

     pthread_cond_wait(&cond, &mutex);      //等待条件变量的成立

}

w = 1;

 

pthread_mutex_unlock(&mutex);

写写写……

pthread_mutex_lock(&mutex);

w = 0;

pthread_cond_broadcast(&cond);       //唤醒其他因条件变量而产生的阻塞

pthread_mutex_unlock(&mutex);    //解锁

 

 

读模式：

pthread_mutex_lock(&mutex);     

while(w != 0)

{

     pthread_cond_wait(&cond, &mutex);      //等待条件变量的成立

}

r++;

pthread_mutex_unlock(&mutex);

读读读……

pthread_mutex_lock(&mutex);

r- -;

if(r == 0)

     pthread_cond_broadcast(&cond);       //唤醒其他因条件变量而产生的阻塞

pthread_mutex_unlock(&mutex);    //解锁

• 用互斥锁实现读写锁

这里使用2个互斥锁+1个整型变量来实现

#include <pthread.h> //多线程、互斥锁所需头文件

pthread_mutex_t r_mutex = PTHREAD_MUTEX_INITIALIZER;      //定义和初始化互斥锁

pthread_mutex_t w_mutex = PTHREAD_MUTEX_INITIALIZER; 

int readers = 0;     //记录读者的个数

 

写模式：

pthread_mutex_lock(&w_mutex);

写写写……

pthread_mutex_unlock(&w_mutex);

 

 

读模式：

pthread_mutex_lock(&r_mutex);         

 

if(readers == 0)

     pthread_mutex_lock(&w_mutex);

readers++;

pthread_mutex_unlock(&r_mutex); 

读读读……

pthread_mutex_lock(&r_mutex);

readers- -;

if(reader == 0)

     pthread_mutex_unlock(&w_mutex);

pthread_mutex_unlock(&r_mutex); 

• 用信号量来实现读写锁

这里使用2个信号量+1个整型变量来实现。令信号量的初始数值为1，那么信号量的作用就和互斥量等价了。

#include <semaphore.h>     //线程信号量所需头文件

 

sem_t r_sem;     //定义信号量

sem_init(&r_sem, 0, 1);     //初始化信号量 

 

sem_t w_sem;     //定义信号量

sem_init(&w_sem, 0, 1);     //初始化信号量  

int readers = 0;

 

写模式：

sem_wait(&w_sem);

写写写……

sem_post(&w_sem);

 

 

读模式：

sem_wait(&r_sem);

if(readers == 0)

     sem_wait(&w_sem);

readers++;

sem_post(&r_sem);

读读读……

sem_wait(&r_sem);

readers- -;

if(readers == 0)

     sem_post(&w_sem);

sem_post(&r_sem);

线程的安全是现在各个领域在多线程开发必须要掌握的基础！只有对底层有所掌握，才能在真正的实际开发中游刃有余！

⛲️内存池

内存池提供了内存的复用和持久的存储功能。设想一个场景，当你分配了一块大内存并且填写了内容，但是你又不是经常去访问这块内存。这样的内存利用率将不高，而且无法复用。而如果是采用内存池则可以很轻松解决这个问题：你只需要从内存池中申请这块内存，设置完内容后当不需要用时你可以将这块内存放入内存池中，供其他地方在申请时进行复用，而当你再次需要时则只需要重新申请即可。内存池提供了内存分配编号而且设置脏标志的概念，当你把分配的内存放入内存池并设置脏标志后，系统就会在适当的时候将这块内存的内容写回到磁盘，这样当你再次根据内存编号来访问内存时，系统就又会从磁盘中将内容读取到内存中去。

功能：在iOS中提供了一套内存池管理的API，你可以用这套API来实现上述的功能，而且系统内部很多功能也是借助内存池来实现内存复用和磁盘存储的。
头文件: #include <mpool.h>, #include <db.h>
平台: BSD系统，linux系统

一、内存池的创建、同步和关闭

功能:创建和关闭一个内存池对象并和磁盘文件绑定以便进行同步操作。
函数签名：

//创建一个内存池对象
 MPOOL * mpool_open(void *key, int fd, pgno_t pagesize, pgno_t maxcache);

//将内存池中的脏数据同步写回到磁盘文件中
int mpool_sync(MPOOL *mp);

//关闭和销毁内存池对象。
int mpool_close(MPOOL *mp);

参数：

key:[in] 保留字段，暂时没有用处，传递NULL即可。
fd:[in] 内存池关联的磁盘文件句柄，文件句柄需要用open函数来打开。
pagesize:[in] 内存池中每次申请和分配的内存的尺寸大小，单位是字节。
maxcache:[in] 内存池中内存页的最大缓存数量。如果池中缓存的内存数量超过了最大缓存的数量就会复用已经存在的内存，而不是每次都分配新的内存。
return:[out] 返回一个新创建的内存池对象，其他两个函数成功返回0，失败返回非0.

描述：

1、内存池中的内存的分配和获取是以页为单位进行的，每次分配的页的尺寸大小由pagesize指定，同时内存池也指定了最大的缓存页数量maxcache。每次从内存池中分配一页内存时，除了会返回分配的内存地址外，还会返回这一页内存的编号。这个编号对于内存池中的内存页来说是唯一的。因为内存池中的内存是可以被复用的，因此就有可能是不同的编号的内存页所得到的内存地址是相同的。

2、每一个内存池对象都会要和一个文件关联起来，以便能够实现内存数据的永久存储和内存的复用。文件句柄必须用open函数来打开，比如下面的例子：

int fd = open("/Users/apple/mpool", O_RDWR|O_APPEND|O_CREAT,0660);

3、当我们不需要使用某个内存页时或者内存页的内容有改动则我们需要将这个内存页放入回内存池中，并将页标志为脏(DIRTY)。这样系统就会在适当的时候将此内存页的数据写回到磁盘文件中，同时此内存页也会在后续被重复利用。

4、当我们想将所有设置为脏标志的内存页立即写入磁盘时则需要调用mpool_sync函数进行同步处理。

5、当我们不再需要内存池时，则可以通过mpool_close来关闭内存池对象，需要注意的是关闭内存池并不会将内存中的数据回写到磁盘中去。

二、内存池中内存的获取

功能： 从内存池中申请分配一页新的内存或者获取现有缓存中的内存。
函数签名:

//从内存池中申请分配一页新的内存
void *  mpool_new(MPOOL *mp, pgno_t *pgnoaddr);
//根据内存编号页获取对应的内存。
void * mpool_get(MPOOL *mp, pgno_t pgno, u_int flags);

参数:

mp:[in] 内存池对象。
pgnoaddr:[out] 用于mpool_new函数，用于保存新分配的内存页编号。
pngno:[in] 用于mpool_get函数，指定要获取的内存页的编号。
flags:[in] 此参数暂时无用。
return:[out] 返回分配或者获取的内存地址。如果分配或者获取失败则返回NULL。

描述:

1、无论是new还是get每次从内存池里面分配或者获取的内存页的大小都是由上述mpool_open函数中的pagesize参数指定的大小。
2、系统内部分配的内存是用calloc函数实现的，但是我们不需要手动调用free来对内存进行释放处理。
3、每个内存页都有一个唯一的页编号，而且每次分配的页编号也会一直递增下去。
4、mpool_new函数申请分配新的内存时，如果当前缓存中的内存页小于maxcache数量则总是分配新的内存，只有当缓存数量大于maxcache时才会从现有的缓存中寻找一页可以被重复利用的内存页，如果没有可以重复利用的页面，则会继续分配新的内存页。
5、mpool_get函数则根据内存页的编号获取对应的内存页。如果编号不存在则返回NULL。需要注意的是一般在获取了某一页内存后，不要进行重复获取操作，否则在DEBUG状态下会返回异常。另外一个情况是有可能相同的页编号下两次获取的内存地址是不一样的，因为系统实现内部有内存复用的机制。

三、内存池中内存的放回

功能：将分配或者申请的内存页放回到内存池中去，以便进行重复利用。
函数签名:

int  mpool_put(MPOOL *mp, void *pgaddr, u_int flags);

参数:

mp: [in] 内存池对象。
pgaddr:[in] 要放入缓存的内存页地址。这个地址由mpool_get/new两个函数返回。
flags:[in] 放回的属性，一般设置为0或者MPOOL_DIRTY。
return:[in] 函数调用成功返回0，失败返回非0

描述：

1、这个函数用来将内存页放入回内存池缓存中，以便对内存进行重复利用。当将某个内存地址放入回缓存后，将不能再次访问这个内存地址了。如果要想继续访问内存中的数据则需要借助上述的mpool_get/new函数来重新获取。
2、flags:属性如果指定为0时，表明放弃这次内存中的内容的修改，系统不会将内存中的内容写入到磁盘中，而只是将内存放入缓存中供其他地方重复使用。而如果设置为MPOOL_DIRTY时，则表明将这页内存中的数据设置为脏标志，除了同样将内存放入缓存中重复利用外，则会在适当的时候将内存中的数据写入到磁盘中，以便下次进行读取。

四、内存池磁盘读写通知

功能：注册回调函数，当某页内存要写回到磁盘或者要从磁盘中读取时就会调用指定的回调函数。
函数签名:

void mpool_filter(MPOOL *mp, void (*pgin)(void *, pgno_t, void *),
         void (*pgout)(void *, pgno_t, void *), void *pgcookie);

参数:

mp:[in] 内存池对象.
pgin: [in]: 回调函数，当某个内存页的数据需要从磁盘读取时，会在读取完成后调用这个回调函数。
pgout:[in]: 回调函数，当某个内存页的数据要到磁盘时，会在写入完成后调用这个回调函数。
pgcookie: [in] 上述两个回调函数的附加参数。

描述：

因为内存池中的内存页会进行复用，以及会在适当的时候将内容同步到磁盘中，或者从磁盘中将内容读取到内存中，因此可以借助这个函数来监控这些磁盘文件和内存之间的读写操作。pgin和pgout函数的格式定义如下：

//pgin和pgout回调函数的格式。
//pgcookie：是mpool_filter函数中传入的参数。
//pgno: 要进行读写的内存页编号
//pageaddr: 要进行读写的内存地址。
void (*pgcallback)(void *pgcookie, pgno_t pgno, void *pageaddr);

五、实例代码

#include <mpool.h>
#include <db.h>

 //创建并打开一个文件。
 int fd = open("/Users/apple/mpool", O_RDWR|O_APPEND|O_CREAT,0660);

//创建一个内存池对象，每页的内存100个字节，最大的缓存数量为4
 MPOOL *pool = mpool_open(NULL, fd, 100, 4);

   
//从内存池中分配一个新的内存页，这里对返回的内存填写数据。
 pgno_t pidx1, pidx2 = 0;
 char *mem1 =  (char*)mpool_new(pool, &pidx1);
 memcpy(mem1, "aaa", 4);
    
 char *mem2 = (char*)mpool_new(pool, &pidx2);
 memcpy(mem2, "bbb", 4);
    
//将分配的内存mem1放回内存池中，但是内容不保存到磁盘
 mpool_put(pool, mem1, 0);
//将分配的内存mem2放回内存池中，但是内容保存到磁盘。
 mpool_put(pool, mem2, MPOOL_DIRTY);
    
//经过上面的操作后mem1,mem2将不能继续再访问了，需要访问时需要再次调用mpool_get。   
mem1 = (char*)mpool_get(pool, pidx1, 0);
mem2 =   (char*)mpool_get(pool, pidx2, 0);

//上面的mem1和mem2可能和前面的new返回的地址是不一样的。因此在内存池中不能通过地址来做唯一比较，而应该将编号来进行比较。
       
//将所有设置为脏标志的内存也写回到磁盘中去。
 mpool_sync(pool);

 mpool_close(pool);  //关闭内存池。

 close(fd);  //关闭文件。

内存池为iOS系统底层开发提供了一个非常重要的能力，我们可以好好利用内存池来对内存进行管理，以及一些需要进行持久化的数据也可以借助内存池来进行保存，通过内存池提高内存的重复利用率。

转自：https://www.jianshu.com/p/34bd3e5c5b4e

一、问题 & 结论

1. css 加载会阻塞 DOM 树的解析渲染吗 ？

• css 并不会阻塞 dom 树的解析
• css 会阻塞 dom 树的渲染

2. css 加载会阻塞 js 运行吗 ？

• css 加载会阻塞后面 js 语句的执行

二、造成的结果以及优化方案

1. 造成的结果

• css 加载缓慢会造成长时间的白屏

1. CDN 加速：CDN 会根据网络状况，挑选一个最近的具有缓存内容的节点提供资源，减少加载时间
2. 对 css 进行压缩：使用打包工具 webpack、gulp 等，开启 gzip 压缩
3. 合理的使用缓存：强缓存、协商缓存等策略
4. 减少 http 请求次数，合并 css 文件，或者干脆写成内联样式(缺点：不能缓存)

深入理解z-index

在MDN上的定义是z-index 属性设定了一个定位元素及其后代元素或 flex 项目的 z-order。 当元素之间重叠的时候， z-index 较大的元素会覆盖较小的元素在上层进行显示。

但是这个说明太含糊了,当遇到z-index不生效的情况时,就不知所以然了,最近也查看了很多和z-index相关的资料,决定把z-index相关知识系统性的梳理一遍.

以前我总是很片面的认为元素在Z轴上的层叠顺序只跟z-index值的大小有关, 属性值大的元素显示在上面、属性值小的元素显示在下面,但是就像下面, 为啥z-index不生效呢,明明box1的z-index属性值大于box2的.

事实上z-index属性并非对所有元素都生效, 它仅对定位元素生效而且定位元素的prosition属性值不为static时才会起作用:

其实判断元素在Z轴的层叠顺序取决于两个方面: 元素所在的层叠上下文、元素自身的层叠级别, 在此之前我们先了解一下这两个概念:

z-index

通常情况下，html页面可以被认为是二维的，因为文本，图像和其他元素被排列在页面上而不重叠。在这种情况下，只有一个渲染进程，所有元素都知道其他元素所占用的空间。

在 CSS 2.1 中, 所有的盒模型元素都处于三维坐标系中。 除了我们常用的横坐标和纵坐标， 盒模型元素还可以沿着“z 轴”层叠摆放， 当他们相互覆盖时，z轴顺序就变得十分重要。这意味着 CSS 允许你在现有的渲染引擎上层叠的摆放盒模型元素。 所有的层都可以用一个整数( z 轴顺序)来表明当前层在 z 轴的位置。 数字越大， 元素越接近观察者。Z 轴顺序用 CSS 的 z-index 属性来指定。z-index的属性值默认为auto,可设置值为一个整数、可为正整数也可以是负整数

层叠上下文

MDN上的定义: 我们假定用户正面向（浏览器）视窗或网页，而 HTML 元素沿着其相对于用户的一条虚构的z轴排开，层叠上下文就是对这些HTML元素的一个三维构想。众HTML元素基于其元素属性按照优先级顺序占据这个空间。

那么如何才能创建层叠上下文呢?我在网上看到过一个, 总结的很好: 目前有三类方法创建层叠上下文

• 元素自身就能创建的


• 需要结合z-index才能创建的


• 不需要z-index 就能创建的

一、元素自身形成层叠上下文

文档根元素（<html>）会自动形成一个层叠上下文, 不需要结合任何其他属性

二、需要配合z-index才能触发创建层叠上下文的

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

采用flex布局容器的子元素, 且子元素 z-index 属性值不为 auto 的元素；

三、不要配合z-index就能触发创建层叠上下文的

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

透明度opacity属性值不为1的元素

转换transform属性值不为none的元素

滤镜filter属性值不为none的元素

上面列举出来的都是一些常用到的属性,当然还有其他的属性值设置也能触发形成层叠上下文,这里就不一一列举了,有兴趣的同学可以去MDN文档查看.这里我们需要注意的几点:

• 层叠上下文可以包含在其他层叠上下文中, 由于根元素HTML本身就是一个层叠上下文,所以页面文档中的创建的层叠上下文都是HTML元素层级的一个子级


• 当某个元素创建了层叠上下文后, 应当把它及其后代当成一个整体,去判断层叠顺序


• 父子元素、兄弟元素都可能会处于同一层叠上下文中

层叠级别

在不考虑层叠上下文的情况下, 元素的层叠级别就是判断发生层叠时,元素在Z轴如何显示的依据, 下图就是著名的7阶层叠水平:

background/border、负z-index元素、块级元素、浮动元素、行内/行内块元素、z-index为0元素、正z-index元素.

文本节点我们也看成是一个行内元素

判断层叠顺序

在理解了层叠上下文和元素层叠水平的概念后,现在我们就可以说说元素在Z轴上的层叠顺序到底是怎么回事了: 元素在Z轴上的层叠顺序取决于两个方面: 元素所在的层叠上下文、元素自身的层叠级别,如果抛开层叠上下文来判断元素在Z轴上的层叠顺序就是瞎胡闹

1. 当要比较的两个元素在同一层叠上下文时, 就按照元素自身的层叠级别, 如果级别相同时后则覆盖前者

• 
  

  同一层叠上下文中的兄弟元素

上图box1、box2都处在同一层叠上下文中(html元素形成的上下文) ,二者都是行内块元素,级别相同, 所以后者覆盖前者

前言: 根据需求有时候需要用到JS与Objective-C交互来实现一些功能, 本文介绍实现交互的一种方式, 使用WKWebView的新特性MessageHandler, 来实现JS调用原生, 原生调用JS.

一. 基础说明

WKWebView 初始化时，有一个参数叫configuration，它是WKWebViewConfiguration类型的参数，而WKWebViewConfiguration有一个属性叫userContentController，它又是WKUserContentController类型的参数。WKUserContentController对象有一个方法- addScriptMessageHandler:name:，我把这个功能简称为MessageHandler。- addScriptMessageHandler:name:有两个参数，第一个参数是userContentController的代理对象，第二个参数是JS里发送postMessage的对象。
所以要使用MessageHandler功能，就必须要实现WKScriptMessageHandler协议。

二. 在JS中使用方法

1. js文件代码实例

function locationClick() {
                /// "showMessage". 为我们和前端开发人员的约定
                window.webkit.messageHandlers.showMessage.postMessage(null);
            }

2. 在ViewController 我们需要做哪些事情

2.1 对WKWebView进行初始化以及设置

/// 创建网页配置对象
    WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];
    /// 创建设置对象
    WKPreferences *preference = [[WKPreferences alloc]init];
    /// 最小字体大小 当将javaScriptEnabled属性设置为NO时，可以看到明显的效果
    preference.minimumFontSize = 40.0;
    /// 设置是否支持javaScript 默认是支持的
    preference.javaScriptEnabled = YES;
    /// 在iOS上默认为NO，表示是否允许不经过用户交互由javaScript自动打开窗口
    preference.javaScriptCanOpenWindowsAutomatically = YES;
    config.preferences = preference;
    /// 这个类主要用来做native与JavaScript的交互管理
    
    _wkwebView = [[WKWebView alloc] initWithFrame:CGRectMake(0, 0, self.view.frame.size.width, self.view.frame.size.height) configuration:config];
    [self.view addSubview:_wkwebView];
    /// Load WebView
#if 0
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@"https://m.benlai.com/huanan/zt/1231cherry"]];
    [self.wkwebView loadRequest:request];
#endif
    
#if 1
    NSString *bundleStr = [[NSBundle mainBundle] pathForResource:@"summerxx-test" ofType:@"html"];
    [self.wkwebView loadRequest:[NSURLRequest requestWithURL:[NSURL fileURLWithPath:bundleStr]]];
#endif
    
    // UI代理
    _wkwebView.UIDelegate = self;
    // 导航代理
    _wkwebView.navigationDelegate = self;
    // 是否允许手势左滑返回上一级, 类似导航控制的左滑返回
    _wkwebView.allowsBackForwardNavigationGestures = YES;
    
    // 添加监测网页加载进度的观察者
    [self.wkwebView addObserver:self
                     forKeyPath:@"estimatedProgress"
                        options:0
                        context:nil];
    // 添加监测网页标题title的观察者
    [self.wkwebView addObserver:self
                     forKeyPath:@"title"
                        options:NSKeyValueObservingOptionNew
                        context:nil];

2.2 在合理地方进行注册

[self.wkwebView.configuration.userContentController addScriptMessageHandler:self name:@"showMessage"];

2.3 接收JS给我们传递消息, 这里我做了一个简单的弹窗提示

#pragma mark - WKScriptMessageHandler
/// 通过接收JS传出消息的name进行捕捉的回调方法
- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message
{
    if ([message.name isEqualToString:@"showMessage"]) {
        UIAlertController *alertController = [UIAlertController alertControllerWithTitle:@"title" message:@"messgae" preferredStyle:UIAlertControllerStyleAlert];
        UIAlertAction *okAction = [UIAlertAction actionWithTitle:@"同意" style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {
            
            NSString *jsStr = [NSString stringWithFormat:@"setLocation('%@')",@"虽然我同意了你, 但是答应我别骄傲."];
            [self.wkwebView evaluateJavaScript:jsStr completionHandler:^(id _Nullable result, NSError * _Nullable error) {
                NSLog(@"%@----%@",result, error);
            }];
        }];
        UIAlertAction *cancelAction = [UIAlertAction actionWithTitle:@"cancel" style:UIAlertActionStyleCancel handler:^(UIAlertAction * _Nonnull action) {
            NSLog(@"cancel");
            
        }];
        UIAlertAction *errorAction = [UIAlertAction actionWithTitle:@"拒绝" style:UIAlertActionStyleDestructive handler:^(UIAlertAction * _Nonnull action) {
            NSString *jsStr = [NSString stringWithFormat:@"setLocation('%@')",@"虽然我拒绝了你, 但是继续爱我好吗"];
            [self.wkwebView evaluateJavaScript:jsStr completionHandler:^(id _Nullable result, NSError * _Nullable error) {
                NSLog(@"%@----%@",result, error);
            }];
        }];
        [alertController addAction:errorAction];
        [alertController addAction:okAction];
        [alertController addAction:cancelAction];
        
        // 出现
        [self presentViewController:alertController animated:YES completion:^{
            
        }];
        
    }
}

2.4 销毁

- (void)dealloc {
    /// Remove removeObserver
    [_wkwebView removeObserver:self
                    forKeyPath:NSStringFromSelector(@selector(estimatedProgress))];
    [_wkwebView removeObserver:self
                    forKeyPath:NSStringFromSelector(@selector(title))];
    WKUserContentController *userCC = self.wkwebView.configuration.userContentController;
    [userCC removeScriptMessageHandlerForName:@"showMessage"];
}

Demo: 演示步骤, 点击获取定位 Objective-C获取到JS消息
点击拒绝, JS获取到Objective-C传递的消息

如图:

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

UITableViewController vs. UIViewController

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

Table View Controllers 的特性

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

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

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

Table View Controllers 的限制

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

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

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

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

使用 Child View Controllers

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

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

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

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

@interface PhotoViewController () 
@end

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

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

分离关注点（Separating Concerns）

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

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

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

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

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

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

@implementation PhotoCell (ConfigureForPhoto)

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

@end

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

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

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

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

让 Cells 可复用

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

在 Cell 内部控制 Cell 的状态

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

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

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

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

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

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

控制多个 Cell 类型

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

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

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

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

编辑 Table View

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

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

总结

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

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

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

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

总览

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

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

优化资源的 OpenGL ES

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

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

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

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

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

从相机获取像素数据

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

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

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

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

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

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

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

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

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

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

从影片中获取像素数据

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

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

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

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

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

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

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

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

创意地使用滤镜

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

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

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

混合图片

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

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

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

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

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

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

CPU vs. GPU

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

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

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

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

避免转移

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

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

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

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

工作和目标

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

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

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

缓冲区和图像

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

结论

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

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

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

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

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

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

测试代码在这

semaphore的三个方法

dispatch_semaphore_create

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

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

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

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

dispatch_semaphore_wait

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

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

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

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

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

dispatch_semaphore_signal

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

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

semaphore使用篇

线程同步

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

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

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

运行之后的log如下：

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

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

资源加锁

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

semaphore的释放

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

首先我们来看2个例子：

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

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

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

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

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

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

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

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

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

dispatch_semaphore_t
dispatch_semaphore_create(long value)
{
    dispatch_semaphore_t dsema;

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

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

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

    return dsema;
}

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

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

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

    _dispatch_dispose(dsema);
}

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

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

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

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

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

※unavailable
#define UNAVAILABLE_ATTRIBUTE __attribute__((unavailable))

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

Swift中

@available(*, unavailable)

func foo() {}

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

func foo2() {}

※availability

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

展开看

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

再展开看

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

iOS即是iOS平台

introduced从哪个版本开始使用

deprecated从哪个版本开始弃用

message警告的信息

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

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

obsoleted完全禁止使用的版本

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

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

Swift中：

@available(iOS 6.0, *)

public var minimumScaleFactor: CGFloat

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

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

func foo3() {}

※objc_subclassing_restricted

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

__attribute__((objc_subclassing_restricted))

@interface Eunuch : NSObject

@end

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

@end

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

※objc_requires_super

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

#define NS_REQUIRES_SUPER __attribute__((objc_requires_super))

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

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

关于Swift中的final的详细讲解

※overloadable

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

__attribute__((overloadable))

void logAnything(id obj) {

NSLog(@"%@", obj);

}

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

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

}

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

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

}

// Tests

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

logAnything(233);

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

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

※cleanup

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

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

#define onExit\

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

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

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

sunnyxx这篇博客讲的很清楚

Swift中：可以用defer

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

神奇的attribute

Clang Attributes黑魔法小记

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

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

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

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

二、能给你带来什么

ReactiveHttp 能够给你带来什么？

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

ReactiveHttp 不能带给你什么？

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

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

三、架构说明

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

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

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

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

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

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

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

四、惯常做法

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

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

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

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

interface ApiService {

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

}

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

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

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

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

五、简单入门

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

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

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

    override val httpCode: Int
        get() = status

    override val httpMsg: String
        get() = msg

    override val httpData: T
        get() = data

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

}

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

interface ApiService {

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

}

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

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

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

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

    companion object {

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

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

    }

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

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

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

}

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

六、进阶使用

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

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

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

1、BaseReactiveActivity

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

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

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

    override val lifecycleSupportedScope: CoroutineScope
        get() = lifecycleScope

    override val lContext: Context?
        get() = this

    override val lLifecycleOwner: LifecycleOwner
        get() = this

    private var loadDialog: ProgressDialog? = null

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

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

2、BaseReactiveViewModel

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

open class BaseViewModel : ViewModel(), IViewModelActionEvent {

    override val lifecycleSupportedScope: CoroutineScope
        get() = viewModelScope

    override val showLoadingEventLD = MutableLiveData()

    override val dismissLoadingEventLD = MutableLiveData()

    override val showToastEventLD = MutableLiveData()

    override val finishViewEventLD = MutableLiveData()

}

3、关联上

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

class WeatherViewModel : BaseReactiveViewModel() {

    private val remoteDataSource by lazy {
        SelfRemoteDataSource(this)
    }

    val forecastsBeanLiveData = MutableLiveData()

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

}

class WeatherActivity : BaseReactiveActivity() {

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

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

    private fun showWeather(forecastsBean: ForecastsBean) {

    }

}

七、其它

1、BaseRemoteDataSource

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

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

    companion object {

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

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

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

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

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

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

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

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

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

}