默认
发表评论 10
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
iOS版微信安装包“减肥”实战记录
阅读(73477) | 评论(10 收藏2 淘帖2

前言


微信经过多次版本迭代,产生不少冗余代码和无用资源。之前微信也没有很好的手段知道哪个模块增量多少。另外去年10月微信开始做ARC支持,目的是为了减少野指针带来的Crash,但代价是可执行文件增大20%左右。而苹果规定今年6月提交给Appstore的应用必须支持64位,32位和64位两个架构的存在使得可执行文件增加了一倍多。安装包大小优化迫在眉睫。

Appstore安装包是由资源和可执行文件两部分组成,安装包瘦身也是从这两部分进行。(您也可以查看本文的iOS姊妹篇:《移动端IM实践:Android版微信界面卡顿监测方案》)

第一弹:引用资源“减肥”


资源瘦身主要是去掉无用资源和压缩资源,资源包括图片、音视频文件、配置文件以及多语言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的数据类型

typedef struct {
    Byte _fieldNumber;
    Byte _fieldLabel;
    Byte _fieldType;
    BOOL _isPacked;
    int _enumInitValue;
    union {
        __unsafe_unretained NSString* _messageClassName;
        __unsafe_unretained Class _messageClass; // ClassName对应的Class
        IsEnumValidFunc _isEnumValidFunc; // 检测枚举值是否合法函数指针
    };
} PBFieldInfo;

另外通过无用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挺影响性能的);等等

class PBClassInfo {
public:
    PBClassInfo(Class cls, PBFieldInfo* fieldInfo);
    ~PBClassInfo();

public:
    unsigned int _numberOfProperty;
    std::string* _propertyNames;
    size_t* _propertyNameHashes;
    std::string* _getterObjCTypes;
    std::string* _setterObjCTypes;

    PBFieldInfo* _fieldInfos;
};

@interface WXPBGeneratedMessage () {
    uint32_t _has_bits_[3]; // 最多96个属性,表示属性是否有赋值
    int32_t _serializedSize;
    PBClassInfo* _classInfo;
    id* _ivarValues;
}
- (NSMethodSignature*) methodSignatureForSelector:(SEL) aSelector;
- (void) forwardInvocation:(NSInvocation*) anInvocation;
- (void) setValue:(id) value forUndefinedKey:(NSString*) key;
- valueForUndefinedKey:(NSString*) key;
@end

把冗余代码去掉后,整个类清爽多了。像GameResourceReq只有3个属性的proto结构体,类方法代码行数由以前的127行变成现在的8行。protobuf精简改造中,精简类方法减少了可执行文件8.8M,去掉类成员变量和类属性改用@dynamic减少了2.5M。
message GameResourceReq {
    required BaseRequest BaseRequest = 1;
    required int32 PropsCount = 2;
    repeated uint32 PropsIdList = 3[packed=true];
}
// 老实现
@implementation GameResourceReq

@synthesize hasBaseRequest;
@synthesize baseRequest;
@synthesize hasPropsCount;
@synthesize propsCount;
@synthesize mutablePropsIdListList;
@dynamic propsIdList;

- (id) init {...}
- (void) SetBaseRequest:(BaseRequest*) value {...}
- (void) SetPropsCount:(int32_t) value {...}
- (NSArray*) propsIdListList {...}
- (NSMutableArray*)propsIdList {...}
- (void)setPropsIdList:(NSMutableArray*) values {...}
- (BOOL) isInitialized {...}
- (void) writeToCodedOutputStream:(PBCodedOutputStream*) output {...}
- (int32_t) serializedSize {...}
+ (GameResourceReq*) parseFromData:(NSData*) data {...}
- (GameResourceReq*) mergeFromCodedInputStream:(PBCodedInputStream*) input {...}
- (void) addPropsIdList:(uint32_t) value {...}
- (void) addPropsIdListFromArray:(NSArray*) values {...}
@end
// 新实现
@implementation GameResourceReq

PB_PROPERTY_TYPE baseRequest;
PB_PROPERTY_TYPE opType;
PB_PROPERTY_TYPE brandUserName;

+ (void) initialize {
  static PBFieldInfo _fieldInfoArray[] = {
    {1, FieldLabelRequired, FieldTypeMessage, NO, 0, ._messageClassName = STRING_FROM(BaseRequest)},
    {2, FieldLabelRequired, FieldTypeInt32, NO, 0, 0},
    {3, FieldLabelRepeated, FieldTypeUint32, NO, 0, 0},
  };
  initializePBClassInfo(self, _fieldInfoArray);
}
@end

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文件的分析,可以得知每个模块可执行文件占用大小。再对比两个版本,就知道业务模块的增量大小。参考如下:

iOS版微信安装包“减肥”实战记录_微信安装包瘦身监控.jpg

全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择:
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
WebSocket详解(一):初步认识WebSocket技术
socket.io实现消息推送的一点实践及思路
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
>> 更多同类文章 ……

[7] 有关实时音视频开发:
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、V8的前世今生
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM系统中如何保证消息的可靠投递(即QoS机制)
谈谈移动端 IM 开发中登录请求的优化
完全自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Android客户端开发指南
开源移动端IM技术框架MobileIMSDK:Java客户端开发指南
开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南
开源移动端IM技术框架MobileIMSDK:Server端开发指南
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

附录:有关QQ、微信的文章汇总


[1] 有关QQ、微信的技术文章:
微信后台团队:微信后台异步消息队列的优化升级实践分享
微信团队原创分享:微信客户端SQLite数据库损坏修复实践
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)
微信Mars:微信内部正在使用的网络层封装库,即将开源
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]
微信团队原创分享:Android版微信从300KB到30MB的技术演进
微信技术总监谈架构:微信之道——大道至简(演讲全文)
微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]
如何解读《微信技术总监谈架构:微信之道——大道至简》
微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]
微信异步化改造实践:8亿月活、单机千万连接背后的后台解决方案
微信朋友圈海量技术之道PPT [附件下载]
微信对网络影响的技术试验及分析(论文全文)
一份微信后台技术架构的总结性笔记
架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
快速裂变:见证微信强大后台架构从0到1的演进历程(二)
微信团队原创分享:Android内存泄漏监控和优化技巧总结
全面总结iOS版微信升级iOS9遇到的各种“坑”
微信团队原创资源混淆工具:让你的APK立减1M
微信团队原创Android资源混淆工具:AndResGuard [有源码]
Android版微信安装包“减肥”实战记录
iOS版微信安装包“减肥”实战记录
移动端IM实践:iOS版微信界面卡顿监测方案
微信“红包照片”背后的技术难题
移动端IM实践:iOS版微信小视频功能技术方案实录
移动端IM实践:Android版微信如何大幅提升交互性能(一)
移动端IM实践:Android版微信如何大幅提升交互性能(二)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
移动端IM实践:iOS版微信的多设备字体适配方案探讨
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事:
技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码
技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史
开发往事:深度讲述2010到2015,微信一路风雨的背后
开发往事:微信千年不变的那张闪屏图片的由来
开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)
一个微信实习生自述:我眼中的微信开发团队
>> 更多同类文章 ……

(原文链接:点此查看

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:移动端IM实践:iOS版微信界面卡顿监测方案下一篇:Android版微信安装包“减肥”实战记录

本帖已收录至以下技术专辑

推荐方案
评论 10
这篇文章之前看过。可以借鉴的主要是编译选项的设置,这倒是可以试试。
其它涉及代码的删减和优化主要跟代码的实现联系一起,最好还是能具体项目具体分析。
安装包减重总归是有办法的,只要死磕它。
iOS的安装包大小确实太夸张了,动不动一个IPA就是几十M,尤其需要同时兼容32位和64位,几乎是双倍大小。这确实很恶心。
签名: 家里电脑坏了,还让不让人好好撸了。
使用图片资源的时候不需要@2x和@3x的图片了么? 那是不是说现在的app里只要一套图片就可以了? 求解~~
WeChat的工程名竟然是MicroMessenger
另一种是通过otool命令逆向__DATA.__objc_classlist段和__DATA.__objc_classrefs段来获取当前所有oc类和被引用的oc类,两个集合相减就是无用oc类。 不知道这个咋操作??哭哭哭
楼主, 我最近在公司也是做的这么一个工作, 但是我的任务只是排布.o文件大小, 删除资源, 当然我是用的笨办法,关于下面这一段,读者看了还是不会操作, 你可再详细指导一下, 我的qq:914078998 多谢了。 结合LinkMap文件的__TEXT.__text,通过正则表达式([+|-][.+\s(.+)]),我们可以提取当前可执行文件里所有objc类方法和实例方法(SelectorsAll)。再使用otool命令otool -v -s __DATA __objc_selrefs逆向__DATA.__objc_selrefs段,提取可执行文件里引用到的方法名(UsedSelectorsAll),我们可以大致分析出SelectorsAll里哪些方法是没有被引用的(SelectorsAll-UsedSelectorsAll)。注意,系统API的Protocol可能被列入无用方法名单里,如UITableViewDelegate的方法,我们只需要对这些Protocol里的方法加入白名单过滤即可。
引用:lcqingx 发表于 2016-03-11 01:52
使用图片资源的时候不需要@2x和@3x的图片了么? 那是不是说现在的app里只要一套图片就可以了? 求解~~

你理解错了文章里的意思了:作者说要要把@2x、@3x的图片的删除,意思是在删除不带@2x或@3x尾巴的图片时,不要忘了把@2x、@3x的同名高清图也删除,而不是说app里不需要这两种图了。
引用:lcqingx 发表于 2016-03-11 01:53
另一种是通过otool命令逆向__DATA.__objc_classlist段和__DATA.__objc_classrefs段来获取当前所有oc类和被 ...

就是通过otool找出2个集合,相减得出的地址再去LinkMap&nbsp;file找出类名称。<br>而且还要减去__objc_superrefs段。<br>还存在2种误报情况:<br>1.NSClassFromString(“ABCClass”)动态调用;<br>2.被间接继承的基类;
MicroMessenger  这是标准的名称
最近正好在关注瘦身相关技术文档,&#128077;
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部