即使您不想与其他开发人员共享您的代码,您仍然可以从创建静态库中获得巨大的好处。
正如Srikar Appal 所提到的,从创建静态库中获得的好处是1) 代码分发,2) 代码重用,我还想补充一下,3) 版本控制,4) 可测试性(对下面BergQuester的评论表示赞赏)和5 ) 文档。
让我们更仔细地看看这些:
1) 代码分发
静态库很棒,因为它们使您的代码分发变得容易——您所要做的就是编译和共享生成的.a
文件。
即使您从未打算与其他开发人员共享您的代码,您仍然可以在您自己的项目中使用它。
或者,您可以改为将静态库的项目作为子项目包含到您的各种主项目中,使其成为主项目的依赖项......请参阅https://github.com/jverkoey/iOS-Framework了解如何设置.
2) 代码重用
即使在非常不同的应用程序中,您也经常会发现您正在执行与之前编写代码的任务相同的任务。如果您是一名高效的开发人员,您不会想再次编写相同的代码……相反,您只想包含以前编写的、经过优化的代码。
你可能会说,But I can just include the classes directly
.
但是,如果您的代码不一定polished
是 怎么办?或者,随着时间的推移,它使用的框架会发生变化?
当您对代码集进行更改和错误修复时,能够轻松地将最新版本包含在您的项目中(或者稍后能够轻松地更新您的项目)会很好。静态库使这更容易做到,因为所有相关代码都包含在一个包中。
也不必担心其他开发人员对其施加了哪些其他特定于项目的黑客攻击——主项目不能(或者在作为子项目包含的静态库的情况下,不应该)更改静态库的代码集。
这有一个额外的好处,如果有人确实需要更改静态库的代码集,他必须进行更改,以便依赖它的所有项目仍然能够使用它(没有特定于项目的快捷方式黑客)。
3) 版本控制
如果您有一组移动并包含项目到项目的类,那么很难跟上版本控制。最有可能的是,您拥有的唯一版本控制是主项目的版本控制。
如果一个项目修复了一些错误而另一个项目修复了这个类集中的其他错误怎么办?您可能不知道合并这些更改(如果两个团队即使在这些更改上也分开工作怎么办)?或者,每个项目可能都在修复相同的错误!
通过创建静态库,您可以跟踪版本控制(静态库的项目有自己的版本号),并且通过对静态库进行更改,您将减少合并问题并消除修复相同错误的风险和结束。
4) 可测试性
随着 iOS 作为一个平台不断成熟,对代码进行单元测试变得越来越普遍。Apple 甚至继续构建和扩展测试框架 (XCTest),以使iOS 开发人员更轻松、更快地编写单元测试。
虽然您可以(并且恕我直言,应该)在应用程序级别为您的代码编写单元测试,但使用 IN 静态库创建和封装代码通常会使这些测试更好且更易于维护。
测试更好,因为设计良好的静态库封装了有目的的功能(即,设计良好的库执行特定任务,例如网络任务),这使得“单元”测试代码更容易。
也就是说,一个设计良好的静态库旨在完成一个预定义的“目的”,因此本质上,它自然地创建了测试边界(即联网和呈现获取的数据可能至少是两个独立的库)。
测试更容易维护,因为它们与静态库代码位于同一存储库(例如 Git 存储库)中(因此,与此代码一起进行版本化和更新)。就像您真的不想在项目之间复制和粘贴代码一样,您同样也不想复制和粘贴测试。
5) 文档
与单元测试一样,内联文档在 iOS 中变得越来越重要。
虽然您可以(恕我直言,应该)在应用程序级别记录代码,但如果它在静态库级别(与上述单元测试相同的原因) ,维护起来会更好也更容易。
所以回答你的问题,
我真的需要创建一个静态库,还是应该只为仅供内部使用的代码创建一个类?
你可能会问自己以下问题:
- 这段代码会在多个应用程序中使用吗?
- 这段代码会有不止一个类吗?
- 是否会有多个开发人员同时处理或使用此代码(可能在不同的应用程序中)?
- 这段代码会被单元测试吗?
- 这段代码会记录在案吗?
如果您回答YES
了上述大部分问题,您可能应该为此代码创建一个静态库。从长远来看,它可能会为您省去麻烦。
如果您回答NO
了上述大部分问题,您可能不会从创建静态库中获得太多好处(因为在这种情况下,代码集必须非常特定于项目)。