看看别家的APP性能优秀不？

This post was updated 2010 days ago and some of the ideas may be out of date.

一、前言：

APP的性能大家应该都比较关注，那么咱们的自己APP性能如何呢？如何在拿不到源码的情况下去调试第三方应用的性能呢？下面我就简单实践一下。就以比较著名的今日头条和贝壳找房为例吧！大家看看自己的APP和他们还有多少差距。

二、分析启动时和启动后的cpu和内存占用

下面我们对这个指标以2个APP进行性能分析，分别是贝壳找房2.6.1版本、今日头条7.2.2版本。手机我们使用12.2系统的iPhoneX。我们借助于Instruments中的Activity Monitor工具进行分析。首先我们去拿到这几个ipa的脱壳包（这里可以借鉴这两篇文章，传送门一->点击我, 传送门二->点击我；或者可以去越狱市场直接下载脱壳好的包），脱壳后使用development的证书进行重签名（可以参考：传送门->点击我）。然后我们将这两个包安装到手机中去。
如图：

以下我们分别对这2个APP测试APP启动前5秒的CPU峰值以及对应的内存占用和启动后某一平稳时段的CPU占用以及对应的内存。

2.1

先看今日头条的数据：
如图：

今日头条在前5秒的CPU峰值达到了148.1%，此时的内存占用是63.66M
然后我们再看看启动后的平稳数据
如图：

CPU是3.9%，此时的内存占用是102.06M

2.2

我们再看贝壳找房的数据：
如图：

贝壳找房在前5秒的CPU峰值达到了116.4%，此时的内存占用是77.30M
然后我们再看看启动后的平稳数据
如图：

CPU是2.9%，此时的内存占用是77.02M

从以上数据看，两个APP的突发峰值都还好，平峰比较稳定，大家可以对比看下自己的APP是否和他们差不多，我们再看下一个指标，APP启动时间。

三、分析APP启动时常

下面我们使用 MonkeyDev (传送门->点击我) 工具将上面的那两个包运行起来，在Environment Variables中加入DYLD_PRINT_STATISTICS变量，得到Total pre-main time。我们对每个APP分别测量3次，取平均值。
如图：

3.1

我们先看今日头条的3次测量数据
第一次：

第二次：

第三次：

得到最终今日头条的平均值是：1.3s

3.2

然后我们再看贝壳找房的3次数据
第一次：

第二次：

第三次：

得到最终贝壳找房的平均值是：954.66ms

从以上数据分析，各个APP之间的pre-main之间耗费的时间差别并不多，我们看下各个内容的含义。

dylib loading time
载入动态库，这个过程中，会去装载app使用的动态库，而每一个动态库有它自己的依赖关系，所以会消耗时间去查找和读取。对于Apple提供的的系统动态库，做了高度的优化。而对于开发者定义导入的动态库，则需要在花费更多的时间。Apple官方建议尽量少的使用自定义的动态库，或者考虑合并多个动态库，其中一个建议是当大于6个的时候，则需要考虑合并它们
rebase/binding time
重构和绑定，rebase会修正调整处理图像的指针，并且会设置指向绑定(binding)外部的图像指针。所以为了加快rebase/binding，则需要更少的做指针修复。当你的app当中有太多的Objective-C的类，方法选择器，和类别会增加这一部分的启动时间。有一个数据当大于20000个时候，会增加800ms的时间。另一点：当你的app中使用了很少的C++的虚拟函数，使用Swift会更加高效
ObjC setup time
在Objective-C的运行时(runtime)，需要对类(class)，类别(category)进行注册，以及选择器的分配，所以参照rebase/binding time，尽量减少类的数量，可以达到减少这一部分的时间
initializer time
这一份指代的是执行+initialize方法的时间。如果你执行了+load方法(不建议)，尽量使用+initialize代替。
slowest intializers
这个列出的是最慢的几个dylib文件。

从以上数据来看，他们大致的耗时操作都差不多，需要从以上几点进行一下优化。不过我看来优化启动的时间应该从pre-main之后入手，测试main到第一个viewcontroller的viewDidAppear的时间。

四、分析APP第一个控制器的启动时间

下面我以贝壳找房进行详细描述，用FLEXible获取贝壳找房的首页控制器名称
如图：

然后我们注入如下代码：获取首页控制器的viewDidLoad到viewDidAppear的执行时间

CHDeclareClass(LJHomePageViewController)

CHOptimizedMethod1(self, void, LJHomePageViewController, viewDidAppear, BOOL, animated)
{
    CHSuper1(LJHomePageViewController, viewDidAppear, animated);
    NSLog(@"第一个视图完毕");
    // 得到加载时间
    NSTimeInterval duration = [[NSDate date] timeIntervalSinceDate:self.testDate];
    NSLog(@"????????????%g", duration);
}

CHOptimizedMethod0(self, void, LJHomePageViewController, viewDidLoad)
{
    CHSuper0(LJHomePageViewController, viewDidLoad);
    YYFPSLabel *fpsLabel = [YYFPSLabel new];
    fpsLabel.frame = CGRectMake(180, 200, 120, 30);
    [fpsLabel sizeToFit];
    [[UIApplication sharedApplication].delegate.window addSubview:fpsLabel];

    NSDate *date = [NSDate date];
    // 保存开始时间
    self.testDate = date;
}

////add new property
CHPropertyRetainNonatomic(LJHomePageViewController, NSDate*, testDate, setTestDate);

CHConstructor{
    CHLoadLateClass(LJHomePageViewController);
    CHClassHook0(LJHomePageViewController, viewDidLoad);
    CHClassHook1(LJHomePageViewController, viewDidAppear);

    CHHook0(LJHomePageViewController, testDate);
    CHHook1(LJHomePageViewController, setTestDate);

}

可以看到他第一个控制器的时间约为0.24s，当然网络请求后的渲染时间此处是没有统计的，有兴趣的大家可以再hook网络那部分。

五、分析APP主要列表的FPS

这里我以今日头条为例子，使用FLEXible获取今日头条的主页面，然后分别对各个主页面的viewDidLoad方法进行Hook，然后在这里加入YYFPSLabel。这里直接对APPDelegate进行Hook也可以。
如图：

以下是hook的代码：

@interface TTFeedCollectionViewController
- (void)viewDidLoad;
@end

CHDeclareClass(TTFeedCollectionViewController)

CHOptimizedMethod0(self, void, TTFeedCollectionViewController, viewDidLoad)
{
    CHSuper0(TTFeedCollectionViewController, viewDidLoad);
    YYFPSLabel *fpsLabel = [YYFPSLabel new];
    fpsLabel.frame = CGRectMake(180, 200, 50, 30);
    [fpsLabel sizeToFit];
    [[UIApplication sharedApplication].delegate.window addSubview:fpsLabel];
}

CHConstructor{
    CHLoadLateClass(TTFeedCollectionViewController);
    CHClassHook0(TTFeedCollectionViewController, viewDidLoad);
}

然后我们就可以看到所有页面的帧率
如图：