|
引用资源“减肥”
资源瘦身主要是去掉无用资源和压缩资源,资源包括图片、音视频文件、配置文件以及多语言wording。无用资源是指资源在工程文件里,但没有被代码引用。检查方法是,用资源关键字(通常是文件名,图片资源需要去掉@2x @3x),搜索代码,搜不到就是没有被引用。当然,有些资源在使用过程中是拼接而成的(如loading_xxx.png),需要手工过滤。
资源压缩主要对png进行无损压缩,用的是ImageOptim工具和compress命令(需要安装XQuartz-2.7.5.dm插件)。不建议对资源做有损压缩,有损压缩需要设计一个个检查,通常压缩后效果不尽人意。
可执行文件减肥
可执行文件瘦身问题,LinkMap文件可以帮助我们寻找优化点,关于“Xcode's Link Map File”的说明请参考附录哦。
1找出无用的selector
以往C++在链接时,没有被用到的类和方法是不会编进可执行文件里。但Objctive-C不同,由于它的动态性,它可以通过类名和方法名获取这个类和方法进行调用,所以编译器会把项目里所有OC源文件编进可执行文件里,哪怕该类和方法没有被使用到。
结合LinkMap文件的__TEXT.__text,通过正则表达式([+|-][.+\s(.+)]),我们可以提取当前可执行文件里所有objc类方法和实例方法(SelectorsAll)。再使用otool命令otool -v -s __DATA __objc_selrefs逆向__DATA.__objc_selrefs段,提取可执行文件里引用到的方法名(UsedSelectorsAll),我们可以大致分析出SelectorsAll里哪些方法是没有被引用的(SelectorsAll-UsedSelectorsAll)。注意,系统API的Protocol可能被列入无用方法名单里,如UITableViewDelegate的方法,我们只需要对这些Protocol里的方法加入白名单过滤即可。
另外第三方库的无用selector也可以这样扫出来的。
2找出无用Objective-C类
查找无用oc类有两种方式,一种是类似于查找无用资源,通过搜索"[ClassName alloc/new"、"ClassName *"、"[ClassName class]"等关键字在代码里是否出现。另一种是通过otool命令逆向__DATA.__objc_classlist段和__DATA.__objc_classrefs段来获取当前所有oc类和被引用的oc类,两个集合相减就是无用oc类。
3Protobuf优化
protobuf是Google推出的一种轻量高效的结构化数据存储格式,在微信用于网络协议和本地文件序列化。但google默认工具生成的代码比较冗余,像序列化、反序列化、计算序列化大小等方法都生成在具体的pb类里,每个类的实现大同小异。通过代码分析以及结合protobuf原理,要想把这些方法抽象到基类,派生类提供每个字段相关信息就够了:
field number
field label, optional, required or repeated
wire type, double, float, int, etc
是否packed
repeated的数据类型
另外通过无用selector列表,发现不少pb类属性的getter或setter没有被使用。原先的pb类属性是用@synthesize修饰,编译器会自动生成getter和setter。如果不想编译器生成,则要用@dynamic。甚至我们可以把pb类的成员变量去掉。做法如下:
基类增加id类型数组ivarValues(参考了objc_class结构体ivars做法),用于存放对象的属性值。对象属性值统一用oc对象表示,如果类型是基础类型(primitive,如int、float等),则用NSValue存
重载methodSignatureForSelector:方法,返回属性getter、setter的方法签名
重载forwardInvocation:方法,分析invocation.selector类型。如果是getter,从ivarValues获取属性值并设置为invocation的returnValue;如果是setter,从invocation第二个argument获取属性值,并存放到ivarValues里
重载setValue:forUndefinedKey:、valueForUndefinedKey:,防止通过KVO访问属性Crash
做下性能优化,如pb类在initialize做一次初始化,缓存属性名的hash值,属性的getter、setter方法的objcType等;属性值不用std::map(属性名->属性值),而是改用数组;MRC代替ARC(有些时候ARC自动添加的retain/release挺影响性能的);等等。即时通讯聊天软件app开发可以加蔚可云的v:weikeyun24咨询
把冗余代码去掉后,整个类清爽多了。像GameResourceReq只有3个属性的proto结构体,类方法代码行数由以前的127行变成现在的8行。protobuf精简改造中,精简类方法减少了可执行文件8.8M,去掉类成员变量和类属性改用@dynamic减少了2.5M。
4选择合理的编译设置
Strip Link Product设成YES,WeChatWatch可执行文件减少0.3M
Make Strings Read-Only设为YES,也许是因为微信工程从低版本Xcode升级过来,这个编译选项之前一直为NO,设为YES后可执行文件减少了3M
去掉异常支持,Enable C++ Exceptions和Enable Objective-C Exceptions设为NO,并且Other C Flags添加-fno-exceptions,可执行文件减少了27M,其中__gcc_except_tab段减少了17.3M,__text减少了9.7M,效果特别明显。可以对某些文件单独支持异常,编译选项加上-fexceptions即可。但有个问题,假如ABC三个文件,AC文件支持了异常,B不支持,如果C抛了异常,在模拟器下A还是能捕获异常不至于Crash,但真机下捕获不了(有知道原因可以在下面留言:)。去掉异常后,Appstore后续几个版本Crash率没有明显上升。个人认为关键路径支持异常处理就好,像启动时NSCoder读取setting配置文件得要支持捕获异常,等等
5其他可能的优化
iOS8 Embed-Framework:提取WeChatWatch、ShareExtention和微信主工程的公共代码,可执行文件可以减少5M+,不过这特性需要最低版本iOS8才能用,iOS7设备启动会crash
iOS9
App Thinning:严格来说App
Thinning不会让安装包变小,但用户安装应用时,苹果会根据用户的机型自动选择合适的资源和对应CPU架构的二进制执行文件(也就是说用户本地可执行文件不会同时存在armv7和arm64),安装后空间占用更小
6建立版本增量日志
通过对LinkMap文件的分析,可以得知每个模块可执行文件占用大小。再对比两个版本,就知道业务模块的增量大小。 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
×
|