当产品日渐成熟，当与竞品功能追赶趋于一致，当小群效应渐渐显露，性能将浮出水面，草灰蛇线，但又潜移默化间带来影响。
一、背景
随着移动端项目趋于成熟，很多app与对手公司已经初步度过了抢占市场份额的阶段，开始进入留存、再付费、用户粘性的赛道，这时候，可能一些曾经为了匆忙上线、或初期架构限制导致的遗留问题等等，导致部分功能虽然实现，但在用户体验上感官不佳，一旦出现问题，将面临失信于用户，流失用户的情况；
当然，如果产品具有唯一性和必要性时，他的性能表现，可能会带来用户吐槽，但迫于现状，不得不继续使用，例如曾经的12306；但反观现在，大家更习惯用美团、携程、飞猪等长期使用“感官”良好稳定app；
所以，当产品是可选时，“感官体验”将是影响用户留存、再付费、用户粘性的一大考验。举个例子，我一直以来都有看直播午睡的习惯，在17年之前，我一直用的是斗鱼客户端，后来斗鱼的PC客户端在长时间播放时，经常会出现“卡顿”、“无限回放”、“音视频不同步”，甚至出现过卡死黑屏的情况，我就换用了虎牙直播，即使后来斗鱼可能在新的版本修复了这些问题，但因为我在虎牙的使用期间没有出过什么大问题，就再也没有换回来，一直用到今天；
性能的优化，一直以来，都是一条需要持续关注的特殊赛道！功能追赶的路上，既要考虑效率和收益，也要考虑长期可持续优化，一旦步子大了，容易把用户扯没了～
二、性能项释义，以及带来的影响
1.物理占用
1.1 包体积
1>包体积是指安装包的体积大小
2>影响：
2.1>分享
常见的拉新方法中，分享占着必不可少的部分，例如常见的从app内活动页点击分享，自动带apk到WhatsApp聊天框；(一些公司会通过出极速版进行分享，安装后部分模块再通过Wi-Fi网络下载)
2.2>下载、安装
部分场景下，包体积过大，可能会影响用户决定是否下载、安装；例如用户使用流量下载，例如用户手机内空间不足等等；
1.2 空间（物理内存）占用
1>空间占用一般由应用程序占用、数据占用和缓存构成
2>影响：
2.1>运行
较高的空间占用，会导致Android机器设备负载升高，影响运行流畅性，有时也会导致crash、ANR等等
2.启动时长
2.1 冷启
1>冷启一般是指后台无该应用进程时（区分保活机收集数据），从用户启动app开始，期间系统创建进程分配给该应用，再到应用完成初始化(SplashActivity)后进入首页;
2>影响
2.1>较快的进入能带给用户更好更快的体验；有些公司也会通过设置开屏广告，来遮盖启动慢的问题；
2.2>冷启一般可参考2/5/8原则，2秒内可以接受，5秒内需要优化，8秒内体验较差，超出8秒就是事故了～
2.2 热启
1>热启动则是后台有该进程(进程处于活跃状态)下，启动app的时长；
2>影响
2.1>较快的完成切入事务的处理，可以让用户可以尽快恢复使用；
2.2>热启一般可参考1/2/4原则，同理如果一个app只是切到后台再切回来，并且进程处于活跃状态，这种情况下超过4秒不可以操作，那基本上可以跳过优化app，直接优化RD和QA了；
2.3 完全启动
1>有时根据场景不同，会关注从用户点击app icon开始，到首页可操作的第一桢时长，这种统计更贴近用户视角去关注“体感”启动时长，这里可能会考虑到首页的逻辑判断、缓存、数据加载、渲染等等；
2>影响
更快的完全启动，能给用户带来更好的体验，降低等待成本；
2.4 deeplink启动
1>一些特定的场景，会关注deeplink启动时长，例如分享落地页掉起app时，从启动到跳转再到页面渲染的总时长，时间过长会影响活动最终的转化；
2>影响
从deeplink启动进来的场景，一般有特定的目的，例如某个活动的落地页，跳转回app内的指定活动页，那么跳转路径上的非必要元素，可以选择不加载或者后加载；
2.5 无网启动
1>一般关注无网时loading、重试、再到缺省展示时长；
2>影响
我曾经遇到过，遇到网络问题导致的启动失败，除了重启无法恢复的问题；没有缺省页，没有刷新，没用重试按钮，甚至config接口已经失败了，但后续接口没有限制重试次数无限重连；
我们要重视每一次用户重启的成本，这对于一个流畅性要求高的特定场景来说，是致命的；
3.PSS（内存占用）
3.1 在Android系统中，每个APP进程除了同其他进程共享内存(shared dirty)外，还独用私有内存(private dirty)，通常我们使用PSS(私有内存+比例分配共享内存)来衡量一个APP的内存开销。由于一个移动设备的内存是固定的，如果内存消耗过大就会造成应用卡顿或者闪退，需要对内存进行测试。正常情况下，应用不应占用过多的内存资源，且能够及时释放内存，保证整个应用内的稳定性和流畅性。
可以通过 adb shell dumpsys meminfo packageName获取
3.2 影响
Kill：当app置于后台时，如果Android系统在遇到内存开销不足的特定情况下，会按照PSS由大到小的顺序开始杀死进程。
Crash：崩溃
其他：当发生OOM(内存泄漏)时，还可能会出现程序卡顿、响应速度慢、重启、ANR等
4.CPU
我们在做CPU测试时，除了关注设备本身的性能属性，也会关注当前环境的性能负荷；例如国内用户一般会在后台开着微信、音乐软件、拍照软件等等，海外部分地区用户一般开着Facebook、WhatsApp、instagram等等；在做性能测试时，除了考虑待测app给设备带来的性能压力，也要考虑待测app在不同设备性能负荷下的表现；
4.1 关注点
1>CPU总体使用率
2>应用程序CPU占用率
4.2 关注方法
1>android自带的DDMS可视化工具
2>Android Studio 3>通过linux系统/proc/stat和/proc/<pid>/stat文件进行占用率的计算
3>通过top命令或者dumpsys cupinfo等命令实时查看当前cpu情况。
4.4 影响
王者在今年下半年的某个版本中，大家一玩就会发现特别烫，除了系统兼容性的特征外，CPU占用率高也是一个比重较高的原因；我们在关注应用占用CPU率时，要保证在合理的范围内控制有效占用，也要关注在不同的运行环境、设备性能负荷下进行流畅性、温度、电量等验证；
过高的CPU占用除了影响运行流程、温度、电量消耗，还可能会导致app重启、crash、ANR等致命问题；
5.FPS
5.1 FPS(流畅度)，玩FPS游戏的同学应该不陌生，理论上来讲，FPS达到系统预期(Android系统一般要求每一帧在16ms内绘制完成)则不会出现明显卡顿；当16ms内没有完成绘制，则会发生掉帧，就会引起用户注意；
5.2 影响
不合理的布局、过度绘制、频繁的垃圾回收等等都是可能会触发掉帧的原因，当发生掉帧后，用户就会感觉卡顿、不流畅；另外还会有画面撕裂、偏移等问题；一般对于fps游戏，这是一项很关键的指标；举个例子，当你玩吃鸡的时候，每次遇到人就会卡卡的，他可能不是网络问题，而是fps掉帧问题哦～
6.GPU渲染（Profile GPU Rendering）
6.1 GPU渲染一般指每帧画面的渲染消耗，一般由绘制时间、执行时间、处理时间三部分组成；大多数android机器都带有GPU渲染的Debug功能；
6.2 影响
GPU的渲染一般影响着FPS流畅度
GPU的过度绘制：
蓝：过度绘制1次；
绿：过度绘制2次；
粉红：过度绘制3次；
红色：过度绘制4次或更多。
7.电耗
7.1 APP消耗电量为 APP运行过程中，涉及各部件的消耗电量总和；
Wakelock(保持唤醒锁)：Android系统为了尽可能的增加设备的续航能力，会不断的关闭各种硬件模块来节省电量。当我们在app休眠时想要进行网络请求，会先唤醒设备，接着进行网络请求，经过一段时间后设备再次慢慢进入休眠状态；
当设备运行在前台时，CPU(I/O、处理事物)、网络(网络传输的数据量)、各种传感器(陀螺仪、GPS)等使用，都决定app的电量消耗排行；
7.2 影响
过多、过快的消耗电量，影响部分场景下用户使用的意愿；我们可以通过排查场景上的非必要事务，来优化电量消耗；也可以通过推迟非面向用户的任务、设定部分事务的处理时机(例如充电时备份数据)、或特定资源Wi-Fi下载、零散任务合并等等策略，来提升用户在非充电情况下的电耗感知；
8.流耗
8.1 现在Android应用市场有很多流量统计的软件可以直观观测到app运行过程中的流量消耗统计；
8.2 统计纬度
1>Wi-Fi
2>3G/4G/5G
8.3 影响
一般用户认为，网络高开销的app，除了消耗他大量流量以外，也会消耗很多他的电量，甚至把手机运行时的卡顿、过热、死机等问题都推给这个原因；所以，我们应该注重网络消耗，通过排查非必要资源请求、缓存、资源下载时机等等方法，降低用户的高流耗感知；
9. 兼容性
9.1 兼容性测试是指测试软件在特定的硬件产台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能很好地运行的测试
9.2 影响
Android的不同品牌、机型、分辨率、不同架构的CPU、不同的操作系统等等都会影响软件的性能表现。
10. 稳定性
10.1 稳定性除了Crash、ANR、性能纬度，还需关注业务的高可用性；在一些核心流程上，随着用户量增加，业务访问量增加，极易出现稳定性问题，所以对于核心流程的稳定性保障是非常必要的；
10.2 分类
1>崩溃(Crash)
2>ANR
3>性能
4>业务高可用性
10.3 影响
较高的稳定性在满足用户日常产品需要的同时，也会持续增加产品可信度，是用户自推广、自裂变的关键前提之一，稳定性不仅影响留存、再付费，也会侧面的影响增长指标；我们可以通过监控、自动化手段等预警机制，提高稳定性保障，降低稳定性问题的处理时常；
三、性能三角
在性能测试开始前，对于性能测试的数据准备是非常重要的一点，要根据产品的受众国家、目标用户、设备环境、网络环境等情况综合制定；
1. 设备&环境
过往的性能测试中，我们一般会先通过hive去查一下相关数据，包括当前产品覆盖的top机型、top系统(版本)，选用占比较高的机型进行性能数据采集设备，能更好的贴近真实场景数据；
拿到设备后，我们会根据产品主要覆盖的国家，有针对有特色的去模拟当地用户的各种环境，例如我们收集的用户已安装app_list，然后通过分析网站获取该国家、该年龄段，用户使用app的习惯和周期，去进行环境的准备；
例如：曾经做过的某国外音乐软件app性能测试，其中一台设备选用了用户量占比最高的红米note4
1>设备主要参数：4GB内存+64GB闪存，CPU最高主频2.1吉赫兹，5.5英寸屏，4100毫安电池，5伏/2安充电，传感器包含(红外、陀螺仪、环境光传感器等等)，GPS，指纹，双卡双待，MIUI8等等
2>环境主要参数：
2.1>已安装：待测app、Facebook、WhatsApp、instagram、soloP、Messenger、Snapchat、Twitter、Paytm、Zomato、Swiggy、KFC、Pizza Hut、Amazon、My More Store、Big Basket、Google Map、Tinder、Book My Show、Indian Railway、Jugnoo等等
2.2>已启动：待测app、Messenger、WhatsApp、soloP、还有一些基础的google服务和其他应用的后台进程；
2.3>网络：因具体情况特定；
2.场景
关于性能测试场景的选择，我们也是通过埋点梳理出核心业务覆盖率最高的5大流程，针对该流程进行场景设计，设计完成后通过评审、路径优化等敲定了最终方案；
3.指标
大多数性能指标都有两条曲线，一条是业内平均，另一条是竞品曲线；我们设定存量版本的性能指标，一般要不低于业内平均，也要赶超竞品指标；当进行一段时间后，则需要关注增量版本性能指标，如果当前版本与上一版本的性能数据差异较大，就需要分析功能实现是否合理、分析性能数据日志、定位问题场景，进行专项优化了；
四、性能项获取工具
1.物理占用
1.1 包体积
Jenkins统计/APK包大小统计
1.2 空间（物理内存）占用
系统-应用程序统计
2.启动时长
adb/PerfDog/AirtestIDE
3.PSS（内存占用）
adb/Android Profiler(Android Studio)/PerfDog/soloP
4.CPU
adb/Android Profiler(Android Studio)/PerfDog/soloP
5.FPS
adb/GT/PerfDog
6.GPU渲染
Android系统开发者工具/Profile GPU rendering/PerfDog
7.电耗
adb/Battery Historian/PerfDog
8.流耗
adb/Android Profiler(Android Studio)/PerfDog
9. 兼容性
云测/自动化
10. 稳定性
专项治理/监控/自动化
五、性能自动化与CI(持续集成)
1. 物理占用：利用python或其他语言脚本获取；
2. 启动时长：利用AirtestIDE(poco+图像识别)+adb获取；
3. PSS、CPU：利用AirtestIDE+SoloP实现的UI自动化场景外层嵌套性能录制；再通过python脚本分析计算性能数据；
4. FPS、GPU、电耗、流耗：同理可以使用airtestIDE+PerfDog+python来实现自动化数据收集；
5. 通过Jenkins和shell脚本将这些能力整合起来，再集成现有的打包工具、虚拟机或真机，进行性能自动化的持续集成；
六、附录文档
努力只能及格，拼命才能优秀～