在头脑风暴会议上，有人建议我们在未来的项目中使用静态库。我整天都在研究这个话题。
我找到了一些关于静态库是什么以及如何创建静态库的有用答案。
Library? Static? Dynamic? Or Framework? Project inside another project
我还找到了关于如何使用库的资源的答案：
我真的需要创建一个静态库，还是应该只为内部使用代码创建一个类？
我应该在什么情况下创建静态库？
答案 0 :(得分：8)
即使您不想与其他开发人员共享您的代码，您仍然可以通过创建静态库获得巨大的好处。
正如Srikar Appal所述，创建静态库所获得的好处是 1）代码分发， 2）代码重用，我也是喜欢添加， 3）版本控制， 4）可测试性（感谢BergQuester以下评论）和 5）文档
让我们更仔细地看看这些：
静态库非常棒，因为它们可以轻松分发代码 - 您只需要编译并共享生成的.a文件。
即使您从未计划与其他开发人员共享代码，您仍然可以在 自己的 项目中使用此代码。
或者，您可以将静态库的项目作为子项目包含在各个主项目中，使其成为主项目的依赖项...请参阅https://github.com/jverkoey/iOS-Framework如何设置。
即使在非常不同的应用中，您也经常会发现您正在执行您之前为其编写代码的相同任务。如果您是一位高效的开发人员，那么您不会想再次编写相同的代码......相反，您只想包含以前编写的优质代码。
你可能会说，But I can just include the classes directly。
但是，如果您的代码不一定是polished怎么办？或者随着时间的推移，它使用的框架会随着时间的推移而发生变化？
当您对代码集进行更改和错误修复时，能够轻松地在项目中包含最新版本（或者稍后可以轻松更新项目）会很好。静态库使这更容易，因为所有相关代码都包含在单个包中。
也不用担心其他开发人员对其施加的其他项目特定的黑客攻击 - 主要项目不能（或者作为子项目包含静态库的情况下，不应该）更改静态库的代码集。
这有一个额外的好处，如果有人 需要更改静态库的代码集，他必须进行更改，以便所有依赖它的项目仍然可以使用它（没有项目特定的快捷方式）。
如果您有一组移动并将项目包含在项目中的类，那么很难跟上版本控制。最有可能的是，你所拥有的唯一版本是主项目的版本。
如果一个项目修复了一些错误而另一个项目修复了这个类集中的其他错误怎么办？您可能不知道合并这些更改（如果两个团队甚至分开工作会怎样）？或者，每个项目可能都在修复相同的错误！
通过创建静态库，您可以跟踪版本控制（静态库的项目有自己的版本号），通过对静态库进行更改，您可以减少合并问题，消除了反复修复相同错误的风险。
随着iOS作为一个平台的不断成熟，对代码进行单元测试变得越来越普遍。 Apple甚至继续构建和扩展测试框架（XCTest），使其更容易和更快让iOS开发人员编写单元测试。
虽然可能（以及，IMHO，应）在应用程序级别为您的代码编写单元测试，但使用静态库创建和封装代码通常会使这些测试< em>更好和更容易维护。
测试是更好，因为精心设计的静态库封装了有目的的功能（即设计良好的库执行特定的任务，例如网络任务），这使得＃更容易34;单元＆＃34;测试代码。
也就是说，一个设计良好的静态库开始实现预定义的目的＆＃34;，基本上，它自然地创建测试边界（即网络和呈现所获取的数据可能至少有两个独立的库。）
测试更易于维护因为它们与静态库代码位于同一个存储库（例如Git repo）中（因此，与此代码一起进行版本化和更新）。就像你不想将代码从一个项目复制并粘贴到项目中一样，你也同样不想复制和粘贴测试。
与单元测试一样，在线文档在iOS中继续变得更加重要。
当可以（并且再次，恕我直言，应该）在应用程序级别的文档代码时，它再次更好并且更容易维护如果它在静态库级别（与上面的单元测试相同的原因）。
我真的需要创建一个静态库，还是应该只为内部使用代码创建一个类？
你可能会问自己以下几点：
如果你对上面的大部分内容回答YES，你应该为这段代码创建一个静态库。从长远来看，它可能会为您省去麻烦。
如果您对上述大部分内容回答NO，那么您可能不从创建静态库中获得了很多好处（因为代码集必须非常特定于项目中这样的例子）。
答案 1 :(得分：5)
在我看来，创建一个静态库有以下好处 -
.m文件）中的类，可以在头文件和文件中使用方法定义来实现代码重用。导入头文件（.h文件）。因此，这不是创建静态库的理由。 由于静态链接代码，我不知道任何性能优势。创建静态库也有自己的维护开销。它不会像创建一个构建那么简单。您必须记住链接静态库，保持兼容性等。
因此，在您的情况下，创建静态库可能没有多大意义。