性能-iOS性能调优

iOS之性能调优工具

 

 概述：

　　三类工具

  • 基础工具:（NSLog的方式记录运行时间.）
  • 性能工具: 检测各个部分的性能表现,找出性能瓶颈
  • 内存工具: 检查内存正确性和内存使用效率

性能工具：

　　可以衡量CPU的使用,时间的消耗,电池的消耗

一、Time Profile

　　启动Time Profile：Xcode ——> Product ——> Profile ——> Time Profile

　　使用Time Profiler调试程序，能获取到整个应用程序运行中所消耗的时间分布和百分比

　　使用Time Profile前有两点需要注意的地方：

  • 一定要使用真机调试

在开始进行应用程序性能分析的时候，一定要使用真机。因为模拟器运行在Mac上，然而Mac上的CPU往往比iOS设备要快。相反，Mac上的GPU和iOS设备的完全不一样，模拟器不得已要在软件层面（CPU）模拟设备的GPU，这意味着GPU相关的操作在模拟器上运行的更慢，尤其是使用CAEAGLLayer来写一些OpenGL的代码时候，这就导致模拟器性能数据和用户真机使用性能数据相去甚远

  • 应用程序一定要使用发布配置

在发布环境打包的时候，编译器会引入一系列提高性能的优化，例如去掉调试符号或者移除并重新组织代码。另iOS引入一种"Watch Dog"[看门狗]机制，不同的场景下，“看门狗”会监测应用的性能，如果超出了该场景所规定的运行时间，“看门狗”就会强制终结这个应用的进程。开发者可以crashlog看到对应的日志，但Xcode在调试配置下会禁用"Watch Dog"

    • 启动后如图
    • 点击左上角红色按钮，开始调试
    • 调试时注意右下方选项

      • Separate by Thread：每个线程应该分开考虑，只有这样你才能揪出那些大量占用CPU的"重"线程

      • Invert Call Tree：从上倒下跟踪堆栈，这意味着你看到的表中的方法，将已从第0帧开始取样，这通常你是想要的，只有这样你才能看到CPU中话费时间最深的方法，也就是说FuncA{FunB{FunC}} 勾选此项后堆栈以C->B-A 把调用层级最深的C显示在最外面

      • Hide System Libraries：勾选此项你会显示你app的代码，这是非常有用的。因为通常你只关心cpu花在你自己写的代码上的时间 而不是花在系统代码上的时间

      • Flatten Recursion：递归函数, 每个堆栈跟踪一个条目

      • Top Functions：一个函数花费的时间直接在该函数中的总和，以及在函数调用该函数所花费的时间的总时间。因此，如果函数A调用B，那么A的时间报告在A花费的时间加上B花费的时间，这非常有用，因为它可以让你每次下到调用堆栈时挑最大的时间数字，归零在你最耗时的方法

    • 最终调试界面如图
    • 双击选中行查看代码

内存工具：

　　关心内存泄露和内存垃圾问题

一、Analyze静态分析

  •  静态内存分析

  1. 所谓静态内存分析, 是指在程序没运行的时候, 通过工具对代码直接进行分析

    • 根据代码的上下文的语法结构, 让编译器分析内存情况, 检查是否有内存泄露

  2. 作用

    • 逻辑错误: 访问未初始化的变量或者野指针

    • 声明错误: 声明了一个对象, 但是从未使用过

    • 内存管理错误: 内存泄露

    • 缺点: 静态内存分析由于是编译器根据代码进行的判断, 做出的判断不一定会准确, 因此如果遇到提示, 应该去结合代码上文检查一下

  3. OC中的静态内存分析:

    • 曾经在MRC环境下, OC的代码需要手动管理内存, 任何对象的引用, 都要伴随一次release操作, 否则很容易发生内存泄露, 因此在MRC环境下, 使用静态内存分析很有必要

    • 而在目前的ARC环境下, 很少会发生内存泄露, 但是也会有很少数的情况导致内存泄露

      • 如Foundation对象与CoreFoundation对象的相互转化, CoreFoundation对象享用ARC机制, 所以容易发生内存泄露

  4. Swift的静态内存分析

    • Swift中, 使用了类型重映射机制, 他可以将对象转换成能够自动管理内存的对象, 不需要我们手动释放, 因此Swift在内存管理方面更为安全

  • 内存分配

  1. 作用

    • 查看当前运行情况的内存分配

    • 查看使用过的内存有没有释放掉

  2. 关于App中加载图片的注意点

    • -imageNamed:

      • 该方法用于加载小图片/使用频率高的图片

      • 此方法加载过得图片, 在App运行期间, 始终会保有缓存, 这个缓存是由系统管理的, 无法通过代码销毁缓存

      • 当系统察觉到内存消耗过高, 就会自动释放这部分内存

          Search for an object whose name was set explicitly using the setName: method and currently resides in the image cache.
  该方法首先会从图片内存中查找
  Search the app's main bundle for a file whose name matches the specified string. 
  如果没有找到, 就在App的mainBundle中查找
  Search the Application Kit framework for a shared image with the specified name.
  如果bundle中也没有, 就会去framework的库中寻找

    • -imageWithContentsOfFile:

      • 该方法用于加载大图片/使用率较低的图片

      • 它只是加载一次图片, 并且不会做缓存, 当对象释放的时候, 内存也就被释放掉了

      • 因此对于不常用的图片应该使用这个方法

  3. 图片在沙盒中的存在形式

    1. 如果当前项目部署版本 <= 6.x: 那么所有图片就会直接暴露在沙盒的资源包中(main bundle), 不会进行压缩为Assets.car文件

    2. 如果当前项目部署版本 >= 7.x

      • 放在Images.xcassets中的所有图片, 都会被压缩为Assets.car文件, 不会直接暴露在沙盒的资源包中

      • 而没有放在Images.xcassets的图片, 会直接暴露在沙盒的资源包中

    3. 使用对比

      • 压缩为Assets.car的文件:

        • 这些图片不会暴露在外, 但是无法或得到这些图片的路径, 只能通过图片名-imageName来加载图片, 并且会产生缓存
        • 小图片/使用频率高, 放在image.xcassets中

      • 未压缩的图片:

        • 图片暴露在外, 可以通过imageWithContentOfFile来获得图片的路径, 不会有缓存

        • 大图片/使用频率低, 如新特性界面, 放在外面

二、Leaks动态内存分析

　　对于有些内存泄漏情况通过静态分析无法解决的，可以通过动态分析来发现，分析起来更有针对性

  • 点击XCode的Product菜单Profile启动Instruments：

  • 选择Leaks，会自动启动Leaks工具和IOS模拟器：

    Leaks启动后会开始录制，随着对模拟器运行的App的操作，可以在Leaks中查看内存占用的情况。

    Leaks顶部分为两栏：Allocations和Leaks


    Allocations纪录了内存分配，用来优化内存使用的

    Leaks用来分析内存泄漏。ARC中引起的内存泄漏原因就是引用环。

　　然后看看Call Tree，因为Call Tree会给我们大概的位置，有时候会给我们精确的位置，不过要看运气了。　　 

       

　　然后，再又面选择Invert Call Tree和Hide System Library

       
　　然后，我们就知道大概内存泄漏的位置在NSOperation的子类这里了。

　　然后双击上文图片中的任意一行，就会跳到代码处内存泄漏的地方（事实上，到这步，很多内存泄漏的问题都会被发现）

      

      那么怎么办呢？有问题下看文档，我们看到图片中引起引用计数加一的是

      + (NSURLSession*)sessionWithConfiguration:(NSURLSessionConfiguration*)configurationdelegate:(id)delegatedelegateQueue:(NSOperationQueue*)queue:

      看下文档，发现了这个地方

　　

　　于是，我们要手动的去断开强引用，于是，我们手动去断开

-(void)setOperationFinished{ 

  [self.sessioninvalidateAndCancel]; 

  [selfwillChangeValueForKey:@"isFinished"];   

  [selfwillChangeValueForKey:@"isExecuting"];   

  executing =NO;    finished =YES;   

  [selfdidChangeValueForKey:@"isExecuting"];   

  [selfdidChangeValueForKey:@"isFinished"];

}

     再运行下看看，能够正常的Dealloc了，用leaks分析，也没有内存泄漏了

     

　　总结：其实大多数问题在双击上文的代码部分就可以解决了，少数问题需要详细的分析ARC引用过程 

三、Zombie内存垃圾

  1. 内存中被过度释放的对象，又称僵尸对象，报EXC_BAD_ACCESS错误调式。访问了一个已经被释放的对象。

  2. 手动设置NSZombieEnabled环境变量：Edit scheme—>Test—>diagnostics—>zombie objects。不建议手动设置，因为会导致内存占用的增长，同时会影响Leaks工具的调式，这是因为设置NSZombieEnabled会用僵尸对象来代替已释放对象。



  3. 启动Instruments,选择Zombies进行调试。

参考： https://www.cnblogs.com/junhuawang/p/5652996.html

 

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/cpas-3-org/p/15429689.html