


























动态库 & 静态库,若单独输出并接入主工程,逻辑倒很清晰。如果牵涉到多个 framework 不同类型并且相互依赖,会增加不少复杂度。
以下说明中,动态库使用 DFramework 表示,静态库使用 SFramework 表示。
仅需要提供 1 个 framework,直接提供 DFramework 即可。DFramework 优先,必要的时候再提供 SFramework
因为代码结构分组,可能需要提供多个 framework:
frameworks文件夹中,通过 embed 实现。一般这种场景是因为开发 framework 的同时,又使用了开源的库。这个时候如何处理开源库是个问题(开源库一般都是 源码 提供的,不讨论 闭源包 提供方式,这个和上面的场景一致)。
由于 apple 的 Swift Package Manager 三方库管理的介入,一个 module 在最终的 app 中到底是 dymanic 还是 static,已经不可控了。SPM 会自行管理,不像 cocoapods 的时候我们可以自行控制。
如果是源码提供者,可以增加 dymanic / static 约束。但很多源码都不会提供这个选项,而是让 SPM 自行管理采用哪一个。
在这种场景下,开发的 framework 如果对开源库有依赖,就必须考虑是否【去开源】事宜了。
另外,除了自己使用开源库,App 主工程开发者,可能也需要使用同一个开源库,这时候还会出现【版本不一致问题】。
以下场景,假设有 T 开源代码需要使用:
framework 需要依赖 T
-weak_framework进行标记,这样业务也可以不接入,相当于默认不使用这个功能。第一步就是需要对 T 进行【模块隔离】,否则外界也接入 T 的时候,App 主工程和我们提供的 framework 同时有 T 代码,会有问题。
虽然 xcode 在编译连接的时候,会处理好这个问题,使得同一份代码尽量在 app 中仅保留一份。
但如果开发人员使用不恰当或者配置错误,很可能导致出现两份 T 源码在项目中。
这个时候如果版本还不兼容,就会有非常大的调试和异常隐患。
模块隔离方案:修改 Product Name,将 T 变成 TT 模块
然后,还需要考虑将 TT 变成静态库还是动态库:
这是完全去开源的方案。变成静态库后,TT 源码将打入 framework 二进制中一起提供。因为模块隔离,外部也无法调用和感知。
使用动态库的话,如前面【需要提供多个 framework】所描述的,有两种方案:
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。