产品设计时的App性能需求考量

智能手机的普及比电脑要短，但目前已经成为了我们生活中必不可少的工具了。手机的性能和配置也在不断提高，作为产品经理，需要基于用户最常关注的性能问题，明确产品设计的需求。本文将探讨产品设计时的App性能需求考量，一起来看看吧。

智能手机的普及时间远比电脑要短，但其已成为人们生活中更为重要的设备了。随着时代的发展，智能手机的配置也在发生巨大的变化，无论是CPU性能还是内存容量都在以肉眼可见的方式不断提升。

除此之外，App在使用时的耗电量、流量、发热情况等也是用户极为关心的，这些其实都属于性能方面。作为产品经理，需要基于用户最常关注的性能问题，明确产品设计的需求。

一、Android手机为何普遍比较卡顿

很多用户对Android手机存在着极大的“偏见”，觉得Android手机很卡，苹果手机不卡。

1. 系统生态

造成这种差异的原因很多，最核心的是Android系统生态问题。由于谷歌主张的开源策略，诸多手机厂商都会基于原生Android系统定制新系统，加之不同手机厂商研发水平不同，从而造成部分手机易卡顿的情况。相比之下，iOS系统则是从系统到App完全封闭打造，App开发者必须完全遵从苹果生态要求，从而使得系统全局对App有更好的管理。

2. 硬件配置

除了系统生态，App自身的原因也会导致卡顿情况发生。

手机的硬件配置是一个非常重要的原因。苹果手机凭借着完全自研的CPU芯片，与自研的系统完美结合，从而可以更加充分地发挥出硬件性能。Android手机则使用了第三方CPU厂商的芯片，系统与硬件的配合并不能做到像苹果手机那样完美，只能靠提升配置来弥补。不过目前很多Android手机的配置已远超苹果手机，所以配置上基本已经达标。

3. App“抱团”

很多国产App厂商，为了尽可能占用用户的使用时间，想尽各种办法让App一直处于运行状态，无论是在手机后台运行还是使用其他方式。为了达到这样的目的，甚至会“抱团作战”，比如某公司旗下有10款App，在用户启动了其中一个App后，该App就会想办法在后台启动其他9个App，一旦启动，这些App就处于“抱团”的状态，互相之间彼此牵制，其中一个App被“杀死”，另一个App就会想办法再把被“杀死”的App唤醒，这样会使系统的内存资源逐渐消耗掉，从而造成卡顿的情况。

这种行为从公司层面看无可厚非，但从用户的角度看，极大地伤害了用户体验，这是以完成KPI为目的的“作恶”行为。有时App中所表现出的功能及做法，也是一个产品经理人品和一家公司调性的体现。

4. 内存泄漏

内存泄漏也有可能造成App卡顿。要理解内存泄漏的原因，首先需要大概了解系统中App的运行机制。简单来说，App启动后，系统会为App分配一块内存空间，App需要的越多分配得就越多，当App不需要该内存空间时，就将其释放出来供其他App使用。如果某个App无需运行，但占据的内存无法释放，就会造成系统中内存的浪费，从而引发App的运行速度变慢，甚至整个系统都无法响应。

内存泄漏的情况并不只发生在Android系统中，iOS系统中同样会发生，大部分情况都是App开发者在内存回收方面没有做好处理导致的。

二、App的耗电量

在功能机时代，手机充一次电，可以轻松用上一个星期，进入智能机时代后，一天一充或多充都很常见。当然，正常使用手机导致的掉电，用户能接受，但有时只要手机上装了某些App，哪怕没有使用手机，耗电也很快，就会让用户难以接受。

对于手机厂商，从系统层面控制App的耗电量是必须考虑的。另外，App自身也得想办法降低自己给手机带来的耗电影响。

常见的会导致耗电量增加的因素主要有这几个方面：CPU及内存的高频使用带来的电量消耗，数据传输造成的电量消耗，使用定位（尤其是GPS定位）带来的电量消耗，屏幕亮度过高造成的电量消耗，以及各种传感器的使用带来的电量消耗等。

为避免CPU及内存的高频使用带来的电量消耗，在App退到后台后，应尽量减少App的主动运行；为避免数据传输造成的电量消耗，设计产品时可考虑将常用数据缓存到本地，避免每次都请求加载网络数据；App中要使用GPS或其他传感器时，应尽可能地控制这些传感器的使用时间及使用频率，只在必要时才提示用户开启使用它们，其他时间则无须一直开启。

三、App的安装包大小

App的功能越做越复杂，导致安装包的大小也越来越大。尽管现在人们的手机流量已经很充裕，但用户在只想体验某产品时，却发现产品App的安装包有好几百MB大，这时或多或少会犹豫，一是下载会消耗流量，二是下载时间较长，除非“刚需”则八成会放弃下载。并且，关于App安装包大小对App下载量的影响，曾有过相关统计，当App的安装包大小每增加6MB时，App下载量会下降1%。所以，产品经理，以及开发者，要想办法让App在保持功能不变的情况下，尽可能缩减安装包大小。

为了更好地完成这件事，下面先来了解一下安装包由哪些部分组成，这可以帮助我们明确优化方向。

1. Android的App安装包

先说说Android的App安装包。Android的App安装包是APK格式的文件，在应用市场中下载App安装包，并将其解压缩后，会发现APK文件中包含了一些共同的内容，如图6-60所示。

图6-60 Android App安装包解压缩后的目录结构

AndroidManifest.xml文件：该文件是Android App安装包中的配置文件，包含了App的配置信息，包括App的包名、App中所使用的组件、各页面的Activity名称及使用的第三方lib名称。

assets文件夹：该文件夹中保存的是文件的原始格式，即App中需要用到的固定文件，如字体文件或需要引用的音视频文件。

classes.dex系列文件：在Android系统中，这些文件是可以直接在Dalvik虚拟机上运行的文件，由Java源代码经过开发工具编译后转换而成。转换的目的是方便硬件更好地运行这些代码，而且转换后的文件体积也会减小。

lib文件夹：很多App的开发者会使用第三方库，后缀名多为.so，是一种二进制文件，类似于Windows系统中的dll文件。

META-INF文件夹：该文件夹中主要保存描述jar文件中信息和签名相关信息的文件。

r文件夹：App中用到的资源文件，比如页面布局xml文件，App中的固定图标及图片文件等。

resources.arsc文件：该文件可以理解为资源的索引表或目录，其中记录了各种资源ID信息、资源名称、资源路径及对应值，App运行过程中AssetManager会通过该索引表找到需要的具体资源。

从组成目录及文件归类，可将这些文件划分为资源文件及代码文件，classes.dex系列文件和lib文件夹中的文件都可以算作代码文件，剩下的基本上都可以算作资源文件。要调整这两类文件的文件大小，具体可以怎么着手呢？

首先，对于代码类型的文件，应尽可能优化代码，使文件大小减小。可通过剔除无用的lib库，删除代码中的无用功能，优化代码中的冗余代码，将重复代码通过封装简化来减小文件大小。另外，因classes.dex系列文件是由Java代码转换后生成的文件，所以这类文件的大小与代码中的方法数有很大关系，方法数过多会造成转换后的文件变大，这时开发者可通过减少代码中的非必要方法来达到目的。除了上面提到的几种方法，还存在一种方法可以间接起到作用，这就是将代码混淆。因为代码混淆后，代码中的类名、字段名及方法名均被简化并替换成无实际意义的名称，这样可减小最终生成的classes.dex文件的大小，从而减小安装包的大小。

然后，就是从资源文件角度优化了。资源文件中随着版本迭代，可能会出现曾使用，现在已经不再使用，但却没有及时删除的功能的情况，所以每次发布新版本时可以让开发者及时清理App中不再使用的资源文件，比如无效xml代码及图片资源等。如果实在无法删除，还可以对资源文件中的图片、音频、视频等进行压缩处理。

2. iOS的App安装包

再来说说iOS的App安装包。iOS的App安装包格式为IPA，将IPA文件解压缩后会得到如图6-61所示的目录，其中包含了4部分内容，iTunesArtwork是一个没有后缀名的图片，用途是在iTunes中显示App的图标；另一个是iTunesMetadata.plist文件，用来记录开发者及App的基本信息；META-INF文件夹则保存了一些签名信息；最关键的是Payload这个文件夹，其中有一个.app文件，这是安装程序的主程序。