智能手机的普及比电脑要短，但目前已经成为了我们生活中必不可少的工具了。手机的性能和配置也在不断提高，作为产品经理，需要基于用户最常关注的性能问题，明确产品设计的需求。本文将探讨产品设计时的App性能需求考量，一起来看看吧。
智能手机的普及时间远比电脑要短，但其已成为人们生活中更为重要的设备了。随着时代的发展，智能手机的配置也在发生巨大的变化，无论是CPU性能还是内存容量都在以肉眼可见的方式不断提升。
除此之外，App在使用时的耗电量、流量、发热情况等也是用户极为关心的，这些其实都属于性能方面。作为产品经理，需要基于用户最常关注的性能问题，明确产品设计的需求。
很多用户对Android手机存在着极大的“偏见”，觉得Android手机很卡，苹果手机不卡。
造成这种差异的原因很多，最核心的是Android系统生态问题。由于谷歌主张的开源策略，诸多手机厂商都会基于原生Android系统定制新系统，加之不同手机厂商研发水平不同，从而造成部分手机易卡顿的情况。相比之下，iOS系统则是从系统到App完全封闭打造，App开发者必须完全遵从苹果生态要求，从而使得系统全局对App有更好的管理。
除了系统生态，App自身的原因也会导致卡顿情况发生。
手机的硬件配置是一个非常重要的原因。苹果手机凭借着完全自研的CPU芯片，与自研的系统完美结合，从而可以更加充分地发挥出硬件性能。Android手机则使用了第三方CPU厂商的芯片，系统与硬件的配合并不能做到像苹果手机那样完美，只能靠提升配置来弥补。不过目前很多Android手机的配置已远超苹果手机，所以配置上基本已经达标。
很多国产App厂商，为了尽可能占用用户的使用时间，想尽各种办法让App一直处于运行状态，无论是在手机后台运行还是使用其他方式。为了达到这样的目的，甚至会“抱团作战”，比如某公司旗下有10款App，在用户启动了其中一个App后，该App就会想办法在后台启动其他9个App，一旦启动，这些App就处于“抱团”的状态，互相之间彼此牵制，其中一个App被“杀死”，另一个App就会想办法再把被“杀死”的App唤醒，这样会使系统的内存资源逐渐消耗掉，从而造成卡顿的情况。
这种行为从公司层面看无可厚非，但从用户的角度看，极大地伤害了用户体验，这是以完成KPI为目的的“作恶”行为。有时App中所表现出的功能及做法，也是一个产品经理人品和一家公司调性的体现。
内存泄漏也有可能造成App卡顿。要理解内存泄漏的原因，首先需要大概了解系统中App的运行机制。简单来说，App启动后，系统会为App分配一块内存空间，App需要的越多分配得就越多，当App不需要该内存空间时，就将其释放出来供其他App使用。如果某个App无需运行，但占据的内存无法释放，就会造成系统中内存的浪费，从而引发App的运行速度变慢，甚至整个系统都无法响应。
内存泄漏的情况并不只发生在Android系统中，iOS系统中同样会发生，大部分情况都是App开发者在内存回收方面没有做好处理导致的。
在功能机时代，手机充一次电，可以轻松用上一个星期，进入智能机时代后，一天一充或多充都很常见。当然，正常使用手机导致的掉电，用户能接受，但有时只要手机上装了某些App，哪怕没有使用手机，耗电也很快，就会让用户难以接受。
对于手机厂商，从系统层面控制App的耗电量是必须考虑的。另外，App自身也得想办法降低自己给手机带来的耗电影响。
常见的会导致耗电量增加的因素主要有这几个方面：CPU及内存的高频使用带来的电量消耗，数据传输造成的电量消耗，使用定位（尤其是GPS定位）带来的电量消耗，屏幕亮度过高造成的电量消耗，以及各种传感器的使用带来的电量消耗等。
为避免CPU及内存的高频使用带来的电量消耗，在App退到后台后，应尽量减少App的主动运行；为避免数据传输造成的电量消耗，设计产品时可考虑将常用数据缓存到本地，避免每次都请求加载网络数据；App中要使用GPS或其他传感器时，应尽可能地控制这些传感器的使用时间及使用频率，只在必要时才提示用户开启使用它们，其他时间则无须一直开启。
App的功能越做越复杂，导致安装包的大小也越来越大。尽管现在人们的手机流量已经很充裕，但用户在只想体验某产品时，却发现产品App的安装包有好几百MB大，这时或多或少会犹豫，一是下载会消耗流量，二是下载时间较长，除非“刚需”则八成会放弃下载。并且，关于App安装包大小对App下载量的影响，曾有过相关统计，当App的安装包大小每增加6MB时，App下载量会下降1%。所以，产品经理，以及开发者，要想办法让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代码及图片资源等。如果实在无法删除，还可以对资源文件中的图片、音频、视频等进行压缩处理。
再来说说iOS的App安装包。iOS的App安装包格式为IPA，将IPA文件解压缩后会得到如图6-61所示的目录，其中包含了4部分内容，iTunesArtwork是一个没有后缀名的图片，用途是在iTunes中显示App的图标；另一个是iTunesMetadata.plist文件，用来记录开发者及App的基本信息；META-INF文件夹则保存了一些签名信息；最关键的是Payload这个文件夹，其中有一个.app文件，这是安装程序的主程序。
图6-61 iOS App安装包解压缩后的目录结构
在Payload文件夹中找到.app文件后，继续执行解压缩或者直接显示包内容，能看到更多文件，这些文件又可以分成以下这几类。
签名文件：主要放置在_CodeSignature文件夹中，记录了所有资源的签名信息。
资源文件：找到Payload文件夹中的.app文件，点击右键并选择“显示包内容”，可以查看到App在运行过程中用到的资源文件，比如图片、音视频及其他配置文件。
可执行代码文件：这类文件是App中的主体内容，是确保App功能得以实现的重要部分。
其他支持文件：这部分文件又包含了多种不同类型的文件，如开发过程中会用到的第三方库文件及一些插件等。
了解了安装包文件中包含的文件后，对于如何减小安装包大小，就应该有思路了。大体上还是与Android App安装包一致，即减小代码文件、资源文件及其他支持文件的大小，通过优化代码、压缩资源文件、删除非必要支持文件等方式达到目的。
本文节选自作者新书《产品经理技术手册》，本书定位于让不懂技术的产品经理从产品经理的工作和思考方式切入了解应该掌握的技术原理。
专栏作家
小风老师，公众号：村上风，人人都是产品经理专栏作家。《产品经理技术手册》作者，互联网从业者，独立原创音乐人。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。