What is a memory leak?
This should be freed memory is not released, resulting in reduction of available space phenomenon. (Excerpt from Baidu know, we dare you to believe)
For example: you dismiss a view controller, but ultimately did not perform this view controller's dealloc method.
Lead to more serious memory leaks are a few places currently experiencing:
A .delegate
I wonder why that developers retain all with the modifier, should lead to the release of many view controllers did not release. This change is simple: retain weak to change.
Two .block
whether to write their own block, or even tripartite system, we must be careful, especially when you refer to the cycle there is no better time control, but be careful how careful one more heart eyes did not always Incorrect.
For example, when using MJRefresh, write cause a memory leak:
|
1
2
3
|
self.tableView.header = [CQHeader headerWithRefreshingBlock:^{
[self getLocation];
}];
|
Write will not:
|
1
2
3
4
|
__weak typeof (self) weakSelf = self;
self.tableView.header = [CQHeader headerWithRefreshingBlock:^{
[weakSelf getLocation];
}];
|
Generally, we will weakSelf and strongSelf used in conjunction.
Three .timer
the actual situation at the right time of the active timer will be set to nil.
|
1
2
|
[_timer invalidate];
_timer = nil;
|
iOS performance optimization: Instruments Tools
Instruments offers a lot of features, focus on what I most often used ones:
1.Time Profiler: the CPU analysis tool for analyzing code execution time.
2.Core Animation: offscreen rendering, layer blending GPU and other time-consuming.
3.Leaks: memory test, memory leak detection tools.
4.Energy Log: power detection means.
5.Network: flow detection tool.
Xcode Instruments using a built-in tool first need to open it.
After you may want to try it in different properties to select the corresponding debugging tools.
A .Time Profiler Introduction
TimeProfiler see the name EENOW: time analysis tool, it will follow a set time interval (default 1 ms) to track information about each thread's stack (stacktrace), and the comparison between the state of the stack by the time interval to calculate a a method of performing a long, give an approximation. Specific steps are as follows:
1. Double-click TimeProfiler into the top left corner of the debug interface After clicking the red origin (Launcher button) you will be able to see the time consumed in the following figure.
However, we found that this information can only be displayed to the bottom of the thread Runloop time-consuming, and can not help us to target specific code to, the following describes the operation and check the meaning CallTree options. These options are not selected by default, but they can help you quickly check on the positioned on the key code, which is often the source of the problem.
Separate by Thread: separate analysis done by threading, it is easier to ferret out those problems eating thread resources. Especially for the main thread, it has to deal with and render all data interfaces, once blocked, and the program is bound Caton or stop responding.
Invert Call Tree: Call Tree reverse output. The call hierarchy of the deepest way to show at the top, is easier to find the most time-consuming operation.
Hide Missing Symbols: Hidden missing symbols. If dSYM file deletion or other system architecture, the list will be a lot of strange hexadecimal value, use this option to screen out these interfering elements, make a list of refreshing return.
Hide System Libraries: hide the system library files. Filter out all kinds of system calls, just to show their code to call.
Flattern Recursion: recursive split. Multiple stack will produce the same recursive functions (because the recursive function calls itself) combined into one.
Top Functions: find a function or method most time-consuming.
After checking the above it can be seen corresponding to the specific code, then double-click operation to select one line Processed they can enter the code and the corresponding display time consuming detailed below:
The time code corresponding to these can do some optimization to reduce duplication of logic optimization consuming CPU.
Two .Core Animation animation rendering using a profile:
CoreAnimation系要注意的一点是必须是真机调试，用于调试离屏渲染，绘图，动画，等操作。调试需注意以下几个选项的勾选：
比较重要的：
·"Color BlendedLayers"：图层混合
显示出被混合的图层BlendedLayer(用红色标注)，BlendedLayer是因为这些Layer是透明的(Transparent)，系统在渲染这些view时需要将该view和下层view混合(Blend)后才能计算出该像素点的实际颜色。所以红色越少越好
·"Color HitsGreen and Misses Red":图层缓存
很多视图Layer由于Shadow、Mask和Gradient等原因渲染很高，因此UIKit提供了API用于缓存这些Layer：[layersetShouldRasterize:YES]，系统会将这些Layer缓存成Bitmap位图供渲染使用，如果失效时便丢弃这些Bitmap重新生成。所以绿色越多，红色越少越好
·"ColorOffscreen-Rendered Yellow":离屏渲染
Offscreen-Rendering离屏渲染意思是iOS要显示一个视图时，需要先在后台用CPU计算出视图的Bitmap，再交给GPU做Onscreen-Rendering显示在屏幕上，因为显示一个视图需要两次计算，所以这种Offscreen-Rendering会导致app的图形性能下降。所以黄色越少越好。
次要的：
·"ColorMisaligned Images":图片缩放
MisalignedImage表示要绘制的点无法直接映射到频幕上的像素点，此时系统需要对相邻的像素点做anti-aliasing反锯齿计算，增加了图形负担，通常这种问题出在对某些View的Frame重新计算和设置时产生的。
·"Color Copiedimages":标注应用绘制时被Core Animation复制的图片
·"ColorImmediately":Instruments在做color-flush操作时取消10毫秒的延时
·"ColorCompositing Fast-Path Blue":标记由硬件绘制的路径
·"Flash UpdatedRegions":重绘的区域
勾选这些不同的选项可以在真机上看到不同颜色的渲染标注。
三.Leaks内存调试使用简介
Leaks是iOS程序中用来检测内存泄漏的工具，灵活的运用Leaks可以帮助我们预防程序中的内存泄漏防止程序内存耗用过大被挂起。首先双击Leaks点击左上角红色圆点运行，并且选中CallTree，在CallTree选项中勾选InvertCallTree和HideSystemLibraries选项如下图所示
然后程序跑起来我们观察上方的内存变化区域，工具中按照时间把所耗内存的大小都以填充图的形式展现出来，当鼠标移动到图的位置时直接显示出那一时刻所占用的内存大小，如果内存途中下方显示出红色叉号则代表此处存在内存泄漏。可以通过鼠标在图中圈出此区域，此时下面的CallTree就会打印出对应的函数堆栈调用以及所占内存大小信息，双击便可进入到对应的代码区域来查看。如下图：
双击函数名称进入到代码对应的位置查看具体：
此时便可以根据代码中对应的位置来进行内存调试工作。
四.Energy Log耗电量检测使用简介：
双击打开EnergyLog直接点击红色圆点运行程序，左侧依次即可看到CPU活动比例，网络活动比例，亮度状态，手机睡眠状态，手机连接蓝牙状态，手机连接wifi状态，手机GPS状态这次都是手机耗电的构成部分。如下图：
我们也可以在Xoce启动程序时点击Xcode左侧状态栏，选择EnergyImpact选项，在右侧即可看到手机实时的耗电情况。如下图：
左上部分是资源实时消耗情况仪表盘,右上部分是资源平均消耗情况,下方是资源具体消耗情况。
注意资源实时消耗情况仪表盘中指针指向的区域
绿色—合理
黄色—资源消耗高.你的程序比较耗电.
红色—资源消耗非常高.仅仅轻度使用你的app,用户就可以明显感到电量在消耗。
下图为具体电量消耗情况：
四个最主要的耗电原因,分别是CPU(唤醒及使用),Network(网络访问),Location(定位功能),Background(后台运行功能)。
每秒刷新.不同功能分别的资源消耗情况.如果消耗资源小方块显示深灰色,没有消耗资源的时候小方块显示白色。
五.Network网络检测使用简介：
双击打开Network直接点击红色圆点运行程序在上方便可以看到手机网络的输入输出大小，用鼠标拦截住一块区域就可以查看这个区间内是我们的App发生的网络消耗还是其他进程发生的，我们还可以查看到网络请求的本地地址和服务地址，输入和输出的大小等信息下面将详细介绍各种查看检测等方式：
上图随便圈出一块消耗网络资源的地方，此时在下方有三个选项：
第一个：Processes代表查看网络进程，也就是你的App和其他程序的使用流量总大小。
第二个：Connections代表所有的访问网络请求的端口，输入输出大小，本地地址，数据包大小，往返时间等信息。
第三个：interfaces即在用户的角度当前手机的整体网络使用情况（不区分线程，只区分网络使用类型- wifi Or流量）。
1.选择Processes
我们可以发现工具把整个网络访问划分为两部分，我们的App和其他的进程，分别显示出它们的：
1.process：进程名。
2.data in请求数据大小。
3.packets in请求数据包大小。
4.data out发送数据大小。
5.packets out发送数据包大小。
6.duplicate Data Recv重传数据大小。
7.out-of-Order data传输失败数据大小。
8.retransmissions网络重传次数。
2.选择Connections
这个选项把所有的网络请求发生的数据交互明细都打印出来可以让我们一目了然的发现数据来自哪里，到哪里去，大小是多少，帧率是多少等信息。
相比Processes选项Connections选项多出了
1.local代表本地访问地址。
2.remote远程服务地址。
3.shortest Roundtrip：最短往返时间。
4.avg. Roundtrip：平均往返时间。
3.选择interfaces
interfaces代表在用户层面上的手机的网络使用情况，其中Interface选项代表网络环境，Connections代表总体连接次数其他选项和以上意义相同。
根据以上三个选项的不同信息我们就可以全面系统的掌握我们的App和用户当前手机的网络使用情况。
小结：整理总结关于优化部分实在有限，如上仅供各位参考.另外Instruments确实是把分析代码利器.目前没有任何一个第三方工具可以去替代.推荐各位使用.