iOS应用程序瘦身的静态库解决方案

最新推荐文章于 2021-12-17 14:02:45 发布

Julday

最新推荐文章于 2021-12-17 14:02:45 发布

阅读量262

点赞数

分类专栏： iOS 文章标签：程序员 iOS

iOS 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

为什么要给程序瘦身？

随着应用程序的功能越来越多，实现越来越复杂，第三方库的引入，UI体验的优化等众多因素程序中的代码量成倍的增长，从而导致应用程序包的体积越来越大。当程序体积变大后不仅会出现编译流程变慢，而且还会出现运行性能问题，会增加应用下载时长和消耗用户的移动网络流量等等。因此在这些众多的问题下需要对应用进行瘦身处理。
一个应用程序由众多资源文件和可执行程序文件组成，资源文件的优化不在本文探讨范围。本文主要讨论对可执行程序代码瘦身的方法。

对可执行程序代码瘦身主要就是想办法让程序中不会被调用的源代码不参与编译或链接。我们可以通过一些源代码分析工具来查找哪些函数或者类方法没有被调用并从代码中删除掉来解决编译链接前的瘦身问题。这些分析工具也不在本文的讨论范围内。应用程序在编译时会对工程中的所有代码都执行编译处理并生成目标文件。而在链接阶段则会根据程序代码中对符号的引用关系来将所有相关的目标文件链接为一个大的可执行程序文件，并且在链接阶段链接器会优化掉所有没被调用的C/C++函数代码，但是对于OC类中的没有调用的方法则不会被优化掉。所以为了对可执行程序在编译链接阶段进行瘦身处理就需要了解源代码的编译链接规则。这也是本文所要介绍的针对工程通过静态库的形式进行编译和链接的方式来减少可执行程序代码的尺寸。您可以从文章：《深入iOS系统底层之静态库介绍》中详细的了解到静态库的编译链接过程，以及相关的技术细节。

一个瘦身的例子！

为了验证和具体的实践，我在github上建立了一个项目：YSAppSizeTest。您可以从这个项目中看到如何对工程进行构建以实现程序的瘦身处理。

在示例项目中同一个Workspace中分别建立ThinApp和FatApp两个工程，这两个工程实现的功能是一样。在整个应用程序中分别定义了CA、CB、CC、CD、CE一共5个OC类，定义了一个UIView(Test)分类，还有定义了两个C函数：libFoo1和libFoo1。

整个应用程序中只使用了CA和CC两个OC类，以及调用了UIView(Test)分类方法，以及调用了libFoo1函数，并且同时都采用导入静态库的形式。因为这两个工程对文件的定义和分布策略不同使得两个应用程序的最终可执行代码的尺寸是不相同的。

FatApp中的文件定义和分布策略

FatApp工程依赖并导入了FatAppLib静态库工程。
CA,CB两个类都定义在主程序工程中。
CC,CD,CE三个类，以及UIView(Test)分类，还有libFoo1,libFoo2两个函数都定义在FatAppLib静态库工程中。
CC,CD两个类定义在同一个文件中，CE类则定义在单独的文件中。
FatApp工程的Other Linker Flags中设置了 -ObjC选项。

ThinApp中的文件定义和分布策略

ThinApp工程依赖并导入了ThinAppLib静态库工程。
主程序工程就是一个壳工程。
CA,CB,CC,CD,CE5个类，以及UIView(Test)分类，还有libFoo1,libFoo2两个函数都定义在ThinAppLib静态库工程中。
上述的5个类都分别定义在不同的文件中。
ThinApp工程的Other Linker Flags中没有设置-ObjC选项。

上述两个工程的程序被Archive出来后，FatApp可执行程序的尺寸是367KB，而ThinApp可执行程序的尺寸是334KB。通过一些工具比如Mach-O View或者 IDA可以看出：FatApp中5个OC类的代码以及libFoo1函数还有UIView(Test)分类的代码都被链接进可执行程序中；而ThinApp中则只有CA,CC两个类以及libFoo1函数还有UIView(Test)分类的代码被链接进可执行程序中。在ThinApp中虽然没有使用-Objc链接选项，但是静态库中的分类也被链接进可执行程序中。

应用程序工程构建规则

根据对项目中的文件定义和引用策略以及相关的理论基础我们可以按照如下的规则来构建您的应用程序：
尽量将所有代码都移植到静态库中，而主程序则保留为一个壳程序。具体操作方法是建立一个Workspace，然后主程序工程就只有默认创建工程时的代码，所有新加入的代码都建立并存放到静态库工程中去，然后通过工程依赖来引入这些静态库工程，或者借助一些工程化工具比如Cocoapods来实现这种拆分和引用处理。主程序工程中只保留AppDelegate的代码，其他代码都一致到静态库中。然后在AppDelegate中的相关代码处调用静态库中定义的业务代码。
按业务组件对工程进行解耦每个组件是一个静态库工程。静态库中的每一个文件中最好只有一个类的实现，并且类的分类实现最好和类实现编写在同一个文件中，相同功能的代码以及可能都会被调用的代码尽量存放在一个文件中。
不要在主程序工程中使用-ObjC和-all_load两个选项而改为用-force_load 来单独指定要执行加载的静态库。-ObjC和-all_load选项会把主程序工程以及所依赖的所有静态库中的工程中的全部代码都链接到可执行程序中而不管代码是否有被调用过或者使用过。而force_load则只会将指定的静态库中的所有代码链接到可执行程序中，当然force_load如果没有必要也尽量不要使用。
尽量减少在静态库中定义OC类的分类方法，如果一定要定义分类方法则可以将分类方法定义在和类定义相同的文件中，或者将分类方法定义在一个一定会被调用和引用的实现文件中。因为根据链接规则静态库中的分类是不会被链接进可执行程序中的，除非使用了上述的三个链接选项。如果将分类代码单独的定义在一个文件中的话则可以通过在分类的头文件中定义一个内联函数，内联函数调用分类实现文件中的一个dumy函数,这样只要这个分类的头文件被include或者import就会把整个分类的实现链接到可执行程序中去。一般情况下我们在静态库中建立分类那就表明一定会被某个文件引用这个分类，从而实现整个文件的链接处理。在分类中定义的这两个函数则因为没有被任何地方调用，因此会在链接优化中将这两个函数给优化掉。这样就使得即使我们不用-ObjC选项也能将静态库中的分类链接到可执行程序中去。最后需要注意的是在每个分类中定义的这两个函数名最好能够唯一这样就不会出现符号重名冲突的问题了。

//分类文件的头文件UIView+XXX.h
@interface UIView (XXX)

//分类中定义的方法

@end

/*
  通过在分类的头文件中定义一个内联函数，内联函数调用分类实现文件中的一个dumy函数,这样只要这个分类的头文件被include或者import就会把
  整个分类的实现链接到可执行程序中去。一般情况下我们在静态库中建立分类那就表明一定会被某个文件引用这个分类，从而实现整个文件的链接处理。
  而在分类中定义的这两个函数则因为没有被任何地方调用，因此会在链接优化中将这两个函数给优化掉。这样就使得即使我们不用-ObjC选项也能
  将静态库中的分类链接到可执行程序中去。最后需要注意的是在每个分类中定义的这两个函数名最好能够唯一这样就不会出现符号重名冲突的问题了。
 */
extern void _cat_UIView_XXX_Impl(void);
inline void _cat_UIView_XXX_Decl(void){_cat_UIView_XXX_Impl();}


------------------------------------------------------------
//分类文件的实现文件UIView+XXX.m
#import "UIView+XXX.h"

@implementation UIView (XXX)

//分类的实现代码

@end

void _cat_UIView_XXX_Impl(void){}


---------------------------------------------------------------
//最后把这个分类头文件放入到某个对外暴露的头文件中，比如本例中将分类代码放入到了ThinAppLib.h文件中
//ThinAppLib.h

#import "UIView+XXX.h"
//其他头文件

除了可以通过-force_load来加载指定静态库中的所有代码外。我们还可以在构建静态库时，在静态库的工程的Build Settings中将Perform Single-Object Prelink 中的开关选项打开。当这个开关打开时，系统会对生成的静态库的所有目标文件执行预链接操作，预链接操作会将所有的目标文件组合成为一个单独的大的目标文件。这样根据以文件为单位的链接规则就会将静态库中的所有代码全部都链接进可执行程序中去，但是这样带来的问题就是最后在dead code stripping时删除不掉已经链接进来的那些没有被任何地方使用过的OC类了。
对于引入的一些第三方静态库或者第三方的开源库来说因为我们无法去改变其实现逻辑。如果这个静态库中没有任何分类代码的定义则正常引用即可，如果静态库中有分类方法的定义则单独对这个静态库采用-force_load选项。

总之一句话：为了让你的程序瘦身，尽量将代码放到静态库中，不要使用-Objc和-all_load选项