前言

在本文中，我们将深入探讨一些创建 SwiftUI 动画的高级技术。我将广泛讨论 Animatable 协议，它可靠的伙伴 animatableData，强大但经常被忽略的 GeometryEffect 以及完全被忽视但全能的 AnimatableModifier 协议。

这些都是被官方文档完全忽略的主题，在SwiftUI 的帖子和文章中也几乎没有提及。不过，它们还是为我们提供了创建一些相当不错的动画的工具。

在我们进入这些隐藏的瑰宝之前，我想对一些基本的 SwiftUI 动画概念做一个非常快速的总结。只是为了让我们能有共同语言，请耐心听我说。

前言

我们社区陆续会将顾毅（Netflix 增长黑客，《iOS 面试之道》作者，ACE 职业健身教练。微博:@故胤道长）的 Swift 算法题题解整理为文字版以方便大家学习与阅读。

LeetCode 算法到目前我们已经更新了 29 期，我们会保持更新时间和进度（周一、周三、周五早上 9:00 发布），每期的内容不多，我们希望大家可以在上班路上阅读，长久积累会有很大提升。

不积跬步，无以至千里；不积小流，无以成江海，Swift社区 伴你前行。如果大家有建议和意见欢迎在文末留言，我们会尽力满足大家的需求。

难度水平：简单

前言

我们社区陆续会将顾毅（Netflix 增长黑客，《iOS 面试之道》作者，ACE 职业健身教练。微博:@故胤道长）的 Swift 算法题题解整理为文字版以方便大家学习与阅读。

LeetCode 算法到目前我们已经更新了 27 期，我们会保持更新时间和进度（周一、周三、周五早上 9:00 发布），每期的内容不多，我们希望大家可以在上班路上阅读，长久积累会有很大提升。

不积跬步，无以至千里；不积小流，无以成江海，Swift社区 伴你前行。如果大家有建议和意见欢迎在文末留言，我们会尽力满足大家的需求。

难度水平：简单

前言

我们社区陆续会将顾毅（Netflix 增长黑客，《iOS 面试之道》作者，ACE 职业健身教练。微博:@故胤道长）的 Swift 算法题题解整理为文字版以方便大家学习与阅读。

LeetCode 算法到目前我们已经更新了 26 期，我们会保持更新时间和进度（周一、周三、周五早上 9:00 发布），每期的内容不多，我们希望大家可以在上班路上阅读，长久积累会有很大提升。

不积跬步，无以至千里；不积小流，无以成江海，Swift社区 伴你前行。如果大家有建议和意见欢迎在文末留言，我们会尽力满足大家的需求。

难度水平：简单

前言

我们社区陆续会将顾毅（Netflix 增长黑客，《iOS 面试之道》作者，ACE 职业健身教练。微博:@故胤道长）的 Swift 算法题题解整理为文字版以方便大家学习与阅读。

LeetCode 算法到目前我们已经更新了 25 期，我们会保持更新时间和进度（周一、周三、周五早上 9:00 发布），每期的内容不多，我们希望大家可以在上班路上阅读，长久积累会有很大提升。

不积跬步，无以至千里；不积小流，无以成江海，Swift社区 伴你前行。如果大家有建议和意见欢迎在文末留言，我们会尽力满足大家的需求。

难度水平：简单

前言

我们社区陆续会将顾毅（Netflix 增长黑客，《iOS 面试之道》作者，ACE 职业健身教练。微博:@故胤道长）的 Swift 算法题题解整理为文字版以方便大家学习与阅读。

LeetCode 算法到目前我们已经更新了 24 期，我们会保持更新时间和进度（周一、周三、周五早上 9:00 发布），每期的内容不多，我们希望大家可以在上班路上阅读，长久积累会有很大提升。

不积跬步，无以至千里；不积小流，无以成江海，Swift社区 伴你前行。如果大家有建议和意见欢迎在文末留言，我们会尽力满足大家的需求。

难度水平：困难

前言

我们社区陆续会将顾毅（Netflix 增长黑客，《iOS 面试之道》作者，ACE 职业健身教练。微博:@故胤道长）的 Swift 算法题题解整理为文字版以方便大家学习与阅读。

LeetCode 算法到目前我们已经更新了 23 期，我们会保持更新时间和进度（周一、周三、周五早上 9:00 发布），每期的内容不多，我们希望大家可以在上班路上阅读，长久积累会有很大提升。

不积跬步，无以至千里；不积小流，无以成江海，Swift社区 伴你前行。如果大家有建议和意见欢迎在文末留言，我们会尽力满足大家的需求。

难度水平：中等

在面向对象的编程中，抽象类型提供了一个基础实现，其他类型可以从中继承，以获得某种共享的、共同的功能。抽象类型与普通类型的区别在于，它们永远不会被当作原样使用（事实上，一些编程语言甚至阻止抽象类型被直接实例化），因为它们的唯一目的是作为一组相关类型的共同父类。

例如，假设我们想统一我们通过网络加载某些类型的模型的方式，通过提供一个共享的API，我们将能够用来分离关注点，使依赖注入和模拟变得容易，并在我们的项目中保持方法名称的一致性。

Swift的总体目标是既强大到可以用于底层系统编程，又足够容易让初学者学习，这有时会导致相当有趣的情况——当Swift的类型系统的力量要求我们部署相当高级的技术来解决乍一看可能更微不足道的问题。

大多数Swift开发人员会在某一时刻或另一时刻（通常是马上，而不是日后）会遇到这样一种情况，即需要某种形式的类型擦除才能引用通用协议。从本周开始，让我们看一下是什么使类型擦除在Swift中成为必不可少的技术，然后继续探索实现它的不同 “风味(Flavors)”，以及每种风味为何各有优缺点。

在之前的文章中，我们看了一些使用依赖注入的不同方法，以实现Swift应用中更多的解耦和可测试架构。例如， “在Swift中使用工厂的依赖注入”中把依赖注入和工厂模式结合起来，以及“在Swift中避免使用单例” 中利用依赖注入取代单利。

到目前为止，我的大部分文章和例子都使用了基于初始化器的依赖注入。然而，就像大多数编程技术一样，依赖注入有多种“风味(Flavors)”，每一种都有自己的优点和缺点。本周，让我们来看看三种不同方式的依赖注入，以及它们如何在Swift中使用。