内存分析(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来获得图片的路径, 不会有缓存
        • 大图片/使用频率低, 如新特性界面, 放在外面

4. 补充一个获取car中图片的方法

   • github: https://github.com/devcxm/iOS-Images-Extractor