iOS应用启动速度分析
来源:互联网 发布:金淘淘软件 编辑:程序博客网 时间:2024/05/16 19:51
很多app的开发者都不重视app的启动速度,这对于碎片化使用情景的用户来说,简直是灾难。
iOS应用的启动速度
应用启动时,会播放一个放大的动画。iPhone上是400ms,iPad上是500ms。最理想的启动速度是,在播放完动画后,用户就可以使用。
如果应用启动过慢,用户就会放弃使用,甚至永远都不再回来。抛开代码不谈,如果抱着PC端游和单机游戏的思维,在游戏启动时强加公司Logo,启动动画,并且用户不可跳过,也会使用户的成功使用率大大降低。
iOS系统的“看门狗"
为了防止一个应用占用过多的系统资源,开发iOS的苹果工程师门设计了一个“看门狗”的机制。在不同的场景下,“看门狗”会监测应用的性能。如果超出了该场景所规定的运行时间,“看门狗”就会强制终结这个应用的进程。开发者们在crashlog里面,会看到诸如0x8badf00d
这样的错误代码(“看门狗”吃了坏的食物,它很不高兴)。
值得注意的是,Xcode在Debug的时候,会禁止“看门狗”。
如何测试启动时间
两种方法:一种使用NSLog,另外一种使用Time Profiler。
- 使用NSLog
CFAbsoluteTime StartTime; int main(int argc, char **argv) { StartTime = CFAbsoluteTimeGetCurrent(); // ... } - (void)applicationDidFinishLaunching:(UIApplication *)app { dispatch_async(dispatch_get_main_queue(), ^{ NSLog(@"Launched in %f sec", CFAbsoluteTimeGetCurrent() - StartTime); }); // ... }
- 使用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秒的启动动画时,应该想想究竟什么是应该做的。做正确的事情比把事情做好更重要。
App启动时间过长,系统会杀掉进程(转自)
有一天,公司的网络出现的问题,所有的机器都不能访问外网了。突然我发现一直运行正常的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的超时时间似乎是应用控制不了的。
- iOS应用启动速度分析
- iOS应用启动速度
- iOS应用启动速度
- iOS应用启动速度
- iOS开发 应用启动速度的优化
- Android应用启动速度分析和优化方法
- ios应用启动过程及生命周期分析
- Android 应用启动速度优化
- Android 应用启动速度优化
- Android 应用启动速度优化
- Android应用启动速度优化
- Android应用启动速度优化
- Android 应用启动速度优化
- Android优化应用启动速度
- Android优化应用启动速度
- Android优化应用启动速度
- Android 应用启动速度优化
- iOS苹果APP启动速度
- TCP/UDP端口扫描(多线程应用-仅处于理论状态)-java
- C# .net 简单的点击小图显示大图。
- node PM2 简介
- 关于latch的说明
- 发送http请求
- iOS应用启动速度分析
- 给应用名加后缀以区分正式版和测试版
- MongoDB学习笔记(一) Linux下MongoDB的安装和配置
- android游戏开发中图形绘制:Canvas和Paint的使用
- 针对设置RGB颜色,无需转换
- 转载:cassandra读写性能原理分析
- Git 合并时冲突 Merge Conflict:file still marked as conflicted 解决方法
- 年终总结
- css3动画 抖动效果