关于Activity生命周期学习之窗口化一个Activity-低调大师

关于Activity生命周期学习之窗口化一个Activity

2017-10-19 629

和先前一样,我们有两个Activity,Activity01和Activity02.先看一个传统的没有定义窗口模式的Activity.

可以看到,从Activity01切换到Activity02时,当Activity02最终覆盖了Activity01,占据了整个屏幕后,Activity01调用了onStop方法.从android官方给出来的文档中来看,onStop方法是这个Activity被完全覆盖掉,不可见之后才会调用的.

因此如果一个Activity并没有被完全覆盖时,是否会调用onStop方法呢.先看看如何将一个Activity窗口化,即不覆盖整个屏幕.

打开AndroidManifest.xml文件,修改

为:

这回运行效果是

和先前没有定义主题的新打开的Activity相比,定义了Theme.Dialog主题的Activity就弹出来一个小窗口.

我们继续查看logcat的日志.

可以看到,Activity02调用了onResume方法后,Activity01并没有调用onStop方法.从这一点上也验证了官方文档中的Activity的生命周期中关于onStop方法的描述是正确的.

本文转自leipei博客园博客，原文链接：http://www.cnblogs.com/leipei2352/archive/2011/08/09/2132279.html，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/371192

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

再谈Finalizer对象--大型App中内存与性能的隐性杀手

在上一篇《提升Android下内存的使用意识和排查能力》的文章中，多次提到了Finalizer对象。也可以看到该对象的清理至少是需要两次GC才能完成，而在Android5.0，尤其是6.0以后的系统中，对于该对象的回收变得更加的慢。我们在开发的时候往往关注内存的分配、泄漏，却容易忽视Finalizer对象，其实在大型App中，该对象是引起内存和性能问题的一个不可忽视的元凶。在类似于双十一会场的界面中，在使用一段时间后，设备会变得越来越慢，内存使用量也不断攀升，甚至容易引发OOM，这个有一个重要原因就和Finalizer对象的过度使用有关。为什么过度的使用Finalizer对象会对性能和内存都造成危害呢？我们不妨来看下Finalizer对象的原理。一、Finalizer对象创建过程带来的开销 Finalizer对象是指Java类中重写了finalize方法，且该方法不为空的对象。当运行时环境遇到创建Finalizer对象的时候，既创建对象实例的时候，会先判断该对象是否是Finalizer对象，如果是，那么在构造函数过程中会把生成的对象再封装成Finalizer对象并添加到 Fina...

2017-10-20

747

原作者：“裂缝中的阳光dg”，本文现已重新修订并整理发布，感谢原作者的无私分享。 1、前言在Android 4.4及以后的系统中，应用能否常驻内存，一直以来都是相当头疼的事情，尤其移动端IM、消息推送这类应用，为了保证“全时在线”的概念，真是费尽了心思。虽然APP常驻内存对于用户来说比较”恶心”，但是在诸如IM和消息推送这类场景来说，APP的常驻内存却尤其重要。 APP常驻内存(保活防杀)，旧事重提，距离上一次的研究亦有半年有余。最近，用户反馈说多进程守护方案（详见上篇《Android应用保活终极总结(一)：Android6.0以下的双进程守护保活实践》）在华为Mate8（Andriod 7.0）保活效果不是很好，有时候还是不能及时收到消息。于是，又带着怀疑的眼光，重新找回原来的代码进行测试，顺便分析了市场上主流运动类APP保活方法（微信、手Q就算了，富人家的孩子，不具代表性），同时也对系统对内存中APP的管理规则进行了进一步探索。本文便是对最近一周的Android进程防杀、进程被杀复活的探索、学习、测试的内容总结，以备将来不时之需。因保活防杀和被杀复活涉及内容较多，我将它分成了...

2017-10-20

638

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。