iOSApp性能优化

性能优化-详解

性能测试:实时监测应用内存、CPU消耗

                                                                                      部分性能指标及定义

性能指标                                指标描述

应用首次启动时间              测量系统从开始处理 activity到完成运行进入主界面的时间,即冷启动响应时间

界面帧率                              FPS指应用每秒渲染帧数,是用户对应用界面所量现的画面流畅度的体验,FPS过低，用户可感知的流畅度差。 

应用前台运行内存占用      应用在前台且运行稳定时的内存占用情况

应用后台运行CPU占用       应用在后台且亮屏时的cPU占用情况。

CPU&GPU理解

 

CPU：中央处理器(Central Processing Unit)

GPU：图形处理器(Grphics Processing Unit)

 

屏幕成像原理：

屏幕的显示成像是结合CPU数据处理和GPU渲染而来的，即每次屏幕刷新时都会受到CPU和GPU的影响。CPU计算显示内容(视图的创建、布局计算、图片解码、文本绘制等)，完成后将计算好的内容提交到GPU,由GPU进行变换、合成、渲染，随后GPU会把渲染结构提交的帧缓冲区去，等待下一此垂直同步信号到来时显示到屏幕上。iOS系统图形服务提供CADisplayLink等机制通知App，App在主线程开始上述操作。如果在一个刷新时间内，CPU或GPU没有完成内容提交，则那一帧就会被丢弃，等待下一次机会再显示，而此时显示屏会保持之前的内容不变，从而产生掉帧情况，从而导致界面卡顿。

 

 

离屏渲染

在OpenGL中，GPU有两种渲染方式

①On-Screen Rendering : 当前屏幕渲染，在当前用于显示的屏幕缓冲区进行渲染操作.

②Off-Screen Rendering : 离屏渲染 ,在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作.

 

离屏渲染消耗性能的原因

1.需要创建新的缓冲区

2.离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕(On-Screen)切换到离屏(Off-Screen);

当离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕。

 

哪些操作会触发离屏渲染？

1.光栅化, layer.shouldRasterize = YES.

(rasterizedLayer栅格化的空间是有限的，iOS大概有屏幕大小两倍的空间来存储rasterizedLayer或是屏幕外缓冲区)如果设置了shouldRasterize=YES,也要设置rasterizationScale 为 contentsScale.即

self.layer.shoudlRasterize = YES;
self.layer.rasteriztionScale = [UIScreen mainScreen].scale;

2.遮罩, layer.mask

3.圆角, 同时设置layer.masksToBounds = YES、layer.cornerRadious 大于0(通过CoreGraphics绘制裁剪圆角，或者美工提供圆角图片)

4.阴影, layer.shadowXX (如果设置了layer.shadowPath就不会产生离屏渲染)

5.系统的切圆角也会触发离屏渲染

  view.layer.cornerRadious = 5;
  view.layer.maskToBounds = true;

①卡顿优化-CPU

1.尽量用轻量级的对象，比如，用不到事件处理的地方，可以考虑用CALayer代替UIView.

2.不要频繁调用UIView的相关属性，比如frame、bounds、transform等属性，尽量减少不必要的修改.

3.尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性。

4.AutoLayout要比直接修改frame消耗更多的CPU资源。

5.图片的size最好和UIImageView的size保持一致

6.控制一下线程的最大并发数量

7.尽量把耗时的操作放在子线程

 

②卡顿优化-GPU

1.尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示

2.尽量减少视图数量和层次

3.减少透明的视图(alpha<1),不透明的就设置opaque为YES.

4.尽量避免出现离屏渲染

 

其他：

A.频繁操作部分界面

B.自定义绘图渲染(代码)

C.App启动(冷启动、热启动)

D.选择API 多线程/UIImageAPI

E.文件读写

F.APP太大了（如何给APP瘦身）？

G.内存使用不正确

③耗电优化

耗电的主要来源：

• 1.CPU处理, Processing
• 2.网络 ,Networking
• 3.定位, Location
• 4.图像, Graphics

④定位优化:

• 如果只是快速确认位置，最好用CLLocationManager的requestLocation方法。定位完成后，会自动让定位硬件断电。
• 如果不是导航应用，尽量不要实时更新位置，定位完毕就关掉定位服务
• 尽量降低定位精度，比如尽量不要使用精度最高的kCLLocationAccuracyBest
• 需要后台定位时, 尽量设置pausesLocationUpdatesAutomatically为YES， 如果用户不太可能移动的时候系统就会自动暂停位置更新。
• 尽量不要使用startMonitoringSignificantLocationChanges, 优先考虑startMonitoringForRegin

⑤App启动优化

App启动方式：

1.冷启动:(Cold Launch): 从零开始启动App

2.热启动(Warm Launch) App 已经在内存中，在后台存活着，再次点击图标启动APP

App启动时间的优化主要针对冷启动进行优化

通过添加环境变量可以打印出来App的启动时间分析(Edit scheme - >Run ->Arguments)

1.DYLD_PRINT_STRATISTICS设置为1

2.如果需要更详细的信息，那就将DYLD_PRINT_STRATISTICS_DETAILS设置为1

App冷启动大致分三个阶段

①dyld , Apple的动态链接器，可以用来装在Mach-O文件(可执行文件、动态库)

启动App时，dyld做的事

1.装载App的可执行文件，同时会递归加载所有依赖的动态库

2.当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理

②runtime

1.调用map_images进行可执行文件的内容的解析和处理

2.在load_images中调用call_load_methods，调用所有的Class和Category的+load方法

3.进行各种objc结构的初始化(注册Objc类、初始化类对象等等)

4.调用C++静态初始化器和_attribute_((constructor))修饰的函数

到此为止，可执行文件和动态库中所有的符号(Class,Protocol,Selector,IMP…)都已经按照格式成功加载到内存中，被runtime管理。

③main

1.App的启动由dyld主导，将可执行文件加载到内存，顺便加载所有的依赖的动态库、

2.并由runtiem负责加载成objc定义的结构。

3.所有初始化工作结束后，dyld就会调用main函数

4.接下来就是UIApplicationMain函数，AppDelegate的application:didFinishLaunchingWithOptions:方法

优化方案

一、dyld

       减少动态库、合并一些动态库(定期清理不必要的动态库)

        减少Objc类、分类的数量、减少Selector的数量(定期清理不必要的类，分类)

        减少C++虚函数数量

        Swift尽量使用Struct

二、runtime

        用+initialize方法和dispatch_once取代所有的__attribute__((constructor))、C++静态构造器、ObjC的+load方法

三、main

       在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在finishLaunching方法中，按需加载。

 

⑥圆角终极优化方案

 

     /*
     实际中重绘圆角的优化方案需要考虑的是，将图像重新绘制为为圆角图像相当于多了一份拷贝，要不要缓存？A.第一次重绘后将这些圆角图像缓存在磁盘里，第二次加载直接使用缓存的圆角图像；B.直接保存在内存里，在内存比较吃紧时显然不是个好选择；C.不缓存，和系统圆角一样，每次都重绘，浪费电量。
     */
     // 终极优化方案:
   /*
     //Ultimate Solution: Rasterization

     Typical use cases:
     Avoid redrawing expensive effects for static content
     Avoid redrawing of complex view hierarchies
     */
    func enableRasterizationOn(_ view: UIView) {
        view.layer.shouldRasterize = true
        view.layer.rasterizationScale = view.layer.contentsScale
    }

     总结

     1.RoundedCorner 在仅指定cornerRadius时不会触发离屏渲染，仅适用于特殊情况：contents为 nil 或者contents不会遮挡背景色圆角；

   2.Shawdow 可以通过指定路径来取消离屏渲染；

   3. Mask 无法取消离屏渲染；

     以上效果在同等数量的规模下，对性能的影响等级：Shadow > RoundedCorner > Mask > GroupOpacity(迷之效果)。

 

     任何时候优先考虑避免触发离屏渲染，无法避免时优化方案有两种：

     1.    Rasterization：适用于静态内容的视图，也就是内部结构和内容不发生变化的视图，对上面的所有效果而言，在实现成本以及性能上最均衡的。即使是动态变化的视图，开启 Rasterization 后能够有效降低 GPU 的负荷，不过在动态视图里是否启用还是看 Instruments 的数据。

     2.    规避离屏渲染，用其他手法来模拟效果，混合图层是个性能最好、耗能最少的通用优化方案，尤其对于 rounded corer 和 mask。

⑦稳定App缓存

scrollViewDidScrollView，清除缓存

// 清除缓存
[[SDImageCache sharedImageCache] clearMemory];
// 设置缓存时长为1个月
// [SDImageCache sharedImageCache].maxCacheAge = 30 * 24 * 60 * 60; 
// 清除沙盒中所有使用SD缓存的过期图片（缓存时长 > 一个星期）
//  [[SDImageCache sharedImageCache] cleanDisk];
// 清除沙盒中所有使用SD缓存的图片
//  [[SDImageCache sharedImageCache] clearDisk];

⑧UITableView-hightForRow调用时机+Cell行高计算(缓存)

⑨内存优化分析 如何检测内存方面的问题

 公共配置:

A:打开全局断点, 僵尸对象检测，Zombie Objects 进行野指针的检测

  [Person release]: message sent to deallocated instance 0x60400001e690

B:打开全局断点

C.(dealloc方法)析构方法打印看调没调用

常见问题汇总: 

循环引用 / 错误的内存访问 / 内存消耗<RAM :运行内存 ROM:SD卡>

内存泄漏 / 内存溢出

Exc_BAD_ACESS野指针(错误的内存访问 )

/*
(a 向一个已经释放的对象发送消息)
(b weak)
(c 指针)
检测方法: 打开僵尸断点
Edit Scheme-> Run->Diagnostics->Memory Management 
->Malloc Scribble (Bugly 函数 )(增大野指针的崩溃率)
-> Zombie Objects 僵尸对象
*/

 

1.需求分析：UIViewController是否释放，pop/push

2.思路分析：

①ViewWillAppear / DidDisAppear

②确定对象是否存活

1.静态检测方法

     手动：选中Xcode -> Product -> Analyze 【Shift +Command + B】

     自动检测：Build-settings 搜索 Analyze

     Analyze During ‘Build’  设置为YES

 

2.动态检测方法  Instruments->Leaks

   1.跟踪收集信息

     2.分析信息，定位问题

     3.定位问题，解决问题

   分析在绘制过程中捕获的数据。修复源代码中的任何问题

    建议：Instruments 每次修改代码切记使用 cmd + I 进行profile记录

    内存泄漏检查 常见的内存问题（内存泄露、野指针、僵尸对象、循环引用）

   Xcode - > Open Developer Tool -> Instruments -Leaks 

   循环引用：精确到类名

    Leaks -> Cycles & Roots >Leak Cycles

3.第三方检测工具

    pod ‘MLeaksFinder’, ‘~> 1.0.0’

 思路:

/*
UIViewController 延迟发送消息 
push ->viewWillAppear: NO
pop -> YES
viewDidDisappear: 标识信息，发送消息
*/

 

 

 

 

 

 

转载于:https://www.cnblogs.com/StevenHuSir/p/10215114.html