面试之性能优化

你在项目中是如何优化内存的?
优化你是从哪几个方面入手?
列表卡顿的原因可能有哪些?你平时是怎么优化的?
遇到 tableView卡顿吗?会造成卡顿的原因大致有哪些?


CPU 和 GPU

  1. 在屏幕成像的过程中,CPU 和 GPU起着至关重要的作用
  • CPU(Central Processing Unit , 中央处理器)
    对象的创造和销毁,对象属性的调整,布局计算,文本的计算和排版,图片的格式转换和解码,图像的绘制(Core Graphics)
  • GPU(Graphics Processing Unit , 图像处理器)
    文理的渲染
image.png
  1. 在iOS中是双缓冲机制,有前帧缓存、后帧缓存

屏幕成像原理

image.png

卡顿产生的原因

image.png
  1. 卡顿解决的主要思路
  • 尽可能的减少CPU,GPU资源消耗
  1. 按照60FPS的刷帧率,每隔16ms就会有一个VSync信号

卡顿优化 CPU

  1. 尽可能用轻量级的应用,比如用不到事件处理的地方,可以考虑使用CALayer取代 UIView
  2. 不要频繁的调用UIView 的相关属性,比如 frame, bounds, transfrom 等属性,尽量减少不必要的修改
  3. 尽量提前计算好布局,在有需要时一次性调整对应的属性,不要多次修改属性
  4. Autolayout会比直接设置 frame 消耗更多的CPU 资源
  5. 图片的 size最好刚好跟 UIImageView的 size保持一致
  6. 控制一下线程的最大并发量
  7. 尽量把耗时的操作放在子线程
  • 文本的处理(尺寸计算 , 绘制)
  • 图片处理(解码 , 绘制)

卡顿优化 GPU

  1. 尽可能避免短时间大量图片的显示,尽可能的将多张图片合成一张显示
  2. GPU 能处理的最大纹理尺寸4096*4096 , 一旦超过这个尺寸就会占用 CPU 资源处理,所以纹理尽量不要超过这个尺寸
  3. 尽量减少视图的数量和层次
  4. 减少透明的视图(alpha < 1) , 不透明就设置opaque 为 YES
  5. 尽量避免出现离屏渲染

离屏渲染

  1. 在 OpenGL 中, GPU有两种渲染方式
  • On-Screen Rendering : 当前屏幕渲染,在当前用于显示的屏幕缓冲区进行渲染操作
  • Off-Screen Rendering : 离屏渲染 , 在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作
  1. 离屏渲染消耗性能的原因
  • 需要创建新的缓冲区
  • 离屏渲染的整个过程,需要多次切换上下文环境,显示从当前屏幕( On - Screen )切换到( Off - Screen),等到离屏渲染结束之后,将离屏缓冲区的渲染结果显示到屏幕上,又需要将上下文环境从离屏切换到当前屏幕
  1. 哪些操作会触发离屏渲染
  • 光栅化 , layer.shouldRasterize = YES
  • 遮罩 , layer.mask
  • 圆角 , 同时设置layer.masksToBounds = YES '; layer.cornerRadius大于0 (考虑通过CoreGraphics 绘制裁剪圆角, 或者让美工提供圆角图片)
  • 阴影, layer.shadowXXX (如果设置了layer.shoadowPath 就不会产生离屏渲染)

卡顿检测

  1. 平常所说的 "卡顿", 主要是因为在主线程执行了比较耗时的操作
  2. 可以添加Observer到主线程RunLoop中, 通过监听RunLoop状态切换的耗时,以达到监控卡顿的目的

耗电的主要来源

image.png
  1. CPU处理,Processing
  2. 网络, Networking
  3. 定位, Location
  4. 图像, Graphics

耗电优化

  1. 尽可能降低 CPU , GPU 的功耗
  2. 少用定时器
  3. 优化 I/O 操作
  • 尽量不要频繁的写入小数据,最好批量一次性写入
  • 读写大量重要数据时,考虑用dispatch_io,其提供了基于 GCD 的异步操作文件 I/O 的API.用 dispatch_io系统会优化磁盘访问
  • 数据量比较大的,建议使用数据库(比如SQlite, CoreDate)
  1. 网络优化
  • 减少,压缩网络数据
  • 如果多次请求的结果是相同的,尽量使用缓存
  • 使用断点续传,否则网络不稳定时可能多次传输相同的内容
  • 网络不可用时, 不要尝试执行网络请求
  • 让用户可以取消长时间运行或者速度很慢的网络操作,设置合适的超时时间
  • 批量传输,比如,下载视频流时,不要传输很小的数据包,直接下载整个文件或者一大块一大块的下载. 如果下载广告,一次性多下载一些,然后再慢慢展示. 如果下载电子邮件,一次下载多封,不要一封一封的下载.
  1. 定位优化
  • 如果只是需要快速确定用户位置,最好用CLLocationManager的requestLocation方法。定位完成后,会自动让定位硬件断电
  • 如果不是导航应用,尽量不要实时更新位置,定位完毕就关掉定位服务
  • 尽量降低定位精度,比如尽量不要使用精度最高的kCLLocationAccuracyBest
  • 需要后台定位时,尽量设置pausesLocationUpdatesAutomatically为YES,如果用户不太可能移动的时候系统会自动暂停位置更新
  • 尽量不要使用startMonitoringSignificantLocationChanges,优先考虑startMonitoringForRegion:
  1. 硬件检测优化
  • 用户移动、摇晃、倾斜设备时,会产生动作(motion)事件,这些事件由加速度计、陀螺仪、磁力计等硬件检测。在不需要检测的场合,应该及时关闭这些硬件

APP 的启动

1.APP的启动可以分为2种

  • 冷启动(Cold Launch):从零开始启动APP
  • 热启动(Warm Launch):APP已经在内存中,在后台存活着,再次点击图标启动APP
  1. APP启动时间的优化,主要是针对冷启动进行优化
  2. 通过添加环境变量可以打印出APP的启动时间分析(Edit scheme -> Run -> Arguments)
  • DYLD_PRINT_STATISTICS设置为1
  • 如果需要更详细的信息,那就将DYLD_PRINT_STATISTICS_DETAILS设置为1
  1. APP的冷启动可以概括为3大阶段
  • dyld
  • runtime
  • main
image.png

APP的启动 - dyld

1.dyld(dynamic link editor),Apple的动态链接器,可以用来装载Mach-O文件(可执行文件、动态库等)

  1. 启动APP时,dyld所做的事情有
  • 装载APP的可执行文件,同时会递归加载所有依赖的动态库
  • 当dyld把可执行文件、动态库都装载完毕后,会通知Runtime进行下一步的处理

APP的启动 - runtime

  1. 启动APP时,runtime所做的事情有
  • 调用map_images进行可执行文件内容的解析和处理
  • 在load_images中调用call_load_methods,调用所有Class和Category的+load方法
  • 进行各种objc结构的初始化(注册Objc类 、初始化类对象等等)
  • 调用C++静态初始化器和attribute((constructor))修饰的函数
  1. 到此为止,可执行文件和动态库中所有的符号(Class,Protocol,Selector,IMP,…)都已经按格式成功加载到内存中,被runtime 所管理

APP的启动 - main

  • APP的启动由dyld主导,将可执行文件加载到内存,顺便加载所有依赖的动态库
  • 并由runtime负责加载成objc定义的结构
  • 所有初始化工作结束后,dyld就会调用main函数
  • 接下来就是UIApplicationMain函数,AppDelegate的application:didFinishLaunchingWithOptions:方法

APP的启动优化

按照不同的阶段

  1. dyld
  • 减少动态库、合并一些动态库(定期清理不必要的动态库)
  • 减少Objc类、分类的数量、减少Selector数量(定期清理不必要的类、分类)
  • 减少C++虚函数数量
  • Swift尽量使用struct
  1. runtime
  • 用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++静态构造器、ObjC的+load
  1. main
  • 在不影响用户体验的前提下,尽可能将一些操作延迟,不要全部都放在finishLaunching方法中
  • 按需加载

安装包瘦身

  1. 安装包(IPA)主要由可执行文件、资源组成
  2. 资源(图片、音频、视频等)
  1. 可执行文件瘦身
  • 编译器优化
    Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default设置为YES
    去掉异常支持,Enable C++ Exceptions、Enable Objective-C Exceptions设置为NO, Other C Flags添加-fno-exceptions
  • 利用AppCode(https://www.jetbrains.com/objc/)检测未使用的代码:菜单栏 -> Code -> Inspect Code
  • 编写LLVM插件检测出重复代码、未被调用的代码

linkMap

1.生成LinkMap文件,可以查看可执行文件的具体组成

image.png

2.可借助第三方工具解析LinkMap文件: https://github.com/huanxsd/LinkMap


最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,884评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,347评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,435评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,509评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,611评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,837评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,987评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,730评论 0 267
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,194评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,525评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,664评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,334评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,944评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,764评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,997评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,389评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,554评论 2 349

推荐阅读更多精彩内容