Activity管理机制

文章仅记录自己的一点理解,供日后参考。

AMS管理四大组件外加进程管理,其中最庞大的算是Activity了吧。

1、AMS中对ActivityStack划分为两类,其中一类是FrontStack,另一类刚好相反。

    boolean isFrontStack(ActivityStack stack) {
        return !(stack.isHomeStack() ^ getFocusedStack().isHomeStack());
    }
    ActivityStack getFocusedStack() {
        if (mFocusedStack == null) {
            return mHomeStack;
        }
        switch (mStackState) {
            case STACK_STATE_HOME_IN_FRONT:
            case STACK_STATE_HOME_TO_FRONT:
                return mHomeStack;
            case STACK_STATE_HOME_IN_BACK:
            case STACK_STATE_HOME_TO_BACK:
            default:
                return mFocusedStack;
        }
    }

上面的代码可以得出以下结论:

A )、对于4.4目前只有两个ActivityStack的逻辑很清晰:HomeStack、AStack

a、如果getFocusedStack()==HomeStack,那么HomeStack就是FrontStack,另一个就是非FrontStack。

b、如果getFocusedStack()==    AStack,那么HomeStack就是非FrontStack,另一个就是FrontStack。

B )、如果做成多窗口至少有三个ActivityStack:HomeStack、AStack、BStack

a、如果getFocusedStack()==HomeStack,那么HomeStack就是FrontStack,AStack、BStack就是非FrontStack。

b、如果getFocusedStack()==       AStack,那么HomeStack就是非FrontStack,AStack、BStack就是FrontStack。

c、如果getFocusedStack()==       BStack,那么HomeStack就是非FrontStack,AStack、BStack就是FrontStack。

按照现有的逻辑来说,HomeStack跟其他所有ActivityStack是完全相反的,其他所有ActivityStack要么都是FrontStack,要么都是非FrontStack。那它这个isFrontStack分类有啥用?出于什么目的而设计的?

时间: 2024-11-05 11:41:08

Activity管理机制的相关文章

Android开发——Android 6.0权限管理机制详解

0.前言 最近在研究所实习,我负责维护Android手机取证项目的Android客户端,有客户反映我们的APP在Android6.0无响应,经过调试发现SD卡读写权限权限被拒绝.但明明是在AndroidManifest.xml文件中声明过的.查了很多资料才知道Android6.0的很多权限申请机制发生了改变,可以说是Android6.0在安全机制上更进了一步吧,因此写下这篇文章以记录. 注:在运行程序时,对于某些权限向用户询问申请(后面会详细地讲)时因为我们知道客户在我们APP中不会点"拒绝&q

Android的包管理机制浅析(二)

上篇刚好说到获取到了签名信息,下面进入安装过程,直接上源码: private void installNewPackageLI(PackageParser.Package pkg, int parseFlags, int scanMode, UserHandle user, String installerPackageName, PackageInstalledInfo res) { // Remember this for later, in case we need to rollback

Android 内存管理机制详解

??嵌入式设备的一个普遍特点是内存容量相对有限.当运行的程序超过一定数量时,或者涉及复杂的计算时,很可能出现内存不足,进而导致系统卡顿的现象.Android 系统也不例外,它同样面临着设备物理内存短缺的困境.对于已经启动过一次的Android程序,再一次启动所花的时间会明显减少.原因在于Android系统并不马上清理那些已经"淡出视野"的程序(比如你调用Activity.finish退出UI界面).它们在一定的时间里仍然驻留在内存中.这样做的好处是明显的,即下一次启动不需要再为程序重新

Android内存进程管理机制

参考文章: http://www.apkbus.com/android-104940-1-1.htmlhttp://blog.sina.com.cn/s/blog_3e3fcadd0100yjo2.html 一.理论: Android采取了一种有别于Linux的进程管理策略,有别于Linux的在进程活动停止后就结束该进程,Android把这些进程都保留在内存中,直到系统需要更多内存为止.这些保留在内存中的进程通常情况下不会影响整体系统的运行速度,并且当用户再次激活这些进程时,提升了进程的启动速度

Android ActivityManagerService(AMS)的Activity管理

对于AMS来讲,Activity管理是它的核心工作,前面两篇文章都是讲AMS的启动流程和进程的管理,这两篇文章其实是为本文做铺垫的,只有理解了前面两篇文章才能更好地理解AMS的activity管理.在谈到Activity的管理的时候,就不得不说一下Activity的启动流程,说道activity的启动流程就要说一下进程启动的问题了,前面一片文章中我们已经分析了AMS的进程管理,这里需要补充的一点就是在android中并没有针对app开放进程的启动接口,只是在启动activity或者service

Android包管理机制(二)PackageInstaller安装APK

前言 在本系列上一篇文章Android包管理机制(一)PackageInstaller的初始化中我们学习了PackageInstaller是如何初始化的,这一篇文章我们接着学习PackageInstaller是如何安装APK的.本系列文章的源码基于Android8.0. 1.PackageInstaller中的处理 紧接着上一篇的内容,在PackageInstallerActivity调用startInstallConfirm方法初始化安装确认界面后,这个安装确认界面就会呈现给用户,用户如果想要

【朝花夕拾】Android性能篇之(六)Android进程管理机制

前言        Android系统与其他操作系统有个很不一样的地方,就是其他操作系统尽可能移除不再活动的进程,从而尽可能保证多的内存空间,而Android系统却是反其道而行之,尽可能保留进程.Android这样设计有什么优势呢?又是通过怎样的方法来管理这些被保留的进程的呢?Android用户又该如何正确使用手机从而更好发挥Android系统所特有的优势呢?本文将一一为您解开这些谜团.        一.Android进程管理的特殊设计 Linux系统对进程的管理方式是一旦进程活动停止,系统就

untiy3d action管理机制的编写

使用unity3d对于一些可视化强迫者来说,是一个不错的选择,但unity3d没有cocos2d的action管理机制,比如cocos2dx的CCMoveTo,CCScale等action,所以笔者通过封装action管理来实现类似cocos2dx的actionmanager. 首先需要写一个ActionManager来创建.更新.移除所有action.编写代码实现如下: using UnityEngine;using System.Collections;using System; publi

内存管理机制

Objective-C中提供了两种内存管理机制MRC(MannulReference Counting)和ARC(Automatic Reference Counting),分别提供对内存的手动和自动管理,来满足不同的需求. ARC: ARC是Auto Reference Counting的缩写,即自动引用计数,由编译器在代码合适的位置中自动添加retain/Release/Autorelease/dealloc方法从而进行内存管理. ARC几个要点: 在对象被创建时 retain count