Core Animation 实现探索

小编回顾粗略的写完 19 年 想要写的系列博文中 iOS UI 优化总纲中第一篇博文 Core Animation 一直在想怎么样展示自己的理解，就先从我们熟知的 Core Animation 在整个 APP 提供架构方面来进行O对比。

注：上图分别是从 2014 年的 WWDC 讲述 Advanced Graphics and Animations for iOS Apps 中截取 和 2018 年最新描述 About Core Animation 文档获取Core Animation 在架构中实现。

由上面显示具体信息我们可以得出下面结论：

1、Core Animation 作为主要内容载体承接对 iOS 和 OS 具体显示的绘制；
2、UIKit 框架从初始化到通过 GPU 生成纹理显示在屏幕上是依靠 Core Animation、 Core Graphics、 OpenGL ES(iOS 11) 和 Matel(iOS 12) 来实现;
3、在 iOS 8.0 中苹果官方尝试使用 Metal 来替代 OpenGL ES 在目前最新的官方文档中实现在绘制生成纹理底层架构依据 Metal 进行。

想要深入了解一个架构我们就从最基本的系统 API 着手，下面是小编对系统 API 根据分类来对具体类的 API 进行整理。

iOS UI 优化博文大纲

2019 年开年第一篇博文，今天先起个头。

今年第一个主题是关于 UI 界面实现原理，UI 目前实现主要方式在其实现上相关缺陷。开始从 Core Animation 框架总结以及实现方式上讲解，然后从 Core Graphics 和 Core Iamge 在绘制层面三者如何把 UIKit 控件如何实现绘制交由 OpenGL ES | Metal 来实现每一帧绘制。

最后分析 FB 开源的框架 ASDK 和 YYKit 实现 UI 优化方式，对 Core Text 进行最后封装来结束 UI 专题。

iOS UI 架构图

Core Animation 大纲

iOS 11 的最新技术发布在 6月6号，由于小编在工作上的原因只能在今天把 iOS 11的相关信息整理出来对后面的开发便利以及在实际开发过程中可以更好的避免踩过的坑。

新增的框架

对于上一个版本总体来说新增加两个主要大的框架 Core ML 和 ARKit

Core ML 框架

只从去年的时候 AlphaGo 打败李世石，今年的升级版的 AlphaGo 也战胜中国的柯洁，到最近前端时间升级版的 AlphaZero 也战胜了前代的 AlphaGo。感觉后面 AI 只能是最近最火的科技，而且目前也可以看出来后面科技更新替代可能是对依据重复性训练获取技能重复单样工作的人员优化（这是后话）。

不过 Core ML 是 Apple 提供的已经训练好的模型，也就是说是根据数据进行相关训练好可以直接使用的一个数据匣子。小编讲的直白一点，就是你往匣子中输入数据然后获取相应的结果数据。

Core ML 背后是对 iOS 的视觉识别 Vision 框架和 Foundation 中语义相关分析的 API。一般移动端的开发者可以使用相关的接口来获取相关人脸识别或者是文字的识别结果。

之所以在关注到 WCDB 是因为在新的一家公司重构数据库来解决胶水代码问题，换而言之在使用 SQLite 数据中尽量减少 SQL 中增、删、改和查语句的使用。

WCDB 是腾讯微信开源在 2017/06/09 号开源的一种变种数据库，本质也是基于 SQLite 。

WCDB 简介

WCDB 本质上对 SQLite 数据库 OC++ 的组件，采用的方式是：
（1）使用 ORM 映射来完成自定义数据表和相关的索引，这里就解决公司胶水代码问题
（2）使用 WING 来解决 SQL 查询过程中经常使用查询过程中字符串的拼装问题
（3）多线程实现读取数据时的并发操作，在修改或者插入数据时执行串行操作
（4）在数据库发生顺怀时实现修复功能
（5）可以实现在执行 SQL 消耗的时间，可以帮助性能的监控
（6）采用防注入的 SQL 语句，避免恶意输入损坏数据。

下面简单的介绍上面在 WCDB 具体实现

ORM 实现原理

于数据库表和索引采用的

前篇博文小编写了基本的 SQLite 操作方式，如果只是对数据库采取基本的操作看完小编第一篇博文就可以。后面小编将会讲述一些数据的相对来说比较复杂的操作方式。

本篇将会列出下面的数据库相关知识：

• 多表查询
• 运算符
• 表达式

多表查询

接着上篇文章小编把数据库中查询使用的多表查询给大家做讲解。

在多表查询过程中需要用到的关键词是: join，而且在多表连接查询过程中有三种情况。

分别是：交叉连接、内连接和外连接。

一下操作均以 Employee 和 Programmer 两个表格为基础来实现使用用例。

内容是乱取的，上次取名可能气到在意的人，后面名字均是乱取！！！

交叉连接(CROSS JION)

（1）交叉连接特点：

在实现交叉连接过程中数据库中每一行和每一行会做对比，生成一张查找出来内容很大的数据。例如：如果一个表格有 a 行，另一个表格有 b 行，生成的表格大小为 a * b 行内容。

几天得闲，上周一想把数据库相关知识整理一份当做在看到数据库后续，但是一直都在看公司的项目重构工作。今天终于把相关的技术问题解决，打算重新整理一份新知识点。

数据库

小编在这里提出一个问题：为什么要使用数据库？

在系统编译或者运行期间同时使用内存或者相关变量储存在堆中可以实现相关数据保存。但是在占用的内存或者是堆中的相关内容在程序 KILL 之后，相关的数据也会被系统回收。我们为了保存相关的数据实现永久性的储存的，就是考虑磁盘的储存能力。这时文件储存和数据库储存就会是我们选择的对象。

小编这里就以 SQLite 来讲解相关数据基本原理和操作。

SQLite

Sqlite 学习总结

SQLite 的安装

一般在 MAC 上面系统会自带 Sqlite 的数据库版本的。

查看本地的数据库版本号呢，可以在终端输入执行下面的语句（以 mac 为例）：

sqlite3

小编的 MAC 上输出的内容是：

1
2
3
4
5
6
7

SQLite version 3.16.0 2016-11-04 19:09:39 //可以看到 SQLite 的版本信息和安装时间

Enter ".help" for usage hints.

Connected to a transient in-memory database.

Use ".open FILENAME" to reopen on a persistent database.

SQLite 语法基本操作

目前对于 LLDemo 方面的架构思考，是针对于个人理解以及自己在以往项目经验来给出的个人的建议，可能会有不合适的地方望多多包涵。

出发角度：

• 项目整体创建 FloDer 结构
• 在模块开发过程中选择开发方式
• 基础类和公有类提取
• 具体模块开发中架构设计
• 相关类在开发中应该准守的规则

项目整体创建 Floder 架构
下面创建的文件目录以 LLDemo 为例

LLDemo

• resource（资源文件）
  • builtin （内置资源）
  • images （图片资源，assets）
• lib （第三方库的代码引入）
• base utils （项目中基础库，开发过程中基本保持不变）
  • layout constant （布局常量判断）
  • basic informations（一些基础配置信息）
• utils （依据基础库来封装使用与多个模块公共接口，经常变动）
  • interface of module （模块中接口）
  • heigh api （基于基础库开发瞒住模块高级方法）
• custom view（项目中多个模块使用自定义 View）
• extensions (可以直接执行 App 的功能)
• module （按模 块划分，在具体模块开发需要根据开发选型：MVC，MVP 或者 MVVM）
  • home （首页）
  • setting （设置）
  • vip page （VIP Page）
  • editor （编辑模块）

之所以这样创建 FFloder 文件原因：
（1）瞒住在开发过程中明确每一个 floder 的职能；
（2）在新模块添加过程中更好管理相关资源；
（3）提取相关基类以及抽象方法，方便复用在查找和维护过程中减少成本；
（4）Floder 职能明确在后续新队员接手学习成本低。

在模块开发过程中选择开发方式
在模块开发过程中选定相关开发方式其实目前做常用的是 MVC，MVVM 两者

目前项目开发基本是基于 MVC 开发来进行构架模块下面在 module 中 Home 为例解释：

• Home
  • model（数据模型）
  • view controller（视图控制器）
  • view（控件）
    • custom view（Home 中独有 view）
    • global view（对 Home 中 view 拆分）

上面在模块构建过程中可以通过对 View 拆分，然后减少 View 在 VC 初始化，把数据处理搬移到 Model，也可以减少 VC 肥大。但是当 VC 功能逐渐增多，趋向于平台入口 VC 肥大很难避免。

可以在新的简单模块逐渐引入 MVVM 开发模式，这样既可以熟悉 MVVM 开发模式，同时在新添加模块中逐渐向 MVVM 转变在不妨碍工作进度情况下也为后续 VM 的单独测试以及 LLDemo 功能多样化防止 VC 肥大做准备。（在后续估计也需要做统一大家一起使用，不能凭个人爱好）

这里给出在 github 上面模式介绍
参考地址：https://github.com/Optimize-iOS/app-architecture

基础类和公有类提取
感觉不用详说好处多多

具体模块开发中架构设计
因为目前 LLDemo 整个 APP 功能最详细，而且最全是在图片编辑类。
可以对改编辑类的框架搭建，减少不必要的 View 的创建和保存取消操作重复实现。

目前大概思路是：
（1）对共用的 View 的进行提取在 EditVC 实现，然后对渲染，展示这些 View 提供接口在编辑子类可以添加独有的 View；
（2）对在每一个编辑子类中保存，取消，展示原图这些方法在 EditVC 实现，给每一个子编辑调用。

不过存在一定的风险，就是在每个子编辑需要重新按照原来的逻辑实现功能，修改起来难度较大，测试周期长。好的一点就是后续添加方便修改内容少，实现更加便捷。也可以给大家一个思路，后续模块搭建过程中更好设计架构。

承接上一篇博文小编讲述在镜头采集过程所需知识点和 AVCaptureSession 基本使用方法，本篇博文将要讲述 AVCaptureDevice 相关使用方法。

下图为本博文写作思路：