从十月中旬面试至今已满一个月, 尘埃即将落地, 在此对这段面试经历做个小结.

内容主要围绕面试准备以及职业发展两方面展开, 虽不包含具体面试题等信息, 但会列出个人归纳的面试考纲以及注意事项等供参考.

面试经历

面试结果

老规矩, 先上大家关心的结果

• 上海:
  • 喜马拉雅FM: offer call
  • 小红书: offer call
  • 携程: 二轮游卒
  • 英语流利说: offer call
  • 饿了么: 三轮游+hr面卒
  • B站: offer call
  • 美团: 二轮游 卒
  • 抖音: 三轮游+hr面卒
• 北京:
  • 百度贴吧: offer call
  • 蚂蚁金服: 5面完, 等hr面
  • 高德地图: offer call
  • 百度凤巢: offer call
  • 西瓜视频: offer call

投递建议

首先, 无论是走内推、猎头或自投(某直聘、某钩、官网/公众号)等方式, 在简历投递次数和频率上都要克制, 比如只安排一周内的面试、每天至多面1家、预约下午面试等等.

其次, 看清楚JD职位要求, 以及错开对同派系公司不同岗位的投递. 比如, 可能公司内部共用同一套招聘系统, 某个岗位进入面试流程后, 那么其他岗位是无法同时进行面试的.

最后, 不要太在意投递结果, 2~3天没回复就尝试投递其他岗位.

另外, 可能有同学注意到, 我面过同派系不同bu的岗位, 据我个人不靠谱的猜测, 这块逻辑可能是这样的:

1
2
3
4
5
6
7

if (内推 + 之前面试记录性质良好) {
  // 可能有机会
} else if (自己继续投 + 多争取一番) {
  // 机会很小, 但想去就得尝试
} else {
  // 可能得半年后了
}

面试准备

准备方面我分为两部分, 首先是心理层面的准备, 然后才是战备”物资”

心理准备

1.明确动机

比如为什么要跳槽或你想从事什么内容? 马爸爸曾提及过三要素(钱、心、事), 你是否完全认同? 或是有其他的原因?

不鼓励轻易跳槽, 跳槽未必有利于你长期的发展, 还有就是像某东在就职经历这块卡的很严

2.优势劣势

面对其他候选人, 是否清楚自己的优势劣势？比如你某方面技术突出、抗压能力更好、沟通能力更好等. 认清不足以及想好未来具体的提高的计划

3.最坏打算

若决定离开, 那么便坚决离开, 没有回头路. 决定前做好最坏打算, 比如连续面试下来结果都不好, 是否能承受, 有无备选方案?

4.学会健忘

可能某几次面试结果不尽人意, 或是因为准备不足, 或是因为”气场不和”等等. 总之摆正心态, 忘记之前的面试结果, 对面试中发现的问题有针对性的去总结和提高, 然后接着面就好

尤其对于”放长线作战”的同学, 个人推荐花时间搞清楚以上4点

物资准备

“物资”直接决定面试的成败. 主要分为硬实力与软实力的体现

硬实力

相比于记面试题, 不如夯实题目后边的知识点, 面试遇到原题的几率还是不要赌了. 掌握知识点无论对面试或工作成长都大有裨益

此处奉上三年iOS开发面试考纲, 个人愚见, 仅供参考

• 通用技能
  • 数据结构、算法(排序、字符串、数组、位操作、回溯、双指针、DFS、BFS、DP、分治、二分查找..)
  • 设计模式(创建型、结构型、行为型设计模式)
  • 计算机网络(应用层/传输层协议、网络分层..)
  • 操作系统(进程、线程、内存布局..)
  • 编译原理(编译过程..)
• iOS技能
  • 修饰符, 可变不可变对象等基础
  • Runtime
  • RunLoop
  • KVC、KVO原理
  • block本质
  • category本质
  • 内存管理
  • 事件传递
  • App、VC、View、CALayer生命周期
  • 多线程(队列、锁)
  • 性能优化(体验优化、启动优化、网络优化、编译优化)
  • 主流组件化、模块化、架构方案
  • Core Animation、屏幕渲染等
  • 数据持久化方案
  • 动态化方案(Hybird/RN/Weex/Flutter)
• 项目经历
  • 简历上写的
  • 主流三方库

所有列举的知识点, 本次面试均有涉及. 深度方面需个人进行挖掘

算法貌似大厂必考项, 技术面几乎每轮都有, 推荐leetcode分类型进行算法思路的训练, 一般可以秒杀medium的题目足矣, 仅一次问到hard难度的题目

然后iOS知识点考察, 仅知道是什么远不够, 更多的是为什么, 实现原理这些. 平时需要多积累, 比如从某个问题深入挖掘, 看源码, 博客文章(内容未必都对, 带着辩证思维去看)等. 另外印象笔记剪藏功能用于收藏回顾真的相当不错.

面试官往往会由浅入深进行考察, 若不会就明确表示出来(吃过强答的亏, 印象分那是卡卡卡的掉) 一定要多与面试官沟通, 倾听面试官把问题描述完, 若只是忘了细节争取能说下思路也好

软实力

• 沟通能力
• 价值观
• 学习方式
• 职业规划
• EQ
• …

最后, 有时间不妨了解下面试岗位的相关产品, 比如对产品体验一番, 或做个逆向, 面试时也会多一笔谈资

职业发展

这方面结合各位大佬赠与的宝贵建议简单概括一下

• 围绕核心

  对于走技术路线的同学来说, 毫无疑问就是不断提升技术方面的深度以及广度

• 提高软实力

  专业以外的能力, 具体前边也有提及, 比如学习方式的改进, 沟通能力的提高, 变得更靠谱等

• 承担更多

  不单单专注于完成分类之事或提高个人, 可以尝试放大格局, 主动去承担本分以外的职责, 比如思考并实践对整个团队或者整个公司层面有益的事

The End

全文观点皆主观想法, 各位见仁见智

最后祝大家早日拿到期望offer, 未来发展上越走越远!

还特别感谢老东家的知遇之恩以及各位领导同事对我的关照, 谢谢所有给与我面试机会的公司跟遇到的每位面试官和hr同学.

很多大佬(达文哥、官钦哥、东哥、亮哥等等)在面试中或私下就职业发展方面赠与了非常非常宝贵的建议, 受益匪浅, 大恩不言谢!

为了满足运营同学动态配置频道页的内容排版, 以及产品同学一次开发, 各频道复用的需求, 要开发一个框架来满足以下两点:

• 内容灵活排版: 某个频道页展示的内容及其顺序, 甚至说一个新的频道页, 皆可由运营同学在cms后台直接配置
• 模块全局复用: 一个承载内容的 模块 开发完后, 可在全部频道页配置使用

页面模块化的好处:

1. 方便运营同学在线上cms后台直接创建新的界面或动态调整界面(导航栏、页头脚、内容元素等). 缩短内容上线周期
2. 在我们不同的业务代码组件化后, 是相互隔离的. 不同的业务线开发好的业务组件难以复用(数据模型、命名、方法定义等都不统一). 而且并非所有业务组件都能封装成通用型基础组件下沉到基础组件库中. 开发这个框架, 就可以同时创建一个统一规范的业务组件库

二、模块定义

上文提及的 内容 , 就是我们各频道页看到的 模块. 不同的 模块 具有其独特的产品功能与运营目的.

以驴妈妈首页频道为例, 如下图:

每个框所圈区域为一个独立模块. 比如:

• banner模块(产品推荐、活动推广、广告投放等)
• 频道入口、主题列表模块(用户分流导向)
• 旅行头条模块(热门游记推荐)
• …

此外, 每个模块可以包含单个或多个不同的模块组件:

三、模块化设计原则

除了考虑SOLID(六大原则)外, 框架设计还会围绕以下三点.

3.1 面向接口

通过定义 接口(即协议) 抽象和规范框架所关心的类或事. 框架与模块间低耦合.

举个例子, 对于框架来说, 它并不关心配置数据是什么结构或如何获取, 它仅关心的是有多少个模块、每个模块在容器中所占大小以及位置等数据.

可为此定义一个数据源协议, 来规范充当框架数据源对象所必须遵循的行为. 至于数据源对象的具体类型是什么不重要, 只要遵循协议即可充当框架中的某个角色.

接口 就好比一份 合同, 拟定好的 合同 就不能轻易修改, 如果贸然修改原有的条款, 那势必波及到所有遵循 合同 的人. 所以, 合同 制定阶段尤为重要, 不能好高骛远也不能鼠目寸光, 定好了大家就按照 合同 来.

当然, 面向接口与面向对象并不冲突, 反而是相辅相成, 此处不展开讨论.

3.2 数据驱动

数据决定并驱动内容的展示与响应.

• 数据决定展示内容, 即数据与内容一一对应:

  框架根据数据源提供的相关数据, 决定每个模块该创建的组件类型, 模块组件的展示大小及布局位置等.

• 数据驱动内容变化. 关注点为数据, 而非事件.

  举个例子, 对于框架中模块发生的任意事件, 其结果也就两种:

  1. 事件发生后, 数据有变化
  2. 事件发生后, 数据无变化

  

  也就说框架不会去管具体发生什么事件, 只”盯着”它所关心的数据有没有变

  另外, 事件驱动中一个事件往往对应一个响应操作, 是1对1的关系. 而数据驱动可以是1对N的关系, 可能是多个事件修改同个数据.

3.3 模块隔离

模块间相互隔离, 模块独立自治, 其相关事务自行处理.

模块可单独开发, 注册到配置中. 模块内可自行使用MVX、VIPER等结构型设计模式(Structual Design Pattern).

此外, 模块联合开发中, 框架与模块也应该适当隔离. 遵循 依赖倒置原则 . 模块(高层)依赖也不应该直接依赖框架(低层)进行开发, 框架仅知道我们抽象出来模块接口, 模块也仅知道框架接口, 双方都遵循接口进行实现.

通俗来说就是框架的功能开发与模块的开发是两条平行线, 除非修改接口, 否则双方修改实现都不会影响到另一方.

目前这块实现是传统型架构(4.6架构图), 即模块的开发是直接依赖了框架的实现(具体的基类), 框架没有抽象出暴露给上层的接口. 在遵循 依赖倒置原则 后, 模块(高层)在访问低层(框架)时, 就只能接触到遵循框架接口的某个对象(UIViewController\<XxxProtocol> *), 而非具体某个XXXClass类.

还是取舍的问题, 选择性的开闭. 若完全遵循 依赖倒置原则, 那高层也没法直接依赖低层实现进行继承了, 包括哪些不允许修改, 哪些要使用公共实现, 哪些留给上层去拓展等等.

四、模块化框架设计

以iOS平台举例, 阐述对整个框架的具体设计. 抛开Android和iOS平台系统编码的风格习惯和具体实现上存在的不同, 整体思想大同小异.

4.1 数据源

一个频道页由若干个模块组成, 一个模块包含1个或多个不同的组件. 框架根据数据源提供的信息, 创建和安置模块组件.

4.1.1 数据源协议

1. 模块数据源协议: 主要向框架提供某个模块包含的组件信息、相关的布局信息、以及组件填充数据的内容等等

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

   typedef NSObject<LVTSectionDataSource> LVTSectionData; @protocol LVTSectionDataSource <NSObject> - (LVTemplateClass)headerClass; - (LVTemplateClass)cellClassAtIndex:(NSUInteger)index; - ... - (BOOL)hidden; - (NSUInteger)numOfItems; - (UIEdgeInsets)sectionInset; - (CGFloat)itemSpace; - (CGFloat)lineSpace; - (CGSize)itemSizeAtIndex:(NSUInteger)index withContainerSize:(CGSize)size; - ... - (nullable LVTItemModel *)itemModelAtIndex:(NSUInteger)index; - (void)requestSectionCustomData; @end

2. 频道页数据源协议: 主要向框架提供整个频道拥有的模块总数, 以及各模块的局部数据源

   1 2 3 4 5 6 7 8

   @protocol LVTPageDataSource <NSObject> - (NSUInteger)numberOfSections; - (LVTSectionData *)sectionDataAt:(NSUInteger)section; - (void)fetchPageDataWithCompletedBlock:(void (^)(NSError _Nullable *error))completedBlk; @end

4.1.2 模块组件管理

对于模块内的任意组件, 都有对应一个标识ID. 我们通过一个配置文件来维护标识与组件的对应关系. 联合开发时, 每开发好一个新的组件, 就只用修改配置文件.

配置的JSON结构大致如下:

1
2
3
4
5
6
7
8
9
10
11
12
13

// 部分举例
{
  "header": {
    "header1": "LVTXXXHeader", // value为具体类名
    "header2": "LVTXXXHeader",
    ...
  },
  "cell": {
    "cell1": "LVTXXXCell",
    ...
  },
  ...
}

通过ID我们可获得一个具体的类名, 再使用反射获得类对象以供框架创建组件实例.

在iOS上我们通过一个ClassMapper来专门维护对应关系, 如下图.

上图类名仅为更好的表达Mapper的职责, 实际ClassMapper返回的类对象会使用泛型来进行解耦, ClassMapper中也不会引入任何组件的头文件.

4.1.3 数据流向

从原始数据到呈现到屏幕上的每个模块组件, 数据流向如下图所示:

1
2
3
4
5

上图各元素代表:
LVTPageDataSource为遵循 频道数据源协议 的对象
LVTSectionData为遵循 模块数据源协议 的对象
ClassMapper为管理对应关系的对象
LVTCellXXX、LVTHeaderXXX为组件等

4.2 模块组件

组件是模块化框架中复用的基础元素.

4.2.1 组件协议

模块组件分为可复用与不可复用两类, 分别对应以下协议:

1. 复用组件协议: 提供组件用于复用队列的复用Id、用于布局的元素大小等

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

   typedef Class<LVTReuseItemProtocol> LVTemplateClass; typedef UICollectionViewCell<LVTReuseItemProtocol> LVTemplateCell; typedef UICollectionReusableView<LVTReuseItemProtocol> LVTemplateReuseView; typedef WKWebView<LVTReuseItemProtocol> LVTemplateWebView; @protocol LVTReuseItemProtocol <NSObject> + (NSString *)tIdentifier; + (CGSize)itemSizeWithModel:(LVTItemModel *)model andContainerSize:(CGSize)size; - (void)configItemWithModel:(LVTItemModel *)model; - (void)setEventCenter:(id<LVTEventCenterProtocol>)center; - (void)setCacheUtil:(LVTCacheUtil *)util; - (void)itemPrepareForReuse; @end

2. 不可复用的悬浮组件协议: 提供视图高度, 悬浮定位信息等

   1 2 3 4 5 6 7 8 9 10 11

   typedef Class<LVTFloatViewProtocol> LVTFloatViewClass; @protocol LVTFloatViewProtocol <NSObject> + (CGFloat)topInSection; + (CGFloat)viewHeight; - (void)configItemWithModel:(LVTItemModel *)model; - ... @end

数据填充等公共方法可抽象到另一个协议中, 再进行继承

4.2.2 模块组件数据模型

用于填充模块组件的数据模型类型不一, 框架也不与具体模型产生瓜葛. 通过协议规范数据模型得有的属性即可.

数据模型协议:

1
2
3
4
5
6
7
8
9
10

typedef NSObject<LVTItemModelProtocol> LVTItemModel;

@protocol LVTItemModelProtocol <NSObject>

@property (nonatomic, assign) BOOL isFolded;
@property (nonatomic, assign) CGSize itemSize;
@property (nonatomic, assign) CGSize foldedItemSize;
...

@end

我们在前边协议中看到的LVTItemModel即代表了遵循该协议的数据模型

4.3 频道代理对象协议

以上我们说的那些模块在框架中的位置都是可调整的. 对于频道中位置固定的内容, 比如导航栏, 容器页头, 页脚等元素, 会交给一个频道的 代理对象 来处理.

除了固定内容的管理, 还有一些与框架无关联的业务功能, 比如点位获取、站点切换等功能, 也会放到代理对象里边实现, 但不在协议里边体现.

具体代理协议如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@protocol LVTPageDelegate <NSObject>

@property (nonatomic, weak) LVTEventCenter *eventCenter;
@property (nonatomic, weak) LVTLayoutQuery *layoutQuery;

@property (nonatomic, readonly) CGFloat containerViewTopInset;
@property (nonatomic, readonly) BOOL hidesBottomBarWhenPushed;
@property (nonatomic, readonly) BOOL showsLoadingIndicator;

@property (nonatomic, strong) MJRefreshHeader *header;
@property (nonatomic, strong) MJRefreshFooter *footer;
...

- (void)setupPageUI;
- (void)configPageWithModel:(id)model;
- ...

@end

代理类型的管理, 与模块管理一致, 共用配置文件, 代理类对象的获取同样通过ClassMapper.

另外, 严格意义上讲, 把这个delegate命名为strategy会更加合适, 它的使用体现是 策略模式. 不同的代理有着不同的实现, 某个频道运行时, 也可能会动态的切换代理对象.

比如, 某次下拉刷新后, 下发的代理ID变了, 即对应的类对象变了, 就会创建新的 策略对象 来替换, 从而产生了不一样的UI或行为表现.

4.4 对象通信

模块之间, 模块与框架间存在相互通讯的需求. 比如在某些模块组件需要知道框架存在的生命周期事件, 以作出对应的操作.

对象间的常见通讯方式有:

1. 命令模式或Target-Action
2. 代理模式或回调Callback
3. 观察者模式

考虑到模块间通讯可以1对多, 而前面两种皆为1对1通讯, 所以我们选择基于ReactiveCocoa或RxJava库, 遵循观察者模式来实现一个囊括所有跨模块事件的共享对象, 以进行集中式管理. 以下称之为 事件中心.

具体来说, 就是把有通信需求模块的相关事件集, 以空方法的形式统统添加到事件中心的共享对象上暴露出来(方法实现为空, 但并非抽象类). 各模块则根据自己的需求, 选择性的订阅共享对象上的事件.

模块通讯方式则为直接调用共享事件中心上已添加好的事件方法, 如下:

在 4.2 模块组件一节中的两个协议里, 都可见定义了设置事件中心的方法以供框架赋值, 以供组件访问.

4.5 交互图

整个框架核心元素间的交互如下:

上图没有包括具体的交互细节, 补上两张时序图:

• 某频道页首屏展示的时序图(忽略本地缓存等各种情况):

  

  注: 模块的数据源(SectionData)会向ClassMapper获取具体的类对象, 具体可见数据源协议

• 某个框架事件(比如切换界面、滑动等)通过事件中心传递给订阅者的时序图:

  

  事件传递为同步操作, 哪个线程调用哪个线程触发, 订阅者接收事件的顺序由订阅时的先后顺序决定

4.6 架构一览

上张简版架构图以示频道页模块化后上述提到的元素分别位于哪一层.

五、小结

以上便为驴妈妈频道页模块化的大致思路, 思路不复杂, 主要细节繁多, 就不一一展开.

无论何种实现方案, 在灵活满足业务需求的前提下, 同时保证技术上的拓展性, 未来再不断”打怪升级”, 都不失为一个较优解.

原文作者: 傅翔

原文链接: https://mp.weixin.qq.com/s/J5YhTk5gyTt7Ie5803PeQg

许可协议: 本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可. 非商业转载请注明作者及上述原文链接

本文主要叙述的就是大礼物动效的实现.

先放上按序列帧播放方案实现的动画引擎FXAnimationEngine, Demo中实现了直播间礼物队列、礼物配置、礼物列表, 另外还分别用动画引擎与原生Core Animation去播放序列帧动画以做比较.

然后国际惯例, 上两张图

一、直播应用礼物动画的常见方案

仅个人了解, 实现iOS侧动画配置化常见方案有如下几种:

可以看出, 序列帧播放方案是其中最简单易行的一个. 在我看来, 花椒直播用的即是这套方案, 他们每一个动画, 都会对应一个配置文件config.ini及对应该动画的所有序列帧图片.

感兴趣的朋友可以移至最后一部分礼物资源的下载策略、资源目录结构等相关内容, 更建议尝试去探索一下花椒、映客等主流直播应用的bundle目录以及document中的资源.

二、序列帧播放方案实践

2.1 实现方式

序列帧播放动画一方案的具体实现必须能够满足以下需求:

1. 图片展示: CALayer、UIImageView
2. 按时间间隔逐帧播放: CAKeyframeAnimation、UIImageView、定时器类(CADisplayLink、NSTimer、dispatch_source_t)+切换关键帧逻辑
3. 提供所有序列帧播放完的事件: CAAnimationDelegate、CATransaction CompletionBlock、定时器类+回调触发逻辑

组合方式很多, 比如: CALayer+CAKeyframeAnimation+delegate, UIImageView+定时器, CALayer+定时器类等等.

我们先选定这一套组合进行实践: CALayer+CAKeyframeAnimation+delegate

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 伪代码
- (void)startAnimation {
    UIImage *frame = [UIImage imageWithContentsOfFile:...];
    NSArray<UIImage *> *frames = @[(id)frame.CGImage, ...];
    CAKeyframeAnimation *keyframeAnim = ...;
    keyframeAnim.contents = frames;
    ...
    keyframeAnim.delegate = self;
    [xxx.layer addAnimation:keyframeAnim forKey:@"xxx"];
}

- (void)animationDidStop:(CAAnimation *)anim finished:(BOOL)flag {
    // 触发动画播放结束(全部播放完、中途结束)回调
    ...
}

如果此处你已经下载了Demo, 可以打开Debug Navigator(cmd+6)简单查看内存增长或者留意Xcode Instrument-Allocations中VM:ImageIO_PNG_Data一项, 就会看到有内存增长波峰. 而且序列帧图片越多, 波峰越明显.

那么其他方案是否出现了相同的问题呢? 是的, 其他方案一样会如此, 换成UIImageView自带的animationImages来做序列帧播放或是其他组合方式, 也出现内存激增的情况.

2.2 了解图片加载

在我们搞清楚是什么导致内存激增前, 我们先了解一下图片从磁盘加载, 到写入内存, 最后显示到屏幕上分别都发生了什么. 大致分为如下步骤:

1. 为磁盘中的图片创建映射
2. IO操作读取图片数据流
3. 图片解码位图拷贝, 写入内存
4. 硬件绘制渲染到屏幕

2.2.1 映射文件

当我们通过[UIImage imageWithContentsOfFile:]从磁盘加载图片数据流, 实际上只是为此图片创建了一个文件映射数据, 图片文件既没有真正被加载到内存, 更没有被解码成位图的形式可供Core Animation传递给底层硬件进行渲染, 故此时内存并不会明显增加, 也不会出现因为解码操作导致CPU使用增加的情形. 但从网络下载图片数据不包含在内.

简单提及一下映射文件:

A mapped file uses virtual memory techniques to avoid copying
pages of the file into memory until they are actually needed.

直译就是一个映射文件借助虚拟内存技术来避免当他们还没有真正使用到时就被拷贝到内存中.

下面来一组对照验证一下:

对照组一

1
2
3
4
5
6

- (void)test1 {
    UIImage *frame = [UIImage imageWithContentsOfFile:filePath];
    // 确保超出局部作用域后, 依旧保持对这个Image对象的强引用
    self.frame = frame;
}
// 待上方函数执行完后, 再查看内存使用情况

对照组二

1
2
3
4

- (void)test2 {
    UIImage *frame = [UIImage imageWithContentsOfFile:filePath];
    self.imageview.image = frame;
}

我们可以发现对照组二的内存占用明显比对照组一要多. 即通过imageWithContentsOfFile:创建的UIImage对象后, 内存并没有明显增长, 等我们将该UIImage对象赋值给UIImageView的image属性后的某个时刻, 内存才出现明显增长.

此处再留几个问题:

1. 我们都知道imageWithName:方法加载的图片, 会被系统缓存, 那么第一次通过该方法进行如上两个对照组的实验, 结果如何呢?
2. 通过imageWithName:方法第2、3..n次加载同名图片时, 加载的图片数据流会不会再次被解码? 期间CPU占用有没有增加?
3. 尝试把创建的UIImage对象桥接赋值给CALayer的contents属性, 结果如何?

2.2.2 浅谈CALayer的隐式动画及事务

从上一节中, 我们发现当给UIImageView的image属性或CALayer的contents属性赋值Image对象后的某一刻, 内存和CPU占用才会出现明显变化. 那是因为每一次Runloop循环, Core Animation都会在其开始创建一个动画事务, 在本次Runloop结束时才去执行所有添加到该事务里的所有动画操作. 此刻图片才被解码加载入内存, 图片数据会被解码为渲染可用的bitmap数据. 一些相关细节可看我另一篇分享.

浅谈CALayer隐式动画及事务

2.3 解决内存激增问题

当前我们面临的问题是无论采用何种实现方案, 在执行序列帧动画时, 所有图片都会被解码成为位图并载入内存中.

2.3.1 解压后的图片所占内存大小

图片解码后的格式为位图形式. 位图是由一组像素(pixel)组成的, 每一个像素就代表图片中的一个点. 比如常见的JPEG, 以及PNG格式的图片文件都是位图图片.

我们还需要知道, JPEG和PNG图片实际上都是一种编码/压缩后的位图格式, 它们是不能直接用来图片渲染的, 所以得先对其压缩的数据进行解码/解压缩操作.

那么一张解压后的位图其所占内存大小怎么计算呢?

此处假设我们有一张32位的PNG格式图片, 其像素格式为RGBA四部分组成, 每部分占8位, 该图片尺寸为160px * 320px.

1
2
3
4

32位的图片意味着其每个像素占32位, 即4个字节.
又根据图片尺寸计算出总像素数量为 160*320 个像素.
所以该图片解码后所占内存大小就为 像素总数 * 单位像素的字节数
即 (160*320) * 4 / 1024 = 200 KB.

所以可想而知, 假设一个序列帧动画有80张图片, 200 * 80 / 1024 = 15.625 mb, 就会占用15mb的内存. 序列帧图片越多, 占用内存越大!

2.3.2 解决方案

那么有什么方法可以避免呢? 可否每次播放到哪一帧时就去加载那一帧的图片, 即每次仅加载一张图片到内存中. 这样当播放到下一张图片时, 上一张图片已无任何引用, 系统自然会对其进行释放.

这就是最简单可行的一套方案. 但是我们无法靠CAAnimation及其派生类CAKeyframeAnimation来实现这一方案, 因为所有的图片都会解码导致占用大量的内存.

但我们可以通过CADisplayLink来实现该方案, 选CADisplayLink的原因是它比NSTimer精度要高很多, 正常情况下CADisplayLink的回调会在屏幕每次刷新时触发, 即一般1/60秒触发一次, 适合用于做UI的重绘, 因此可以通过它来周期性的替换关键帧图片, 从而达到播放动画的效果. 那么具体怎么做呢?

在CADisplayLink的回调中获取两次屏幕刷新的间隔时间, 通过不断的累加间隔时间来判断总的时间是否已经满足下一帧的播放时刻, 如果大于下一帧的播放时刻就可以替换为下一帧图片了, 直至最后一张关键帧也播放完成.

举个例子, 我们要在1秒内播放完一个含有5张关键帧图片的动画, 每张图片的停留时间、切换时间如下图2.3.2.a所示. 所以第0秒的时候就开始展示第一张关键帧, 直到1.0秒这一刻时, 动画播放结束.

此外, 如果还需要进一步优化, 我们可以加入图片异步解码、图片预加载逻辑等方案.

• 异步图片解码, 图片解码是一项比较耗时、比较占CPU的操作, 对于未解码的图片, 系统一般会在主线程对其进行解码, 所以可以通过在异步线程进行图片强制解压缩, 从而不占用UI线程. 关于图片解码的详情, 强烈推荐谈谈 iOS 中图片的解压缩.

• 图片预加载, 这个就是为了进一步节省上下文切换时间, 即前后两张图片切换的时间. 就是要做到当上一帧图片播放完时, 我们不用等下一张图片解码完成后再进行图片的切换, 而是可以直接从已解码图片的缓存队列中取出直接进行切换. 预加载我个人觉得其实主要就是阈值的最优选择, 可参考预加载与智能预加载一文.

• 字节对齐(byte alignment)对Core Animation性能的影响

三、序列帧动画引擎源代码及Demo

FXAnimationEngine - Github跳转

针对该Demo近期会另起一文特别介绍, 此处占坑, 等待跳转链接

四、礼物资源下载策略及资源目录结构

4.1 礼物资源下载策略

4.1.1 两种方式比较

4.1.2 资源更新流程

因对上家公司的代码保密, 此处不上具体代码

我们在上一小节中提及的两种更新方式, 它们主要的不同的就在于”资源更新”这一步骤

图 4.1.2.a 整包更新的流程图

图 4.1.2.b 增量更新的流程图

不知道各位发现两个流程共同之处没? 它们都需要检测资源版本号大小, 包括游戏补丁、热更补丁这一步骤都必不可少. 相比于补丁类的, 资源更新不用太考虑灰度发布、回滚机制等问题, 但还是依旧需要注意资源核对, 内部测试, 以及日志监控等保障, 我记得在前任公司就遇到了有的地区下载下来的资源包有问题, 所以不管是CDN的问题或资源本身有问题, 前端都需要为最坏的情况做好打算, 这才是万全之策.

引用我上家公司, 我老大兼mentor, 达文哥, 告诫的一句箴言

不要相信后台下发的数据都是正确的

大概意思如此, 原句没背下来😂, 这句话绝非不是指后台同学不行, 或者甩锅给后台, 而是要prepare for the worst.

前后端测试都是一家人, 遇到问题我们先看看是不是自己问题, 不要相互甩锅..本是同根生相煎何太急, 如果有问题就一块搓一顿, 一顿不行就再来一顿

4.2 资源目录结构设计

不管哪个直播平台, 每个礼物都会对应一个逻辑id, 我们可以通过礼物的id作为该礼物的资源目录名, 然后在该目录内在去划分不同类型的图片子目录, 如下所示

1
2
3
4

- 10000 // 一级目录, 礼物id
  -- gift// 二级目录, 小礼物序列帧图片
  -- giftlist    // 二级目录, 礼物列表序列帧图片 
  -- giftanim    // 二级目录, 大动画序列帧图片

这只是其中的一种设计, 也有的平台会采用如下形式, 所以主要还是看需求而定

1
2
3
4
5
6

- gift
  -- 10000
- giftlist
  -- 10000
- giftanim
  -- 10000

此外, 有的平台还会采用id_version, 即礼物id+礼物版本的形式来命名, 这样可以方便配置使后台可以灵活下发给前端具体要去播放哪个动画的某个版本了

1
2

- 10000_11  // id为10000, 版本为11的礼物资源目录
- 10000_12

本文是为了后续直播App送礼大动画实战演练做铺垫, 浅谈CALayer的隐式动画及事务.

全文主要涉及以下问题:

• CALayer图层的定义
• 何为隐式动画?
• 所有CALayer都有隐私动画吗? UIView的backing layer呢?
• 哪些对象遵循CAAction协议
• 动画事务是什么?

二、 CALayer

CALayer图层, 是数据模型, 数据对象. 对于iOS平台, 一个UIView视图在展示之前, 系统都会为其创建一个支持图层(backing layer), 其中就储存了View外貌样式的表现内容, 比如图层通过contents属性来管理bitmap位图, 从而充当位图的容器.

Backing layer的delegate(CALayerDelegate)就是该图层所属的view对象.

三、 隐式动画

我们平常都肯定使用过显式动画, 但我们比较少见到的隐式动画(implicit animation)又是什么.

从Core Animation Guide官方指南中, 并没有找到隐式动画的明确定义, 仅提及了以下相关内容:

1. 直接更改图层CALayer的属性就会触发隐式动画, 但是修改UIView对象支持图层(backing layer)的动画属性是不会发生隐式动画的, 因为UIView默认禁止了backing layer的隐式动画, 所以对backing layer属性的修改在UIView上的反应是直接变化, 没有平滑过度的动画效果
2. 隐式动画会使用当前动画事务的参数默认值来执行动画
3. 隐式动画会直接更改了layer模型中的值, 而显式动画不会(在动画执行完后, 会根据layer模型的属性进行”还原”, 所以我们在添加动画后需要手动修改layer的属性来确保动画完成时, 图层能够”还原”到动画结束时的位置! 只有presentationLayer中的值会随着动画执行不断改变.)
4. 隐式动画执行过程中无法直接被移除, 而显式动画可以通过实例方法removeAnimationForKey:或removeAllAnimations来直接移除
5. Core Animation通过 遵循CAAction协议的对象 来实现隐式动画

此处来一发示例, 帮助我们理解一下上方第1点:

1
2
3
4
5
6
7
8
9
10

/*
 现有UIView对象 viewA, 以及一个CALayer对象 layerB, 我们把 layerB 添加到 
 viewA 的 layer(这个就叫backing layer) 上.
*/

// 对backing layer进行属性修改, 不会发生隐式动画, 而是由之前的颜色直接变成红色
viewA.layer.backgroundColor = [UIColor redColor].CGColor;

// layerB作为viewA.layer的子图层, 会发生隐式动画, layerB的颜色会由原先的颜色平滑过渡到蓝色
layerB.backgroundColor = [UIColor blueColor].CGColor;

至此, 想必我们已经清楚CALayer何时会发生隐式动画了, 但后半句中说UIView的backing layer不会有隐式动画又是何解?

这里需要关联第5点中提到的遵循CAAction协议的对象

实际上, CAAnimation及其派生类, 如CABasicAnimation、CASpringAnimation, 以及CATransition都遵循并实现了 CAAction 协议中的方法. 当CALayer的动画属性改变时就会去查找匹配的CAAniamtion对象来执行动画. 其查找流程用代码形式表示如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

/*
1. 若返回遵循 CAAction 协议对象, 则用其执行动画(runActionForKey:object:arguments:)
2. 若该方法返回nil, 不执行隐式动画, 直接更新属性
*/
- (id<CAAction>)searchActionForLayer:(CALayer *)layer forKey:(NSString *)key {
    id<CAAction> action = nil;
    // 先问代理该key对应的Action, 如果返回不为nil, 则已找到; 如果返回nil, 则继续执行查找逻辑; 如果返回NSNull对象则停止剩余查找逻辑, 最终返回NSNull
    if ([layer.delegate respondsToSelector:@selector(actionForLayer:forKey:)]) {
        id<CAAction> action = [layer.delegate actionForLayer:layer forKey:key];
        if ([NSNull null] == action) {
            return nil;
        }
        else if (action) {
        return action;
        }
    }
    if (!action) {
        action = [self actionForKey:key in:layer.actions];
    }
    if (!action) {
        for (NSDictionary<NSString*, id<CAAction>> *actions in layer.style) {
            if ((action = [self actionForKey:key in:actions])) {
                break;
            }
        }
    }
    if (!action) {
        action = [[layer class] defaultActionForKey:key];
    }
    return action;
}

- (id<CAAction>)actionForKey:(NSString *)key in:(NSDictionary<NSString*, id<CAAction>> *)actions {
    for (NSString *actionKey in actions.allKeys) {
        if ([actionKey isEqualToString:key]) {
            return actions[actionKey];
        }
    }
    return nil;
}

UIView作为backing layer的delegate(as CALayerDelegate), 实现了-actionForLayer:forKey方法; 当不处于动画block范围内时, 该方法返回nil; 否则, 返回对应的动画对象. 关联上方函数注释若该方法返回nil, 不执行隐式动画, 直接更新属性, 这就是为什么UIView的backing layer不会有隐式动画.

四、 动画事务

动画事务, 也类似于数据库事务, 用于组合某个逻辑里边的一系列操作. Core Animation会自动为我们某个图层的单个或多个显式动画、隐式动画创建隐式事务. 当然, 我们也可以通过 CATransaction 的类方法, 来显式创建事务.

1
2
3
4
5
6
7
8
9
10

// 显式事务
[CATransaction begin];
[CATransaction setValue:@(0.3) forKey:kCATransactionAnimationDuration];
layer.opacity = 0.0;
[CATransaction commit];

// UIView提供用来做动画的类方法等价于上方显式创建动画, 因为这些类方法内部就调用了CATransaction的+begin, +commit方法
[UIView animateWithDuration:0.3 animations:^{
    layer.opacity = 0.0;
}];

当runloop开始一次新的循环时, Core Animation就会开启一个事务, 在本次循环中的所有动画操作, 包括我们显示创建的事务都会被嵌套其中, 直至本次runloop循环结束之时, 再一块提交进行动画. 比如下方代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// layerA、layerB、layerC均为寄宿/单独图层(hosted layer/standalone layer)

// --- runloop 新的循环开始 ---
[CATransaction begin]; // Core Animation 开始的新事务

// -- 本次循环中, 我们涉及的动画操作 start -- 

// 修改单独图层属性, 将以最外层CATransaction的动画参数发起隐式动画, 动画时间为当前所在事务的动画时间, 即默认的0.25秒
layerA.backgroundColor = [UIColor redColor].CGColor; 

// 创建显式事务, 嵌套事务
[CATransaction begin];
[CATransaction setValue:@(1) forKey:kCATransactionAnimationDuration];
// 当前事务中的隐式动画, 执行时间为1秒
layerB.position = CGPoint(110, 119);
[CATransaction commit];

// 实际也相当于嵌套事务
[UIView animateWithDuration:0.5 animations:^{
    layerC.opacity = 0.0;
}];

// -- 本次循环中, 我们涉及的动画操作 end -- 

[CATransaction commit]; // Core Animation 提交所有事务
// --- runloop 循环结束 ---

利用事务, 禁止动画发生:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[CATransaction begin];
// 设置 kCATransactionDisableActions 为 false
[CATransaction setValue:@(false)
                 forKey:kCATransactionDisableActions];

// UIView Animation显示动画失效
[UIView animateWithDuration:0.33
                 animations:^{
                 // 单独的图层layerA
                    layerA.backgroundColor = [UIColor redColor].CGColor;
                 }];

// 单独的图层layerB, 隐式动画失效
layerB.opacity = 0.0;

[CATransaction commit];

五、推荐资料

本文提及内容仅为Core Animation的冰山一角, 如果想深入了解iOS动画, 可以尝试阅读一下下方资料, 定会有一番收获!

Core Animation Guide
iOS Core Animation
CATransaction In Depth

去年, 2016年, 一大波直播平台在移动端涌出, 直播慢慢步入了人们的视角. 网上如今能够看到各式各样的直播, 如秀场直播、游戏直播、体育直播、娱乐直播等等.

在各种类型的直播中, 弹幕在PC、移动端都几乎成为了标配, 今天在这里主要介绍一下个人开源的iOS弹幕, 以及提前为实现一款弹幕库涉及的相关技术分享的相关篇章占坑, 虽不细至于手把手教如何实现, 但关键点都会有所涉及且不仅限于实现弹幕, 如iOS中用pthread实现生产者消费者模型、响应正在执行动画对象的点击事件、实现某类对象复用的ReuseQueue、使用GCD封装实现可取消未执行代码块的OperationQueue等等, 对这些更感兴趣的朋友麻烦直接滑至最后一段.

欢迎各位大神指点一二.

广告

统计了各渠道的一周浏览记录, 以及github浏览次数、评论留言数, 感觉弹幕估计是有点过时了..感兴趣的朋友比较少, 所以弹幕相关技术分享打算暂时一缓. 准备开源并分享一下可能更多人感兴趣的序列帧动画引擎, Demo会通过分别Core Animation以及个人FXAnimationEngine来实现花椒礼物动画的效果(资源花椒ipa中提取), 比较内存占用, 动画被系统打断情况下的表现, 图片解码相关知识等. 此外, 还会分享一下礼物资源热更的方案.

Github

Talk is cheap, I’ll show you the code.

请大力点击上方超链接⬆️⬆️⬆️⬆️⬆️

特性

1. 除了UI操作, 其他操作都以代码块交给异步队列处理了.(使用GCD提交的代码块, 最终会由XNU kernel根据CPU使用情况创建新的线程去执行或分配给其他线程执行)
2. 遵循 生产者消费者模式, 通过pthread去阻塞队列而非使用timer或异步队列开启runloop空转
3. 定义了包含 弹幕块点击、将出现、已消失事件的delegate
4. 提供 注册复用 自定义弹幕块 的方法
5. 各种自定义参数, 如弹幕块移速, 弹幕库插入方向(从上, 从下, 随机), 弹幕库移动方向(左到右, 右到左), 重置弹道位移百分比系数(防前后弹幕块碰撞)、弹幕队列容量控制
6. 简单易用, 控制方法就三个 start(同时也是恢复), pause, stop. 另外大部分方法都是线程安全的
7. 轻易适配设备方向旋转
8. 设置单行配置即可作为 跑马灯、直播间公告 使用

预览图

示例

弹幕设置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// Configuration
FXDanmakuConfiguration *config = [FXDanmakuConfiguration defaultConfiguration];
config.rowHeight = [DemoDanmakuItem itemHeight];
config.dataQueueCapacity = 500;
config.itemMinVelocity = 80;  // set random velocity between 80 and 120 pt/s
config.itemMaxVelocity = 120;
self.danmaku.configuration = config;

// Delegate
self.danmaku.delegate = self;

// Reuse
[self.danmaku registerNib:[UINib nibWithNibName:NSStringFromClass([DemoDanmakuItem class]) bundle:nil]
   forItemReuseIdentifier:[DemoDanmakuItem reuseIdentifier]];
[self.danmaku registerClass:[DemoBulletinItem class] 
     forItemReuseIdentifier:[DemoBulletinItem reuseIdentifier]];

数据添加

1
2
3
4
5
6
7
8

// add data for danmaku view to present
DemoDanmakuItemData *data = [DemoDanmakuItemData data];
[self.danmaku addData:data];

// start running
if (!self.danmaku.isRunning) {
    [self.danmaku start];
}

代理事件

1
2
3
4
5
6
7
8
9
10
11

- (void)danmaku:(FXDanmaku *)danmaku didClickItem:(FXDanmakuItem *)item withData:(DemoDanmakuItemData *)data {
    // 此处 处理点击
}

- (void)danmaku:(FXDanmaku *)danmaku willDisplayItem:(FXDanmakuItem *)item withData:(FXDanmakuItemData *)data {
    // 此处 处理弹幕块将要出现/展示
}

- (void)danmaku:(FXDanmaku *)danmaku didEndDisplayingItem:(FXDanmakuItem *)item withData:(FXDanmakuItemData *)data {
    // 此处 处理弹幕块完全离开视线，结束展示
}

更多详情 麻烦参照 Gitbub Demo project FXDanmakuDemo.xcworkspace.

有关弹幕库使用问题答疑

1. rowHeight、estimatedRowSpace and rowSpace 三者之间的关系

2. 如何使用nib创建自定义弹幕块

3. 如何适配设备屏幕旋转

如果你的弹幕View 在横竖屏状态下 高度不一样, 比如竖屏高200pt, 横屏约束却是100pt, 那么需要在对应的controller.m文件中加入以下代码(否则 当你的弹幕块使用AutoLayout进行布局时, 横竖屏切换后, 由于视图的frame会变化多次，导致正在展示的弹幕块 出现布局约束冲突的报错)

iOS8+

1
2
3
4
5
6
7
8
9
10

- (void)viewWillTransitionToSize:(CGSize)size withTransitionCoordinator:(id<UIViewControllerTransitionCoordinator>)coordinator {
    [self.danmaku pause];
    [self.danmaku cleanScreen];
    
    [coordinator animateAlongsideTransition:nil
                             completion:^(id<UIViewControllerTransitionCoordinatorContext>  _Nonnull context) {
                                     // resume danmaku after orientation did change
                                     [self.danmaku start];
                                 }];
}

系统版本小于iOS8

1
2
3
4
5
6
7
8

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration {
    [self.danmaku pause];
    [self.danmaku cleanScreen];
}

- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation {
    [self.danmaku start];
}

安装

Cocoapods(iOS7+)

1. Podfile中 视情况对应添加以下内容

   1 2 3 4

   platform :ios, 'xxx' target 'xxx' do pod 'FXDanmaku' end

2. pod install

Manually(iOS7+)

直接拖动 FXDanmaku 文件夹 到你的项目 对应结构下

介绍结尾

欢迎各位 提出宝贵的issues, 更多功能建议, 或者改进之处等等. 同时若各位想要了解弹幕库具体实现的其他相关点, 也可在评论区留言.

首先放上两个类似ReactiveCocoa中定义weakify和strongify的宏, 以便下文用到

#define WeakObj(o) autoreleasepool{} __weak typeof(o) weak##o = o
#define StrongObj(o) autoreleasepool{} __strong typeof(o) o = weak##o

一、weak的作用(代码+注解 简单跳过)

防止被block捕获(会导致引用计数加1), 打破循环引用(retain cycle)

1
2
3
4
5
6
7
8
9
10
11

// DeallocMonitor继承NSObject, 仅重写其dealloc方法, 并在其中打印其被释放日志
DeallocMonitor *object1 = [DeallocMonitor new];
DeallocMonitor *object2 = [DeallocMonitor new];
@WeakObj(object2);//__weak typeof(object2) weakobject2 = object2;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_global_queue(0, 0), ^{
    // object1被block捕获, 引用计数加1, 外部作用域结束时仍未被释放, 直至该Block执行完毕才被释放
    NSLog(@"5s已到, %@该被释放勒", object1);
    // weakobject2被weak 修饰, 其指向的object2对象的引用计数不会增加, 当外部作用域结束时就已被释放
    NSLog(@"5s已到, %@早已被释放, 此处为null", weakobject2);
});
// 外部作用域结束

二、为何要加strong, 其何时才起作用？

加strong的原因想必大家都知道是为了防止block执行过程中 __weak typeof(object) weakObject指向的对象突然被释放了, 这就会导致block中的代码运行结果出现意想不到的结果(比如一些代码执行有效, 其余代码执行无效; 弱引用的对象因为为nil而导致的crash等.)

2.1 即使加了strong, 也不能保证weakObject指向的对象不会被释放

只能确保在block执行期间, weakObject指向的对象有效(不会被释放)

下面这段代码就是在block中用strong申明的对象强引用一次weakObject, 但修饰对象在block执行前就已经被释放的栗子

1
2
3
4
5
6
7
8
9
10
11
12
13

// DeallocMonitor继承NSObject, 仅重写其dealloc方法, 并在其中打印其被释放日志
DeallocMonitor *object = [DeallocMonitor new];
@WeakObj(object);// weakobject
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_global_queue(0, 0), ^{
    // 该strongObj的申明仅在block执行时才见效, 而外部作用域一结束object就已经被释放了, 所以然并卵
    @StrongObj(object);
    /* weakobject用 weak修饰, 故其引用计数不变, 
上边的宏本意是申明一个新的object局域变量对weakobject指向的原object进行强引用..
按理 原object引用计数应该会加1, 可是它还没等到被强引用时就已经挂掉了
*/
    NSLog(@"5s已到, %@然后早已被释放, 此处为null", object);
});
// 外部作用域结束

2.2 Block内部申明的强引用指针变量指向weakObject仅在block执行时才有效

定义该Block的时strongObj宏还尚未使原对象引用计数加1! 那么strongObj宏生效时的表现是什么样子的呢? 继续上代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 该段代码主要是打了一个时间差, 以模拟strong申明起作用的情形

// DeallocMonitor继承NSObject, 仅重写其dealloc方法, 并在其中打印其被释放日志
DeallocMonitor *object = [DeallocMonitor new];
// 保证外部作用域结束的2.5秒(无限接近..)内object不会被释放
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2.5 * NSEC_PER_SEC)), dispatch_get_global_queue(0, 0), ^{
    NSLog(@"果断强引用object: %@\n 还能再多坚持2.5s", object);
});
@WeakObj(object);// weakobject
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_global_queue(0, 0), ^{
    @StrongObj(object);// __strong typeof(object) object = weakobject
    sleep(3);// 卡个3s
    // 此处就不会像上一段代码那样, 强引用一个为nil的object, 故weakobject指向的对象引用计数加1, 直到该block运行完, 才会被释放
    NSLog(@"5s已到, %@打印完这个日志就飞升了", object);
});
// 外部作用域结束

2.3 有多少个嵌套block就应该申明多少对weak-strong

假定我们在最外层block使用的一对weak-strong, 且外层block内还有一个block(没有用weak-strong)引用到了strongObj宏申明的局域变量object, 并假设原对象在外层block开始运行前一直存活, 这就会导致内层block捕获到局域变量object并使其指向对象的引用计数加1, 因为内层block捕获到了外层block中申明的object(强引用), 就跟外层block会捕获到外部强引用变量指向的对象一样一样的

1
2
3
4
5
6
7
8
9
10
11
12

DeallocMonitor *object = [DeallocMonitor new];
@WeakObj(object);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_global_queue(0, 0), ^{
    @StrongObj(object);// 因为block运行时, weakObject指向对象依旧存在, 故该强引用使其引用计数加1
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_global_queue(0, 0), ^{
        // 这一层block 发现上边的object是强引用, 导致捕获到其指向对象, 使其引用计数在该内层block尚未执行时就加1了
        NSLog(@"打印完这个日志, %@才被释放", object);
    });
    NSLog(@"%@外层block结束, 引用计数减一", object);
});
sleep(3);
// 外部作用域所在线程小歇一会, 确保object存活3s, 作用域结束

所以嵌套block时 万万要小心, 不要漏写了. 另外weak-strong要成对出现, 不然少一个strong, 都有可能为此付出代价

2.4 遗漏补缺

1. 在block中对外部weakObject进行强引用(strong修饰)的结果是使weakObject指向的原对象的引用计数加1, 因为weakObject指针指向的是原对象在堆中的存储地址
2. block 不会对弱引用指针变量指向的对象进行捕获

2.5 block的相关知识, 个人推荐书籍章节

• Effective-ObjectiveC(Item 37: Understand Blocks)
• Pro Multithreading and Memory Management for iOS and OS X(Blocks Implementation)

三、题外篇(内存泄露检测工具-妈妈再也不用担心内存泄露)

对于ReactiveCocoa以及各种嵌套Block的常用玩家..想必仅靠Xcode的Instrument去检测memory leak问题是绝对不够的, 个人卖瓜推荐一个检测内存泄露的小工具类:
FXDeallocMonitor
拷贝FXDeallocMonitor.h、FXDeallocMonitor.m文件到项目中, 根据头文件中的方法调用就行, 简单易用😄

对于需求更高者, 推荐近期facebook开源的FBAllocationTracker

http://www.cnblogs.com/fu4904/