App 优化（一）

末蓝、 2022-06-14 11:54 369阅读 0赞

优化的目的：使各种UI的反应灵敏，减少卡顿；提高运行速度；降低内存占用；提升用户体验；

第一部分：

一：instruments

> 使用instruments分析器分析工程性能，不要凭空想象；比如要查看程序哪些部分耗时时，可以使用Time Profiler，要查看内存是否泄漏时，可以使用Leaks等；

二：不要阻塞主线程

> 在iOS里关于UIKit的操作都是放在主线程中的，为防止UI可能无法及时响应事件，视觉上产生卡顿的感觉，要避免主线程阻塞；大多数阻塞主线的情况是在主线程做IO操作，比如文件的读写（包含数据库、图片、json文本或者log日志等），尽量将这些操作放到子线程进行（如果数据库有一次有较多的操作，记得采用事务处理【备注】，性能相差会挺大的），或者在后台建立对应的dispatch queue 来做这些操作（比如一个低级别的serial  queue【连续队列】来负责log文件的记录），程序中的代码逻辑最好不要使用同步逻辑【备注】

三：使用cache

> 一般为了提升用户体验，都会在应用中使用缓冲。比如：图片资源可以使用SDWebImage开源库实现图片缓冲，该库中实现了一个图片缓冲的功能；
> 
> 获取资源的具体过程如下：
> 
> 业务层----> ResourceManager(资源管理)--->memory cache（内存缓冲）----> disk(硬盘)  --->internet（因特网）  【cache简单示意图】
> 
> 具体描述：业务层根据资源的url向resourceManager获取应用的资源，resourceManager首先会到memory cache中获取资源，memory cache可以利用NSCache实现，因为NSCache首先是线程安全的，而且在收到内存警告的时候会自动释放对应的内存；如果memorycache中没有对应的资源再去disk中查找，disk也没有的话再去internet中获取，获取到的话，会更新到memorycache和disk中；

四：减少程序启动过程中的任务：

> 当用户点击app的图标之后，程序应该尽可能快的进入到主页面，尽可能减少用户的等待时间；比如：我们的应用程序在启动的时候会去做3d渲染操作，完成之后再进入首页展示，但其实我可以先进入首页，将3d渲染的任务放到子线程去完成，缩短用户需要等待的时间。

五：使用合适的数据结构

> 根据不同的业务场景选择适合的数据结构，当数据少的时候可能看不出，但是当数据较大时且数据结构比较复杂的话，这可能会影响到程序性能。一般用的比较多的数据结构是array，但是，她的查找复杂度为O（n），因此假如需要快速查找某个元素，可以使用map【备注】。

六：内存

> 一般开发都使用ARC，不太需要开发者关注内存的创建和释放，但如果使用的是MRC，并且与其他语言（比如：c++、lua）混杂，如何确保内存正确释放，就需要考虑了。有时候内存泄漏instruments可能无法准确的分析出来，那么可以使用method swizzling【备注】方法来扶着排查内存泄漏。

七：懒加载view

> 不要在cell里边嵌套太多的view，这回影响滑动的流畅感，而且更多的view也需要花费更多的cpu和内存。假如由于view太多而导致了滑动不流畅，那就不要一次就把所有的view都创建出来，把部分view放到需要显示cell的时候再去创建；

八：lua优化：(业务层用lua实现的，用于做游戏，实现热更新)

> 由于项目的业务以及部分框架是用lua语言实现的，因此，也需要注意lua的优化问题；lua是最快的脚本语言，一般性能上不会有什么问题，如果lua代码要优化的话，需要注意很多点；比如：lua的垃圾回收：垃圾回收是一个比较耗时的操作；假如垃圾回收的操作过去频繁，势必会影响到这个程序的运行（比如在iPod中利用lua——cjson解析一份4.7M的json文件是花费3.43S的时间，后来发现跟垃圾回收这块有关）；一般内存的使用量适中的话，可以不用考虑它，让lua的incremental模式自己去处理，正常情况下会工作的比较好；假如想要自己去控制gc的运行，可以设置gc的参数，这些参数可能会跟项目有一定关系，可以自己多试验取最优值；
> 
> //gc的参数设置，根据情况取最优值
> 
> collectgarbage("setpause",150)
> 
> collectgarbage("setstepmul",200)

>   
>

备注：

事务处理：所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。例如，银行转账工作：从一个账号扣款并使另一个账号赠款，这两个操作要么都执行，要么都不执行。

同步逻辑：【见之后的博客】

map：【见之后的博客】

method swizzling：【见之后博客】

第二部分：iOS app中滑动的优化

> iOS为了提高滑动的流畅感，特意在滑动的时候将runloop模式切换到UITrackingRunLoopMode，在这个过程中专心做到跟滑动相关的工作，这就是在滑动过程中NSTimer无法工作的原因，因为他们两个没有再同一个model里（NSTimer在Runloop模式中，滑动在UITrackingRunLoopMode中）。但是，即使这样，在滑动的时候任然不流畅。遇到这种情况，首先

第三部分：

一.计算代码运行时间：【注意：模拟器和真机是有差别的】

> 计算方法1：对简单的工具NSDate，但精度不是很高。

> > NSDate \*tmpStartDate = \[\[NSDate date\] retain\];
> 
> > double  deltaTime  = \[\[NSDate date\] timeIntervalSinceDate:tmpStartDate\];
> 
> > NSLog(@">>>>>>>cost time = %f",deltaTime);

> 计算方法2：将运行代码放到如下方法的block参数中，然后返回所运行的时间；

> > \#import <mach/mach\_time.h>  // for mach\_absolute\_time() and friends

> > CGFloat BNRTimeBlock(void  (^block)(void))\{
> > 
> > mach\_timebase\_info\_data\_t info;
> > 
> > if(mach\_timebase\_info(&info)  != KERN\_SUCCESS )  return  -1.0;
> > 
> >   
> > 
> > 
> > uint64\_tstart = mach\_absolut\_time();
> > 
> > block();
> > 
> > uint64\_t end=mach\_absolute\_time();
> > 
> > uint64\_t elapsed = end \- start;
> > 
> >   
> > 
> > 
> > uint 64\_t nanos = elapsed \*info.numer / info.denom;
> > 
> > return (CGFloat) nanos / NSEC\_PER\_SEC;

二：善用性能分析工具：

> XCode自带了很强大的分析工具，包括静态Analyze工具，以及运行时Profile工具；
> 
> 例如：Instruments的使用【具体使用略】

三：具体控件的优化分析：

> 1.图片优化：优先使用\[UIImage imageNamed:@""\];
> 
> 与\[\[UIImage alloc\] initWithCOntentsOfFile:\]和\[UIImage alloc\] initWithData:\]相比，\[UIImage imageNamed:\]有着更好的效率；这是因为：iOS会自带cache通过\[UIImage imageNamed:\]载入图像，但该方法有一个缺点，那就是只能载入应用程序bundle中的图像，像网络下载的图像就无能为力了。

四：对复杂结构的view的处理：

> 我习惯的做法是自定义一个 ImageCache 类，自己来 cache 图像。
> 
> 尽量不要使用全屏大小的背景图片；使用 gradient 图片来取代硬编码的 gradient；gradient 图片应当尽可能窄，然后将之拉伸运用到实际场合中去。
> 
> 使用drawRect自绘，而不是从nib中载入；【备注nib】

五、Tableview的优化：

六：使用多线程延迟加载资源

> 比如：tableViewCell中的网络图像显示，先使用一个默认图像，然后开启线程下载网络图像，当图像下载完成后，再替换默认图像；

七：关于后台任务：

八：如果关键代码使用c/c++效率更高就使用c/c++;

九：内存释放：

>   
> 
> 
>   
> 
> 
> 备注：
> 
> 1、nib（与storybored和xib比较）
> 
> nib是3.0以前的产物，在终端下可以看到；nib其实是一个文件夹，其内存放着二进制文件；这些二进制文件是Interface Builder将窗口、菜单栏以及窗口上的各种控件对象“冻结”形成的，将在程序运行时“苏醒”。nib最终在UIViewController生命周期函数loadView之前，会转化成可执行的nib文件，xib同样如此；
> 
> xib是基于xml的描述文件，可以实现可视化编程；同样的，storybored也是基于xml 的描述文件，用来实现可视化编程的；但是，他们两者是由区别的，区别如下：
> 
> storybored是多个xib文件集合的描述性文件；一个工程中要一个storybored文件就可以了。而一个工程中要有多个xib文件，一个xib文件对应一个视图控制器和多个视图控件。因此，在一个工程中有多个视图控制器时，使用storybored进行管理更为方便，而且storybored可以描述界面之间的导航关系；
> 
>   
> 
> 
>   
>