frizzlefur / dailylearning

My Daily Learning~

dailylearning's Issues

LarkContact拆分

看懂UML类图和时序图

看懂UML类图和时序图

这里不会将UML的各种元素都提到，我只想讲讲类图中各个类之间的关系； 能看懂类图中各个类之间的线条、箭头代表什么意思后，也就足够应对 日常的工作和交流； 同时，我们应该能将类图所表达的含义和最终的代码对应起来； 有了这些知识，看后面章节的设计模式结构图就没有什么问题了；

本章所有图形使用Enterprise Architect 9.2来画,所有示例详见根目录下的design_patterns.EAP

从一个示例开始

请看以下这个类图，类之间的关系是我们需要关注的：

• 车的类图结构为<>，表示车是一个抽象类；
• 它有两个继承类：小汽车和自行车；它们之间的关系为实现关系，使用带空心箭头的虚线表示；
• 小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示；
• 小汽车与发动机之间是组合关系，使用带实心箭头的实线表示；
• 学生与班级之间是聚合关系，使用带空心箭头的实线表示；
• 学生与身份证之间为关联关系，使用一根实线表示；
• 学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；

下面我们将介绍这六种关系；

---

类之间的关系

泛化关系(generalization)

类的继承结构表现在UML中为：泛化(generalize)与实现(realize)：

继承关系为 is-a的关系；两个对象之间如果可以用 is-a 来表示，就是继承关系：（..是..)

eg：自行车是车、猫是动物

泛化关系用一条带空心箭头的直接表示；如下图表示（A继承自B）；

eg：汽车在现实中有实现，可用汽车定义具体的对象；汽车与SUV之间为泛化关系；

注：最终代码中，泛化关系表现为继承非抽象类；

实现关系(realize)

实现关系用一条带空心箭头的虚线表示；

eg：”车”为一个抽象概念，在现实中并无法直接用来定义对象；只有指明具体的子类(汽车还是自行车)，才 可以用来定义对象（”车”这个类在C++中用抽象类表示，在JAVA中有接口这个概念，更容易理解）

注：最终代码中，实现关系表现为继承抽象类；

聚合关系(aggregation)

聚合关系用一条带空心菱形箭头的直线表示，如下图表示A聚合到B上，或者说B由A组成；

聚合关系用于表示实体对象之间的关系，表示整体由部分构成的语义；例如一个部门由多个员工组成；

与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在；例如， 部门撤销了，人员不会消失，他们依然存在；

组合关系(composition)

组合关系用一条带实心菱形箭头直线表示，如下图表示A组成B，或者B由A组成；

与聚合关系一样，组合关系同样表示整体由部分构成的语义；比如公司由多个部门组成；

但组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也不存在了；例如， 公司不存在了，部门也将不存在了；

关联关系(association)

关联关系是用一条直线表示的；它描述不同类的对象之间的结构关系；它是一种静态关系， 通常与运行状态无关，一般由常识等因素决定的；它一般用来定义对象之间静态的、天然的结构； 所以，关联关系是一种“强关联”的关系；

比如，乘车人和车票之间就是一种关联关系；学生和学校就是一种关联关系；

关联关系默认不强调方向，表示对象间相互知道；如果特别强调方向，如下图，表示A知道B，但 B不知道A；

注：在最终代码中，关联对象通常是以成员变量的形式实现的；

依赖关系(dependency)

依赖关系是用一套带箭头的虚线表示的；如下图表示A依赖于B；他描述一个对象在运行期间会用到另一个对象的关系；

与关联关系不同的是，它是一种临时性的关系，通常在运行期间产生，并且随着运行时的变化； 依赖关系也可能发生变化；

显然，依赖也有方向，双向依赖是一种非常糟糕的结构，我们总是应该保持单向依赖，杜绝双向依赖的产生；

注：在最终代码中，依赖关系体现为类构造方法及类方法的传入参数，箭头的指向为调用关系；依赖关系除了临时知道对方外，还是“使用”对方的方法和属性；

参考

看懂UML类图和时序图 — Graphic Design Patterns

DiaryCard-19-01

1月的记录

DiaryCard-20-11

11月 🍁

DiaryCard-18-10

10月的记录

DiaryCard-18-12

12月的记录

DiaryCard-19-04

2019-04-06

2. Chat Logic
3. RxSwift
4. 健身🏃

总结

完成了：....

😃100

Block

如果你已经厌烦了一直使用delegate模式来编程的话，偶尔转转写一些block，不仅可以锻炼思维，也能让你写的代码看起来高端洋气一些，而且因为代码跳转变少，所以可读性也会增加。

目录

• Block简介
• Block的定义语法
• Block的内存分配
• Block的具体使用

参考

1. How Do I Declare A Block in Objective-C?
2. Objective-C中的Block
3. 《Objective-C 高级编程》干货三部曲（二）：Blocks篇 - 简书
4. Objective-C中的Block | 程序员说
5. iOS的Block的内存分配 – Bloodline's Blog
6. analyze/iOS 中的 block 是如何持有对象的.md at master · Draveness/analyze

iOS-项目组件化

iOS 组件化开发项目框架设计，结合 MVVM 设计模式 + RAC 数据绑定 + Pod 组件管理， 实现一套实战性的iOS组件化框架

业务的拆分

路由的拆分

私有Pod的制作

参考组件库

wangshiyu13/Lothar: 基于CTMediator的组件化中间件

iOS 组件化方案探索 | WeRead团队博客
iOS组件化实践(一)：简介 - 简书
iOS组件化实践(三)：实施 - 简书

DiaryCard-18-11

11月的记录

Runtime

这个项目涉及到的点比较多，我会慢慢分部整理

一、Runtime运行时的机制

• 对于C语言，函数的调用在编译的时候会决定调用哪个函数。 在编译阶段，C语言调用未实现的函数就会报错。

• 对于Objective-C的函数，属于动态调用过程，在编译的时候并不能决定真正调用哪个函数，只有在真正运行的时候才会根据函数的名称找到对应的函数来调用。在编译阶段，Objective-C可以调用任何函数，即使这个函数并未实现，只要声明过就不会报错。

• Objective-C语言是一门动态语言，它将很多静态语言在编译和链接时期做的事放到了运行时来处理。这种动态语言的优势在于：我们写代码时更具灵活性，如我们可以把消息转发给我们想要的对象，或者随意交换一个方法的实现等。

• 这种特性意味着Objective-C不仅需要一个编译器，还需要一个运行时系统来执行编译的代码。对于Objective-C来说，这个运行时系统就像一个操作系统一样：它让所有的工作可以正常的运行。这个运行时系统即Objc Runtime。Objc Runtime其实是一个Runtime库，它基本上是用C和汇编写的，这个库使得C语言有了面向对象的能力。

二、Runtime运行时的作用

• 能获得某个类的所有成员变量
• 能获得某个类的所有属性
• 能获得某个类的所有方法
• 交换方法实现
• 能动态添加一个成员变量
• 能动态添加一个属性
• 字典转模型
• Runtime归档/反归档

三、Runtime运行时的优点

1. 实现多继承Multiple Inheritance
2. Method Swizzling
3. 面向切面编程Aspect Oriented Programming（在运行时，动态地将代码切入到类的指定方法、指定位置上的编程**就是面向切面的编程。）
4. Isa Swizzling
5. 使用Associated Object关联对象
6. 动态的添加方法
7. NSCoding的自动归档和自动解档
8. 字典和模型互相转换

四 Runtime项目实战

TODO

Demo的展示

参考

1. Runtime运行时 isa指针 SEL方法选择器 IMP函数指针 Method方法 Runtime消息机制 Runtime的使用
2. iOS~Runtime理解 - 简书
3. Objective-C Runtime | yulingtianxia's blog
4. iOS - Runtime 方法与消息 - 简书
5. 深入理解Objective-C：方法缓存
6. Objective-C 消息发送与转发机制原理

DiaryCard-20-09

2020年9月

CI集成优化

项目集成

1. iOS利用Jenkins实现自动化打包（SVN版） - 简书
2. Ccache 让你的编译时间飞起来 - 简书
3. BLStopwatch代码耗时打点计时器
4. 一次立竿见影的启动时间优化 - 简书

Jenkins

Jenkins是个比较方便持续集成的工具，简单记录一下利用Jenkin拉取SVN的iOS代码，并且打包上传到蒲公英（fir.im类似）的过程。安卓只需要安装对应的插件就可以。可以实现定时打包发布任务，方便自动化管理。考虑到现在代码基本往Git上迁移，在第八步给出快捷迁移SVN代码到Git的方法。

Ccache

Ccache 是一个编译缓存器，它会在实际编译之前先检查缓存。它有直接和预处理模式，而且由于在 Clang 3.2 版本之前是不支持 ccache 插件，所以在 Clang 3.2 之前会有一些问题，但是现在 Clang 的版本是 3.2.3，所以没有 Clang 不支持的问题。ccache 是一个具有悠久历史的项目，其主要焦点是快速正确。

逆向

逆向App，进行分析

KVO

KVO

占坑~

请你出一套iOS面试题

请你出一套iOS面试题

底层

• 1.1 在一个对象的方法里面: self.name = "object"; 和 name = "object"有什么不同吗?

参考解答: self.name ="object":会调用对象的setName(）方法; name =“object":会直接把object赋值给当前对象的name属性。

• 1.2 对于语句NSString*obj = [[NSData alloc] init]; obj在编译时和运行时分别时什么类型的对象?

参考解答: 编译时是NSString的类型, 运行时是NSData类型的对象

• 1.3 想到一个关于Runloop的面试题：
  在程序通过main()函数启动后，在主线程开启UIApplicationMain的Runloop后，在下面的
  main()函数里创建了一个autoreleasepool，请问如果程序不退出，main()函数永远不会返回，那么程序中（比如一个VC中）创建的对象是否就永远不会被释放？

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

参考解答: 在程序创建的对象，不是被main()函数中的autoreleasepool管理的，
而是由主线程的Runloop管理，在某次Runloop循环中，Runloop休眠之前调用了对象的release方法释放。

在每次Runloop循环中，Runloop休眠之前会调用了对象的release方法释放AutoreleasePoolPage中边界内的对象。

• KVO · Issue #5 · FrizzleFur/DailyLearning
• Runtime · Issue #3 · FrizzleFur/DailyLearning
• Block · Issue #7 · FrizzleFur/DailyLearning

Cocoa

• 2.1 这个写法会出什么问题:@Property (copy) NSMutableArray array

参考解答: 两个问题: 1、添加，删除,修改数组内的元素的时候程序会因为找不到对应的方法而崩溃.因为copy就是复制一个不可变NSArray的对象，使用了atomic属性会严重影响性能。

• 2.2 copy 和strong的使用?

参考解答: 我们在声明一个NSString属性时，对于其内存相关特性，通常有两种选择(基于ARC环境): strong与copy。那这两者有什么区别呢?什么时候该用strong,什么时候该用copy呢?

• 由于NSMutableString是NSString的子类，所以一个NSString指针 可以指向NSMutableString对象，让我们的strongString指针指向一 个可变字符串是OK的。

• 而上面的例子可以看出，当源字符串是NSString时，由于字符串是不可变的，所以，不管是strong还是copy属性的对象，都是指向源对象，copy操作只是做了次浅拷贝。当源字符串是NSMutableString时，strong属 性只是增加了源字符串的引用计数，而copy属性则是对源字符串做了次深拷贝，产生一个新的对象，且copy属性对象指向这个新的对象。另外需要注意的是，这个copy属性对象的类型始终是NSString,而不是NSMutableString,因此其是不可变的。

• 这里还有一个性能问题，即在源字符串是NSMutableString, strong是单纯的增加对象的用计数，而copy操作是执行了一次深拷贝，所以性能上会有所差异。而如果源字符串是NSString时,则没有这个问题。

• 所以，在声明NSString属性时，到底是选择strong还是copy,可以根据实际情况来定。不过，一般我们将对象声明为NSString时，都不希望它改变，所以大多数情况下，我们建议用copy,以免因可变字符串的修改导致的一些非预期问题。

• 2.3 __strong的使用场景？

• 2.4 谈谈AutoLayout？

参考解答: AutoLayout，是苹果公司提供的一个基于约束布局，动态计算视图大小和位置的库，并且已经集成到了Xcode开发环境里。

• AutoLayout的实现原理

  • AutoLayout是基于Cassowary算法，
  • Cassowary 算法让视图位置可以按照一种简单的布局思路来写，这些简单的相对位置描述可以在运行时动态地计算出视图具体的位置。视图位置的写法简化了，界面相关代码也就更易于维护。
  • Cassowary 能够有效解析线性等式系统和线性不等式系统，用来表示用户界面中那些相等关系和不等关系。基于此，Cassowary 开发了一种规则系统，通过约束来描述视图间的关系。约束就是规则，这个规则能够表示出一个视图相对于另一个视图的位置。
  • Auto Layout 不只有布局算法 Cassoway，还包含了布局在运行时的生命周期等一整套布局引擎系统，用来统一管理布局的创建、更新和销毁。了解 Auto Layout 的生命周期，这一整套布局引擎系统叫作 Layout Engine ，是 Auto Layout 的核心，主导着整个界面布局。
  • 每个视图在得到自己的布局之前，Layout Engine 会将视图、约束、优先级、固定大小通过计算转换成最终的大小和位置。在 Layout Engine 里，每当约束发生变化，就会触发 Deffered Layout Pass，完成后进入监听约束变化的状态。当再次监听到约束变化，即进入下一轮循环中。整个过程如下图所示：
  • 

• AutoLayout性能

  • 兄弟视图之间没有关系时，是不会出现性能呈指数增加问题的。这就表示 Cassowary 算法在添加时是高效的。但如果兄弟视图间有关系的话，在视图遍历时会不断处理和兄弟视图间的关系，这时会有修改更新计算。
  • iOS 12 之前，Auto Layout 并没有用上 Cassowary 高效修改更新的特性。很多约束变化时都会重新创建一个计算引擎 NSISEnginer 将约束关系重新加进来，然后重新计算。结果就是，涉及到的约束关系变多时，新的计算引擎需要重新计算，最终导致计算量呈指数级增加。
  • iOS12 的 Auto Layout 更多地利用了 Cassowary 算法的界面更新策略，使其真正完成了高效的界面线性策略计算。
  • UIStackView： iOS9后，在 Auto Layout 基础上模仿前端 Flexbox 布局思路的 UIStackView；可以提高布局效率。

• AutoLayout关于更新的几个方法的区别

  • setNeedsLayout：告知页面需要更新，但是不会立刻开始更新。执行后会立刻调用layoutSubviews。
  • layoutIfNeeded：告知页面布局立刻更新。所以一般都会和setNeedsLayout一起使用。如果希望立刻生成新的frame需要调用此方法，利用这点一般布局动画可以在更新布局后直接使用这个方法让动画生效。
  • layoutSubviews：系统重写布局
  • setNeedsUpdateConstraints：告知需要更新约束，但是不会立刻开始
  • updateConstraintsIfNeeded：告知立刻更新约束
  • updateConstraints：系统更新约束
    参考：Masonry · ming1016/study Wiki

• 多线程Demo学习 · Issue #21 · FrizzleFur/DailyLearning

性能优化

TableView性能优化

1. 行高一定要缓存!
2. 不要动态创建子视图所有的子视图都预先创建，如果不需要显示可以设置hidden。
3. 所有的子视图都应该添加到contentView上
4. 所有的子视图都必须指定背景颜色，且所有的颜色都不要使用alpha
5. cell栅格化
6. 异步绘制

UITableView核心**

• UITableView最核心的**就是UITableViewCelI的重用机制。简单的理解就是: UITableView只会创建一屏幕(或一屏幕多一点)的UITableViewCell,其他都是从中取出来重用的。每当Cell滑出屏幕时，就会放入到一个集合(或数组) 中(这里就相当于一个重用池)，当要显示某一位置的Cel时，会先去集合(或数组)中取，如果有，就直接拿来显示;如果没有，才会创建。这样做的好处可想而知，极大的减少了内存的开销。
• tableView:cellForRowAtIndexPath:和tableView:heightForRowAtIndexPath:.
• UITableView是继承自UIScrolView的，需要先确定它contentSize及每个Cell的位置，然后才会把重用的Cell放置到对应的位置。所以事实上，UITableView的回调顺序是先多次调用tableView:heightForRowAtIndexPath:以确定contentSize及Cel的位置，然后才会调用tableView:cellForRowAtIndexPath;,从而来显示在当前屏幕的Cell。
• 思路是把赋值和计算布局分离。这样让tableView:cellForRowAtIndexPath:方法只负责赋值,
• tableView:heightForRowAtIndexPath:方法只负责计算高度。
• 可以在获得数据后，直接先根据数据源计算出对应的布局，并缓存到数据源中，这样在tableView:heightForRowAtlndexPath:方法中就直接返回高度，而不需要每次都计算了。

UlTableView的优化总结

1. 提前计算并缓存好高度(布局) ， 因heightForRowAtIndexPath:是调用最频繁的方法;
2. 异步绘制，遇到复杂界面，遇到性能瓶颈时，可能就是突破口;
3. 滑动时按需加载，这个在大量图片展示，网络加载的时候很管用! (SDWeblmage已经实现异步加载，配合这条性能杠杠的)。正确使用reuseldentifier来重用Cells

• 尽量使所有的view opaque, 包括Cell自身
• 尽量少用或不用透明图层如果Cell内现实的内容来自web，使用异步加载，缓存请求结果减少subviews的数量
• 在heightForRowAtIndexPath:中尽量不使用cellForRowAtIndexPath:, 如果你需要用到它，只用一次然后缓存结果
• 尽量少用addView给Cell动态添加View,可以初始化时就添加，然后通过hide来控制是否显示在使用UITableView的时候，有的时候你会碰到Cell卡顿，图片加载慢，使得滑动cel时变得不那么流畅，这些都会影响用户体验，拉低整体app的效果。

1. 使用cell重用机制，尽可能快地返回重用cell实例这点大家都应该比较清楚，使用reuse机制能大幅降低创建cell所带来的损耗，这就要各位在UITableView的dataSource中实现的tableView:cellForRowAtIndexPath:方法。只是有一点，尽量不要在此时绑定数据，因为目前在屏幕上还没有cell，可以在UITableView的delegate方法tableView:willDisplayCell:forRowAtIndexPath:中进行数据的填充。需要说明的是，你可能会动态计算cel高度，但最好是不要选择Autolayout。使用Autolayout后，会根据cel的子视图使得求解的约束也越多，从而降低计算速度，影响滑动时FPS。所以，为了使tableview平滑滚动，请使用动态计算高度，不要选择Autolayout。
2. cell的subViews的各级opaque值要设成YES,opaque用于辅助绘图系统，表示UIView是否透明。 在不透明的情况下，渲染视图时需要快速地渲染，以提高性能。渲染最慢的操作之一是混合(blending)。提高性能的方法是减少混合操作的次数，其实就是GPU的不合理使用，这是硬件来完成的(混合操作由GPU来执行，因为这个硬件就是用来做混合操作的，当然不只是混合)。优化混合操作的关键点是在平衡CPU和GPU的负载。还有就是cell的layer的shouldRasterize要设成YES。
3. 尽量少用addView给Cell动态添加View，可以初始化时就添加，然后通过hide来控制是否显示在使用UITableView的时候，有的时候你会碰到Cell卡顿，图片加载慢，使得滑动cel时变得不那么流畅，这些都会影响用户体验，拉低整体app的效果。
4. 在绘制字符串时，尽可能使用drawAtPoint:withFont: , 在绘制图片，尽量使用drawAtPoint
   • 不要使用更复杂的drawAtPoint:(CGPoint)point forWidth:(CGFloat)width withFont:(UIFont*)font
   • lineBreakMode:(UIL ineBreakModel)lineBreakMode;如果要绘制过长的字符串，建议先截断，然后使用drawAtPoint:withFont:方法绘制。
   • 不要使用drawInRect，因为它在绘制过程中对图片放缩大小，消耗CPU。
   • 其实，最快的绘制就是你不要做任何绘制。有时，通过UIGraphicsBeginlmageContextWithOptions()或者CGBitmapContextCeate(）创建位图会显得更有意义，从位图上面抓取图像，并设置为CALayer的内容。如果你必须实现-drawRect;，并且你必须绘制大量的东西，这将占用时间。
5. cell异步加载图片以及缓存
   • 对于cell里的图片采用异步的方式，加载好后缓存。当图片还没有请求加载时，你可以使用默认图片。
   • 一旦你缓存好图片，使用cell的重用机制时就可以从关联好的视图源里以相应的url来找到对应的缓存图片，缓存大大节省重复请求图片的耗损。只是你要考虑内存级别的缓存还是磁盘级别的缓存，记得使用完毕清缓存哦! (记得减少内存级别的拷贝)
   • 为了防止图片多次下载，我们需要对图片做缓存，缓存分为内存缓存于沙盒缓存，我们当然两种都要实现。
   • 一般情况下在我们会在cellForRow方法里面设置cell的图片数据源，也就是说如果一个cell的imageview对象开启了一个下载任务，这个时候该cell对象发生了重用，新的image数据源会开启。
   • 另外的一个下载任务，由于他们关联的imageview对象实际。上是同一个cell实例的imageview对象，就会发生2个下载任务回调给同一个imageview对象。这个时候就有必要做一些处理，避免回调发生时，错误的image数据源刷新了UI。
   • 在我们向下滑动tableview的时候我们需要手动去取消掉下载操作，当用户停止滑动，再去执行下载操作
   • 如果快速滑下去，然后又滑回来的话，图片是过了一会才显示出来，这是因为快速滑动的时候,旧数据源的下载任务被取消掉了。
   • 异步下载图片我们用的是NSOperation,并且创建一个全局的queue来管理下载图片的操作。在把图片显示到Cell上之前先判断内存中(images字典中)有没有图片
     • 如果有，则取出ur对应的图片来显示，如果没有，再去沙盒缓存中查看，当然存到沙盒中都是NSData。如果沙盒缓存中有，我们取出对应的数据给Cell去显示
     • 如果沙盒中也没有图片，我们先显示占位图片。再创建operation去执行下载操作了。当然在创建operation之前，我们要判断这个operation操作是否存在。
     • 如果没有下载操作，我们才需要真正的去创建operation执行下载。创建好下载操作之后应该把该操作存放到全局队列中去异步执行，同时吧操作放入operations字典中记录下来。
   • 下载完成之后:
     • 把下载好的图片放到内存中、同时存到沙盒缓存中，执行完上面的操作之后回到主线程刷新表格,
     • 从operations字典中移除下载操作(防止operations越来越大，同时保证下载失败后，能重新下载)

网络请求

网络Http请求 · Issue #9 · FrizzleFur/DailyLearning

架构设计

• 搭建App快速发开框架 · Issue #23 · FrizzleFur/DailyLearning

设计模式

• ViewModel+RAC · Issue #2 · FrizzleFur/DailyLearning
• 看懂UML类图和时序图 · Issue #18 · FrizzleFur/DailyLearning

组件化

知名框架原理

• Alamofire 的设计之道 · Issue #17 · FrizzleFur/DailyLearning
• SDWebImg框架学习 · Issue #22 · FrizzleFur/DailyLearning

CS基础

• CS基础 · Issue #10 · FrizzleFur/DailyLearning

职业

• 你认为你的最大优势点在哪？有什么不足或者需要提高的地方?

Hybrid

1. Flutter学习
2. Weex学习
3. JS学习- Vue框架

Flutter的项目实践

学习Flutter还是为了在项目中利用Flutter的优势，提升开发效率和性能。

先分flutter的介绍，语法重点，底层原理，和项目实战，和注意坑点。

SwiftUI & Combine

主要通过项目学习SwiftUI
SwiftUI的原理&**
Combine框架的使用

ViewModel+RAC

DailyCard-18-09

2018-03-15

今天规划

• 今天主要以学习为主
• 下午晚点去跑步

学习收获（源码、书籍、文章）

• SwipeTableView 看了架构，类似捕手发现的模块,tabBar下面对应一个滚动的多个竖直方向的视图，
• NJHu/iOSProject 虽然也是iOS的Demo集合，但是看README后感觉很想学，整理的比较好吧。作者对issue的回复也很有范：
  
• NJHu/vue 是一个很好学习前端JavaScript的好资源

回顾感想

• SwipeTableView作者做iOS只有一年时间，对比自己，倍感惭愧。学习需要提高效率和专注，戒骄戒躁。沉下❤️来才能快速前行。
• 记录很重要，但是回顾才能有所收获
• 就想房间需要定期清理一样，生活和学习都需要定期的Review, 清除垃圾，提高效率。
• ShannonChenCHN的周报记录给我很大的启发，自己一直在零散的记录，没有形成知识体系是很伤的，反应出不够专注吧。

明天计划

亮点

Swift进阶

Swift进阶

Guide

ipader/SwiftGuide: Swift Featured Projects in brain Mapping

Swift函数

Swift 3关于函数类型的一项重要提议 - 泊学 - 一个全栈工程师的自学网站

Alamofire

基于Alamofire的HTTP通信 - 泊学 - 一个全栈工程师的自学网站

RxSwift

• RxSwift 使用详解系列 - 简书
• RxSwift - step by step - 泊学 - 一个全栈工程师的自学网站
• 《RxSwift.Reactive.Programming.with.Swift.v2.0》

MVVM

Master MVVM in Swift - 泊学 - 一个全栈工程师的自学网站

算法

Algorithms in Swift 3 - 泊学 - 一个全栈工程师的自学网站

基于Github-Issue的GTD工作流

基于Github-Issue的GTD工作流

• Github issues
• Github project

工具

• Bee for mac
• Zen for Chome, Zen for iOS.

Github issues

• 模板template
• 打标签tag
• 关联issue

Github project

• todo
• in progress
• review
• done

Todo

• 整理成文档
• 输出到简书

参考

1. Tracking Projects From A to ZenHub on Vimeo
2. 培训和资源
3. zenhub - Support

DiaryCard-19-05

面试总结

一次好的面试是一次难得的交流机会。

CS基础

1. 《深入理解计算机系统 第二版》
2. 数据结构
3. 算法

DailyCard-19-08

DiaryCard-19-02

2月的记录

搭建App快速发开框架

搭建App快速发开框架

• App架构
  • 设计模式
    • RAC+MVVM
    • 单例
    • KVO
• App工具
  • 网络请求
  • 动画
  • 数据处理
  • 分类工具
  • Runtime
    • 方法交换
    • 属性绑定
    • 消息转发
  • 定时器
• App的UI工具库
  • 封装的UI库
  • 参考QMUI_iOS
  • 空页面
  • HUD
• 其他
  • 分享
  • 三方登录
  • 统计打点
  • 个推
• App三方库
  • BlockKit
  • AFN
  • Alamafire
  • SDWebImage
  • RAC
  • Masonry
  • YYModel
  • MJRefresh
  • WebViewJavascriptBridge

DiaryCard-20-10

2020年10月

多线程Demo学习

网络Http请求

• 读《网络是怎样连接的》
• HTTP & Web Servers - Udacity

• HTML 教程- (HTML5 标准)

SDWebImg框架学习

analyze/iOS 源代码分析 --- SDWebImage.md at master · draveness/analyze

Alamofire 的设计之道

Alamofire 的设计之道 - iOS - 掘金

Alamofire.md 源代码分析

DiaryCard-19-03

3月的记录