我是否真的需要为仅供内部使用的代码创建iOS静态库?

Yi *_*ang 4 objective-c static-libraries ios

在头脑风暴会议上,有人建议我们在未来的项目中使用静态库.我整天都在研究这个话题.

我找到了一些关于静态库是什么以及如何创建静态库的有用答案.

图书馆?静态的?动态?还是框架?项目在另一个项目内

我还找到了关于如何使用库的资源的答案:

带有资源的iOS库

我的问题是:

我真的需要创建一个静态库,还是应该只为内部使用代码创建一个类?

条件:

  1. 我有三个需要特殊编码和解码引擎的项目.
  2. 引擎的功能涉及加密,IP包传输和硬件二进制编码.
  3. 功能少于20个.
  4. 我们永远不会将此引擎发布给第三方开发人员或开源.

另一种问方式:

在什么情况下我应该创建一个静态库?

JRG*_*per 8

即使您不想与其他开发人员共享代码,您仍然可以通过创建静态库获得巨大的好处.

正如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开发人员更容易,更快地编写单元测试.

虽然您可以(并且,恕我直言,应该)在应用程序级别为您的代码编写单元测试,但使用静态库创建和封装代码通常会使这些测试更好,更易于维护.

测试更好,因为精心设计的静态库封装了有目的的功能(即设计良好的库执行特定的任务,例如网络任务),这使得更容易"单元化"测试代码.

也就是说,设计良好的静态库开始实现预定义的"目的",因此基本上,它自然地创建测试边界(即,网络呈现所获取的数据可能至少是两个单独的库).

测试更容易维护,因为它们将与静态库代码位于同一个存储库(例如Git repo)中(从而与此代码一起进行版本化和更新).就像您不想将代码从项目复制并粘贴到项目中一样,您也同样不希望复制和粘贴测试.

5)文档

与单元测试一样,在线文档在iOS中继续变得更加重要.

虽然你可以(并且再次,恕我直言,应该)在应用程序级别记录代码,但如果它在静态库级别(与上面的单元测试相同的推理),它再次更好,更容易维护.


所以回答你的问题,

我真的需要创建一个静态库,还是应该只为内部使用代码创建一个类?

你可能会问自己以下几点:

  1. 这个代码会在多个应用程序中使用吗?
  2. 这段代码会不会有多个课程?
  3. 多个开发人员是否会同时处理或使用此代码(可能在不同的应用程序中)?
  4. 这个代码会进行单元测试吗?
  5. 这段代码会被记录下来吗?

如果您回答YES上述大部分内容,您应该为此代码创建一个静态库.从长远来看,它可能会为您省去麻烦.

如果您回答NO上述大部分内容,您可能无法从创建静态库中获得太多好处(因为代码集必须非常特定于此类实例中的项目).


Sri*_*aju 5

在我看来,创建一个静态库有以下好处 -

  1. 代码分发 - 这是开发人员创建静态库的最大原因(也许是唯一的原因).它模糊了实际代码并公开了API方法.但是,由于您已明确提到此"库包"永远不会分发给第三方开发人员,因此这个原因可能不适用.
  2. 代码重用 - 这是我能想到的另一个原因.但是,通过简单地使用(.m文件)中的类,在头文件中具有方法定义并导入头文件(.h文件),可以实现代码重用.因此,这不是创建静态库的理由.

由于静态链接代码,我不知道任何性能优势.创建静态库也有自己的维护开销.它不会像创建一个构建那么简单.你必须记住链接静态库,保持兼容性等.

因此,在您的情况下,创建静态库可能没有多大意义.