关于APP优化，从wwdc内容来看，主要是关注于APP启动时间，CPU耗时操作，电量三个方面
对于启动时间，wwdc2018里面提到app启动动画时间为600ms，其中100ms的时间用来加载我们的动态库，以及一些静态的对象的初始化，剩余的500ms我们可以进行第一屏展示的准备，所以我们的启动操作最好控制在500ms以内
启动分为三种，冷启动，热启动，暖启动。冷启动是第一次安装App后的第一次启动，热启动是程序从后台再次进入前台的启动，这里一般不会有性能问题，暖启动是我们最关心的，因为我们可以对其进行一些操作，来提高暖启动的时间。
关于CPU耗时操作，wwdc提到，大多数代码调用会有副作用，所以要关注你的代码调用是不是造成了不必要的副作用
另外如果CPU占用过高，能延时的操作尽量延时操作，加载读取数据尽量只读取最少量的数据（数据够用就可以了），比如photo中只加载当前要显示的图片，同时只加载低分辨率图片，对于更新UI等操作，如果可以批量更新，就要批量更新，比如tableview的batchupdate方法。
使用适量的view，如果view太多，则应当适当的减少view，如wwdc中提到的photo引用中时刻从当前到年的转换，将每月的低分辨率的图片绘制到同一张图上，同时记录绘制的位置信息与图片的索引，从而达到减少view的目的
另外我们要让我们的CPU耗时可控，也就是优化为常量时间
对于一次的计算结果，如果可以共享我们应当避免多次计算，这在我们应用中用的比较多的场景就是缓存cell的布局信息，避免多次计算
另外对于监听，使用NSNotification，KVO，delegate，block，我们应该尽量避免使用KVO，使用KVO的好处是，信息更改时就通过runloop自动发出通知进行操作，但是很多情况下，我们并不需要这样做，如果我们对实时性要求并不高，我们不需要根据每次更新都去改变，只需要保证最后一次的改变生效就可以，这时我们最好延迟的去通知最后一次的改变，因为每次更改都产生副作用，对我们的CPU进行了无谓的消耗
对于数据记录，我们应当优先使用对象object，或者使用struct，而不是使用NSDictionary，因为对于很多的小对象，进行hash操作很耗时

我们优化APP的操作是怎样的。
首先我们应该尝试去复现，找到复现的条件，模拟条件，保证可以复现操作
其次，我们通过profile去测试，记录，分析
最后，我们去解决，解决问题，我们应当采用直接简单的方式。
第一，我们应该考虑直接去掉有问题的代码。如果去掉后，对实现没有任何影响问题就解决了。
第二，如果不能直接去掉，我们细分操作，减少副作用，能不调用的就不调用，能延迟加载的就延迟加载，能批量操作就批量操作，能共享数据的就共享数据
第三，都不行的话，我们要从头了解业务需求，尝试重新设计

Instrument每1ms进行一次记录，所以我们在Instrument中看到的最小耗时都是1ms，在Instrument里面每次记录好像称为Sample
Instrument中有很多过滤器，如Separate by Thread，该选项是默认勾选的，选择该选项时，我们的方法列表会按Thread id进行分割，而不选中时，方法列表将按调用入口进行分割，这适合GCD的使用情况
我们在查找耗时操作时，最重要的就是聚焦，所以对于我们不关心的操作，我们应该隐藏我们不关心的操作，比如一些系统库的操作，或者第三方库的操作，我们无法去修改的代码，我们可以通过，右键然后charge...to caller的选项，charge...to...表示记在谁的账上，这样我们选中的操作，就被隐藏不再干扰我们的视野，同时她的耗时会记录在他的调用者身上。
另外一种聚焦操作，就是屏蔽极细颗粒的操作，也就是屏蔽耗时极少的操作，这个可以通过Call Tree Constraints选项，前面说过Instrument的每次记录就是一个Sample，所以如果我们设置了Sample的范围，就可以将耗时集中在这个区间，比如我们选择的范围是（10～+∞），那么小于10ms的操作将不再展示出来。

Time Profile

wwdc中讲的比较多的一个，可以在苹果开发者，wwdc全部视频搜索instrument去看一下，下面的文章是对wwdc2018和wwdc2019里面两期内容的总结
https://www.jianshu.com/p/108c09e814de
1、操作的副作用可能造成耗时
2、不必要的反复执行造成的耗时
3、本身是一个耗时操作

Allocations

https://developer.apple.com/library/archive/technotes/tn2434/_index.html
Consider ways to reduce this allocation.
1、Remove the allocation 不必要的初始化
2、Reduce the number of allocations 减少初始化的数量，比如可见的只有一个view，我们没必要把所有的一起初始化
3、Reduce the size of the allocation，减少初始化的体积

Instrument help

https://help.apple.com/instruments/mac/current/#/dev7b09c84f5

Diggest

trick

使用Xcode Debug Navigator
使用view->zoom, view->track来放大缩小我们的track，使我们注意力集中
使用view->clear Inspection range关闭选中区

When viewing a call tree, many instruments include options to hide system calls and invert the call tree. These options are found in the Call Tree area under Display Options in the inspector pane. Hiding system calls allows you to quickly filter for calls made by your app. Inverting the call tree allows you to see the heaviest calls first.

Time Profiler

Track CPU core and thread use

Counters

Look for performance bottlenecks
Performance monitor counters (PMCs) are hardware registers that measure events occurring in the processor. They help find bottlenecks in your app by identifying an excessive number of events of a particular type. For example, a high number of conditional branch instructions may indicate a section of logic that, if rearranged, might lower the number of branches required. PMC events bring these issues to light, but it is up to you to match them to your code and decide how they will help you improve your app’s performance. The Counters profiling template uses the Counters instrument to track PMC events.

Activity Monitor：Use Activity Monitor to track overall network and disk use

The Activity Monitor profiling template uses the Activity Monitor instrument to track overall system activity over time, including CPU, memory, network, and disk. By default, the Activity Monitor template doesn’t display network or disk activity in the timeline pane. However, you can manually enable the display of these statistics.

Network ：Monitor network connections of an iOS app

The Network profiling template uses the Connections instrument to analyze your iOS app’s TCP/IP and UDP/IP connections.

File Activity：Monitor disk use

The File Activity profiling template uses the File Activity, Reads/Writes, File Attributes, and Directory I/O instruments to watch your macOS app’s disk use.

Allocations

This instrument measures heap memory usage and tracks allocations, including specific object allocations by class.

Leaks

check for leaks—memory that has been allocated to objects that are no longer referenced and reachable.

Retain has been called on an object without a corresponding release call when the object is no longer referenced.

An object has been allocated and initialized with APIs that don’t cause the object to autorelease.

If a leak isn’t an object, you may be calling an API that assumes ownership of a malloc-created memory block, and you are missing a corresponding call to free().

Zombies

The Zombies profiling template uses the Allocations instrument to measure general memory usage in your app, with a focus on the detection of overreleased “zombie” objects—that is, objects that are called after they’ve been released and no longer exist.

An object has already been released (or autoreleased), and your app tries to release it again.

An object hasn’t been retained when it should have been.

Some other call is made to an object after it has been released.

Energy Log

The Energy Usage instrument indicates a level from 0 to 20, indicating how much energy your app is using at any given time. These numbers are subjective. If your app’s energy usage level is occasionally high, it doesn’t necessarily mean that your app has a problem. Your app may simply require more energy for some of the tasks it performs. For example, it may use the GPS while performing complex network operations. This is valid energy use. Look for spikes or areas of high energy use that are unexpected or that could be performed at more optimal times.

使用手机开发者模式监测Energy，然后使用Instrument导入

Loggin & signposts