前提

从事视频编辑4年多, 一直做视频编辑SDK, 积累了大量的做视频编辑APP的客户, 自己手机里装了很多视频编辑APP,是这个行业的从业人员.  对整个产品有一些认识, 谈谈自己的认识;
这里主要谈视频编辑功能, 就是普通用户用相机拍好一个视频后, 想主动的去做一些视频编辑, 比如加音乐, 加特效, 加动画,调速, 倒序,加特效等编辑的行为;

时间轴界面是什么

当前(2020年11月05日)大部分的视频编辑APP,是预览界面+ 时间轴的形式呈现的;时间轴,就是在视频预览下面,随着播放而走动的缩略图横向列表. 当在编辑的时候, 拖动缩略图这个时间轴, 从而预览画面随之变化.
预测最近两三年内大部分视频编辑APP都会采用这样的界面,因为简单,直接,无学习成本, 类似现在95%的股票APP走势图,都是一样的界面.一样的界面会成为大趋势, 只是功能亮点, 素材亮点,和操作交互谁更简单,才是一个视频编辑APP的竞争力.

开始
视频编辑的基础 我认为是三个关键点: 加载快/时间轴顺滑/导出快

如果说视频编辑是一个一个的功能组成, 是枝枝叶叶, 则这三个关键点则是整个产品的骨架, 是撑起整个视频编辑的底层基石.

1. 加载快.

因为首先你要用户感觉到快, 很轻,手指头点击几下就可以完成的,  是一个很简单的事情, 用户才有编辑的兴趣; 如果很慢, 很笨重, 很卡, 会让用户望而却步, 从而不再使用.没有人喜欢等待, 没有人喜欢麻烦. 选择好一个视频, 下一步直接打开编辑界面, 这中间不能有等待加载导入, 因为加载导入的时间长会让用户感觉视频很沉重, 用户打开视频编辑界面时,他就大概想好了要做什么, 比如"想把画面左右裁剪一下",“去掉声音”, “某个地方加特效”,“剪去前后一些时长”, “把某个好玩的地方调速一下”, "增加一些说明文字"等等. 用户本来想调整一下,大部分时候是灵感或突发性的想法, 你让用户在打开的时候, 等待很长时间, 则兴趣全无. 可能最后说声:“算了,用别的APP吧”. 故视频加载一定要快, 一定要让用户感觉视频编辑就是手边上的工具, 信手拈来,顺手就做了的事情, 故加载快是前提.

2. 时间轴顺滑.

用户顺手加载进去一个视频, 下一步,就是找到自己要编辑的时间点. 这个[找] 也要快, 比如用户拍了30秒的时候, 用户想在第10秒处增加一个"哇塞"这样的声音, 我认为最好的体验就是, 滑动时间轴,极快的刷新到用户想要的那个画面, 中间不能卡顿, 要让用户感觉录好的视频,就是很多个连续的图片而已, 像拿到一本书一样, 直接翻到那一页, 弹出素材框, 选中"哇塞"声音, 点击就增加了一个时间轴, 然后调整下就做完了.
用户各种功能增加完毕后, 他大概率的会去再次拖动时间轴, 会再次去预览下自己编辑的是否是自己心中要的, 就是他自己会"过一遍", 他的大致操作是: 快速的滑动时间轴, 查看是否完好.类似他把一本书做好了个各种笔记, 他要从头到尾翻一遍一样, 这时更反应了时间轴顺滑的意义, 如果慢了,沉重复杂,耐心去等待, 这样编辑一个视频,本来是顺手做的事情, 慢会导致体验差.
再者, 各种功能也是依次增加到对应的时间轴的, 是以时间轴为参考增加的, 即使你从0到最后一秒完全增加一个效果功能, 也会在增加后, 滑动时间轴看下,这个效果增加的是否合适, 是否舒服, 和录制的视频是否搭配.
时间轴顺滑, 可最大程度的消除用户心中的排斥感, 让用户自己感觉他录好的东西, 触手可及, 录制的每个画面都是可以用手感觉到的, 是自己走进这个画面里的.

3. 导出快:

不用多说, 类似用户对一本书标记完毕后, 把书本合上的过程. 很快的导出,分享出去, 完成处理. 用户感觉 视频编辑是一个轻松愉快的过程.就是手边上的一个工具, 下一次还会打开使用.

随着中国经济的蓬勃发展，金融行业迎来了前所未有的发展机会，证券行业作为金融市场的重要组成部分，获得了发展的红利，但同时也面临着巨大的挑战。在移动化已经全面融入人们生活的背景下，完成系统的、高质量的移动化转型便成了无数挑战中最亟待解决的问题。用户量增长放缓，用户对体验要求越来越高，行业竞争愈加激烈，一道道屏障都需要证券行业从业者去跨越，只有这样才能留住每一个弥足珍贵的用户。

北京云测信息技术有限公司，以下简称（Testin云测），从第三方观察者的角度，以“最终用户视角”从证券行业抽取20家券商手机APP进行“业务层面”运营质量和用户体验综合评测，选取评测的业务共计11个，分别为应用启动、行情入口、上证指数、深证成指、个股详情、个股F10、开户入口、理财入口、基金详情、交易入口、综合资讯（具体评测方法详见综合评测说明）。

(一) 业务性能评测

业务操作平均耗时评测



 



 

业务Apdex指数评测



 



 

(二) 基础性能评测

应用崩溃率评测



 

应用安装包大小评测



 

应用安装时间评测



 

应用冷启动时间评测



 

(三) 应用性能评测

应用CPU平均消耗评测



 

内存平均消耗评测



 

应用网络流量平均消耗



 

(四) 综合评测结语

各家券商在技术上的积累和实力等诸多方面均不相同，这就导致了各家应用表现出的用户体验和性能体验也各不相同。

通过抽样数据来看，证券行业业务用户体验整体表现趋好，多数业务操作平均耗时在4秒以内，各业务Apdex指数较高，但不同APP中还是存在较大的差异，业务操作平均耗时最优与最差值相差将近3秒，业务Apdex指数最优和最差相差0.5左右。

从单个业务性能综合评测数据来看，应用启动、基金、理财、个股F10等业务存在一定的差距外，其它各业务差距在逐步缩小。

从应用性能和基础性能综合评测数据来看，各项指标还是存在不小的差距。

(五) 综合评测说明

一、本次测评是“从最终用户视角”开展的业务层面的测试，在技术上依托Testin云测的云监控平台及Testin云测AI自动化技术，执行券商手机APP中相同或相近的业务，获取用户体验数据。

二、本次评测，选择了证券行业手机APP中11个代表业务功能点做为本次评测的业务场景，分别为：应用启动(UI)、行情入口、上证指数、深证成指、个股详情、个股F10(个股介绍或简况)、开户入口、理财入口、基金详情、交易入口、综合资讯，如下图。



 

三、本次抽样综合测评是对20家券商手机APP应用，在相同的手机(Android手机)，相同的网络（中国移动4G、中国电信4G、中国联通4G）,相同的地域（北京），相同的时段（交易日交易时间，9:15-15:00），执行业务，获取数据样本（各APP各业务样本数>500），综合评测各业务运营质量用户体验。

四、针对各家券商APP，本次综合评测将提供业务性能指标、基础性能指标和应用性能指标的综合评测，业务性能指标主要包括“业务操作耗时”、“业务Apdex指数”，基础性能指标包括“崩溃率”、“应用安装包大小”、“应用安装时间”、“应用冷启动时间”；应用性能提标是指在执行业务过程中，应用综合性能情况，评测指标分别为：“CPU消耗”、“内存消耗”、“流量消耗”。

五、相关指标计算方法说明

“业务操作耗时”：是指基于UI层点击一个动作到识别下一个对象（或控件）之间的时间，用来衡量页面加截的快慢，用户体验的重要性能指标。

“Apdex指数”：Apdex(APPlication Performance Index)是一个国际通用标准，Apdex 是用户对应用性能满意度的量化值。它提供了一个统一的测量和报告用户体验的方法，把最终用户的体验作为一个完整的指标进行统一度量。用于衡量用户对应用性能满意度的量化标准。它是一个评分标准，范围在0-1之间（0代表没有用户满意，1代表所有用户满意）。计算方法：Apdex指数=（满意样本+0.5*容忍样本）/总样本数*100%。在本次综合测评中，以业务操作耗时做为计算对象，设计满意样本值为5秒，容忍样本值为5-8秒。

“应用冷启动时间”：是指当APP启动时，后台没有此APP的进程，启动时系统会重新创建一个新的进程分配给该APP，这样启动应用的方式叫冷启动（后台不存在此APP进程），整个过程所消耗的时间为“应用冷启动时间”。通过系统Adb命令获得。

“应用启动”时间：是指基于UI操作，点击应用，正常进入到业务操作界面并识别目标对象所花的时间。针对各家应用启动有加载广告的现象，在计算“应用启动时间”时，各家将减去广告加载的时间，其中有时间长短提示的的APP将减去提示的时间；没有时间长短提示的（有广告），按统一标准减去3秒来进行计算。

六、券商抽样说明

本次抽样的20家券商，包含综合实力排行业TOP10的大券商手机APP应用，也有综合实力排行业中下的中、小券商的手机APP应用，报告中不涉及具体企业。

附报告下载地址：http://u6.gg/rKSQD


云监控服务

依托Testin云测手机真机云平台，基于领先的Testin云测自动化技术，从最终用户视角实现用户业务感知和业务持续可用性监测。帮助企业及时发现和快速定位问题，为开发团队和业务运营团队提供数据支撑，简化企业应用优化和故障排查工作，实时监测系统运营风险。

详情访问：http://u6.gg/rKK95

                    
          
1、前言
随着项目版本的迭代，App的性能问题会逐渐暴露出来，而好的用户体验与性能表现紧密相关，性能问题从应用的启动优化开始，下面会根据实际app性能测试案例，进行app性能评测之启动时间的分析和总结。
2、App启动方式了解
通常来说, 一个App启动也会分如下三中不同的状态:

冷启动

当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动，也就是先实例化Application
冷启动的流程即为App启动流程的全过程, 需要创建App进程, 加载相关资源, 启动Main Thread, 初始化首屏Activity等.

在这个过程中, 屏幕会显示一个空白的窗口(颜色基于主题), 直至首屏Activity完全启动.

下图展示了冷启动的时间线:






冷启动流程.png



热启动

当启动应用时，后台已有该应用的进程，这时会从已有的进程来启动Activity（不需要重新创建Application）

类同与冷启动, 在这个过程中, 屏幕会显示一个空白的窗口(颜色基于主题), 直至activity渲染完毕.



温启动

介于冷启动和热启动之间, 一般来说在以下两种情况下发生:
用户back退出了App, 然后又启动. App进程可能还在运行, 但是activity需要重建.
用户退出App后, 系统可能由于内存原因将App杀死, 进程和activity都需要重启, 但是可以在onCreate中将被动杀死锁保存的状态(saved instance state)恢复.

通过三种启动状态的相关描述, 可以看出我们要做的启动优化其实就是针对冷启动. 热启动和温启动都相对较快.
3、性能评测结果案例分析
3.1 XX银行 APP启动时间评测结果分析
3.1.1 启动时间测试结果
统计的时间为APP的冷启动时间，4G网络情况下，平均冷启动时间为14.1S，平均热启动时间为6.7S,无网络时平均启动时间为5.2S。由于APP的启动时间耗时远远超过行业标准水平3S，当app启动时，任何一个地方有耗时操作都会拖慢我们应用的启动速度，所以针对APP启动时间做了具体分析
3.1.2评测结果分析

首先来看App从点击桌面图标到我们看到App的主界面整个过程中经过了哪些步骤：

启动虚拟机—>启动AMS —>通过Zygote创建ApplicationProcess进程–>Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量布局绘制显示在界面上。

1）初始化Application
【初始化Application】应用程序初始化总共耗费了3.26S，耗时已超过行业APP启动标准基线时间3S。具体看下耗时详情分析：

（1）应用Application.attach的时间较长。应用存在多个dex文件，请控制应用方法数量。

（2）onCreate方法耗时长，主要体现BaseApplication创建上。

长耗时方法排名如下:

1.com.pingan.fstandard.framework.base.BaseApplication.onCreate(BaseApplication.java)
com.pingan.fstandard.common.c.a(InitManager.java)
com.pafinancialtech.pafs.kitchendaddy.f.b(PAFFToast.java:83

4.com.pingan.fstandard.HomeApplication.d(HomeApplication.java:51

综上分析，BaseApplication创建上耗费较长时间，需要开发进行更详细的分析优化。另外，初始化Application时，也包含了任意门相关等非核心功能的程序，建议启动时不创建该类程序。
2）初始化Activity
【初始化Activity】耗时也过长，耗时约1s左右

主要耗时的地方是在闪屏界面创建oncreate时com.pingan.fstandard.activity.SplashActivity.onCreate，建议开发优化
3）加载请求及响应
首先来一张流程图了解一下我们APP首页加载的一个流程





页面加载流程.png






冷启动资源加载.png

【网络请求及响应】总体来看，首页加载耗时占比最多，需要6s左右，对应的网络消耗时间占比45%左右。

根据抓包及代码段分析显示APP启动到首页加载完成是一个预加载和异步加载的过程。

(1) 项目中大部分第三方组件都抢占先机，在Application主线程初始化。这样的初始化方式肯定是过重的，建议考虑异步初始化三方组件，不阻塞主线程；延迟部分三方组件（比如埋点统计、任意门、ImageLoader的初始化）。

(2) 启动到首页加载完成网络请求密集，请求内容丰富,部分资源重复请求。

请求了相关配置信息、启动页广告、个推、磁贴配置信息、商城理财产品列表，运营广告Banner、F后端接口，广告BANNER位、插件信息、任意门、百度地图SDK（talkingdata、灰度升级）等林林总总加起来就有40+个网络请求，加载的数据+广告页一共有1.7M左右，这说明了我们的APP首页设计的内容比较丰富，部分资源重复请求，部分内容需要调外部接口，所以耗时比较长，这是产品设计问题、信息未做缓存处理和部分外部关联方接口响应慢的原因导致，建议优化。

（3）非核心功能资源过早请求加载

另外其中类似百度地图SDK、任意门、微信sdk相关插件只有在生活页\分享时使用到的非主要业务功能启动时也加载出来了，建议开发同学和产品同学调整APP启动时网络请求的加载策略，非核心/主要/高PV的功能相关的API,SDK、插件等没有必要在启动时做加载缓存，这是非常耗时且得不偿失的。

3.1.3启动时间优化建议
（1）应用Application.attach的时间较长。应用存在多个dex文件，请控制应用方法数量。

（2）onCreate方法耗时长，主要体现BaseApplication创建上，需要开发进行更详细的分析优化，建议考虑异步初始化三方组件，不阻塞主线程；延迟或者和产品一起梳理需要的去除的部分三方组件（比如统计、任意门、ImageLoader的初始化）。

（3）com.pingan.fstandard.activity.MainActivity存在过度绘制导致卡顿，首页UI布局层次过多，建议开发进一步分析优化

（4）建议产品调整优化app启动时网络请求的加载策略，非核心/主要/高PV的功能相关的API,SDK、插件等没有必要在启动时做加载缓存

（5）部分资源重复请求，建议信息缓存，常用信息只在第一次获取，之后从缓存中取

（6）建议开发梳理无用但被执行的老代码，去掉无用但被执行的老代码
综上，建议开发童鞋尽快投入做APP启动时性能改善和优化，以提升行业相比竞品的竞争力。
4、App端启动耗时排查方法及思路
4.1 排查方法：使用Traceview分析
TraceView 是 Android SDK 中内置的1个工具，它可以加载 trace 文件，用图形的情势展现代码的履行时间、次数及调用栈，便于我们分析。
（1）使用Android Studio工具DDMS
生成Traceview 进行分析查看具体Trace期间各方法调用关系，调用次数以及耗时比例






ddms.png

（2）使用代码生成 trace 文件
  Debug.startMethodTracing("shixintrace");   
 //开始 trace，保存文件到 "/sdcard/shixintrace.trace"
    // ...
    Debug.stopMethodTracing();    //结束

代码很简单，当你调用开始代码的时候，系统会生产 trace 文件，并且产生追踪数据，当你调用结束代码时，会将追踪数据写入到 trace 文件中。

下1步使用 adb 命令将 trace 文件导出到电脑：
adb pull /sdcard/shixintrace.trace /tmp

使用代码生成 trace 方式的好处是容易控制追踪的开始和结束，缺点就是步骤略微多了一点。
（3）直接使用android studio生成trace文件
Android Studio 内置的 Android Monitor 可以很方便的生成 trace 文件到电脑。

注意：此方法仅仅适用于下拉代码到本地生成DEBUG测试包到手机进行调试






monitor1.png






monitor2.png

分析指标：

不应在Application以及Activity的生命周期回调中做任何费时操作，具体指标大概是你在onCreate，onResume，onStart等回调中所花费的总时间最好不要超过400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。

4.2 开启严苛模式（StrictMode）
检查是否有主线程做了耗时操作： 开启 严苛模式（StrictMode）

（1）StrictMode可以用于捕捉发生在应用程序 主线程中耗时的磁盘、网络访问或函数调用，使主线程处理UI和动画在磁盘读写和网络操作时变得更平滑，避免主线程被阻塞，导致ANR窗口的发生。

下面是启用StrictMode的实例，可以在Application的OnCreate中添加，这样就能在程序启动的最初一刻进行监控了。
private void setStrictMode() {
        if (Integer.valueOf(Build.VERSION.SDK) > 3) {
            Log.d(LOG_TAG, "Enabling StrictMode policy over Sample application");
            StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                    .detectAll()    // 这里可以替换为.detectDiskReads().detectDiskWrites().detectNetwork()。
                                    // detectAll() 包括了磁盘读写和网络I/O
                    .penaltyLog()   //打印logcat，当然也可以定位到dropbox，通过文件保存相应的log
                    .penaltyDeath()
                    .build());
            StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                    .detectAll()
                    .penaltyLog()
                    .build());
        }
    }


（2）除了通过日志查看之外，我们也可以在开发者选项中开启严格模式，开启之后，如果主线程中有执行时间长的操作，屏幕则会闪烁，这是一个更加直接的方法。

4.3、通过抓包工具分析
可以通过抓包工具Charels、Fiddler等查看网络请求加载了哪些资源，加载资源的顺序、哪些资源重复加载、信息是否缓存
4.4、查看Logcat
通过adb输出log信息，过滤日志查看APP启动时每个方法的大致耗时。
4.5、启动时间排查思路
对于App来说, 我们可以控制的启动时间线的点无外乎:

Application的onCreate

首屏Activity的渲染

而我们现在的App动不动集成了很多第三方服务, 启动时需要检查广告, 注册状态等等一系列接口都是在Application的onCreate或是首屏的onCreate中做的.
5、启动时间耗时常见原因及优化建议
5.1、 常见主要问题（持续补充ing）
部分数据库及IO的操作发生在首屏Activity主线程；
Application中创建了线程池；
启动时做密集沉重的初始化（Heavy app initialization）；
Multidex的使用，也是拖慢启动速度的元凶；
UI存在过度绘制；
首屏Activity网络请求密集；
非核心功能资源过早请求加载
工作线程使用未设置优先级；
信息未缓存，重复获取同样信息；
流程问题：例如闪屏图每次下载，当次使用；
执行无用老代码；
执行开发阶段使用的代码；
执行重复逻辑；
调用三方SDK里或者Demo里的多余代码；
5.2、建议：
去掉无用但被执行的老代码；
去掉开发阶段使用但线上被执行的代码；
去掉重复逻辑执行代码；
UI渲染优化，去除重复绘制，减少UI重复绘制时间
去掉调用三方SDK里或者Demo里的多余代码；
信息缓存，常用信息只在第一次获取，之后从缓存中取；
项目是多进程架构，只在主进程执行Application的onCreate()；
根据优先级的划分，一些初始化工作能否将任务优先级划分成3个等级,任务优先级为2，3的，通过懒加载的方式在首页渲染完成后进行加载
避免I/O操作、反序列化、网络操作、布局嵌套等。

参考文献:

学习地址：
https://www.cnblogs.com/sunzn/p/3192231.html
http://www.wfuyu.com/technology/27625.html
http://blog.csdn.net/qq_16131393/article/details/51172488


        
        
        
                
    

优秀APP评定标准我个人认为应该从APP自身性能、APP UI、用户粘性方面进行分析

本文部分观点主要针对Android应用

一、APP自身性能
app性能测试主要包含但不仅限于以下方面
响应、崩溃、内存、cpu、GPU过度渲染、耗电

(app除了这些性能测试，还有：FPS、耗流、手机版本号兼容性，屏幕分辨率兼容性，稳定性测试，安全测试等 )
1、响应
软件的响应时间和响应速度直接影响到用户的体验度，如果一个软件，迟迟加载不出来，会直接影响到软件的日活、留存。因此对于一个软件，对响应速度测试是必不可少的。

主要测试点：
1、冷启动：首次启动app的时间间隔（只是启动时间，不包括页面加载）
2、热启动：非首次启动app的时间间隔（只是启动时间，不包括页面加载）

要求：
冷启动时间不超过1.5s, 热启动不超过1s.

2、崩溃现象
在移动应用性能方面，崩溃带来的影响是最为严重的，移动应用崩溃主要是由操作系统引发，是指应用在运行过程中出现的强制关闭(Force Closing)现象，从而打断用户正在进行的操作体验。应用崩溃可以造成关键业务中断、用户留存率下降、品牌口碑变差、生命周期价值下降等影响。
具体情况可参考app的崩溃率标准
3、内存
在Android系统中，每个APP进程除了同其他进程共享内存(shared dirty)外，还独用私有内存(private dirty)，通常我们使用PSS(私有内存+比例分配共享内存)来衡量一个APP的内存开销。由于一个移动设备的内存是固定的，如果内存消耗过大就会造成应用卡顿或者闪退，需要对内存进行测试。正常情况下，应用不应占用过多的内存资源，且能够及时释放内存，保证整个应用内的稳定性和流畅性。

关注点：
1、退出某个页面后，内存是否有回落。如果没有及时回落，且程序自动GC或者手动GC，那便可确认有问题。
2、进行某个操作后，内存是否增长过快。如果增长过快，也有可能存在风险，需重复操作确认。

4、CPU
CPU测试，主要关注的是cpu的占用率。很多时候，我们玩手机时，会出现发热发烫，那是因为CPU使用率过高，CPU过于繁忙，会使整个手机无法响应用户，整体性能降低，用户体验就会很差，也容易引起ANR（application not responding, 主线程(UI线程)如果在规定时内没有处理完相应工作，就会出现ANR）等等一系列问题。
测试点：
1).在空闲时间(切换至后台)的消耗，基本没大应用使用cpu
2).在运行一些应用的情况下，cpu已占50%的情况下，观察应用程序占用cpu的情况
3).在高负荷的情况下看CPU的表现（cpu占用应是在80%以上）

具体场景：
1、应用空闲状态运行监测CPU占用率
空闲状态：应用按Home键退到后台，不再占用系统的状态（通常是灭屏半分钟后）
CPU占用率=0%

2、应用中等规格运行监测CPU占用率
中等规格：模拟用户最常见的使用场景
CPU占用率≤30%

3、应用满规格长时间正常运行监测CPU占用率
Monkey测试
CPU占用率≤30%

4、应用正常运行期间监测CPU占用率峰值
应用正常运行：打开应用进行基本操作
CPU占用率≤50%

5、GPU渲染
GPU渲染是指在一个像素点上绘制多次（超过一次）：显示一个什么都没有做的activity界面算作画了1层，给activity加一个背景是第2层，在上面放了一个Text View（有背景的Text View）是第3层，Text View显示文本就是第4层仅仅只是为了显示一个文本，却在同一个像素点绘制了四次,这是一定要优化的。过度绘制对动画性能的影响是极其严重的，如果你想要流畅的动画效果，那么一定不能忽视过度绘制。
GPU过渡渲染不同的颜色代表不同的绘制程度
1）、原色：无过渡绘制
2）、蓝色：绘制一次 （理想状态）
3）、绿色：绘制二次
4）、浅红：绘制三次 （可以优化）
5）、深红：绘制四次 （必须优化）

测试指标：
1、控制过渡绘制为2x
2、不允许存在4x过渡绘制
3、不允许存在面积超过屏幕1/4的3x过渡绘制

6、耗电量
测试应用对电量的消耗前需要对手机本身的电量消耗有个大概了解，测试前先看规定时间内手机正常待机下（重启后待机）电量消耗为多少。然后再启动待测试APP看看消耗的电量增加了多少取差值。
测试点：
测试手机安装目标APK前后待机功耗无明显差异；
常见使用场景中能够正常进入待机，待机电流在正常范围内；
长时间连续使用应用无异常耗电现象。

二、UI设计
迎合受众的心理是一个好APP的重要特质。APP总要跟用户交互，交互过程应当尽量让人感到愉悦。要做到令人愉悦，就必须认清自己的用户群体，根据他们的特征喜好不断增加细节元素。从而让用户感觉APP是活的
1、UI设计者
规范APP - UI设计标准，有便于以下几点：

1、保证 APP 中各个页面间的显示效果统一

2、UI规范化后，允许 APP 中抽取样式资源文件，便于App的开发；

3、后续有显示效果调整需求时，可统一调整，减少工作量，提高工作效率;
2、开发者
对于开发者那就一句话，还原UI设计 适配好各种屏幕
三、解决用户需求，增加用户粘性
1、切实解决用户需求
用户评价一款App应用时，会首先是从它的用途入手，而真正成功的App应用能够解决用户所面临的问题。除了单纯的使用外，还必须了解用户的年龄段，应用的使用频率、时间、方式等。特别的，对受众群体进行特征分析，可以估测不同受众群体使用情况，预测模型转换。

开发出让用户满意的产品，得弄懂用户的需求。产品需求可以来自用户、客户、销售、领导，也可以来自竞品、技术、以及自我反省。不同时期的用户需求也不一样，产品在开发之前和发布之后所需面对的用户便不一样。

了解这些问题后，可以对App应用有更深刻的见解，并且有的放矢进行资源分配，从而获得更大的利润。
2、如何增加用户粘性
1、聚焦强需求提供内容价值，帮助用户最决策
这些存活下来并且活的很好的低频APP，首先，他们都找到了用户的强需求，比如结婚需要婚庆服务、求职需要找到好企业并且好让企业找到，而那些没有找到强需求的APP，如同无源之水、无本之木，难以生存，基本最后都死了。
2、提供工具价值，扩展APP应用场景
对用户的需求及行为流程的分析，在满足核心消费场景，如投简历、购买旅游产品外，额外提供工具，拓展产品的应用场景覆盖面，让用户的场景访问和使用APP，提升用户粘性。
3、提供社交价值，打造圈子
细分行业APP，本身汇聚有共同关注的用户，互相之间有共同沟通的话题，提供平台，帮助用户打造圈子，通过社交关系黏住客户。

综合以上说说的几点，其实用户行为分析可以这样来看：用户行为分析就是对用户使用产品过程中的所有数据（包括下载量、使用频率、访问量、访问率、留存时间等等）进行收集、整理、统计、分析用户使用产品的规律，为产品的后续发展、优化或者营销等活动提供有力的数据支撑。
1、分析用户行为，那我们应该先确定用户群体特征；
2、用户对产品的使用率。网站类产品主要体现在点击率、点击量、访问量、访问率、访问模块、页面留存时间等等；移动应用产品主要体现在下载量、使用频率、使用模块等等；
3、用户使用产品的时间。比如用户基本是每天中的什么时候使用产品。综合以上说说的几点，其实用户行为分析可以这样来看：用户行为分析就是对用户使用产品过程中的所有数据（包括下载量、使用频率、访问量、访问率、留存时间等等）进行收集、整理、统计、分析用户使用产品的规律，为产品的后续发展、优化或者营销等活动提供有力的数据支撑。

附带参考网站：
Android APP性能及专项测试

app常见性能测试点

app的崩溃率标准