第一个练手作品:Matrix Code Rain
及对Core Graphics绘制的优化

前情提要

书接上文,上回书说到我意识到自己在专业领域有欠缺,于是正在大量阅读Blog。在9月25号看到Kevin Chou的这篇介绍他开源的组件库PNChart受到欢迎的文章时,我突然想到:对啊,这是个把自己喜好与技术积累结合起来的好途径!之前总觉得往开源社区贡献代码需要超强的底层代码功力,又不想仿写已有的组件重复造轮子,这时我才刚刚意识到,上层的UI层面同样需要优秀的贡献——某种程度上讲更加稀缺,毕竟同时对设计和代码都有研究的程序员比较少。

恰好,一个做前端的朋友Fanta发来了一份他业余时间用HTML+JS写着玩做的《黑客帝国》代码雨效果的demo:

我觉得这个还挺有意思,搜了一下GitHub上还没有做过的,于是便开始了编码工作。

架构及轨迹生成

这是一个很简单的小组件,所以基本架构也很简单:

我们约定将每一条下落的轨迹都称为一个Track,由一个Generator实例专门来生成,每隔指定的时间(显然,随机亦可)就新生成一条,加到DataSource中,并创建其对应的CALayer子类CodeRainLayer加到最底层的UIView上。

下落及轨迹清理

如何产生动画呢?最开始自然想到用CAAnimation来做。
因为代码太简单,就不在这里写了。
但是写完个大概之后,运行起来却发现不对劲:总感觉没有电影里面酷。

问题出在哪里呢?我又从移动硬盘里翻出了那三部曲仔细地研究了一下,经过一帧一帧地探究,我找到了原因:
电影里面的代码并不是在“下落”,如果你盯着一个字母看,会发现它根本就没移动过位置(除去镜头本身的移动)。换句话说,整个空间是一个已经排列好的字母矩阵,而我们看到的表象是一阵脉冲流过而已。

所以最后改成的方案是由每个Track实例自带的Timer负责驱动控制自身的下落(为表述方便我们依然沿用这个词),当需要刷新时,通知其对应的CodeRainLayer实例(-setNeedsDisplay)进行重绘。至于如何重绘,由每个CodeRainLayer自行负责。

而当整条轨迹掉出屏幕的时候,Track会检测出边界条件,然后把对应的CALayer执行removeFromSuperlayer,最后把自身从DataSource中清除。

阶段性成果

OK, so far so good. 我们成功实现了整个的动画效果,看起来也确实蛮酷的:

封装

在把它传到GitHub之前,还需要进行一些封装。这里主要有两方面的工作,一个是增加控制关键字来限制外界能接触到的内部类和方法,另一个是将可调节的参数向外界暴露出来。

Access Control

在Swift 3中特地新加了fileprivate这个访问权限,正好在这里可以用到。我们把不希望暴露给外界的类都加上这个限定关键字。

顺便,Swift 3中的访问权限依次是:

open,public,internal,fileprivate,private.

Configurable Parameters

在之前,组件中用到的所有参数都定义在了一个struct里:

fileprivate struct JSMatrixConstants {
static let maxGlowLength: Int = 3 // Characters
static let minTrackLength: Int = 8 // Characters
static let maxTrackLength: Int = 40 // Characters
static let charactersSpacing: CGFloat = 0.0 // pixel
static let characterChangeRate = 0.9
static let firstDropShowTime = 2.0 // Time between the First drop and the later

// Configurable
static let speed: TimeInterval = 0.15 // Seconds that new character pop up
static let newTrackComingLap: TimeInterval = 0.4
static let tracksSpacing: Int = 5
}

为了暴露其中的一些参数,我们在CodeRainView那里增加几个变量:

var trackSpacing: Int
var newTrackComingLap: CGFloat
var speed: CGFloat

那么如果用户不设置的时候呢?我们应该用回默认值。比如这样:

var speed: CGFloat = CGFloat(JSMatrixConstants.speed){
didSet{
datasource.speed = TimeInterval(speed)
}
}
var newTrackComingLap: CGFloat = CGFloat(JSMatrixConstants.newTrackComingLap){
didSet{
datasource.newTrackComingLap = TimeInterval(newTrackComingLap)
}
}
var trackSpacing: Int = JSMatrixConstants.tracksSpacing{
didSet{
datasource.trackSpacing = trackSpacing
}
}

而一个2016年的UI组件应当是Interface Builder-Friendly的——尤其是,要做到这点只需举手之劳:将上面的参数声明为@IBInspectable

最后在IB中看到的效果是:

优化性能

在我的iPhone6s上测试时,整个组件的表现没什么大问题;但在比较老的iPhone5s上测试时,就有点吃力了。虽然画面依然比较流畅,在CPU监测中能明显看出占用:

而在我后面想结合一些CoreMotion的回调实现视角缩放效果时,在5s上的画面终于卡了起来。

之所以会卡很容易理解,整个组件在主线程中进行了大量的绘制工作,搁你你也卡。

在我搜索相关信息的时候,偶然看到一篇叫《一些提高UI绘制性能的技巧》的文章中写道:

绘制UIView最快的方法就是把它当成imageview,我们把需要用Core Graphic绘制的代码放到另一个线程中去绘制,生成image后直接赋值给view,达到异步绘制的目的。

我试了一下,差不多是这样:

let track = self.track
DispatchQueue.global().async {
let size = self.bounds.size
UIGraphicsBeginImageContext(size)
context.saveGState()

... // Calculate positions, etc.

context.restoreGState()
self.render(in: context)
let resultImage = UIGraphicsGetImageFromCurrentImageContext();
DispatchQueue.main.async {
if let image = resultImage{
self.contents = image.cgImage
}
}
UIGraphicsEndImageContext()
}

但这样做有问题:在每一次更新的时候,这个Layer需要在空白的背景下进行绘制,而直接调用self.render(in: context)方法,绘制的内容会叠加在当前显示的内容之上,出来的效果是不可用的。(截图过于残暴,从略)

那么怎么解决这个问题呢?一个直接的想法是,如果能在一个新的context上绘制就好了。

带着这个目标去搜索,在这个文章里面介绍了创建context的方法,于是上面的代码变成了:

let track = self.track
DispatchQueue.global().async {
let size = self.bounds.size
UIGraphicsBeginImageContext(size)

/* Create drawing context */
let colorSpace = CGColorSpaceCreateDeviceRGB()
let createdContext = CGContext(data: nil, width: Int(size.width), height: Int(size.height), bitsPerComponent: 8, bytesPerRow: 0, space: colorSpace, bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue)

if let context = createdContext{
context.saveGState()

... // calc positions, etc.

context.restoreGState()
self.render(in: context)
let resultImage = UIGraphicsGetImageFromCurrentImageContext();
DispatchQueue.main.async {
if let image = resultImage{
self.contents = image.cgImage
}
}
}
UIGraphicsEndImageContext()
}

优化结果

搞定了这些之后兴冲冲地在5s上跑了一下,发现除了线程多了一些之外,差别几乎不可见:

细想一下也可以理解,我们并没有减少任何绘制的工作量,只不过是把它们移到了后台线程而已。

那么接下来的问题是,在为主线程减了这么多负之后,程序的响应性能有提高吗?因为要是再没什么变化的话,我要为前面这些花出的时间哭几秒。

接下来我搜到了一篇讲述如何测量程序响应性的文章,还附了源码的截图,非常良心。

fileprivate class PingThread: Thread{
var pingTaskIsRunning = false
var semaphore = DispatchSemaphore(value: 0)
override func main(){
while !self.isCancelled{
pingTaskIsRunning = true
DispatchQueue.main.async {
self.pingTaskIsRunning = false
self.semaphore.signal()
}
Thread.sleep(forTimeInterval: 1/30.0)
if pingTaskIsRunning {
NSLog("Delayed!")
}
_ = semaphore.wait(timeout: DispatchTime.distantFuture)
}
}
}

核心思想是,每隔一定的时间就在主线程给该线程的信号量发消息,要是主线程因为卡顿耽搁了,该线程就会输出警告信息。

我把时间设为1/30秒,因为这是一个流畅的动画所应当达到的帧率。

这下终于有了喜人的对比结果:

之前:

之后:

直到启动20多秒后收到内存警告,都没有一次卡顿出现!

虽然我不是一个使用meme表情控,但看国外的blog看多了之后,总觉得在这种情况下需要出现一个表情……

就是下面这个:

最后的话

整个项目已经传到了GitHub上:
https://github.com/zshowing/JSMatrixCodeRainView

通过这个项目,我学到的东西包括:

  • Core Graphic的一些深入内容
  • 一些之前用不到的封装策略
  • 一个优化绘制性能的方法
  • 一个测量程序响应性能的方法

接下来又想到一个比较有趣的项目,不知道什么时候能填坑。

感谢观赏。