iOSApp性能优化

时间 2019-12-09

标签 iosapp 性能优化栏目系统性能繁體版

原文原文链接

性能优化-详解web

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

部分性能指标及定义性能优化

性能指标 指标描述网络

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

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

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

应用后台运行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:方法

优化方案

1、dyld

减小动态库、合并一些动态库(按期清理没必要要的动态库)

减小Objc类、分类的数量、减小Selector的数量(按期清理没必要要的类，分类)

减小C++虚函数数量

Swift尽可能使用Struct

2、runtime

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

3、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: 标识信息，发送消息
*/