一个工匠

今天，在公司卫生间里面，看到了这个 “每天努力 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。

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

这次又折腾了一把。原因是我想有一个能够宣传出去的名字了。我希望以后，这个名字所生产的内容，可以指导或者引导一些人，也希望这个名字可以成就自己。

这个名字，其实想了很久了，但是一直没有想好。因为一开始，我想找一个英文名。找了许久许久，找到了几个试用了一段时间，发现并不合我心。终于几天前，我想到，或许那些写小说的人，他们的笔名就很有意思呢？比如南派三叔，唐家三少啥的。没有必要局限在英文名字里面走不出去。中国的文字可真是博大精深，不多久，我确定了响当当的 **” 一个工匠”**。

一个工匠。跋山涉水，走心为匠。

好久没有写博客了，猛的一下打字，久旱逢甘霖，突破九重天。

开始的 CSDN 博，到后面私有博，现在的静态博。虽然都挺方便的，但是变迁中感觉自己原来越懒了，要啥维护，就静态的！

最近几年，养精蓄锐全是瞎扯，不过在我身上发生的一些事情，倒是值得简要回味一下。