美文网首页
iOS性能优化

iOS性能优化

作者: 英俊神武 | 来源:发表于2018-06-26 14:05 被阅读0次

    性能问题的主要原因是什什么,原因有相同的,也有不不同的,但归根到底,不不外乎内存 使⽤用、代码效率、合适的策略略逻辑、代码质量量、安装包体积这⼀一类问题。 但从⽤用户体验的⻆角度去思考,当我们置身处地得把⾃自⼰己当做⽤用户去玩⼀一款应⽤用时候,那么都 会在意什什么呢?假如正在玩⼀一款⼿手游,⾸首先⼀一定不不希望玩着玩着突然闪退,然后就是不不希望 卡顿,其次就是耗电和耗流量量不不希望太严重,最后就是安装包希望能⼩小⼀一点。简单归类如下:
    快:使⽤用时避免出现卡顿,响应速度快,减少⽤用户等待的时间,满⾜足⽤用户期望。
    稳:不不要在⽤用户使⽤用过程中崩溃和⽆无响应。
    省:节省流量量和耗电,减少⽤用户使⽤用成本,避免使⽤用时导致⼿手机发烫。
    ⼩小:安装包⼩小可以降低⽤用户的安装成本。

    一、快 应⽤用启动慢,使⽤用时经常卡顿,是⾮非常影响⽤用户体验的,应该尽量量避免出现。卡顿的场景有 很多,按场景可以分为4类:UI 绘制、应⽤用启动、⻚页⾯面跳转、事件响应。引起卡顿的原因很 多,但不不管怎么样的原因和场景,最终都是通过设备屏幕上显示来达到⽤用户,归根到底就是 显示有问题,
    根据iOS 系统显示原理理可以看到,影响绘制的根本原因有以下两个⽅方⾯面: 1.绘制任务太重,绘制⼀一帧内容耗时太⻓长。
    2.主线程太忙,根据系统传递过来的 VSYNC 信号来时还没准备好数据导致丢帧。 绘制耗时太⻓长,有⼀一些⼯工具可以帮助我们定位问题。主线程太忙则需要注意了了,主线程关键 职责是处理理⽤用户交互,在屏幕上绘制像素,并进⾏行行加载显示相关的数据,所以特别需要避免 任何主线程的事情,这样应⽤用程序才能保持对⽤用户操作的即时响应。总结起来,主线程主要 做以下⼏几个⽅方⾯面⼯工作:
    1.UI ⽣生命周期控制
    2.系统事件处理理
    3.消息处理理
    4.界⾯面布局
    5.界⾯面绘制
    6.界⾯面刷新 除此之外,应该尽量量避免将其他处理理放在主线程中,特别复杂的数据计算和⽹网络请求等。

    二、稳 应⽤用的稳定性定义很宽泛,影响稳定性的原因很多,⽐比如内存使⽤用不不合理理、代码异常场景考 虑不不周全、代码逻辑不不合理理等,都会对应⽤用的稳定性造成影响。其中最常⻅见的两个场景是: Crash 和 ANR,这两个错误将会使得程序⽆无法使⽤用,⽐比较常⽤用的解决⽅方式如下: 1.提⾼高代码质量量。⽐比如开发期间的代码审核,看些代码设计逻辑,业务合理理性等。 2.代码静态扫描⼯工具。常⻅见⼯工具有Clang Static Analyzer、OCLint、Infer等等。 3.Crash监控。把⼀一些崩溃的信息,异常信息及时地记录下来,以便便后续分析解决。
    4.Crash上传机制。在Crash后,尽量量先保存⽇日志到本地,然后等下⼀一次⽹网络正常时再上传⽇日 志信息。

    三、省 在移动设备中,电池的重要性不不⾔言⽽而喻,没有电什什么都⼲干不不成。对于操作系统和设备开发商 来说,耗电优化⼀一致没有停⽌止,去追求更更⻓长的待机时间,⽽而对于⼀一款应⽤用来说,并不不是可以 忽略略电量量使⽤用问题,特别是那些被归为“电池杀⼿手”的应⽤用,最终的结果是被卸载。因此,应 ⽤用开发者在实现需求的同时,需要尽量量减少电量量的消耗。
    1.CPU
    不不论⽤用户是否正在直接使⽤用, CPU 都是应⽤用所使⽤用的主要硬件, 在后台操作和处理理推送通知 时, 应⽤用仍然会消耗 CPU 资源


    C27ED90547AA1F50F801C341C2FB1AE4.png

    应⽤用计算的越多,消耗的电量量越多.在完成相同的基本操作时, ⽼老老⼀一代的设备会消耗更更多的电 量量, 计算量量的消耗取决于不不同的因素

    2.网络 智能的⽹网络访问管理理可以让应⽤用响应的更更快,并有助于延⻓长电池寿命.在⽆无法访问⽹网络时,应该 推迟后续的⽹网络请求, 直到⽹网络连接恢复为⽌止. 此外,应避免在没有连接 WiFi 的情况下进⾏行行⾼高 宽带消耗的操作.⽐比如视频流, 众所周知, 蜂窝⽆无线系统(LTE,4G,3G等)对电量量的消耗远远⼤大于 WiFi信号, 根源在于 LTE 设备基于多输⼊入,多输出技术,使⽤用多个并发信号以维护两端的 LTE 链接,类似的,所有的蜂窝数据链接都会定期扫描以寻找更更强的信号. 因此:我们需要 1)在进⾏行行任何⽹网络操作之前,先检查合适的⽹网络连接是否可⽤用 2)持续监视⽹网络的可⽤用性,并在链接状态发⽣生变化时给与适当的反馈
    3.定位管理理器器和 GPS
    我们都知道定位服务是很耗电的,使⽤用 GPS 计算坐标需要确定两点信息:
    1)时间锁 每个 GPS 卫星每毫秒⼴广播唯⼀一⼀一个1023位随机数, 因⽽而数据传播速率是 1.024Mbit/s GPS 的接收芯⽚片必须正确的与卫星的时间锁槽对⻬齐
    2)频率锁 GPS 接收器器必须计算由接收器器与卫星的相对运动导致的多普勒勒偏移带来的信号误 差
    计算坐标会不不断的使⽤用 CPU 和 GPS 的硬件资源,因此他们会迅速的消耗电池电量量, 那么怎么 减少呢?
    1)关闭⽆无关紧要的特性
    判断何时需要跟踪位置的变化, 在需要跟踪的时候调⽤用 startUpdatingLocation⽅方法, ⽆无须跟 踪时调⽤用stopUpdatingLocation⽅方法. 当应⽤用在后台运⾏行行或⽤用户没有与别⼈人聊天时,也应该关闭位置跟踪,也就说说,浏览媒体库,查看 朋友列列表或调整应⽤用设置时, 都应该关闭位置跟踪
    2)只在必要时使⽤用⽹网络
    为了了提⾼高电量量的使⽤用效率, IOS 总是尽可能地保持⽆无线⽹网络关闭.当应⽤用需要建⽴立⽹网络连接时, IOS 会利利⽤用这个机会向后台应⽤用分享⽹网络会话, 以便便⼀一些低优先级能够被处理理, 如推送通知, 收取电⼦子邮件等 关键在于每当⽤用户建⽴立⽹网络连接时,⽹网络硬件都会在连接完成后多维持⼏几秒的活动时间.每次 集中的⽹网络通信都会消耗⼤大量量的电量量 要想减轻这个问题带来的危害,你的软件需要有所保留留的的使⽤用⽹网络.应该定期集中短暂的使 ⽤用⽹网络,⽽而不不是持续的保持着活动的数据流.只有这样,⽹网络硬件才有机会关闭

    4.屏幕
    屏幕⾮非常耗电, 屏幕越⼤大就越耗电.当然,如果你的应⽤用在前台运⾏行行且与⽤用户进⾏行行交互,则势必 会使⽤用屏幕并消耗电量量
    这⾥里里有⼀一些⽅方案可以优化屏幕的使⽤用:
    1)动画优化
    当应⽤用在前台时, 使⽤用动画, ⼀一旦应⽤用进⼊入了了后台,则⽴立即暂停动画.通常来说,你可以通过监听 UIApplicationWillResignActiveNotification或UIApplicationDIdEnterBackgroundNotification 的通知事件来暂停或停⽌止动画,也可以通过监听UIApplicationDidBecomeActiveNotification 的通知事件来恢复动画
    2)视频优化
    视频播放期间,最好保持屏幕常量量.可以使⽤用UIApplication对象的 idleTimerDisabled属性来实 现这个⽬目的.⼀一旦设置了了 YES, 他会阻⽌止屏幕休眠,从⽽而实现常亮. 与动画类似,你可以通过相应应⽤用的通知来释放和获取锁
    ⽤用户总是随身携带者⼿手机,所以编写省电的代码就格外重要, 毕竟⼿手机的移动电源并不不是随处 可⻅见, 在⽆无法降低任务复杂性时, 提供⼀一个对电池电量量保持敏敏感的⽅方案并在适当的时机提示⽤用 户, 会让⽤用户体验良好。

    四、⼩小

    应⽤用安装包⼤大⼩小对应⽤用使⽤用没有影响,但应⽤用的安装包越⼤大,⽤用户下载的⻔门槛越⾼高,特别是 在移动⽹网络情况下,⽤用户在下载应⽤用时,对安装包⼤大⼩小的要求更更⾼高,因此,减⼩小安装包⼤大⼩小 可以让更更多⽤用户愿意下载和体验产品。 当然,瘦身和减负虽好,但需要注意瘦身对于项⽬目可维护性的影响,建议根据⾃自身的项⽬目进 ⾏行行技巧的选取。App安装包是由资源和可执⾏行行⽂文件两部分组成,安装包瘦身从以下三部分优化。

    资源优化: 1. 删除⽆无⽤用的资源2.删除重复的资源3.⽆无损压缩图⽚片4.不不常⽤用资源换为下载

    编译优化:1.去除debug符号2.开启编译优化3.避免编译多个架构

    可执⾏行行⽂文件优化: 1.去除⽆无⽤用代码 2.统计库占⽤用,去除⽆无⽤用库 3.混淆类/⽅方法名 4.减少冗余字符串串 5.ARC->MRC (⼀一般不不到特殊情况不不建议这么做,会提⾼高维护成本)

    缩减iOS安装包⼤大⼩小是很多中⼤大型APP都要做的事,⼀一般⾸首先会对资源⽂文件下⼿手,压缩图⽚片/⾳音频,去除不不必要的资源。这些资源优化做完后,我们还可以尝试对可执⾏行行⽂文件进⾏行行瘦身, 项⽬目越⼤大,可执⾏行行⽂文件占⽤用的体积越⼤大,⼜又因为AppStore会对可执⾏行行⽂文件加密,导致可执 ⾏行行⽂文件的压缩率低,压缩后可执⾏行行⽂文件占整个APP安装包的体积⽐比例例⼤大约有80%~90%,还 是挺值得优化的。

    下⾯面是⼀一些常⻅见的优化⽅方案: TableViewCell 复⽤用 在cellForRowAtIndexPath:回调的时候只创建实例例,快速返回cell,不不绑定数据。在willDisplayCell: forRowAtIndexPath:的时候绑定数据(赋值)。
    ⾼高度缓存 在tableView滑动时,会不不断调⽤用heightForRowAtIndexPath:,当cell⾼高度需要⾃自适应时,每 次回调都要计算⾼高度,会导致 UI 卡顿。为了了避免重复⽆无意义的计算,需要缓存⾼高度。 怎么缓存?

    字典,NSCache。
    UITableView-FDTemplateLayoutCell
    视图层级优化
    不不要动态创建视图 在内存可控的前提下,缓存subview。 善⽤用hidden。

    减少视图层级 减少subviews个数,⽤用layer绘制元素。 少⽤用clearColor,maskToBounds,阴影效果等。

    减少多余的绘制操作
    图⽚片
    不不要⽤用JPEG的图⽚片,应当使⽤用PNG图⽚片。 ⼦子线程预解码(Decode),主线程直接渲染。因为当image没有Decode,直接赋值给imageView会进⾏行行⼀一个Decode操作。 优化图⽚片⼤大⼩小,尽量量不不要动态缩放(contentMode)。 尽可能将多张图⽚片合成为⼀一张进⾏行行显示。

    减少透明 view使⽤用透明view会引起blending,在iOS的图形处理理中,blending主要指的是混合像素颜⾊色的 计算。最直观的例例⼦子就是,我们把两个图层叠加在⼀一起,如果第⼀一个图层的透明的,则最终 像素的颜⾊色计算需要将第⼆二个图层也考虑进来。这⼀一过程即为Blending。 会导致blending的原因: UIView的alpha<1。 UIImageView的image含有alpha channel(即使UIImageView的alpha是1,但只要image含 有透明通道,则仍会导致blending)。

    为什什么blending会导致性能的损失? 原因是很直观的,如果⼀一个图层是不不透明的,则系统直接显示该图层的颜⾊色即可。⽽而如果图 层是透明的,则会引起更更多的计算,因为需要把另⼀一个的图层也包括进来,进⾏行行混合后的颜 ⾊色计算。opaque设置为YES,减少性能消耗,因为GPU将不不会做任何合成,⽽而是简单从这个层拷 ⻉贝。

    减少离屏渲染 离屏渲染指的是在图像在绘制到当前屏幕前,需要先进⾏行行⼀一次渲染,之后才绘制到当前屏幕。

    OpenGL中,GPU屏幕渲染有以下两种⽅方式: On-Screen Rendering即当前屏幕渲染,指的是GPU的渲染操作是在当前⽤用于显示的屏幕缓 冲区中进⾏行行。 Off-Screen Rendering即离屏渲染,指的是GPU在当前屏幕缓冲区以外新开辟⼀一个缓冲区进 ⾏行行渲染操作。

    小结

    性能优化不不是更更新⼀一两个版本就可以解决的,是持续性的需求,持续集成迭代反馈。在实际 的项⽬目中,在项⽬目刚开始的时候,由于⼈人⼒力力和项⽬目完成时间限制,性能优化的优先级⽐比较低, 等进⼊入项⽬目投⼊入使⽤用阶段,就需要把优先级提⾼高,但在项⽬目初期,在设计架构⽅方案时,性能 优化的点也需要提早考虑进去,这就体现出⼀一个程序员的技术功底了了。 什什么时候开始有性能优化的需求,往往都是从发现问题开始,然后分析问题原因及背景,进 ⽽而寻找最优解决⽅方案,最终解决问题,这也是⽇日常⼯工作中常会⽤用到的处理方式。

    参考⽂文章
    绘制像素到屏幕上
    iOS图形原理理与离屏渲染,在1.4.1中,这也是为什什么 CALayer 有⼀一个叫做 opaque 的属性 了了。如果这个属性为 NO,GPU 将不不会做任何合成,⽽而是简单从这个层拷⻉贝,不不需要考虑 它下⽅方的任何东⻄西(因为都被它遮挡住了了)。中的opaque属性为NO,GPU将不不会做任何合 成,这句句话时错误的,应该是为YES,GPU才不不会做任何合成。
    iOS 保持界⾯面流畅的技巧
    Advanced Graphics and Animations for iOS Apps(session 419) 使⽤用 ASDK 性能调优 - 提升 iOS 界⾯面的渲染性能
    Designing for iOS: Graphics & Performance iOS离屏渲染之优化分析
    iOS视图渲染以及性能优化总结
    iOS 离屏渲染
    深刻理理解移动端优化之离屏渲染
    iOS 流畅度性能优化、CPU、GPU、离屏渲染
    iOS 图形性能优化锦集
    离屏渲染优化详解:实例例示范+性能测试

    相关文章

      网友评论

          本文标题:iOS性能优化

          本文链接:https://www.haomeiwen.com/subject/oizpyftx.html