您正在使用IE低版浏览器，为了您的雷锋网账号安全和更好的产品体验，强烈建议使用更快更安全的浏览器
发私信给maomaobear
导语：对于安卓手机，我们听到最多的抱怨就是不流畅，在选购前，问的最多的问题也是这款手机流畅不流畅。
同步到新浪微博
技术偏执狂，深度分析师，关注科技、互联网、汽车。
当月热门文章
为了您的账户安全，请
您的邮箱还未验证,完成可获20积分哟！
您的账号已经绑定，现在您可以以方便用邮箱登录判断App是否在后台运行
来源：博客园



 
在一些场景中，经常会需要判断App是否在后台运行，比如是否显示解锁界面，收到新消息是否显示Notification等。需求可能是多样化的，但所依仗的原理是相通的，今天Stay打算说说这些需求的最优解。
当然，Stay肯定不会说去for loop判断当前runningProcess或者runningTasks。比如：
这样

或者这样

这种方法调用起来感觉就像是在用Windows系统里的任务管理器，真是让人蛋疼。我们暂且不去计较性能问题，就说为啥Android连个像样的API都不给我，着实让人郁闷。
如果带着这样的质疑去调研，你会发现还真有其他方式来实现。
Android在SDK 14的时候提供了一个Callback。ActivityLifecycleCallbacks，你可以通过这个Callback拿到App所有Activity的生命周期回调。看图：
这个Callback写在Application里的，你可以在Application初始化的时候来注册。我们可以写个单例类来cache这些status。这里我叫它AppStatusTracker。在Application的onCreate()里让AppStatusTracker注册ActivityLifecycleCallbacks。

拿到这些Callback有什么用呢，我怎么能知道App是否在前台运行呢。 
别急，我们先来说说Activity的生命周期。这是面试时必问题，虽然有官方答案，但真正理解生命周期，并灵活运用的不多。
我们来设想下如果Activity调用了onResume()，那么这个Activity肯定是可见的，也就是运行在前台的。如果调用了onPause()，且没有Activity来调用onResume()，那么App要跑到后台去了。至于它是点了home键还是back键我都不管。
通过这样的判断，我们来利用ActivityLifecycleCallbacks回调的onActivityResumed()和onActivityPaused()方法来计数，如果只有一个activityCount，那么当前App在前台，如果木有activityCount，它就在后台。
好了，就这么愉快的解决了，再也不用for loop了。但是很快你会发现，这里有个延时，会导致判断不准确。
我们假设有两个Activities，一个A，一个B，从A跳转到B，生命周期怎么走的？ A.onPause() -& B.onResume() 对应到ActivityLifecycleCallbacks里是onActivityPaused(A) -& onActivityResumed(B)，刚才我们说的计数resumeCount，在onActivityPaused()里--，在onActivityResumed()里++， 根据这样的判断会有个短暂的间隔，也就是在A的onPause()到B的onResume()之间，App是运行在后台的，这样逻辑肯定就不对了。
那如何解决问题呢？如果你打印过生命周期的哪些方法，你会发现是Activity间切换的步骤是这样的： 
从WelcomeActivity跳转到GestureActivity。（这里只说onStart, onResume这些回调 ）A.onPause() -& B.onStart() -& B.onResume() -& A.onStop()
我估摸着60%的同学都没想过Activities之间切换的生命周期是什么样的。
 
通过这些回调我们可以将这个计数放在onStart()和onStop()中去，这样就不会存在那个短暂间隔。activityCount==1，那么就是前台，activityCount==0，那就是后台。这样判断很很简单了吧。
现在再说，什么情况下来显示手势解锁界面。 我的需求是当用户锁屏后再解锁或者切换到后台10分钟后显示手势解锁界面。 我们拆分下需求，先说锁屏，解锁。
这个是有BroadCastReciever来接收的，注册下就可以了，每次收到锁屏ACTION_SCREEN_OFF的action时，将AppStatusTracker里的isScreenOff设置为true。 当onActivityResumed()被调用时再将isScreenOff设为false。
再说切换到后台10分钟后显示手势解锁。这个只需要在onActivityStop()时更新下lastBackgroudTimestamp就可以了
核心代码如下：

原理很简单，但是涉及到的知识点很重要，大家可以自己写写测试下，别总依赖别人的代码，别人的类库，技术实现很简单，但需求的变体扩展有时候还是需要自己来想办法解决的。
 



 





免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动1525人阅读
android（14）
移动互联（21）
转载（134）
手机APP项目测试点(内容)总结
对于手机项目（应用软件），主要是进行系统测试。
而针对手机应用软件的系统测试，我们通常从如下几个角度开展测试工作：
功能模块测试
交叉事件测试
兼容性测试
易用性/用户体验测试
硬件环境测试
安装/卸载测试
升级/更新测试
1、功能模块测试：
根据软件需求说明书或者用户需求验证app的各个功能是否实现，采用如下方法实现并评估功能测试过程：
采用时间、地点、对象、行为、和背景五元素或业务分析等方法、提炼app的用户使用场景，对比说明和需求，整理出内在，外在及非功能直接相关需求，构建测试点和用例，并明确测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。
根据被测试功能点的特性列出相应类型的测试用例对其进行覆盖，如：涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。
在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误地方。
1）App安装完成后的试运行，可正常打开软件。
2）App打开测试，是否有加载状态进度提示。
3）App打开速度测试，速度是否可观。
4）App页面间的切换是否流畅，逻辑是否正确
--同表单编辑页面
--用户名密码长度
--注册后的提示页面
--前台注册页面和后台的管理页面数据是否一致
--注册后，在后台管理中页面提示
--使用合法的用户登录系统。
--系统是否允许多次非法的登陆，是否有次数限制。
--使用已经登陆的账号登陆系统是否正确处理。
--使用禁用的账号登陆系统是否正确处理。
--用户名、口令（密码）错误或漏填时能否登陆。
--删除或修改后的用户，原用户登陆。
--不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。
--登陆后，页面中登陆信息。
--页面中有注销按钮。
--登陆超时的处理。
--注销原模块，新的模块系统能否正确处理。
--终止注销能否返回原模块，原用户。
--注销原用户，新用户系统能否正确处理。
--使用错误的账号、口令、无权限的被禁用的账号进行注销
应用的前后台切换
1) APP切换到后台，再回到app，检查是否停留在上一次操作界面。
2) APP切换到后台，再回到app，检查功能及应用状态是否正常，IOS4和IOS5的版本的处理机制有的不一样。
3) app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
4) 手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
5) 当App使用过程中有电话进来中断后再切换到app，功能状态是否正常
6) 当杀掉app进程后，再开启app，app能否正常启动。
7) 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。
8) 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。
很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来使用app.
1) app有免登录功能时，需要考虑IOS版本差异。
2) 考虑无网络情况时能否正常进入免登录状态。
3) 切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。
4) 根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。
5) app切换到后台，再切回前台的校验
6) 切换到后台，再切换回前台的测试
7) 密码更换后，检查有数据交换时是否进行了有效身份的校验
8) 支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误。
9) 检查用户主动退出登录后，下次启动app，应停留在登录界面
根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。
1) 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新。
2) 确定哪些地方从后台切换回前台时需要进行数据更新。
3) 根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。
4) 确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试。
5) 检查有数据交换的地方，均有相应的异常处理。
很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。
1) 在无网络情况可以浏览本地数据
2) 退出app再开启app时能正常浏览
3) 切换到后台再切回前台可以正常浏览
4) 锁屏后再解屏回到应用前台可以正常浏览
5) 在对服务端的数据有更新时会给予离线的相应提示
1) 当客户端有新版本时，有更新提示。
2) 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。
3) 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。
4) 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。
5) 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。
6) 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。
定位、照相机服务
1) App有用到相机，定位服务时，需要注意系统版本差异
2) 有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。
3) 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。
4) 测试定位、照相机服务时，需要采用真机进行测试。
客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响。
--中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东8区时间时，再查看则显示为10：00。
1) 检查push消息是否按照指定的业务规则发送
2) 检查不接受推送消息时，检查用户不会再接收到push.
3) 如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。
在非免打扰时间段，用户能正常收到push。
4) 当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。
5) 测试push时，需要采用真机进行测试。
2、交叉事件测试：又叫事件冲突测试
是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰测试。如：App在前/后台运行状态时与来电、文件ixaz、音乐收听等关键运用的交互情况测试等。
多个App同时运行是否影响正常功能。
App运行时前/后台切换是否影响正常功能。
App运行时拨打/接听电话。
App运行时发送/接收信息。
App运行时发送/收取邮件。
App运行时切换网络（2G/3G/WIFI）.
App运行浏览网页。
App运行时使用蓝牙传送/接收数据。
App运行时使用相机、计算器手机自带设备。
App运行时插拔充电器。
执行干扰的冲突事件不能导致软件应用软件异常、手机死机或者花屏等严重问题，还需要注意各交叉事件的优先级别，检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级别较低的事件吊死。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题。
3、性能测试：评估App的时间和空间特性&
极限测试：
在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。
--内存满时安装App
--运行App时手机断电
--运行App时断掉网络
响应能力测试：
测试App中的各类操作是否满足用户响应时间要求 。
--App安装、卸载的响应时间
--App各类功能性操作的影响时间
压力测试：
反复/长期操作下、系统资源是否占用异常。
--App反复进行安装卸载，查看系统资源是否正常
--其他功能反复进行操作，查看系统资源是否正常
性能评估：
评估典型用户应用场景下，系统资源的使用情况。
Benchmark测试（基线测试）：与竞争产品的Benchmarking, 产品演变对比测试等。
特定场景测试
1.通过模拟终端低电量（例如5%电量）的状态来测试功能在该状态下的正确性
2.通过模拟终端处于特殊地理位置（例如上海）来测试功能在该状态下的正确性
3.通过模拟终端处于特定网络状态下（例如3G）来测试功能在该状态下的正确性
深度性能测试
1.获取App在典型使用场景及状态下消耗的电量流量消耗
2.获取App在典型使用场景及待机状态下消耗的流量
3.获取App在典型使用场景及待机状态下的CPU占用率
4.获取App在典型使用场景及待机状态下内存量
5.获取App冷启动和热启动耗时内容
6.获取App特定页面的内容加载耗时
7.获取App退出的耗时
8.获取App在典型使用场景下帧率&
4、安全测试：
--扣费风险：包括发送短信、拨打电话、连接网络等
--隐私泄露风险：包括访问手机信息、访问联系人信息等
--对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测
--限制/允许使用手机功能接人互联网
--限制/允许使用手机发送接受信息功能
--限制/允许应用程序来注册自动启动应用程序
--限制或使用本地连接
--限制/允许使用手机拍照或录音
--限制/允许使用手机读取用户数据
-- 限制/允许使用手机写人用户数据
--检测App的用户授权级别、数据泄漏、非法授权访问等
安装与卸载安全性
--应用程序应能正确安装到设备驱动程序上
--能够在安装设备驱动程序上找到应用程序的相应图标
--是否包含数字签名信息
--JAD文件和JAR包中包含的所有托管属性及其值必需是正确的
--JAD文件显示的资料内容与应用程序显示的资料内容应一致
--安装路径应能指定
--没有用户的允许, 应用程序不能预先设定自动启动
--卸载是否安全, 其安装进去的文件是否全部卸载
--卸载用户使用过程中产生的文件是否有提示
--其修改的配置信息是否复原
--卸载是否影响其他软件的功能
--卸载应该移除所有的文件
--验证App是否能正确安装、运行、卸载，以及操作过程和操作前后对系统资源的使用情况，主要包括：
--检测软件是否能正确安装、运行、卸载；大量真机多维度测试,兼容性测试无死角
--安装、卸载、更新错误报告；包含安装、卸载、高/低版本覆盖安装
--用于检测的安全软件包括：百度手机管家、LBE、QQ手机管家、网秦、安卓优化大师
数据安全性
--当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码
--输人的密码将不以明文形式进行显示
--密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上
--不同的应用程序的个人身份证或密码长度必需至少在4一8 个数字长度之间
--当应用程序处理信用卡明细, 或其他的敏感数据时, 不以明文形式将数据写到其它单独的文件或者临时文件中。以
--防止应用程序异常终止而又没有侧除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息。
--当将敏感数据输人到应用程序时, 其不会被储存在设备中
--备份应该加密, 恢复数据应考虑恢复过程的异常
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1550253次
积分：16707
积分：16707
排名：第462名
原创：207篇
转载：435篇
评论：217条
(11)(6)(9)(6)(4)(33)(6)(7)(6)(5)(1)(10)(4)(2)(8)(7)(16)(8)(2)(4)(7)(4)(4)(14)(8)(20)(59)(7)(9)(3)(6)(5)(5)(5)(28)(5)(1)(1)(4)(5)(4)(4)(12)(6)(12)(11)(1)(10)(1)(1)(3)(4)(4)(2)(6)(7)(10)(7)(9)(3)(4)(3)(1)(10)(8)(8)(9)(4)(9)(10)(4)(2)(8)(1)(1)(1)(1)(1)(3)(3)(3)(3)(4)(15)(25)(7)(13)(8)(15)(26)后使用快捷导航没有帐号？
其他登录方式
查看: 1668|回复: 9
在线时间314 小时最后登录阅读权限20UID452972注册时间积分601精华0
, 积分 601, 距离下一级还需 99 积分
主题帖子 金币1376 元 智豆1 点
本帖最后由 盖世英雄0823 于
17:13 编辑
对于安卓手机，我们听到最多的抱怨就是不流畅，在选购前，问的最多的问题也是这款手机流畅不流畅。
有的人看配置，但是同样配置的手机，流畅性天差地别，而有些低配手机反而很流畅；有的人看跑分，但是有些手机跑分很高，流畅性却很差；更糟的是，因为人和人的流畅标准不同，同样的手机，张三觉得不流畅，李四觉得还不错，选购前问别人也无法有个正确的参考。
那么到底应该看什么呢？我们来做个解读。
一、什么是手机的流畅性
所谓手机的流畅性，其实是 iPhone 出现后，手机有了拖动滑屏概念以后出现得。以前电阻屏，WM 系统的手机是谈不上拖动流畅的。
而屏幕要滑动，就有个帧数的概念。我们看到的动态画面，是一帧帧静态画面联动起来后达到的。这利用了人眼的视觉暂留。一秒内静态画面越多，我们眼睛的感觉就越流畅。静态画面的数量，我们叫帧数。
我们看到的电影是 24 帧到 29 帧，就是一秒钟 24 幅静态画面，因为电影的每一帧都是模糊帧，包含一定的时间信息，所以 24 帧我们看着就很流畅了。
我们看的动画、玩 3D 游戏，因为每一帧都是清晰的画面，所以需要 1 秒钟 60 帧才会感觉流畅，有些眼睛特别敏感的甚至需要 85 帧。不过大多数人 60 帧就足够了，所以我们的液晶屏幕都是每秒 60 帧来刷新的。而手机要流畅，也需要在滑动的时候达到每秒 60 帧，这就是手机的流畅性。
二、手机的流畅性如何测试？
手机的流畅性，其实是分不同场景的。在滑动桌面的时候流畅，但是玩游戏就不一定流畅；看视频的时候流畅，但是缩放图片的时候就不一定流畅。所以手机流畅性的测试也需要多种软件和方法。
（一）系统界面的流畅性
系统界面的流畅性，我们通常用一个软件 MobileXPRT 2013，这个软件带有两个测试项目，一个是性能测试，还有一个是用户体验测试。性能测试和诸如安兔兔之类的性能测试差不多，跑的是处理器的理论性能，而用户体验测试就可以测试出来系统界面的流畅性。
UX Tests 就是测试用户体验的
上图是用户体验测试的具体项目，包括菜单滑动、界面滑动、图库滑动、网页浏览滑动和放大缩小。就这台手机的测试项目来看，图库滑动的帧数不足，会有不流畅的感觉，其他滑动都是 60 帧，系统体验还是非常流畅的。
（二）常用软件的流畅性
MobileXPRT 2013 的用户体验测试虽然不错，但是只能代表系统自带用户界面的流畅性，不能代表用户所使用软件的流畅性，而用户使用软件是个性化的。如何判断自己常用的软件在准备购买的手机上是否流畅呢？
这种情况我们用 FPS meter 来测试，FPS meter 是一个实时帧数显示软件（需要 root），后台运行，可以实时显示当前程序滑动或者运行的帧数。
开启这个软件，然后打开你常用的程序，快速滑动（测游戏不需要滑动，只要看帧数）看这个软件显示的实时帧数是否在 60 以上，就可以判断你常用的程序能否在手机上运行流畅。
三、帧数之外的流畅性
除了帧数以外，还有两个因素决定着人们使用安卓手机的流畅性。
（一）程序开启速度
在点击程序后，程序多长时间开启，直接决定用户体验。这个就是硬件性能比拼，但是简单看安兔兔总分是看不出来的，因为安兔兔总分包含东西太多，你看安兔兔得分里面的安卓虚拟机得分一项比较准确，
（二）响应时间
安卓系统有个毛病，就是触摸和屏幕响应的间隔时间比较长。Windows 和 IOS 都要好很多。这也是各个厂商优化的重点所在，这个测试没有软件可以解决，高速摄像机用户不具备，有个建议的方法是拖动图标快速转圈，看图标和手指的距离远近，同样转圈速度，图标距离手指的距离越近越好。
安卓通常的安兔兔跑分并不能代表用户体验，高配置因为高分辨屏幕和系统优化的原因，也未必能带来流畅体验，而上述的几个方法可以比较准确的测试安卓手机是否流畅，拿起你的手机试一下吧。
/android-fluent.html
附件: 你需要才可以下载或查看附件。没有帐号？
在线时间897 小时最后登录阅读权限40UID注册时间积分2542精华0
, 积分 2542, 距离下一级还需 458 积分
主题帖子 金币7059 元 智豆448 点
好像不错！！
在线时间646 小时最后登录阅读权限1UID705144注册时间积分4190精华0
头像被屏蔽
主题帖子 金币4128 元 智豆1 点
提示: 作者被禁止或删除 内容自动屏蔽
签名被屏蔽
在线时间14 小时最后登录阅读权限1UID注册时间积分367精华0
头像被屏蔽
主题帖子 金币380 元 智豆0 点
提示: 作者被禁止或删除 内容自动屏蔽
在线时间11 小时最后登录阅读权限20UID注册时间积分693精华0
, 积分 693, 距离下一级还需 7 积分
主题帖子 金币1189 元 智豆0 点
回复一下吧
在线时间60 小时最后登录阅读权限1UID注册时间积分778精华0
头像被屏蔽
主题帖子 金币1837 元 智豆0 点
提示: 作者被禁止或删除 内容自动屏蔽
在线时间61 小时最后登录阅读权限1UID注册时间积分1108精华0
头像被屏蔽
主题帖子 金币1466 元 智豆0 点
提示: 作者被禁止或删除 内容自动屏蔽
在线时间61 小时最后登录阅读权限1UID注册时间积分1108精华0
头像被屏蔽
主题帖子 金币1466 元 智豆0 点
提示: 作者被禁止或删除 内容自动屏蔽
在线时间274 小时最后登录阅读权限45UID注册时间积分4768精华0
, 积分 4768, 距离下一级还需 232 积分
主题帖子 金币1290 元 智豆0 点
谢谢楼主的共享
在线时间21 小时最后登录阅读权限20UID注册时间积分495精华0
, 积分 495, 距离下一级还需 205 积分
主题帖子 金币827 元 智豆0 点
回复一下吧
【每日话题】说到任性，撒过泼，打过滚，吹过牛逼，灌过水......Android判断App前台运行还是后台运行(运行状态)
作者：一叶飘舟
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了Android判断App前台运行还是后台运行的相关资料,需要的朋友可以参考下
本文通过图文并茂的方式给大家介绍android判断app状态的相关内容，具体详情如下所示：
要了解这块，首先需要明白一些概念，app，process,task
1.process就是进程，是linux的概念。
2.一般一个app拥有一个uid，运行在一个进程里，如果app中给service等定义不同的uid，那Service就运行在另外一个进程里，也就是说uid就相当于进程的id一样，一个uid就代表一个进程；也可以几个app定义一个uid，那他们就运行在一个进程里了。
3.task是android系统的一个activity的栈，包含多个app的activity，通过ActivityManager可以获取栈中的activity信息，从而判断activity对应应用的状态。
3.1可以做的事情包括：
ActivityManagermActivityManager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
PackageManagermPackageManager = context.getPackageManager();
①getRecentTasks() 获取最近打开的task，手机查看最近打开的应用可以用这个实现。
②getRunningAppProcess() 获取app运行中的process。
List list = mActivityManager.getRunningAppProcesses();
StringBuilder apps = new StringBuilder();
for (RunningAppProcessInfo info : list) {
apps.append(info.processName + "\n" + info.importance);
System.out.println(apps.toString());
list是系统当前运行进程的集合，importance属性==100 表示这个进程在前台，其他数字表示在后台，所以通过importance和processName判断应用是否在前台
我做测试的时候，方法返回的list中只有这个应用的进程，前台是状态是100，后台时状态是400，
这是因为我的手机是5.0以上的，从api21开始这个方法只能返回自身应用的进程信息，如果应用中有Service并且定义了process属性，那么就会返回两个进程，app进程仍是100，Service是其他值。5.0以下可以返回所有，另外有个方法5.0以上可以返回所有，5.0以下不行，后面说。
*另外：当某个app的Service设置为粘性时，Service所在的app就会被认为是在前台，app进程的importance一直是100，这个时候就不能通过这个方法判断是否在前台了。
总结：5.0以上只能判断自身应用是否在前台，当有app的Service被设置为粘性时，就不能用了 。
If(importance == 100) 中100在runningprocessinfo下的常量IMPORTANCE_FOREGROUND
所以这里要写成 if（info.importance == RunningProcessInfo.IMPORTANCE_FOREGROUND)
③getRunningServices()获取系统运行中的后台service。
④getRunningTask()获取系统运行中的任务。
上面说了activity的task栈，栈顶activity所在app就是前台的app，所有拿到栈顶activity的信息获取他的包名，对比应用的包名来判断应用是不是在前台，5.0以前可以判断是哪个应用在前台，5.0以后只会返回自身和部分不重要task，不能再判断其他应用是否在前台，只能判断自己了。
ActivityManager am = (ActivityManager) context
.getSystemService(Context.ACTIVITY_SERVICE);
List tasks = am.getRunningTasks(1);
if (!tasks.isEmpty()) {
ComponentName topActivity = tasks.get(0).topA
if (topActivity.getPackageName().equals(context.getPackageName())) {
4.ActivityLifecycleCallbacks
以前做过所有的activity都集成baseactivity，重写onCreate方法，onStop方法，定义一个变量count统计打开的activity数，onCreate时 count++，onStop时count--,当count == 0 时，应用就在后台了。现在，从api14开始，api提供了一个所有activity生命周期的回调，就是ActivityLifecycleCallbacks，每个activity的生命周期都会触发，通过registerActivityLifecycleCallbacks注册这个回调。
其实和重写baseactivity的onCreate和onStop一样的，在回调的onCreate中count++，onStop中count--，在onStop中增加个判断，if（count == 0）{“我在后台了”}，为什么在onStop中呢？不论是back返回还是home退出，还是其他手段退出，activity总会回调onStop的。
也可以在onStop中直接调用getRunningAppProcess或者getRunningTask判断应用是不是跑后台去了，这个时候可以做一些事情。然后从后台回到前台调用onCreate，又可以做一些事情。
我做过的这个是在每次应用跑到前台时就检测是不是有新版本更新。在自定义application的onCreate中注册这个回调。
5.UsageStatsManager ,这个就是上面说的5.0以后才有效的方法.使用需要加入权限
&uses-permission android:name="android.permission.PACKAGE_USAGE_STATS" tools:ignore="ProtectedPermissions" xmlns:tools="/tools"&&/uses-permission&
手机-设置-安全-高级，在有权查看使用情况的应用中，选中自己应用。
6.通过Android自带的无障碍功能，
/articles/tong-guo-android-fu-zhu-gong-neng-accessibility-service-jian-ce-ren-yi-qian-tai-jie-mian/
7.读取Linux内核保护在/proc目录下的process进程信息，GitHub地址/jaredrummler/AndroidProcesses
不需要权限，可以判断任意应用是否在前台，但是检索文件夹需要时间。
获取一系列正在运行的App的进程
List processes = ProcessManager.getRunningAppProcesses();&/androidappprocess&
获取任一正在运行的App进程的详细信息
AndroidAppProcess process = processes.get(location);
String processName = process.
Stat stat = process.stat();
int pid = stat.getPid();
int parentProcessId = stat.ppid();
long startTime = stat.stime();
int policy = stat.policy();
char state = stat.state();
Statm statm = process.statm();
long totalSizeOfProcess = statm.getSize();
long residentSetSize = statm.getResidentSetSize();
PackageInfo packageInfo = process.getPackageInfo(context, 0);
String appName = packageInfo.applicationInfo.loadLabel(pm).toString();
判断是否在前台
if (ProcessManager.isMyProcessInTheForeground()) {
// do stuff
获取一系列正在运行的App进程的详细信息
List processes = ProcessManager.getRunningAppProcessInfo(ctx);&/activitymanager.runningappprocessinfo&
以上内容是针对android判断app 状态，希望对大家有所帮助！
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具