一个工匠

互联网规则

1. 互联网本质，就是数据在一定的协议基础上，在多台主机之间，进行数据的流动共享。
2. 网络传输协议非常多，不是简简单单的 HTTP/HTTPS 协议，我们 App 看的直播就有 RTMP、私有 UDP 协议、DNS (+CDN 加速) 等等。
3. 数据在网络上基于二进制包进行传输，传输规则基于 7 层网络协议，4/5 层网络协议便于理解
4. 数据包在传输过程中几个关键不可缺少的字段：端口、MAC 地址、IP 地址。可以没有应用层的 HTTP 等协议，但是绝对不可能没有网络层、Mac 层和物理层。没有这三层，数据是不可能找到对应接收方的，甚至这个数据包都出不了你的电脑端口。可以没有应用层等，如 ping 一个主机使用的 ICMP 就是网络层协议，就没有应用层。

HTTP/HTTPS 规则

1. HTTP 协议是无状态的协议，所以需要 Session、Cookie
2. HTTP 没有三次握手，握手的是 TCP。应用层只要通过 TCP 必定会有三次握手。握手并不是 C-S 之间有一条网络管道进行连接，而是两端各自维护相应的状态，当双方状态都处于 runing 的时候 (双方套接字处于完成状态，本质是 Socket 套接字，UDP 也适用该规则)，代表双方连接建立
3. HTTPS 的公私钥认证，很多情况下只发生一次，公私钥认证的用途仅仅是为 C-S 之间的后续通讯建立对称密钥。后续的网络请求不出问题是不会重新公私钥认证的。因为服务器会在第一次公私钥认证的时候，生成 Session ID，该 Session ID 指向对称密钥并保存。客户端一般也会保存这个 Session ID 和对称密钥，后面客户端提交 Session ID 到服务器就可以建立起来安全通信。HTTP1.0 就可以支持 keep alive，多个网络请求可以复用建立的连接，这个时候更加不需要公私钥认证了。
4. HTTPS 的公私钥认证，生成的对称密钥是由 C 生成一个随机数、S 生成一个随机数、C 再生成一个随机数这三个数完成的。公私钥认证的开始，是没有加密的，因为客户端还没有拿到公钥。所以前两个随机数是可以抓包拿到的，但是第三个随机数是 C 通过公钥加密传输的，所以第三个随机数的安全传输才是整个安全机制的重点。（前两个随机数被串改了也没关系，因为 C 和 S 的随机数不一样了，生成的对称密钥也不一样，后面的数据传输加解密过程中，就无法完成校验了）有个重点是，为什么需要 3 个随机数？而不能直接传输上面的第三次随机数？因为随机数为了确保随机性，而随机性不能完全依靠一方来确定，因为很可能不随机。而 3 个随机数，已经可以很好的保障最后生成的对称密钥的随机性了。

字节与比特

比特是计算机存储的最小存储单元。我们认知到的数字 3，在计算机的存储里（硬盘或者内存）的结构是这样的：00000011，也就是我们理解的二进制。
所以这个数字 3 是由 8 位组成的。每位有 0 和 1 两种变化。
比特存储，是计算机的基石。我们在互联网上通行的一切，如图片、音视频、文字，甚至各位的博客、App、电子书等等，能想到的能通过互联网传输的一切，都是比特存储。
举个例子，我们看的一张图片，在磁盘上的存储，或许就是这样子：0101011101010101010111101011110101010101100***(省略100000000个)***1010100111010101。

1 字节 (byte)=8 比特 (bit)
我们刚才说到的数字 3，就是一个字节，在磁盘上就是 00000011。（为了便于理解，实际可能是 00000000 00000011，或者 00000000 00000000 00000000 00000011）。

1KB = 1024B（2 的 10 次方）
1MB = 1024KB（2 的 10 次方）
1GB = 1024MB（2 的 10 次方）
这些大小的计算都是定死的规则。规则很重要，有了规则才能合作。

今天，在公司卫生间里面，看到了这个 “每天努力 0.01” 和 “每天懈怠 0.01” 一年后的差距，颇为感触。
不过我不是因为这两个差距的比较产生心里的鸡汤，而是引发了一些关于努力的思考。
什么算是努力？好人一定要好报吗？

1
2
3
4
5
6

update 2023.09.21
近一年没有洗牙了，几天前再次去洗了一次。
现在我学的聪明了，不去医院洗了，去诊所，价格便宜很多。两个人 100 元左右。
这几年牙齿护理的比较好，牙结石比较少，也没有什么烟渍。出了一些血，问题不大。
老婆发现有 4 颗蛀牙，打算本周去补牙。
洗完牙后，很舒服的。值得推荐。

今天去社区一个牙科诊所洗牙了。

现在已经洗牙归来，本来不是什么天大的个人事情需要在博客里面说一遍。
但是我忍不住自己的喜悦，所以一定想要推荐没有洗牙习惯的朋友，一定要去一次。
这是脱胎换骨的体验。

From Internet. 方便自己查阅使用，侵权删。

一、常见类

1、RACSiganl 信号类。

RACEmptySignal ：空信号，用来实现 RACSignal 的 +empty 方法；

RACReturnSignal ：一元信号，用来实现 RACSignal 的 +return: 方法；

RACDynamicSignal ：动态信号，使用一个 block - 来实现订阅行为，我们在使用 RACSignal 的 +createSignal: 方法时创建的就是该类的实例；

RACErrorSignal ：错误信号，用来实现 RACSignal 的 +error: 方法；

RACChannelTerminal ：通道终端，代表 RACChannel 的一个终端，用来实现双向绑定。

2023.02.18 更
引用计数是 iOS 内存管理的核心，strong 是对其直接应用，weak / 自动释放池 是对其间接应用。要理解 weak 和自动释放池，最有效的办法就是看 runtime 源码，理解 hashTable 和 hashMap 这两张数据结构表。其中 自动释放池 还和 runtime 有很大关系，这点需要串联下知识点。

没有经历过 MRC 年代，对 iOS 的内存管理的理解就不会那么顺畅。
MRC 年代的内存总是不好管理，所以 ARC 帮我们做了很多事情。ARC 做了很多事情让内存管理更加精准优秀外，也隐藏了很多内存管理的细节，也让这块知识点不容易啃食。
真正的内存管理，一定需要回到 MRC 下面去理解，根本思想是：谁创建、谁释放、谁引用、谁管理。
内存释放的唯一途径是：引用计数 = 0
其中自动释放池做了 “谁创建谁释放” 里面的一部分。
ARC 帮我们做了 “谁创建、谁释放、谁引用、谁管理” 四个部分。
ARC 帮我们写了很多管理内存的代码，包括 autolease、retain、release 等。如果不理解 MRC 下面他们的含义，是不可能理解 iOS 内存管理的。
对于 autolease、autoleasepool、autoleasepoolpage 这些，是自动释放池部分，是 iOS 内存管理的一个面。

在 ARC 下，我们虽然不需要写 retain 和 release，不代表他们不存在了。只是编译器帮我们自动添加了，并且在合适的时间添加的。只有编译器也不行，在运行时也会进行内存的控制。在编译和运行时两方的协调控制下，才做到了引用计数及时 = 0，也只有计数 = 0，内存才正确释放。

ARC 内存不是绝对安全释放的，还牵涉到内存区，如果字符串定义到了堆区，释放是及时的，定义到了栈区和常量区，就不那么及时了（虽然引用计数 = 0，代码也不能在调用，但是真实内存还在）。
而且很可能还会因为代码原因导致引用计数永远不可能为 0，常见的就是循环引用，如 Block 的双向强引用，NSTimer 的双向强引用等等，这里都需要特别的破环。解决双向引用的问题，核心在于破环，只要有一个缺口，内存不可能不释放。
其中循环引用的环的查找，也有不少技巧。核心还是在于通过 runtime 来判断是否是强引用，然后通过广度遍历，来确定环的存在。

深入理解自己生成的对象，自己持有、非自己生成的对象，自己也能持有、不再需要自己持有的对象需要释放、非自己持有的对象无法释放，就能深入理解 iOS 的内存管理。
推荐《Objective-C 高级编程》，更推荐苹果开源的 runtime 源码。

最近一年，试玩了不少几款游戏。
有下载需要付费的，有内购的，也有免费的。有本机的，也有联网的。有养成类的，也有公平平台的。
游戏过程是下载了，试玩了，玩了，卸载了。最后连游戏名字也忘了。
今天，也是在 2018 年的最后一天，开始卸载最后一批游戏。游戏这段旅程，在我的生命里，初步结束了。
昨晚，我刚在一个游戏里面付费了 30 元。接着，我杀死了应用，想着这段时间我的游戏生涯。
我对于游戏，始终有一条清晰的线，沿着这条线，不迷失。也是这条线，让我知道游戏的本质，看清很 low 的游戏也日流水过百万的简单操作下的华丽外衣。

像 Block 这种闭包，就是怎么用怎么爽，怎么用怎么喜欢的编码方式了。

闭包很伟大，也是各个语言都实现了的基础语法。我这边对闭包的理解，就是：内部函数持有外部变量。

但是各个语言都有需要注意的点，如 iOS 里面的循环引用，Swift 里面的逃逸闭包，Python 里面的闭包变量延迟定义等。

雪穗和亮司大约 10 岁在图书馆相识
因为家庭及环境等感同身受两人很默契
雪穗早年丧父贫穷
亮司家为典当行但家庭不和谐
雪穗母亲把雪穗卖给有恋童癖的亮司父亲
亮司躲在荒楼里看到父亲强暴雪穗
亮司杀死了父亲并制造了密室杀人的现场
雪穗杀死母亲并制造煤气自杀现场
两个小孩在年龄的掩护下没被警方怀疑
亮司受不了母亲和管家有染后离家出走
雪穗认亲戚做养母到另一个地方学习生活

亮司未满十八开始了自己的黑夜生活
亮司做色情交易赚中间费
亮司同学和 40 岁妇女脱离亮司管理私下交易过程中妇女过于激动死亡于酒店
亮司认为电脑终将改变世界并带来财富
亮司经过努力制造了会写游戏代码的同学不在场证明并成功捕获其同学忠心
雪穗偷盗私教的游戏大部分代码后给了亮司
亮司伙同同学补全其代码靠卖盗版游戏生活
雪穗因幼年生活被其女同学察知并嘲笑后让亮司强暴了该女同学成功掩藏过去
亮司察觉磁卡是漏洞后制造假银行磁卡并盗取原卡现金
雪穗让亮司强暴了大学好友拿到大学舞蹈社的工费卡后交由亮司并套现

后面事件很多，也更复杂和离奇，写不下去了，因为写出来就感觉是雪穗和亮司的错，但全文都体会不到他们有什么错。
事件和故事终将不一样。

事件驱动这个技术方案，可以说实实在在影响了这些年编程界的技术方向。最实际的受用者应该就是异步编程了，如 I/O。

我所认知到的语言，都是事件驱动的使用者，受益者，推动者。