读源码系列（swift2048）-view篇
前言
笔者是swift自学新手，希望借助阅读别人开源项目提升自己swift水平。文中将尽量使用文字描述来代替代码的堆砌，建议读者多参考源码，以便更好理解项目。文中难免有错误之处，欢迎各路大牛留言指正。
项目信息
swift-2048 github地址
项目主界面
该项目可以说一个带有实验学习性质的项目，其中部分功能没有实现或不完整。但2048游戏的基本功能均完整实现。笔者将分3篇文章，分别按controller、model、view的进行介绍。
本篇是最后一篇，将重点展开介绍view部分。
以往文章：
第1篇-controller篇
第2篇-model篇
正文
本文将从以下2点展开说明：
- 文件结构概括
- 游戏盘view
1.文件结构概括
笔者喜欢先从文件结构看起。该项目的view部分，有下面4个文件组成：
views/AccessoryViews.swift //辅助的views.里面含显示得分ScoreView和用来控制作用的ControlView（未实现也未使用）
views/GameboardView.swift //游戏盘view
views/TileView.swift //棋子view
AppearanceProvider.swift //外观的提供者,按规则显示提供颜色和字体大小
2.游戏盘view（GameboardView）
GameboardView代表游戏盘，TileView代表棋子。
游戏盘和棋子
GameboardView源码中
class GameboardView : UIView {
...
var tiles: Dictionary<NSIndexPath, TileView>
...
}
源码可见，GameboardView是以Dictionary结构来存储TileView。Dictionary中的key，是NSIndexPath，实际运用中将位置坐标x y（或raw col）转成NSIndexPath，例如：
tiles[NSIndexPath(forRow: row, inSection: col)] = tile //设置位置坐标为（row，col）上的TileView
各位移步看TileView的内部：
class TileView : UIView {
...
let numberLabel : UILabel//显示数字的label
var value : Int = 0 {
didSet {
backgroundColor = delegate.tileColor(value)//棋子的背景
numberLabel.textColor = delegate.numberColor(value)//数字的颜色
numberLabel.text = "\(value)"//值
}
}
unowned let delegate : AppearanceProviderProtocol //显示信息委托
...
}
TileView不复杂，UIView中是一个UILabel。然后数字和棋子背景因value不同而不同。显示的规则来自AppearanceProviderProtocol。
protocol AppearanceProviderProtocol: class {
func tileColor(value: Int) -> UIColor //根据值,返回棋子的背景颜色
func numberColor(value: Int) -> UIColor//根据值,返回棋子的数字颜色
func fontForNumbers() -> UIFont //返回数字使用的字体
}
该协议的的实现，按典型的switch-case的结构，有多少情况，只要预先设定好，即可：
class AppearanceProvider: AppearanceProviderProtocol {
func tileColor(value: Int) -> UIColor {
switch value {
case 2:
return UIColor(red: 238.0/255.0, green: 228.0/255.0, blue: 218.0/255.0, alpha: 1.0)
case 4:
return UIColor(red: 237.0/255.0, green: 224.0/255.0, blue: 200.0/255.0, alpha: 1.0)
...
}
}
...
}
那开发者为何使用AppearanceProviderProtocol呢？笔者猜想，这样可以将显示属性（颜色、字体）相关的逻辑从TileView的逻辑中独立出来，便于统一修改和调试。
读过上一篇model篇的读者，会发现这里的GameboardView-TileView与model中的SquareGameboard-TileObject比较相似，但是2者还是有本质上的差别：
- 相同点：2者都在各自领域（view和model）中，表示游戏盘和棋子
- 不同点：在model中，SquareGameboard组织TileObject的方式是数组。
struct SquareGameboard<T> {
...
var boardArray : [T]//实际使用过程中，泛型使用TileObject代替
...
}
在view中,GameboardView组织TileView的方式是Dictionary
class GameboardView : UIView {
...
var tiles: Dictionary<NSIndexPath, TileView>
...
}
为何是这样？笔者认为是model和view关注点不同
- model关注整个游戏的逻辑，即游戏盘中的每一个有效的位置都要被管理起来。TileObject不仅代表有数字的棋子，也代表空棋子。所以，游戏盘中所有棋子（位置）是连续的，可以用数组表示。
- view关注显示，即只关心游戏盘中有数字的棋子（移动、插入等）。TileView只表示有数字的格子，不表示空棋子（空位置）。在游戏过程中，有数字的棋子数量小于游戏盘中棋子位置的总数量，而且棋子与棋子之间没有连续的关系。故而使用数组就不适合了，而采用Dictionary，并用位置坐标（NSIndexPath）做key就比较合理。
查看GameboardView的代码，你会发现GameboardView没有配套的委托协议。
没有委托协议意味着：只存在viewController主动调用（通知）GameboardView，反过来GameboardView不需要通知viewController。进一步讲，GameboardView只负责显示，不负责与用户交互。（看过前面文章的读者应该会记得，该项目的用户交互是由滑动手势发起的）
笔者统计，GameboardView被controller调用的方法是以下4个：
b.reset()
b.moveOneTile(from, to: to, value: value)
b.moveTwoTiles(from, to: to, value: value)
b.insertTile(location, value: value)
除了reset之外，其他3个方法，基本和model的协议是一样的。因为controller就只负责以简单方式通知view（代码上，就是直接调用view的方法）。以移动一个棋子的委托方法为例（model委托的分析，请参见model部分的文章）
func moveOneTile(from: (Int, Int), to: (Int, Int), value: Int) {//controller实现的model的委托
assert(board != nil)//board就是GameboardView
let b = board!
b.moveOneTile(from, to: to, value: value)// 直接调用view的方法
}
下面是moveOneTile方法：
func moveOneTile(from: (Int, Int), to: (Int, Int), value: Int) {
...(略，检查参数代码)
let (fromRow, fromCol) = from
let (toRow, toCol) = to
let fromKey = NSIndexPath(forRow: fromRow, inSection: fromCol)
let toKey = NSIndexPath(forRow: toRow, inSection: toCol)
//上面是得到棋子view的key
guard let tile = tiles[fromKey] else {
assert(false, "placeholder error")
}//得到旧位置的棋子(旧位置上一定会有棋子）
let endTile = tiles[toKey]//得到新位置的棋子，可能不存在（单棋子移动分成移动和合并2种情况。只有合并情况才有新位置上的棋子。具体见model篇）
var finalFrame = tile.frame
finalFrame.origin.x = tilePadding + CGFloat(toCol)*(tileWidth + tilePadding)
finalFrame.origin.y = tilePadding + CGFloat(toRow)*(tileWidth + tilePadding)
//旧位置的frame，计算成新位置的frame
tiles.removeValueForKey(fromKey)
tiles[toKey] = tile
//然后在字典中更新，删除旧的，在放进新的
...（略，移动动画和pop动画，有兴趣可查阅源码）
}
用文字说明流程：
1》参数是坐标，转成NSIndexPath，在字典中找到棋子view
2》tiles字典更新，将原来位置的棋子从字典原来位置删除，覆盖到新位置
3》原来位置的棋子view，计算新位置的frame，使用动画移动到新位置。新位子原来的view删除。如果是合并（新位置原来有格子），需要pop动画
另外2个方法也是差不多的套路：
moveTwoTiles 移动2个格子,过程与前面基本一致：
1》参数是坐标，转成NSIndexPath，找到棋子view（2个原来位置的棋子）
2》tiles字典更新：将一个原始棋子view从字典原来位置删除，覆盖到新位置。另外一个原始位置的棋子view从字典中删除
3》计算新位置棋子的frame。然后2个原来位置的棋子，动画移动到新的位置，然后删除一个，只保留一个。并显示pop动画
insertTile 新增格子
1》参数是坐标，转成NSIndexPath。
2》计算frame，创建新的TileView。加入游戏盘view，然后插入字典中
3》动画显示。
总结
笔者经过分析model时的逻辑洗礼，再分析view部分时，头脑就清晰多了。
处理model的委托时，基本就是2步：1》修改保存棋子view的字典。2》移动棋子view
(该项目的view部分还有一些处理逻辑文中没有提到（例如游戏盘背景的显示、棋子动画，得分view等），有兴趣的读者可自行查看源码了解。
