使用Core Animation完成自定义animation – 性能
文章
https://www.objc.io/issues/12-animations/animating-custom-layer-properties/
对于使用Core Animation完成自定义animation有这个说法：
假设我们不是使用单独的图层来实现我们的钟面，而是使用Core Graphics绘制时钟。 （一般情况下 ，这将会有较差的性能 ，但是可以想象，我们可能想要实现的复杂绘图操作难以使用普通图层属性和变换进行复制。）我们将如何实现这一点？
换句话说，我们使用CG手动绘制CA的每一帧，因为我们的animation太复杂，只能使用内置的CALayerfunction。
问题是关于劣质的performance 。
- 由于CG在CPU上运行，这是否会阻塞主线程？
- 这可能是使用SpriteKit而不是CA的原因（因为SpriteKit在GPU上运行，不会阻塞主线程）？
- 是。 对你的第一个问题。 使用Core Graphics（Quartz或CG）进行绘图会受到CPU的限制，并且会大大减慢应用程序的各个方面。如果准备，绘图，合成和演示文稿占用了帧时间，则您的应用程序将明显停止并减慢其帧速率完成绘图。 即使这less于每秒1帧。
输出一个大的PDF时你会看到这个。 核心graphics忙于渲染所有其他活动，偏重于所有其他因素的输出质量。 部分原因是因为它的起源是PostScript，以打印输出为目标，质量是主要目标，也是因为它始终是一个以质量为中心的图像创作框架，而不是animation。
- SpriteKit和CA比SpriteKit / CA和CG更加细致
了解这些框架的不同优先级，function和性能特征揭示了如何最好地将它们一起使用，以及何时以独占性来select它们。
在CA和CG的情况下，命名约定expression的依赖性和互操作性不一定是真实的，必要的，或者存在的，但是它们可以有效地结合起来，而且非常好。 这只是一个平衡的行为，因为他们做了一些非常不同的事情。
CG =核心graphics
CA =核心animation
核心animation就是它所说的：擅长animation的东西。 但它也有惊人的创意内容创作工具。 可能会让你感到惊讶的事情，因为它不是一个多说的框架。 它的许多关键function都被使用它们的UIKit包装所遮盖。
你所链接的文章完全避免了讨论Core Animation的内容创build工具，这些工具还没有完成，而且相当不错。 特别是对于animation框架。 您可以使用Core Animation完成所有必需的组件和完美的时钟animation，而无需使用任何较慢的Core Graphics绘图。 我不知道为什么这篇文章没有说明这些function。
在Core Animation内容创build层上，这里有两个：
CAShapeLayer可以制作和制作任何形状或形状组合的graphics。 CATextLayer完全支持NSAttributedString及其所有属性，并为它们设置animation。
可以将核心animation想像成Flash和QuickTime的灵感，封闭的源代码，特定于平台的API，用于从头开始创build高性能animation和视觉交互性。
-
作为绘图和内容创build框架，CALayers不具备Core Graphics的所有function。 但是它们在SpriteKit的使用方式上还远远不够。
-
作为一个animation和交互框架，Core Sprite比Sprite Kit更好，并且（在许多方面）更具性能的graphics，animation和基于事件的游戏引擎，没有SpriteKit中包含的一些更具体的附加组件。
CALayers不只是简单的事情。 他们能够绘制内容，并掩盖它。 然后以各种奇妙的方式高度生动，包括一个伪3D旋转空间，完成透视变形。
核心animation缺失，但在SpriteKit是：
- 声音：在SK中有两种不同的播放方式，没有一种是在没有滚动的情况下进行的
- 游戏循环：虽然SK优化事件，但它也有一个周围的游戏循环
- 物理学：你需要使用UIKit Dynamics与核心animation层来获得物理学
- 图像包装：需要做你自己的文件处理的纹理，并将其拆包
- 视觉场景编辑器：可以说没有太大的损失。 从devise师的angular度来说
- 视觉粒子编辑器：这是更多的损失。 如果没有一个，就难以做出好的效果
- SKActions：但CA具有隐式/显式animation和/或CAKeyFrameAnimation
夺取使用SpriteKit的底线：
- UIKit和它的美妙的布局能力，当你想要他们玩不好
- 特殊的错误，因为它给了最小的（看似）资源和错误testing
- 非常小的用户群提供了一个小池，其中大部分问题和答案都是微不足道的
- 几乎没有支持从苹果提起，他们的论坛是悲伤的荒原
- 这些文件是糟糕的，大多是过时的和/或没有意义的
- 游戏引擎中无数的例子和示范都是常见的
- 了解工作stream程，范例和stream程是通过渗透学习的
- 场景编辑器速度慢，devise不好，营养不良，在Xcode中效果不佳
- 没有NSAttributedString支持标签和其他文本演示需求
一些历史性的问题，我将删除一次添加第二部分的答案：
核心graphics历史快速回顾，有一个相关的转折…
苹果公司的PostScript主要负责桌面出版业务，苹果公司在devise和创意计算机市场的新兴市场取得成功。 这些市场让苹果一直处于活跃状态，而IBM /英特尔/微软则抨击成本和兼容性意识的“生产力”和企业市场。 数字创意公司现在对蒂姆•库克（Tim Cook）的苹果公司为挤奶iPhone摇钱树而感到沮丧和愤怒，但却没有承认，尊重，关心甚至与现代桌面创意能力保持同步。
select框架时要考虑一些其他的运球：
拥有消费者和创意计算历史上最大的现金储备，他们也没有创造创造性的工具创新。 这感觉（而且看起来）很像是对苹果核心价值/传统的背叛，以及那些致力于学习和使用以苹果为中心的创意工具在精简的十年中的精力和热情。 “酷”的创意帮助苹果变得“酷炫”，提供了通向iPhone和iPad的iPod的期待和采用是不可置信的。
由于在iPhone上轻松无瑕的现金抢占焦点，品牌的一些光泽绝对下降。 这是令人担忧的一个简单的原因，这些types的决定因素：SpriteKit的吸收已经很小。 苹果公司可能会决定削减其已经是精益的开发团队，以赚取更大的利润，因为看起来利润在新苹果公司的所有其他动机中占据优势。 与iPhone的利润增长相比，在框架和软件开发资源方面的创新成本相差无几。
苹果公司没有任何理解需求的迹象，也不希望积极和热情地投资于尽可能好的或稳定的新框架。 validation，并因此吸引开发人员到新的框架需要透明的努力，苹果似乎不愿意做。 对于学习，采用和使用新框架所需要的时间和精力，苹果似乎不屑一顾。 并且完全假定他们的期望，开发者将冒险采用苹果公司的技术，可以closures利润寻求心血来潮。
Sprite Kit和Scene Kit正在遭受漫长的酝酿期，以及之前版本中的几个bug。 加上开发人员交stream非常差，以及对编码者信心和采用程度的增长缺乏明显的关注，这导致了真正的贫困采用率。
如果没有被广泛采用，苹果可能会决定放弃SpriteKit，而不是像现在这样一发不可收拾。
可以这么说，cocos2D-X的持续成功是苹果公司未能将SpriteKit完全做成和应该成为的直接结果。 完全没有及时和体贴地支持，沟通，pipe理和更新问题，已经产生了避免使用SpriteKit的强烈愿望，以及在开发人员中的许多开发人员的不确定性和不安。
由于他们对发展人才的预算几乎是无限的，这种事情应该成为苹果公司尴尬和批评的来源，激起对其他“举措”的严密审查，并且用“创新”来实施。 由于我不明白的原因，批判性地思考苹果做什么和不做什么，以及这些select的影响和影响，并不是一件好事。
我认为公平的说他们雇用的内部软件开发人员和软件产品的质量远远不能满足iOS平台在硬件销售，应用程序商店收入，覆盖范围和市场影响力方面的增长。 这将很快产生比Sprite Kit的瘦用户基础更为明显的后果，并且几乎不存在使用SceneKit。