一、Instruments介绍

Instruments 一个很灵活的、强大的工具，是性能分析、动态跟踪 和分析OS X以及iOS代码的测试工具，用它可以极为方便收集关于一个或多个系统进程的性能和行为的数据，并能及时随着时间跟踪而产生的数据，并检查所收集的数据，还可以广泛收集不同类型的数据.也可以追踪程序运行的过程，这样instrument就可以帮助我们了解用户的应用程序和操作系统的行为。

总结一下instrument能做的事情：

1. Instruments是用于动态调追踪和分析OS X和iOS的代码的性能分析和测试工具；
2.Instruments支持多线程的调试；
3.可以用Instruments去录制和回放，图形用户界面的操作过程
4.可将录制的图形界面操作和Instruments保存为模板，供以后访问使用。

1.追踪代码中的（甚至是那些难以复制的）问题；
2.分析程序的性能；
3.实现程序的自动化测试；
4.部分实现程序的压力测试；
5.执行系统级别的通用问题追踪调试；
6.使你对程序的内部运行过程更加了解。

 打开方式：
Xcode -> Open Developer Tool -> Instruments

其中比较常用的有四种：

1.Allocations：用来检查内存分配，跟踪过程的匿名虚拟内存和堆的对象提供类名和可选保留/释放历史

2.Leaks：一般的查看内存使用情况，检查泄漏的内存，并提供了所有活动的分配和泄漏模块的类对象分配统计信息以及内存地址历史记录

3.Time Profiler：分析代码的执行时间，执行对系统的CPU上运行的进程低负载时间为基础采样

4.Zombies：检查是否访问了僵尸对象

其他的：

Blank：创建一个空的模板，可以从Library库中添加其他模板

Activity Monitor：显示器处理的CPU、内存和网络使用情况统计

Automation：用JavaScript语言编写，主要用于分析应用的性能和用户行为，模仿/击发被请求的事件，利用它可以完成对被测应用的简单的UI测试及相关功能测试

Cocoa Layout：观察约束变化，找出布局代码的问题所在。

Core Animation：用来检测Core Animation性能的，给我们提供了周期性的FPS，并且考虑到了发生在程序之外的动画，界面滑动FPS可以进行测试

Core Data：监测读取、缓存未命中、保存等操作，能直观显示是否保存次数远超实际需要

Energy Diagnostic ：用于Xcode下的Instruments来分析手机电量消耗的。（必须是真机才有电量）

GPU Driver ：可以测量GPU的利用率，同样也是一个很好的来判断和GPU相关动画性能的指示器。它同样也提供了类似Core Animtaion那样显示FPS的工具。

Network：分析应用程序如何使用TCP / IP和UDP / IP连接使用连接仪器。就是检查手机网速的。（这个最好是真机）

二、Allocations（分配）

1.内存分类：

Leaked memory：泄漏的内存，如为对象A申请了内存空间，之后再也没用到A，也没有释放A导致内存泄漏（野指针。。。）

Abandoned memory：被遗弃的内存，如循环引用，递归不断申请内存而导致的内存泄漏

Cached memory：缓存的内存

2.Abandoned memory

其中内存泄漏我们可以用Leaks，野指针可以用Zombies（僵尸对象），而在这里我们就可以用Allocations来检测Abandoned memory的内存。

即我们采用Generational Analysis的方法来分析，反复进入退出某一场景，查看内存的分配与释放情况，以定位哪些对象是属于Abandoned Memory的范畴。

在Allocations工具中，有专门的Generational Analysis设置，如下：

我们可以在程序运行时，在进入某个模块前标记一个Generation，这样会生成一个快照。然后进入、退出，再标记一个Generation，如下图：

在详情面板中我们可以看到两个Generation间内存的增长情况，其中就可能存在潜在的被遗弃的对象，如下图：

其中growth就是我们增长的内存，GenerationA是程序启动到进入该场景增长的内存，GenerationB就是第二次进入该场景所增长的内存，查看子类可以发现有两个管理类造成了Abandoned memory。

3.设置Generations

使用instrument测试内存泄露 工具 Allocations 测试是否内存泄露 使用标记，可以更省事省力的测试页面是否有内存泄露
1）设置Generations

2）选择mark generation

3）使用方法 在进入测试页面之前，mark一下----->进入页面----->退出----->mark------>进入------->退出------->mark------>进入如此往复5、6次，就可以看到如下结果

这种情况下是内存有泄露，看到每次的增量都是好几百K或者上M的，都是属于内存有泄露的，这时候就需要检测下代码一般情况

100K以下都属于正常范围，growth表示距离你上次mark的增量

三、Leaks（泄漏）

1.内存溢出和内存泄漏的区别

内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出

内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。

memory leak会最终会导致out of memory！

在前面的ALLcations里面我们提到过内存泄漏就是应该释放而没有释放的内存。而内存泄漏分为两种：Leaked Memory 和 Abandoned Memory。前面我们讲到了如何找到Abandoned Memory被遗忘的内存，现在我们研究的就是Leaked Memory。

以发生的方式来分类，内存泄漏可以分为4类：

常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

影响：从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

下边我们介绍Instruments里面的Leaked的用法，首先打开Leaked，跑起工程来，点击要测试的页面，如果有内存泄漏，会出现下图中的红色的❌。然后按照后边的步骤进行修复即可

上面的旧版的样式，下面的是新版的样式，基本操作差不多

在详情面板选中显示的若干条中的一条，双击，会自动跳到内存泄露代码处，然后点击右上角 Xcode 图标进行修改。

下图是对Leaked页面进一步的理解：

内存泄漏动态分析技巧：

1.在 Display Settings 界面建议把 Snapshot Interval （snapʃɒt, 数据快照）间隔时间设置为10秒，勾选Automatic Snapshotting，Leaks 会自动进行内存捕捉分析。（新版本直接在底部修改）

2.熟练使用 Leaks 后会对内存泄漏判断更准确，在可能导致泄漏的操作里，在你怀疑有内存泄漏的操作前和操作后，可以点击 Snapshot Now 进行手动捕捉。

3.开始时如果设备性能较好，可以把自动捕捉间隔设置为 5 秒钟。

4.使用ARC的项目，一般内存泄漏都是 malloc、自定义结构、资源引起的，多注意这些地方进行分析。

5.开启ARC后，内存泄漏的原因,开启了ARC并不是就不会存在内存问题，苹果有句名言：ARC is only for NSObject。

注：如果你的项目使用了ARC，随着你的操作，不断开启或关闭视图，内存可能持续上升，但这不一定表示存在内存泄漏，ARC释放的时机是不固定的

这里对 Display Settings中 的 Call tree 选项做一下说明 [官方user guide翻译]：

Separate By Thread：线程分离,只有这样才能在调用路径中能够清晰看到占用CPU最大的线程.每个线程应该分开考虑。只有这样你才能揪出那些大量占用CPU的"重"线程，按线程分开做分析，这样更容易揪出那些吃资源的问题线程。特别是对于主线程，它要处理和渲染所有的接口数据，一旦受到阻塞，程序必然卡顿或停止响应。

Invert Call Tree：从上到下跟踪堆栈信息.这个选项可以快捷的看到方法调用路径最深方法占用CPU耗时（这意味着你看到的表中的方法,将已从第0帧开始取样,这通常你是想要的,只有这样你才能看到CPU中花费时间最深的方法）,比如FuncA{FunB{FunC}},勾选后堆栈以C->B->A把调用层级最深的C显示最外面.反向输出调用树。把调用层级最深的方法显示在最上面，更容易找到最耗时的操作。

Hide Missing Symbols：如果dSYM无法找到你的APP或者调用系统框架的话，那么表中将看到调用方法名只能看到16进制的数值,勾选这个选项则可以隐藏这些符号，便于简化分析数据.

Hide System Libraries：表示隐藏系统的函数，调用这个就更有用了,勾选后耗时调用路径只会显示app耗时的代码,性能分析普遍我们都比较关系自己代码的耗时而不是系统的.基本是必选项.注意有些代码耗时也会纳入系统层级，可以进行勾选前后前后对执行路径进行比对会非常有用.因为通常你只关心cpu花在自己代码上的时间不是系统上的，隐藏系统库文件。过滤掉各种系统调用，只显示自己的代码调用。隐藏缺失符号。如果 dSYM 文件或其他系统架构缺失，列表中会出现很多奇怪的十六进制的数值，用此选项把这些干扰元素屏蔽掉，让列表回归清爽。

Show Obj-C Only：只显示oc代码 ,如果你的程序是像OpenGl这样的程序,不要勾选侧向因为他有可能是C++的

Flatten Recursion：递归函数, 每个堆栈跟踪一个条目，拼合递归。将同一递归函数产生的多条堆栈（因为递归函数会调用自己）合并为一条。

Top Functions：找到最耗时的函数或方法。 一个函数花费的时间直接在该函数中的总和，以及在函数调用该函数所花费的时间的总时间。因此，如果函数A调用B，那么A的时间报告在A花费的时间加上B.花费的时间,这非常真有用，因为它可以让你每次下到调用堆栈时挑最大的时间数字，归零在你最耗时的方法。

四、Time Profiler（时间分析器）

用来检测app中每个方法所用的时间，并且可以排序，并查找出哪些函数占用了大量时间。

使用Time Profile前有两点需要注意的地方：

1、一定要使用真机调试

在开始进行应用程序性能分析的时候，一定要使用真机。因为模拟器运行在Mac上，然而Mac上的CPU往往比iOS设备要快。相反，Mac上的GPU和iOS设备的完全不一样，模拟器不得已要在软件层面（CPU）模拟设备的GPU，这意味着GPU相关的操作在模拟器上运行的更慢，尤其是使用CAEAGLLayer来写一些OpenGL的代码时候，这就导致模拟器性能数据和用户真机使用性能数据相去甚远

2、应用程序一定要使用发布配置

在发布环境打包的时候，编译器会引入一系列提高性能的优化，例如去掉调试符号或者移除并重新组织代码。另iOS引入一种"Watch Dog"[看门狗]机制，不同的场景下，“看门狗”会监测应用的性能，如果超出了该场景所规定的运行时间，“看门狗”就会强制终结这个应用的进程。开发者可以crashlog看到对应的日志，但Xcode在调试配置下会禁用"Watch Dog"

1）界面详情：

2）详细面板

主要是看Call Tree和Sample List这两种视图：

3）调用树

Running Time：函数运行的时间，这个时间是累积时间

Self：在栈顶次数

Symbol Name：被调用函数的符号信息

4）详情面板更多的信息选项

5）样本列表

五、Zombies（僵尸）

1.概念

翻译英文：专注于检测过度释放的“僵尸”对象。还提供了数据对象分配的类以及所有活动分配内存地址的历史。

这里我们可以看到一个词语叫“over-release”,过度释放。我们在项目中见到最多的就是“EXC_BAD_ACCESS”或者是这样的：Thread 1: Program received signal:"EXC_BAD_ACCESS"，这就是访问了被释放的内存地址造成的

过度释放，是对同一个对象释放了过多的次数，其实当引用计数降到0时，对象占用的内存已经被释放掉，此时指向原对象的指针就成了“悬垂指针”，如若再对其进行任何方法的调用，（原则上）都会直接crash（然而由于某些特殊的情况，不会马上crash）。过度释放简单的说就是对release的对象再release，就是过度释放。

我们需要知道这几个概念：

1、内存泄漏：对象使用完没有释放，导致内存浪费。
2、僵尸对象：已经被销毁的对象(不能再使用的对象)
3、野指针：指向僵尸对象(不可用内存)的指针。给野指针发消息会报EXC_BAD_ACCECC错误。
4、空指针：没有指向储存空间的指针(里面存的是nil,也就是0)。在oc中使用空指针调中方法不会报错。

注意:为了避免野指针错误的常见方法:在对象被销毁之后,将指向对象的指针变为空指针。

对于过度释放的问题，可以直接使用Zombie，当过度释放发生时会立即停在发生问题的位置，同时结合内存分配释放历史和调用栈，可以发现问题。至于上文提到的不会crash的原因，其实有很多，比如：

对象内存释放时，所用内存并没有完全被擦除，仍有旧对象部分数据可用
原内存位置被写入同类或同样结构的数据

2.原理

我们将僵尸对象“复活”的目的：僵尸对象就是让已经释放了的对象重新复活，便于调试；是为了让已经释放了的对象在被再次访问时能够输出一些错误信息。其实这里的“复活”并不是真的复活，而是强行不死：这么说吧 相当于 他的RC=0的时候 系统再强行让他RC=1，顺便打上一个标记 zoom，等到你去掉那个沟以后 系统会把带有标记zoom的对象RC=0。

3.用法

下边是Instruments里面的Zombies的用法：

在Launch Configuration中勾选Record reference counts和Enable NSZombie detection。其中Recordreference counts是显示引用计数，Enable NSZombie detection是能够检测僵尸对象。

这样在程序运行的时候，如果发现僵尸对象它就会弹出一个对话框，点击其中“→”按钮，在屏幕的下方会显示僵尸对象的详细信息，下图可以看到僵尸对象的引用计数变化情况。

注意：Zombies模版在使用的时候会导致内存的飙升，这是因为所有被释放的对象被僵尸对象取代，并未真的释放掉，在结束Zombies时会释放，这是预知行为，这就意味着instrument里的其它工具和Zombies是不能同时使用的，Zombies会导致其它的数据不准。包括leaks，你也不应该把它加到Zombies模版中，即使这么做了结果也没什么意义。对于iOS应用来说，在用Zombies模版时使用iOS模拟器比真机要好。

另外XCode也提供了手动设置NSZombieEnabled环境变量的方法，不过设置NSZombieEnabled为True后，会导致内存占用的增长，同时会影响Leaks工具的调试，这是因为设置NSZombieEnabled会用僵尸对象来代替已释放对象

点击Product菜单Edit Scheme打开该页面，然后勾选Enable Zombie Objects复选框：

最后提醒的是NSZombieEnabled只能在调试的时候使用，千万不要忘记在产品发布的时候去掉，因为NSZombieEnabled不会真正去释放dealloc对象的内存，一直开启的话，该死去的对象会一直存在，后果可想而知，自重！

六、扩展

野指针

僵尸对象

内存回收的本质.

申请1块空间,实际上是向系统申请1块别人不再使用的空间.
释放1块空间,指的是占用的空间不再使用,这个时候系统可以分配给别人去使用.
在这个个空间分配给别人之前 数据还是存在的.
OC对象释放以后,表示OC对象占用的空间可以分配给别人.
但是再分配给别人之前 这个空间仍然存在 对象的数据仍然存在.

僵尸对象: 1个已经被释放的对象 就叫做僵尸对象.

使用野指针访问僵尸对象.有的时候会出问题,有的时候不会出问题.

当野指针指向的僵尸对象所占用的空间还没有分配给别人的时候, - 这个时候其实是可以访问的.
因为对象的数据还在.
当野指针指向的对象所占用的空间分配给了别人的时候 这个时候访问就会出问题.
所以,你不要通过1个野指针去访问1个僵尸对象.
虽然可以通过野指针去访问已经被释放的对象,但是我们不允许这么做.

僵尸对象检测.

默认情况下. Xcode不会去检测指针指向的对象是否为1个僵尸对象. 能访问就访问 不能访问就报错.

可以开启Xcode的僵尸对象检测.

那么就会在通过指针访问对象的时候,检测这个对象是否为1个僵尸对象 如果是僵尸对象 就会报错.

为什么不默认开启僵尸对象检测呢?

因为一旦开启,每次通过指针访问对象的时候.都会去检查指针指向的对象是否为僵尸对象.
那么这样的话 就影响效率了.

如何避免僵尸对象报错.

当1个指针变为野指针以后. 就把这个指针的值设置为nil

僵尸对象无法复活.

当1个对象的引用计数器变为0以后 这个对象就被释放了.
就无法取操作这个僵尸对象了. 所有对这个对象的操作都是无效的.
因为一旦对象被回收 对象就是1个僵尸对象 而访问1个僵尸对象 是没有意义.

摘自：https://blog.csdn.net/weixin_41963895/article/details/107231347

如果想让某个view不能处理事件（或者说，事件传递到某个view那里就断了），那么可以通过刚才提到的三种方式。比如，设置其userInteractionEnabled = NO;那么传递下来的事件就会由该view的父控件处理。
例如，不想让蓝色的view接收事件，那么可以设置蓝色的view的userInteractionEnabled = NO;那么点击黄色的view或者蓝色的view所产生的事件，最终会由橙色的view处理，橙色的view就会成为最合适的view。
所以，不管视图能不能处理事件，只要点击了视图就都会产生事件，关键在于该事件最终是由谁来处理！也就是说，如果蓝色视图不能处理事件，点击蓝色视图产生的触摸事件不会由被点击的视图（蓝色视图）处理！

注意：如果设置父控件的透明度或者hidden，会直接影响到子控件的透明度和hidden。如果父控件的透明度为0或者hidden = YES，那么子控件也是不可见的！

3.3.如何寻找最合适的view

应用如何找到最合适的控件来处理事件？
1.首先判断主窗口（keyWindow）自己是否能接受触摸事件

2.触摸点是否在自己身上

3.从后往前遍历子控件，重复前面的两个步骤（首先查找数组中最后一个元素）

4.如果没有符合条件的子控件，那么就认为自己最合适处理

详述：

1.主窗口接收到应用程序传递过来的事件后，首先判断自己能否接手触摸事件。如果能，那么在判断触摸点在不在窗口自己身上
2.如果触摸点也在窗口身上，那么窗口会从后往前遍历自己的子控件（遍历自己的子控件只是为了寻找出来最合适的view）
3.遍历到每一个子控件后，又会重复上面的两个步骤（传递事件给子控件，1.判断子控件能否接受事件，2.点在不在子控件上）
4.如此循环遍历子控件，直到找到最合适的view，如果没有更合适的子控件，那么自己就成为最合适的view。
找到最合适的view后，就会调用该view的touches方法处理具体的事件。所以，只有找到最合适的view，把事件传递给最合适的view后，才会调用touches方法进行接下来的事件处理。找不到最合适的view，就不会调用touches方法进行事件处理。

注意：之所以会采取从后往前遍历子控件的方式寻找最合适的view只是为了做一些循环优化。因为相比较之下，后添加的view在上面，降低循环次数。

3.3.1.寻找最合适的view底层剖析

两个重要的方法：
hitTest:withEvent:方法
pointInside方法

3.3.1.1.hitTest：withEvent：方法

什么时候调用？

只要事件一传递给一个控件,这个控件就会调用他自己的hitTest：withEvent：方法

作用

寻找并返回最合适的view(能够响应事件的那个最合适的view)

注 意：不管这个控件能不能处理事件，也不管触摸点在不在这个控件上，事件都会先传递给这个控件，随后再调用hitTest:withEvent:方法

拦截事件的处理

// 这里redView是whiteView的第0个子控件
#import "redView.h"
 
@implementation redView
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{ 
   return self;
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
   NSLog(@"red-touch");
}@end
// 或者
#import "whiteView.h"
 
@implementation whiteView
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{ 
   return self.subviews[0];
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
   NSLog(@"white-touch");
}
@end

#import "WYWindow.h"
@implementation WYWindow
// 什么时候调用:只要事件一传递给一个控件，那么这个控件就会调用自己的这个方法
// 作用:寻找并返回最合适的view
// UIApplication -> [UIWindow hitTest:withEvent:]寻找最合适的view告诉系统
// point:当前手指触摸的点
// point:是方法调用者坐标系上的点
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{
    // 1.判断下窗口能否接收事件
     if (self.userInteractionEnabled == NO || self.hidden == YES ||  self.alpha <= 0.01) return nil; 
    // 2.判断下点在不在窗口上 
    // 不在窗口上 
    if ([self pointInside:point withEvent:event] == NO) return nil; 
    // 3.从后往前遍历子控件数组 
    int count = (int)self.subviews.count; 
    for (int i = count - 1; i >= 0; i--)     { 
    // 获取子控件
    UIView *childView = self.subviews[i]; 
    // 坐标系的转换,把窗口上的点转换为子控件上的点 
    // 把自己控件上的点转换成子控件上的点 
    CGPoint childP = [self convertPoint:point toView:childView]; 
    UIView *fitView = [childView hitTest:childP withEvent:event]; 
    if (fitView) {
    // 如果能找到最合适的view 
    return fitView; 
    }
    } 
    // 4.没有找到更合适的view，也就是没有比自己更合适的view 
    return self;
    }
    // 作用:判断下传入过来的点在不在方法调用者的坐标系上
    // point:是方法调用者坐标系上的点
    //- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
    //{
    // return NO;
    //}
    - (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
    NSLog(@"%s",__func__);
    }
    @end

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{
    UIView *view = [super hitTest:point withEvent:event];
    if (view == self) {
        return nil;
    }
    return view;
}

@implementation WYView 
//只要点击控件,就会调用touchBegin,如果没有重写这个方法,自己处理不了触摸事件
// 上一个响应者可能是父控件
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
// 默认会把事件传递给上一个响应者,上一个响应者是父控件,交给父控件处理
[super touchesBegan:touches withEvent:event]; 
// 注意不是调用父控件的touches方法，而是调用父类的touches方法
// super是父类 superview是父控件 
}
@end

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

前言：

按照时间顺序，事件的生命周期：
　　事件的产生和传递（事件如何从父控件传递到子控件并寻找到最合适的view、寻找最合适的view的底层实现、拦截事件的处理）->找到最合适的view后事件的处理（touches方法的重写，也就是事件的响应）

重点和难点是：
　　1.如何寻找最合适的view
　　2.寻找最合适的view的底层实现（hitTest:withEvent:底层实现）

（一）iOS中的事件

iOS中的事件可以分为3大类型：
1.触摸事件

2.加速计事件

3.远程控制事件

这里我们只讨论iOS中的触摸事件。

1.1.响应者对象(UIResponder)

在iOS中不是任何对象都能处理事件，只有继承了UIResponder的对象才能接受并处理事件，我们称之为“响应者对象”。以下都是继承自UIResponder的，所以都能接收并处理事件。

UIApplication
UIWindows
UIViewController
UIView

那么为什么继承自UIResponder的类就能够接收并处理事件呢？

因为UIResponder中提供了以下4个对象方法来处理触摸事件。UIResponder内部提供了以下方法来处理事件触摸事件

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event;
加速计事件
- (void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event;
- (void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event;
- (void)motionCancelled:(UIEventSubtype)motion withEvent:(UIEvent *)event;
远程控制事件
- (void)remoteControlReceivedWithEvent:(UIEvent *)event;

（二）事件的处理

下面以UIView为例来说明触摸事件的处理。

// UIView是UIResponder的子类，可以覆盖下列4个方法处理不同的触摸事件
// 一根或者多根手指开始触摸view，系统会自动调用view的下面方法
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
// 一根或者多根手指在view上移动，系统会自动调用view的下面方法（随着手指的移动，会持续调用该方法）
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
// 一根或者多根手指离开view，系统会自动调用view的下面方法
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
// 触摸结束前，某个系统事件(例如电话呼入)会打断触摸过程，系统会自动调用view的下面方法
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
// 提示：touches中存放的都是UITouch对象

需要注意的是：以上四个方法是由系统自动调用的，所以可以通过重写该方法来处理一些事件。

1.如果两根手指同时触摸一个view，那么view只会调用一次touchesBegan:withEvent:方法，touches参数中装着2个UITouch对象

2.如果这两根手指一前一后分开触摸同一个view，那么view会分别调用2次touchesBegan:withEvent:方法，并且每次调用时的touches参数中只包含一个UITouch对象

3.重写以上四个方法，如果是处理UIView的触摸事件。必须要自定义UIView子类继承自UIView。因为苹果不开源，没有把UIView的.m文件提 供给我们。我们只能通过子类继承父类，重写子类方法的方式处理UIView的触摸事件（注意：我说的是UIView触摸事件而不是说的 UIViewController的触摸事件）。

4.如果是处理UIViewController的触摸事件，那么在控制器的.m文件中直接重写那四个方法即可！

/************************自定义UIView的.h.m文件************************/

#import 
 
@interface WYView : UIView
@end

#import "WYView.h"
@implementation WYView
// 开始触摸时就会调用一次这个方法
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 
    NSLog(@"摸我干啥！");
}
// 手指移动就会调用这个方法
// 这个方法调用非常频繁
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event{ 
    NSLog(@"移动过程中持续调用！");
}
// 手指离开屏幕时就会调用一次这个方法
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event{ 
    NSLog(@"手放开还能继续玩耍！");
}
@end

/**************************控制器的.m文件*************************/

#import "ViewController.h"
#import "WYView.h"
@interface ViewController ()
@end@implementation ViewController
- (void)viewDidLoad { 
    [super viewDidLoad]; 
// 创建自定义view 
    WYView *touchView = [[WYView alloc] initWithFrame:CGRectMake(100, 100, 100, 100)]; 
// 背景颜色 
    touchView.backgroundColor = [UIColor redColor]; 
// 添加到父控件 
    [self.view addSubview:touchView]; 
}
@end

注 意：有人认为，我要是处理控制器的自带的view的事件就不需要自定义UIView子类继承于UIView，因为可以在viewController.m 文件中重写touchBegan:withEvent:方法，但是，我们此处讨论的是处理UIView的触摸事件，而不是处理 UIViewController的触摸事件。你如果是在viewController.m文件中重写touchBegan:withEvent:方法，相当于处理的是viewController的触摸事件，因为viewController也是继承自UIResponder，所以会给人一种错觉。
所以，还是那句话，想处理UIView的触摸事件，必须自定义UIView子类继承自UIView。

2.1.UIView的拖拽

那么，如何实现UIView的拖拽呢?也就是让UIView随着手指的移动而移动。
　　- 重写touchsMoved:withEvent:方法
此时需要用到参数touches，下面是UITouch的属性和方法：

NS_CLASS_AVAILABLE_IOS(2_0) @interface UITouch : NSObject
 
@property(nonatomic,readonly) NSTimeInterval      timestamp;
@property(nonatomic,readonly) UITouchPhase        phase;
@property(nonatomic,readonly) NSUInteger          tapCount;   // touch down within a certain point within a certain amount of time
 
// majorRadius and majorRadiusTolerance are in points
// The majorRadius will be accurate +/- the majorRadiusTolerance
@property(nonatomic,readonly) CGFloat majorRadius NS_AVAILABLE_IOS(8_0);
@property(nonatomic,readonly) CGFloat majorRadiusTolerance NS_AVAILABLE_IOS(8_0);
 
@property(nullable,nonatomic,readonly,strong) UIWindow                        *window;
@property(nullable,nonatomic,readonly,strong) UIView                          *view;
@property(nullable,nonatomic,readonly,copy)   NSArray  *gestureRecognizers NS_AVAILABLE_IOS(3_2);
 
- (CGPoint)locationInView:(nullable UIView *)view;
- (CGPoint)previousLocationInView:(nullable UIView *)view;
 
// Force of the touch, where 1.0 represents the force of an average touch
@property(nonatomic,readonly) CGFloat force NS_AVAILABLE_IOS(9_0);
// Maximum possible force with this input mechanism
@property(nonatomic,readonly) CGFloat maximumPossibleForce NS_AVAILABLE_IOS(9_0);

2.1.1.UITouch对象

当用户用一根手指触摸屏幕时，会创建一个与手指相关的UITouch对象

一根手指对应一个UITouch对象

如果两根手指同时触摸一个view，那么view只会调用一次touchesBegan:withEvent:方法，touches参数中装着2个UITouch对象

如果这两根手指一前一后分开触摸同一个view，那么view会分别调用2次touchesBegan:withEvent:方法，并且每次调用时的touches参数中只包含一个UITouch对象

2.1.1.1.UITouch的作用

保存着跟手指相关的信息，比如触摸的位置、时间、阶段

当手指移动时，系统会更新同一个UITouch对象，使之能够一直保存该手指在的触摸位置

当手指离开屏幕时，系统会销毁相应的UITouch对象
提 示:iPhone开发中，要避免使用双击事件！

2.1.1.2.UITouch的属性


触摸产生时所处的窗口
@property(nonatomic,readonly,retain) UIWindow *window;
 
触摸产生时所处的视图
@property(nonatomic,readonly,retain) UIView *view
;
 
短时间内点按屏幕的次数，可以根据tapCount判断单击、双击或更多的点击
@property(nonatomic,readonly) NSUInteger tapCount;
 
记录了触摸事件产生或变化时的时间，单位是秒
@property(nonatomic,readonly) NSTimeInterval timestamp;
 
当前触摸事件所处的状态
@property(nonatomic,readonly) UITouchPhase phase;

2.1.1.3.UITouch的方法


(CGPoint)locationInView:(UIView *)view;
// 返回值表示触摸在view上的位置
// 这里返回的位置是针对view的坐标系的（以view的左上角为原点(0, 0)）
// 调用时传入的view参数为nil的话，返回的是触摸点在UIWindow的位置
 
(CGPoint)previousLocationInView:(UIView *)view;
// 该方法记录了前一个触摸点的位置

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event{ 
    // 想让控件随着手指移动而移动,监听手指移动 
    // 获取UITouch对象 
    UITouch *touch = [touches anyObject]; 
    // 获取当前点的位置 
    CGPoint curP = [touch locationInView:self]; 
    // 获取上一个点的位置 
    CGPoint preP = [touch previousLocationInView:self]; 
    // 获取它们x轴的偏移量,每次都是相对上一次 
    CGFloat offsetX = curP.x - preP.x; 
    // 获取y轴的偏移量 
    CGFloat offsetY = curP.y - preP.y; 
    // 修改控件的形变或者frame,center,就可以控制控件的位置 
    // 形变也是相对上一次形变(平移) 
    // CGAffineTransformMakeTranslation:会把之前形变给清空,重新开始设置形变参数 
    // make:相对于最原始的位置形变 
    // CGAffineTransform t:相对这个t的形变的基础上再去形变 
    // 如果相对哪个形变再次形变,就传入它的形变 
    self.transform = CGAffineTransformTranslate(self.transform, offsetX, offsetY);}

（三）iOS中的事件的产生和传递

3.1.事件的产生

发生触摸事件后，系统会将该事件加入到一个由UIApplication管理的事件队列中,为什么是队列而不是栈？因为队列的特点是FIFO，即先进先出，先产生的事件先处理才符合常理，所以把事件添加到队列。

UIApplication会从事件队列中取出最前面的事件，并将事件分发下去以便处理，通常，先发送事件给应用程序的主窗口（keyWindow）。

主窗口会在视图层次结构中找到一个最合适的视图来处理触摸事件，这也是整个事件处理过程的第一步。

找到合适的视图控件后，就会调用视图控件的touches方法来作具体的事件处理。

3.2.事件的传递

触摸事件的传递是从父控件传递到子控件
也就是UIApplication->window->寻找处理事件最合适的view
注 意: 如果父控件不能接受触摸事件，那么子控件就不可能接收到触摸事件

应用如何找到最合适的控件来处理事件？

1.首先判断主窗口（keyWindow）自己是否能接受触摸事件

2.判断触摸点是否在自己身上

3.子控件数组中从后往前遍历子控件，重复前面的两个步骤（所谓从后往前遍历子控件，就是首先查找子控件数组中最后一个元素，然后执行1、2步骤）

4.view，比如叫做fitView，那么会把这个事件交给这个fitView，再遍历这个fitView的子控件，直至没有更合适的view为止。

5.如果没有符合条件的子控件，那么就认为自己最合适处理这个事件，也就是自己是最合适的view。

UIView不能接收触摸事件的三种情况：

1.不允许交互：userInteractionEnabled = NO
2.隐藏：如果把父控件隐藏，那么子控件也会隐藏，隐藏的控件不能接受事件
3.透明度：如果设置一个控件的透明度<0.01，会直接影响子控件的透明度。alpha：0.0~0.01为透明。

注 意:默认UIImageView不能接受触摸事件，因为不允许交互，即userInteractionEnabled = NO。所以如果希望UIImageView可以交互，需要设置UIImageView的userInteractionEnabled = YES。


总结一下

1.点击一个UIView或产生一个触摸事件A，这个触摸事件A会被添加到由UIApplication管理的事件队列中（即，首先接收到事件的是UIApplication）。

2.UIApplication会从事件对列中取出最前面的事件（此处假设为触摸事件A），把事件A传递给应用程序的主窗口（keyWindow）。

3.窗口会在视图层次结构中找到一个最合适的视图来处理触摸事件。（至此，第一步已完成）

前言

简单工厂模式每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度，违背了“开闭原则”。
“工厂方法模式”是对简单工厂模式的进一步抽象化，其好处是可以使系统在不修改原来代码的情况下引进新的产品，即满足开闭原则。

优点：

• 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程。
• 灵活性增强，对于新产品的创建，只需多写一个相应的工厂类。
• 典型的解耦框架。高层模块只需要知道产品的抽象类，无须关心其他实现类，满足迪米特法则、依赖倒置原则和里氏替换原则。

缺点：

• 类的个数容易过多，增加复杂度
• 增加了系统的抽象性和理解难度
• 抽象产品只能生产一种产品，此弊端可使用抽象工厂模式解决。

应用场景：

• 客户只知道创建产品的工厂名，而不知道具体的产品名。如 TCL 电视工厂、海信电视工厂等。
• 创建对象的任务由多个具体子工厂中的某一个完成，而抽象工厂只提供创建产品的接口。
• 客户不关心创建产品的细节，只关心产品的品牌

代码实现

工厂方法模式的主要角色如下。

1. 抽象工厂：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法 newProduct() 来创建产品。
2. 具体工厂：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
3. 抽象产品：定义了产品的规范，描述了产品的主要特性和功能。

4. 具体产品：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。

   
   
   
   

   在这里插入图片描述
   
   

   kotlin代码实现

//抽象产品：提供了产品的接口

interface IProduct{

    fun setPingPai(string: String)

    fun showName() :String

}

//具体产品1：实现抽象产品中的抽象方法

class Dog : IProduct{

    var pinPai:String? = null

    override fun setPingPai(string: String) {

        this.pinPai = string

    }



    override fun showName() = "dog"



}

//具体产品2：实现抽象产品中的抽象方法

class Cat : IProduct{

    var pinPai:String? = null

    override fun setPingPai(string: String) {

        this.pinPai = string

    }

    override fun showName() = "cat"

}

//抽象工厂：提供了厂品的生成方法

interface IFactory{

    fun getPinPai():String

    fun createProduct(type:Int):IProduct

}

//具体工厂1：实现了厂品的生成方法

class ABCFactory():IFactory{

    override fun getPinPai() = "ABC"



    override fun createProduct(type: Int): IProduct {

        return when(type){

            1-> Dog().apply { setPingPai(getPinPai()) }

            2-> Cat().apply { setPingPai(getPinPai()) }

            else -> throw NullPointerException()

        }

    }



}

//具体工厂2：实现了厂品的生成方法

class CBDFactory():IFactory{

    override fun getPinPai() = "CBD"

    override fun createProduct(type: Int): IProduct {

        return when(type){

            1-> Dog().apply { setPingPai(getPinPai()) }

            2-> Cat().apply { setPingPai(getPinPai()) }

            else -> throw NullPointerException()

        }

    }



}

Android源码分析

ThreadFactory

在这里插入图片描述

//抽象产品

public interface Runnable {

    public abstract void run();

}

 

//抽象工厂

public interface ThreadFactory {

    Thread newThread(Runnable r);

}

具体的实现

//实现1 TaskThreadFactory

class TaskThreadFactory(var name: String) : ThreadFactory {

    private val mThreadNumber = AtomicInteger(1)

    override fun newThread(r: Runnable): Thread {

        return Thread(r, name + "#" + mThreadNumber.getAndIncrement())

    }

}

//实现2 DiskLruCacheThreadFactory 

  private static final class DiskLruCacheThreadFactory implements ThreadFactory {

    @Override

    public synchronized Thread newThread(Runnable runnable) {

      Thread result = new Thread(runnable, "glide-disk-lru-cache-thread");

      result.setPriority(Thread.MIN_PRIORITY);

      return result;

    }

  }

解释：

参数Runnable r，我们可以创建很多此类线程的产品类，我们还可以创建工厂来创造某类专用线程

在 UIView 中有一个 CALayer 的属性，负责 UIView 具体内容的显示。具体过程是系统会把 UIView 显示的内容（包括 UILabel 的文字，UIImageView 的图片等）绘制在一张画布上，完成后倒出图片赋值给 CALayer 的 contents 属性，完成显示。

这其中的工作都是在主线程中完成的，这就导致了主线程频繁的处理 UI 绘制的工作，如果要绘制的元素过多，过于频繁，就会造成卡顿。

那么是否可以将复杂的绘制过程放到后台线程中执行，从而减轻主线程负担，来提升 UI 流畅度呢？

答案是可以的，系统给我们留下的异步绘制的口子，请看下面的流程图，它是我们进行基本绘制的基础。

UIView 调用 setNeedsDisplay 方法其实是调用其 layer 属性的同名方法，这时 layer 并不会立刻调用 display 方法，而是要等到当前 runloop 即将结束的时候调用 display，进入到绘制流程。在 UIView 中 layer.delegate 就是 UIView 本身，UIView 并没有实现 displayLayer: 方法，所以进入系统的绘制流程，我们可以通过实现 displayLayer: 方法来进行异步绘制。

有了上面的异步绘制原理流程图，我们可以得到一个实现异步绘制的初步思路：
在“异步绘制入口”去开辟子线程，然后在子线程中实现和系统类似的绘制流程。

二、系统绘制流程

要实现异步绘制，我们首先要了解系统的绘制流程，看下面一张流程图：

三、异步绘制流程

我们看一幅时序图

#import "AsyncDrawLabel.h"
#import <CoreText/CoreText.h>
 
@implementation AsyncDrawLabel
 
- (void)setText:(NSString *)text {
    _text = text;
    [self.layer setNeedsDisplay];
}
 
- (void)setFont:(UIFont *)font {
    _font = font;
    [self.layer setNeedsDisplay];
}
 
- (void)displayLayer:(CALayer *)layer {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        __block CGSize size;
        dispatch_sync(dispatch_get_main_queue(), ^{
            size = self.bounds.size;
        });
        UIGraphicsBeginImageContextWithOptions(size, NO, UIScreen.mainScreen.scale);
        CGContextRef context = UIGraphicsGetCurrentContext();
        [self draw:context size:size];
        UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
        UIGraphicsEndImageContext();
        dispatch_async(dispatch_get_main_queue(), ^{
            self.layer.contents = (__bridge id)image.CGImage;
        });
    });
}
 
- (void)draw:(CGContextRef)context size:(CGSize)size {
    // 将坐标系上下翻转，因为底层坐标系和 UIKit 坐标系原点位置不同。
    CGContextSetTextMatrix(context, CGAffineTransformIdentity);
    CGContextTranslateCTM(context, 0, size.height); // 原点为左下角
    CGContextScaleCTM(context, 1, -1);
    
    CGMutablePathRef path = CGPathCreateMutable();
    CGPathAddRect(path, NULL, CGRectMake(0, 0, size.width, size.height));
    
    NSMutableAttributedString *attrStr = [[NSMutableAttributedString alloc]initWithString:self.text];
    [attrStr addAttribute:NSFontAttributeName value:self.font range:NSMakeRange(0, self.text.length)];
    
    CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString((CFAttributedStringRef)attrStr);
    CTFrameRef frame = CTFramesetterCreateFrame(framesetter, CFRangeMake(0, attrStr.length), path, NULL);
    CTFrameDraw(frame, context);
}
 
@end

AsyncDrawLabel 是一个继承 UIView 的类，其 Label 的文本绘制功能需要我们自己实现。

我们在 - (void)displayLayer:(CALayer *)layer 方法中异步在全局队列中创建上下文环境然后使用 - (void)draw:(CGContextRef)context size:(CGSize)size 方法进行文本的简单绘制，再回到主线程为 self.layer.contents 赋值。从而完成了一个简单的异步绘制。

当然这样的绘制的问题是，如果绘制数量较多，绘制频繁，会阻塞全局队列，因为全局队列中还有一些系统提交的任务需要执行，可能会对其造成影响。

YYAsyncLayer

我们需要更加优化的方式去管理异步绘制的线程和执行流程，使用 YYAsyncLayer 可以让我们把注意力放在具体的绘制（需要我们做的是上面代码中 - draw: size: 做的事情），而不需要考虑线程的管理，绘制的时机等，大大提高绘制的效率以及我们编程的速度。

YYAsyncLayer 的主要流程如下

在主线程的 RunLoop 中注册一个 observer，它的优先级要比系统的 CATransaction 低，保证系统先做完必须的工作。

把需要异步绘制的操作集中起来。比如设置字体、颜色、背景色等，不是设置一个就绘制一个，而是把它们集中起来，RunLoop 会在 observer 需要的时机通知统一处理。

处理时机到时，执行异步绘制，并在主线程中把绘制结果传递给 layer.contents。

流程图如下：

使用 YYAsyncLayer 的代码：

#import "AsyncDrawLabel.h"
#import <YYAsyncLayer.h>
#import <CoreText/CoreText.h>
 
@interface AsyncDrawLabel ()<YYAsyncLayerDelegate>
 
@end
 
@implementation AsyncDrawLabel
 
+ (Class)layerClass {
    return YYAsyncLayer.class;
}
 
- (void)setText:(NSString *)text {
    _text = text.copy;
    [self commitTransaction];
}
 
- (void)setFont:(UIFont *)font {
    _font = font;
    [self commitTransaction];
}
 
- (void)layoutSubviews {
    [super layoutSubviews];
    [self commitTransaction];
}
 
- (void)contentsNeedUpdated {
    [self.layer setNeedsDisplay];
}
 
- (void)commitTransaction {
    [[YYTransaction transactionWithTarget:self selector:@selector(contentsNeedUpdated)] commit];
}
 
// 在这里创建异步绘制的任务
- (YYAsyncLayerDisplayTask *)newAsyncDisplayTask {
    YYAsyncLayerDisplayTask *task = [YYAsyncLayerDisplayTask new];
    task.willDisplay = ^(CALayer * _Nonnull layer) {
        
    };
    task.display = ^(CGContextRef  _Nonnull context, CGSize size, BOOL (^ _Nonnull isCancelled)(void)) {
        if (isCancelled() || self.text.length == 0) {
            return;
        }
        // 在这里进行异步绘制
        [self draw:context size:size];
    };
    task.didDisplay = ^(CALayer * _Nonnull layer, BOOL finished) {
        if (finished) {
            
        } else {
            
        }
    };
    return task;
}
 
- (void)draw:(CGContextRef)context size:(CGSize)size {
    // 将坐标系上下翻转，因为底层坐标系和 UIKit 坐标系原点位置不同。
    CGContextSetTextMatrix(context, CGAffineTransformIdentity);
    CGContextTranslateCTM(context, 0, size.height); // 原点为左下角
    CGContextScaleCTM(context, 1, -1);
    
    CGMutablePathRef path = CGPathCreateMutable();
    CGPathAddRect(path, NULL, CGRectMake(0, 0, size.width, size.height));
    
    NSMutableAttributedString *attrStr = [[NSMutableAttributedString alloc]initWithString:self.text];
    [attrStr addAttribute:NSFontAttributeName value:self.font range:NSMakeRange(0, self.text.length)];
    
    CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString((CFAttributedStringRef)attrStr);
    CTFrameRef frame = CTFramesetterCreateFrame(framesetter, CFRangeMake(0, attrStr.length), path, NULL);
    CTFrameDraw(frame, context);
}
@end

原文链接：https://blog.csdn.net/wywinstonwy/article/details/105660643

Auto Layout 原理

前言

Category是我们平时用到的比较多的一种技术，比如说给某个类增加方法，添加成员变量，或者用Category优化代码结构。
我们通过下面这几个问题作为切入点，结合runtime的源码，探究一下Category的底层原理。
我们在Category中，可以直接添加方法，而且我们也都知道，添加的方法会合并到本类当中，同时我们也可以声明属性，但是此时的属性没有功能，也就是不能存值，这就类似于Swift中的计算属性，如果我们想让这个属性可以储存值，就要用runtime的方式，动态的添加。

探究

1. Category为什么能添加方法不能添加成员变量
首先我们先创建一个Person类，然后创建一个Person+Run的Category，并在Person+Run中实现-run方法。
我们可以使用命令行对Person+Run.m进行编译

xcrun -sdk iphonesimulator clang -rewrite-objc Person+Run.m

得到一个Person+Run.cpp文件，在文件的底部，可以找到这样一个结构体

struct _category_t {
    const char *name;
    struct _class_t *cls;
    const struct _method_list_t *instance_methods;
    const struct _method_list_t *class_methods;
    const struct _protocol_list_t *protocols;
    const struct _prop_list_t *properties;
};

这些字段几乎都是见名知意了。
每一个Category都会编译然后存储在一个_category_t类型的变量中

static struct _category_t _OBJC_$_CATEGORY_Person_$_Run __attribute__ ((used, section ("__DATA,__objc_const"))) = 
{
    "Person",
    0, // &OBJC_CLASS_$_Person,
    (const struct _method_list_t *)&_OBJC_$_CATEGORY_INSTANCE_METHODS_Person_$_Run,
    0,
    0,
    0,
};

因为我们的Person+Run里面只有一个实例方法，从上述代码中来看，也只有对应的位置传值了。
通过这个_category_t的结构结构我们也可以看出，属性存储在_prop_list_t，这里并没有类中的objc_ivar_list结构体，所以Category的_category_t结构体中根本没有储存ivar的地方，所以不能添加成员变量。
如果我们在分类中手动为成员变量添加了set和get方法之后，也可以调用，但实际上是没有内存来储值的，这就好像Swift中的计算属性，只起到了计算的作用，就相当于是两个方法（set和get），但是并不能拥有真用的内存来存储值。
举个例子

@property (copy, nonatomic) NSString * name;

下面这个声明如果实在类中，系统会默认帮我们声明一个成员变量_name, 在.h中声明setName和name两个方法，并提供setName和name方法的默认实现。
如果是在Category中，只相当于声明setName和name两个方法，没有实现也没有_name。

2. Category的方法是何时合并到类中的
大家都知道Category分类肯定是我们的应用启动是，通过运行时特性加载的，但是这个加载过程具体的细节就要结合runtime的源码来分析了。
runtime源码太多了，我们先通过大概浏览代码来定位实现功能的相关位置。
我从objc-runtime-new.mm中找到了下面这个方法。

void attachLists(List* const * addedLists, uint32_t addedCount)

而且他的注释一些的很清楚，修复类的方法，协议和变量列表，关联还未关联的分类。
然后我们继续找，就找到了我们需要的这个方法。

void attachLists(List* const * addedLists, uint32_t addedCount)

我们从其中摘出一段代码来分析就可以解决我们的问题了。

// many lists -> many lists
  uint32_t oldCount = array()->count;
  uint32_t newCount = oldCount + addedCount;
  setArray((array_t *)realloc(array(), array_t::byteSize(newCount)));
  array()->count = newCount;
  memmove(array()->lists + addedCount, array()->lists, 
          oldCount * sizeof(array()->lists[0]));
  memcpy(array()->lists, addedLists, 
         addedCount * sizeof(array()->lists[0]));

在调用此方法之前我们所有的分类会被方法一个list里面（每一个分类都是一个元素），然后再调用attachLists方法，我们可以看到，在realloc的时候传进一个newCount，这是因为要增加分类中的方法，所以需要对之前的数组扩容，在扩容结束后先调用了memmove方法，在调用memcopy，大家可以上网查一下这两个方法具体的区别，这里简单一说，其实完成的效果都是把后面的内存的内容拷贝到前面内存中去，但是memmove可以处理内存重叠的问题。
其实也就是首先将原来数组中的每个元素先往后移动（我们要添加几个元素，就移动几位），因为移动后的位置，其实也是数组自己的内存空间，所以存在重叠问题，直接移动会导致元素丢失的问题，所以用memmove（会检测是否有内存重叠）。
移动完之后，把我们储存分类中方法的list中的元素移动到数组前面位置。
过程就是这样子了，其实我们第三个问题就顺便解决完了。

3. Category方法和类中方法的执行顺序
上面其实说到了，类中原来的方法是要往后面移动的，分类的方法添加到前面的位置，而且调用方法的时候是在list中遍历查找，所以我们调用方法的时候，肯定会先调用到Category中的方法，但是这并不是覆盖，因为我们的原方法还在，只是这中机制保证了如果分类中有重写类的方法，会被优先查找到。

4. +load和+initialize的区别
对于这个问题我们从两个角度出发分析，调用方式和调用时刻。

+load
简单的举一个例子，我们创建一个Person类，然后重写+load方法，然后为Person新建两个Category，都分别实现+load。

@implementation Person
+ (void)load {
    NSLog(@"Person - load");
}
@end

@implementation Person (Test1)
+ (void)load {
    NSLog(@"Person Test1 - load");
}
@end

@implementation Person (Test2)
+ (void)load {
    NSLog(@"Person Test2 - load");
}
@end

当我们进行项目的时候，会得到下面的打印结果。

2020-09-14 09:34:41.900161+0800 Category[4533:53426] Person - load
2020-09-14 09:34:41.900629+0800 Category[4533:53426] Person Test1 - load
2020-09-14 09:34:41.900700+0800 Category[4533:53426] Person Test2 - load

我们并没有使用这个Person类和他的Category，所以应该是项目运行后，runtime在加载类和分类的时候，就会调用+load方法。
我们从源码中找到下面这个方法
void load_images(const char *path __unused, const struct mach_header *mh)
方法中的最后一行调用了call_load_methods()，这个call_load_methods()中就是实现了+load的调用方式。
下面是call_load_methods()函数的实现 ，大家简单浏览一遍

void call_load_methods(void)
{
    static bool loading = NO;
    bool more_categories;

    loadMethodLock.assertLocked();

    // Re-entrant calls do nothing; the outermost call will finish the job.
    if (loading) return;
    loading = YES;

    void *pool = objc_autoreleasePoolPush();

    do {
        // 1. Repeatedly call class +loads until there aren't any more
        while (loadable_classes_used > 0) {
            call_class_loads();
        }

        // 2. Call category +loads ONCE
        more_categories = call_category_loads();

        // 3. Run more +loads if there are classes OR more untried categories
    } while (loadable_classes_used > 0  ||  more_categories);

    objc_autoreleasePoolPop(pool);

    loading = NO;
}

从源码中很清楚的可以看到， 先调用call_class_loads()， 再调用call_category_loads()，这就说明了在调用所有的+load方法时，实现调用了所有类的+load方法，再去调用分类中的+load方法。
然后我们在进入到call_class_loads()函数中

static void call_class_loads(void)
{
    int i;
    
    // Detach current loadable list.
    struct loadable_class *classes = loadable_classes;
    int used = loadable_classes_used;
    loadable_classes = nil;
    loadable_classes_allocated = 0;
    loadable_classes_used = 0;
    
    // Call all +loads for the detached list.
    for (i = 0; i < used; i++) {
        Class cls = classes[i].cls;
        load_method_t load_method = (load_method_t)classes[i].method;
        if (!cls) continue; 

        if (PrintLoading) {
            _objc_inform("LOAD: +[%s load]\n", cls->nameForLogging());
        }
        (*load_method)(cls, @selector(load));
    }
    
    // Destroy the detached list.
    if (classes) free(classes);
}

从中间的循环中可以看出，是取到了每个类的+load函数的指针，直接通过指针调用了这个函数。 call_category_loads()函数中体现出来的Category的+load方法的调用，也是同理。
同时这也解答了我们的另一个疑惑，那就是为什么总是先调用类的+load，在调用Category的+load。
思考：如果存在继承的情况，+load又会是怎样的调用顺序呢？
从上面call_class_loads()函数中可以看到有一个list：loadable_classes，我们猜测这里面应该就是存放着我们所有的类，因为下面的循环是从0开始循环，所以我们要研究所有的类的+load方法的执行顺序，就要看这个list中的类的顺序是怎么样的。
我们从个源码中可以找到这样一个方法，prepare_load_methods，在其实现中调用了schedule_class_load方法，我们看一下schedule_class_load的源码

static void schedule_class_load(Class cls)
{
    if (!cls) return;
    ASSERT(cls->isRealized());  // _read_images should realize

    if (cls->data()->flags & RW_LOADED) return;

    // Ensure superclass-first ordering
    schedule_class_load(cls->superclass);

    add_class_to_loadable_list(cls);
    cls->setInfo(RW_LOADED); 
}

从源码中schedule_class_load(cls->superclass);这一句中可以看出，递归调用自己本身，并且传入自己的父类，结果递归之后，才调用add_class_to_loadable_list，这就说明父类总是在子类前面加入到list当中，所有在调用一个类的+load方法之前，肯定要先调用其父类的+load方法。
那如果是其他没有继承关系的类呢，这就跟编译顺序有关系了，大家可以自己尝试验证一下。
小结：

• +load方法会在runtime加载类和分类时调用

• 每个类和分类的+load方法之后调用一次

• 调用顺序：先调用类的+load

+initialize
+initialize的调用是不同的，如果某一个类我们没有使用过，他的+initialize方法是不会调用的，到我们使用这个类（调用了类的某个方法）的时候，才会触发+initialize方法的调用。

@implementation Person
+ (void)initialize {
    NSLog(@"Person - initialize");
}
@end

@implementation Person (Test1)
+ (void)initialize {
    NSLog(@"Person Test1 - initialize");
}
@end

@implementation Person (Test2)
+ (void)initialize {
    NSLog(@"Person Test2 - initialize");
}
@end

当我们执行[Person alloc];的时候，才会走+initialize方法，而且执行的Category中的+initialize：

2020-09-14 10:40:23.579623+0800 Category[9134:94173] Person Test2 - initialize

这个我们之前已经说过了，Category的方法会添加list的前面，所以会先被找到并且执行，所以我们猜测+initialize的执行是走的正常的消息机制，objc_msgSend。

由于objc_msgSend实现并没有完全开源，都是汇编代码，所以我们需要换一个思路来研究源码。

objc_msgSend本质是什么？以调用实例方法为例，其实就是通过isa指针找到该类，然后寻找方法，找到之后调用。如果没有找到则通过superClass找到父类，继续查找方法。上面的例子中，我们仅仅是调用了一个alloc方法，但是也执行了+initialize方法，所以我们猜测+initialize会在查找方法的时候调用到。通过这个思路，我们定位到了class_getInstanceMethod()函数（class_getInstanceMethod函数就是在类中查找某个sel时候调用的），在这个函数中，又调用了IMP lookUpImpOrForward(id inst, SEL sel, Class cls, int behavior)

在该函数中我们可以找到下面这段代码

if ((behavior & LOOKUP_INITIALIZE)  &&  !cls->isInitialized()) {
    initializeNonMetaClass (_class_getNonMetaClass(cls, inst));
}

可以看出如果类还没有执行+initialize 就会先执行，我们再看一下if语句中的initializeNonMetaClass函数，他会先拿到superClass，执行superClass的+initialize

supercls = cls->superclass;
if (supercls  &&  !supercls->isInitialized()) {
    initializeNonMetaClass(supercls);
}

这就是存在继承的情况，为什么会先执行父类的+initialize。

大总结

1. 调用方式：
   load是根据函数地址直接调用
   initialize是通过消息机制objc_msgSend调用
   

2. 调用时刻：
   

   load是在runtime加载类和分类时调用（只会调用一次）
   initialize是在类第一次收到消息时调用个，默认没有继承的情况下每个类只会initialize一次（父类的initialize可能会被执行多次）

3. 调用顺序
   

   load
   先调用类的load：先编译的类先调用，子类调用之前，先调用父类的
   在调用Category的load：先编译的先调用
   

   initialize
   先初始化父类
   在初始化子类（初始化子类可能调用父类的initialize）

补充
上面总结的时候说到父类的initialize会被执行多次，什么情况下会被执行多次，为什么？举个例子：

@implementation Person
+ (void)initialize {
    NSLog(@"Person - initialize");
}
@end

@implementation Student
@end

Student类继承Person类，并且只有父类Person中实现了+initialize，Student类中并没有实现
此时我们调用[Student alloc];， 会得到如下的打印。

2020-09-14 11:31:55.377569+0800 Category[11483:125034] Person - initialize
2020-09-14 11:31:55.377659+0800 Category[11483:125034] Person - initialize

Person的+initialize被执行了两次，但这两个意义是不同的，第一次执行是因为在调用子类的+initialize方法之前必须先执行父类的了+initialize，所以会打印一次。当要执行子类的+initialize时，通过消息机制，student类中并没有找到实现的+initialize的实现，所以要通过superClass指针去到父类中继续查找，因为父类中实现了+initialize，所以才会有了第二次的打印。

结尾
本文的篇幅略长，笔者按照自己的思路和想法写完了此文，陈述过程不一定那么调理和完善，大家在阅读过程中发现问题，可以留言交流。
感谢阅读。

转自：https://www.jianshu.com/p/141b04e376d4

复杂场景下的h5与小程序通信

一、背景

在套壳小程序盛行的当下， h5调用小程序能力来打破业务边界已成为家常便饭，h5与小程序的结合，极大地拓展了h5的能力边界，丰富了h5的功能。使许多以往纯h5只能想想或者实现难度极大的功能变得轻松简单。
但在套壳小程序中，h5与小程序通信存在以下几个问题：

• 注入小程序全局变量的时机不确定，可能调用的时候不存在小程序变量。和全局变量my相关的判断满天飞，每个使用的地方都需要判断是否已注入变量，否则就要创建监听。
• 小程序处理后的返回结果可能有多种，h5需要在具体使用时监听多个结果进行处理。
• 一旦监听建立，就无法取消，在组件销毁时如果没有判断组件状态容易导致内存泄漏。

二、在业务内的实践

• 因业务的特殊性，需要投放多端,小程序sdk的加载没有放到head里面，而是在应用启动时动态判断是小程序环境时自动注入的方式：

export function injectMiniAppScript() {
    if (isAlipayMiniApp() || isAlipayMiniAppWebIDE()) {
        const s = document.createElement('script'); 

        s.src = 'https://appx/web-view.min.js';
        s.onload = () => {
            // 加载完成时触发自定义事件
            const customEvent = new CustomEvent('myLoad', { detail:'' });
            document.dispatchEvent(customEvent);
        };

        s.onerror = (e) => {
            // 加载失败时上传日志
            uploadLog({
                tip: `INJECT_MINIAPP_SCRIPT_ERROR`,
            });
        };

        document.body.insertBefore(s, document.body.firstChild);
    }
}

// 处理扫脸签到逻辑
    const faceVerify = (): Promise => {

        return new Promise((resolve) => {
            const handle = () => {
                window.my.onMessage = (result: AlipaySignResult) => {
                    if (result.type === 'FACE_VERIFY_TIMEOUT' ||
                        result.type === 'DO_SIGN' ||
                        result.type === 'FACE_VERIFY' ||
                        result.type === 'LOCATION' ||
                        result.type === 'LOCATION_UNBELIEVABLE' ||
                        result.type === 'NOT_IN_ALIPAY') {
                        resolve(result);
                    }
                };

                window.my.postMessage({ action: SIGN_CONSTANT.FACE_VERIFY, activityId: id, userId: user.userId });
            };

            if (window.my) {
                handle();
            } else {
                // 先记录错误日志
                sendErrors('/threehours.3hours-errors.NO_MY_VARIABLE', { msg: '变量不存在' });
                // 监听load事件
                document.addEventListener('myLoad', handle);
            }
        });
    };

// 处理扫脸签到逻辑
    const faceVerify = (): Promise => {
        miniAppBus.postMessage({ action: SIGN_CONSTANT.FACE_VERIFY, activityId: id, userId: user.userId });
        return miniAppBus.subscribeAsync([
            'FACE_VERIFY_TIMEOUT',
            'DO_SIGN',
            'FACE_VERIFY',
            'LOCATION',
            'LOCATION_UNBELIEVABLE',
            'NOT_IN_ALIPAY',
        ])
    };

interface MiniAppEventBus {
           /**
           * @description 回调函数订阅单个、或多个type
           * @template T
           * @param {(string | string[])} type
           * @param {MiniAppMessageSubscriber} callback
           * @memberof MiniAppEventBus
           */
           subscribe(type: string | string[], callback: MiniAppMessageSubscriber): void;
           /**
           * @description Promise 订阅单个、或多个type
           * @template T
           * @param {(string | string[])} type
           * @returns {Promise>}
           * @memberof MiniAppEventBus
           */
           subscribeAsync(type: string | string[]): Promise>;
           /**
           * @description 取消订阅单个、或多个type
           * @param {(string | string[])} type
           * @returns {Promise}
           * @memberof MiniAppEventBus
           */
           unSubscribe(type: string | string[]): Promise;
           /**
           * @description postMessage替代，无需关注环境变量
           * @param {MessageToMiniApp} msg
           * @returns {Promise}
           * @memberof MiniAppEventBus
           */
           postMessage(msg: MessageToMiniApp): Promise;
       }

import { injectMiniAppScript } from './tools';

   /**
   * @description 小程序返回结果
   * @export
   * @interface MiniAppMessage
   */

   interface MiniAppMessageBase {
       type: string;
   }

   type MiniAppMessage = MiniAppMessageBase & {
       [P in keyof T]: T[P]
   }
   /**
   * @description 小程序接收消息
   * @export
   * @interface MessageToMiniApp
   */
   export interface MessageToMiniApp {
       action: string;
       [x: string]: unknown
   }

   interface MiniAppMessageSubscriber {
       (params: MiniAppMessage): void
   }
   interface MiniAppEventBus {
       /**
       * @description 回调函数订阅单个、或多个type
       * @template T
       * @param {(string | string[])} type
       * @param {MiniAppMessageSubscriber} callback
       * @memberof MiniAppEventBus
       */
       subscribe(type: string | string[], callback: MiniAppMessageSubscriber): void;
       /**
       * @description Promise 订阅单个、或多个type
       * @template T
       * @param {(string | string[])} type
       * @returns {Promise>}
       * @memberof MiniAppEventBus
       */
       subscribeAsync(type: string | string[]): Promise>;
       /**
       * @description 取消订阅单个、或多个type
       * @param {(string | string[])} type
       * @returns {Promise}
       * @memberof MiniAppEventBus
       */
       unSubscribe(type: string | string[]): Promise;
       /**
       * @description postMessage替代，无需关注环境变量
       * @param {MessageToMiniApp} msg
       * @returns {Promise}
       * @memberof MiniAppEventBus
       */
       postMessage(msg: MessageToMiniApp): Promise;
   }
   class MiniAppEventBus implements MiniAppEventBus{

       /**
       * @description: 监听函数
       * @type {Map}
       * @memberof MiniAppEventBus
       */
       listeners: Map;
       constructor() {
           this.listeners = new Map>>();
           this.init();
       }

       /**
       * @description 初始化
       * @private
       * @memberof MiniAppEventBus
       */
       private init() {
           if (!window.my) {
               // 引入脚本
               injectMiniAppScript();
           }

           this.startListen();
       }

       /**
       * @description 保证my变量存在的时候执行函数func
       * @private
       * @param {Function} func
       * @returns 
       * @memberof MiniAppEventBus
       */
       private async ensureEnv(func: Function) {
           return new Promise((resolve) => {
               const promiseResolve = () => {
                   resolve(func.call(this));
               };

               // 全局变量
               if (window.my) {
                   promiseResolve();
               }

               document.addEventListener('myLoad', promiseResolve);
           });
       }

       /**
       * @description 监听小程序消息
       * @private
       * @memberof MiniAppEventBus
       */
       private listen() {
           window.my.onMessage = (msg: MiniAppMessage) => {
               this.dispatch(msg.type, msg);
           };
       }

       private async startListen() {
           return this.ensureEnv(this.listen);
       }

       /**
       * @description 发送消息，必须包含action
       * @param {MessageToMiniApp} msg
       * @returns 
       * @memberof MiniAppEventBus
       */
       public postMessage(msg: MessageToMiniApp) {
           return new Promise((resolve) => {
               const realPost = () => {
                   resolve(window.my.postMessage(msg));
               };

               resolve(this.ensureEnv(realPost));
           });
       }

       /**
       * @description 订阅消息，支持单个或多个
       * @template T
       * @param {(string|string[])} type
       * @param {MiniAppMessageSubscriber} callback
       * @returns 
       * @memberof MiniAppEventBus
       */
       public subscribe(type: string | string[], callback: MiniAppMessageSubscriber) {
           const subscribeSingleAction = (type: string, cb: MiniAppMessageSubscriber) => {
               let listeners = this.listeners.get(type) || [];

               listeners.push(cb);
               this.listeners.set(type, listeners);
           };

           this.forEach(type,(type:string)=>subscribeSingleAction(type,callback));
       }

       private forEach(type:string | string[],cb:(type:string)=>void){
           if (typeof type === 'string') {
               return cb(type);
           }

           for (const key in type) {
               if (Object.prototype.hasOwnProperty.call(type, key)) {
                   const element = type[key];

                   cb(element);
               }
           }
       }

       /**
       * @description 异步订阅
       * @template T
       * @param {(string|string[])} type
       * @returns {Promise>}
       * @memberof MiniAppEventBus
       */
       public async subscribeAsync(type: string | string[]): Promise> {
           return new Promise((resolve, _reject) => {
               this.subscribe(type, resolve);
           });
       }

       /**
       * @description 触发事件
       * @param {string} type
       * @param {MiniAppMessage} msg
       * @memberof MiniAppEventBus
       */
       public async dispatch(type: string, msg: MiniAppMessage) {
           let listeners = this.listeners.get(type) || [];

           listeners.map(i => {
               if (typeof i === 'function') {
                   i(msg);
               }
           });
       }

       public async unSubscribe(type:string | string[]){
           const unsubscribeSingle = (type: string) => {
               this.listeners.set(type, []);
           };

           this.forEach(type,(type:string)=>unsubscribeSingle(type));
       }
   }

   export default new MiniAppEventBus();

const actionHandles = {
    async FACE_VERIFY(){},
    async GET_STEP(){},
    async UPLOAD_HASH(){},
    async GET_AUTH_CODE(){},
    ...// 其他action
}
.... 
// 在webview的消息监听函数中
async startProcess(e) {
    const data = e.detail;
    // 根据不同的action调用不同的handle处理
    const handle = actionHandles[data.action];
    if (handle) {
        
        return actionHandles[data.action](this, data)
    }
    return uploadLogsExtend({
        tip: STRING_CONTANT.UNKNOWN_ACTIONS,
        data
    })
}

工厂模式的定义

定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

简单工厂

如果要创建的产品不多，只要一个工厂类就可以完成，这种模式叫“简单工厂模式”。

简单工厂通常为静态方法，因此又叫静态工厂方法模式

优点：

• 工厂类包含必要的逻辑判断，可以决定在什么时候创建哪一个产品的实例。客户端可以免除直接创建产品对象的职责，很方便的创建出相应的产品。工厂和产品的职责区分明确。
• 客户端无需知道所创建具体产品的类名，只需知道参数即可。
  也可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。

缺点：

• 简单工厂模式的工厂类单一，负责所有产品的创建，职责过重，一旦异常，整个系统将受影响。且工厂类代码会非常臃肿，违背高聚合原则。
• 使用简单工厂模式会增加系统中类的个数（引入新的工厂类），增加系统的复杂度和理解难度
• 系统扩展困难，一旦增加新产品不得不修改工厂逻辑，在产品类型较多时，可能造成逻辑过于复杂
• 简单工厂模式使用了 static 工厂方法，造成工厂角色无法形成基于继承的等级结构。

应用场景

对于产品种类相对较少的情况，考虑使用简单工厂模式。使用简单工厂模式的客户端只需要传入工厂类的参数，不需要关心如何创建对象的逻辑，可以很方便地创建所需产品。

代码实现

简单工厂模式的主要角色如下：

• 简单工厂：是简单工厂模式的核心，负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。
• 抽象产品：是简单工厂创建的所有对象的父类，负责描述所有实例共有的公共接口。
• 具体产品：是简单工厂模式的创建目标。

其结构图如下图所示。

kotlin代码实现

interface IProduct{

    fun showName() :String

}



class Dog : IProduct{

    override fun showName() = "dog"



}



class Cat : IProduct{

    override fun showName() = "cat"

}



object AnimalFactory{

    fun createAnimal(type:Int):IProduct{

        return when(type){

            1-> Dog()

            2-> Cat()

            else -> throw NullPointerException()

        }

    }

}

简单工厂模式在Android中的实际应用

fragment 的构建

有时候，为了简化简单工厂模式，我们可以将抽象产品类和工厂类合并，将静态工厂方法移至抽象产品类中。Fragment的创建使用简单工厂方法没有抽象产品类，所以工厂类放到了实现产品类中。

class ListWorkFragment : BMvpFragment<ListWorkView ,ListWorkPresenter>(),ListWorkView,ISubjectView{

        companion object {

        @JvmStatic

        fun newInstance(recommendTypeId: Int,

                        termCode: String = "") =

            ListWorkFragment().apply {

                arguments = Bundle().apply {

                    putInt("type", recommendTypeId)

                    putString("code", termCode)

                }

            }

    }

优点

1. 在创建Fragment的时候，可以不需要管内部参数，而从外部输入
2. Fragment推荐使用setArguments来传递参数，避免在横竖屏切换的时候Fragment自动调用自己的无参构造函数，导致数据丢失。

Bitmap源码分析

@UnsupportedAppUsage(maxTargetSdk = 28)

    Bitmap(long nativeBitmap, int width, int height, int density,

            boolean requestPremultiplied, byte[] ninePatchChunk,

            NinePatch.InsetStruct ninePatchInsets) {

        this(nativeBitmap, width, height, density, requestPremultiplied, ninePatchChunk,

                ninePatchInsets, true);

    }



    // called from JNI and Bitmap_Delegate.

    Bitmap(long nativeBitmap, int width, int height, int density,

            boolean requestPremultiplied, byte[] ninePatchChunk,

            NinePatch.InsetStruct ninePatchInsets, boolean fromMalloc) {

        ...

    }

看构造函数可知，无法new出bitmap，那么怎么创建bitmap对象呢？

 BitmapFactory.decodeFile("")

内部源码

public static Bitmap decodeFile(String pathName) {

    return decodeFile(pathName, null);

}



public static Bitmap decodeFile(String pathName, Options opts) {

    Bitmap bm = null;

    InputStream stream = null;

    try {

        stream = new FileInputStream(pathName);

        bm = decodeStream(stream, null, opts);

    } catch (Exception e) {

        /*  do nothing.

            If the exception happened on open, bm will be null.

        */

        Log.e("BitmapFactory", "Unable to decode stream: " + e);

    } finally {

        if (stream != null) {

            try {

                stream.close();

            } catch (IOException e) {

                // do nothing here

            }

        }

    }

    return bm;

}



public static Bitmap decodeStream(InputStream is, Rect outPadding, Options opts) {

    // we don't throw in this case, thus allowing the caller to only check

    // the cache, and not force the image to be decoded.

    if (is == null) {

        return null;

    }



    Bitmap bm = null;



    Trace.traceBegin(Trace.TRACE_TAG_GRAPHICS, "decodeBitmap");

    try {

        if (is instanceof AssetManager.AssetInputStream) {

            final long asset = ((AssetManager.AssetInputStream) is).getNativeAsset();

            bm = nativeDecodeAsset(asset, outPadding, opts);

        } else {

            bm = decodeStreamInternal(is, outPadding, opts);

        }



        if (bm == null && opts != null && opts.inBitmap != null) {

            throw new IllegalArgumentException("Problem decoding into existing bitmap");

        }



        setDensityFromOptions(bm, opts);

    } finally {

        Trace.traceEnd(Trace.TRACE_TAG_GRAPHICS);

    }



    return bm;

}



private static native Bitmap nativeDecodeStream(InputStream is, byte[] storage,

        Rect padding, Options opts);



/**

 * Set the newly decoded bitmap's density based on the Options.

 */

private static void setDensityFromOptions(Bitmap outputBitmap, Options opts) {

    if (outputBitmap == null || opts == null) return;



    final int density = opts.inDensity;

    if (density != 0) {

        outputBitmap.setDensity(density);

        final int targetDensity = opts.inTargetDensity;

        if (targetDensity == 0 || density == targetDensity || density == opts.inScreenDensity) {

            return;

        }



        byte[] np = outputBitmap.getNinePatchChunk();

        final boolean isNinePatch = np != null && NinePatch.isNinePatchChunk(np);

        if (opts.inScaled || isNinePatch) {

            outputBitmap.setDensity(targetDensity);

        }

    } else if (opts.inBitmap != null) {

        // bitmap was reused, ensure density is reset

        outputBitmap.setDensity(Bitmap.getDefaultDensity());

    }

}

看下BitmapFactory的注释我们可以看到，这个工厂支持从不同的资源创建Bitmap对象，包括files, streams, 和byte-arrays，但是调用关系都大同小异。

背景

近期团队打算做一个小程序自动化测试的工具，期望能够做到业务人员操作一遍小程序后，自动还原之前的操作路径，并且捕获操作过程中发生的异常，以此来判断这次发布是否会影响小程序的基础功能。

上述描述看似简单，但是中间还是有些难点的，第一个难点就是如何在业务人员操作小程序的时候记录操作路径，第二个难点就是如何将记录的操作路径进行还原。

自动化 SDK

如何将操作路径还原这个问题，首选官方提供的 SDK： miniprogram-automator。

小程序自动化 SDK 为开发者提供了一套通过外部脚本操控小程序的方案，从而实现小程序自动化测试的目的。通过该 SDK，你可以做到以下事情：

• 控制小程序跳转到指定页面
• 获取小程序页面数据
• 获取小程序页面元素状态
• 触发小程序元素绑定事件
• 往 AppService 注入代码片段
• 调用 wx 对象上任意接口
• ...

上面的描述都来自官方文档，建议阅读后面内容之前可以先看看官方文档，当然如果之前用过 puppeteer ，也可以快速上手，api 基本一致。下面简单介绍下 SDK 的使用方式。

// 引入sdk
const automator = require('miniprogram-automator')

// 启动微信开发者工具
automator.launch({
  // 微信开发者工具安装路径下的 cli 工具
  // Windows下为安装路径下的 cli.bat
  // MacOS下为安装路径下的 cli
  cliPath: 'path/to/cli',
  // 项目地址，即要运行的小程序的路径
  projectPath: 'path/to/project',
}).then(async miniProgram => { // miniProgram 为 IDE 启动后的实例
    // 启动小程序里的 index 页面
  const page = await miniProgram.reLaunch('/page/index/index')
  // 等待 500 ms
  await page.waitFor(500)
  // 获取页面元素
  const element = await page.$('.main-btn')
  // 点击元素
  await element.tap()
    // 关闭 IDE
  await miniProgram.close()
})

有个地方需要提醒一下：使用 SDK 之前需要开启开发者工具的服务端口，要不然会启动失败。

捕获用户行为

有了还原操作路径的办法，接下来就要解决记录操作路径的难题了。

在小程序中，并不能像 web 中通过事件冒泡的方式在 window 中捕获所有的事件，好在小程序所以的页面和组件都必须通过 Page 、Component 方法来包装，所以我们可以改写这两个方法，拦截传入的方法，并判断第一个参数是否为 event 对象，以此来捕获所有的事件。

// 暂存原生方法

const originPage = Page

const originComponent = Component



// 改写 Page

Page = (params) => {

  const names = Object.keys(params)

  for (const name of names) {

    // 进行方法拦截

    if (typeof obj[name] === 'function') {

      params[name] = hookMethod(name, params[name], false)

    }

  }

  originPage(params)

}

// 改写 Component

Component = (params) => {

  if (params.methods) {

      const { methods } = params

      const names = Object.keys(methods)

      for (const name of names) {

        // 进行方法拦截

        if (typeof methods[name] === 'function') {

          methods[name] = hookMethod(name, methods[name], true)

        }

      }

  }

  originComponent(params)

}



const hookMethod = (name, method, isComponent) => {

  return function(...args) {

    const [evt] = args // 取出第一个参数

    // 判断是否为 event 对象

    if (evt && evt.target && evt.type) {

      // 记录用户行为

    }

    return method.apply(this, args)

  }

}

这里的代码只是代理了所有的事件方法，并不能用来还原用户的行为，要还原用户行为还必须知道该事件类型是否是需要的，比如点击、长按、输入。

const evtTypes = [

    'tap', // 点击

    'input', // 输入

    'confirm', // 回车

    'longpress' // 长按

]

const hookMethod = (name, method) => {

  return function(...args) {

    const [evt] = args // 取出第一个参数

    // 判断是否为 event 对象

    if (

      evt && evt.target && evt.type &&

      evtTypes.includes(evt.type) // 判断事件类型

    ) {

      // 记录用户行为

    }

    return method.apply(this, args)

  }

}

确定事件类型之后，还需要明确点击的元素到底是哪个，但是小程序里面比较坑的地方就是，event 对象的 target 属性中，并没有元素的类名，但是可以获取元素的 dataset。

为了准确的获取元素，我们需要在构建中增加一个步骤，修改 wxml 文件，将所有元素的 class 属性复制一份到 

<!-- 构建前 -->

<view class="close-btn"></view>

<view class="{{mainClassName}}"></view>

<!-- 构建后 -->

<view class="close-btn"  style="box-sizing: border-box; color: rgb(221, 17, 68);">"close-btn"></view>

<view class="{{mainClassName}}"  style="box-sizing: border-box; color: rgb(221, 17, 68);">"{{mainClassName}}"></view>

但是获取到 class 之后，又会有另一个坑，小程序的自动化测试工具并不能直接获取页面里自定义组件中的元素，必须先获取自定义组件。

<!-- Page -->

<toast text="loading" show="{{showToast}}" />

<!-- Component -->

<view class="toast" wx:if="{{show}}">

  <text class="toast-text">{{text}}</text>

  <view class="toast-close" />

</view>

// 如果直接查找 .toast-close 会得到 null

const element = await page.$('.toast-close')

element.tap() // Error!



// 必须先通过自定义组件的 tagName 找到自定义组件

// 再从自定义组件中通过 className 查找对应元素

const element = await page.$('toast .toast-close')

element.tap()

所以我们在构建操作的时候，还需要为元素插入 tagName。

<!-- 构建前 -->

<view class="close-btn" />

<toast text="loading" show="{{showToast}}" />

<!-- 构建后 -->

<view class="close-btn"  style="box-sizing: border-box; color: rgb(221, 17, 68);">"close-btn"  style="box-sizing: border-box; color: rgb(221, 17, 68);">"view" />

<toast text="loading" show="{{showToast}}"  style="box-sizing: border-box; color: rgb(221, 17, 68);">"toast" />

现在我们可以继续愉快的记录用户行为了。

// 记录用户行为的数组

const actions = [];

// 添加用户行为

const addAction = (type, query, value = '') => {

  actions.push({

    time: Date.now(),

    type,

    query,

    value

  })

}



// 代理事件方法

const hookMethod = (name, method, isComponent) => {

  return function(...args) {

    const [evt] = args // 取出第一个参数

    // 判断是否为 event 对象

    if (

      evt && evt.target && evt.type &&

      evtTypes.includes(evt.type) // 判断事件类型

    ) {

      const { type, target, detail } = evt

      const { id, dataset = {} } = target

        const { className = '' } = dataset

        const { value = '' } = detail // input事件触发时，输入框的值

      // 记录用户行为

      let query = ''

      if (isComponent) {

        // 如果是组件内的方法，需要获取当前组件的 tagName

        query = `${this.dataset.tagName} `

      }

      if (id) {

        // id 存在，则直接通过 id 查找元素

        query += id

      } else {

        // id 不存在，才通过 className 查找元素

        query += className

      }

      addAction(type, query, value)

    }

    return method.apply(this, args)

  }

}

到这里已经记录了用户所有的点击、输入、回车相关的操作。但是还有滚动屏幕的操作没有记录，我们可以直接代理 Page 的 onPageScroll 方法。

// 记录用户行为的数组

const actions = [];

// 添加用户行为

const addAction = (type, query, value = '') => {

  if (type === 'scroll' || type === 'input') {

    // 如果上一次行为也是滚动或输入，则重置 value 即可

    const last = this.actions[this.actions.length - 1]

    if (last && last.type === type) {

      last.value = value

      last.time = Date.now()

      return

    }

  }

  actions.push({

    time: Date.now(),

    type,

    query,

    value

  })

}



Page = (params) => {

  const names = Object.keys(params)

  for (const name of names) {

    // 进行方法拦截

    if (typeof obj[name] === 'function') {

      params[name] = hookMethod(name, params[name], false)

    }

  }

  const { onPageScroll } = params

  // 拦截滚动事件

  params.onPageScroll = function (...args) {

    const [evt] = args

    const { scrollTop } = evt

    addAction('scroll', '', scrollTop)

    onPageScroll.apply(this, args)

  }

  originPage(params)

}

这里有个优化点，就是滚动操作记录的时候，可以判断一下上次操作是否也为滚动操作，如果是同一个操作，则只需要修改一下滚动距离即可，因为两次滚动可以一步到位。同理，输入事件也是，输入的值也可以一步到位。

还原用户行为

用户操作完毕后，可以在控制台输出用户行为的 json 文本，把 json 文本复制出来后，就可以通过自动化工具运行了。

// 引入sdk

const automator = require('miniprogram-automator')



// 用户操作行为

const actions = [

  { type: 'tap', query: 'goods .title', value: '', time: 1596965650000 },

  { type: 'scroll', query: '', value: 560, time: 1596965710680 },

  { type: 'tap', query: 'gotoTop', value: '', time: 1596965770000 }

]



// 启动微信开发者工具

automator.launch({

  projectPath: 'path/to/project',

}).then(async miniProgram => {

  let page = await miniProgram.reLaunch('/page/index/index')

  

  let prevTime

  for (const action of actions) {

    const { type, query, value, time } = action

    if (prevTime) {

      // 计算两次操作之间的等待时间

          await page.waitFor(time - prevTime)

    }

    // 重置上次操作时间

    prevTime = time

    

    // 获取当前页面实例

    page = await miniProgram.currentPage()

    switch (type) {

      case 'tap':

              const element = await page.$(query)

        await element.tap()

        break;

      case 'input':

              const element = await page.$(query)

        await element.input(value)

        break;

      case 'confirm':

              const element = await page.$(query)

                 await element.trigger('confirm', { value });

        break;

      case 'scroll':

        await miniProgram.pageScrollTo(value)

        break;

    }

    // 每次操作结束后，等待 5s，防止页面跳转过程中，后面的操作找不到页面

    await page.waitFor(5000)

  }



    // 关闭 IDE

  await miniProgram.close()

})

这里只是简单的还原了用户的操作行为，实际运行过程中，还会涉及到网络请求和 localstorage 的 mock，这里不再展开讲述。同时，我们还可以接入 jest 工具，更加方便用例的编写。

总结

看似很难的需求，只要用心去发掘，总能找到对应的解决办法。另外微信小程序的自动化工具真的有很多坑，遇到问题可以先到小程序社区去找找，大部分坑都有前人踩过，还有一些一时无法解决的问题只能想其他办法来规避。最后祝愿天下无 bug。

原文链接：https://segmentfault.com/a/1190000023555693

在小程序开发过程中，用户输入是必不可少的，我们经常会需要用户输入一些内容，来完成产品收集用户信息的需求。

在这种情况下，我们可以考虑借助小程序提供的一些和键盘相关的 API 来优化小程序的使用体验。

Input 组件的 type 属性

从小程序的 1.0 版本开始，就支持为 input 组件设置 type，不同的 type 会显示不同的手机键盘。默认情况下，显示的是 text 文本输入键盘，这个键盘的特点是显示所有的内容，可以适用于所有的场景。

但，适用于所有场景也就意味着不适用于所有场景，总会在每一个场景中有着种种不便，因此，在实际的开发中，为了获得更佳的体验，你可以通过设置不同的 Type 来控制实际的键盘显示情况。

除了默认的 text 类以外，你还可以使用 number(数字输入键盘)、idcard 身份证输入键盘和 digit 带小数点的数字键盘。

你可以根据自己的实际使用场景来设置不同的类型，比如说

• 如果你的小程序的验证码都是数字的，那么你给出一个 text 类型的键盘，显然不如给一个 number 类型的键盘更合适。
• 如果你的小程序中涉及到了手机号的输入，那么这种情况下你就可以选择使用 number 类型的键盘，来优化用户输入时的体验。

这里的思路是类似的，当你预期用户输入的内容只有数字，就可以考虑 number、digit、idcard 等类型，来优化你的小程序的实际使用体验。

## 总结

input 组件默认提供的 四种 type ，可以通过选择不同的类型，从而获得不同的体验效果，从而对于你的小程序体验进行优化和推进。

原文链接：https://segmentfault.com/a/1190000025160488

我们需要在选择图片后

对图片做一次安全校验

启用云开发

现在我们需要一个 后端接口 来实现图片的 安全校验 功能

这时候临时搭个Node服务好像不太现实

又不是什么正经项目

于是就想到了微信的云开发功能

用起来真实方便快捷

至于图片的校验方法

直接用云函数调用 security.imgSecCheck 接口就好了

流程

chooseImage() {
  /// 用户选择图片
  wx.chooseImage({
    count: 1,
    sizeType: ['original', 'compressed'],
    sourceType: ['album', 'camera'],
    success: async res => {
      if (res.errMsg === 'chooseImage:ok') {
        wx.showLoading({ title: '图片加载中' })
        // 获取图片临时地址
        const path = res.tempFilePaths[0]
        // 将图片地址实例化为图片
        const image = await loadImage(path, this.canvas)
        // 压缩图片
        const filePath = await compress.call(this, image, 'canvas_compress')
        // 校验图片合法性
        const imgValid = await checkImage(filePath)
        wx.hideLoading()
        if (!imgValid) return
        // 图片安全检测通过，执行后续操作
        ...
    }
  })
}

所以在图片上传前要先对超出尺寸的图片进行压缩处理

基本逻辑就是

超出尺寸的图片等比例缩小就好了

我们先要有一个canvas元素

用来处理需要压缩的图片

<template>

  <view class="menu-background">

    <view class="item replace" bindtap="chooseImage">

      <i class="iconfont icon-image"></i>

      <text class="title">图片</text>

      <text class="sub-title">图片仅供本地使用</text>

    </view>

    //

    // canvas

    //

    <canvas

      type="2d"

      id="canvas_compress"

      class="canvas-compress"

      style="width: {{canvasCompress.width}}px; height: {{canvasCompress.height}}px"

    />

  </view>

</template>

将canvas移到视野不可见到位置

.canvas-compress

    position absolute

    left 0

    top 1000px

图片进行压缩处理

/**
 * 压缩图片
 * 将尺寸超过规范的图片最小限度压缩
 * @param {Image} image 需要压缩的图片实例
 * @param {String} canvasId 用来处理压缩图片的canvas对应的canvasId
 * @param {Object} config 压缩的图片规范 -> { maxWidth 最大宽度, maxHeight 最小宽度 }
 * @return {Promise} promise返回 压缩后的 图片路径
 */
export default function (image, canvasId, config = { maxWidth: 750, maxHeight: 1334 }) {
  // 引用的组件传入的this作用域
  const _this = this
  return new Promise((resolve, reject) => {
    // 获取图片原始宽高
    let width = image.width
    let height = image.height
    // 宽度 > 最大限宽 -> 重置尺寸
    if (width > config.maxWidth) {
      const ratio = width / config.maxWidth
      width = config.maxWidth
      height = height / ratio
    }
    // 高度 > 最大限高度 -> 重置尺寸
    if (height > config.maxHeight) {
      const ratio = height / config.maxHeight
      height = config.maxHeight
      width = width / ratio
    }
    // 设置canvas的css宽高
    _this.canvasCompress.width = width
    _this.canvasCompress.height = height
    const query = this.createSelectorQuery()
    query
      .select(`#${canvasId}`)
      .fields({ node: true, size: true })
      .exec(async res => {
        // 获取 canvas 实例
        const canvas = res[0].node
        // 获取 canvas 绘图上下文
        const ctx = canvas.getContext('2d')
        // 根据设备dpr处理尺寸
        const dpr = wx.getSystemInfoSync().pixelRatio
        canvas.width = width * dpr
        canvas.height = height * dpr
        ctx.scale(dpr, dpr)
        // 将图片绘制到 canvas
        ctx.drawImage(image, 0, 0, width, height)
        // 将canvas图片上传到微信临时文件
        wx.canvasToTempFilePath({
          canvas,
          x: 0,
          y: 0,
          destWidth: width,
          destHeight: height,
          complete (res) {
            if (res.errMsg === 'canvasToTempFilePath:ok') {
              // 返回临时文件路径
              resolve(res.tempFilePath)
            }
          },
          fail(err) {
            reject(err)
          }
        })
      })
  })
}

图片安全校验

云函数 checkImage.js

const cloud = require('wx-server-sdk')
cloud.init({
  env: cloud.DYNAMIC_CURRENT_ENV
})
/**
 * 校验图片合法性
 * @param {*} event.fileID 微信云存储的图片ID
 * @return {Number} 0:校验失败；1:校验通过
 */
exports.main = async (event, context) => {
  const contentType = 'image/png'
  const fileID = event.fileID
  try {
    // 根据fileID下载图片
    const file = await cloud.downloadFile({
      fileID
    })
    const value = file.fileContent
    // 调用 imgSecCheck 借口，校验不通过接口会抛错
    // 必要参数 media { contentType, value }
    const result = await cloud.openapi.security.imgSecCheck({
      media: {
        contentType,
        value
      }
    })
    return 1
  } catch (err) {
    return 0
  }
}

组件调用云函数封装

/**
 * 校验图片是否存在敏感信息
 * @param { String } filePath
 * @return { Promise } promise返回校验结果
 */
export default function (filePath) {
  return new Promise((resolve, reject) => {
    // 先将图片上传到云开发存储
    wx.cloud.uploadFile({
      cloudPath: `${new Date().getTime()}.png`,
      filePath,
      success (res) {
        // 调用云函数-checkImage
        wx.cloud.callFunction({
          name: 'checkImage',
          data: {
            fileID: res.fileID
          },
          success (res) {
            // res.result -> 0:存在敏感信息；1:校验通过
            resolve(res.result)
            if (!res.result) {
              wx.showToast({
                title: '图片可能含有敏感信息, 请重新选择',
                icon: 'none'
              })
            }
          },
          fail (err) {
            reject(err)
          }
        })
      },
      fail (err) {
        reject(err)
      }
    })
  })
}

原文链接：https://segmentfault.com/a/1190000038685508

Observable.create(new ObservableOnSubscribe<String>() {

    @Override

    public void subscribe(ObservableEmitter<String> e) throws Exception {

        Log.d("WanRxjava ", "subscrib  td ==" + Thread.currentThread().getName());

        e.onNext("我在发送next");

        e.onComplete();

    }

}).subscribeOn(Schedulers.io())

        .observeOn(AndroidSchedulers.mainThread())

        .subscribe(new Observer<String>() {

            @Override

            public void onSubscribe(Disposable d) {

                Log.d("WanRxjava ", "onSubscribe td ==" + Thread.currentThread().getName());

            }



            @Override

            public void onNext(String value) {

                Log.d("WanRxjava ", "onNext td ==" + Thread.currentThread().getName());

            }



            @Override

            public void onError(Throwable e) {



            }



            @Override

            public void onComplete() {

                Log.d("WanRxjava ", "onComplete td ==" + Thread.currentThread().getName());

            }

        });

@SchedulerSupport(SchedulerSupport.NONE)

public static <T> Observable<T> create(ObservableOnSubscribe<T> source) {

    ObjectHelper.requireNonNull(source, "source is null");

    return RxJavaPlugins.onAssembly(new ObservableCreate<T>(source));

}

public final class ObservableCreate<T> extends Observable<T> {

    final ObservableOnSubscribe<T> source;



    public ObservableCreate(ObservableOnSubscribe<T> source) {

        this.source = source;

    }

}

@SchedulerSupport(SchedulerSupport.CUSTOM)

public final Observable<T> subscribeOn(Scheduler scheduler) {

    ObjectHelper.requireNonNull(scheduler, "scheduler is null");

    return RxJavaPlugins.onAssembly(new ObservableSubscribeOn<T>(this, scheduler));

}

public final class ObservableSubscribeOn<T> extends AbstractObservableWithUpstream<T, T> {

    final Scheduler scheduler;



    public ObservableSubscribeOn(ObservableSource<T> source, Scheduler scheduler) {

        super(source);

        this.scheduler = scheduler;

    }

}

@SchedulerSupport(SchedulerSupport.CUSTOM)

public final Observable<T> observeOn(Scheduler scheduler) {

    return observeOn(scheduler, false, bufferSize());

}

@SchedulerSupport(SchedulerSupport.CUSTOM)

public final Observable<T> observeOn(Scheduler scheduler, boolean delayError, int bufferSize) {

    ObjectHelper.requireNonNull(scheduler, "scheduler is null");

    ObjectHelper.verifyPositive(bufferSize, "bufferSize");

    return RxJavaPlugins.onAssembly(new ObservableObserveOn<T>(this, scheduler, delayError, bufferSize));

}

public final class ObservableObserveOn<T> extends AbstractObservableWithUpstream<T, T> {

    final Scheduler scheduler;

    final boolean delayError;

    final int bufferSize;

    public ObservableObserveOn(ObservableSource<T> source, Scheduler scheduler, boolean delayError, int bufferSize) {

        super(source);

        this.scheduler = scheduler;

        this.delayError = delayError;

        this.bufferSize = bufferSize;

    }

}

//ObservableObserveOn.java

@SchedulerSupport(SchedulerSupport.NONE)

@Override

public final void subscribe(Observer<? super T> observer) {

    ObjectHelper.requireNonNull(observer, "observer is null");

    try {

        observer = RxJavaPlugins.onSubscribe(this, observer);



        ObjectHelper.requireNonNull(observer, "Plugin returned null Observer");



        subscribeActual(observer);

    } catch (NullPointerException e) { // NOPMD

        throw e;

    } catch (Throwable e) {

        Exceptions.throwIfFatal(e);

        // can't call onError because no way to know if a Disposable has been set or not

        // can't call onSubscribe because the call might have set a Subscription already

        RxJavaPlugins.onError(e);



        NullPointerException npe = new NullPointerException("Actually not, but can't throw other exceptions due to RS");

        npe.initCause(e);

        throw npe;

    }

}

//ObservableObserveOn.java

@Override

protected void subscribeActual(Observer<? super T> observer) {

    if (scheduler instanceof TrampolineScheduler) {

        source.subscribe(observer);

    } else {

        Scheduler.Worker w = scheduler.createWorker();



        source.subscribe(new ObserveOnObserver<T>(observer, w, delayError, bufferSize));

    }

}

//ObservableObserveOn 内部类

static final class ObserveOnObserver<T> extends BasicIntQueueDisposable<T>

implements Observer<T>, Runnable {



    private static final long serialVersionUID = 6576896619930983584L;

    final Observer<? super T> actual;

    final Scheduler.Worker worker;

    final boolean delayError;

    final int bufferSize;



    SimpleQueue<T> queue;



    Disposable s;



    Throwable error;

    volatile boolean done;



    volatile boolean cancelled;



    int sourceMode;



    boolean outputFused;



    ObserveOnObserver(Observer<? super T> actual, Scheduler.Worker worker, boolean delayError, int bufferSize) {

        this.actual = actual;

        this.worker = worker;

        this.delayError = delayError;

        this.bufferSize = bufferSize;

    }



    @Override

    public void onSubscribe(Disposable s) {

        if (DisposableHelper.validate(this.s, s)) {

            this.s = s;

            if (s instanceof QueueDisposable) {

                @SuppressWarnings("unchecked")

                QueueDisposable<T> qd = (QueueDisposable<T>) s;



                int m = qd.requestFusion(QueueDisposable.ANY | QueueDisposable.BOUNDARY);



                if (m == QueueDisposable.SYNC) {

                    sourceMode = m;

                    queue = qd;

                    done = true;

                    actual.onSubscribe(this);

                    schedule();

                    return;

                }

                if (m == QueueDisposable.ASYNC) {

                    sourceMode = m;

                    queue = qd;

                    actual.onSubscribe(this);

                    return;

                }

            }



            queue = new SpscLinkedArrayQueue<T>(bufferSize);



            actual.onSubscribe(this);

        }

    }



    @Override

    public void onNext(T t) {

        if (done) {

            return;

        }



        if (sourceMode != QueueDisposable.ASYNC) {

            queue.offer(t);

        }

        schedule();

    }



    @Override

    public void onError(Throwable t) {

        if (done) {

            RxJavaPlugins.onError(t);

            return;

        }

        error = t;

        done = true;

        schedule();

    }



    @Override

    public void onComplete() {

        if (done) {

            return;

        }

        done = true;

        schedule();

    }



    @Override

    public void dispose() {

        if (!cancelled) {

            cancelled = true;

            s.dispose();

            worker.dispose();

            if (getAndIncrement() == 0) {

                queue.clear();

            }

        }

    }



    @Override

    public boolean isDisposed() {

        return cancelled;

    }



    void schedule() {

        if (getAndIncrement() == 0) {

            worker.schedule(this);

        }

    }



    void drainNormal() {

        int missed = 1;



        final SimpleQueue<T> q = queue;

        final Observer<? super T> a = actual;



        for (;;) {

            if (checkTerminated(done, q.isEmpty(), a)) {

                return;

            }



            for (;;) {

                boolean d = done;

                T v;



                try {

                    v = q.poll();

                } catch (Throwable ex) {

                    Exceptions.throwIfFatal(ex);

                    s.dispose();

                    q.clear();

                    a.onError(ex);

                    return;

                }

                boolean empty = v == null;



                if (checkTerminated(d, empty, a)) {

                    return;

                }



                if (empty) {

                    break;

                }



                a.onNext(v);

            }



            missed = addAndGet(-missed);

            if (missed == 0) {

                break;

            }

        }

    }



    void drainFused() {

        int missed = 1;



        for (;;) {

            if (cancelled) {

                return;

            }



            boolean d = done;

            Throwable ex = error;



            if (!delayError && d && ex != null) {

                actual.onError(error);

                worker.dispose();

                return;

            }



            actual.onNext(null);



            if (d) {

                ex = error;

                if (ex != null) {

                    actual.onError(ex);

                } else {

                    actual.onComplete();

                }

                worker.dispose();

                return;

            }



            missed = addAndGet(-missed);

            if (missed == 0) {

                break;

            }

        }

    }



    @Override

    public void run() {

        if (outputFused) {

            drainFused();

        } else {

            drainNormal();

        }

    }



    boolean checkTerminated(boolean d, boolean empty, Observer<? super T> a) {

        if (cancelled) {

            queue.clear();

            return true;

        }

        if (d) {

            Throwable e = error;

            if (delayError) {

                if (empty) {

                    if (e != null) {

                        a.onError(e);

                    } else {

                        a.onComplete();

                    }

                    worker.dispose();

                    return true;

                }

            } else {

                if (e != null) {

                    queue.clear();

                    a.onError(e);

                    worker.dispose();

                    return true;

                } else

                if (empty) {

                    a.onComplete();

                    worker.dispose();

                    return true;

                }

            }

        }

        return false;

    }



    @Override

    public int requestFusion(int mode) {

        if ((mode & ASYNC) != 0) {

            outputFused = true;

            return ASYNC;

        }

        return NONE;

    }



    @Override

    public T poll() throws Exception {

        return queue.poll();

    }



    @Override

    public void clear() {

        queue.clear();

    }



    @Override

    public boolean isEmpty() {

        return queue.isEmpty();

    }

}

//ObservableSubscribeOn.java

@Override

public void subscribeActual(final Observer<? super T> s) {

    final SubscribeOnObserver<T> parent = new scheduler<T>(s);



    s.onSubscribe(parent);



    parent.setDisposable(scheduler.scheduleDirect(new Runnable() {

        @Override

        public void run() {

            source.subscribe(parent);

        }

    }));

}



static final class SubscribeOnObserver<T> extends AtomicReference<Disposable> implements Observer<T>, Disposable {



    private static final long serialVersionUID = 8094547886072529208L;

    final Observer<? super T> actual;



    final AtomicReference<Disposable> s;



    SubscribeOnObserver(Observer<? super T> actual) {

        this.actual = actual;

        this.s = new AtomicReference<Disposable>();

    }



    @Override

    public void onSubscribe(Disposable s) {

        DisposableHelper.setOnce(this.s, s);

    }



    @Override

    public void onNext(T t) {

        actual.onNext(t);

    }



    @Override

    public void onError(Throwable t) {

        actual.onError(t);

    }



    @Override

    public void onComplete() {

        actual.onComplete();

    }



    @Override

    public void dispose() {

        DisposableHelper.dispose(s);

        DisposableHelper.dispose(this);

    }



    @Override

    public boolean isDisposed() {

        return DisposableHelper.isDisposed(get());

    }



    void setDisposable(Disposable d) {

        DisposableHelper.setOnce(this, d);

    }

}

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

kotlin 扩展函数之Boolean扩展

inline fun <reified T : ViewModel> Fragment.viewModel(

    factory: ViewModelProvider.Factory,

    body: T.() -> Unit

): T {

    val vm = ViewModelProviders.of(this, factory)[T::class.java]

    vm.body()

    return vm

}

复制代码

package com.kpa.component.ui.extension



/**

 * @author: kpa

 * @time: 2021/4/17

 * @email: billkp@yeah.net

 **/



/**

 * 数据

 */

sealed class BooleanExt<out T>



object Otherwise : BooleanExt<Nothing>()

class WithData<T>(val data: T) : BooleanExt<T>()



/**

 * 判断条件为true 时执行block

 */

inline fun <T : Any> Boolean.yes(block: () -> T) =

    when {

        this -> {

            WithData(block())

        }

        else -> {

            Otherwise

        }

    }



/**

 * 判断条件为false 时执行block

 * 

 */

inline fun <T> Boolean.no(block: () -> T) = when {

    this -> Otherwise

    else -> {

        WithData(block())

    }

}



/**

 * 与判断条件互斥时执行block

 */

inline fun <T> BooleanExt<T>.otherwise(block: () -> T): T =

    when (this) {

        is Otherwise -> block()

        is WithData -> this.data

    }

复制代码

@Test

fun addition_isCorrect() {

    true.yes { 

        // doSomething

    }

    false.no{

        // doSomething

    }

    // 有返回值（条件为true）

    val otherwise = getBoolean().yes {

        2

    }.otherwise {

        1

    }

    assertEquals(otherwise, 2)

    // 有返回值（条件为false）

    val otherwise1 = false.no {

        2

    }.otherwise {

        3

    }

    assertEquals(otherwise1, 2)

}





fun getBoolean() = true

复制代码

接上一章。。。。。。。

三、NSNotification Crash

#import 

/**
 当一个对象添加了notification之后，如果dealloc的时候，仍然持有notification，就会出现NSNotification类型的crash。
 
 iOS9之后专门针对于这种情况做了处理，所以在iOS9之后，即使开发者没有移除observer，Notification crash也不会再产生了
 */

NS_ASSUME_NONNULL_BEGIN

@interface NSObject (NSNotificationCrash)

+ (void)xz_enableNotificationProtector;

@end

NS_ASSUME_NONNULL_END

#import "NSObject+NSNotificationCrash.h"
#import "NSObject+XZSwizzle.h"
#import 


static const char *isNSNotification = "isNSNotification";

@implementation NSObject (NSNotificationCrash)


+ (void)xz_enableNotificationProtector {
    
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        NSObject *objc = [[NSObject alloc] init];
        
        [objc xz_instanceSwizzleMethod:@selector(addObserver:selector:name:object:) replaceMethod:@selector(xz_addObserver:selector:name:object:)];
        
        // 在ARC环境下不能显示的@selector dealloc。
        [objc xz_instanceSwizzleMethod:NSSelectorFromString(@"dealloc") replaceMethod:NSSelectorFromString(@"xz_dealloc")];
    });
}

- (void)xz_addObserver:(id)observer selector:(SEL)aSelector name:(nullable NSNotificationName)aName object:(nullable id)anObject {
    
    // 添加标志位，在delloc中只有isNSNotification是YES，才会移除通知
    [observer setIsNSNotification:YES];
    [self xz_addObserver:observer selector:aSelector name:aName object:anObject];
}


- (void)setIsNSNotification:(BOOL)yesOrNo {
    objc_setAssociatedObject(self, isNSNotification, @(yesOrNo), OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

- (BOOL)isNSNotification {
    NSNumber *number = objc_getAssociatedObject(self, isNSNotification);;
    return  [number boolValue];
}

/**
 如果一个对象从来没有添加过通知，那就不要remove操作
 */
- (void)xz_dealloc
{
    if ([self isNSNotification]) {
        NSLog(@"CrashProtector: %@ is dealloc，but NSNotificationCenter Also exsit",self);
        [[NSNotificationCenter defaultCenter] removeObserver:self];
    }
    
    [self xz_dealloc];
}

@end

#import 

NS_ASSUME_NONNULL_BEGIN

@interface XZProxy : NSProxy

+ (instancetype)proxyWithTarget:(id)target;

@end

NS_ASSUME_NONNULL_END

#import "XZProxy.h"


@interface XZProxy ()

/// 消息转发的对象
@property (nonatomic, weak) id target;

@end

@implementation XZProxy

+ (instancetype)proxyWithTarget:(id)target {
    // NSProxy没有init方法, 只需要调用alloc创建对象即可
    XZProxy *proxy = [XZProxy alloc];
    proxy.target = target;
    return proxy;
}

- (nullable NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [self.target methodSignatureForSelector:sel];
}

- (void)forwardInvocation:(NSInvocation *)invocation {
    [invocation invokeWithTarget:self.target];
}

@end

#import 

NS_ASSUME_NONNULL_BEGIN

@interface NSObject (NSTimerCrash)

+ (void)xz_enableTimerProtector;

@end

NS_ASSUME_NONNULL_END

#import "NSObject+NSTimerCrash.h"
#import "NSObject+XZSwizzle.h"
#import "XZProxy.h"

@implementation NSObject (NSTimerCrash)


+ (void)xz_enableTimerProtector {
    
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        
        // 创建一个timer并把它指定到一个默认的runloop模式中，并且在 TimeInterval时间后 启动定时器
        [NSTimer xz_classSwizzleMethod:@selector(scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:) replaceMethod:@selector(xz_scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:)];
        
        // 创建一个定时器，但是么有添加到运行循环，我们需要在创建定时器后手动的调用 NSRunLoop 对象的 addTimer:forMode: 方法。
        [NSTimer xz_classSwizzleMethod:@selector(timerWithTimeInterval:target:selector:userInfo:repeats:) replaceMethod:@selector(xz_timerWithTimeInterval:target:selector:userInfo:repeats:)];
    });
}


+ (NSTimer *)xz_scheduledTimerWithTimeInterval:(NSTimeInterval)timeInterval target:(id)target selector:(SEL)selector userInfo:(id)userInfo repeats:(BOOL)repeats {
    
    return [self xz_scheduledTimerWithTimeInterval:timeInterval target:[XZProxy proxyWithTarget:target] selector:selector userInfo:userInfo repeats:repeats];
}

+ (NSTimer *)xz_timerWithTimeInterval:(NSTimeInterval)timeInterval target:(id)target selector:(SEL)aSelector userInfo:(nullable id)userInfo repeats:(BOOL)yesOrNo {
    
    return [self xz_timerWithTimeInterval:timeInterval target:[XZProxy proxyWithTarget:target] selector:aSelector userInfo:userInfo repeats:yesOrNo];
}

@end

摘自链接：https://www.jianshu.com/p/3324786893a1

1、概念

将对象以树形结构组织起来，以达成“部分-整体”的层次机构，使得客户端对单个对象和组合对象的使用具有一致性。

是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。

这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。

2、使用场景

部分、整体场景，如树形菜单，文件、文件夹的管理。

1. 需要表示一个对象整体或部分层次
2. 希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

3、如何使用

树枝和叶子实现统一接口，树枝内部组合该接口。

4、UML结构图分析

5、实际代码分析

例：文件与文件夹的关系

先进行普通的实现方式

//文件类

public class File {

    public String name;



    public File(String name) {

        this.name = name;

    }



    /**

     * 操作方法

     * @return

     */

    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name = name;

    }



    public void watch() {

        System.out.println("文件名"+getName()+"文件数目");

    }

}

//文件夹类

public class Folder{

    public String name;



    private List<File> mFileList;

    public Folder(String name) {

        mFileList = new ArrayList<>();

        this.name = name;

    }



    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name = name;

    }



    public void watch() {

        StringBuilder sb = new StringBuilder();

        for(File f:mFileList){

            sb.append(f.name);

        }

        System.out.println("文件名"+getName()+"文件数目"+ mFileList.size()+"名字"+sb.toString());

    }



    public void add(File file) {

        mFileList.add(file);

    }



    public void remove(File file) {

        mFileList.remove(file);

    }



    public File getChild(int pos) {

        return mFileList.get(pos);

    }

}

//运行

        File file = new File("hehe");

        Folder folder = new Folder("heere");

        folder.add(file);

        folder.watch();

文件和文件夹作为两个类来进行操作，将文件类进行添加文件，但是呢？如果文件夹下添加文件夹该咋办呢？就需要再创建一个list来存放文件夹，这样大家都是节点，为啥搞得这么复杂呢？既然存在上下级节点的问题，咱们就抽象为一个抽象类，用抽象类作为节点，子类就是文件夹和文件。

//将文件与文件夹统一看作是一类节点，做一个抽象类来定义这种节点，然后以其实现类来区分文件与目录，在实现类中分别定义各自的具体实现内容，把组合方法写到这个节点类中

public abstract class File {



    public String name;



    public File(String name) {

        this.name = name;

    }



    /**

     * 操作方法

     * @return

     */

    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name = name;

    }



    public abstract void watch();



    /**

     * 组合方法

     * @param file

     */

    public void add(File file){

        throw new UnsupportedOperationException();

    }



    public void remove(File file){

        throw new UnsupportedOperationException();

    }



    public File getChild(int pos){

        throw new UnsupportedOperationException();

    }



}

public class Folder extends File{



    private List<File> mFileList;

    public Folder(String name) {

        super(name);

        mFileList = new ArrayList<>();

    }



    @Override

    public void watch() {

        StringBuilder sb = new StringBuilder();

        for(File f:mFileList){

            sb.append(f.name);

        }

        System.out.println("文件名"+getName()+"文件数目"+ mFileList.size()+"名字"+sb.toString());

    }



    @Override

    public void add(File file) {

        mFileList.add(file);

    }



    @Override

    public void remove(File file) {

        mFileList.remove(file);

    }



    @Override

    public File getChild(int pos) {

        return mFileList.get(pos);

    }

}

public class TestFile extends File {

    public TestFile(String name) {

        super(name);

    }



    @Override

    public void watch() {

        System.out.println("文件名"+getName()+"文件数目");

    }

}

//运行

        TestFile file = new TestFile("hehe");

        Folder folder = new Folder("heere");

        folder.add(file);

        folder.watch();

        folder.getChild(0).watch();