iOS程序性能优化的技巧

1. 用ARC管理内存

ARC(Automatic ReferenceCounting, 自动引用计数)和iOS5一起发布,它避免了最常见的也就是经常是由于我们忘记释放内存所造成的内存泄露。它自动为你管理retain和release的过程,所以你就不必去手动干预了。忘掉代码段结尾的release简直像记得吃饭一样简单。而ARC会自动在底层为你做这些工作。除了帮你避免内存泄露,ARC还可以帮你提高性能,它能保证释放掉不再需要的对象的内存。

2.尽量把views设置为透明

如果你有透明的Views你应该设置它们的opaque属性为YES。

原因是这会使系统用一个最优的方式渲染这些views。这个简单的属性在IB或者代码里都可以设定。

Apple的文档对于为图片设置透明属性的描述是:

(opaque)这个属性给渲染系统提供了一个如何处理这个view的提示。如果设为YES,渲染系统就认为这个view是完全不透明的,这使得渲染系统优化一些渲染过程和提高性能。如果设置为NO,渲染系统正常地和其它内容组成这个View。默认值是YES。

在相对比较静止的画面中,设置这个属性不会有太大影响。然而当这个view嵌在scroll view里边,或者是一个复杂动画的一部分,不设置这个属性的话会在很大程度上影响app的性能。

你可以在模拟器中用Debug\Color Blended Layers选项来发现哪些view没有被设置为opaque。目标就是,能设为opaque的就全设为opaque!

这里有一点需要注意,只要是有中文字符的Label,哪怕你设置成不透明,模拟器中这个Label依然会变红,这个猜测是字符绘制的时候出的问题,这个目前没找到好的解决方法。

3.避免过于庞大的XIB

iOS5中加入的Storyboards(分镜)正在快速取代XIB。然而XIB在一些场景中仍然很有用。比如你的app需要适应iOS5之前的设备,或者你有一个自定义的可重用的view,你就不可避免地要用到他们。

如果你不得不XIB的话,使他们尽量简单。尝试为每个Controller配置一个单独的XIB,尽可能把一个View Controller的view层次结构分散到单独的XIB中去。

需要注意的是,当你加载一个XIB的时候所有内容都被放在了内存里,包括任何图片。如果有一个不会即刻用到的view,你这就是在浪费宝贵的内存资源了。Storyboards就是另一码事儿了,storyboard仅在需要时实例化一个view controller.

当家在XIB是,所有图片都被chache,如果你在做OS X开发的话,声音文件也是。Apple在相关文档中的记述是:

当你加载一个引用了图片或者声音资源的nib时,nib加载代码会把图片和声音文件写进内存。在OS X中,图片和声音资源被缓存在named cache中以便将来用到时获取。在iOS中,仅图片资源会被存进named caches。取决于你所在的平台,使用NSImage 或UIImage的imageNamed:方法来获取图片资源。

这个问题我深有体会,用xib写的界面加载速度比直接用代码写的要慢好多

4. 在Image Views中调整图片大小

如果要在UIImageView中显示一个来自bundle的图片,你应保证图片的大小和UIImageView的大小相同。在运行中缩放图片是很耗费资源的,特别是UIImageView嵌套在UIScrollView中的情况下。

如果图片是从远端服务加载的你不能控制图片大小,比如在下载前调整到合适大小的话,你可以在下载完成后,最好是用background thread,缩放一次,然后在UIImageView中使用缩放后的图片。

5. 选择正确的Collection

学会选择对业务场景最合适的类或者对象是写出能效高的代码的基础。当处理collections时这句话尤其正确。

一些常见collection的总结:

Arrays: 有序的一组值。使用index来lookup很快,使用value lookup很慢,插入/删除很慢。

Dictionaries: 存储键值对。用键来查找比较快。

Sets: 无序的一组值。用值来查找很快,插入/删除很快。因为Set用到了哈希,所以插入删除查找速度比Array快很多

6. 打开gzip压缩

大量app依赖于远端资源和第三方API,你可能会开发一个需要从远端下载XML, JSON, HTML或者其它格式的app。

问题是我们的目标是移动设备,因此你就不能指望网络状况有多好。一个用户现在还在edge网络,下一分钟可能就切换到了3G。不论什么场景,你肯定不想让你的用户等太长时间。

减小文档的一个方式就是在服务端和你的app中打开gzip。这对于文字这种能有更高压缩率的数据来说会有更显著的效用。

好消息是,iOS已经在NSURLConnection中默认支持了gzip压缩,当然AFNetworking这些基于它的框架亦然。像Google App Engine这些云服务提供者也已经支持了压缩输出。

7. 重用和延迟加载(lazy load) Views

更多的view意味着更多的渲染,也就是更多的CPU和内存消耗,对于那种嵌套了很多view在UIScrollView里边的app更是如此。

这里我们用到的技巧就是模仿UITableView和UICollectionView的操作:不要一次创建所有的subview,而是当需要时才创建,当它们完成了使命,把他们放进一个可重用的队列中。

这样的话你就只需要在滚动发生时创建你的views,避免了不划算的内存分配。

创建views的能效问题也适用于你app的其它方面。想象一下一个用户点击一个按钮的时候需要呈现一个view的场景。有两种实现方法:

  1. 创建并隐藏这个view当这个screen加载的时候,当需要时显示它;
  2. 当需要时才创建并展示。

每个方案都有其优缺点。用第一种方案的话因为你需要一开始就创建一个view并保持它直到不再使用,这就会更加消耗内存。然而这也会使你的app操作更敏感因为当用户点击按钮的时候它只需要改变一下这个view的可见性。

第二种方案则相反-消耗更少内存,但是会在点击按钮的时候比第一种稍显卡顿。

8.权衡渲染方法

在iOS中可以有很多方法做出漂亮的按钮。你可以用整幅的图片,可调大小的图片,或者可以用CALayer, CoreGraphics甚至OpenGL来画它们。当然每个不同的解决方法都有不同的复杂程度和相应的性能。

简单来说,就是用事先渲染好的图片更快一些,因为如此一来iOS就免去了创建一个图片再画东西上去然后显示在屏幕上的程序。问题是你需要把所有你需要用到的图片放到app的bundle里面,这样就增加了体积–这就是使用可变大小的图片更好的地方了:你可以省去一些不必要的空间,也不需要再为不同的元素(比如按钮)来做不同的图。

然而,使用图片也意味着你失去了使用代码调整图片的机动性,你需要一遍又一遍不断地重做他们,这样就很浪费时间了,而且你如果要做一个动画效果,虽然每幅图只是一些细节的变化你就需要很多的图片造成bundle大小的不断增大。

总得来说,你需要权衡一下利弊,到底是要性能能还是要bundle保持合适的大小。

9.处理内存警告

一旦系统内存过低,iOS会通知所有运行中app。在官方文档中是这样记述:

如果你的app收到了内存警告,它就需要尽可能释放更多的内存。最佳方式是移除对缓存,图片object和其他一些可以重创建的objects的strong references.

幸运的是,UIKit提供了几种收集低内存警告的方法:

在app delegate中使用applicationDidReceiveMemoryWarning:的方法

在你的自定义UIViewController的子类(subclass)中覆盖didReceiveMemoryWarning

注册并接收 UIApplicationDidReceiveMemoryWarningNotification的通知

一旦收到这类通知,你就需要释放任何不必要的内存使用。

例如,UIViewController的默认行为是移除一些不可见的view,它的一些子类则可以补充这个方法,删掉一些额外的数据结构。一个有图片缓存的app可以移除不在屏幕上显示的图片。

这样对内存警报的处理是很必要的,若不重视,你的app就可能被系统杀掉。

然而,当你一定要确认你所选择的object是可以被重现创建的来释放内存。一定要在开发中用模拟器中的内存提醒模拟去测试一下。

当然,现在iOS设备运行内存越来越大,这一点很难出现了

10. 使用Sprite Sheets

Sprite sheet可以让渲染速度加快,甚至比标准的屏幕渲染方法节省内存。

11.避免反复处理数据

许多应用需要从服务器加载功能所需的常为JSON或者XML格式的数据。在服务器端和客户端使用相同的数据结构很重要。在内存中操作数据使它们满足你的数据结构是开销很大的。

比如你需要数据来展示一个table view,最好直接从服务器取array结构的数据以避免额外的中间数据结构改变。

类似的,如果需要从特定key中取数据,那么就使用键值对的dictionary。

这一点在处理大量数据的时候极为重要,用空间换时间的方法也许是极好的。

12.选择正确的数据格式

从app和网络服务间传输数据有很多方案,最常见的就是JSON和XML。你需要选择对你的app来说最合适的一个。

解析JSON会比XML更快一些,JSON也通常更小更便于传输。从iOS5起有了官方内建的JSON deserialization就更加方便使用了。

但是XML也有XML的好处,比如使用SAX来解析XML就像解析本地文件一样,你不需像解析json一样等到整个文档下载完成才开始解析。当你处理很大的数据的时候就会极大地减低内存消耗和增加性能。

以上就是iOS程序性能优化的建议的详细内容,更多关于ios 程序性能优化的资料请关注我们其它相关文章!

时间: 2020-08-31

iOS性能优化教程之页面加载速率详解

前言 我认为在编码过程中时刻注意性能影响是有必要的,但凡事都有个度,不能为了性能耽误了开发进度.在时间紧急的情况下我们往往采用"quick and dirty"的方案来快速出成果,后面再迭代优化,即所谓的敏捷开发.与之相对应的是传统软件开发中的瀑布流开发流程. 卡顿产生的原因 在 iOS 系统中,图像内容展示到屏幕的过程需要 CPU 和 GPU 共同参与.CPU 负责计算显示内容,比如视图的创建.布局计算.图片解码.文本绘制等.随后 CPU 会将计算好的内容提交到 GPU 去,由 GP

h5 ios输入框和键盘的兼容性优化指南

起因 h5的输入框引起键盘导致体验不好,目前就算微信.知乎.百度等产品也没有很好的技术方案实现,尤其底部固定位置的输入框各种方案都用的前提下体验也并没有很好,这个问题也是老大难问题了.目前在准备一套与native协议 来解决这个问题,目前项目中的解决方案还是有值得借鉴的地方的,分享一下 下面话不多说了,来一起看看详细的介绍吧 业务场景 固定在h5页面底部的输入框 无论是使用 <input /> 还是 <div contenteditable="true"> &l

阿里数据iOS端启动速度优化心得

背景 7月26号我们阿里数据iOS端发布了4.4.0版本,这次版本主要是优化了性能,其中main()阶段的启动耗时优化成果比较明显,从之前的0.5-0.7秒,降低为目前的0.1-0.2秒(main()第一行代码到didFinishLaunchingWithOptions最后一行代码的耗时),用户体验提升明显.在这里梳理一下优化的一些经验,欢迎大家一起交流. 应用启动流程 iOS应用的启动可分为pre-main阶段和main()阶段,其中系统做的事情依次是: 1. pre-main阶段 1.1.

iOS开发中UITableview控件的基本使用及性能优化方法

UITableview控件基本使用 一.一个简单的英雄展示程序 NJHero.h文件代码(字典转模型) 复制代码 代码如下: #import <Foundation/Foundation.h> @interface NJHero : NSObject /**  *  头像  */ @property (nonatomic, copy) NSString *icon; /**  *  名称  */ @property (nonatomic, copy) NSString *name; /**  

详解优化iOS程序性能的25个方法

1. 用ARC管理内存 ARC(Automatic ReferenceCounting, 自动引用计数)和iOS5一起发布,它避免了最常见的也就是经常是由于我们忘记释放内存所造成的内存泄露.它自动为你管理retain和release的过程,所以你就不必去手动干预了.忘掉代码段结尾的release简直像记得吃饭一样简单.而ARC会自动在底层为你做这些工作.除了帮你避免内存泄露,ARC还可以帮你提高性能,它能保证释放掉不再需要的对象的内存. 现在所有的iOS程序都用ARC了,这条可以忽略. 2. 在

IOS开发中加载大量网络图片优化方法

IOS开发中加载大量网络图片如何优化 1.概述 在IOS下通过URL读一张网络图片并不像其他编程语言那样可以直接把图片路径放到图片路径的位置就ok,而是需要我们通过一段类似流的方式去加载网络图片,接着才能把图片放入图片路径显示.比如: -(UIImage *) getImageFromURL:(NSString *)fileURL { //NSLog(@"执行图片下载函数"); UIImage * result; NSData * data = [NSData dataWithCont

iOS中的UITableView的重用机制与加载优化详解

UITableView可以说是UIKit中最重要的一个组件,用来展示数据列表,还可以灵活使用进行页面的布局.UITableView的使用遵循MVC模式,数据模型(NSObject).视图(UIView)和控制器(UITableViewController)分离.UITableView继承自UIScrollView,可上下滑动,可以作为跟视图也可以作为子视图组件. reuseIdentifier顾名思义是一个复用标识符,是一个自定义的独一无二的字符串,用来唯一地标记某种重复样式的可复用UITabl

详细整理iOS中UITableView的性能优化

一.介绍 iOS开发中,UITableView可能是平时我们打交道最多的UI控件之一,其重要性不言而喻.Android也是如此,Android中的ListView和UITableView是相同功能的一个控件,但是iOS的UITableView更为强大一点,原因就不说了,如果你学过Android就知道iOS中的UITableView使用起来是非常简单的,这也是峰哥喜欢iOS胜过Android的原因之一.今天研究的内容就是UITableView的优化. 开始之前,你能说出几种UITableView的

iOS体验性优化之RTL适配右滑返回的实现

简述 所谓RTL方向布局就是right to left direction.也就是界面中的元素总是按从右往左的方向进行排列布局,大部分国家的书写以及排列习惯都是从左往右,是LTR方向布局,而对于一些阿拉伯国家,文字的书写以及展示的顺序都是从右往左方向的. iOS的导航支持左滑手势返回上一个界面,这是果粉普遍喜欢的一个特性,iOS7之后的APP适配大多会保留这一特性,慢慢的大多用户已经有了这种操作习惯,对于iPhone的无虚拟键,这种操作也能增加比较友好的用户体验. 在公司新项目之前,没有考虑过多

iOS禁用右滑返回的两种方法

本文实例为大家分享了iOS禁用右滑返回的具体代码,供大家参考,具体内容如下 方式一: 前提:如果使用的自定义UINavigationController基类,请不要在此基类里写相关的手势操作方法. 代码如下: -(void)viewDidAppear:(BOOL)animated{ if ([self.navigationController respondsToSelector:@selector(interactivePopGestureRecognizer)]) { self.naviga

iOS开发之导航栏各种右滑返回失效的解决方法汇总

前言 众所周知iOS 的几乎全部页面都是需要右滑返回的,否则用户体验会大打折扣,但是在开发过程中经常会碰到某些页面右滑返回失效的情况,下面记录一下各种情况下右滑返回失效的解决方法. 下面话不多说了,来随着小编一起学习学习吧 自定义返回按钮时失效 当你重写 self.navigationItem.leftBarButtonItem 之后,自带的返回按钮就会被覆盖,右滑返回就会失效,解决办法只要加入下面这句代码即可. - (void)viewDidLoad { [super viewDidLoad]

iOS app 右滑返回操作的两种方法

前提条件,存在A和B两个页面,A是主界面,A push 到 B 方法一:如果B页面的返回按钮要用自定义的按钮(在iOS7中,如果使用了UINavigationController,那么系统自带的附加了一个从屏幕左边缘开始滑动可以实现pop的手势.但是,如果自定义了navigationItem的leftBarButtonItem,那么这个手势就会失效.) 在A界面: - (void)viewDidAppear:(BOOL)animated { self.navigationController.i

Android实现类似IOS右滑返回的效果(原因分析及解决办法)

使用类库SwipeBackLayout https://github.com/Issacw0ng/SwipeBackLayout 出现的问题: 1. 主Activity返回时黑屏或者返回只是看到桌面背景而没有看到上一个Activity界面 原因: 使用滑动返回需要在Activity的额主题中声明android:windowIsTranslucent=true,而该属性是设置Activity为是否为透明主题,当主Activity采用透明主题时,由于是app Activity栈中的第一个,所以滑动返

Android 实现右滑返回功能

前言 右滑返回这个功能好像在iOS上蛮实用的,因为它的返回键在左上角,右手握持手机就得穿越整个屏幕去按它,不过对于大屏Android手机也是蛮实用的,右下角的返回键随着屏占比的增大按起来的难度也不小,就算有mBack这样的交互,多一个右滑返回也是极好的是吧? 上代码 SwipBackDemo 上效果图 SlidingPaneLayout 这个东西是Support V4中早就存在的,同样是侧滑,远没有侧滑菜单android.support.v4.widget.DrawerLayout被熟知,这玩意

Android右滑返回上一个界面的实现方法

Android右滑返回上一个界面的实现方法 public class BaseActivity extends Activity implements OnTouchListener { public ProgressDialog progressDialog; public String states; public RequestQueue mQueue; /** 触摸时按下的点 **/ PointF downP = new PointF(); /** 触摸时当前的点 **/ PointF

Android中SwipeBack实现右滑返回效果

现在有很多App支持右滑返回,比如知乎,效果比较赞. 于是自己对Activity和Fragment进行了继承,派生出SwipeBackActivity和SwipeBackFragment,用于对这种效果的实现,也就是只要继承这两个类就可以了. 效果如下 Activity Fragment Frgament的效果实现比Activity稍微简单,因为Activity要考虑到dectorView. 支持滑动的控件SwipeLayout,核心思路就是把原有的控件添加到支持滑动的控件中,SwipeLayo

Android仿微信右滑返回功能的实例代码

先上效果图,如下: 先分析一下功能的主要技术点,右滑即手势判断,当滑到一直距离时才执行返回,并且手指按下的位置是在屏幕的最左边(这个也是有一定范围的),  这些可以实现onTouchEvent来实现. 接着就是返回时,有滑动效果,很显然这个是Acitivty切换动画实现的.好啦,分析完了就开干.下面上代码: @Override public boolean onTouchEvent(MotionEvent event) { switch (event.getAction()){ case Mot

android 右滑返回的示例代码

类似于微信的右滑返回,在BaseActivity里利用dispatchTouchEvent()拦截右滑动作,利用setTranslationX()实现动画,在DecorView里添加View作为滑动时的左侧阴影. 渐进步骤: 设置activity背景透明 重写finish()等方法设置activity的跳转动画 重写dispatchTouchEvent()拦截 所需要 右滑动作 重写onTouchEvent()给根布局设置偏移量 添加滑动时上层activity的左侧阴影 滑动时关联下层activ