coding不死，也未曾凋零

基于ios底层block源码阅读的基础上，抽象出block的顶层设计结构，尽可能方便实惠的了解block的真正魔法内涵，只有意识里顺畅捋清楚block的设计问题，才可能下一步更好的处理block的引用

无主引用 - swift实例内存空间引用存储方式为如何闭包循环引用 - 强引用 弱引用存储方式 deinit执行逻辑 强应用，导致deinit不执行的真正逻辑是什么 闭包捕获列表参数的理解闭包解决循环引用的方式闭包延长实例的声明周期 两种方式

swift 的引用源码探究RefCountBitsT模板的理解强引用 无主引用的存储散列表 - 弱引用结构的存储与强引用存储关系如何通过调试查看还原读取弱引用信息

为什么说指针不安全原因：堆内存生命周期，内存空间访问越界，指针类型与内存类型不一致；Swift中的指针分为两类 typed pointer & raw pointer原始指针-rawPointer 的使用泛型指针的使用

swift提供了3种不同的API来绑定/重新绑定指针assumingMemoryBound(绕过编译器检查, 并不发生指针转换)bindMemory(发生指针转换)withMemoryRebound(api闭包作用域内有效，也就是转换只发生在闭包作用域内，临时改变内存绑定)关于尾随闭包语法形式问题的补充解释说明

可选值 自定义Optional 替代模式匹配 if let/guard let可选链 swift.模拟OC向一个nil发送消息可选链也适用于下标和函数调用运算符重载隐士解析可选类型应用可选值高阶函数map flatMap 及 Sequence - compactMap

对比OC 枚举类型，探究验证swift中枚举类型本质swift enum声明原始类型Swift 原始值推断机制关联值&模式匹配No-payloadSingle-payloadMutil-payload

对比OC 枚举类型，探究验证swift中枚举类型本质swift enum声明原始类型Swift 原始值推断机制关联值&模式匹配No-payload

结合源码分析得出的metadata结构，通过MachO读取类相关信息，进一步验证swift class结构，了解MachO结构了解到类结构在MachO section中的存储方式及类结构在MachO可执行文件中的内存部署方式，尤其是偏移，如何利用读取到的地址信息递进获取结构内容

swift class底层本质数据结构swift类结构源码探索过程中遇到的问题符合继续MachO文件类数据读取

紧跟，继续 TargetClassDescriptor分析TargetClassDescriptor 中包含了超长的基类描述，超多的using我们分析主干思路，重在检索数据结构，暂时无关的信息暂时忽略掉先从 TargetClassDescriptor 属性信息 整理汇总注意FieldOffsetVectorOffset 注释信息结合关于 Description: TargetClassDescriptor 越界描述大概意思是 偏移出 metadata结构 之外，还存在的一些信息。

通过简单的demo实例 + 少量汇编代码查看 + swift编译器swiftc生成swift中间代码 sil语法分析来探究，最后通过 MachO进行验证 OC是通过clang编译器，编译成IR，然后生成可执行文件.o(机器码) Swift则是通过Swift编译器编译生成IR，然后生成可执行文件 了解到一些必要的汇编指令 通过读取MachO文件得到swift类的方法调用地址 源码查看分析Metadata数据结构

结构体值类型使用 测试结构体与类的内存分配 类的内存开辟消耗时间均 比 结构体值类型内存开品时间长 引用类型内存开辟与访问比值类型 内存访问多一个层级 引用类型访问堆，在堆上开辟空间；值类型直接在栈上分配内存，少一个层级操作；结构体值类型的一个重要应用就是字典的key的存储；异变方法的本质 - 对于变异的方法，方法默认参数（最后一个参数 self 被标记为 inout）, 无论在 mutaing 修饰的方法内部发生什么，都会影响外部依赖类型的一切

是一种可执行文件，用于目标代码，动态库，内核转储每个Mach-O文件包括一个Mach-O头，一系列的载入命令，多个块Mach Header: 描述 Mach-O 的CPU架构、文件类型、加载命令等信息Load Commands: 描述文件中数据等具体组织结构，不同数据类型使用不同等加载命令表示Data: Data中每一个段(Segment)的数据保存在此，段用来存放数据和代码...

假设对象 objc， 属性 key 属性值 value- objc 求hash ==> index - buckets[index] ==> bucket- bucket->second ==> sub_buckets (bucke->first ==> objc)- key 求hash ==> sub_index- sub_buckets[sub_index] ==> sub_bucket- sub_bucket->second ==> association....

使用 __weak typeof(id) weakSelf = selfweakSelf 加入到弱引用表此时 self 引用计数为 1，weakSelf 引用计数为 2，也就是 加入弱引用表之后，是不影响引用计数的。具体弱引用表结构的访问 StripedMap - SideTable.weak_table - weak_entries数组 - 哈希计算索引 - 目标entry 两种存储方式，按条件触发选择方式...

散列表究竟是个什么样的结构，它与引用计数的关系是什么样的;引出StripedMap; StripedMap取表的过程;SideTable;理解散列表;全局StripdMap可以理解为三层套娃结构; 第一层，通过 对象指针地址 经过哈希函数运算，得到 StripdMap中数组结构的索引;第二层，通过hash得到的索引，从 StripdMap中数组结构 中取出 Sidetable;引用计数表-refcnts[对象指针] --> Bucket() 结构...

符号其实就是文件里定义的函数或者方法在 Mach-o中的名称 实际上运行app的时候，执行的是机器码 机器码经过反汇编之后，会生成我们平时见到的汇编代码 app去掉符号之后，能不能运行呢？xcode 可以理解为一个大号的脚本 符号类型补充 弱定义/弱引用符号 ...

作为iOS开发人员，经常会碰到符号的问题，确切的说在调试，收集崩溃时，避免不了乍一看，是个抽象的东西，不像我们处理逻辑业务问题那样，直接依托于语言本身，逻辑漏洞分析你面对的项目不可能是独立的很小的项目，往往依赖很多库，动态库等等，冲突无可避免，至于如何解决，那么前提你就需要多多少少理解符号的本质了虽然研究符号主要为了解决符号冲突问题。理解符号的种类与作用；查看符号的两个命令 nm & objdump；脱去(strip)不需要的符号；理解strip命令的实际作用；解决符号冲突；llvm-objcopy使用..

hmap - header map 描述头文件映射关系.m文件 -> 最终app 的简单过程主要是两部分这两个阶段都需要时间，要考虑如何加快编译速度，首先得选择在以上哪个阶段处理，选择的标准就是看哪个阶段的耗时更长，处理才变得更有意义编译消耗时间 编译阶段消耗时长与链接消耗时间时间差一个数量级，所以处理编译阶段时间优化更有效如果头文件目录很多，意味着耗时进一步增加针对于编译.o 优化的几种方式组件二进制化 提前编译二进制库文件(打包静态库 dylibs framework)...

解耦之路: 经历单工程-模块化-插件化-组件化-独立编译发布依托于解耦工具BeeHive，如何解决组件之间，主工程与组件之间的耦合问题组件能够独立编译发布的细节在哪里解决耦合可以大幅提升编译效率............

了解坐标转换及原因。梳理流程-- 触摸屏幕；IOKit.framework捕捉；通过IPC(进程间通信)转发给SpringBoard进程；通过IPC将事件转发给当前活跃的进程 ；app主线程runloop通过port signal检测到source1, 线程由休眠状态被激活,runloop继续轮询；runloop检测到source0(InputSource)；touch事件加入application事件队列；查询响应者；低级处理/apple封装高级touch处理及关系；UIControl系统控件处理...

结合clang编译中间c++代码，block会创建两层结构BlockCreate 结构Block结构，属于BlockCreate的成员通过BlockCreate构造传参，实例化BlockCreate成员Block::block最终返回的是一个 BlockCreate结构指针通过BlockCreate结构首地址，可以拿到成员Block::block然后就可以调用Block::block的成员方法FuncPtr了, 而FuncPtr恰恰是通过 BlockCreate构造实例化block赋值的fun.

list_array_tt 是个模板，存在于runtime头文件中entsize_list_tt 也是个模板，也存在于runtime 头文件中objc类的底层结构 method_array_t property_array_t protocol_array_t 都是继承自list_array_t在 list_array_tt 中 都对应了模板List 元素都是Elementmethod_array_t properties_array_t protocol_array_t 都套用一个通用嵌套模板容器

map_images()镜像文件类的信息 class ro rw protocols 处理arr_init()SideTablesMap.init(); 初始化散列表_objc_associations_init(); 关联对象管理 初始化startWeakTableScan(); 扫描若引用修复selectorFix up old objc_msgSend_fixup call sites实现 （有实现+load方法）的类.........

`_dyld_start`(dyld)->`doModInitFunctions`(dyld)->`libSystem_initializer`(libSystem)->`libdispatch_init`(libdispatch)->`_objc_init`(libobjc)->`registerObjCNotifiers`(dyld): sNotifyObjCMapped=mapped;&&sNotifyObjCInit=init;&&sNotifyObjCUnmapped = unmapped;

组件化方式 module里资源文件的访问组件策略一: target - action (CTMediator)CTMediator 通过目标target，根据action，通过绑定的组件拿到目标视图，完成初始化，返回给调用者组件策略二: BeeHive 通过service获取目标实例对象注册service - class 键值信息的，两种方式，一种读取文件，一种动态注册每个module类其实绑定一个业务类，而modSetup就是通过 allServicesDict字典缓存业务类 ........

首先 架构设计更新到MVVM，是在MVC MVP KVC KVO的基础上发展而来的，我计划用前面的内容来成就MVVM，而不会增加新的内容，更不会平白无故的增加额外的管理类什么的这种设计就是个双向的管道， 一头是View，一头是PresenterPresenter是数据的源头，自然而然从Presenter流入View，期间经过AdapterView最终是要把数据渲染到视图上去的，状态的变化自然要回溯到源头Presenter，中间也经过AdapterMVP中有一个context的设计，这种架构还可以调整

kvo提供了一种机制，允许其他对象的特定属性的变化通知给目标。对于应用程序中模型层和控制层之间的通信特别有用observer不会自动remove掉，被观察到对象在observer内存被回收之后，会继续向已释放的内存地址发送通知............

kvc 是由NSKeyValueCoding非正式协议采用的一种机制，对象通过该协议来提供属性间接访问accessInstanceVariablesDirectly 返回YESsetValue forKey 根据 _ _is is 的顺序查找变量进行设置accessInstanceVariablesDirectly 返回NOsetValue forKey 将执行 setValue: forUndefinedKey:......

- MVP是presenter基于代理驱动的，所以MVC中的controller就沦为配置层，可以理解为初始化配置的操作- view的数据渲染交给了适配器，preseter自会驱动适配器- 对view自身来讲，adapter也可以尝试去按照数据源的概念去理解- 按照稳重的MVP构想，执行项目的话就可以拷贝代码，按照相应的格式规则去编辑代码 文件 类，框架设计就好了，写代码会变得很轻松 大可以自己去下载代码在自己的项目里尝试一下adapter同样需要在context里追加注册............

开发时间久了，经常会听到这样一个说法，mvc会随着项目的复杂度，controller会变得越来越臃肿我并不认同这种说法，按照这样的逻辑，不管哪种设计，项目复杂了，各种客观的主观的原因，一不小心都会使一些代码变得臃肿，我倒认为这不是MVC的缺陷就像最后的view从controller抽离，view最终要的是需要数据源，控制器就是想办法把view需要的交付出去，而且还必须明智，就是view只需要拿，具体怎么拿到的，我就简单放到view的初始化里.........

启动runloop有几种方式:1.Unconditionally,无条件进入runloop是最简单的选择，但也是最不可取的无条件地运行runloop会使线程进入永久循环，这使得你对runloop本身几乎没有控制权2.设定限制时间 如果设定超时，runloop将一直运行直到事件到达或者分配的时间过期为止3.在特定mode下子线程中 没有启动runloop timer是没办法调度执行 而且子线程一启动 马上就销毁线程安全取决于你使用哪种api操作runloopCore Foundation线程安全

runloop是与线程相关的基础架构的一部分，说白了runloop是与线程密不可分的，离开线程，runloop无从谈起runloop是一个事件处理循环，你可以使用它安排工作，对接收进来的事件进行统筹处理runloop的目的 - 为了达到这样一种效果，有工作就处理，没有工作就休眠Input sources 提供异步事件, 事件 来自于其他线程或进程Timer sources 提供同步事件, 事件 按照预定时间或者重复的间隔发生runloop Mode，可以通俗的来讲两个集合 监视的对象 通知的对象.

释放池是分页设计，就像内存分页概念一样，如果不分页，一下子要面对池子里的一坨很大的数据，人是无法处理超级多的复杂的事情的，这儿自动释放池也一样；不分页的设计会造成池子里对象么次操作 都需要检索整个池子，而池子对象可能很多，效率不高；只有分页对于栈式结构来说，每次操作只在有限长度栈结构内，超过就一页一页pop，之前被压在hot页下面的不活动页变成hot，每次操作只需要检索一小块数据对象；对于嵌套释放池，不分页设计就没有了渐进式内存处理，池子要么整个内存，要么整个释放；自动释放池整体可以理解为两层栈结构....

心心念念查看了下objc4源码 https://opensource.apple.com/releases/ ，果然更新了，果断编译调试如果想最省时省力，直接 github 下载可编译源码下面开始配置可编译环境（本次配置为M1）首先确保下载到841.13源码 gg搜索 os/variant_private.h opensource.apple.com得到结果 https://opensource.apple.com/source/Libc/Libc-1244.50.9/os/variant_priva...

对于我们的app所附带的图片 苹果强烈建议我们使用图像素材来存储 图像素材针对基于名称和基于特征的查找进行了优化在素材目录中查找图片资源 会比搜索磁盘上的文件要快得多如果主要将图像渲染到图形图像渲染器中 该图像可能使用超出SRGB色域的色彩空间值 并不需要更大的元素尺寸来存储这些信息UIImage获取预构建的 UIGraphicsImageRenderFormat 对象的 image renderer format属性 最优化存储Core Image 对图片实时进行大量的高级处理 ...

创建一个CGImageSource对象CGImageSourceCreate可以接受一个选项字典参数 我们这里要传递的重要选项参数是这个 ShouldCache标志这就告诉了 Core Graphics框架 我们只是在创建一个对象来表示存储在该URL的文件中的信息不要立即解码这个图像 只需创建一个表示它的对象我们将需要来自此URL的信息然后我们将在水平和垂直轴上进行计算该计算基于期望的图片的大小 以及我们要渲染 还要预防线程爆炸cpu针对线程切换做了更多的工作......

UIKit - Images and Graphics Best Praticies - 如何在app中高效使用图形内容的技术及策略解决问题 - 如何将先进的cpu和gpu技术集成到你的app中当app中使用更多的cpu时，将会对电池寿命和app的响应能力产生负面的影响可能不那么明显的是，当你的app和系统上的其他app，消耗更多内存，也会导致更高的cpu使用率，这对电池寿命和性能有进一步的不利影响因此，我们将重点关注如何改进对这些资源的使用对于这个问题的讨论还有什么比一个需要处理大量图像内容的app为背景

url设置image背后的工作流程处理 loaderOperation cacheOperation 以及抽象组合operation的协议设计 NSURLSession网络层协议如何嫁接