iOS应用启动速度

http://ke.indiebros.com/2012/08/20/ios-app-launch-time-optimization/

很多app的开发者都不重视app的启动速度，这对于碎片化使用情景的用户来说，简直是灾难。

iOS应用的启动速度

应用启动时，会播放一个放大的动画。iPhone上是400ms，iPad上是500ms。最理想的启动速度是，在播放完动画后，用户就可以使用。

如果应用启动过慢，用户就会放弃使用，甚至永远都不再回来。抛开代码不谈，如果抱着PC端游和单机游戏的思维，在游戏启动时强加公司Logo，启动动画，并且用户不可跳过，也会使用户的成功使用率大大降低。

iOS系统的“看门狗"

为了防止一个应用占用过多的系统资源，开发iOS的苹果工程师门设计了一个“看门狗”的机制。在不同的场景下，“看门狗”会监测应用的性能。如果超出了该场景所规定的运行时间，“看门狗”就会强制终结这个应用的进程。开发者们在crashlog里面，会看到诸如0x8badf00d这样的错误代码(“看门狗”吃了坏的食物，它很不高兴)。

场景 “看门狗”超时时间

启动	20秒
恢复运行	10秒
悬挂进程	10秒
退出应用	6秒
后台运行	10分钟

值得注意的是，Xcode在Debug的时候，会禁止“看门狗”。

如何测试启动时间

两种方法：一种使用NSLog，另外一种使用Time Profiler。

• 使用NSLog

 1 CFAbsoluteTime StartTime;
 2 int main(int argc, char **argv) {
 3      StartTime = CFAbsoluteTimeGetCurrent();
 4      // ...
 5 }
 6 
 7 - (void)applicationDidFinishLaunching:(UIApplication *)app {
 8      dispatch_async(dispatch_get_main_queue(), ^{
 9         NSLog(@"Launched in %f sec", CFAbsoluteTimeGetCurrent() - StartTime);
10      });
11      // ...
12  }

• 使用Time Profiler
  • Instruments->Time Profiler
  • Profile你的app
  • 切换到CPU strategy view，找到你的app启动的第一帧
  • 搜索-[UIApplication _reportAppLaunchFinished]
  • 找到包含-[UIApplication _reportAppLaunchFinished]的最后一帧，即可计算出启动时间

iOS App启动过程

• 链接并加载Framework和static lib
• UIKit初始化
• 应用程序callback
• 第一个Core Animation transaction

链接并加载Framework及static lib时需要注意：

• 每个Framework都会增加启动时间和占用的内存
• 不必要的Framework，不要链接
• 必要的Framework，不要票房为Optional
• 只在使用在Deployment Target之后发布的Framework时，才使用Optional（比如你的Deployment Target是iOS 3.0，需要链接StoreKit的时候）
• 避免创建全局的C++对象

初始化UIKit时需要注意：

• 字体、状态栏、user defaults、main nib会被初始化
• 保持main nib尽可能的小
• User defaults本质上是一个plist文件，保存的数据是同时被反序列化的，不要在user defaults里面保存图片等大数据

应用程序的回调：

• application:willFinishLaunchingWithOptions:
• 恢复应用程序的状态
• application:didFinishLaunchingWithOptions:

我一直认为设计的本质是折衷。当你为了100ms的启动速度优化欢欣不已，而无视那长达10秒的启动动画时，应该想想究竟什么是应该做的。做正确的事情比把事情做好更重要。

 

http://blog.csdn.net/dqatsh/article/details/6098849


 

有一天，公司的网络出现的问题，所有的机器都不能访问外网了。突然我发现一直运行正常的iPad应用在启动时经过较长时间的等待后就退出了。

第一反应：是不是对网络通信的处理有问题，导致程序崩溃？那就进入debug跟踪一下吧。奇怪的是，在debug模式下，尽管启动时间较长，但仍然能正常运行下去。（启动时间长的原因是，启动时需要访问服务器，获取数据，由于网络有问题，时间就长了）

 

我一度怀疑是不是ios的bug，但我试了很多其他的应用，为什么其他应用都能正常运行呢？

经过长时间的google，终于对这个问题的产生理解的越来越清楚了。（google是需要技巧的，不合适的关键字往往找不到想要的答案，不要放弃，多尝试，要相信你不是第一个遇到这个问题的人）

 

原来，启动时间太长，ios会认为应用不用正常启动，所以把应用直接给退出了。并不是应用崩溃了。

那为什么debug时没有这个问题呢？ 参见文档： http://developer.apple.com/library/ios/#qa/qa2009/qa1592.html

 

如此看来，解决问题的办法就是尽快的结束启动过程。网络访问通过线程解决，这样就不会阻塞主线程的运行了。

参见： http://iphone.demay-fr.net/2010/05/don’t-perform-network-reachability-tests-in-applicationdidfinishlaunching/

 

最后，为什么网络有问题时通信时间就很长呢？我已经设置了timeout为20秒，显然远远大于这个时间。原来，建立网络连接前需要做域名解析，但网关出现问题后，dns解析也不正常了。dns的超时时间似乎是应用控制不了的。