Effective Objective-C
先来看一组调研数据
- 应用首次启动 出错以后,79% 的用户只会在重试一两次
- 当应用载入时间超过3秒时,25%的用户放弃使用该应用
- 31%的用户会将糟糕的体验告诉其他人
以上的调研数据都强调了性能对于应用的重要性
性能会受到很多因素的影响,这些因素包括内存消耗, 网络宽带效率以及用户界面的相应速度.我们先概述不同类型的性能特征,然后在对他们进行测量
性能指标是面向用户的各个属性,每种属性可能是一个或多个测量工程参数的一个要素
一 影响性能的因素
1.1 内存
内存涉及运行应用所需的 RAM 最小值,以及应用消耗的内存平均值和峰值.最小内存值会严重限制硬件,而最高的内存平均值和峰值意味着更多的后台应用会被强制关闭
同时还用确保没有内存泄露, 随时间流逝而持续增长的内存消耗意味着,应用很可能会因为内存不足的异常而崩溃
1.2 电量消耗
在编写高性能 代码时, 电量消耗是一个需要重点处理的重要因素, 就执行时间和 CPU 资源的利用而言, 我们不仅要实现高效的数据结构和算法, 还需要考虑其他的因素,如果某个应用是个电池黑洞,那么一定不会有人喜欢他
电量消耗不仅仅与计算 CPU 周期有关,还包括高效的使用硬件, 除了要实现电量消耗最小化, 还要确保不会影响用户体验
1.3 初始化时间
应用在启动时应执行刚好够用的任务以完成初始化, 从而满足用户的使用需求,执行这些消耗的时间就是应用的初始化时间, "搞好够用"是一个开放式用语------正确的平衡点取决于应用的需要
在首次使用应用时 创建对象并进行初始化是一个合理的选择, 例如:直到需要使用对象时,才创建对象, 这种方式叫做惰性初始化,
下面列举了 你可能想在应用初始化阶段执行的一些动作
- 检查应用是否是首次启动
- 检查用户是否已经登录
- 如果用户已经登录, 尽可能地载入之前的状态
- 连接服务器以拉取最新的变更
- 检查应用是否由某个深层链接唤起.如果是,还需要载入深层链接相应的 UI 和状态
- 检查是否存在应用上次启动时 挂起的任务,需要时恢复他们
- 初始化后续需要使用的对象和线程池
- 初始化依赖项(如对象关系映射, 崩溃报告和缓存)
1.4 执行速度
一旦启动应用, 用户总是希望他可以尽可能快的工作,一切必要的处理都应该在尽可能短的时间内完成
例如 在照片应用中, 用户通常希望看到调整高度或对比度等简单效果的实时预览效果 因此相应的处理需要在几毫秒内完成
1.5 相应速度
每个应用都应该快速的相应用户交互, 在应用中所做的一切优化和权衡最终都体现在相应速度上
App Store中有需要应用可以完成相似或者相关的任务, 这位用户提供了很大的选择空间,而用户基本都会选择相应最快的应用
1.6 本地存储
针对任何在服务器上存储数据或通过外部来源刷新数据的应用,开发人员应该对本地存储的使用有所规划.以便应用具备离线浏览的能力
如果你的应用使用了本地存储,那么请提供一个清楚数据的选项,遗憾的是,市场上的大部分应用都没有提供此选项,更让人烦恼的是,一些应用竟然会消耗数百兆的存储空间,用户会频繁的卸载这些应用来回收本地存储, 这回导致糟糕的用户体验,从而威胁应用的成功
一定要向终端用户提供清空本地缓存的选项
此处打广告 本人已经基于 FMDB 二次封装了一个 LLFMDB 拿来及用 简单容易上手 可参考Demo
1.7 互操作性
这个知识点就比较懵懂了 待后续书中好好研究分析
用户可能会使用对个应用来完成某个任务, 这就需要这些应用直接提供互操作的能力, 如一个相册可能需要一个幻灯片应用来实现最佳的浏览效果,但需要另一个应用来编辑照片, 其中浏览照片的应用要能够将照片发送到编辑器,并接收编辑后的图片
IOS 为实现应用间的互操作和数据共享提供了多种机制,其中包括
UIActivityViewController,深层链接, MulipeerConnetivity框架,等等
为深层链接定义良好的 URL 结构与编写优异的代码来解析 URL 同样重要,类似的使用共享对话框共享数据时,精确识别用于分享的数据非常重要,同时在处理不同数据源传入的数据时还有注意安全隐患
1.8 网络环境
移动设备会在不同网络环境下使用, 为了确保能够提供最好的用户体验,你的应用应当适应各种网络条件
- 高宽带稳定网络
- 低宽带稳定网络
- 高宽带不稳定网络
- 高宽带不稳定网络
为用户提供进度指示或错误信息是相对合理的方式, 无尽的等待或崩溃则让人无法忍受
如图因网络差或数据量大而显示的不同提示信息
因网络差或数据量大而显示的不同提示信息
1.9 宽带
人们会在不同的网络条件下使用自己的移动设备,网速从每秒数千字节到每秒数十兆字节
因此宽带的优化使用是定义应用质量的另一个关键参数, 此外在高宽带网络下运行一个基于低宽带网络开发的应用可能产生完全不同的结果
1.10 数据刷新
即使没有提供离线浏览能力,你仍可以从服务器端周期性的刷新数据,刷新的频率和每次传输的数据量将决定数据传输的总量,如果传输的字节数过大, 那用户必然会快速耗尽自己的流量计划, 当流量消耗大到一定程度时, 你的应用很可能会流失用户
从 IOS7 开始应用可以在后台周期性的刷新数据, 对于及时聊天应用,持久的 HTTP 链接或原声 TCP 链接可能会非常有用
1.11 多用户登录
是否支持多个并发用户取决于产品的需要, 一旦决定提供此功能,请参考以下准则: ① 添加新用户应尽可能高效② 在不同用户之间更新应尽可能高效③在不同用户之间切换应尽可能高效④用户数据的界限应该简洁且没有 bug
1.12 单点登录
如果你已经创建了多个允许或需要登录的应用, 那么支持单点登录就是一个很多的选择, 如果用户登录了一个应用, 只需要点一次,就可以登录到其他的应用中
其实这一点就需要基于大公司背景了就像微信 QQ 微博第三方登录一样
1.13 安全
安全对移动应用来说是最重要的, 因为敏感信息可能会在应用之间共享,因此 对所有通信以及本地数据和共享数据进行加密就显得尤为重要了
但是引入多个安全层又会影响性能, 并对用户体验造成可感知的负面影响.如何设定安全的基线需要参考对用户群体的统计分析.此外,硬件在其中扮演了重要的角色,选择会因为不同设备的计算能力而有所不同
1.14 崩溃
高性能的应用不仅应尽可能的避免崩溃.还应该在崩溃发生时优雅的恢复, 尤其是在进行某个操作的过程中发生崩溃时
以上即是影响 app 性能的各大因素,
后续会继续总结书中如何去优化这些影响性能的因素
网友评论