iOS启动优化(一)性能检测

项目启动优化是每个APP都可以接入的技术,只不过针对不同的业务逻辑我们需要有不一样的解决方案,因为有大部分人的“优化”,是在处理自己放荡不羁的代码。


既然这里我们要讨论启动优化,那么我们从启动检测开始。启动检测一般我们会以main函数作为分割点,main之前和main之后。
main之前称为per-main 阶段。这个由dyld给你反馈应用的耗时。
main之后由开发者自己检测。我们可以从main开始打点,到第一个页面显示为止。

pre-main阶段检测

main函数之前的检测苹果提供了支持,具体配置方式来来来!上图!

  • 首先进入Edit Scheme


    Edit Scheme
  • 然后配置的 key 为:DYLD_PRINT_STATISTICS


  • 然后我们再运行项目,该项目 pre-main 的耗时就会在控制台输出。
Total pre-main time: 123.34 milliseconds (100.0%)
         dylib loading time:  46.83 milliseconds (37.9%)
        rebase/binding time:   3.01 milliseconds (2.4%)
            ObjC setup time:  18.58 milliseconds (15.0%)
           initializer time:  54.91 milliseconds (44.5%)
           slowest intializers :
             libSystem.B.dylib :   5.00 milliseconds (4.0%)
   libBacktraceRecording.dylib :   9.43 milliseconds (7.6%)
    libMainThreadChecker.dylib :  17.72 milliseconds (14.3%)
  libViewDebuggerSupport.dylib :  20.72 milliseconds (16.8%)

字段含义

dylib loading time 动态库载入耗时

载入动态库,这个过程中,会去装载app使用的动态库,而动态库之间有它自己的依赖关系,所以会消耗时间去查找和读取。
系统的动态库,做了优化。所以从效率的角度来说,尽可能使用系统库。
而对于开发者定义导入的动态库(dynamically linked shared library),则需要在花费更多的时间。Apple官方建议尽量少的使用自定义的动态库,或者考虑合并多个动态库,其中一个建议是当大于6个的时候,则需要考虑合并它们。
在性能上出发将动态库编译成静态库也会优化这部分时间。

rebase/binding time 修正符号和绑定符号耗时

Rebase:在镜像(MachO文件)内部调整指针的指向,针对mach-o在加载到内存中不是固定的首地址(ASLR)这一现象做数据修正的过程。
iOS4.3后引入了 ASLR ,MachO会被加载到随机地址,这个随机的地址跟代码和数据指向的旧地址会有偏差。dyld 需要修正这个偏差,做法就是将 dylib 内部的指针地址都加上这个偏移量。
binding:将指针指向镜像(MachO文件)外部的内容,binding就是将这个二进制调用的外部符号进行绑定的过程。

ObjC setup time OC类注册的耗时

主要做以下几件事来完成Objc Setup:
1、读取二进制文件的 DATA 段内容,找到与 objc 相关的信息
2、注册 Objc 类,ObjC Runtime 需要维护一张映射类名与类的全局表。当加载一个 MachO 时,它定义的所有的类都需要被注册到这个全局表中;
3、读取 protocol 以及 category 的信息,把category的定义插入方法列表 (category registration),
这一步的优化。

那么针对这上面三个步骤,我们可以优化的方案是,不刻意的去减少几个类,但是可以避免浪费。
随着项目的不断迭代,很多模块和方法已经被废弃但是却一直留存在项目中,导致项目越来越臃肿。
我们可以使用一些工具来查找项目中没有被用到的文件。从而达到优化。

initializer time

1、Objc的+load()函数
2、C++的构造函数属性函数 形如attribute((constructor)) void DoSomeInitializationWork()
我们能做的就是将不必须在+load方法中做的事情延迟到+initialize中。
这是因为+load方法是在app启动的时候就被调用,而+initialize方法则是在Class第一次使用的时候才调用,相当于是懒加载了。可以把+load中的代码移到initialize中,并结合dispatch_once来防止重复调用。
但是我们项目中只有在使用method swizzling的时候会在+load中调用方法。所以这一点也没什么好优化的。

针对main函数之后的时间检测就通过打点记录。
在main()、didFinishLaunchingWithOptions以及第一个页面的viewDidAppear中打点,进行记录,从而来计算Main函数之后的时间。

调试三方应用

文章的最后我想要补充一个小东西。就是三方应用的调试。因为既然我们可以检测到性能,那么看看别人的应用性能如何是一件不错的事情。废话不多说!

  • 首先创建一个空工程运行到真机上!(我们要利用这个工程的描述文件)

  • 然后我们需要一个脚本,脚本代码如下:

# ${SRCROOT} 它是工程文件所在的目录
TEMP_PATH="${SRCROOT}/Temp"
#资源文件夹,我们提前在工程目录下新建一个APP文件夹,里面放ipa包
ASSETS_PATH="${SRCROOT}/APP"
#目标ipa包路径
TARGET_IPA_PATH="${ASSETS_PATH}/*.ipa"
#清空Temp文件夹
rm -rf "${SRCROOT}/Temp"
mkdir -p "${SRCROOT}/Temp"
#----------------------------------------
# 1. 解压IPA到Temp下
unzip -oqq "$TARGET_IPA_PATH" -d "$TEMP_PATH"
# 拿到解压的临时的APP的路径
TEMP_APP_PATH=$(set -- "$TEMP_PATH/Payload/"*.app;echo "$1")
# echo "路径是:$TEMP_APP_PATH"
#----------------------------------------
# 2. 将解压出来的.app拷贝进入工程下
# BUILT_PRODUCTS_DIR 工程生成的APP包的路径
# TARGET_NAME target名称
TARGET_APP_PATH="$BUILT_PRODUCTS_DIR/$TARGET_NAME.app"
echo "app路径:$TARGET_APP_PATH"

rm -rf "$TARGET_APP_PATH"
mkdir -p "$TARGET_APP_PATH"
cp -rf "$TEMP_APP_PATH/" "$TARGET_APP_PATH"
#----------------------------------------
# 3. 删除extension和WatchAPP.个人证书没法签名Extention
rm -rf "$TARGET_APP_PATH/PlugIns"
rm -rf "$TARGET_APP_PATH/Watch"
#----------------------------------------
# 4. 更新info.plist文件 CFBundleIdentifier
#  设置:"Set : KEY Value" "目标文件路径"
/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier $PRODUCT_BUNDLE_IDENTIFIER" "$TARGET_APP_PATH/Info.plist"
#----------------------------------------
# 5. 给MachO文件上执行权限
# 拿到MachO文件的路径
APP_BINARY=`plutil -convert xml1 -o - $TARGET_APP_PATH/Info.plist|grep -A1 Exec|tail -n1|cut -f2 -d\>|cut -f1 -d\<`
#上可执行权限
chmod +x "$TARGET_APP_PATH/$APP_BINARY"
#----------------------------------------
# 6. 重签名第三方 FrameWorks
TARGET_APP_FRAMEWORKS_PATH="$TARGET_APP_PATH/Frameworks"
if [ -d "$TARGET_APP_FRAMEWORKS_PATH" ];
then
for FRAMEWORK in "$TARGET_APP_FRAMEWORKS_PATH/"*
do
#签名
/usr/bin/codesign --force --sign "$EXPANDED_CODE_SIGN_IDENTITY" "$FRAMEWORK"
done
fi
#注入
#yololib "$TARGET_APP_PATH/$APP_BINARY" "Frameworks/HankHook.framework/HankHook"

这个脚本可以生成一个脚本文件,或者直接拷贝代码去配置!脚本中每个功能都写上了注释,不要无脑粘贴。

  • 在工程根目录下新建文件夹,并将脱壳的三方iPA包放进去(我们已微信为例)


  • 给工程添加脚本


  • 配置脚本并执行


接下来就可以将三方的应用运行到真机了。下面是微信的启动时间。pre-main大概1.1秒。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,185评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,445评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,684评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,564评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,681评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,874评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,025评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,761评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,217评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,545评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,694评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,351评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,988评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,778评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,007评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,427评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,580评论 2 349

推荐阅读更多精彩内容