博客重整与进度(10-26更新)

如题,由于博客已经写了3年,早期的文章由于当时的技术积累和能力原因,存在或多或少的问题和局限,虽然很早之前就想过要重整博客,但迟迟没有开始。现在立下这个flag要开始重整文章了,所以新文章更新会被搁浅,这次的flag能持续多久也不清楚,不过已经有不少旧文章有重写的思路了。初步计划逐渐将文章进行归类,暂目前定下了五大块内容: 多线程。主要是线程安全、多线程使用以及GCD的源码分析(源码这个鸽了好久) 分析实现。分析系统的机制、某些代码设计,然后写demo实践 质量监控。主要是APM的设计实现 runtime。看源码与吹逼 动画开发。这个也是鸽的厉害 开发日记。其实就是common,懒得进行细分分类 重整的时候会尽可能的保证文章质量以及写作效率,另外还要注意...
Click to read more ...

记一次重构

技术重构 重构是软件开发过程中不断对软件代码进行打散重组,提高代码稳定性和可读性的处理手段之一。对【技术重构】进行关键信息提炼可以得到思维导图: 本文以微视最近一次音乐播放功能的重构为例回顾重构过程 重构步骤 业务梳理 微视4.8版本增加了音乐榜单功能,在更早之前的版本拥有音乐播放的界面只有音乐聚合页,相较于音乐聚合页同时只有一首歌曲需要控制播放,音乐榜单页存在切歌、榜单切换的场景,逻辑处置起来要棘手的多。另外由于音乐播放应该是一个通用能力,在重构前控制器需要维护AVPlayer的各种状态,代码格式如下: - (void)observeValueForKeyPath: (NSString *)keyPath ofObject: ...
Click to read more ...

质量监控-图片减包

经过多个版本迭代,项目在release配置下的打包体积依旧轻松破百,应用体积过大导致的问题包括: 更长的构建时间,换个词就是加班 TEXT段体积过大会导致审核失败 用户不愿意下载应用 通常来说,资源文件能在应用体积包中占据1/3或者更多的体积,相比起代码(5kb/千行)的平均占用来说,对图片进行减包是最直接高效的手段,对图片资源的处理方式包括四种: 通过请求下载大图 使用工具压缩图片 查找删除重复图片 查找复用相似图片 考虑到由于项目开发分工的问题,方式1需要推动落地,所以本文不讨论这种处理方式。其他三种都能通过编写脚本实现自动化处理 图片压缩 图片压缩分为有损压缩和无损压缩两类,有损压缩放弃了一部分图片的质量换取更高的压缩比。网上主流的压...
Click to read more ...

分析实现-离散请求

网络层作为App架构中至关重要的中间件之一,承担着业务封装和核心层网络请求交互的职责。讨论请求中间件实现方案的意义在于中间件要如何设计以便减少对业务对接的影响;明晰请求流程中的职责以便写出更合理的代码等。因此在讲如何去设计请求中间件时,主要考虑三个问题: 业务以什么方式发起请求 请求数据如何交付业务层 如何实现通用的请求接口 以什么方式发起请求 根据暴露给业务层请求API的不同,可以分为集约式请求和离散型请求两类。集约式请求对外只提供一个类用于接收包括请求地址、请求参数在内的数据信息,以及回调处理(通常使用block)。而离散型请求对外提供通用的扩展接口完成请求 集约式请求 考虑到AFNetworking基本成为了iOS的请求标准,以传统的集约式请求代码为例: ...
Click to read more ...

开发笔记-警惕swizzling

不知道什么时候开始,只要使用了swizzling都能被解读成是AOP开发,开发者张口嘴就是runtime,将其高高捧起,称之为黑魔法;以项目中各种method_swizzling为荣,却不知道这种做法破坏了代码的整体性,使关键逻辑支离破碎。本文基于iOS界的毒瘤一文,从另外的角度谈谈为什么我们应当警惕 调用顺序性 调用顺序性是链接文章讲述的的核心问题,它会破坏方法的原有执行顺序,导致意料之外的错误。先从一段简单的代码聊起: @interface SLTestObject: NSObject @end @implementation SLTestObject - (instancetype)init { self = [super init]; return s...
Click to read more ...

分析实现-谈谈响应链

当用户的手指在屏幕上的某一点按下时,屏幕接收到点击信号将点击位置转换成具体坐标,然后本次点击被包装成一个点击事件UIEvent。最终会存在某个视图响应本次事件进行处理,而为UIEvent查找响应视图的过程被称为响应链查找,在整个过程中有两个至关重要的类:UIResponder和UIView 响应者 响应者是可以处理事件的具体对象,一个响应者应当是UIResponder或其子类的实例对象。从设计上来看,UIResponder主要提供了三类接口: 向上查询响应者的接口,体现在nextResponder这个唯一的接口 用户操作的处理接口,包括touch、press和remote三类事件的处理 是否具备处理action的能力,以及为其找到target的能力 总体来说UIR...
Click to read more ...

多线程-线程安全(二)

之前写过一篇线程安全,简单介绍了保护数据安全的多种方式,以及其中一部分方式的原理。基于此基础,本文将介绍如何避免锁的性能浪费,以及如何实现无锁安全结构 避免锁的性能浪费 为了避免多个线程对数据的破坏,在使用锁保障线程安全的情况下,存在几个影响锁性能的重要因素: 上下文切换 临界区资源耗时 如果能够减少这些因素的损耗,就能有效的提高锁的性能 自旋锁 通常来说,当一个线程获取锁失败后,会被添加到一个等待队列的末尾,然后休眠。直到锁被释放后,依次唤醒访问临界资源。休眠时会发生线程的上下文切换,当前线程的寄存器信息会被保存到磁盘上,考虑到这些情况,能做的有两点: 换一个更快的磁盘 改用自旋锁 自旋锁采用死循环等待锁释放来替代线程的休眠和唤醒,避免了上下文切换...
Click to read more ...