Xcodejsonphp登录技巧_高德APP启动耗时剖析与优化实践iOS篇

（文中配图均为多才多艺的技能哥哥手绘）

启动阶段性能多维度剖析

要优化，首先要做到的是对启动阶段的各个性能纬度做剖析，包括主线程耗时、CPU、内存、I/O、网络。
这样才能更加全面的节制启动阶段的开销，找出不合理的方法调用。

启动越快，更多的方法调用就该当做成按需实行，将启动压力分摊，只留下那些启动后方法都会依赖的方法和库的初始化，比如网络库、Crash库等。
而剩下那些须要预加载的功能可以放到启动阶段后再实行。

启动有哪几种类型，有哪些阶段呢？

启动类型分为：

剖析阶段一样平常都是针对Cold类型进行剖析，目的便是要让测试环境稳定。
为了稳定测试环境，有时还须要找些稳定的机型，对付iOS来说iPhone7性能中等，稳定性也不错就很适宜，Android的Vivo系列也相对稳定，华为和小米系列数据颠簸就比较大。

除了机型外，掌握测试机温度也很主要，一旦温度过高系统还会降频实行，影响测试数据。
有时候还会设置翱翔模式采取Mock网络要求的办法来减少不稳定的网络影响测试数据。
最好是重启退却撤退iCloud账号，放置一段韶光再测，更加准确些。

理解启动阶段的目的便是聚焦范围，从用户体验上来确定哪个阶段要快，以便能够让用户可视和响运用户操作的韶光更快。

大略来说iOS启动分为加载Mach-O和运行时初始化过程，加载Mach-O会先判断加载的文件是不是Mach-O，通过文件第一个字节，也叫魔数来判断，当是下面四种时可以剖断是Mach-O文件：

Mach-O紧张分为：

确定是Mach-O后，内核会fork一个进程，execve开始加载。
检讨Mach-O Header。
随后加载dyld和程序到Load Command地址空间。
通过 dyld_stub_binder开始实行dyld，dyld会进行rebase、binding、lazy binding、导出符号，也可以通过DYLD_INSERT_LIBRARIES进行hook。

dyld_stub_binder给偏移量到dyld阐明分外字节码Segment中，也便是真实地址，把真实地址写入到la_symbol_ptr里，跳转时通过stub的jump指令跳转到真实地址。
dyld加载所有依赖库，将动态库导出的trie构造符号实行符号绑定，也便是non lazybinding，绑定解析其他模块功能和数据引用过程，便是导入符号。

Trie也叫数字树或前缀树，是一种搜索树。
查找繁芜度O(m)，m是字符串的长度。
和散列表比较，散列最差繁芜度是O(N)，一样平常都是 O(1)，用 O(m)韶光评估 hash。
散列缺陷是会分配一大块内存，内容越多所占内存越大。
Trie不仅查找快，插入和删除都很快，适宜存储预测性文本或自动完成词典。

为了进一步优化所占空间，可以将Trie这种树形的确定性有限自动机压缩成确定性非循环有限状态自动体（DAFSA），其空间小，做法是会压缩相同分支。

对付更大内容，还可以做更进一步的优化，比如利用字母缩减的实现技能，把原来的字符串重新阐明为较长的字符串；利用单链式列表，节点设计为由符号、子节点、下一个节点来表示；将字母表数组存储为代表ASCII字母表的256位的位图。

只管Trie对付性能会做很多优化，但是符号过多依然会增加性能花费，对付动态库导出的符号不宜太多，只管即便保持公共符号少，私有符号集丰富。
这样掩护起来也方便，版本兼容性也好，还能优化动态加载程序到进程的韶光。

然后实行attribute的constructor函数。
举个例子：

#include <stdio.h>__attribute__((constructor))static void prepare() { printf("%s\n", "prepare");}__attribute__((destructor))static void end() { printf("%s\n", "end");}void showHeader() { printf("%s\n", "header");}

运行结果：

ming@mingdeMacBook-Pro macho_demo % ./main "hi"preparehiend

运行时初始化过程分为：

也便是说对启动阶段的剖析以viewDidAppear为截止。
这次优化之前已经对Application初始化之前做过优化，效果并不明显，没有实质的提高，以是这次紧张针对Application初始化到viewDidAppear这个阶段各个性能多纬度进行剖析。

工具的选择实在目前看来是很多的，Apple供应的System Trace会供应全面系统的行为，可以显示底层系统线程和内存调度情形，剖析锁、线程、内存、系统调用等问题。
总的来说，通过System Trace能清楚知道每时每刻APP对系统资源的利用情形。

System Trace能查看线程的状态，可以理解高优线程利用相对付CPU数量是否合理，可以看到线程在实行、挂起、高下文切换、被打断还是被抢占的情形。
虚拟内存利用产生的耗时也能看到，比如分配物理内存，内存解压缩，无缓存时进行缓存的耗时等。
乃至是发热情形也能看到。

System Trace还供应手动打点进行信息显式，在你的代码中导入sys/kdebug_signpost.h后，配对kdebug_signpost_start和kdebug_signpost_end就可以了。
这两个方法有五个参数，第一个是id，末了一个是颜色，中间都是预留字段。

Xcode11开始XCTest还供应了丈量性能的Api。
苹果在2019年WWDC启动优化专题：

https://developer.apple.com/videos/play/wwdc2019/423/

也先容了Instruments里的最新模板App launch如何剖析启念头能。
但是要想达到对启动数据进行留存取均值、Diff、过滤、关联剖析等自动化操作，App launch目前还没法做到。

下面针对主线程耗时、CPU、网络、内存、I/O 等多维度进行剖析：

主线程耗时

多个纬度性能剖析中最主要、终极用户体感到的是主线程耗时剖析。
对主线程方法耗时可以直策应用Massier，这是everettjf开拓的一个Objective-C方法跟踪工具：

https://everettjf.github.io/2019/05/06/messier/

天生trace json进行剖析，或者参看这个代码

GCDFetchFeed/SMCallTraceCore.c at master · ming1016/GCDFetchFeed · GitHub

https://github.com/ming1016/GCDFetchFeed/blob/master/GCDFetchFeed/GCDFetchFeed/Lib/SMLagMonitor/SMCallTraceCore.c

自己手动hook objc_msgSend天生一份Objective-C方法耗时数据进行剖析。
还有种插桩办法，可以解析IR（加快编译速率），然后在每个方法前后插入耗时统计函数。

文章后面我会着重先容如何开拓工具进一步剖析这份数据，以达到监控启动阶段方法耗时的目的。

hook所有的方法调用，对详细剖析时很有用，不过对付全体启动韶光影响很大，要想获取启动每个阶段更准确的韶光花费还须要依赖手动埋点。

为了更好的剖析启动耗时问题，手动埋点也会埋的越来越多，也会影响启动韶光精确度，特殊是当团队很多，模块很多时，问题会突出。
但是每个团队在排查启动耗时每每只会关注自己或干系某几个模块的剖析，基于此，可以把不同模块埋点分组，灵巧组合，这样就可以照顾到多种需求了。

为什么剖析启动慢除了剖析主线程方法耗时外，还要剖析其它纬度的性能呢？

我们先看看启动慢的表现，启动慢意味着界面相应慢、网络慢（数据量大、要求数多）、CPU超负荷降频（并行任务多、运算多），可以看出影响启动的成分很多，还须要全面考虑。

对付CPU来说，WWDC的

What’s New in Energy Debugging - WWDC 2018 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2018/228/

先容了用Energy Log来查CPU耗电，当前台三分钟或后台一分钟CPU线程连续占用80%以上就剖断为耗电，同时记录耗电线程堆栈供剖析。
还有一个MetrickKit专门用来网络电源和性能统计数据，每24小时就会对网络的数据进行汇总上报，Mattt在NShipster网站上也发了篇文章专门进行先容：

https://nshipster.com/metrickit/

那么，CPU的详细利用情形如何获取呢？也便是说哪个方法用了多少CPU。

有好几种获取详细CPU利用情形的方法。
线程是打算机资源调度和分配的基本单位。
CPU利用情形会提现到线程这样的基本单位上。
task_theads的act_list数组包含所有线程，利用thread_info的接口可以返回线程的基本信息，这些信息定义在thread_basic_info_t构造体中。
这个构造体内的信息包含了线程运行韶光、运行状态以及调度优先级，个中也包含了CPU利用信息cpu_usage。

获取办法参看：

objective c - Get detailed iOS CPU usage with different states - Stack Overflow

https://stackoverflow.com/questions/43866416/get-detailed-ios-cpu-usage-with-different-states

GT GitHub - Tencent/GT

https://github.com/Tencent/GT

也有获取CPU的代码。

整体CPU占用率可以通过host_statistics函数取到host_cpu_load_info，个中cpu_ticks数组是CPU运行的时钟脉冲数量。
通过cpu_ticks数组里的状态，可以分别获取CPU_STATE_USER、CPU_STATE_NICE、CPU_STATE_SYSTEM这三个表示利用中的状态，除以整体CPU就可以取到CPU的占比。

通过NSProcessInfo的activeProcessorCount还可以得到CPU的核数。
线上数据剖析时会创造相同机型和系统的手机，性能表现却截然不同，这是由于手机过热或者电池损耗过大后系统降落了CPU频率所致。

以是，如果取得CPU频率后也可以针对那些降频的手机来进行针对性的优化，以担保流畅体验。
获取办法可以参考：

https://github.com/zenny-chen/CPU-Dasher-for-iOS

要想获取APP真实的内存利用情形可以参看WebKit的源码：

https://github.com/WebKit/webkit/blob/52bc6f0a96a062cb0eb76e9a81497183dc87c268/Source/WTF/wtf/cocoa/MemoryFootprintCocoa.cpp

JetSam会判断APP利用内存情形，超出阈值就会杀去世APP，JetSam获取阈值的代码在这里：

https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/bsd/kern/kern_memorystatus.c

全体设备物理内存大小可以通过NSProcessInfo的physicalMemory来获取。

对付网络监控可以利用Fishhook这样的工具Hook网络底层库CFNetwork。
网络的情形比较繁芜，以是须要定些和韶光干系的关键的指标，指标如下：

有了这些指标才能够有助于更好的剖析网络问题。
启动阶段的网络要求是非常多的，以是HTTP的性能是非常要把稳的。
以下是WWDC网络干系的Session：

Your App and Next Generation Networks - WWDC 2015 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2015/719/

Networking with NSURLSession - WWDC 2015 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2015/711/

Networking for the Modern Internet - WWDC 2016 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2016/714/

Advances in Networking, Part 1 - WWDC 2017 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2017/707/

Advances in Networking, Part 2 - WWDC 2017 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2017/709/

Optimizing Your App for Today’s Internet - WWDC 2018 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2018/714/

对付I/O可以利用

Frida • A world-class dynamic instrumentation framework | Inject JavaScript to explore native apps on Windows, macOS, GNU/Linux, iOS, Android, and QNX

https://www.frida.re/

这种动态二进制插桩技能，在程序运行时去插入自定义代码获取I/O的耗时和处理的数据大小等数据。
Frida还能够在其它平台利用。

关于多维度剖析更多的资料可以看看历届WWDC的先容。
下面我列下16年来 WWDC关于启动优化的Session，每场都很精彩。

Using Time Profiler in Instruments - WWDC 2016 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2016/418/

Optimizing I/O for Performance and Battery Life - WWDC 2016 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2016/719/

Optimizing App Startup Time - WWDC 2016 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2016/406/

App Startup Time: Past, Present, and Future - WWDC 2017 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2017/413/

Practical Approaches to Great App Performance - WWDC 2018 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2018/407/

Optimizing App Launch - WWDC 2019 - Videos - Apple Developer

https://developer.apple.com/videos/play/wwdc2019/423/

延后任务管理

经由前面所说的对主线程耗时方法和各个纬度性能剖析后，对付那些剖析出来没必要在启动阶段实行的方法，可以做成按需或延后实行。

任务延后的处理不能粗犷的一口气在启动完成后在主线程一起实行，那样用户仅仅只是看到了页面，依然没法相应操作。
那该怎么做呢？套路一样平常是这样，创建四个行列步队，分别是：

有依赖关系的任务可以放到异步串行行列步队中实行。
异步并行行列步队可以分组实行，比如利用dispatch_group，然后对每组任务数量进行限定，避免CPU、线程和内存瞬时激增影响主线程用户操作，定义有限数量的串行行列步队，每个串行行列步队做特定的事情，这样也能够避免性能花费短韶光溘然暴涨引起无法响运用户操作。
利用dispatch_semaphore_t在旗子暗记量壅塞主行列步队时随意马虎涌现优先级反转，须要减少利用，确保QoS传播。
可以用dispatch group替代，性能一样，功能不差。
异步编程可以直接GCD接口来写，也可以利用阿里的协程框架

coobjc GitHub - alibaba/coobjc

https://github.com/alibaba/coobjc

闲时行列步队实现办法是监听主线程runloop状态，在kCFRunLoopBeforeWaiting时开始实行闲时行列步队里的任务，在kCFRunLoopAfterWaiting时停滞。

优化后如何保持？

攻易守难，就像刚到新团队时将包大小减少了48兆，但是一年多一贯能够守住，除了决心还须要有手段。
对付启动优化来说，将各个性能纬度通过监控的办法盯住是必要的，但是创造问题后快速、便捷的定位到问题还是须要找些打破口。
我的思路是将启动阶段方法耗时多的按照韶光线一条一条排出来，每条包括方法名、方法层级、所属类、所属模块、掩护人。
考虑到便捷性，最好还能方便的查看方法代码内容。

接下来我通过开拓一个工具，详细先容下怎么实现这样的效果。

如前面所说在输出一份Chrome trace规范的方法耗时json后，先要解析这份数据。
这份json数据类似下面的样子：

{"name":"[SMVeilweaa]upVeilState:","cat":"catname","ph":"B","pid":2381,"tid":0,"ts":21},{"name":"[SMVeilweaa]tatLaunchState:","cat":"catname","ph":"B","pid":2381,"tid":0,"ts":4557},{"name":"[SMVeilweaa]tatTimeStamp:state:","cat":"catname","ph":"B","pid":2381,"tid":0,"ts":4686},{"name":"[SMVeilweaa]tatTimeStamp:state:","cat":"catname","ph":"E","pid":2381,"tid":0,"ts":4727},{"name":"[SMVeilweaa]tatLaunchState:","cat":"catname","ph":"E","pid":2381,"tid":0,"ts":5732},{"name":"[SMVeilweaa]upVeilState:","cat":"catname","ph":"E","pid":2381,"tid":0,"ts":5815},…

通过Chrome的Trace-Viewer可以天生一个火焰图。
个中name字段包含了类、方法和参数的信息，cat字段可以加入其它性能数据，ph为B表示方法开始，为E表示方法结束，ts字段表示。

很多工程在启动阶段会实行大量方法，很多方法耗时很少，可以过滤那些小于10毫秒的方法，让剖析更加聚焦。

耗时的高低也做了颜色的区分。
外部耗时指的是子方法以外系统或没源码的三方方法的耗时，规则是父方法调用的耗时减去其子方法总耗时。

目前为止通过过滤耗时少的方法调用，可以更随意马虎创造问题方法。
但是，有些方法单次实行耗时不多，但是会实行很多次，累加耗时会大，这样的情形也须要表示在展示页面里。
其余外部耗时高时或者碰到自己不理解的方法时，是须要到工程源码里去搜索对应的方法源码进行剖析的，有的方法名很通用时还须要花大量韶光去过滤无用信息。

因此接下来还须要做两件事情，首先累加方法调用次数和耗时，表示在展示页面中，另一个是从工程中获取方法源码能够在展示页面中进行点击显示。

完全思路如下图：

展示方法源码

在页面上展示源码须要先解析.xcworkspace文件，通过.xcworkspace文件取到工程里所有的.xcodeproj文件。
剖析.xcodeproj文件取到所有.m和.mm源码文件路径，解析源码，取到方法的源码内容进行展示。

解析.xcworkspace

开.xcworkspace，可以看到这个包内紧张文件是contents.xcworkspacedata。
内容是一个xml：

<?xml version="1.0" encoding="UTF-8"?><Workspace version = "1.0"> <FileRef location = "group:GCDFetchFeed.xcodeproj"> </FileRef> <FileRef location = "group:Pods/Pods.xcodeproj"> </FileRef></Workspace>

解析.xcodeproj

通过XML的解析可以获取FileRef节点内容，xcodeproj的文件路径就在FileRef节点的location属性里。
每个xcodeproj文件里会有project工程的源码文件。
为了能够获取方法的源码进行展示，那么就先要取出所有project工程里包含的源文件的路径。

xcodeproj的文件内容看起来大概是下面的样子。

实在内容还有很多，须要一个个解析出来。

考虑到xcodeproj里的注释很多，也都很有用，因此会多设计些构造来保存值和注释。
思路是根据XcodeprojNode的类型来判断下一级是key value构造还是array构造。
如果XcodeprojNode的类型是dicStart表示下级是key value构造。
如果类型是arrStart便是array构造。
当碰到类型是dicEnd，同时和最初dicStart是同级时，递归下一级树构造。
而arrEnd不用递归，xcodeproj里的array只有值类型的数据。

有了基本节点树构造往后就可以设计xcodeproj里各个section的构造。
紧张有以下的section：

得到section构造Xcodeproj后，就可以开始剖析所有源文件的路径了。
根据前面列出的section的解释，PBXGroup包含了所有文件夹和文件的关系，Xcodeproj的pbxGroup字段的key是文件夹，值是文件凑集，因此可以设计一个构造体XcodeprojSourceNode用来存储文件夹和文件关系。

接下来须要取得完全的文件路径。
通过recusiveFatherPaths函数获取文件夹路径。
这里须要把稳的是须要处理 ../ 这种文件夹路径符。

解析.m .mm文件

对Objective-C解析可以参考LLVM，这里只须要找到每个方法对应的源码，以是自己也可以实现。
分词前先看看LLVM是怎么定义token的。
定义文件在这里：

https://opensource.apple.com/source/lldb/lldb-69/llvm/tools/clang/include/clang/Basic/TokenKinds.def

根据这个定义我设计了token的构造体，主体部分如下：

// 切割符号 [](){}.&=+-<>~!/%^|?:;,#@public enum OCTK { case unknown // 不是 token case eof // 文件结束 case eod // 行结束 case codeCompletion // Code completion marker case cxxDefaultargEnd // C++ default argument end marker case comment // 注释 case identifier // 比如 abcde123 case numericConstant(OCTkNumericConstant) // 整型、浮点 0x123，阐明打算时用，剖析代码时可不用 case charConstant // ‘a’ case stringLiteral // “foo” case wideStringLiteral // L”foo” case angleStringLiteral // <foo> 待处理须要考虑作为小于符号的问题 // 标准定义部分 // 标点符号 case punctuators(OCTkPunctuators) // 关键字 case keyword(OCTKKeyword) // @关键字 case atKeyword(OCTKAtKeyword)}

完全的定义在这里：

MethodTraceAnalyze/ParseOCTokensDefine.swift

https://github.com/ming1016/MethodTraceAnalyze/blob/master/MethodTraceAnalyze/OC/ParseOCTokensDefine.swift

分词过程可以参看LLVM的实现：

clang: lib/Lex/Lexer.cpp Source File

http://clang.llvm.org/doxygen/Lexer_8cpp_source.html

我在处理分词时紧张是按照分隔符逐一对应处理，针对代码注释和字符串进行了分外处理，一个注释一个token，一个完全字符串一个token。
我分词实当代码：

MethodTraceAnalyze/ParseOCTokens.swift

https://github.com/ming1016/MethodTraceAnalyze/blob/master/MethodTraceAnalyze/OC/ParseOCTokens.swift

由于只要取到类名和方法里的源码，以是语法剖析时，只须要对类定义和方法定义做解析就可以，语法树中节点设计：

// OC 语法树节点public struct OCNode { public var type: OCNodeType public var subNodes: [OCNode] public var identifier: String // 标识 public var lineRange: (Int,Int) // 行范围 public var source: String // 对应代码}// 节点类型public enum OCNodeType { case `default` case root case `import` case `class` case method}

个中lineRange记录了方法所在文件的行范围，这样就能够从文件中取出代码，并记录在source字段中。

解析语法树须要先定义好解析过程的不同状态：

private enum RState { case normal case eod // 换行 case methodStart // 方法开始 case methodReturnEnd // 方法返回类型结束 case methodNameEnd // 方法名结束 case methodParamStart // 方法参数开始 case methodContentStart // 方法内容开始 case methodParamTypeStart // 方法参数类型开始 case methodParamTypeEnd // 方法参数类型结束 case methodParamEnd // 方法参数结束 case methodParamNameEnd // 方法参数名结束 case at // @ case atImplementation // @implementation case normalBlock // oc方法外部的 block {}，用于 c 方法}

完全解析出方法所属类、方法行范围的代码在这里：

MethodTraceAnalyze/ParseOCNodes.swift

https://github.com/ming1016/MethodTraceAnalyze/blob/master/MethodTraceAnalyze/OC/ParseOCNodes.swift

解析.m和.mm文件，一个一个串行解的话，对付大工程，每次解的速率很难接管，以是采取并行办法去读取解析多个文件。
经由测试，创造每组在60个以上时能够最大利用我机器（2.5 GHz双核Intel Core i7）的CPU，内存占用只有60M，一万多.m文件的工程大概2分半能解完。

利用的是dispatch group的wait，担保并行的一组完成再进入下一组。

现在有了每个方法对应的源码，接下来就可以和前面trace的方法对应上。
页面展示只须要写段js就能够掌握点击时展示对应方法的源码。

页面展示

在进行HTML页面展示前，须要将代码里的换行和空格更换成HTML里的对应的和 。

let allNodes = ParseOC.ocNodes(workspacePath: “/Users/ming/Downloads/GCDFetchFeed/GCDFetchFeed/GCDFetchFeed.xcworkspace”)var sourceDic = [String:String]()for aNode in allNodes { sourceDic[aNode.identifier] = aNode.source.replacingOccurrences(of: “\n”, with: “</br>”).replacingOccurrences(of: “ “, with: “ ”)}

用p标签作为源码展示的标签，方法实行顺序的编号加方法名作为p标签的id，然后用display: none; 将p标签隐蔽。
方法名用a标签，click属性实行一段js代码，当a标签点击时能够显示方法对应的代码。
这段js代码如下：

function sourceShowHidden(sourceIdName) { var sourceCode = document.getElementById(sourceIdName); sourceCode.style.display = “block”;}

终极效果如下图：

将动态剖析和静态剖析进行了却合，后面可以通过不同版本进行比拟，创造哪些方法的代码实现改变了，能展示在页面上。
还可以进一步静态剖析出哪些方法会调用到I/O函数、起新线程、新行列步队等，然后展示到页面上，方便剖析。

读到末了，可以看到这个方法剖析工具并没有用任何一个轮子，实在有些是可以利用现有轮子的，比如json、xml、xcodeproj、Objective-C语法剖析等，之以是没有用是由于不同轮子利用的措辞和技能差异较大，当格式更新时如果利用的单个轮子没有更新会影响全体工具。
开拓这个工具紧张事情是在解析上，以是利用自有解析技能也能够让所做的功能更聚焦，不做没用的功能，减少代码掩护量，所要解析格式更新后，也能够自主去更新解析办法。
更主要的一点是可以亲手打仗下这些格式的语法设计。

结语

本文小结了启动优化的技能手段，总的来说，对启动进行优化的决心的主要程度是远大于技能手段的，决定着是否能够优化的更多。
技能手段有很多，我以为手段的好坏差异只是在效率上，最差的情形全用手动一个个去查耗时也是能够解题的。