likes
comments
collection
share

Android面试指南（二）————Android基础篇（一）

作者站长头像
站长
· 阅读数 22

Android基础篇

Application

简述Application

作用：做初始化工作，提供上下文。继承自ContextWarpper，获取的是ContextWrapper中的context对象

  • 一个应用中有且只有一个
  • 其生命周期和应用程序一样长
  • Application的onCreate方法才是整个应用程序的入口
  • 只会实例化一次，所以天生就是一个单例

生命周期：

  • onCreate：创建时执行
  • onTerminate：终止时执行
  • onLowMemory：低内存时执行

Application的初始化流程

通过AMS协调，ActivityThread优先建立后，会新建一个ApplicationThread，用作和AMS通过Binder通信，之后AMS通知ActivityThread去bindApplication，将消息返送到messageQueue，进行初始化Application的任务，然后调用attachBaseContext将Context绑定到Application，最后调用Application.onCreate()方法进行后续Activity的初始化

AMS 来通知 zygote 进程来 fork 一个新进程，来开启我们的目标 App 的

ActivityLifecycleCallbacks理解

ActivityLifecycleCallback是Application中的一个接口，可以监听应用中所有Activity的生命周期，可以通过该方法完成一些特殊的需求，比如监测当前App显示的Activity是那个？App是否存在前台

public class MyApplication extends Application {
     private ActivityLifecycleCallbacks activityLifecycleCallbacks = new ActivityLifecycleCallbacks() {
        @Override
        public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState) {

        }

        @Override
        public void onActivityStarted(@NonNull Activity activity) {

        }

        @Override
        public void onActivityResumed(@NonNull Activity activity) {

        }

        @Override
        public void onActivityPaused(@NonNull Activity activity) {

        }

        @Override
        public void onActivityStopped(@NonNull Activity activity) {

        }

        @Override
        public void onActivitySaveInstanceState(@NonNull Activity activity, @NonNull Bundle outState) {

        }

        @Override
        public void onActivityDestroyed(@NonNull Activity activity) {

        }
    };

    @Override 
    public void onCreate() {
        super.onCreate(); 
        
        // 注册Callback
        registerActivityLifecycleCallbacks(callbacks);  
    }
}

Activity

简述生命周期

Android面试指南（二）————Android基础篇（一）

Activity：
  • onCreate() 正在被创建
  • onRestart() 不可见到可见
  • onStart() Activity正在启动，已经可见了
  • onResume() Acitivty已经可见，并在前台显示
  • onPause() Acitivty正在停止，之后会不可见
  • onStop() Activity即将停止
  • onDestory() Activity被销毁

onStart和onResume都为可见，onStart不在前台显示，onResume在前台显示

onPause后已经不可见，会进入onResume或者另一个onResume，所以不能做耗时操作，会影响界面显示

onPause和onStop中不能太耗时

如果新的Activity采用了透明主题，那么当前Activity不会回调onStop

onStart和onStop对应Activity是否可见

onResume和onPause对应Activity是否在前台显示

异常情况下会执行onSaveInstance方法进行数据保存

简述启动模式

  • standard：标准模式，来一个添加一个
  • singleTop：栈顶复用，如果在栈顶，就复用这个Activity，onNewIntent会被执行，替代onCreate()
  • singleTask：栈内复用，如果在栈内，就复用这个Activity，该Activity之上的全部出栈，onNewIntent会被执行
  • singleInstance：单实例模式。加强版singleTask，会为自己新建一个栈，在该栈中栈内复用

LauncherMode和startActivityForResult

Android面试指南（二）————Android基础篇（一） Android面试指南（二）————Android基础篇（一）

在5.0之前，当启动一个Activity时，系统将首先检查Activity的launchMode，如果为A页面设置为SingleInstance或者B页面设置为singleTask或者singleInstance,则会在LaunchFlags中加入FLAG_ACTIVITY_NEW_TASK标志，而如果含有FLAG_ACTIVITY_NEW_TASK标志的话，onActivityResult将会立即接收到一个cancle的信息，而5.0之后这个方法做了修改，修改之后即便启动的页面设置launchMode为singleTask或singleInstance，onActivityResult依旧可以正常工作，也就是说无论设置哪种启动方式，StartActivityForResult和onActivityResult()这一组合都是有效的

什么时候会启动一个新的Activity栈？

  • allowTaskReparenting：
  1. singleInstance单独使用，会新建一个栈
  2. singleTask配合taskAffinity使用
  3. taskAffinity配合Intent.FLAG_ACTIVITY_NEW_TASK修饰Activity（AMS先处理LauncherMode，在处理FLAG_ACTIVITY_NEW_TASK）
  4. taskAffinity配合allowTaskReparenting属性，使Activity从启动栈移动到正在使用的栈中并显示出来

如何控制Activity的动画切换

  1. 通过overridePendingTransition(R.anim.slide_in_right, R.anim.slide_out_left)方法控制 再startActivity方法后或者finish方法之后调用即可生效
  2. 使用style定义切换动画

如何控制Fragment的动画切换

FragmentTransaction fragmentTransaction = mFragmentManager
                .beginTransaction();

fragmentTransaction.setCustomAnimations(
                R.anim.in_from_right,
                R.anim.out_to_left);

使用FragmentTransaction开启Fragment动画，设置自定义动画切换，进入动画和推出动画

ActivityA跳转到ActivityB，再按back键返回ActivityA，生命周期情况？

ActivityA跳转到ActivityB：onPauseA()----->onCreateB()----->onStartB()----->onResumeB()----->onStopA()

ActivityB按back键返回ActivityA：

onPauseB()----->onRestartA()----->onStartA()----->onResumeA()----->onStopB()----->onDestoryB()

如果ActivityB是窗口Activity呢？

ActivityA跳转到ActivityB：onPauseA()----->onCreateB()----->onStartB()----->onResumeB()

ActivityB按back键返回ActivityA：onPauseB()----->onResumeA()----->onStopB()----->onDestoryB()

Activity的生命周期会受Dialog影响吗？

不会，Activity生命周期不会随Dialog的显示而变化

Activity的生命周期受AMS调用，而dialog不是Activity，所以不受AMS控制，所以不会触发Activity的生命周期

Service

Service有几种创建方式？有什么区别？

  1. startService()，在不需要的时候stopService()
  2. bindService()，与生命周期相绑定，在销毁的时候进行回收unbind()

Android面试指南（二）————Android基础篇（一）

如何理解IntentService？生命周期是什么？HandlerThread 是什么？

intentService继承自Service，持有Service的功能，同时，他是一个处理异步操作的类，当异步执行结束后会自动关闭intentService，多次执行startService()，只是执行onStartCommand方法，将消息加入到消息队列中。

其本质就是启动了一个类似于主线程Handler的机制去维护异步操作。

生命周期：onStartCommand()中执行onStart()方法，在onstart()方法中添加handler.sendMessage()方法

HandlerThread：就是将Handler+looper进行封装，允许直接在子线程中使用handler的一套逻辑。

IntentService更像是一个后台线程，但是他又是一个服务，不容易被回收，这是他的优点

JobIntentService

是IntentService的子类，在android 8.0（26）以上，IntentService的所有后台执行任务都会受到限制约束，所以要使用JobIntentService。

service不能使用后台服务，需要使用ContextCompat.startForegroundService启动前台服务，这样就会启动一个notification，对用户来说体验不是很好，所以就要使用 JobIntentService启动一个后台服务

在使用JobIntentService的时候不需要startService，stopService，在需要的时候调用

DownLoadJobIntentService.enqueueWork(MainActivity.this,DownLoadJobIntentService.class,jobId(8),intent);

而后会执行onHandleWork方法中的逻辑，执行完毕后自动销毁

onStartCommand中三个回调分别是什么？

  • START_NOT_STICKY：Service被回收后不做处理
  • START_STICKY：Service在被回收后，重新创建Service，但是不保存intent
  • START_REDELIVER_INTENT：Service在被回收后，重新创建Service，保存intent
  • START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。

Service保活

  1. 设置成前台服务，绑定Notification， startForeground(1, getNotification());
  2. 单独设置为服务进程
  3. onStartCommand返回START_STICKY，START_REDELIVER_INTENT，保证服务被干掉后重启
  4. 在onDestory发送一个广播，广播接收器接收广播后拉起服务
  5. 添加系统广播拉起
  6. 提升服务的优先级

Fragment

生命周期

Android面试指南（二）————Android基础篇（一）

FragmentPagerAdapter和FragmentStatePagerAdapter的区别？

FragmentPagerAdapter：切换页面只是将Fragment分离，适合Fragment较少的情况不影响内存

FragmentStatePagerAdapter：切换页面将Fragment回收，适合Fragment较多的情况，这样不会消耗太多内存资源

Fragment的3种切换方式

  1. add方法：只是重新回到fragment
  2. replace方法：每次都会重新构建fragment

为什么不能用Fragment的构造函数进行传参？有什么劣势，应该怎么办？为什么？

Fragment在异常崩溃后重建时，默认会调用Fragment无参构造，这样会导致Fragment中的有参构造的值不会被执行，这样数据就会异常

Fragment中调用setArguments来传递参数，在Activity构造Fragment时会通过反射午餐构造实例化一个新的Fragment，并且给mArguments初始化为原先的值

Fragment的重建在那个生命周期中？

在FragmentActivity的onSaveInstanceState中做存储，将Framgent通过序列化Parcelable进行存储，在Activity的onCreate中进行恢复

当配置发生变化时，Activity进入销毁过程，FragmentManager先销毁队列中Fragment的视图，然后检查每个Fragment的retainInstance属性。如果retainInstance为false，FragmentManager会销毁该Fragment实例；如果retainInstance为true，则不会销毁该Fragment实例，Activity重建后，新的FragmentManager会找到保留的Fragment并为其创建视图。

BroadCastReceiver

简述广播的启动方式和区别

  • 静态注册：在AndroidManifest中注册，常驻型广播
  • 动态注册：使用intentFilter过滤广播，registerReceiver注册广播，跟随生命周期

Android8.0以上部分广播不允许静态注册

无序广播和有序广播的区别

  • 无序广播：所有广播接收器都可以获得，不可以拦截，不可以修改
  • 有序广播：按照优先级向下传递，可拦截广播，修改广播

本地广播和全局广播

本地广播接收器只接收本地广播，减少应用外广播干扰，高效 androidx中1.1.0-alpha01中弃用本地广播，官方推荐该用LiveData或响应式流

IPC机制

简述android中的IPC机制

进程间通信

架构：Client/Server架构，Binder机制，之间通过代理接口通信

client，server，serverManager

AndroidManifest中指定Android:process属性

  • 包名:remote为应用私有进程，其他应用不可访问
  • 包名.remote为全局进程，其他应好通过ShareUID可以和他跑在同一个进程

多进程带来的问题：四大组件共享数据失败，每个进程会单独开辟内存空间存储信息

  1. 静态成员和单例模式完全失效
  2. 线程同步机制完全失效
  3. SharedPreferences可靠性下降，不支持多进程
  4. Application会多次创建

Serializable和parcelable区别

serializable:java自带，反射后产生大量临时变量，容易引起gc，主要用于持久化存储和网络传输的序列化

parcelable:android专用，性能强，将完整对象分解为部分对象，每一部分进行intent传输，可用于ipc，内部实现Bundle，主要用于内存的序列化

Android为什么引入Parcelable？

  1. serializable通过反射，性能不好，
  2. serializable反射产生大量临时变量，容易gc，导致内存抖动
  3. serializable使用了大量的IO操作，也影响了耗时

parcelable使用复杂，但高效，适用于内存序列化

Parcelable一定比Serializable快吗？

单论内存中的传输速度，Parcelable一定快于Serializable，但是Parcelable没有缓存的概念 Serializable存在缓存，会将解析过的内容放置在HandleTable，下次解析到同一类型的对象时就可以直接复用

为什么java使用Serializable序列化对象，而不是json或者xml？

因为历史遗留问题，在json和xml出来之前，java已经设计了Serializable，对于Java的庞大体系，并不容易修改这个问题。java官方文档也推荐使用json库，因为他简单、易读、高效

简析Binder机制

在Android通信中并不是所有的进程通信都使用Binder，当fork()进程时，使用的是Socket()通信，因为fork不允许多线程，Binder是多线程模式，所以不被允许

进程空间划分

一个进程空间分为用户空间和内核空间

用户空间：数据独享，其他进程无法访问

内核空间：数据共享，其他进程可以访问

所有的进程共用1个内核空间

如何看待ServiceManager？

ServiceManager管理系统中所有的服务，服务需要使用时都要在ServiceManager中进行注册，他的存在类似于DNS，提供client访问某一个服务的查询。

Binder原理

binder驱动属于进程中的内核空间，即共享空间，在client发起请求时，需要将数据从用户空间拷贝到内核空间，binder通过传输内核空间中数据存储的引用映射给服务端，供服务端调用，服务端处理后，将返回值放在内核空间，通过binder传递引用映射给客户端进行处理

Android面试指南（二）————Android基础篇（一）

简述通信流程

总体通信流程就是：

  • 客户端通过代理对象向服务器发送请求。
  • 代理对象通过Binder驱动发送到服务器进程
  • 服务器进程处理请求，并通过Binder驱动返回处理结果给代理对象
  • 代理对象将结果返回给客户端。
详细的通信过程
  • 服务端跨进程的类都要继承Binder类，所以也就是服务端对应的Binder实体。这个类并不是实际真实的远程Binder对象，而是一个Binder引用(即服务端的类引用)，会在Binder驱动里还要做一次映射。
  • 客户端要调用远程对象函数时，只需把数据写入到Parcel，在调用所持有的Binder引用的transact()函数
  • transact函数执行过程中会把参数、标识符（标记远程对象及其函数）等数据放入到Client的共享内存，Binder驱动从Client的共享内存中读取数据，根据这些数据找到对应的远程进程的共享内存。
  • 然后把数据拷贝到远程进程的共享内存中，并通知远程进程执行onTransact()函数，这个函数也是属于Binder类。
  • 远程进程Binder对象执行完成后，将得到的写入自己的共享内存中，Binder驱动再将远程进程的共享内存数据拷贝到客户端的共享内存，并唤醒客户端线程。

通过Binder将客户端，服务端的共享内存中的数据进行读写，放入对方的共享内存中，并通知。

Binder在Android中的应用？
  • 系统服务及四大组件的启动调用工作：系统服务是通过getSystemService获取的服务，内部也就是通过ServiceManager。例如四大组件的启动调度等工作，就是通过Binder机制传递给ActivityManagerService，再反馈给Zygote。而我们自己平时应用中获取服务也是通过getSystemService(getApplication().WINDOW_SERVICE)代码获取。
  • AIDL（Android Interface definition language）。例如我们定义一个IServer.aidl文件，aidl工具会自动生成一个IServer.java的java接口类（包含Stub，Proxy等内部类）。
  • 前台进程通过bindService绑定后台服务进程时，onServiceConnected(ComponentName name, IBinder service)传回IBinder对象，并且可以通过IServer.Stub.asInterface(service)获取IServer的内部类Proxy的对象，其实现了IServer接口。

为什么选择Binder机制？他的优势是什么？

  1. 性能高，效率高： 传统的IPC（socket，管道，消息队列）需要拷贝两次内存，Binder只需要拷贝一次内存、共享内存不需要拷贝数据，只需要传递引用
  2. 安全性好： C/S通信添加UID/PID，方便验证，安全机制完善。
  3. 利用C/S架构，通过多线程控制一个服务端多个客户端的情况

Android中IPC的几种方式详细分析与优缺点分析

  1. Bundle
  2. 文件共享
  3. Messenger：内部实现AIDL机制，c/s架构，通过handler接收message对象
  4. AIDL
  5. ContentProvider
  6. Binder连接池

Handler

Android Handler机制之总目录

Android面试题：Handler

其实并不是每一次添加消息时，都会唤醒线程。当该消息插入到队列头时，会唤醒该线程；如果有延迟消息，插入到头部，也会唤醒线程后在休眠

一句话概括Handler，并简述其原理

android中用于主线程和子线程之间通信的工具

主要包含Handler,Looper,MessageQueue,ThreadLocal.

Handler：封装了消息的发送和接收looper分发过来的Message

Looper：协调Handler和MessageQueue之间的桥梁，Looper的作用是循环从MessageQueue中取出message，并分发

给相应的Handler，Handler则存储在Message中的target中

message：单节点，存储handler传输的数据

MessageQueue：内部结构为单链表，由Looper创建，具体代码为Looper.prepare()；先进先出原则(队列)，根据 Message.when进行插入队列（队列中是按时间执行顺序排序）

ThreadLocal：负责存储和获取本线程的Looper

handler.sendMessage(message)将message发送到MessageQueue，MessageQueue执行enqueueMessage()方法入队，Looper执行looper.loop()方法从MessageQueue中取出message，执行message.target.dispatchMessage(message)方法将消息发送到Handler中，在handleMessage()方法中拿到回调

Looper.loop()是在主线程的死循环，为什么没有造成线程阻塞？

真正的ANR是在生命周期的回调中等待的时间过长导致的，深层次的讲，就是Looper.loop()没有及时取出消息进行分发导致的。一旦没有消息，Linux的epoll机制则会通过管道写文件描述符的方式来对主线程进行唤醒与沉睡，Android里调用了linux层的代码实现在适当时会睡眠主线程。

MessageQueue包含jni调用，无消息时，通知epoll休眠，来消息时，线程启动

looper.loop()中循环，判空退出怎么理解？

 public static void loop() {
       ....
        for (;;) {
            Message msg = queue.next(); // might block（可能会阻塞）
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }

在queue.next中，会通过jni调用，通过Linux的epoll机制则会通过管道写文件描述符的方式来对主线程进行唤醒与沉睡，只有当应用程序退出时，才会执行if语句退出循环。

为什么不能在子线程更新UI？

因为如果要在子线程中更新UI，势必要考虑线程安全，加锁机制，这样很耗时，不加锁又很容易发生错误，这些错误是致命的，所以在设计时只允许UI线程更新UI，避免这些错误。

真的不能在子线程更新UI吗？

ViewRootImpl中会进行通过checkThread()进行线程检测

public ViewRootImpl(Context context, Display display) {
        ......
        mThread = Thread.currentThread();
        ......
}
......

void checkThread() {
        if (mThread != Thread.currentThread()) {
            throw new CalledFromWrongThreadException(
                    "Only the original thread that created a view hierarchy can touch its views.");
        }
    }

由此得出：viewRootImpl在那个线程被初始化，就会在那个线程更新UI，大部分情况下，ViewRootImpl都是在UI线程中初始化的，所以只能在UI线程更新UI，部分情况下可以在子线程更新UI（比如Dialog是在addView中初始化ViewRootImpl）

SurfaceView可以在子线程中更新

ViewRootImpl是什么时候被创建的？

在Acitivty中，ViewRootImpl是在onResume中创建的，所以在onCreate中进行子线程更新是可以绕过checkThread()检测的。

一个Thread中可以有几个Looper?几个Handler

一个Thread中只有一个Looper，可以存在无数个Handler，但是使用MessageQueue都是同一个，也就是一个Looper

可以在子线程直接new一个Handler吗？那该怎么做？

thread= new Thread(){
            @Override
            public void run() {
                super.run();
                //创建Looper，Looper再创建MessageQueue
                Looper.prepare();
                //新建Handler
                handler=new Handler();
                //循环取出消息并执行
                Looper.loop();
            }
        }.start();

需要创建Looper，Looper会创建MessageQueue，循环从MessageQueue中取消息。

Message可以如何创建？哪种效果更好，为什么？

享元模式

数据重复利用

  1. Message msg = new Message();
  2. Message msg2 = Message.obtain();
  3. Message msg1 = handler1.obtainMessage();

2，3从整个Messge池中返回一个新的Message实例，通过obtainMessage能避免重复Message创建对象。

所以2，3都可以避免重复创建Message对象，所以建议用第二种或者第三种任何一个创建Message对象。

messge就是一个节点，存在就是一条链表，链表中存储的都是可以复用的message，在handleMessage和callback

方法执行完成后执行message.recycle()方法，进行信息重置后加入闲置链表头部中，每次调用obtain方法会从闲置链表中取出头节点，如果闲置链表为空，则新建message。

Message缓存池大小为50

使用Hanlder的postDelay()后消息队列会发生什么变化？

postDelay()内部调用sendMessageDelayed()

public final boolean sendMessageDelayed(Message msg, long delayMillis)
    {
        if (delayMillis < 0) {
            delayMillis = 0;
        }
        return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    }

时间：SystemClock.uptimeMillis() + delayMillis

SystemClock.uptimeMills()是从开机到现在的时间，不使用currentMills，因为其是可变的，uptimeMills()期间不包括休眠的时间，是一个相对时间

  1. Handler.postDelayed(Runnable r, long delayMillis)
  2. Handler.sendMessageDelayed(getPostMessage(r), delayMillis)
  3. Handler.sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis)
  4. Handler.enqueueMessage(queue, msg, uptimeMillis)
  5. MessageQueue.enqueueMessage(msg, uptimeMillis)

消息入队的时候会根据when判断时间，最终按照时间大小排序，时间短的在链表头，时间长的在链表尾部。

案例如下：

  1. postDelay()一个10秒钟的Runnable A、消息进队，MessageQueue调用nativePollOnce()阻塞，Looper阻塞；
  2. 紧接着post()一个Runnable B、消息进队，判断现在A时间还没到、正在阻塞，把B插入消息队列的头部（A的前面），然后调用nativeWake()方法唤醒线程；
  3. MessageQueue.next()方法被唤醒后，重新开始读取消息链表，第一个消息B无延时，直接返回给Looper；
  4. Looper处理完这个消息再次调用next()方法，MessageQueue继续读取消息链表，第二个消息A还没到时间，计算一下剩余时间（假如还剩9秒）继续调用nativePollOnce()阻塞；
  5. 直到阻塞时间到或者下一次有Message进队；

同步消息、异步消息和同步屏障消息是什么？具体应用场景是什么？

同步消息：handler默认无参构造的形式是同步消息

异步消息：async传入true，则为异步消息

屏障消息：msg.target == null，使用postSyncBarrier()方法打开同步屏障，导致同步消息不执行，优先执行异步消息，规则同同步消息一样，当执行完毕后关闭同步屏障。

应用场景：在view的更新过程中，draw，requestLayout、invalidate中都用到这个方法，系统会优先处理这些异步消息，等处理结束后再处理同步消息。这样可以优先处理我们指定的系统消息。

postSyncBarrier()该方法为私有方法，所以api不允许我们在开发中调用，我们只要知道原理就好了

调用该方法，会直接发送一个屏障消息进入messageQueue，则队列头部为屏障消息

ThreadLocal，谈谈你的理解

跟HashMap功能类似，为什么不直接用HashMap呢？ 原因：

  1. HashMap太大了，太臃肿了。ThreadLocal的key值只有Thread，value为looper，而HashMap的key值则可以 是string、int等数据类型，我们可以不用考虑这些数据类型;
  2. 线程隔离：我们的线程是系统中唯一的，用ThreadLocal来管理这些唯一的线程和其对应的value值会非常方便，
  3. ThreadLocal参照了HashMap,简化了HashMap,便于我们使用。
  4. HashMap线程不安全

ThreadLocal的理解

为什么子线程中不能使用Handler，而UI线程可以？

UI线程就是ActivityThread，他在初始化的时候创建了Looper,MessageQueue，所以可以直接使用Handler，而新创建的子线程没有创建Looper，所以创建了就可以使用了

Handler的构造方法中使用Looper.myLooper()获取了looper，但是在子线程中并没有looper

Handler如何引起内存泄露？怎么解决？

非静态内部类或匿名内部类默认持有外部类的引用，当外部类被回收时，因为内部类持有外部类的引用，导致外部类不能被回收，造成内存泄露。

  1. Activity销毁时及时清理消息队列；
  2. 自定义静态Handler类+弱引用。

MessageQueue.next()会因为发现了延迟消息，而进行阻塞。那么为什么后面加入的非延迟消息没有被阻塞呢？

首先非延时消息会入队，并且插入链表头，这时唤醒线程，进行循环取出message，非延时消息出队，到延迟消息后，如果事件未到，触发next的阻塞机制，如果时间到了，取出message，执行消息

Handler延时机制保时吗？

不保时

 chatIflyHandler.post(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(3000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });
        chatIflyHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                Log.e("handler","执行延时1s操作");
            }
        },1000);

首先一个非延时消息入队，紧接着一个延时消息入队，执行第一个非延时消息，用时3s后执行延时消息，对比when，然后直接执行，测试总共耗时3420ms

Handler的入队机制是线程安全的（synchronized）

messageQueue.equeue(){
    synchronized(this){
        ......
    }
}

如何精确计时？

  • 使用timer（子线程处理TimerThread）

  • 误差补偿算法(TextClock控件方法)

private final Runnable mTicker = new Runnable() {
        public void run() {
            onTimeChanged();

            long now = SystemClock.uptimeMillis();
            long next = now + (1000 - now % 1000);

            getHandler().postAtTime(mTicker, next);
        }
    };

整秒数执行，当上次执行累积到1200，在下次执行时，通过next的计算后保证下次执行的时间不被累加到2200，而是同样在2000

IdleHandler是什么？用处是什么？

messageQueue中有一个addIdleHandler()方法，添加IdleHandler接口

  • 添加时messageQueue不为空，则在线程休眠（没有消息，延时消息）时回掉方法
  • 添加时messageQueue为空，则当时不会触发回掉，当线程被唤醒时才会执行

就是在启用IdleHandler的时候，如果线程处于休眠状态，要等到下次休眠状态才会生效。如果不是休眠状态，则下一次休眠立即生效。

启用IdleHandler后，主线程下次休眠时会通知

 Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
            @Override
            public boolean queueIdle() {
               //do something
                return false;
            }
        });

如果return true，则表示这个IdleHandler可多次使用 如果return false，则表示这个IdleHandler只能使用一次

主线程的Looper何时退出？能否手动退出？

在app退出或者异常终止时，会退出Looper。在正常退出时，ActivityThread主线程中的mH（Handler）会接收到回调信息，调用quit()方法，强制退出

//ActivityThread.java
case EXIT_APPLICATION:
    if (mInitialApplication != null) {
        mInitialApplication.onTerminate();
    }
    Looper.myLooper().quit();
    break;

  • Looper.quit():调用后直接终止Looper，不在处理任何Message，所有尝试把Message放进消息队列的操作都会失败，比如Handler.sendMessage()会返回 false，但是存在不安全性，因为有可能有Message还在消息队列中没来的及处理就终止Looper了。

  • Looper.quitSafely():调用后会在所有消息都处理后再终止Looper，所有尝试把Message放进消息队列的操作也都会失败。

当尝试在主线程手动退出looper时，会报错：

Caused by: java.lang.IllegalStateException: Main thread not allowed to quit.
    at android.os.MessageQueue.quit(MessageQueue.java:428)
    at android.os.Looper.quit(Looper.java:354)
    at com.jackie.testdialog.Test2Activity.onCreate(Test2Activity.java:29)
    at android.app.Activity.performCreate(Activity.java:7802)
    at android.app.Activity.performCreate(Activity.java:7791)
    at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1299)
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3245)
    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3409) 
    at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83) 
    at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135) 
    at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95) 
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016) 
    at android.os.Handler.dispatchMessage(Handler.java:107) 
    at android.os.Looper.loop(Looper.java:214) 
    at android.app.ActivityThread.main(ActivityThread.java:7356) 
    at java.lang.reflect.Method.invoke(Native Method) 
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492) 
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

因为主线程退出意味着app的关闭，这种操作不和规范，需要使用正式的退出操作

如何退出app

  1. 记录Activity任务栈，全部finish
  2. System.exit(0);//正常退出 System.exit(1);//非正常退出
  3. android.os.Process.killProcess(android.os.Process.myPid()); 关闭进程，如果系统发现进程未正常关闭，会重新启动进程
  4. 在Intent中直接加入标识Intent.FLAG_ACTIVITY_CLEAR_TOP，这样开启B时，会清除该进程空间的所有Activity。
  5. 2.2版本之前使用ActivityManager关闭
ActivityManager am = (ActivityManager)getSystemService (Context.ACTIVITY_SERVICE);
am.restartPackage(getPackageName());

2.2版本以后

ActivityManager am = (ActivityManager)getSystemService (Context.ACTIVITY_SERVICE);
am.killBackgroundProcesses(getPackageName());
System.exit(0);

该方法只是结束后台进程的方法，不能结束当前应用移除所有的 Activity。如果需要退出应用，需要添加System.exit(0)方法一起使用，并且只限栈内只有一个Activity，如果有多个Activity时，正如上面 方法 2 所说，就不起作用了。

  1. 将MainActivity设置为singleTask，返回MainActivity后会清空所有的Activity，这样直接在MainActivity执行finish()方法即可

如何看待sendMessageAtFrontOfQueue()

public final boolean sendMessageAtFrontOfQueue(Message msg) {
    MessageQueue queue = mQueue;
    if (queue == null) {
        RuntimeException e = new RuntimeException(
            this + " sendMessageAtTime() called with no mQueue");
        Log.w("Looper", e.getMessage(), e);
        return false;
    }
    return enqueueMessage(queue, msg, 0);
}

传入的延迟时间为0，头插入消息队列，即消息队列下一次立即执行的消息，

如何看待Handler构造中的CallBack方法？
    @UnsupportedAppUsage
    public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
        mLooper = looper;
        mQueue = looper.mQueue;
        mCallback = callback;
        mAsynchronous = async;
    }

public void dispatchMessage(Message msg) {
  //这里的 callback 是 Runnable
  if (msg.callback != null) {
    handleCallback(msg);
  } else {
    //如果 callback 处理了该 msg 并且返回 true， 就不会再回调 handleMessage
    if (mCallback != null) {
      if (mCallback.handleMessage(msg)) {
        return;
      }
    }
    handleMessage(msg);
  }
}

由源码可以看出构造函数中传入Callback参数，调用dispatch方法时，会优先调用callback方法，在调用handleMessage方法，即

Callback接口可以在handleMessage前收到消息，如果返回true，则不会调用handleMessage方法

我们可以利用 Callback 这个拦截机制来拦截 Handler 的消息！

Looper.prepareMain()和Looper.perpare的区别？

区别是一个boolean值，主线程的looper永不退出，除非调用

AsyncTask

如何理解AsyncTask？

  • 必须创建在主线程

AscncTask内部封装了Handler+线程池

包含两个线程池，一个是用来排队的 ，一个才是真正的执行，通过Handler将状态回掉到主线程

  • 核心线程数，最少两个，最多四个
  • 最大线程数= cpu核心数*2+1
  • 核心线程无超时限制，非核心线程在闲置时的超时时间为1s
  • 任务队列容量为128

execute方法执行，加入排队线程池排队，等待任务执行后通过handler通知主线程，调用状态回调方法，内部实现因为排队线程池阻塞，导致任务是串行的，即同时只有一个任务会进入线程池执行

executeOnExecutor执行调用异步操作

谷歌为何弃用AsyncTask

  1. 使用多线程更加复杂，使bug难以定位
  2. 太过复杂
  3. 滥用继承，effic java推荐“使用组合而不是继承”，使类多，且低效
  4. 默认的THREAD_POOL_EXECUTOR线程池配置不太合适

线程池

线程

简述线程池

android中线程池主要实现是ThreadPoolExecutor

参数：

  • 核心线程数：如果指定ThreadPoolExecutor的allowCoreThreadTimeOut这个属性为true，那么核心线程如果不干活(闲置状态)的话，超过一定时间，就会被销毁掉
  • 最大线程数： = 核心线程数 + 非核心线程数
  • 超时时间：非核心线程的闲置超时时间
  • 超时时间单位：非核心线程的闲置超时时间单位
  • 线程等待队列：当所有的核心线程都在干活时，新添加的任务会被添加到这个队列中等待处理，如果队列满了，则新建非核心线程执行任务
  • 线程创建工厂：线程池的拒绝策略，可以出错，也可以顾虑

allowCoreThreadTimeOut设置为true，非核心线程超时时间同样用于核心线程，如果为false，核心线程永远不会终止

  1. SynchronousQueue（空集合）：这个队列接收到任务的时候，会直接提交给线程处理，而不保留它，如果所有线程都在工作怎么办？那就新建一个线程来处理这个任务！所以为了保证不出现<线程数达到了maximumPoolSize而不能新建线程>的错误，使用这个类型队列的时候，maximumPoolSize一般指定成Integer.MAX_VALUE，即无限大

  2. LinkedBlockingQueue（大小无限）：这个队列接收到任务的时候，如果当前线程数小于核心线程数，则新建线程(核心线程)处理任务；如果当前线程数等于核心线程数，则进入队列等待。由于这个队列没有最大值限制，即所有超过核心线程数的任务都将被添加到队列中，这也就导致了maximumPoolSize的设定失效，因为总线程数永远不会超过corePoolSize

  3. ArrayBlockingQueue（大小可以设置）：可以限定队列的长度，接收到任务的时候，如果没有达到corePoolSize的值，则新建线程(核心线程)执行任务，如果达到了，则入队等候，如果队列已满，则新建线程(非核心线程)执行任务，又如果总线程数到了maximumPoolSize，并且队列也满了，则发生错误

  4. DelayQueue（延迟出队，大小可以设置）：队列内元素必须实现Delayed接口，这就意味着你传进去的任务必须先实现Delayed接口。这个队列接收到任务时，首先先入队，只有达到了指定的延时时间，才会执行任务

规则：

  1. 未达到核心线程数，新建核心线程
  2. 达到或者大于核心线程数，任务被插入任务队列等待执行
  3. 步骤2中无法插入队列（队列满了），线程数量小于线程池最大值，启动一个非核心线程执行任务
  4. 步骤3 中线程数量达到最大值，则拒绝执行此任务

android主要分为几种线程池？

四种

FixedThreadPool：全是核心线程，没有超时机制，任务队列没有大小限制

CachedThreadPool：全是非核心线程，最大为Integer.MAX_VALUE，空闲线程60s超时（60s内可以复用，60s后回收），适用于执行短时的大量任务，空闲时也不占用cpu资源

ScheduledThreadPool：核心线程固定，非核心线程为Interger.MAX_VALUE，非核心线程无超时机制（执行完就被回收），适用执行定时任务和固定周期任务

SingleThreadExecutor：只有一个核心线程，无超时机制，保证只在一个线程中执行任务

线程池中一个线程崩溃会导致线程池崩溃吗？

不会，线程池存在两种方式去执行线程任务，submit和execute方式。 当发生线程崩溃时，execute下会将线程关闭，开辟新的线程，submit会返回异常，但不会关闭线程。

submit：

  • 继承自ExecutorService
  • 不会抛出栈堆异常，通过Future.get方法获取异常信息
  • submit通过构造一个RunnableFuture后，执行execute方法，RunnableFuture内部使用状态管理，通过死循环判断任务执行状态，在执行完或者cancle后返回，

get()方法是一个阻塞方法，在调用时需要注意

execute：

  • 继承自Executor
  • 会抛出堆栈异常信息，关闭该线程并创建新的线程

如何检测线程池中的崩溃问题呢？

submit的get()方法可以获取崩溃，但是该方法是阻塞的，可用性不高，于是我们使用另一种方法

  1. execute+ThreadFactory.UncaughtExceptionHandler 在submit下UncaughtExceptionHandler失效，因为FutureTask会捕获异常并保存不会放入UncaughtExceptionHandler中
  2. 在run方法中自行捕获
  3. 重写ThreadLocalExecutor.afterExecute方法
  4. submit+get方法
转载自:https://juejin.cn/post/6972045203980943397
评论
请登录