为iOS应用程序打造反光工厂– Vincent Pradeilles –中

非常感谢 BenoîtCaron 引起了我的注意，并提出了我将在下面描述的技术的相当一部分。

iOS应用程序是复杂的软件。 如今，不太可能运行到聚合了一百多个视图控制器的应用程序中。 当您考虑到其中的某些可能只能通过特定的业务场景访问的事实时，通常会遇到这样的情况：在屏幕上显示特定的控制器非常困难。

这种情况可能会威胁到应用程序的质量，尤其是在要求开发人员检查每个屏幕（例如，确保它们在iPhone X上能正常工作）的时候。

一个非常方便的工具是调试视图，从中可以实例化任何控制器并将其显示在屏幕上。 那么我们如何实现这样的工具呢？

一个好的起点

第一步是弄清楚如何实例化任意控制器。 幸运的是，这将成为简单的部分，因为该功能已经通过Foundation的public func NSClassFromString(_ aClassName: String) -> Swift.AnyClass? 基本上，再加上一些代码，开发人员可以从其类的名称实例化一个对象。

所以现在我们只需要在我们的应用程序中列出所有视图控制器。 如果没有其他选择，我们可以将它们手动存储在.plist文件中，但是这种方法的缺点是每次创建，删除或重命名类时都需要手动更新，这很繁琐且极易出错。

利用Objective-C运行时

您可能没有意识到这一点，但是每个iOS应用程序都在轻量级运行时环境上运行。 关于此运行时，可以说很多话，如果您想详细了解它，请随时查看Apple提供的文档。

就本文而言，我将解释限于以下事实：iOS应用程序启动时，其所有与Objective-C兼容的类都在运行时加载，并且只要应用程序处于活动状态，它们就会一直存储在该位置。使此运行时成为从中检索所有视图控制器列表的绝佳来源。

我们如何在实践中实现这一目标？ 首先，我们从导入与运行时交互的API开始：

处理更高级的用例

我们所取得的成就非常好，但是在大多数情况下，使其真正有用仍然很简单。 当您考虑它时，我们能够实例化视图控制器，但是我们无法为它提供任何类型的初始数据。

在一个现实世界的项目中，这个问题很可能会导致交易中断，因为许多视图控制器可能依赖于先前屏幕传递的一些初始数据。

那么我们如何改善呢？ 首先，我们需要一种让控制器提供其用例列表并处理其中一个用例的方法。 为此，我们声明一个协议：

结论

自反编程是一个功能强大的工具，使用它的这个特定实例也不例外：只需几行代码，我们就可以组建一个易于包含在现有应用程序中的工厂，并允许其开发人员实例化任何从一个好的调试视图中查看控制器。

当确保旧版应用程序在iPhone X上流畅运行时，无疑会令人欢迎的工具是这样的工具，但是当您想要对该应用程序的一部分进行非回归测试时，它也很方便。令人讨厌的复杂。

如果您想在项目中使用以上代码，请随时在我的GitHub上使用。