怎么理解 onStart可见但不可交互

简介: onStart生命周期表示Activity可见,那为什么不能交互呢

前言


今天朋友遇到一个面试题,分享给大家:


onStart生命周期表示Activity可见,那为什么不能交互呢?


这个问题看似简单,但涉及到的面还是比较多的,比如Activity生命周期的理解,进程的理解,以及View绘制的时机。


一起看看吧。


onStart介绍


首先,是关于onStart生命周期的理解。


官网是这么介绍的:


当 Activity 进入“已开始”状态时,系统会调用此回调。onStart() 调用使 Activity 对用户可见,因为应用会为 Activity 进入前台并支持互动做准备。


对用户可见?


奇怪了,对用户可见,不就是我们可以看到了吗,为什么又不能互动呢?


更何况onStart 的时候界面都还没绘制,该怎么理解这个可见呢?


做个小实验


首先,科普官方定义的两个状态。


  • onStart到onStop中间的状态叫做“已开始”状态。
  • onResume到onPause中间的状态叫做“已恢复”状态。


然后我们做个小实验,定义ActivityAActivityBActivityB为Dialog主题,ActivityA中点击可以跳转到B:


image.setOnClickListener {
        startActivity(Intent(this, ActivityB::class.java))
    }
    <activity android:name=".activity.ActivityB"
        android:theme="@style/Theme.AppCompat.Light.Dialog"
        android:launchMode="standard">
    </activity>


进入ActivityA后,点击按钮,跳转到B,这时候A的生命周期走到了onPause,也就是回到了已开始状态。


14.png


这个时候,界面是这个样子:


15.png


ActivityA处在已开始状态,对用户可见。


这里的可见是不是就很好理解了,确实对我们可见了,只不过 不在前台,不能交互

所以延伸到普通的Activity,这个可见,并不是表示用户能用肉眼看到了,而是想表达:


Activity已经显示出来了,但是还不在前台,所以只是可见,但不可交互。


这个可见状态是从onStart开始,onStop结束,我们可以分为两个阶段:


  • onStart到onResume。这个阶段,Activity被创建,布局已加载,但是界面还没绘制,可以说界面都不存在。
  • onPause到onStop。这个阶段,就是我们刚才所做的实验,Activity有界面,只是被新的界面所遮挡,也就是不在前台。


所以综合两个阶段,我们把这种Activity被创建或已经显示出来,但是不在前台,介于两者之间的状态叫做 可见 状态。


onStart 和 onResume


到此,我们知道了可见的意思,其实也就知道了另外一个问题,也就是为什么要设计出onStart和onResume这两种状态。


  • onStart和onStop,是从Activity是否可见的角度设计的。
  • onResume和onPause,是从Activity是否位于前台的角度设计的。


所以Activity的生命周期又可以解释为:


被创建(onCreate)——> 可见(onStart)——> 位于前台(onResume)——> 可见但不在前台(onPause)


可见进程


从另外的角度看,这个可见 可以指的是 可见进程。这就涉及到进程的分类。


为了确定在内存不足时应该终止哪些进程,Android 会根据每个进程中运行的组件以及这些组件的状态,将它们放入“重要性层次结构”。这些进程类型包括(按重要性排序):前台进程,可见进程,服务流程,缓存进程


这些进程是什么意思呢?


  • 前台进程是用户目前执行操作所需的进程。比如 正在用户的互动屏幕上运行一个 Activity(其 onResume() 方法已被调用)
  • 可见进程是正在进行用户当前知晓的任务。比如 正在运行的 Activity 在屏幕上对用户可见,但不在前台(其 onPause() 方法已被调用)
  • 服务流程包含一个已使用 startService() 方法启动的 Service。
  • 缓存进程是目前不需要的进程。比如 当前不可见的一个或多个 Activity 实例(onStop() 方法已被调用并返回)


所以Activity的生命周期又可以通过进程分为:


可见进程(onStart)——> 前台进程(onResume)——> 可见进程(onPause)——> 缓存进程(onStop)


这些进程有什么用呢?


我们都知道,在Android系统中有很多很多运行中的APP,也就代表了不同的进程。


当内存不够时(达到了某个阈值),系统首先会通过onTrimMemory()回调方法告诉应用,让应用自己来处理低内存情况下的减少内存操作。这之后,如果内存还是很紧张,那么就会开始对一些进程的杀除,以释放内存。这里就需要判断进程的优先级了,从低优先级开始按顺序终止进程。


所以,进程的分类作用就在这了。优先级的高低其实就代表了 终止进程的顺序,也代表了对用户的影响程度。


当然实际代码中,进程优先级是有数字表示的,也就是ADJ,而上面说的进程类型都有相应的进程优先级数字范围。比如:


public final class ProcessList {
    //可见进程
    static final int VISIBLE_APP_ADJ = 100;
    // 前台进程
    static final int FOREGROUND_APP_ADJ = 0;
    // 服务进程
    static final int SERVICE_ADJ = 500;
    // 缓存进程
    static final int CACHED_APP_MIN_ADJ = 900;
    //...
}


再回到我们的问题上来:


其中,可见进程这里也出现了可见的概念,给出的解释是:用户知晓


当我们点击一个页面,我们知道这个页面将要显示出来,也知道之前的页面在这个页面后面。所以这些页面和进程都是我们所知晓的,只是不在前台。


所以onStart表示的可见,也可以理解为可见进程,意思是这个Activity所在的进程任务已经被创建并显示,我们知晓它,只是没在前台。


可交互


那么可以交互到底是发生在什么阶段呢?


之前我们说过,在Activity启动过程中,调用了handleResumeActivity方法。在这个方法中,调用了onResume方法和addView方法,完成了View的第一次绘制,并显示到界面上。


@Override
    public void handleResumeActivity() {
        //onResume
        final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
        //addView
        if (r.window == null && !a.mFinished && willBeVisible) {
            wm.addView(decor, l);
        }
    }


所以到onResume,View才被绘制出来,并显示到前台。


官网是这么解释onResume的:


Activity 会在进入“已恢复”状态时来到前台,然后系统调用 onResume() 回调。这是应用与用户互动的状态。应用会一直保持这种状态,直到某些事件发生,让焦点远离应用。此类事件包括接到来电、用户导航到另一个 Activity,或设备屏幕关闭。


所以可交互状态应该是在onResume之后,也就是Activity可见并且处于前台。


小结


总结下:


onStart状态表示Activity可见,而可见表示的意思是Activity被创建出来了,被用户所知晓,但是不在前台,还没绘制界面,所以无法交互。也可以意指其所在的进程为可见进程。


其可见之意应该和onStop一起使用,即onStartonStop这个阶段叫做 可见 阶段。


而真正显示出来可以进行交互 发生在onResume之后,也就是View绘制出来,并处于前台的时候。


参考


《Android开发艺术探索》 https://juejin.cn/post/6896751245722615815https://juejin.cn/post/6891911483379482637

目录
相关文章
|
9月前
|
存储 前端开发 JavaScript
第六章(原理篇) 微前端间的通信机制
第六章(原理篇) 微前端间的通信机制
219 0
|
4月前
|
消息中间件 测试技术 数据库
吊打面试官!应用间交互如何设计?
【10月更文挑战第18天】设计应用间交互需从明确需求、选择合适方式、设计协议与数据格式、考虑安全性和权限管理、进行性能优化和测试五个方面入手。明确功能和用户需求,选择接口调用、消息队列、数据库共享或文件交换等方式,确保交互高效、安全、可靠。展示这些能力将在面试中脱颖而出。
|
6月前
|
Python
Python IPC深度探索:解锁跨进程通信的无限可能,以管道与队列为翼,让你的应用跨越边界,无缝协作,震撼登场
【8月更文挑战第3天】Python IPC大揭秘:解锁进程间通信新姿势,让你的应用无界连接
38 0
|
8月前
|
Java
java线程之定制化通信(多轮顺序打印问题)
java线程之定制化通信(多轮顺序打印问题)
|
存储 开发框架 缓存
数据流动的精妙之道——UniApp中的数据通信与状态管理解析
数据流动的精妙之道——UniApp中的数据通信与状态管理解析
|
存储 缓存 算法
【优化技术专题】「线程间的高性能消息框架」再次细节领略Disruptor的底层原理和优势分析
【优化技术专题】「线程间的高性能消息框架」再次细节领略Disruptor的底层原理和优势分析
219 0
【优化技术专题】「线程间的高性能消息框架」再次细节领略Disruptor的底层原理和优势分析
Java实现多线程开发的四种方式,详解它们之间异同
Java实现多线程开发的四种方式,详解它们之间异同
|
Java 调度
35. 谈谈你对Java线程之间通信方式的理解
35. 谈谈你对Java线程之间通信方式的理解
67 0
|
算法 Java Android开发
抽丝剥茧聊Kotlin协程之Job是如何建立结构化并发的双向传播机制关系的
抽丝剥茧聊Kotlin协程之Job是如何建立结构化并发的双向传播机制关系的
抽丝剥茧聊Kotlin协程之Job是如何建立结构化并发的双向传播机制关系的
使用一个例子探析:生产者消费者在多线程之间的通信的使用
使用一个例子探析:生产者消费者在多线程之间的通信的使用
137 0