您好,欢迎来到一站式众包服务平台-威客牛网
当前位置:威客牛首页 > 知识百科 > IT软件 > App开发 > iOS 性能优化的方案

iOS 性能优化的方案

2022-12-04作者:网友投稿
首先这是一个很宏大的题目,我也只能窥其一斑。只说说自己的一些浅见和反思。因为之前有一段时间,在面对说要技术方案优化的时候,自己也有过一段不知所措的时期。后来才开始慢慢觉得自己找到点门道了,这片文章也算是自己的一个总结吧。以下是赢在威客网小编整理的iOS 性能优化的方案。

什么是优化

首先我们先破题,来谈谈“优化”这个事情。通常情况下,我们说到优化的时候,往往会伴随着对之前系统的吐槽。或是不好用,或是性能低,或是用起来很麻烦。巴拉巴拉。是的,当我们对原先的系统有槽点的时候,我们会谈到“优化”。而“优化”的前提也是,之前已经有过一个东西存在,而且真对目前的场景应景不再适合。这个是有需要对原有系统进行调整,以满足当前的场景与需求。那么所谓优化即是:对原有系统进行有目的的改造。

好吧,这听起来虽然说了什么,但其实什么都没说。因为这是一句大实话。

but,我们仔细分析一下,我们要进行优化必须能够:

对原有系统的问题有所了解

了解目前场景和需求

有目的性的改造原有系统

我们来说一个我们通常会遇到的例子,也是在面试的时候会遇到的问题–“UItableView的性能优化”。其实每次有人问我这个问题,我内心都有千万只“草泥马”奔腾而过。没有具体的问题场景,只单单跑出来这样一个问题。是可以和他扯什么图片内存缓存了,避免圆角的使用了,预渲染,预加载了之类的东西。但是这些东西,真的对于在解决他们TableView卡顿的问题有效吗,不见得。套用《安娜卡列尼娜》一句话:

流畅的UItableView都是相似的,不流畅的UItableView各有各的不幸。

好了,吐槽到此为止。吐槽的目的是为了说明一点,你要进行优化,必须有一个特定的场景。在一个受限的范围内进行优化,因为这样目的是可控的。漫无边际的优化,和别人基于方法论的建议之类的东西,不一定对当前的问题有帮助。

比如,之前我们在做的一个社交类的App中,首页使用了UItableView,老板说怎么用着这么卡顿。然后我们就开始了“优化”。

首先,我们知道我们要优化的是第一个tab的tableview的滑动效率的问题。那总得有个监控的指标吧。对于程序猿来说,感觉这个不卡了,或者感觉这个卡,这个东西太模糊了。无法衡量啊。所以一定要量化。对于界面来讲就是大家常说的FPS,每秒帧率。于是我们测量了一下帧率,平均下来是25FPS。ou my god!的确是有点卡。

然后我们知道对于ios来说如果能达到60FPS,那界面绝对不会有卡顿的感觉了。而很少有应用能达到这个水准。那么我们给自己设置了一个目标45FPS。btw,这个目标只是个阶段性目标。

好了下面的过程,就是朝着这个目标前进了。当然我们知道,造成FPS较低的原因,一般都是主线程做了太多的事情,导致帧率降低。这只是个大方向。而对我们来讲,我们需要精准的知道,主线程都做了些什么事情,导致帧率降低。

首先,我们发现的是,读取图片IO的过程发生在了主线程。IO过程一般是比较耗时的,于是我们像把该过程移到了后台线程中处理。发现帧率能够提高到33FPS,这还不够啊。革命尚未完成,同志仍需努力。

之后的过程中,我们把布局预处理,还有圆角,数据预加载之类的事情做上去之后,终于基本达到45。阶段性目标完成。

好了这是一个优化的例子:始于发现问题,止于目标达成。而重要的是其过程,描述问题!!!!

分析问题 (定性or定量)

其实,我一直比较坚信一句话:当你能够准确的描述一个问题的时候,你到解决问题就没剩几步了。比如刚才说的卡顿的问题,我们当时是这么描述的:图片读取发生了主线程,主线程中有一部分CPU片段用于文件读取和图片解码,造成主线程阻塞,从而导致帧率下降。当描述到这里的时候,解决方案就比较显而易见了,挪呗。搞到其他线程中之行。把主线程空出来。

而上面的这个描述还只是一个定性的描述分析。只是阐述了现象。虽然能够解决了一个问题,但是对整体问题的贡献有多大,也未可知。所以我们可以当时完全可以这样描述:我们图片缓存在文件系统的平均大小是1MB,其读取时间为10.7ms,图片格式为jpeg,解码一个1M的图片耗时是60ms,而我们知道60FPS,每帧给主线程用来处理任务的CPU时间为17.7S,也就说这个地方占用了大量CPU时间片来处理图片读与解码操作,从而造成了CPU阻塞,造成帧率没有达到60ms。

当我们使用定量的描述的时候,我们能够比较精确的知道,一个小问题,对于大问题来说到底意味着什么。而定量分析的方案中,当然包含了很多更多的细节信息,尤其是数据信息。这些也正是定量分析的优势所在。BUT,定量分析是一个非常耗时耗力的事情,你要拿到这么多的数据,你势必要付出很多时间,在采集这些数据上面。对于app开发来讲,除非公司给了足够的资源(尤其是时间),你才能像个研究者一样去采集这些数据,一般情况是,大概都会止步到定性分析这一步。其实这也是看具体问题而定了。

不过无论你是使用定性分析的方式还是定量分析的方式。我们的目标是为了找到能够准确表述问题的方式,并且定位问题,以求找到解决方案。而为了达到这个目的一般情况下我们可以使用两种方式:

你的编程功底和对iOS的了解程度都很深,那么完全可以从一些原理性的事情上去分析。我们称之为:逻辑分析法。

或许你的编程功底很深,或许很浅,或许你尝试分析而没有结果。那么可以使用改改代码试试的方法了。我们称之为:实验法。

逻辑分析法, 原理性分析

哈哈,套用马哲的一句话:事物是普遍联系的。既然是普遍联系的,不说必然存在因果,那么通过一定的逻辑分析。是可以找到他们之间的一些蛛丝马迹的关联的。这些关联或许可以解释一些什么。比如刚才卡顿的问题:原理就是主线程CPU被消耗过多,无法及时处理UI任务导致的。这只是一个例子。

我们进行逻辑分析的目的,是为了找到我们的某些代码和问题之间的因果性联系。就是说,我们能够明确知道造成UI卡顿的问题,就是因为IO的问题之类。这个话题说起来,比较深邃了。其中绝大部分实践的方法可以从《数理逻辑》这本书中找到。不过这是本讲数学的书,咱们得稍微换下脑子,把其中的定理,在编程中应用一下。因为我也只是意会了其中的某些东西,讲出来还没有那么功底。就只能麻烦各位自己去琢磨了。:)

实验法,Assume-Action-Response-Test-Assume

我称这个过称为AARTA。这是一个一直往复的过程,在分析的过程中,你得一次次的重复这个过程来找到真正问题的所在。其实,这个方法比较常应用在改BUG这个场景上。其实如果从广义上讲,按照上面咱们对技术优化的定义,改bug也算是一种优化。只不过这个场景比价特殊而已。当无法准确的分析原理,或者当前程序的复杂性过高(低内聚高耦合)已经超出人脑的计算能力范围的时候,那么就可以“猜”了。

(1)假设 assume

根据以往的经验来,设定一个和问题域相关的假设。比如UI卡顿的问题,你怀疑是不是因为图片的问题呢。那么现在就假设是图片的问题!

(2) 尝试进行修改 action

既然假设是图片的问题,那么就把UIImageView从Cell上删掉吧。

(3)看程序的反馈 Response

重新运行一遍程序,看一下程序运行的效果。FPS是否有所改善,而且改善的幅度有多大。

(4)Test

根据,程序的反馈和我们预先设定的目标来判断一下,当前改动是否满足了我们设计的目标。如果有,那么你大概就找到了问题的一个原因。如果没有那么进行下一步。

(5) 重新提出假设 Assume

既然不是图片的问题,那么会不会是其他事情上耗费了CPU呢。比如布局样式的计算。那么重新假设是局部样式的问题。在执行(2)过程。

所谓实验,即是大胆假设,小心取证,如此往复,以求终解。

监控

上面只是进行了一些方法论的探讨。但是有一件事情,是若要优化一定要做的。那就是“监控”。

监控是个非常重要的东西。

监控是个非常重要的东西。

监控是个非常重要的东西。

重要的事情说三遍。尤其是对于运行在生产环境的程序。这就像是一个体检,你得实时掌控程序的运行情况,知道问题出在了哪里,甚至有些时候知道:哎呀,出问题了。没有监控,程序一旦上线之后,就像脱缰的野马,跑到哪里,做了什么,你就是一头忙然了。突然有一天,老板说有人反馈咱们的app经常崩溃,当你没有crash监控,这个你都不知道从哪里查起。

而且,监控也是优化的数据来源。他能够通过数据的指标来非常直观的告诉你,程序哪里有问题,你优化之后,效果是怎样的。现在网上有很多这方面的服务提供出来,比如bugly之类的,甚至有些是APM(application performance manager),直接监控到程序的运行状态和性能。google一下,能搜出不少来。可以酌情,应用在自己开发的app中。

总结

说了半天,总结一下。优化是在可控的范围内有目的性的对现有程序的修改。一般可以使用逻辑分析法和实验法来定位、分析、描述问题。或者定性或者定量。无论哪种,要想优化,你得先建立起对自己app运行的监控体系。
免费查询商标注册