精华内容
下载资源
问答
  • 从事视频编辑4年多, 一直做视频编辑SDK, 积累了大量的做视频编辑APP的客户, 自己手机里装了很多视频编辑APP,是这个行业的从业人员. 对整个产品有一些认识, 谈谈自己的认识; 这里主要谈视频编辑功能, 就是普通用户用...

    前提

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

    时间轴界面是什么

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

    开始

    视频编辑的基础 我认为是三个关键点: 加载快/时间轴顺滑/导出快
    • 如果说视频编辑是一个一个的功能组成, 是枝枝叶叶, 则这三个关键点则是整个产品的骨架, 是撑起整个视频编辑的底层基石.
    1. 加载快.
    • 因为首先你要用户感觉到快, 很轻,手指头点击几下就可以完成的, 是一个很简单的事情, 用户才有编辑的兴趣; 如果很慢, 很笨重, 很卡, 会让用户望而却步, 从而不再使用.没有人喜欢等待, 没有人喜欢麻烦. 选择好一个视频, 下一步直接打开编辑界面, 这中间不能有等待加载导入, 因为加载导入的时间长会让用户感觉视频很沉重, 用户打开视频编辑界面时,他就大概想好了要做什么, 比如"想把画面左右裁剪一下",“去掉声音”, “某个地方加特效”,“剪去前后一些时长”, “把某个好玩的地方调速一下”, "增加一些说明文字"等等. 用户本来想调整一下,大部分时候是灵感或突发性的想法, 你让用户在打开的时候, 等待很长时间, 则兴趣全无. 可能最后说声:“算了,用别的APP吧”. 故视频加载一定要快, 一定要让用户感觉视频编辑就是手边上的工具, 信手拈来,顺手就做了的事情, 故加载快是前提.
    2. 时间轴顺滑.
    • 用户顺手加载进去一个视频, 下一步,就是找到自己要编辑的时间点. 这个[找] 也要快, 比如用户拍了30秒的时候, 用户想在第10秒处增加一个"哇塞"这样的声音, 我认为最好的体验就是, 滑动时间轴,极快的刷新到用户想要的那个画面, 中间不能卡顿, 要让用户感觉录好的视频,就是很多个连续的图片而已, 像拿到一本书一样, 直接翻到那一页, 弹出素材框, 选中"哇塞"声音, 点击就增加了一个时间轴, 然后调整下就做完了.
    • 用户各种功能增加完毕后, 他大概率的会去再次拖动时间轴, 会再次去预览下自己编辑的是否是自己心中要的, 就是他自己会"过一遍", 他的大致操作是: 快速的滑动时间轴, 查看是否完好.类似他把一本书做好了个各种笔记, 他要从头到尾翻一遍一样, 这时更反应了时间轴顺滑的意义, 如果慢了,沉重复杂,耐心去等待, 这样编辑一个视频,本来是顺手做的事情, 慢会导致体验差.
    • 再者, 各种功能也是依次增加到对应的时间轴的, 是以时间轴为参考增加的, 即使你从0到最后一秒完全增加一个效果功能, 也会在增加后, 滑动时间轴看下,这个效果增加的是否合适, 是否舒服, 和录制的视频是否搭配.
    • 时间轴顺滑, 可最大程度的消除用户心中的排斥感, 让用户自己感觉他录好的东西, 触手可及, 录制的每个画面都是可以用手感觉到的, 是自己走进这个画面里的.
    3. 导出快:
    • 不用多说, 类似用户对一本书标记完毕后, 把书本合上的过程. 很快的导出,分享出去, 完成处理. 用户感觉 视频编辑是一个轻松愉快的过程.就是手边上的一个工具, 下一次还会打开使用.
    展开全文
  • 随着中国经济的蓬勃发展,金融行业迎来了前所未有的发展机会,证券行业作为金融市场的重要组成部分,获得了发展的红利,但同时也面临着巨大的挑战。在移动化已经全面融入人们生活的背景下,完成系统的、高质量的移动...

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

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

    (一) 业务性能评测

    业务操作平均耗时评测

    证券行业手机APP业务运营质量综合评测报告

     

    证券行业手机APP业务运营质量综合评测报告

     

    业务Apdex指数评测

    证券行业手机APP业务运营质量综合评测报告

     

    证券行业手机APP业务运营质量综合评测报告

     

    (二) 基础性能评测

    应用崩溃率评测

    证券行业手机APP业务运营质量综合评测报告

     

    应用安装包大小评测

    证券行业手机APP业务运营质量综合评测报告

     

    应用安装时间评测

    证券行业手机APP业务运营质量综合评测报告

     

    应用冷启动时间评测

    证券行业手机APP业务运营质量综合评测报告

     

    (三) 应用性能评测

    应用CPU平均消耗评测

    证券行业手机APP业务运营质量综合评测报告

     

    内存平均消耗评测

    证券行业手机APP业务运营质量综合评测报告

     

    应用网络流量平均消耗

    证券行业手机APP业务运营质量综合评测报告

     

    (四) 综合评测结语

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

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

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

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

    (五) 综合评测说明

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

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

    证券行业手机APP业务运营质量综合评测报告

     

    三、本次抽样综合测评是对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

    展开全文
  • 随着项目版本的迭代,App的性能问题会逐渐暴露出来,而好的用户体验与性能表现紧密相关,性能问题从应用的启动优化开始,下面会根据实际app性能测试案例,进行app性能评测之启动时间的分析和总结。 2、App启动方式...

    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)

    1. com.pingan.fstandard.common.c.a(InitManager.java)
    2. 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评定标准

    千次阅读 2019-11-24 20:46:57
    优秀APP评定标准我个人认为应该从APP自身性能、APP UI、用户粘性方面进行分析 一、APP自身性能 app性能测试主要包含但不仅限于...软件的响应时间和响应速度直接影响到用户的体验度,如果一个软件,迟迟加载不出来,...

    优秀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的崩溃率标准

    展开全文
  • app的启动模式分为三种: 1.冷启动 冷启动耗时最久,衡量的保准最多 Click Event - IPC - Process.start - ActivityThread - bindApplication - LifeCycle - ViewRootImpl 用户在桌面点击app 发起一个IPC操作,...
  • 前言:相信很多刚刚步入测试行业的小伙伴对于APP测试不是很熟悉,这次我为大家提供一篇宝藏文章,希望大家喜欢,谢谢! 一、APP测试基本流程 1、流程图 2、测试周期 测试周期可按项目的开发周期来确定测试时间,...
  • 移动 App 测试

    2018-02-24 15:44:29
    移动APP测试讲义 本篇讲义主要阐述APP的手工测试要点,并概括介绍主流的APP测试框架。 1. APP测试的准备 在进行APP测试之前,需要准备下列步骤。通过以下网站可以查找。 移动观象台:...
  • 移动App开发

    2020-03-14 02:45:13
    移动 App 开发 Native App-原生开发 开发技术 原生的 Android 平台 原生的 iOS 平台 JavaScript bridge 用于原生应用中的 Web 和原生平台进行交互。 https://github.com/lzyzsd/JsBridge 博学谷 - 在职加薪课 ...
  • APP测试流程

    2018-11-04 22:01:36
    1APP测试基本流程 1.1流程图   1.2测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认...
  • Android App性能评测分析-启动时间篇   1、前言 随着项目版本的迭代,App的性能问题会逐渐暴露出来,而好的用户体验与性能表现紧密相关,性能问题从应用的启动优化开始,下面会根据实际app性能测试案例,进行app...
  • 免费App开发解决方案 一键生成App

    千次阅读 2018-06-25 11:47:55
    Mob App工厂,顾名思义指生产App的一个工厂,这个工厂目前能生产四种类型的App模板(新闻类App、商城类App、社交类App、WordPress),可大量生产不同种类App,满足多种行业需求。Mob App 工厂依托于Mob开发者平台...
  • APP测试梳理

    2018-02-27 11:51:14
    1 APP测试基本流程1.1流程图 1.2测试周期测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期...
  • APP测试

    2019-09-18 21:34:49
    那么我们就要先来了解,web和app的区别。 web项目,一般都是b/s架构,基于浏览器的,而app则是c/s的,必须要有客户端。那么在系统测试测试的时候就会产生区别了。 系统架构 来看的话,web测试只要更新了服务器端...
  • APP功能测试点

    2017-07-31 11:32:31
    1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景,对比说明或需求,整理出内在、外在及非功能直接相关的需求,构建测试点,并明确测试标准,若用户需求中无明确标准遵循,则...
  • 转载自: ... ...测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。 1.3测试资源 测试任务开始前,检查各项测
  • 移动 App 开发 Native App-原生开发 开发技术 原生的 Android 平台 原生的 iOS 平台 JavaScript bridge 用于原生应用中的 Web 和原生平台进行交互。 https://github.com/lzyzsd/JsBridge 博学谷 - 在职加薪课 ...
  • 前言:相信很多刚刚步入测试行业的小伙伴对于APP测试不是很熟悉,这次我为大家提供一篇宝藏文章,希望大家喜欢,谢谢! 一、APP测试基本流程 1、流程图 2、测试周期 测试周期可按项目的开发周期来确定测试时间,...
  • APP 安全测试

    2018-07-17 18:49:24
    3)对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测 4)限制/允许使用手机功能接人互联网 5)限制/允许使用手机发送接受信息功能 6)限制/允许应用程序来注册自动启动应用程序 7)...
  • 关于工厂类app的一些想法

    万次阅读 2019-09-17 21:09:19
    该朋友以前从事互联网行业,一提起app,就想到短时频分享、直播、百度地图等。我在去年恰好在一家制造业公司做工业大数据类的app开发,我觉得,工业类的app还是大有可为的。 一.工业类app和互联网app的区别 ...
  • APP测试内容

    2020-04-16 10:34:54
    1. APP测试的准备 在进行APP测试之前,需要准备下列步骤。通过以下网站可以查找。 移动观象台:http://mi.talkingdata.com/terminals.html 1 确定APP的设备 选定被测试的设备终端。 记录设备的品牌 记录设备的...
  • App测试中常见的测试点
  • 移动端APP测试

    2018-06-13 15:35:04
    移动端APP测试1 APP测试基本流程1.1 流程图1.2 测试周期测试周期可按照项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据目前的情况以及版本质量可适当缩短或延长测试时间。正式测试前...
  • 关于app测试

    2020-05-19 08:12:39
    第一章 手机app业务功能测试 手机测试分类 常用手机操作系统系统介绍 手机app业务功能测试内容 手机测试分类 手机整机功能测试 手机app业务功能测试 主要涵盖测试内容: UI测试、功能测试、交叉事件测试、兼容性测试...
  • 移动APP测试

    千次阅读 2018-09-11 15:33:04
    1. APP测试的准备 在进行APP测试之前,需要准备下列步骤。通过以下网站可以查找。 移动观象台:http://mi.talkingdata.com/terminals.html 1 确定APP的设备 选定被测试的设备终端。 记录设备的品牌 记录设备的...
  • App测试使用指南

    2018-05-17 13:59:45
    译者注:本文从测试人员的角度出发,提出了100多个在测试移动App过程中需要考虑的问题。不管你是测试人员、开发、产品经理或是交互设计师,在进行移动App开发时,这些问题都很有参考价值。测试人员常被看作Bug...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,798
精华内容 5,119
关键字:

行业app加载时间