大疆面试

线程进程的区别

进程是资源分配的基本单位，它拥有自己独立的内存空间，包括代码段、数据段、堆栈段等。一个进程包含了程序运行所需的各种资源，如文件描述符、打开的文件、信号处理等。例如，当我们在手机上同时打开相机应用和音乐播放应用，这两个应用就是两个独立的进程，它们的资源（如内存使用、文件访问权限等）是相互隔离的。

线程是进程中的执行单元，一个进程可以包含多个线程。线程共享进程的资源，如内存空间等。它们在进程的内存空间中并发执行，能够更高效地利用 CPU 资源。例如，在一个文档编辑应用中，一个线程可以负责用户输入的接收，另一个线程可以负责文档内容的自动保存，它们共享应用进程的内存，这样可以加快应用的响应速度。

从调度角度来看，进程之间的切换开销较大，因为操作系统需要切换内存空间等资源。而线程切换的开销相对较小，因为它们共享进程的大部分资源，只需要切换执行上下文（如程序计数器、寄存器等）。

在通信方面，进程间通信相对复杂，需要使用一些特殊的机制，如管道、消息队列、共享内存等。而线程间通信比较简单，因为它们共享内存，可以直接通过共享变量进行通信，但这也需要注意线程安全问题。

线程同步的几种方式

互斥锁（synchronized 关键字）：在 Java 中，synchronized 关键字可以用于修饰方法或者代码块。当一个线程访问被 synchronized 修饰的方法或者代码块时，它会获取对象的锁。其他线程如果想要访问同一个对象的被 synchronized 修饰的部分，就必须等待当前线程释放锁。例如，有一个银行账户类，有存款和取款方法，当一个线程在执行取款操作时，使用 synchronized 修饰取款方法，那么其他线程就不能同时对这个账户进行取款或者存款操作，直到当前线程完成取款并释放锁。这种方式能够保证同一时刻只有一个线程访问被保护的资源，有效地避免了数据不一致的情况。
ReentrantLock 类：这是 Java 提供的另一种可重入锁。它和 synchronized 关键字类似，但提供了更灵活的功能。例如，它可以实现公平锁和非公平锁。公平锁是指按照线程请求锁的顺序来分配锁，而非公平锁则不保证这个顺序。使用 ReentrantLock 时，需要手动获取锁和释放锁，在 try 块中获取锁，在 finally 块中释放锁，这样可以确保锁一定会被释放。例如，在一个多线程下载文件的场景中，为了避免多个线程同时写入同一个文件导致文件损坏，可以使用 ReentrantLock 来保证每次只有一个线程写入文件。
信号量（Semaphore）：信号量用于控制同时访问某个特定资源的线程数量。它维护了一个许可证的计数。线程在访问资源之前需要获取许可证，当许可证数量为 0 时，线程需要等待。例如，在一个数据库连接池的场景中，数据库连接是有限的资源。可以使用信号量来控制同时访问数据库连接的线程数量。假设数据库连接池中有 5 个连接，就可以创建一个初始许可证数量为 5 的信号量。线程在需要访问数据库时，先获取信号量的许可证，如果许可证数量大于 0，线程就可以获取许可证并使用数据库连接，当使用完后释放许可证。这样可以有效地控制对数据库连接这一有限资源的并发访问。
条件变量（Condition）：条件变量通常和锁一起使用，用于线程之间的通信。它允许线程在满足一定条件时等待，直到其他线程通知它条件已经满足。例如，在一个生产者 - 消费者模型中，生产者生产数据，消费者消费数据。当缓冲区为空时，消费者线程需要等待生产者生产数据。可以使用条件变量来实现这个等待和通知机制。当消费者发现缓冲区为空时，它会调用条件变量的 await 方法等待，当生产者生产了数据后，会调用条件变量的 signal 或者 signalAll 方法来通知等待的消费者线程。

说说 GC 机制

垃圾回收（GC）是 Java 和 Android 中自动管理内存的一种机制，它主要用于回收那些不再被程序使用的对象所占用的内存空间。

在 Java 和 Android 的运行环境中，内存是有限的资源。当我们创建对象时，内存会被分配来存储这些对象的信息。但是随着程序的运行，有些对象可能不再被使用，这些对象如果不及时回收，就会导致内存泄漏，最终可能使程序因为内存不足而崩溃。

垃圾回收器（Garbage Collector）会定期或者在内存不足时自动运行。它会通过一些算法来判断哪些对象是可以回收的。其中，最常用的算法之一是引用计数法和可达性分析算法。

引用计数法是比较简单的一种方式，它会为每个对象维护一个引用计数。当一个对象被引用时，引用计数加 1，当引用被释放时，引用计数减 1。当引用计数为 0 时，就表示这个对象可以被回收。但是这种方法存在一个问题，就是无法解决循环引用的情况。例如，有两个对象 A 和 B，A 引用 B，B 也引用 A，它们的引用计数都不会为 0，但实际上这两个对象可能已经没有其他地方引用它们了，应该被回收。

可达性分析算法是目前主流的算法。它从一些被称为 “GC Roots” 的对象开始向下搜索。GC Roots 包括虚拟机栈（栈帧中的本地变量表）中引用的对象、方法区中类静态属性引用的对象、方法区中常量引用的对象等。通过搜索，那些可以从 GC Roots 到达的对象被认为是存活的，而那些无法到达的对象则被认为是垃圾，可以被回收。

垃圾回收器在回收内存时，还需要考虑如何回收内存空间。不同的垃圾回收器有不同的回收策略。例如，标记 - 清除算法会先标记出所有需要回收的对象，然后统一清除这些对象。但是这种方法会产生内存碎片，因为清除后的内存空间是不连续的。为了解决这个问题，又出现了标记 - 整理算法，它在标记完需要回收的对象后，会将存活的对象向一端移动，然后清除掉边界以外的内存空间，这样就可以避免内存碎片。另外，还有复制算法，它将内存分为大小相等的两块，每次只使用其中一块。当需要进行垃圾回收时，将存活的对象复制到另一块内存中，然后清空原来使用的那块内存。这种方法不会产生内存碎片，但是它的内存利用率较低，因为有一半的内存空间是闲置的。

在 Android 开发中，不同版本的 Android 系统可能会使用不同的垃圾回收器。例如，在早期的 Android 系统中，使用的是标记 - 清除算法的垃圾回收器，这种回收器在回收内存时可能会导致应用的卡顿。而在较新的 Android 系统中，引入了更先进的垃圾回收器，如 ART（Android Runtime）中的垃圾回收器，它在性能和内存管理方面都有了很大的改进。

Java 中的四种引用

强引用（Strong Reference）：这是最常见的引用类型。当我们通过 “new” 关键字创建一个对象并将其赋值给一个变量时，这个变量对对象的引用就是强引用。例如，“Object obj = new Object ();”，这里的 “obj” 就是对新创建的 “Object” 对象的强引用。只要强引用存在，垃圾回收器就不会回收被引用的对象。这是因为强引用表明程序仍然在使用这个对象。在一个应用中，比如一个用户登录后的用户信息对象，只要应用还在使用这个用户的信息，这个用户信息对象就会通过强引用被持有，不会被垃圾回收。
软引用（Soft Reference）：软引用是一种相对较弱的引用。它所引用的对象在内存充足的情况下不会被回收，但是当内存不足时，垃圾回收器会考虑回收软引用所指向的对象。软引用通常用于实现缓存机制。例如，在一个图片加载应用中，我们可以使用软引用来缓存已经加载过的图片。当内存充足时，这些图片对象可以一直保存在内存中，方便用户再次查看时快速加载。但是当内存紧张，需要为新的对象分配空间时，垃圾回收器可能会回收这些软引用的图片对象。
弱引用（Weak Reference）：弱引用比软引用更弱。一旦垃圾回收器发现了弱引用的对象，就会立即回收它，而不管当前内存是否充足。弱引用主要用于解决一些特殊的内存管理问题，比如在一些容器类中，如果容器中的元素只被弱引用所引用，那么当没有其他强引用指向这些元素时，它们就可以被垃圾回收。例如，在一个使用 WeakHashMap 的场景中，WeakHashMap 中的键是弱引用。当一个键对象没有其他强引用时，即使 WeakHashMap 还在引用这个键对象，垃圾回收器也会回收这个键对象，并且 WeakHashMap 会自动删除对应的键值对。
虚引用（Phantom Reference）：虚引用是最弱的一种引用。虚引用的对象在任何时候都可能被回收。虚引用主要用于在对象被回收时收到一个系统通知，它不能单独使用，必须和引用队列（ReferenceQueue）一起使用。例如，在一些资源清理的场景中，当一个对象被垃圾回收时，通过虚引用和引用队列，可以让程序知道这个对象已经被回收，从而可以进行一些后续的资源清理工作，比如关闭文件、释放网络连接等。

面向对象三大特性：继承、封装、多态（详细讲一下）

继承
- 继承是面向对象编程中一个重要的概念，它允许一个类（子类）继承另一个类（父类）的属性和方法。例如，我们有一个 “动物” 类，它有一些基本的属性，如 “体重”“年龄”，还有一些基本的方法，如 “进食”“睡眠”。然后我们可以创建一个 “狗” 类来继承 “动物” 类，“狗” 类就自动拥有了 “动物” 类的 “体重”“年龄” 属性和 “进食”“睡眠” 方法。同时，“狗” 类还可以添加自己特有的属性和方法，如 “品种” 属性和 “摇尾巴” 方法。这样就实现了代码的复用，减少了重复代码的编写。
- 在 Java 和 Android 中，继承是通过 “extends” 关键字来实现的。子类可以继承父类的非私有成员（包括属性和方法）。而且，子类可以根据需要重写父类的方法。例如，在上面的例子中，“狗” 类可以重写 “动物” 类的 “进食” 方法，来实现狗特有的进食方式。继承还存在多层继承的情况，例如，我们可以有一个 “哺乳动物” 类继承 “动物” 类，然后 “狗” 类继承 “哺乳动物” 类，这样就形成了一个继承层次结构。这种层次结构可以更好地组织代码，体现事物之间的关系。但是，过度使用继承也可能会导致代码的复杂性增加，因为子类会紧密依赖于父类的实现。
封装
- 封装是指将对象的属性和方法包装在一个类中，并且对外部隐藏对象的内部实现细节。例如，我们有一个 “银行账户” 类，它有 “账户余额” 这个属性。我们不希望外部的代码可以随意修改这个属性，因为这可能会导致账户余额出现不合理的情况。所以，我们可以将 “账户余额” 属性设为私有（在 Java 中使用 “private” 关键字），然后提供一些公共的方法（如 “存款”“取款” 方法）来操作这个属性。外部代码只能通过这些公共方法来访问和修改账户余额，这样就保证了账户余额的安全性和合理性。
- 封装还可以提高代码的可维护性。当我们需要修改类的内部实现时，只要保持公共方法的接口不变，外部使用这个类的代码就不需要修改。例如，我们可能会改变 “银行账户” 类中账户余额的存储方式，从一个简单的变量存储变为一个数据库存储。只要我们在 “存款”“取款” 等公共方法中正确地更新和获取账户余额，外部代码就不会受到影响。此外，封装还可以通过访问控制符（如 “private”“protected”“public”）来控制不同范围的访问权限，从而更好地组织代码。
多态
- 多态是指同一个行为在不同的对象上有不同的表现形式。在 Java 和 Android 中有两种实现多态的方式，一种是通过方法重写（Override），另一种是通过方法重载（Overload）。
- 方法重写是在继承关系中，子类重写父类的方法。例如，在上面提到的 “动物” 和 “狗” 的例子中，“动物” 类有一个 “发出声音” 的方法，在 “狗” 类中可以重写这个方法，让狗发出 “汪汪” 的声音。当我们通过一个 “动物” 类型的变量来调用 “发出声音” 的方法时，如果这个变量实际指向的是一只狗，那么就会调用狗重写后的 “发出声音” 方法。这就实现了多态，同一个 “发出声音” 的方法调用，在不同的对象（动物和狗）上有不同的表现形式。
- 方法重载是指在同一个类中，有多个方法名相同但参数列表不同的方法。例如，我们有一个 “计算器” 类，它有一个 “计算” 方法，可以有不同的参数形式，如两个整数相加的参数形式，或者一个整数和一个浮点数相乘的参数形式等。当我们调用 “计算” 方法时，编译器会根据我们传入的参数类型和数量来决定调用哪个具体的 “计算” 方法。这也是一种多态的表现形式，同一个 “计算” 方法名，根据不同的参数有不同的执行行为。

抽象类和接口的区别

定义和概念
- 抽象类是一种不能被实例化的类，它主要用于被其他类继承。抽象类中可以包含抽象方法和非抽象方法。抽象方法是只有方法声明而没有方法体的方法，它强制子类必须实现这个方法。例如，我们有一个 “图形” 抽象类，它有一个抽象方法 “计算面积”。任何继承这个 “图形” 抽象类的子类，如 “圆形”“矩形”，都必须实现 “计算面积” 方法。抽象类还可以有非抽象方法，这些方法可以被子类继承和直接使用。
- 接口是一种特殊的抽象类型，它只包含抽象方法和常量。接口中的方法默认都是抽象方法，在 Java 8 之前，接口中的方法是不能有方法体的。从 Java 8 开始，接口可以有默认方法和静态方法。接口主要用于定义一组行为规范，一个类可以实现多个接口。例如，我们有一个 “可打印” 接口，它有一个 “打印” 方法。一个 “文档” 类和一个 “图片” 类都可以实现这个 “可打印” 接口，并且实现自己的 “打印” 方法，这样就统一了不同类型对象的打印行为规范。
语法区别
- 在 Java 和 Android 中，抽象类使用 “abstract” 关键字来定义，抽象方法也需要使用 “abstract” 关键字声明。例如，“abstract class Shape { abstract double calculateArea (); }”。而接口使用 “interface” 关键字定义，接口中的方法默认是抽象方法，不需要额外的 “abstract” 关键字。例如，“interface Printable { void print (); }”。
- 一个类只能继承一个抽象类，这是因为 Java 是单继承语言。例如，一个 “圆形” 类继承了 “图形” 抽象类后，就不能再继承其他抽象类了。但是一个类可以实现多个接口，这可以让一个类具备多种行为规范。例如，一个 “智能手机” 类可以实现 “可打电话” 接口和 “可拍照” 接口等。
使用场景区别
- 抽象类通常用于表示一种具有层次结构的抽象概念，它的子类通常是一种具体的类型，并且在抽象类中可以共享一些通用的方法和属性。例如，在一个图形绘制系统中，“图形” 抽象类可以包含一些通用的属性，如颜色、位置等，并且可以有一些通用的方法，如设置颜色、移动位置等。子类 “圆形” 和 “矩形” 在继承 “图形” 抽象类后，可以共享这些属性和方法，并且实现自己特有的 “计算面积” 等方法。
- 接口主要用于定义不同类之间的共同行为规范。例如，在一个多媒体播放系统中，有 “音频播放器” 类和 “视频播放器” 类，它们都可以实现一个 “播放媒体” 接口，这个接口定义了 “播放”“暂停”“停止” 等方法。通过实现这个接口，不同的播放器类就可以遵循统一的播放行为规范，方便系统的管理和调用。

线程池的种类有哪些

FixedThreadPool（固定大小线程池）：它的特点是线程池中的线程数量是固定的。在创建时就确定了线程的数量，当有新任务提交时，如果线程池中有空闲线程，就会直接分配任务给空闲线程执行；如果没有空闲线程，任务就会在任务队列中等待，直到有线程空闲。这种线程池适用于处理一些负载比较稳定的任务，比如在一个简单的网络爬虫程序中，我们可以根据网络请求的数量和服务器的处理能力设置一个固定数量的线程来处理网页下载任务，避免创建过多线程导致系统资源耗尽。它可以保证线程数量的稳定性，对于资源的控制比较有效。
CachedThreadPool（可缓存线程池）：这种线程池的线程数量是根据任务的数量动态变化的。如果有新任务提交，并且当前没有空闲线程，就会创建一个新线程来处理任务；如果线程在一段时间（默认 60 秒）内处于空闲状态，就会被回收。它适用于执行一些生存期较短的异步任务，例如在一个图形界面应用中，处理用户的一些即时操作，如按钮点击后的短暂数据加载或者计算任务。因为这些任务通常是突发的，并且执行时间较短，使用可缓存线程池可以在任务密集时快速创建线程处理，任务完成后空闲线程又可以被回收，有效利用资源。
ScheduledThreadPool（定时线程池）：主要用于执行定时任务或者周期性任务。它可以安排任务在指定的延迟时间后执行，或者按照固定的周期重复执行。例如，在一个系统监控应用中，我们可以使用定时线程池来定期（如每隔 10 分钟）收集系统的性能数据，如 CPU 使用率、内存占用等。它的内部通过一个延迟队列来管理任务，保证任务按照预定的时间执行，这对于需要定时执行任务的场景非常方便，能够精准地控制任务的执行时间和周期。
SingleThreadExecutor（单线程线程池）：线程池中只有一个线程。所有任务按照提交的顺序依次执行，这种线程池可以保证任务的执行顺序，并且由于只有一个线程，对于一些需要保证顺序和原子性的简单任务很有用。比如在一个日志记录系统中，为了保证日志记录的顺序性，我们可以使用单线程线程池来处理日志的写入操作，避免多个线程同时写入日志文件导致日志混乱。

多线程问题及解决方案

线程安全问题：当多个线程同时访问和修改共享资源时，可能会导致数据不一致的情况。例如，多个线程同时对一个计数器进行加 1 操作，可能会出现覆盖的情况，导致计数不准确。
- 解决方案：可以使用同步机制来解决，如互斥锁（synchronized 关键字或者 ReentrantLock 类）。通过在访问共享资源的代码块或者方法上添加锁，保证同一时刻只有一个线程能够访问和修改共享资源。例如，对于上述计数器的情况，我们可以将加 1 操作的方法用 synchronized 关键字修饰，这样在一个线程执行该方法时，其他线程就需要等待，从而保证了数据的准确性。另外，还可以使用原子类（如 AtomicInteger 等），原子类在底层通过 CAS（比较并交换）操作来保证对数据的原子性修改，避免了使用锁带来的性能开销和可能出现的死锁问题。
死锁问题：当多个线程相互等待对方释放资源时，就会出现死锁。例如，线程 A 持有资源 1 并等待资源 2，而线程 B 持有资源 2 并等待资源 1，这样两个线程就会一直等待下去，导致程序无法继续执行。
- 解决方案：可以通过合理的资源分配和锁定顺序来避免。在设计程序时，确定一个固定的资源获取顺序，所有线程都按照这个顺序获取资源。例如，在涉及多个数据库表操作的场景中，如果有两个线程分别需要对表 A 和表 B 进行操作，并且可能会出现交叉获取锁的情况，我们可以规定所有线程先获取表 A 的锁，再获取表 B 的锁，这样就可以避免死锁。另外，也可以使用死锁检测工具来检测和发现程序中可能存在的死锁情况，及时调整代码。
线程饥饿问题：指的是一个线程由于优先级较低或者其他原因，长时间无法获取 CPU 资源而不能执行。例如，在一个高优先级线程不断抢占 CPU 资源的系统中，低优先级线程可能会一直处于等待状态。
- 解决方案：可以通过合理设置线程优先级来解决。在 Java 中，线程优先级是一个整数，范围从 1 到 10，默认是 5。我们可以根据任务的重要性和紧急程度合理分配优先级，避免某些线程一直被高优先级线程抢占资源。同时，也要避免过度依赖线程优先级，因为线程优先级的实现依赖于操作系统，不同操作系统对线程优先级的处理方式可能不同。另外，还可以采用公平调度策略，保证每个线程都有机会获取 CPU 资源，如在一些线程池的实现中，可以选择公平锁来实现公平调度。

OOM 异常，如何处理

理解 OOM 异常（OutOfMemoryError）：这是一种内存溢出异常，通常是因为程序申请的内存超过了系统能够提供的内存。在 Android 开发中，有多种情况可能导致 OOM。例如，在加载大量图片时，如果不进行适当的处理，很容易导致内存溢出。因为图片占用的内存空间较大，当同时加载很多高分辨率图片时，内存使用量会急剧上升。另外，在处理一些复杂的数据结构，如大量的递归数据或者对象之间存在复杂的引用关系时，也可能导致内存泄漏，最终引发 OOM。
内存泄漏导致的 OOM 处理方法
- 检测内存泄漏：可以使用 Android Studio 自带的内存分析工具，如 Memory Profiler。它可以帮助我们发现内存泄漏的源头。例如，当我们怀疑某个 Activity 存在内存泄漏时，可以通过 Memory Profiler 查看该 Activity 对象的引用情况，发现是否有一些对象不应该地持有了 Activity 的引用，导致 Activity 无法被垃圾回收。
- 避免对象的不当持有：在 Android 中，常见的内存泄漏情况是内部类持有外部类的引用。比如，在一个 Activity 中定义了一个内部类的异步任务（如 AsyncTask），如果内部类的生命周期超过了 Activity 的生命周期，并且内部类持有 Activity 的引用，就会导致 Activity 无法被正常回收。解决方法是将内部类改为静态内部类，并通过弱引用（WeakReference）的方式持有外部类的引用。
图片加载导致的 OOM 处理方法
- 图片压缩：在加载图片之前，可以根据显示的需求对图片进行压缩。例如，如果图片只是在一个小的 ImageView 中显示，就不需要加载原始的高分辨率图片。可以使用 Android 提供的 BitmapFactory.Options 来进行压缩。通过设置 inSampleSize 参数，可以按照一定比例缩小图片。例如，设置 inSampleSize 为 2，表示将图片的宽和高都缩小为原来的 1/2，这样图片占用的内存就会变为原来的 1/4。
- 使用图片缓存：可以使用一些图片缓存库，如 Glide 或者 Picasso。这些库会自动管理图片的缓存，避免重复加载相同的图片。它们会根据一定的策略，如 LRU（最近最少使用）缓存策略，当内存不足时，会自动清除一些最近最少使用的图片，从而释放内存。

Final 有什么用

用于修饰变量
- 基本数据类型变量：当一个基本数据类型变量（如 int、float 等）被 final 修饰时，它的值就不能被改变。例如，“final int num = 10;”，在后续的代码中，不能再对 “num” 进行赋值操作。这在一些需要常量的场景中非常有用，比如数学计算中的圆周率 “π”，可以定义为 “final double PI = 3.1415926;”，这样可以保证在整个程序中这个常量的值不会被意外修改，提高了程序的稳定性和可预测性。
- 引用数据类型变量：对于引用数据类型变量（如对象、数组等），被 final 修饰后，变量所指向的对象或数组的引用不能被改变，但是对象或数组的内部内容可以被修改。例如，final ArrayList<String> list = new ArrayList<>();，不能再让 “list” 指向其他的 ArrayList 对象，但是可以对 “list” 中的元素进行添加、删除等操作。这在一些需要固定引用的场景中很有用，比如在一个配置管理类中，有一个 final 的配置对象引用，这个引用在整个类的生命周期中不能被改变，但是配置对象内部的属性可以根据需要进行修改。
用于修饰方法：当一个方法被 final 修饰时，这个方法不能被子类重写。例如，在一个基类中有一个重要的计算方法，这个方法的实现是固定的，不希望子类改变它的实现，就可以将这个方法定义为 final。这可以保证方法的行为在继承体系中的一致性，防止子类对关键方法进行不恰当的修改，从而破坏程序的逻辑。比如在一个图形绘制类中，有一个 “绘制基本图形” 的方法，这个方法的实现是根据固定的规则来绘制图形，为了保证图形绘制的正确性，将这个方法定义为 final，子类在继承这个类时就不能改变这个方法的实现，只能使用这个方法来绘制基本图形。
用于修饰类：当一个类被 final 修饰时，这个类不能被继承。例如，在一些安全敏感或者功能已经固定的类中，可以将类定义为 final。这可以防止其他类继承这个类并修改它的行为。比如在一个密码加密类中，为了保证加密算法的安全性和完整性，将这个类定义为 final，避免其他类继承并可能错误地修改加密算法。

Java 的可见性修饰符区别

public（公共的）
- 可见范围：被 public 修饰的成员（包括类、方法、变量等）在任何地方都可以被访问。例如，在一个 Java 项目中有多个包，一个类中的 public 方法在其他包中的类也可以直接调用。这是最宽松的访问控制修饰符，它提供了最大的可见性。在设计一些对外提供服务的接口或者工具类时，通常会将主要的方法和成员定义为 public。比如，一个公共的数学计算工具类，它的加法、减法等计算方法可以定义为 public，方便其他类在任何地方都能使用这些方法进行计算。
private（私有的）
- 可见范围：被 private 修饰的成员只能在所属的类内部被访问。这是最严格的访问控制修饰符，用于隐藏类的内部实现细节。例如，在一个银行账户类中，账户余额这个变量可以定义为 private，然后通过公共的存款、取款方法来操作这个变量。这样，外部的类就不能直接访问和修改账户余额，保证了数据的安全性和封装性。在类的设计中，对于一些内部使用的变量或者辅助方法，通常会使用 private 修饰，避免外部类的干扰和错误使用。
protected（受保护的）
- 可见范围：被 protected 修饰的成员可以在所属的类内部、同一个包中的其他类以及该类的子类中被访问。它主要用于在继承关系中提供一定程度的访问权限。例如，在一个基类中有一个 protected 方法，这个方法可以被基类中的其他方法调用，也可以被同一个包中的其他类调用，同时，子类在继承这个基类后也可以调用这个 protected 方法。在设计类的继承体系时，对于一些需要在子类中访问和重写的方法，通常会使用 protected 修饰，这样既保证了一定的封装性，又方便了子类的继承和扩展。
默认（没有修饰符）
- 可见范围：如果一个成员没有使用任何可见性修饰符，它的可见范围是在所属的类内部和同一个包中的其他类。这种默认的访问控制方式在一些只需要在包内共享的成员中比较有用。例如，在一个包内的多个工具类之间可能会共享一些数据或者方法，这些共享的部分可以不使用修饰符，这样它们在包内是可见的，但是对于其他包中的类是不可见的，从而实现了一定程度的封装和信息隐藏。

匿名内部类为什么可以访问外部类的对象

在 Java 和 Android 开发中，匿名内部类能够访问外部类的对象是因为内部类持有了外部类的引用。当创建一个匿名内部类时，编译器会自动为其添加一个指向外部类实例的引用。

从内存角度看，外部类的对象先被创建，在创建匿名内部类对象时，会隐式地将外部类对象的引用传递给匿名内部类。这使得匿名内部类可以访问外部类对象的成员变量和方法。例如，在一个包含按钮点击事件的 Android 活动（Activity）中，我们在 Activity 内部定义一个匿名内部类来处理按钮点击事件。这个匿名内部类可以访问 Activity 的成员变量，如文本视图（TextView）的引用，从而在按钮点击时更新文本视图的内容。

从语法规则角度讲，Java 语言规范允许内部类访问外部类的成员。这种设计机制方便了代码的编写，尤其是在事件处理等场景中。例如，当使用 Android 的视图（View）系统时，我们经常会为视图的各种事件（如点击、长按等）定义匿名内部类作为事件处理器。这些匿名内部类可以方便地访问外部类（通常是 Activity 或 Fragment）中的资源，如布局中的其他视图、存储的数据等。

另外，这种访问机制也遵循了封装的原则。虽然匿名内部类可以访问外部类的对象，但它仍然受到访问修饰符的限制。如果外部类的成员是私有的（private），那么只有在外部类内部定义的匿名内部类才能访问这些成员。这确保了数据的安全性和合理的访问范围。

讲一下泛型擦除

泛型擦除是 Java 语言中的一个重要特性。在 Java 编译器处理泛型代码时，会执行泛型擦除操作。简单来说，泛型擦除就是在编译后的字节码中，泛型类型信息被擦除，只保留原始类型。

从原理上看，在编译阶段，编译器会将泛型类型参数替换为它们的边界或者 Object 类型。例如，如果有一个泛型类定义为 class Generic<T extends Number>，在编译后，T 会被替换为 Number 类型。如果没有定义边界，就会被替换为 Object 类型。这样做的主要目的是为了兼容旧版本的 Java 代码，因为 Java 在早期版本中是没有泛型的。

在运行时，由于泛型类型信息被擦除，通过反射等方式获取的类型信息是原始类型，而不是泛型类型。例如，对于一个 List<String> 类型的对象，在运行时通过反射获取它的类型，得到的是 “List” 类型，而不是 List<String> 类型。这就导致了一些在编译时看起来安全的泛型操作，在运行时可能会出现类型转换异常。

为了在一定程度上弥补泛型擦除带来的问题，Java 提供了一些方法来在运行时获取泛型类型信息，比如通过使用类型标记（Type Token）的方式。但是这种方式相对复杂，并且不是完全的泛型支持。

在实际应用中，泛型擦除可能会影响代码的编写。例如，在编写一个泛型方法时，不能依赖运行时的泛型类型信息来进行逻辑判断。同时，在实现一些泛型容器类时，需要注意泛型擦除可能导致的类型安全问题，如在将一个元素添加到泛型容器中时，不能保证在运行时这个元素的类型是符合预期的泛型类型的。

Synchronize，底层实现是怎么做的，Synchronize 加在 Static 和非 Static 的区别

Synchronize 底层实现

在 Java 和 Android 的 JVM（Java 虚拟机）中，synchronized 关键字的底层实现主要依赖于对象头（Object Header）和监视器（Monitor）。

对象头是对象在内存中的一部分，它存储了对象的一些元数据，其中包括锁状态等信息。当一个线程访问一个被 synchronized 修饰的方法或者代码块时，JVM 会通过对象头来判断对象的锁状态。如果对象没有被锁定，线程会将对象头中的锁标志位设置为锁定状态，并获取该对象的监视器。

监视器是一种同步机制，它可以理解为一个管理锁的对象。每个对象都有一个与之关联的监视器。当线程获取了对象的监视器后，其他线程如果想要访问同一个被 synchronized 修饰的对象，就需要等待当前线程释放监视器。在底层，监视器的实现涉及到操作系统的互斥锁（Mutex）和信号量（Semaphore）等机制。当一个线程进入被 synchronized 修饰的代码块或者方法时，实际上是通过操作系统的互斥锁来实现对共享资源的独占访问，以保证同一时刻只有一个线程能够访问。

Synchronize 加在 Static 和非 Static 的区别

当 synchronized 修饰非静态方法时，锁是基于对象实例的。每个对象实例都有自己的锁。例如，有一个类 “Counter”，其中有一个非静态的 “increment” 方法被 synchronized 修饰。如果创建了两个 “Counter” 对象 “counter1” 和 “counter2”，那么当一个线程访问 “counter1.increment ()” 时，另一个线程仍然可以访问 “counter2.increment ()”，因为它们是两个不同的对象实例，拥有各自的锁。

而当 synchronized 修饰静态方法时，锁是基于类对象的。对于一个类来说，类对象是唯一的。所以，无论创建多少个该类的实例，当一个线程访问被 synchronized 修饰的静态方法时，其他线程都不能访问这个类的其他被 synchronized 修饰的静态方法。例如，对于一个 “Utils” 类，有一个静态的 “doSomething” 方法被 synchronized 修饰。无论在程序中创建了多少个 “Utils” 类的实例，当一个线程正在执行 “Utils.doSomething ()” 时，其他线程就不能同时执行这个方法。这是因为所有的静态方法共享同一个类级别的锁。

这种区别在多线程编程中非常重要。在设计类和方法时，需要根据实际的业务逻辑和并发访问的需求来决定是使用基于对象实例的锁还是基于类对象的锁。如果需要对每个对象实例的操作进行同步，就使用非静态的 synchronized 方法；如果需要对整个类的某种行为进行同步，比如类的全局配置操作，就使用静态的 synchronized 方法。

一个线程中的 loop 可以对应多个 Handler 吗？

在 Android 中，一个线程中的 Looper 是可以对应多个 Handler 的。

Looper 主要负责管理消息队列（MessageQueue），它会不断地从消息队列中取出消息并进行分发处理。Handler 则用于发送和处理消息。一个线程中可以有多个 Handler 实例，它们都可以关联到同一个 Looper。

从消息传递角度看，多个 Handler 可以利用同一个 Looper 的消息队列来传递消息。例如，在一个复杂的 Android 应用的后台线程中，可能有不同的功能模块需要发送和处理消息。一个用于网络数据接收的 Handler 可以将接收到的数据消息发送到消息队列，一个用于文件写入的 Handler 可以将文件写入的进度等消息发送到同一消息队列。这些 Handler 通过同一个 Looper 来实现消息的循环处理。

从对象关联角度讲，Handler 在创建时可以指定与之关联的 Looper。如果没有指定，它会默认使用当前线程的 Looper。这使得在一个有 Looper 的线程中，可以方便地创建多个 Handler 来满足不同的业务需求。比如在一个主线程中，有一个 Handler 用于更新 UI 界面上的文本信息，另一个 Handler 用于处理用户手势操作后的动画显示。它们都和主线程的 Looper 关联，通过这个 Looper 来确保消息在合适的时机被处理，以保证 UI 操作的顺序性和线程安全性。

而且，每个 Handler 可以有自己独特的消息处理方式和消息类型。这样，不同的 Handler 可以根据自己的规则从消息队列中筛选和处理属于自己的消息，进一步体现了多个 Handler 与一个 Looper 配合的灵活性，能够更好地组织和处理一个线程中的多种消息相关事务。

如何判断单向链表存在环？

判断单向链表是否存在环可以使用快慢指针的方法。

首先，定义两个指针，一个是快指针（fast），一个是慢指针（slow）。慢指针每次移动一个节点，快指针每次移动两个节点。如果链表不存在环，那么快指针会先到达链表的末尾（即指向 null）。如果链表存在环，快指针和慢指针会在环内相遇。

从原理上分析，假设链表有环，当慢指针进入环时，快指针已经在环内。由于快指针的速度是慢指针的两倍，快指针会逐渐追上慢指针。例如，设慢指针进入环时，快指针与慢指针的距离为 n 个节点。在每次移动中，快指针与慢指针之间的距离会减少 1 个节点。所以经过 n 次移动后，快指针就会和慢指针相遇。

在代码实现上，可以通过以下步骤：首先初始化快慢指针都指向链表的头节点。然后进入循环，循环条件是快指针和快指针的下一个节点都不为空。在循环中，慢指针每次移动一个节点，快指针每次移动两个节点。如果在循环过程中，快指针和慢指针相遇，就可以判断链表存在环。

另外，还有一种标记节点的方法来判断链表是否有环。这种方法是在遍历链表的过程中，对已经访问过的节点进行标记。如果在后续的遍历中，遇到了已经标记过的节点，那么就可以判断链表存在环。不过这种方法可能需要对链表节点的结构进行修改，或者使用额外的空间来存储标记信息，相对而言，快慢指针的方法更加高效，并且不需要对链表结构进行额外的修改。

字节流和字符流的区别？

字节流和字符流是 Java 中用于处理输入输出（I/O）的两种不同的流类型。

字节流主要用于处理二进制数据，它以字节（8 位）为单位进行数据的读写。字节流的两个基类是 InputStream（输入字节流）和 OutputStream（输出字节流）。例如，在读取一个文件的二进制内容（如图片、视频等文件）或者通过网络传输二进制数据时，就会使用字节流。字节流可以处理所有类型的数据，因为所有的数据在计算机底层都是以二进制形式存储的。它不关心数据的具体格式，只是单纯地读写字节序列。

字符流则主要用于处理文本数据，它以字符为单位进行数据的读写。字符流的两个基类是 Reader（输入字符流）和 Writer（输出字符流）。字符流在处理文本时，会考虑字符编码。例如，当读取一个 UTF - 8 编码的文本文件时，字符流会根据 UTF - 8 的编码规则将字节序列转换为字符。这使得字符流在处理文本数据时更加方便，因为它可以直接操作字符，而不需要手动进行编码转换。

在读写效率方面，字节流在处理二进制数据时效率较高，因为它不需要进行字符编码和解码的操作。而字符流在处理文本数据时，由于其能够自动处理字符编码，对于文本的读写更加直观和方便。不过，字符流在内部实现上，其实也是基于字节流的，它会在字节流的基础上进行字符编码和解码的操作。

在应用场景上，字节流适用于所有类型的数据传输和存储，特别是非文本的二进制数据。而字符流主要用于处理文本相关的操作，如读取和写入文本文件、在网络上传输文本数据等。

平衡二叉树的概念？

平衡二叉树是一种特殊的二叉树结构。它的主要特点是左右子树的高度差的绝对值不超过 1，并且左右子树也是平衡二叉树。

从结构特点上看，平衡二叉树的目的是为了避免二叉树出现过于倾斜的情况。例如，如果二叉树是完全不平衡的，如所有节点都在一侧，那么在进行查找、插入和删除操作时，时间复杂度可能会退化为线性时间（O (n)），这与普通链表的性能差不多。而平衡二叉树通过保持自身的平衡结构，可以保证这些操作的时间复杂度在最坏情况下仍然是对数时间（O (logn)）。

在平衡二叉树中，有多种实现方式，如 AVL 树和红黑树。AVL 树是比较严格的平衡二叉树，它在每次插入或删除节点后，会通过旋转操作来重新平衡树。旋转操作包括左旋、右旋等，通过调整节点的位置来保持树的平衡。例如，当插入一个节点导致某一子树的高度差超过 1 时，AVL 树会通过合适的旋转操作来调整树的结构，使它重新满足平衡二叉树的定义。

红黑树也是一种平衡二叉树，但它的平衡要求相对宽松一些。红黑树通过节点的颜色（红色或黑色）来维护树的平衡。在插入和删除节点时，通过一系列复杂的规则来调整节点颜色和树的结构，以保证从根节点到叶子节点的最长路径不超过最短路径的两倍，从而达到平衡的效果。

平衡二叉树在实际应用中非常广泛，特别是在需要高效的查找、插入和删除操作的场景中。例如，在数据库的索引结构、操作系统的文件系统等中，平衡二叉树可以大大提高数据的检索和管理效率。

数组和链表的存储方式，查询效率？

存储方式

数组是一种连续存储的数据结构。它在内存中占用一段连续的存储空间，所有元素按照顺序依次存储。例如，一个整型数组 “int [] array = new int [5];”，这 5 个整数在内存中是一个挨着一个存储的。这种存储方式使得数组在访问元素时，可以通过计算偏移量来快速定位元素。因为数组的元素类型相同，每个元素占用的存储空间是固定的，所以只要知道数组的起始地址和元素的索引，就可以通过简单的计算得到元素的地址。

链表则是一种非连续存储的数据结构。链表中的每个节点包含数据部分和指向下一个节点（在单向链表中）的指针。节点在内存中的位置是不固定的，它们通过指针相互连接。例如，在一个单向链表中，一个节点存储了一个数据元素，并且有一个指针指向下一个节点。这种存储方式使得链表在插入和删除节点时比较灵活，不需要像数组那样移动大量的元素。

查询效率

对于数组，查询效率很高。因为可以通过索引直接计算出元素的位置，所以查询一个元素的时间复杂度是 O (1)。例如，对于一个长度为 n 的数组 “array”，要获取 “array [3]” 这个元素，无论数组的长度是多少，都可以通过一个简单的计算快速定位到这个元素。

而对于链表，查询效率相对较低。如果要查找链表中的一个元素，需要从链表的头节点开始，逐个节点遍历。在最坏的情况下，可能需要遍历整个链表才能找到目标元素。所以，链表查询一个元素的时间复杂度是 O (n)，其中 n 是链表的长度。例如，在一个有 n 个节点的链表中查找一个特定的数据元素，平均需要遍历 n/2 个节点，随着链表长度的增加，查询时间也会线性增加。

Java 基本数据类型及所占字节

Java 有 8 种基本数据类型，它们在内存中占用不同数量的字节，并且有各自的取值范围。

首先是整型数据类型。byte 类型占 1 个字节，它的取值范围是 - 128 到 127。例如，当存储一些小范围的整数，如文件中的字节数据或者简单的计数器等，byte 类型就很合适。short 类型占 2 个字节，取值范围是 - 32768 到 32767。int 类型是最常用的整型类型，占 4 个字节，取值范围为 - 2147483648 到 2147483647，适用于大多数整数运算场景，比如数组的索引、循环计数等。long 类型占 8 个字节，用于存储更大范围的整数，它的取值范围是 - 9223372036854775808 到 9223372036854775807。

接着是浮点型数据类型。float 类型占 4 个字节，它可以表示小数，但是精度相对较低，适用于对精度要求不高的场景，比如简单的科学计算或者图形处理中的一些位置坐标等。double 类型占 8 个字节，精度比 float 高，在大多数涉及小数的数学计算和高精度的数值处理场景中使用，如金融计算等。

然后是字符型数据类型。char 类型占 2 个字节，用于存储单个字符，如字母、数字、标点符号等，它可以通过 Unicode 编码来表示世界上各种语言的字符。

最后是布尔型数据类型。boolean 类型只占 1 位，它只有两个值，true 和 false，用于逻辑判断，比如条件语句中的判断条件、循环的终止条件等。这些基本数据类型是 Java 编程的基础，它们的大小和取值范围决定了在不同场景下的数据存储和运算方式。

“==” 和 “equal” 使用，还有一些使用上的区别？

在 Java 中，“==” 和 “equals” 方法都用于比较，但它们有明显的区别。

“==” 是一个运算符，它比较的是两个对象的引用是否相同，也就是判断两个变量是否指向内存中的同一个对象。例如，对于基本数据类型，“==” 比较的是它们的值是否相等。如 “int a = 5; int b = 5;”，此时 “a == b” 的结果为真，因为它们的值相同。但对于对象类型，情况就不同了。如果有两个对象 “Object obj1 = new Object (); Object obj2 = new Object ();”，那么 “obj1 == obj2” 的结果为假，因为它们是两个不同的对象实例，在内存中有不同的引用。

“equals” 方法主要用于比较对象的内容是否相等。在 Java 中，所有的类都继承自 Object 类，Object 类中的 “equals” 方法默认也是比较引用是否相同。但是，很多类会重写 “equals” 方法来定义自己的比较规则。例如，在 String 类中，“equals” 方法会比较两个字符串的字符序列是否相同。如 “String str1 = "hello"; String str2 = "hello";”，“str1.equals (str2)” 的结果为真，因为它们的字符序列相同，尽管它们在内存中可能是两个不同的对象。

在使用上，如果只是想简单地判断两个变量是否是同一个对象，就使用 “==”。如果想比较对象的内容是否相同，特别是对于自定义的类，就需要使用 “equals” 方法，并且通常需要重写 “equals” 方法来定义符合业务逻辑的比较规则。如果不重写 “equals” 方法，在比较自定义类的对象时，可能会得到不符合预期的结果，因为默认的比较方式是比较引用。

object 中的 wait 方法和 notify 方法怎样联合使用？

在 Java 中，Object 类中的 wait、notify 和 notifyAll 方法主要用于线程间的协作和同步。

wait 方法用于使当前线程进入等待状态，它会释放当前对象的锁。例如，在一个生产者 - 消费者模型中，消费者线程在发现缓冲区为空时，会调用缓冲区对象的 wait 方法，使自己进入等待状态，等待生产者生产数据。这个等待状态会一直持续，直到有其他线程调用该对象的 notify 或者 notifyAll 方法。

notify 方法用于唤醒在该对象上等待的一个线程。当一个线程调用了对象的 notify 方法后，在这个对象上等待的线程中会有一个被唤醒。不过，被唤醒的线程不会立即执行，它需要重新获取对象的锁才能继续执行。例如，在生产者 - 消费者模型中，当生产者生产了一个数据后，它会调用缓冲区对象的 notify 方法，唤醒一个正在等待的消费者线程。

在联合使用时，通常会在一个同步块或者同步方法中使用这些方法。首先，多个线程需要共享一个对象，并且通过这个对象的锁来进行同步。例如，假设有一个共享的资源对象 “Resource”，多个线程需要访问和修改这个资源。线程在访问资源之前，需要获取对象的锁。如果一个线程发现资源不满足自己的需求（如消费者发现没有产品可消费），它会在同步块中调用对象的 wait 方法进入等待状态。当其他线程修改了资源（如生产者生产了产品），在同步块中调用对象的 notify 或者 notifyAll 方法来唤醒等待的线程。

这种协作机制可以有效地协调多个线程之间的执行顺序，避免了线程之间的无序竞争，提高了程序的可靠性和效率。但在使用时，需要注意正确地获取和释放锁，以及合理地判断何时调用 wait 和 notify 方法，以避免出现死锁或者线程饥饿等问题。

Android 活动的启动流程。

在 Android 中，活动（Activity）的启动是一个复杂的过程，涉及多个组件的协作。

当一个活动被启动时，首先是从用户操作或者其他组件的请求开始。例如，用户点击了应用图标，系统会接收到这个启动请求。系统会检查是否已经有这个应用的进程存在。如果不存在，就会通过 Zygote 进程来创建一个新的应用进程。Zygote 进程是 Android 系统中的一个特殊进程，它可以快速地创建新的应用进程，通过复制自身的内存空间来实现高效的进程创建。

在新的应用进程中，会创建一个 ActivityThread 对象。ActivityThread 是 Android 应用的主线程，它负责管理活动、广播接收器、服务等组件的生命周期。然后，系统会通过 ActivityThread 来加载并解析活动的配置信息，包括布局文件、主题等。

接着，系统会创建活动对象，并调用其一系列生命周期方法。首先是 onCreate 方法，在这个方法中，开发者可以进行一些初始化操作，如设置布局、初始化成员变量等。然后是 onStart 方法，此时活动变得可见，但还不能与用户进行交互。之后是 onResume 方法，在这个阶段，活动完全可见并且可以接收用户的输入，如触摸、按键等操作。

在整个启动过程中，系统还会涉及到资源的分配，如内存分配、视图层次结构的构建等。并且，活动的启动还可能受到系统资源管理的影响，如当内存不足时，系统可能会回收一些处于后台的活动，以释放内存。这些活动在重新回到前台时，会根据其保存的状态进行恢复，这也是活动启动流程中的一个重要环节，涉及到 onSaveInstanceState 和 onRestoreInstanceState 等方法的使用。

详细说 Fragment。

Fragment 是 Android 中用于构建灵活的用户界面的组件。

从概念上讲，Fragment 是一种可以嵌入到 Activity 中的模块，它有自己的生命周期，并且可以独立于 Activity 进行部分操作。例如，一个 Fragment 可以包含自己的视图层次结构，包括布局文件中的各种视图元素，如按钮、文本视图等。它可以在不同的 Activity 中被复用，这使得代码的复用性大大提高。

在生命周期方面，Fragment 的生命周期与 Activity 的生命周期紧密相关，但又有自己的特点。当一个 Fragment 被添加到 Activity 中时，它会经历一系列的生命周期阶段。首先是 onAttach 方法，在这个方法中，Fragment 会与 Activity 建立关联，它可以获取到所在 Activity 的引用。接着是 onCreate 方法，这里可以进行一些初始化操作，如初始化 Fragment 的成员变量、恢复之前保存的状态等。

onCreateView 方法是 Fragment 生命周期中非常重要的一个环节，在这个方法中，Fragment 会创建并返回自己的视图。通常会通过加载布局文件来实现，如使用 LayoutInflater 来加载一个 XML 布局文件，并将其返回。之后是 onActivityCreated 方法，此时 Activity 的 onCreate 方法已经执行完毕，Fragment 可以在这里进行一些与 Activity 相关的操作，如获取 Activity 中的资源等。

在使用场景方面，Fragment 可以用于构建多面板的用户界面。例如，在平板电脑的大屏幕上，可以同时显示多个 Fragment，一个 Fragment 用于显示列表，另一个 Fragment 用于显示列表项的详细内容。在手机等小屏幕设备上，这些 Fragment 可以通过切换的方式来显示，从而提供了一种自适应不同屏幕尺寸的解决方案。

Fragment 还可以用于实现动态的用户界面更新。例如，在一个新闻应用中，一个 Fragment 可以用于显示新闻列表，当用户点击某一条新闻时，可以通过替换 Fragment 或者更新 Fragment 中的内容来显示新闻的详细内容，这样可以提供更加流畅的用户体验。

Activity 的生命周期（onResume，onStart，onCreate）

onCreate 方法

onCreate 是 Activity 生命周期中最早被调用的重要方法。当 Activity 首次创建时，系统会调用这个方法。在这个方法中，主要进行一些初始化的操作。例如，设置 Activity 的布局，通过调用 setContentView 方法并传入布局资源 ID，来定义 Activity 的用户界面外观。同时，也会初始化 Activity 的各种成员变量，这些变量可能用于存储数据、管理视图状态或者与其他组件交互。

另外，onCreate 方法还可以用于恢复之前保存的 Activity 状态。如果 Activity 之前被系统销毁（比如因为内存不足），可以通过 onCreate 方法中的 Bundle 参数来恢复之前存储的数据。例如，之前用户在一个文本框中输入的内容，可以通过从 Bundle 中获取数据并重新设置到文本框中，使得用户体验更加连贯。

onStart 方法

onStart 方法在 Activity 变得可见时被调用。在这个阶段，Activity 已经完成了部分初始化工作，并且即将展示给用户。不过，此时 Activity 还不能与用户进行交互，比如用户还不能点击按钮或者输入文字。onStart 方法主要用于一些与 Activity 可见性相关的操作。

例如，在这个阶段可以开始加载一些与界面显示相关的资源，如动画资源。如果 Activity 包含一些需要在可见时就开始的动画，就可以在 onStart 方法中启动动画。而且，当 Activity 从后台重新回到前台时，也会调用 onStart 方法，这可以帮助我们在 Activity 重新可见时进行一些必要的更新操作。

onResume 方法

onResume 方法在 Activity 准备好与用户进行交互时被调用。此时，Activity 已经完全可见，并且用户可以对其进行各种操作，如触摸屏幕、按键等。在这个阶段，一些需要实时响应用户操作的资源应该被完全准备好。

例如，对于一些传感器相关的应用，如重力感应游戏，在 onResume 方法中可以注册传感器监听器，以便能够及时获取传感器数据并更新游戏状态。而且，当 Activity 从暂停状态（如被一个对话框覆盖或者屏幕被锁定）恢复时，也会调用 onResume 方法，保证 Activity 能够顺利地重新开始接收用户的输入并更新界面。

静态广播、动态广播的概念及区别

静态广播概念

静态广播是在 AndroidManifest.xml 文件中进行注册的广播。这种广播在应用安装时，系统就会知道这个应用可以接收哪些广播消息。例如，当注册一个接收系统开机完成广播的静态广播时，即使应用没有运行，当系统开机完成后，系统也会自动启动应用并将开机完成的广播发送给对应的广播接收器。

静态广播的注册方式相对固定，它通过在 AndroidManifest.xml 文件中使用<receiver>标签来定义广播接收器，并且可以指定接收广播的类型、优先级等信息。这种广播适合接收一些系统级别的重要广播，或者一些不依赖于应用当前运行状态的广播消息。

动态广播概念

动态广播是在代码运行过程中通过调用 Context 的 registerReceiver 方法来进行注册的广播。与静态广播不同，动态广播只有在代码执行注册操作后才会开始接收广播消息。例如，在一个音乐播放应用中，可以在播放音乐的服务启动后，动态注册一个广播接收器来接收耳机插拔的广播，这样可以根据耳机的插拔状态来暂停或者继续播放音乐。

动态广播的灵活性较高，它可以根据应用的运行状态和具体需求来决定何时开始和结束接收广播。而且，可以在运行时传递一些参数来更精确地控制广播的接收和处理。

两者区别

注册方式上，静态广播在 AndroidManifest.xml 文件中注册，是一种永久性的注册方式，只要应用安装后就一直有效；动态广播是在代码运行过程中注册，注册和注销都需要在代码中手动操作。

接收广播的时机方面，静态广播可以接收在应用未启动时发出的广播；动态广播只能接收在注册之后发出的广播。另外，在组件的生命周期方面，静态广播接收器的生命周期由系统管理，只要应用不被卸载，它就一直存在；动态广播接收器的生命周期取决于注册和注销的代码位置，一旦注销或者所在的组件（如 Activity、服务）被销毁，就不再接收广播。

自定义 view 的过程

自定义 View 是 Android 开发中用于创建独特用户界面组件的重要方式。

首先是确定自定义 View 的功能和外观。在开始编写代码之前，需要明确这个自定义 View 要实现什么样的功能，比如是一个可以自定义形状的按钮，还是一个带有特殊动画效果的进度条。同时，也要考虑它的外观设计，包括形状、颜色、尺寸等方面的要求。

然后是继承合适的 View 类。如果是一个简单的自定义 View，通常可以继承 View 类。如果这个自定义 View 是基于已有的组件进行扩展，比如自定义一个带有特殊功能的 EditText，就可以继承 EditText 类。在继承后，需要重写一些重要的方法。

其中，onMeasure 方法是关键之一。这个方法用于确定自定义 View 的大小。在 onMeasure 方法中，需要根据父容器传递过来的测量要求（MeasureSpec 参数），结合自身的需求，计算出合适的宽度和高度。例如，对于一个可以自适应内容的自定义文本视图，需要根据文本的长度和字体大小等来计算视图的宽度，根据行数等来计算高度。

onDraw 方法用于绘制自定义 View 的内容。在这个方法中，通过使用 Canvas 对象来进行绘制操作。可以使用 Paint 对象来设置绘制的颜色、样式等参数。例如，要绘制一个圆形的自定义 View，就可以在 onDraw 方法中，使用 Canvas 的 drawCircle 方法，结合合适的 Paint 对象来绘制出圆形。

另外，还需要考虑自定义 View 的事件处理。如果自定义 View 需要响应用户的操作，如触摸、点击等，就需要重写 onTouchEvent 或者其他相关的事件处理方法。例如，对于一个自定义的滑动条 View，需要在 onTouchEvent 方法中处理用户的触摸滑动操作，根据触摸的位置来更新滑动条的状态并重新绘制。

gradle 的启动流程

Gradle 是一个强大的构建工具，在 Android 开发中用于构建、测试和发布应用。

当启动 Gradle 时，首先会加载 Gradle 的核心配置文件。这些配置文件定义了 Gradle 的基本行为和一些全局属性。Gradle 会解析这些文件中的内容，包括插件的定义、仓库的配置等。例如，在一个 Android 项目的根目录下的 build.gradle 文件中，定义了项目级别的插件，如 Android 插件，Gradle 会在启动时识别并加载这个插件。

接着，Gradle 会根据配置文件中的仓库配置来获取所需的依赖。它会检查本地仓库是否已经存在所需的库文件，如果不存在，就会从远程仓库（如 Maven Central、JCenter 等）下载。这个过程涉及到网络请求和文件下载，Gradle 会根据依赖的版本号和其他属性来准确地获取合适的文件。

在获取依赖后，Gradle 会开始构建项目。对于 Android 项目，它会首先解析 Android 项目的结构，包括各个模块（如 app 模块、library 模块）。然后，根据模块中的资源文件（如布局文件、资源字符串等）、Java 代码文件和依赖关系来编译代码。在编译过程中，Gradle 会对 Java 代码进行语法检查、字节码生成等操作，对于 Android 资源文件，会进行资源的打包和适配不同设备的处理。

Gradle 还会执行测试任务（如果配置了测试）。它会运行单元测试和集成测试等，通过执行测试用例来检查代码的质量和功能是否符合预期。最后，Gradle 可以根据配置来生成发布版本的文件，如 APK 文件，并且可以对发布文件进行签名等操作，以便将应用发布到应用商店或者其他渠道。

handler 机制

Handler 机制在 Android 中用于线程间的通信，特别是在处理与 UI 线程相关的任务时非常重要。

Handler 主要包含四个关键部分：Handler、Looper、MessageQueue 和 Message。Handler 用于发送和接收消息，它是开发者直接使用的接口。可以通过 Handler 的 sendMessage 方法发送一个 Message 对象到消息队列中。例如，在一个后台线程中获取了一些数据后，通过 Handler 将数据封装成 Message 发送到主线程，用于更新 UI。

Looper 是一个消息循环器，它会不断地从 MessageQueue 中取出消息并分发给对应的 Handler 进行处理。每个线程中最多只有一个 Looper，在主线程中，系统会自动创建一个 Looper，而在其他线程中，如果需要使用 Handler 机制，需要手动创建 Looper。Looper 的 loop 方法是整个消息循环的核心，它会一直循环，直到 MessageQueue 为空并且没有新的消息进来。

MessageQueue 是一个消息队列，用于存储消息。消息以队列的形式排列，按照先进先出的原则。当 Handler 发送消息时，消息会被添加到 MessageQueue 的末尾。在 MessageQueue 中，消息包含了一些重要的信息，如消息的目标 Handler、消息的参数等。

Message 是消息的载体，它可以携带各种数据。例如，可以通过 Message 的 obj 字段来携带一个自定义的对象，或者通过 arg1 和 arg2 字段来携带两个整数参数。当一个消息被从 MessageQueue 中取出并分发给 Handler 后，Handler 会根据消息的内容进行相应的处理，如更新 UI、执行一些后台任务等。这种机制有效地实现了不同线程之间的通信，保证了在 Android 中 UI 操作的线程安全性。

MVVM 和 MVC 的区别

MVC（Model - View - Controller）

MVC 架构主要由三部分组成。Model 是数据模型，它负责处理数据的存储、获取以及业务逻辑。例如，在一个用户管理系统中，Model 负责与数据库交互，进行用户数据的增删改查操作。View 是视图层，它主要负责展示数据给用户，通常是由各种 UI 组件构成。在 Android 中，可能是布局文件中的各种视图，如 TextView 展示文本信息，ListView 展示列表数据。Controller 是控制器，它作为 Model 和 View 之间的桥梁，接收用户在 View 上的操作，并根据操作来调用 Model 的方法进行数据处理，然后将处理后的结果更新到 View 上。

例如，用户在一个登录界面（View）输入账号和密码后点击登录按钮，Controller 会接收到这个点击事件，然后调用 Model 中的用户验证方法。如果验证成功，Controller 会通知 View 显示登录成功的界面；如果验证失败，会通知 View 显示错误信息。MVC 的优点是职责明确，易于理解和开发。但是，在复杂的应用中，Controller 可能会变得臃肿，因为它需要处理大量的视图和模型之间的交互逻辑。

MVVM（Model - View - ViewModel）

MVVM 也包含三个主要部分。Model 同样是数据模型，负责数据存储和业务逻辑。View 还是视图层，用于展示数据。ViewModel 是 MVVM 的核心部分，它是一种数据绑定的中间层。ViewModel 会暴露一些可观察的数据属性和命令，这些属性和命令会与 View 进行数据绑定。

例如，在一个具有实时数据更新的界面中，ViewModel 中的数据属性可以通过数据绑定机制自动更新 View。当 Model 中的数据发生变化时，ViewModel 会感知到这个变化，并将更新后的数据传递给 View。同时，View 中的用户操作也可以通过数据绑定触发 ViewModel 中的命令，进而影响 Model。MVVM 的优点是通过数据绑定减少了大量的手动 UI 更新代码，使得代码更加简洁和易于维护。并且它更好地分离了视图和业务逻辑，提高了代码的可测试性。

总的来说，MVC 和 MVVM 的主要区别在于数据和视图的交互方式。MVC 通过 Controller 来手动更新视图，而 MVVM 通过数据绑定和 ViewModel 来自动更新视图。MVVM 在处理复杂的 UI 和数据交互场景时更加灵活和高效。

MVP 中的 presenter 如何调用其他 presenter

在 MVP（Model - View - Presenter）架构中，Presenter 主要负责处理业务逻辑和与 View 进行交互。当一个 Presenter 需要调用另一个 Presenter 时，通常有以下几种方式。

一种方式是通过接口来实现。可以定义一个接口，该接口包含另一个 Presenter 需要被调用的方法。例如，假设有一个用户登录 Presenter 和一个用户信息展示 Presenter。用户登录成功后，需要展示用户信息。可以在用户信息展示 Presenter 中定义一个接口，如 “showUserInfo (User user)”，然后在用户登录 Presenter 中获取用户信息展示 Presenter 的实例，并通过这个接口来调用展示用户信息的方法。

另一种方式是通过事件总线（Event Bus）来实现。事件总线是一种消息传递机制，它可以在不同的组件之间传递消息。在这种情况下，一个 Presenter 可以发送一个事件，另一个 Presenter 可以订阅这个事件。当发送事件的 Presenter 需要调用另一个 Presenter 时，就发送一个包含相关参数的事件。例如，使用像 GreenRobot 的 EventBus 库，在用户登录 Presenter 中，当登录成功后，发送一个 “UserLoggedInEvent” 事件，其中包含用户信息。用户信息展示 Presenter 可以订阅这个事件，当接收到这个事件后，就可以根据事件中的用户信息来进行展示。

这种跨 Presenter 的调用需要注意避免循环依赖和过度耦合的问题。要确保每个 Presenter 的职责清晰，并且通过合理的接口或者事件机制来实现调用，以保证代码的可维护性和可扩展性。

内存泄露如何检测与避免

内存泄露检测

在 Android 开发中，可以使用多种工具来检测内存泄露。一种常用的工具是 Android Studio 自带的 Memory Profiler。它可以实时监测应用的内存使用情况。通过 Memory Profiler，可以查看对象的内存分配情况，发现那些不应该存在的对象引用。例如，在一个 Activity 的生命周期结束后，如果发现 Activity 对象仍然存在于内存中，就可能存在内存泄露。

另外，还可以使用 LeakCanary 工具。LeakCanary 是一个专门用于检测内存泄露的开源库。它可以自动检测内存泄露，并且在检测到泄露时会给出详细的报告。它的原理是通过监控对象的生命周期和引用关系来发现泄露。例如，当一个对象应该被垃圾回收但由于某些原因没有被回收时，LeakCanary 会捕获到这个情况，并显示出导致泄露的引用链，帮助开发者快速定位问题。

内存泄露避免

在代码层面，避免内部类对外部类的不当引用可以防止很多内存泄露。例如，在一个 Activity 中定义了一个内部类的异步任务（如 AsyncTask），如果内部类的生命周期超过了 Activity 的生命周期，并且内部类持有 Activity 的引用，就会导致 Activity 无法被正常回收。解决方法是将内部类改为静态内部类，并通过弱引用（WeakReference）的方式持有外部类的引用。

对于资源的释放也要注意。比如在使用数据库连接、文件流等资源时，要确保在不需要使用时及时关闭。如果忘记关闭这些资源，它们会一直占用内存，导致内存泄露。在注册广播接收器等组件时，也要注意在合适的时机进行注销。例如，在 Activity 的 onDestroy 方法中注销动态注册的广播接收器，以避免广播接收器一直占用内存。

在使用单例模式时，也要防止单例对象持有过多的对象引用导致内存泄露。例如，一个单例的缓存类，如果它缓存了大量的对象，并且这些对象又持有其他对象的引用，可能会导致一些对象无法被正常回收。要定期清理单例对象中的缓存，或者采用合适的缓存策略（如 LRU 缓存）来避免内存泄露。

四大组件，分别的作用

Activity（活动）

Activity 是 Android 应用中最直观的组件，主要用于实现用户界面。它可以包含各种视图（View），如按钮、文本框等，用户通过与这些视图进行交互来使用应用。例如，在一个购物应用中，商品展示界面、购物车界面、支付界面等都是通过 Activity 来实现的。Activity 有自己完整的生命周期，从创建（onCreate）到销毁（onDestroy），在不同的生命周期阶段可以进行不同的操作，如在 onCreate 阶段初始化界面布局，在 onResume 阶段开始接收用户的操作。

Service（服务）

Service 主要用于在后台执行长时间运行的操作，不提供用户界面。例如，在一个音乐播放应用中，音乐播放的逻辑可以放在 Service 中，即使应用的界面（Activity）被切换或者关闭，音乐仍然可以继续播放。Service 可以通过 startService 或者 bindService 两种方式启动。它可以与其他组件进行通信，如通过广播或者绑定接口来告知其他组件自己的状态。

Broadcast Receiver（广播接收器）

Broadcast Receiver 用于接收系统或者应用发出的广播消息。例如，当系统开机完成时会发出一个开机广播，应用中的广播接收器可以接收这个广播并进行相应的操作，如启动一些初始化的服务。广播接收器可以是静态注册（在 AndroidManifest.xml 文件中注册），也可以是动态注册（在代码中通过 Context 注册）。它可以接收多种类型的广播，包括系统广播（如网络变化广播、电量变化广播）和应用自定义的广播。

Content Provider（内容提供者）

Content Provider 用于在不同的应用之间共享数据。例如，在一个联系人应用中，它可以通过 Content Provider 将联系人数据提供给其他应用使用。Content Provider 使用一种类似于数据库的方式来管理和提供数据，其他应用可以通过 ContentResolver 来访问 Content Provider 中的数据。它可以提供多种数据操作，如查询、插入、更新和删除，使得数据的共享和交互更加方便和安全。

服务的两种启动方式

startService 方式

当使用 startService 方法启动服务时，服务会在后台独立运行，不受启动它的组件（如 Activity）的生命周期影响。例如，在一个文件下载应用中，当用户点击下载按钮后，可以通过 startService 方法启动一个下载服务。这个下载服务会在后台持续运行，直到下载任务完成或者出现错误。

一旦服务通过 startService 方式启动，它会一直运行，即使启动它的组件被销毁。服务可以通过自身的生命周期方法（如 onStartCommand）来接收启动它的意图（Intent），并根据意图中的参数来执行相应的任务。在这种启动方式下，服务与启动组件之间的联系相对较弱，主要是通过意图来传递信息。

bindService 方式

bindService 方式启动服务是为了实现服务与其他组件之间的交互和通信。当一个组件（如 Activity）通过 bindService 方法绑定一个服务时，它们之间会建立一个连接。例如，在一个音乐播放应用中，Activity 可以通过 bindService 方式绑定音乐播放服务，这样 Activity 就可以获取音乐播放的状态（如播放进度、是否暂停等），并且可以向服务发送控制指令（如播放、暂停、停止等）。

在 bindService 启动方式下，服务的生命周期与绑定它的组件的生命周期相关。当所有绑定的组件都与服务解除绑定后，服务会自动停止。这种启动方式可以使服务和其他组件之间形成紧密的交互关系，方便数据和指令的传递，同时也可以更好地控制服务的生命周期。

屏幕旋转时，碎片的生命周期怎么变化的？

当屏幕旋转时，Fragment 的生命周期会受到一定的影响，其变化过程如下：

首先，当屏幕开始旋转时，Activity 会被销毁并重新创建，与之关联的 Fragment 也会经历相应的生命周期变化。在 Activity 执行 onDestroy 之前，Fragment 会先执行 onDestroyView 方法，此时 Fragment 的视图层次结构会被销毁，但 Fragment 实例本身仍然存在。

接着，在 Activity 重新创建后，Fragment 会依次执行 onCreate、onCreateView 等方法来重新构建视图层次结构。如果在 onCreate 方法中进行了一些数据的初始化操作，那么这些操作会在每次屏幕旋转时重新执行。

需要注意的是，在屏幕旋转过程中，如果 Fragment 中的数据需要在旋转后保持不变，可以通过在 Fragment 的 onSaveInstanceState 方法中保存数据，并在 onCreate 或 onViewCreated 方法中恢复数据来实现。

例如，一个包含有用户输入信息的 Fragment，在屏幕旋转时，可以将用户输入的数据保存到 Bundle 中，然后在重新创建视图时再将数据恢复到相应的视图控件中，以保证用户体验的连贯性。

总的来说，屏幕旋转时 Fragment 的生命周期变化与 Activity 的生命周期紧密相关，开发者需要合理地处理这些生命周期方法，以确保 Fragment 在不同的屏幕方向下都能正确地显示和交互。

对动画了解吗？

Android 中的动画主要用于为用户界面提供视觉效果，增强用户体验。以下是几种常见的动画类型及其特点：

补间动画（Tween Animation）：通过对视图的属性进行渐变来实现动画效果，如平移、缩放、旋转、透明度变化等。它可以在 XML 中定义动画的起始值、结束值、持续时间等参数，也可以通过代码动态创建。补间动画的优点是使用简单，能够快速地为视图添加基本的动画效果。例如，可以使用平移动画让一个按钮从屏幕的一侧移动到另一侧，或者使用缩放动画让一个图标逐渐变大或变小。

帧动画（Frame Animation）：由一系列连续的图片帧组成，通过快速切换这些图片帧来形成动画效果，类似于电影的播放原理。帧动画需要事先准备好一系列的图片资源，然后在 XML 或代码中定义动画的播放顺序、帧率等。它适用于一些需要复杂、细腻动画效果的场景，如实现一个人物的行走动画等，但由于需要加载多张图片，可能会占用较多的内存资源。

属性动画（Property Animation）：可以对任何对象的属性进行动画操作，不仅限于视图的属性。它通过改变对象的属性值来实现动画效果，提供了更强大、更灵活的动画功能。属性动画可以在一定时间内平滑地改变对象的属性，如颜色、位置、大小等，并且可以设置动画的插值器、估值器等，以实现不同的动画效果和速度曲线。例如，可以使用属性动画让一个自定义视图的背景颜色逐渐变化，或者让一个对象沿着复杂的路径移动。

在实际应用中，动画可以用于各种场景，如界面的切换效果、元素的显示和隐藏动画、交互反馈动画等。合理地使用动画可以使应用更加生动、吸引人，提高用户的参与度和满意度。同时，为了确保动画的流畅性和性能，还需要注意优化动画的资源使用和执行效率，避免过度使用复杂的动画导致应用卡顿。

事件冲突的问题？

在 Android 开发中，事件冲突是指当多个视图或视图组嵌套在一起时，对于同一触摸事件，可能会出现多个视图都想要处理该事件的情况，从而导致事件的处理结果不符合预期。以下是一些常见的事件冲突场景和解决方法：

滑动冲突

场景：常见于可滑动的视图与父容器或其他可滑动视图嵌套的情况，例如 ScrollView 中嵌套了 ListView，或者 ViewPager 中嵌套了 RecyclerView 等。当用户在屏幕上进行滑动操作时，可能会出现父容器和子视图都想要响应滑动事件的冲突。
解决方法：
- 外部拦截法：在父容器的 onInterceptTouchEvent 方法中，根据一定的条件来拦截或不拦截触摸事件。例如，当用户的滑动方向主要是水平方向时，父容器拦截事件并进行处理，当滑动方向主要是垂直方向时，不拦截事件，让子视图处理。
- 内部拦截法：子视图通过调用 requestDisallowInterceptTouchEvent 方法来请求父容器不拦截事件，然后在子视图的 onTouchEvent 方法中根据自身的逻辑来处理事件，并在适当的时候允许父容器拦截事件。

点击事件冲突

场景：当多个视图重叠或嵌套时，点击一个位置可能会同时触发多个视图的点击事件。例如，一个按钮被放置在一个 ImageView 之上，当用户点击按钮所在位置时，按钮和 ImageView 的点击事件都可能会被触发。
解决方法：
- 事件分发机制：利用 Android 的事件分发机制，通过合理地重写视图的 dispatchTouchEvent、onInterceptTouchEvent 和 onTouchEvent 方法来控制事件的流向。一般来说，可以在父容器的 dispatchTouchEvent 方法中根据触摸点的位置、视图的可见性等条件来决定将事件分发给哪个子视图，或者直接在父容器中处理事件而不传递给子视图。
- 设置点击事件优先级：可以通过为不同的视图设置不同的点击事件优先级来解决冲突。例如，使用 setOnClickListener 方法为视图设置点击事件时，可以根据业务逻辑来确定哪个视图的点击事件应该先被处理，然后按照优先级顺序依次处理点击事件。

长按事件与其他事件冲突

场景：当一个视图同时设置了长按事件和其他触摸事件（如点击事件、滑动事件等）时，可能会出现长按事件与其他事件的冲突。例如，用户在长按一个按钮时，可能会意外地触发了按钮的点击事件。
解决方法：
- 延迟处理：在长按事件的处理方法中，可以通过设置一定的延迟时间来判断用户是否真的是长按操作。如果在延迟时间内用户没有抬起手指，则认为是长按操作，执行长按事件的逻辑；如果在延迟时间内用户抬起了手指，则不执行长按事件，而是根据手指抬起的位置和时间等条件来判断是否触发其他事件。
- 使用 GestureDetector：使用 GestureDetector 来统一处理各种触摸手势事件，包括点击、长按、滑动等。通过设置 GestureDetector 的相关回调方法，可以更精确地控制事件的处理逻辑，避免不同事件之间的冲突。

总之，解决事件冲突的关键是要深入理解 Android 的事件分发机制，根据具体的业务场景和需求，合理地重写视图的相关事件处理方法，以确保触摸事件能够被正确地处理和响应，提供良好的用户交互体验。

对 jetpack 了解吗？

Jetpack 是 Android 开发中的一套组件库，旨在帮助开发者更轻松地构建高质量的 Android 应用，它具有以下特点和优势：

架构组件

LiveData：是一种可观察的数据持有者类，它遵循观察者模式，能够感知数据的变化并及时通知观察者。LiveData 具有生命周期感知能力，只有在观察者的生命周期处于活跃状态时才会接收数据更新，避免了内存泄漏和不必要的资源消耗。例如，在一个 ViewModel 中使用 LiveData 来存储和管理界面数据，当数据发生变化时，与之绑定的视图会自动更新，无需手动刷新界面。
ViewModel：用于存储和管理与界面相关的数据，它的生命周期与 Activity 或 Fragment 的生命周期相关联，但不受配置变化（如屏幕旋转）的影响。这意味着在屏幕旋转等情况下，ViewModel 中的数据不会丢失，能够保证界面数据的一致性和连续性。例如，在一个购物应用中，购物车的商品列表数据可以存储在 ViewModel 中，无论屏幕如何旋转，购物车中的商品信息都能保持不变。
Room：是 Android 上的一个持久化库，它提供了一种简洁、高效的方式来处理 SQLite 数据库操作。Room 使用注解来定义数据库表、实体类和 DAO（数据访问对象），大大简化了数据库的操作流程，并且支持异步查询和数据观察等功能，方便开发者与数据库进行交互，实现数据的持久化存储。

导航组件

提供了一种简单而强大的方式来实现应用内的导航功能，包括屏幕之间的切换、传递参数、处理返回栈等。通过 Navigation Graph 可以直观地定义应用的导航流程和页面之间的关系，并且支持动画过渡效果、深层链接等功能，使得应用的导航更加清晰、流畅和易于维护。

数据绑定库

允许将布局文件中的视图与数据对象进行绑定，实现数据的自动更新和视图的响应式更新。开发者可以在布局文件中使用表达式语言来绑定视图的属性和数据对象的字段，从而减少了大量的 findViewById 和数据更新的样板代码，提高了开发效率和代码的可读性。

其他组件

还包括 WorkManager 用于处理后台任务的调度和执行，Paging 用于处理大量数据的分页加载，Lifecycle 用于管理组件的生命周期等。这些组件相互协作，为 Android 应用的开发提供了全方位的支持，帮助开发者更好地应对各种复杂的开发场景和需求。

总之，Jetpack 为 Android 开发带来了诸多便利和优势，它提供了一套标准化、现代化的开发工具和架构模式，能够提高开发效率、增强应用的稳定性和可维护性，是 Android 开发者值得深入学习和应用的重要技术之一。

对 Android 的新技术了解吗？

以下是一些当前比较受关注的 Android 新技术：

Kotlin

语言特性：Kotlin 是一种基于 Java 虚拟机的编程语言，与 Java 兼容。它具有简洁的语法、强大的类型推断、空安全等特性，能够大大减少代码量，提高开发效率。例如，使用 Kotlin 可以更简洁地定义变量、函数和类，避免了 Java 中一些繁琐的语法结构。
函数式编程支持：支持函数式编程风格，如 lambda 表达式、高阶函数等，使得代码更加简洁、易读和易于维护。可以方便地使用函数式编程来处理集合数据、异步操作等，提高代码的表达力和灵活性。
Android 开发中的应用：在 Android 开发中，Kotlin 逐渐成为主流的开发语言之一。Google 也在大力推广 Kotlin，许多新的 Android 开发工具和框架都对 Kotlin 提供了良好的支持。例如，Android Studio 对 Kotlin 有很好的集成，并且 Jetpack 中的许多组件也都提供了 Kotlin 的扩展函数和相关支持，方便开发者使用 Kotlin 进行 Android 应用的开发。

Compose

声明式 UI 构建：Compose 是 Android 用于构建用户界面的新工具包，它采用声明式的方式来创建 UI，与传统的命令式 UI 构建方式不同。开发者只需要描述界面的样子和数据的绑定关系，Compose 会自动根据数据的变化来更新界面，无需手动操作视图的创建、更新和销毁等过程，大大简化了 UI 开发的复杂度。
响应式编程：基于响应式编程的理念，Compose 中的 UI 组件能够自动响应数据的变化，实现界面的实时更新。通过使用 @Composable 注解来定义可组合的函数，这些函数可以根据输入的数据动态地生成 UI 界面，并且在数据发生变化时自动重新绘制界面，提供了更加流畅和高效的用户体验。
跨平台支持：除了 Android 平台，Compose 还具有一定的跨平台能力，可以在其他平台上使用，如桌面应用、Web 应用等，为开发者提供了一种统一的 UI 开发方式，能够更好地共享代码和提高开发效率。

Android 11 及以上的新特性

隐私增强：在隐私保护方面有了更多的加强，如一次性权限授予、权限自动重置等功能，让用户能够更好地控制应用对个人数据的访问权限。应用在请求敏感权限时，用户可以选择只授予一次权限，下次使用时需要再次请求，增加了用户数据的安全性。
动态资源加载：支持动态加载资源，应用可以根据不同的设备配置和用户需求动态地加载相应的资源文件，提高了应用的灵活性和兼容性。例如，可以根据设备的屏幕分辨率、语言设置等条件来加载不同的图片、布局等资源，以提供更好的用户体验。
系统界面优化：对系统界面进行了一些优化和改进，如通知栏的重新设计、快捷设置面板的增强等，为用户提供了更加便捷和美观的操作界面。同时，也为开发者提供了更多的系统界面定制和交互的可能性，例如可以创建自定义的通知样式和快捷操作等。

5G 技术在 Android 中的应用

高速网络连接：5G 的高速网络连接为 Android 应用带来了更快的数据传输速度和更低的延迟，使得应用能够更快速地获取和传输大量的数据，如高清视频、大型文件等。这为视频直播、在线游戏、虚拟现实等对网络要求较高的应用提供了更好的支持，能够提供更加流畅和高质量的用户体验。
边缘计算支持：5G 网络的边缘计算能力可以将部分计算任务从云端或设备端转移到网络边缘的服务器上进行处理，从而减轻设备的负担，提高应用的性能和响应速度。例如，在一些人工智能应用中，可以将模型的部分计算任务放在边缘服务器上执行，然后将结果快速返回给设备，实现更快速的智能识别和决策。
物联网集成：5G 的低延迟和高可靠性使得 Android 设备能够更好地与物联网设备进行集成和通信。开发者可以开发各种物联网应用，通过 Android 设备来控制和管理智能家居设备、智能穿戴设备、工业物联网设备等，实现设备之间的互联互通和智能化协同工作。

这些 Android 新技术为开发者提供了更多的开发可能性和创新空间，同时也为用户带来了更好的应用体验和功能特性，推动了 Android 生态系统的不断发展和进步。

Android 签名机制

Android 签名机制是 Android 应用开发和发布过程中非常重要的一部分。它主要用于保证应用的完整性、真实性和安全性。

从原理上来说，Android 签名是通过使用数字证书来实现的。开发者使用私钥对应用进行签名，而对应的公钥会包含在签名文件中。当应用安装到设备上时，系统会使用公钥来验证应用是否被篡改。如果应用的内容被修改，签名验证就会失败，系统将不会安装这个应用。

签名过程通常涉及到一个密钥库（keystore）文件。开发者可以使用 Java 的 keytool 工具来生成密钥库和密钥对。在构建应用时，通过配置构建脚本（如 Gradle 脚本）来指定密钥库文件和密钥别名等信息，使得在打包 APK（Android 应用安装包）时进行签名。

从应用的更新角度看，签名机制也很关键。如果要更新一个已经发布的应用，新的 APK 必须使用与原来相同的签名。否则，系统会将其视为一个全新的应用，而不是更新。这是因为系统通过签名来识别应用的开发者身份，确保只有合法的更新才能安装到用户设备上。

在企业级应用分发和一些特殊的开发场景中，签名机制也发挥着作用。例如，企业内部开发的应用，可以通过自签名的方式来发布，只要企业内部设备信任这个签名，就可以安装和使用这些应用。同时，在开发和测试阶段，调试签名和正式发布签名也有不同的用途。调试签名主要用于开发过程中的测试，方便开发者在模拟器和测试设备上快速部署和测试应用，而正式发布签名则用于将应用发布到应用商店等渠道，保证应用的安全性和合法性。

常用的设计模式

在软件开发包括 Android 开发中，有许多常用的设计模式。

单例模式（Singleton Pattern）：这种模式确保一个类只有一个实例，并提供一个全局访问点来获取这个实例。在 Android 开发中，单例模式常用于管理全局资源，如数据库连接池、网络请求管理器等。例如，一个应用中的网络请求工具类可以设计为单例模式。这样，在整个应用中，无论从哪个组件（如 Activity、Service 等）访问这个网络请求工具，都可以使用同一个实例，避免了创建多个实例导致的资源浪费和可能出现的不一致性。

观察者模式（Observer Pattern）：它定义了一种一对多的依赖关系，当一个对象的状态发生变化时，所有依赖它的对象都会收到通知并自动更新。在 Android 开发中，LiveData（Android Jetpack 组件）就是基于观察者模式实现的。例如，在一个包含用户信息显示的应用中，当用户信息（如用户名、头像等）在后台更新后，通过 LiveData 通知所有与之绑定的 UI 组件（如 Activity 或 Fragment 中的视图），这些视图会自动更新显示的内容，保证了数据和视图的一致性。

工厂模式（Factory Pattern）：工厂模式是一种创建对象的设计模式，它将对象的创建和使用分离。在 Android 中，比如在创建不同类型的数据库访问对象（DAO）时可以使用工厂模式。假设有一个应用需要访问本地数据库和云端数据库，通过一个工厂类来根据不同的配置或需求创建对应的数据库访问对象，这样可以隐藏对象创建的复杂过程，并且方便在不同的场景下切换对象的创建方式。

适配器模式（Adapter Pattern）：用于将一个类的接口转换成客户期望的另一个接口。在 Android 开发的视图（View）系统中经常会用到。例如，当要将一个自定义的数据集合显示在 ListView 或 RecyclerView 中时，需要使用适配器（Adapter）。适配器作为数据和视图之间的桥梁，将数据适配成视图能够理解和展示的形式，使得不同类型的数据可以方便地在各种列表视图中展示。

策略模式（Strategy Pattern）：它定义了一系列的算法，将每个算法封装起来，并使它们可以相互替换。在 Android 开发中，比如在实现图像加载策略时可以使用。有的场景可能需要从本地加载图像，有的场景可能需要从网络加载，通过策略模式可以将不同的加载策略封装成不同的类，然后根据具体的情况（如网络状态、缓存情况等）选择合适的加载策略。

跨平台开发工具

跨平台开发工具在移动应用开发领域越来越受到关注，它可以帮助开发者用一套代码在多个平台（如 Android 和 iOS）上构建应用。

Flutter：这是谷歌开发的一个开源跨平台开发框架。它使用 Dart 语言进行开发。Flutter 的优势在于能够提供高度定制化的、具有原生体验的用户界面。它通过自己的渲染引擎来绘制 UI，不依赖于平台自带的原生控件，因此可以在不同平台上实现高度一致的外观和性能。例如，在 Flutter 中开发的一个复杂的动画效果的应用，在 Android 和 iOS 设备上都能以相似的流畅度和视觉效果展示。

React Native：是 Facebook 开发的跨平台框架，基于 JavaScript 和 React。它允许开发者使用熟悉的 React 开发模式来构建移动应用。React Native 采用了桥接的方式，一部分代码通过 JavaScript 引擎运行，另一部分通过原生平台的组件来展示。这种方式使得它能够在一定程度上复用代码，并且能够利用原生平台的一些性能优势。例如，在需要调用设备的摄像头或者传感器等原生功能时，React Native 可以通过桥接机制来调用原生代码实现。

Xamarin：这是微软推出的跨平台开发工具，它使用 C# 语言。Xamarin 通过将 C# 代码编译成原生平台的代码来实现跨平台。它可以很好地与.NET 生态系统集成，对于熟悉 C# 和.NET 的开发者来说是一个不错的选择。在开发企业级应用时，Xamarin 可以利用已有的.NET 库和服务，并且能够方便地访问原生平台的 API。例如，在开发一个需要与企业内部的.NET 后端服务紧密集成的移动应用时，Xamarin 可以提供高效的开发方式。

Ionic：基于 Web 技术（HTML、CSS、JavaScript）的跨平台开发框架。它主要通过将 Web 应用包装成原生应用的形式来实现跨平台。Ionic 的优点是开发速度快，对于有 Web 开发经验的团队来说，学习成本较低。例如，在开发一个简单的信息展示类应用，如新闻应用或者活动日程应用时，Ionic 可以快速地构建出具有基本功能的应用，并且可以通过一些插件来扩展应用的原生功能。

这些跨平台开发工具各有优缺点，开发者需要根据项目的具体需求、团队的技术背景和对应用性能、外观等方面的要求来选择合适的工具。

在 Flutter 中有两种主要类型的 Widget：StatelessWidget 和 StatefulWidget。

StatelessWidget 是无状态的 Widget，它的属性在创建后就不能再改变。这种 Widget 通常用于展示一些静态的内容，如简单的文本标签、图标等。例如，一个只显示固定文本 “欢迎使用” 的 Text Widget 就可以是一个 StatelessWidget。它根据传入的初始参数来构建 UI，并且在整个生命周期内不会因为内部状态的改变而重新构建。

StatefulWidget 是有状态的 Widget，它可以在其生命周期内根据内部状态的变化而重新构建 UI。这种 Widget 适用于需要动态更新的场景，如用户交互导致的界面变化、数据加载后的更新等。例如，一个计数器 Widget，用户每点击一次按钮，计数器的值就会增加，并且 UI 会更新显示新的值，这个计数器 Widget 就需要是一个 StatefulWidget。

除了这两种基本类型外，还有一些特殊的 Widget，如 InheritedWidget，它主要用于在 Widget 树中共享数据。当一个 InheritedWidget 的数据发生变化时，它的子孙 Widget 可以通过依赖注入的方式获取到最新的数据，从而实现数据的高效传递和共享。

StatefulWidget 生命周期

StatefulWidget 的生命周期包括多个阶段。

首先是 createState 阶段，当 StatefulWidget 被插入到 Widget 树中时，会调用 createState 方法来创建一个对应的 State 对象。这个 State 对象会与 Widget 关联，并在后续的生命周期中管理 Widget 的状态。

接着是 initState 阶段，在 State 对象被创建后，会立即调用 initState 方法。这个方法是进行初始化操作的好时机，如订阅事件、初始化数据等。例如，在一个需要加载网络数据的 StatefulWidget 中，可以在 initState 方法中启动网络请求。需要注意的是，initState 方法只会被调用一次，在 Widget 的整个生命周期中，这是最早的初始化阶段。

然后是 didChangeDependencies 阶段，这个阶段在 initState 之后，并且在 Widget 的依赖关系发生变化时也会被调用。例如，当 Widget 依赖的 InheritedWidget 的数据发生变化时，就会触发 didChangeDependencies 方法。在这个阶段，可以根据新的依赖关系来更新状态或者执行其他相关操作。

build 阶段是构建 UI 的阶段，这个阶段会频繁被调用。当 Widget 的状态发生变化或者其依赖的其他因素（如父 Widget 的尺寸变化）发生变化时，就会调用 build 方法来重新构建 UI。在 build 方法中，通过返回一个 Widget 树来描述 UI 的样子。

当 Widget 从 Widget 树中被移除时，会调用 deactivate 方法，这个方法表示 Widget 暂时失去活性，但不一定会被销毁。在某些情况下，如在动画过渡过程中，Widget 可能会被暂时移除然后又重新添加，此时 deactivate 方法就会被调用。

最后是 dispose 阶段，当 Widget 被永久移除时，会调用 dispose 方法。在这个阶段，应该释放所有占用的资源，如取消订阅事件、关闭数据库连接等，以避免资源浪费和可能出现的内存泄漏。

Android 虚拟机有哪些？怎么选择？

Android 虚拟机类型

Dalvik 虚拟机：这是早期 Android 系统使用的虚拟机。它采用了一种基于寄存器的架构，能够有效地利用内存和提高执行效率。Dalvik 虚拟机执行的是.dex 文件格式，它会将 Java 字节码转换为.dex 格式后再执行。在早期的 Android 设备中，Dalvik 虚拟机在处理资源有限的情况下发挥了较好的性能，但随着应用的复杂性增加和对性能要求的提高，它的一些局限性也逐渐显现出来。例如，在处理大量的内存密集型应用或者复杂的多线程应用时，Dalvik 虚拟机的性能可能会受到影响。
ART 虚拟机（Android Runtime）：ART 是 Android 系统目前主要使用的虚拟机。它在安装应用时就会将字节码编译为机器码，这种预编译的方式相比 Dalvik 虚拟机的即时编译（JIT）方式，可以提高应用的启动速度和执行效率。ART 虚拟机还支持更好的垃圾回收（GC）机制，能够更有效地管理内存，减少内存泄漏和应用卡顿的情况。例如，在运行大型游戏或者复杂的图形应用时，ART 虚拟机能够提供更流畅的体验。

如何选择

在实际开发和应用场景中，开发者一般不需要直接选择虚拟机，因为这主要是由 Android 系统来决定的。不过，在一些特殊情况下，如对性能有深入研究或者进行模拟器开发等场景下，需要考虑虚拟机的特点。

如果是开发一些对内存和性能要求不是特别高的简单应用，并且需要考虑兼容性（如一些旧设备仍然使用 Dalvik 虚拟机），那么可以在一定程度上关注应用在 Dalvik 虚拟机下的性能表现。但如果是开发大型应用、游戏或者对性能敏感的应用，应该更多地考虑 ART 虚拟机的优势。在测试过程中，要确保应用在 ART 虚拟机下能够充分利用其预编译和优化的 GC 机制，以提供更好的用户体验。同时，对于应用的兼容性测试，也需要在不同版本的 Android 系统（包括使用 Dalvik 和 ART 虚拟机的系统）上进行，以保证应用在各种设备上都能正常运行。

ANR 的原理

ANR（Application Not Responding）是指应用程序无响应。在 Android 系统中，当应用的主线程长时间阻塞，无法及时响应系统或用户的输入事件时，就会触发 ANR。

从系统角度看，Android 系统会监测应用主线程的消息处理情况。系统会通过一些机制来判断主线程是否卡顿。例如，当用户进行操作（如点击按钮、滑动屏幕等），这些操作会产生对应的消息放入主线程的消息队列中。如果主线程长时间被其他耗时操作（如复杂的网络请求、大量的数据计算、同步 I/O 操作等）占用，不能及时处理这些用户操作消息，就可能导致 ANR。

具体来说，系统有一个超时时间限制。对于不同类型的操作，超时时间有所不同。比如，当用户进行按键操作或者触摸屏幕操作时，系统默认的超时时间一般是 5 秒左右。如果在这个时间内主线程没有处理完操作对应的消息，系统就会认为应用无响应，进而弹出 ANR 对话框。对于广播接收器，也有类似的时间限制，当广播接收器在规定时间（如 10 秒）内没有完成处理广播消息的操作，也会触发 ANR。

从应用开发角度，ANR 通常是由于不合理的代码逻辑导致的。例如，在主线程中直接进行网络请求或者大量的数据读取操作。为了避免 ANR，开发者应该将耗时操作放在子线程中进行，如使用异步任务（AsyncTask）、线程池或者 IntentService 等来处理耗时任务，确保主线程能够及时处理用户交互相关的消息。

TCP 的优缺点

优点

可靠性高：TCP 协议是一种面向连接的、可靠的传输协议。在数据传输过程中，通过一系列的机制来确保数据的准确性和完整性。它使用序列号和确认应答机制。发送方在发送数据时，会给每个数据包加上序列号，接收方收到数据包后，会返回一个确认应答消息。如果发送方没有收到确认应答，就会重新发送数据包。例如，在文件传输应用中，通过 TCP 协议可以保证文件的每个部分都能准确无误地从发送端传输到接收端，避免数据丢失或损坏。
顺序传输：TCP 能够保证数据按照发送的顺序进行接收。这是因为接收方会根据数据包的序列号来重新排列数据。例如，在一个视频流传输的场景中，画面帧数据通过 TCP 协议传输，接收方可以按照正确的顺序来播放这些帧，确保视频的流畅性和连贯性。
流量控制和拥塞控制：TCP 协议具有流量控制和拥塞控制机制。流量控制主要是为了避免发送方发送数据的速度过快，导致接收方无法及时处理。它通过接收方返回的窗口大小来告知发送方可以发送多少数据。拥塞控制则是为了避免网络出现拥塞。当网络出现拥塞时，TCP 会自动调整发送方的发送速度，减少数据的发送量，以缓解网络压力。例如，在互联网访问高峰期，TCP 协议可以根据网络状况自动降低数据传输速度，防止网络瘫痪。

缺点

开销较大：由于 TCP 的可靠性机制，如序列号、确认应答、流量控制和拥塞控制等，使得它在传输数据时需要增加额外的头部信息，并且在传输过程中需要进行更多的交互。这些额外的操作导致了 TCP 协议的开销相对较大。与 UDP（用户数据报协议）相比，TCP 的传输效率较低。例如，在一些对实时性要求很高，但对数据准确性要求不是特别严格的场景（如实时音频会议），TCP 协议可能因为开销较大而无法满足需求。
建立连接和断开连接的过程复杂：TCP 协议在传输数据之前需要进行三次握手来建立连接，在数据传输结束后需要进行四次挥手来断开连接。这个过程相对复杂，会消耗一定的时间和资源。在一些对连接速度要求很高的场景（如频繁的短连接场景），TCP 协议的连接和断开过程可能会成为性能瓶颈。

DNS 协议

DNS（Domain Name System）协议主要用于将域名转换为对应的 IP 地址。在互联网中，域名是人们便于记忆的网络资源标识，而 IP 地址是网络设备实际通信所使用的地址。

从功能上看，当用户在浏览器中输入一个域名（如www.example.com）时，浏览器会向本地 DNS 服务器发送一个 DNS 查询请求。本地 DNS 服务器首先会检查自己的缓存中是否已经有这个域名对应的 IP 地址。如果有，就直接返回给浏览器；如果没有，它会向其他 DNS 服务器（如根 DNS 服务器、顶级域名服务器等）进行递归查询，直到找到对应的 IP 地址并返回给浏览器。

DNS 协议的工作原理涉及到分布式的域名服务器系统。整个 DNS 系统是一个分层的结构，最顶层是根域名服务器，它知道所有顶级域名（如.com、.org 等）服务器的地址。顶级域名服务器则负责管理该顶级域名下的二级域名信息。例如，.com 域名服务器知道example.com域名服务器的地址，然后example.com域名服务器知道www.example.com这个主机名对应的 IP 地址。

在 DNS 查询方式上，有递归查询和迭代查询。递归查询是指本地 DNS 服务器代替客户端进行完整的查询过程，直到找到最终答案或者确定无法查询到为止。迭代查询则是本地 DNS 服务器向其他 DNS 服务器询问后，如果没有得到最终答案，就把得到的参考信息返回给客户端，让客户端自己继续查询。

DNS 协议对于互联网的正常运行至关重要。它使得人们可以使用方便记忆的域名来访问网络资源，而不是直接使用复杂的 IP 地址。同时，DNS 系统也在不断地进行安全和性能方面的优化，如采用 DNSSEC（DNS 安全扩展）来防止 DNS 欺骗等安全问题。

三次握手，为什么是三次

在 TCP 协议中，三次握手是建立连接的过程。

第一次握手是客户端向服务器发送一个带有 SYN（同步序列号）标志的 TCP 数据包，这个数据包中包含客户端的初始序列号（ISN）。这一步的目的是告诉服务器，客户端想要建立连接，并且让服务器知道客户端的初始序列号，以便后续的通信。

第二次握手是服务器收到客户端的 SYN 数据包后，向客户端发送一个 SYN/ACK 数据包。这个数据包中包含服务器自己的初始序列号，同时对客户端的 SYN 进行确认。这一步表明服务器收到了客户端的连接请求，并且同意建立连接，同时也让客户端知道服务器的初始序列号。

第三次握手是客户端收到服务器的 SYN/ACK 数据包后，向服务器发送一个 ACK 数据包，对服务器的 SYN 进行确认。这一步完成后，连接就正式建立。

之所以需要三次握手，主要是为了保证连接的可靠性和双方的初始序列号能够被正确同步。

从可靠性角度看，如果只有两次握手，当客户端发送了 SYN 请求后，假设服务器收到并直接认为连接建立，开始发送数据。但如果这个 SYN 请求因为网络延迟等原因在网络中滞留，客户端实际上已经放弃了这个连接请求，那么服务器发送的数据就会丢失，并且服务器还一直认为连接是建立的。而通过三次握手，客户端会对服务器的回应进行确认，只有在收到客户端的确认后，服务器才会认为连接真正建立，这样就避免了上述情况的发生。

从序列号同步角度看，三次握手使得双方都能明确对方的初始序列号。这对于后续的数据传输非常重要，因为双方需要根据序列号来确认数据的顺序和完整性。只有通过三次握手，双方才能确保在同一个起始点上开始数据传输，保证通信的准确性。

http 的协议，post 和 get 的区别，参数如何传递

HTTP 协议

HTTP（HyperText Transfer Protocol）是一种用于传输超文本的协议，它是互联网应用广泛使用的通信协议。它基于请求 - 响应模型，客户端（如浏览器）发送请求，服务器收到请求后返回响应。

HTTP 请求由请求行、请求头部、空行和请求正文组成。请求行包含请求方法（如 GET、POST 等）、请求的 URL 和 HTTP 协议版本。请求头部包含了一些关于请求的附加信息，如用户代理（User - Agent）、内容类型（Content - Type）等。请求正文则是在某些请求方法（如 POST）下包含的数据。

HTTP 响应由响应行、响应头部、空行和响应正文组成。响应行包含 HTTP 协议版本、响应状态码（如 200 表示成功、404 表示未找到等）和状态消息。响应头部包含了关于响应的信息，如服务器类型、内容长度等。响应正文是服务器返回的实际内容，如网页的 HTML 文档、图片数据等。

GET 和 POST 的区别

请求语义：GET 请求主要用于获取资源，它是幂等的，即多次执行相同的 GET 请求应该返回相同的结果。例如，在浏览器中输入一个网址访问网页，这就是一个 GET 请求，它只是获取服务器上的网页内容。POST 请求主要用于向服务器提交数据，它通常会改变服务器的状态。例如，在一个用户注册的场景中，用户填写的注册信息通过 POST 请求发送到服务器，服务器会将这些信息保存到数据库中，改变了服务器的数据状态。
参数传递位置：GET 请求的参数是通过 URL 传递的，这些参数会附加在 URL 后面，以 “?” 开头，参数之间用 “&” 分隔。例如，在一个搜索页面中，搜索关键词作为 GET 请求的参数，像 “https://www.example.com/search?q=keyword”，其中 “q=keyword” 就是传递的参数。POST 请求的参数是放在请求正文中传递的，不会显示在 URL 中。这使得 POST 请求更适合传递敏感信息，如用户密码等，因为参数不会暴露在 URL 中，相对更安全。
数据量限制：由于 GET 请求的参数是通过 URL 传递的，受到 URL 长度的限制，不同的浏览器和服务器对 URL 长度有不同的限制，但一般来说数据量不能太大。POST 请求因为参数在请求正文中，没有严格的长度限制，理论上可以传递大量的数据。不过，在实际应用中，服务器也可能会对 POST 请求的数据量进行限制，以防止恶意攻击或者资源浪费。

参数传递方式

对于 GET 请求，如前面所述，参数直接附加在 URL 后面。在服务器端，可以通过解析 URL 来获取这些参数。对于 POST 请求，参数在请求正文中，服务器端需要根据请求头部的 Content - Type 来确定如何解析参数。如果 Content - Type 是 application/x - www - form - urlencoded，那么参数的格式和 GET 请求的参数格式类似，是键值对的形式，通过解析请求正文来获取参数。如果 Content - Type 是 multipart/form - data，通常用于上传文件等场景，服务器端需要使用不同的方式来解析正文，将文件数据和其他参数分离开来进行处理。

HTTP 与 HTTPS 的区别

HTTP 是超文本传输协议，它是一种用于在网络上传输数据的应用层协议。其通信过程相对简单，以明文的方式传输数据。这意味着在数据传输过程中，信息是没有加密的，任何在传输路径上的设备都可以截获并查看这些数据。例如，当用户通过 HTTP 访问一个网页时，网页的内容、用户提交的表单信息等都可以被轻易获取。

HTTPS 则是在 HTTP 的基础上加入了 SSL/TLS 加密协议。SSL（Secure Sockets Layer）和 TLS（Transport Layer Security）是用于在网络通信中提供安全及数据完整性的协议。在 HTTPS 通信中，首先会进行握手过程，客户端和服务器会协商加密算法和密钥，之后的数据传输都会使用这个密钥进行加密。这就好比把传输的数据放在一个加密的盒子里，只有拥有正确密钥的接收方才能打开并读取内容。

从端口使用来看，HTTP 通常使用 80 端口，而 HTTPS 使用 443 端口。这是为了在网络通信中区分两种不同的协议。

在安全性能方面，HTTPS 能够有效防止中间人攻击。中间人攻击是指攻击者在通信双方之间拦截并篡改数据。由于 HTTPS 的加密机制，即使数据被拦截，攻击者没有密钥也无法解密和篡改数据。而且，在身份验证方面，HTTPS 可以通过数字证书来验证服务器的身份，确保用户访问的是真实的服务器，而不是被伪装的服务器。

在搜索引擎优化方面，现在的搜索引擎更倾向于将使用 HTTPS 的网站排在前面，因为这表示网站对用户数据安全更加重视。对于用户来说，浏览器在访问 HTTPS 网站时会显示安全锁的图标，让用户直观地感受到网站的安全性。

网络如何保证信息传输的安全性？

网络保证信息传输安全性主要通过多种技术手段实现。

首先是加密技术。加密技术分为对称加密和非对称加密。对称加密是指加密和解密使用相同的密钥。例如，在一个企业内部的文件传输系统中，发送方和接收方事先约定好一个密钥，发送方使用这个密钥对文件进行加密，接收方使用相同的密钥进行解密。这种方式加密速度快，但密钥管理复杂，因为密钥需要安全地分发给通信双方。

非对称加密则使用一对密钥，即公钥和私钥。公钥可以公开，用于加密；私钥由接收方持有，用于解密。例如，在网上银行系统中，银行会将公钥提供给用户，用户使用公钥对转账等敏感信息进行加密，银行收到后使用私钥进行解密。这样，即使公钥被其他人获取，没有私钥也无法解密信息。

其次是数字签名技术。数字签名用于验证消息的来源和完整性。发送方使用自己的私钥对消息进行签名，接收方可以使用发送方的公钥来验证签名。如果签名验证成功，说明消息确实是由发送方发送的，并且没有被篡改。例如，在电子合同签署过程中，通过数字签名可以确保合同的真实性和不可篡改性。

另外，还有防火墙技术。防火墙可以是硬件设备，也可以是软件程序，它能够对进出网络的流量进行检查和过滤。例如，企业网络的防火墙可以阻止外部未经授权的访问，同时允许内部授权用户访问外部网络。防火墙可以根据设定的规则，如 IP 地址、端口号、协议类型等，来决定是否允许数据包通过。

还有安全协议的使用，如 SSL/TLS 协议，用于在网络传输层提供安全保障，确保数据的保密性、完整性和认证性，就像前面提到的 HTTPS 协议中的应用一样。

IP 和掩码的关系

IP 地址是用于在网络中标识设备的地址，它由 32 位二进制数组成，通常以点分十进制的形式表示，如 192.168.1.1。子网掩码则用于划分网络地址和主机地址。

子网掩码也是 32 位二进制数，它和 IP 地址配合使用。子网掩码中连续的 1 代表网络位，连续的 0 代表主机位。例如，常见的子网掩码 255.255.255.0，对应的二进制是 11111111.11111111.11111111.00000000。

通过 IP 地址和子网掩码的逻辑与运算，可以得到网络地址。假设一个设备的 IP 地址是 192.168.1.10，子网掩码是 255.255.255.0，将它们转换为二进制后进行与运算，得到的网络地址是 192.168.1.0。这个网络地址用于标识设备所在的网络。

子网掩码的作用还体现在子网划分上。通过改变子网掩码，可以将一个大的网络划分为多个小的子网。例如，将一个原本的 B 类网络（子网掩码为 255.255.0.0）通过修改子网掩码为 255.255.240.0，就可以划分出多个子网，每个子网可以有不同的主机数量，这样可以更有效地利用 IP 地址资源，并且便于网络的管理和安全控制。

不同的子网掩码可以划分出不同规模的子网。子网掩码中 1 的数量越多，网络地址部分就越长，子网数量就越多，但每个子网中的主机数量就越少。反之，子网掩码中 1 的数量越少，每个子网中的主机数量就越多，但子网数量就越少。

网络窗口滑动概念

在网络通信的传输控制协议（TCP）中，窗口滑动是一种流量控制机制。

TCP 通过滑动窗口来协调发送方和接收方的数据传输速度。发送方有一个发送窗口，接收方有一个接收窗口。接收窗口的大小表示接收方当前能够接收的数据量。例如，接收方的接收窗口大小为 100 字节，这意味着发送方最多可以发送 100 字节的数据给接收方，而不会导致接收方缓冲区溢出。

窗口滑动是基于确认应答机制的。发送方发送数据后，会等待接收方的确认应答。当接收方收到数据并将其放入缓冲区后，会向发送方发送确认应答，同时根据自己缓冲区的剩余空间调整接收窗口的大小。发送方根据收到的确认应答和接收窗口的大小来滑动自己的发送窗口。

假设发送方的发送窗口大小最初为 100 字节，发送了 50 字节的数据后，还可以发送 50 字节的数据。当收到接收方对于这 50 字节数据的确认应答，并且接收方通知发送方接收窗口大小变为 150 字节时，发送方就可以将发送窗口向右滑动，使得发送窗口的可用空间变为 150 字节，从而可以继续发送更多的数据。

这种窗口滑动机制可以有效地利用网络带宽和接收方的缓冲区资源。它可以根据网络的实际情况和接收方的处理能力动态地调整数据传输速度，避免发送方发送过多的数据导致网络拥塞或者接收方无法处理。同时，通过不断地滑动窗口，保证了数据的持续、有序传输，提高了网络通信的效率。

三次握手过程中的安全问题

在 TCP 的三次握手过程中，虽然它主要是用于建立可靠的连接，但也可能存在一些安全问题。

首先是 SYN 洪泛攻击。在第一次握手时，客户端向服务器发送带有 SYN 标志的数据包请求建立连接。攻击者可以大量发送这种 SYN 数据包，但不回应服务器的 SYN/ACK 数据包，这就导致服务器会为这些半连接状态的请求分配资源，如内存来存储连接信息。随着大量虚假请求的积累，服务器的资源会被耗尽，从而无法正常处理其他合法的连接请求。

例如，在一个面向互联网的服务器上，如果没有对这种攻击进行防范，攻击者可以利用工具发送海量的 SYN 数据包，使得服务器的连接队列被填满，正常用户想要访问服务器就会受到影响，出现连接超时等情况。

其次是 IP 欺骗。攻击者可以伪造 IP 地址来进行三次握手。在第一次握手时，使用伪造的 IP 地址发送 SYN 数据包。如果服务器没有对 IP 地址进行有效的验证，就可能会与这个伪造的 IP 地址进行后续的握手过程。这可能会导致服务器向一个不存在或者不相关的地址发送数据，造成网络资源的浪费，并且可能会被用于恶意的流量转发等目的。

为了防范这些安全问题，可以采用一些措施。对于 SYN 洪泛攻击，可以使用 SYN Cookie 技术。服务器在收到 SYN 数据包时，不是立即分配资源建立半连接，而是通过一种特殊的算法计算出一个 Cookie 值，将这个值放在 SYN/ACK 数据包中发送给客户端。只有当客户端返回的 ACK 数据包中包含正确的 Cookie 值时，服务器才会真正建立连接并分配资源。

对于 IP 欺骗，可以采用 IP 地址验证技术，如使用防火墙或者入侵检测系统来检查 IP 地址的合法性，同时结合一些基于网络拓扑和路由信息的验证方法，确保进行三次握手的 IP 地址是真实可靠的。

Okhttp 的原理，是如何对它封装的？

Okhttp 是一个高效的 HTTP 客户端，用于在 Android 和 Java 应用中进行网络请求。

从原理上讲，Okhttp 基于 HTTP 协议构建请求和响应流程。它内部有一个连接池来管理网络连接。当发起一个 HTTP 请求时，Okhttp 首先会查看连接池中是否有可用的连接。如果有，就直接使用这个连接来发送请求，避免了频繁地建立和断开连接的开销。例如，在短时间内多次请求同一服务器的不同资源时，连接池的存在可以显著提高效率。

在请求构建方面，Okhttp 通过 Request 对象来设置请求的各种参数，如请求方法（GET、POST 等）、URL、请求头和请求体等。它会将这些请求参数按照 HTTP 协议的格式进行组装，然后通过底层的网络通信机制发送出去。

对于响应处理，当服务器返回响应时，Okhttp 会解析响应的头部信息和正文内容。它可以根据响应的状态码判断请求是否成功，并且通过 Response 对象来提供对响应数据的访问方式，如获取响应头、读取响应体中的数据等。

在封装方面，许多开发者会将 Okhttp 的基本功能进行封装，以更好地适应项目的需求。可以创建一个网络请求工具类，在这个类中封装 Okhttp 的初始化、请求发送和响应处理的方法。例如，在封装 POST 请求方法时，可以将设置请求体、添加公共请求头、处理异步请求和同步请求等操作都封装在一个方法中。这样，在应用的其他部分，只需要调用这个封装后的方法，传入必要的参数（如 URL、请求体数据等），就可以方便地进行网络请求，而不需要每次都重复编写 Okhttp 的复杂配置和处理流程。

同时，还可以在封装过程中添加拦截器。Okhttp 的拦截器机制允许在请求发送和响应接收的过程中进行拦截和处理。可以添加网络请求日志拦截器，用于记录请求和响应的详细信息，方便调试；也可以添加缓存拦截器，用于实现数据的缓存策略，提高应用的性能和减少网络流量。

Binder 相对于其他 IPC 方式的优势。

Binder 是 Android 系统中一种重要的进程间通信（IPC）机制。

首先，Binder 基于 C/S 架构，它在 Android 系统中提供了一个稳定的通信模型。在这个模型中，客户端和服务器通过 Binder 驱动进行通信。与传统的 IPC 方式相比，这种架构使得通信更加有序和易于管理。例如，在一个应用中，一个服务（Service）作为服务器提供数据或功能，其他组件（如 Activity）作为客户端来请求这些服务，Binder 可以很好地处理这种请求 - 响应的通信场景。

Binder 的安全性是一个显著的优势。它在 Android 系统内部通过 UID（用户 ID）和 PID（进程 ID）来进行身份验证。这意味着只有经过系统授权的进程才能进行通信。例如，不同应用之间的通信是受到严格限制的，只有具有相同签名或者满足系统安全策略的应用才能通过 Binder 进行通信，有效地防止了恶意应用的非法访问。

在性能方面，Binder 也有出色的表现。它的数据传输效率较高，因为 Binder 驱动在内核空间中进行数据的拷贝操作，并且采用了共享内存的方式来传递数据。与其他 IPC 方式（如 Socket）相比，Binder 减少了数据拷贝的次数，从而降低了通信的开销。例如，在传递较大的数据块时，Binder 的性能优势更加明显，可以更快地将数据从一个进程传输到另一个进程。

另外，Binder 对开发人员比较友好。它提供了一套简单的接口，使得开发者可以方便地在 Android 应用中实现进程间通信。例如，在 Android 开发中，通过实现 AIDL（Android Interface Definition Language）接口，就可以很容易地在不同进程的组件之间进行通信，而不需要深入了解复杂的底层通信机制。

频繁的 GC 情况有遇到过吗？怎么处理。

在 Android 开发过程中，很可能会遇到频繁的 GC（垃圾回收）情况。

频繁 GC 通常会导致应用性能下降，如卡顿等现象。这主要是因为 GC 操作会暂停应用的主线程，当 GC 频繁发生时，这种暂停就会变得很明显。例如，在一个处理大量数据或者频繁创建和销毁对象的应用场景中，垃圾回收器需要不断地回收内存，从而导致频繁的主线程暂停。

当遇到频繁 GC 的情况时，首先要检查内存泄漏。内存泄漏是导致频繁 GC 的一个常见原因。可以使用 Android Studio 自带的 Memory Profiler 工具来检测内存泄漏。通过这个工具，可以查看对象的内存分配情况，找到那些不应该存在但一直占用内存的对象。例如，如果发现一个 Activity 已经被销毁，但仍然有对象持有它的引用，导致它无法被垃圾回收，这就是一个内存泄漏问题。

对于对象的创建和使用要更加谨慎。避免在循环或者频繁调用的方法中创建大量的短期对象。例如，在一个列表滚动的场景中，如果每次滚动都会创建新的视图对象而没有合理地复用，就会导致大量对象的创建和销毁，引发频繁 GC。可以使用对象池技术，对于一些频繁创建和销毁的同类型对象，提前创建好一定数量的对象放在池中，需要时从池中获取，使用完毕后放回池中，减少对象的创建次数。

另外，要注意优化数据结构。有些数据结构可能会导致内存碎片化，从而增加 GC 的频率。例如，频繁地在 ArrayList 中插入和删除中间元素，可能会导致数组的重新分配和复制，产生大量的临时对象。可以考虑使用更合适的数据结构，如 LinkedList 在频繁插入和删除操作时可能更合适，以减少内存碎片的产生。

还可以通过调整 GC 的参数来缓解频繁 GC 的情况，但这需要谨慎操作。不同的 GC 算法和参数设置对应用的性能有不同的影响，需要根据具体的应用场景和性能测试结果来选择合适的 GC 策略。

怎样检测内存泄漏，如何避免。

检测内存泄漏

可以使用多种工具来检测内存泄漏。Android Studio 自带的 Memory Profiler 是一个很强大的工具。通过 Memory Profiler，可以实时观察应用的内存使用情况。它能够展示内存的分配情况，包括不同类型的对象占用的内存大小和数量。

在使用 Memory Profiler 时，可以进行内存快照。在应用运行的不同阶段，如启动后、进行一些操作后、关闭某个界面后等，分别拍摄内存快照。然后对比这些快照，查看是否有对象在应该被回收的情况下仍然存在。例如，当一个 Activity 被销毁后，观察其相关对象是否还在内存中占用空间。

还有 LeakCanary 这个开源工具也非常有效。它可以自动检测内存泄漏，并且在检测到泄漏时提供详细的报告。LeakCanary 通过监控对象的生命周期来发现内存泄漏。当一个对象的生命周期结束但仍然被其他对象引用时，LeakCanary 会捕获到这个情况，并展示出导致泄漏的引用链。例如，它可以发现一个内部类持有外部类（如 Activity）的引用，导致外部类无法被正常回收的情况。

避免内存泄漏

在代码编写方面，要注意内部类对外部类的引用。当在一个外部类（如 Activity）中定义内部类时，如果内部类的生命周期可能超过外部类，应该避免内部类直接持有外部类的引用。可以将内部类改为静态内部类，并通过弱引用的方式来引用外部类。例如，在一个异步任务（AsyncTask）类中，如果它是 Activity 的内部类，并且在 Activity 销毁后可能还在执行，就应该采用这种方式来避免内存泄漏。

对于资源的管理要严格。在使用资源（如文件流、数据库连接、广播接收器等）后，要及时释放。例如，在打开一个文件读取数据后，要确保在读完数据后关闭文件流。如果忘记关闭这些资源，它们会一直占用内存，导致内存泄漏。

在使用单例模式时，要注意单例对象可能会导致的内存泄漏。如果单例对象持有其他对象的引用，并且这些引用的对象生命周期结束后不能被正常回收，就会产生内存泄漏。可以在单例对象中合理地管理引用，如采用弱引用或者在适当的时候清理引用，以避免内存泄漏。

view 的 touch 事件分发机制。

在 Android 中，View 的 Touch 事件分发机制是一个复杂但有序的过程，涉及到三个重要的方法：dispatchTouchEvent、onInterceptTouchEvent 和 onTouchEvent。

首先是 dispatchTouchEvent 方法，它是事件分发的入口。当一个 Touch 事件（如触摸屏幕）发生时，事件会从 Activity 开始，通过 ViewGroup 的 dispatchTouchEvent 方法向下传递。这个方法会根据一系列的条件来决定是自己处理事件还是将事件继续分发给子 View。例如，一个包含多个子 View 的 LinearLayout 在收到 Touch 事件时，会在 dispatchTouchEvent 方法中判断触摸点是否在某个子 View 的范围内，如果在，就可能将事件分发给这个子 View。

onInterceptTouchEvent 方法主要存在于 ViewGroup 中，它用于判断是否拦截事件。ViewGroup 可以根据自身的需求和状态来决定是否拦截事件，不让事件继续传递给子 View。例如，在一个可滑动的 ViewGroup 中，如果检测到用户的触摸动作是水平滑动，而它希望自己处理这个滑动事件而不是让子 View 处理，就可以在 onInterceptTouchEvent 方法中返回 true，拦截事件。

onTouchEvent 方法是 View 处理事件的最终环节。当事件传递到一个 View 时，这个 View 会通过 onTouchEvent 方法来决定是否处理这个事件。如果返回 true，表示这个 View 处理了事件；如果返回 false，事件会按照一定的规则向上传递，可能会被父 ViewGroup 重新处理。例如，一个 Button 的 onTouchEvent 方法会在用户点击按钮时返回 true，表示它处理了这个点击事件，而一个普通的 TextView 在默认情况下可能会返回 false，表示它不处理这个事件，除非开发者对它进行了特殊的设置。

在整个事件分发过程中，还有一些重要的规则。例如，一旦一个 ViewGroup 拦截了事件，那么后续的同一系列事件（如一次触摸动作产生的多个事件）都会直接传递给这个 ViewGroup，而不会再经过 onInterceptTouchEvent 方法的拦截判断。而且，当一个 View 处理了一个事件（如 onTouchEvent 返回 true），那么这个事件的后续动作（如触摸的移动、抬起等）也会优先由这个 View 来处理，除非它明确地返回 false 或者调用了父 ViewGroup 的相关方法来改变事件的处理路径。

Handler，loop 和 HandlerThread 的关系

Handler、Looper 和 HandlerThread 在 Android 开发中紧密相关，用于实现线程间的通信和任务调度。

Handler 是 Android 中用于发送和处理消息的工具。它允许在不同线程之间传递消息，并且可以指定消息被处理的方式。例如，在主线程中，可以使用 Handler 来更新 UI。当一个子线程完成了一个耗时任务并获取到一些数据后，通过 Handler 将包含数据的消息发送到主线程的消息队列，然后主线程中的 Handler 会处理这个消息，将数据更新到 UI 界面上。

Looper 是一个消息循环器。它的主要功能是不断地从消息队列（MessageQueue）中取出消息，并将消息分发给对应的 Handler 进行处理。每个线程最多只有一个 Looper，在主线程中，系统会自动创建一个 Looper。而在其他线程中，如果要使用 Handler，通常需要先创建一个 Looper。Looper 通过它的 loop 方法来实现消息循环，这个方法会一直运行，直到消息队列为空并且没有新的消息进来。

HandlerThread 是一个继承自 Thread 的类，它是一种方便的工具，用于创建一个带有 Looper 的线程。当创建一个 HandlerThread 时，它会在内部创建一个 Looper，并且启动线程。这样，就可以在这个线程中通过 Handler 来发送和处理消息。例如，在一个后台任务处理的场景中，可以创建一个 HandlerThread，然后在这个线程中通过 Handler 来接收和处理来自其他线程或者组件的任务请求，实现异步任务的处理，同时又能通过消息机制来保证任务的有序性。

总的来说，Handler 通过与 Looper 协作来处理消息，而 HandlerThread 则是一种方便的方式来创建带有 Looper 的线程，使得在这个线程中能够方便地使用 Handler 进行消息处理，从而实现了线程间的通信和异步任务的调度。

安卓中的异步任务，问了创建一个 asynchTask 对象可以调用多次吗？

在 Android 中，AsyncTask 是一种用于执行异步任务的工具。一般情况下，一个 AsyncTask 对象只能执行一次。

从 AsyncTask 的设计原理来看，它的内部状态机制决定了它不适合多次执行。AsyncTask 在执行过程中有不同的状态，如准备状态、执行状态、完成状态等。当一个 AsyncTask 对象开始执行任务后，它的状态会发生变化，并且在任务执行完成后，这个状态不会自动重置。如果尝试再次执行已经执行过的 AsyncTask 对象，可能会导致异常或者不符合预期的行为。

例如，假设一个 AsyncTask 用于从网络上下载一个文件。当第一次执行这个 AsyncTask 时，它会在后台线程中启动下载任务，并且在下载完成后更新 UI 或者进行其他后续操作。如果在下载完成后再次尝试执行这个 AsyncTask 对象，由于它的内部状态已经是完成状态，可能会出现状态错误，导致程序崩溃或者无法正确执行下载任务。

不过，如果需要多次执行类似的异步任务，可以通过创建多个 AsyncTask 对象来实现。每次需要执行任务时，创建一个新的 AsyncTask 对象，这样可以保证每个任务都能在正确的状态下开始和完成，并且不会相互干扰。

另外，在一些特殊情况下，通过对 AsyncTask 进行适当的扩展和修改，也可以实现一个对象多次执行的功能，但这需要深入了解 AsyncTask 的内部机制，并且要谨慎处理状态的重置和任务的重复执行问题，以避免出现内存泄漏、线程安全等其他问题。

开发中一些内存优化的应用。如果泄露已经发生了怎么排查是哪个代码块？

内存优化应用

在开发中，有多种内存优化的方法。首先是合理使用缓存。例如，对于一些频繁访问但数据更新不频繁的资源，如图像、网络数据等，可以使用缓存来减少数据的重复获取和内存占用。可以采用 LRU（最近最少使用）缓存策略，当缓存空间不足时，自动清除最近最少使用的缓存项。

在对象的创建和销毁方面，要尽量减少不必要的对象创建。比如，在循环中避免频繁创建新的对象。如果在一个循环中每次迭代都创建一个新的字符串对象，而这些字符串对象的内容相似或者可以复用，就可以考虑将字符串对象提取到循环外部，或者使用 StringBuilder 来拼接字符串，减少对象创建的数量。

对于大型对象，如 Bitmap（位图），要注意及时回收。在 Android 中，Bitmap 占用的内存空间较大，当不再需要使用时，要确保调用 recycle 方法来释放内存。并且，在加载 Bitmap 时，可以根据显示的实际需求进行压缩，避免加载过高分辨率的 Bitmap 导致内存浪费。

排查内存泄露的代码块

当内存泄露已经发生时，可以使用一些工具来排查。Android Studio 自带的 Memory Profiler 是一个很有用的工具。通过 Memory Profiler，可以拍摄内存快照。在应用运行的不同阶段，如启动后、进行某些操作后、关闭某些组件后等，分别拍摄快照。然后对比这些快照，查看哪些对象在应该被回收的情况下仍然存在。

例如，如果怀疑某个 Activity 发生了内存泄露，可以在 Activity 启动后拍摄一个快照，然后在 Activity 被销毁后再拍摄一个快照。对比这两个快照，查看 Activity 对象以及与之相关的对象是否仍然存在于内存中。如果存在，就可以通过 Memory Profiler 提供的引用链来查看是哪些对象持有了 Activity 的引用，从而定位到可能导致内存泄露的代码块。

另外，还可以使用 LeakCanary 这个开源工具。LeakCanary 会自动监测内存泄露，并且在检测到泄露时，会提供详细的报告，包括导致泄露的引用链。通过这个引用链，可以逐步追踪到产生内存泄露的代码位置，如某个内部类持有外部类的引用，或者某个单例对象错误地持有了其他对象的引用等情况。

频繁创建和销毁线程的问题及解决方案

问题

频繁创建和销毁线程会带来多个问题。首先是性能开销。线程的创建和销毁需要消耗系统资源，包括 CPU 时间和内存。每次创建线程时，系统需要为线程分配内存空间，包括栈空间等，并且需要进行一些初始化操作。当线程销毁时，系统又需要回收这些资源。如果频繁地进行这种操作，会导致系统资源的浪费，降低应用的整体性能。

其次是线程管理的复杂性。频繁创建和销毁线程会使得线程的状态难以管理。例如，在多线程并发的场景中，过多的线程创建和销毁可能会导致线程之间的竞争条件和死锁等问题。而且，大量的线程也会增加系统的调度负担，影响其他线程的执行效率。

解决方案

可以使用线程池来解决这个问题。线程池是一种管理和复用线程的机制。它预先创建一定数量的线程，将这些线程放在一个池中，当有任务需要执行时，从池中获取一个线程来执行任务，任务完成后，线程不会被销毁，而是返回池中等待下一个任务。

例如，在一个需要频繁执行网络请求的应用中，可以创建一个固定大小的线程池。当有新的网络请求到来时，从线程池中获取一个线程来执行请求，而不是每次都创建一个新的线程。这样可以减少线程创建和销毁的频率，降低性能开销。

另外，对于线程的生命周期管理要更加谨慎。在设计线程的任务时，要确保任务能够及时完成，避免线程长时间处于等待或者执行无效任务的状态。并且，可以通过合理的线程优先级设置来优化线程的执行顺序，提高系统的整体效率。

性能优化经验（如内存存储问题及其优化）

内存存储优化

在内存存储方面，首先要注意数据结构的选择。不同的数据结构在内存占用和操作效率上有很大差异。例如，对于频繁插入和删除操作的数据集，LinkedList 可能比 ArrayList 更合适。因为 ArrayList 在插入和删除中间元素时，可能需要移动大量的元素，导致内存的频繁重新分配和复制，增加内存开销。而 LinkedList 只需要修改节点之间的指针即可。

对于缓存的合理使用也是内存优化的重要部分。前面提到的 LRU 缓存策略可以有效地利用内存空间。例如，在一个图片加载应用中，通过 LRU 缓存来存储已经加载过的图片。当需要再次显示某张图片时，先从缓存中查找，如果存在，就直接使用，避免重新加载，减少内存和网络资源的消耗。

在处理大型对象（如 Bitmap）时，要注意内存的高效利用。在加载 Bitmap 时，可以根据显示设备的分辨率和实际需求来调整 Bitmap 的大小。例如，在一个手机应用中，如果一个 ImageView 的大小较小，就不需要加载高分辨率的 Bitmap，可以通过 BitmapFactory 的选项来进行压缩，减少 Bitmap 占用的内存。

其他性能优化方面

在布局优化上，要尽量减少布局的嵌套。过多的布局嵌套会导致视图的测量和绘制过程变得复杂，增加 CPU 的计算量。可以使用扁平化的布局结构，或者使用 ConstraintLayout 等高效的布局工具来减少布局嵌套。

在网络请求方面，要避免频繁的小数据量请求。可以将多个小请求合并为一个大请求，减少网络开销。并且，对于网络数据的缓存也很重要，如前面提到的，通过缓存网络数据来减少重复请求，提高应用的性能。

对于动画的使用，要注意动画的性能影响。复杂的动画效果可能会消耗大量的 CPU 和 GPU 资源。在设计动画时，要根据设备的性能和应用的实际需求来选择合适的动画类型和复杂度，避免动画导致应用卡顿。

对智能驾驶技术作何理解

智能驾驶技术是当今科技领域极具发展潜力和变革性的技术，旨在让车辆具备自主感知、决策和控制能力，以实现不同程度的自动驾驶功能。

从感知层面来看，智能驾驶依靠多种传感器协同工作。例如，摄像头可以捕捉道路图像，识别交通标志、车道线以及其他车辆和行人的外形特征；毫米波雷达能够精确探测车辆周围物体的距离、速度等信息，尤其在恶劣天气条件下表现出色；激光雷达则以更高的精度绘制出车辆周边的三维环境地图。这些传感器收集到的海量数据会被传输到车辆的计算平台。

在决策环节，智能驾驶系统会基于感知到的信息，结合预设的规则和算法进行分析判断。比如，根据前方车辆的速度和距离，决定是保持当前车速、减速还是超车；依据交通标志的指示，选择合适的行驶路线和速度限制。这一过程需要强大的计算能力和复杂的软件算法来确保决策的准确性和及时性。

控制方面，智能驾驶系统会将决策指令转化为车辆的实际操作，如控制方向盘转动、调整车速、制动等。通过与车辆的电子控制系统紧密集成，实现对车辆行驶状态的精准掌控。

智能驾驶技术的发展不仅能提升交通效率，减少交通事故，还能为出行带来更多便利，比如让驾驶者在长途旅行中得到充分休息。然而，它也面临诸多挑战，如技术可靠性、网络安全、伦理道德以及法律法规等方面的问题。要实现完全可靠、安全且被社会广泛接受的智能驾驶，还需要科技界、政府和社会各界共同努力，不断完善技术和相关配套体系。

项目里写了 MVI 架构，他和 MVVM 的区别

MVI 架构

MVI 架构是一种在 Android 开发等场景下应用的架构模式，它主要围绕着三个核心概念展开：Model、View 和 Intent。

Model 在 MVI 架构中代表数据模型，它负责存储和管理应用程序的数据状态。例如，在一个天气应用中，Model 可能包含当前天气状况、温度、湿度等数据信息，并且这些数据会随着网络请求或其他操作而更新。

View 则是负责展示数据给用户的界面部分，它是用户与应用交互的窗口。比如天气应用中的界面布局，通过各种 UI 组件如 TextView 展示温度数值，ImageView 展示天气图标等。

Intent 在 MVI 架构中有特殊含义，它并非 Android 系统中用于启动 Activity 等的 Intent 概念，而是作为一种用户意图的表达。当用户在 View 上进行操作，如点击按钮、滑动屏幕等，这些操作会被封装成 Intent，它代表了用户想要实现的某种行为。然后 Intent 会被传递到 Model 端，触发 Model 进行相应的数据处理和状态更新，之后新的状态会再反馈到 View 进行展示。

MVVM 架构

MVVM 同样包含三个核心部分：Model、View 和 ViewModel。

Model 依旧是负责数据存储和业务逻辑处理的部分，与 MVI 中的 Model 类似，承担着数据管理的重任。

View 还是用于展示数据给用户的界面层。

ViewModel 是 MVVM 架构的关键所在，它是一个连接 Model 和 View 的中间层。ViewModel 会暴露一些可观察的数据属性和命令，通过数据绑定机制，View 可以自动获取 ViewModel 中更新的数据并进行展示。例如，在一个电商应用中，ViewModel 可以持有商品列表数据，当后台数据更新时，ViewModel 会感知到并将新数据通过数据绑定传递给 View，使得商品列表能实时更新。同时，View 上的用户操作也可以通过数据绑定触发 ViewModel 中的命令，进而影响 Model。

两者区别

数据流动方式：在 MVI 架构中，数据流动是由用户意图（Intent）触发，从 View 到 Model，Model 处理后再将新状态反馈回 View，是一种较为线性的、基于用户行为驱动的数据流动模式。而 MVVM 架构主要依靠数据绑定，ViewModel 作为中间枢纽，View 和 Model 之间的数据交互相对更自动和频繁，View 的更新往往是随着 ViewModel 中数据的变化而自动进行的，无需像 MVI 那样明确的由用户意图触发的流程。
中间层职责：MVI 架构中的 Intent 更侧重于对用户行为的封装和传递，它不是一个像 ViewModel 那样专门用于数据处理和协调的中间层。MVVM 的 ViewModel 则承担了大量的数据处理、状态管理以及与 View 和 Model 的协调工作，比如将 Model 的数据转换为 View 能理解的形式，以及根据 View 的操作去更新 Model 等。
状态管理：MVI 架构对状态的管理更强调通过 Intent 来触发状态的更新，整个应用的状态变化与用户意图紧密相关，状态更新相对更有迹可循。MVVM 架构虽然也能管理状态，但更多是通过 ViewModel 中可观察的数据属性和命令来实现，状态变化可能更多地是基于数据本身的变化以及 View 和 Model 之间的交互，相对来说状态管理的方式更加灵活多样。

都用过哪些后台加载的工具类

在 Android 开发过程中，为了高效地在后台加载数据等资源，会用到多种工具类。

AsyncTask：这是 Android 提供的一个用于执行简单异步任务的工具类。它将异步任务的执行过程抽象为几个方法，如 onPreExecute（在异步任务执行前执行，可用于进行一些初始化操作，比如显示加载进度条）、doInBackground（在后台线程中执行真正的任务，如网络请求、文件读取等）、onProgressUpdate（在后台任务执行过程中，如果有进度更新，可以通过这个方法将进度信息传递到主线程，用于更新 UI 上的进度显示）和 onPostExecute（在异步任务完成后执行，可用于处理任务完成后的结果，比如隐藏加载进度条并展示获取到的数据）。AsyncTask 适用于一些简单的、不需要复杂配置的异步任务场景，例如从网络上获取一篇短文并在 UI 上展示。

Loader：Loader 是 Android 中用于异步加载数据的另一种机制，它提供了一种更灵活、更强大的方式来处理数据加载。Loader 有不同的类型，比如 CursorLoader 可用于从数据库中获取数据，AsyncTaskLoader 则是基于 AsyncTask 实现的，可以用于执行一般的异步任务，如网络请求等。Loader 的优点在于它可以自动管理数据加载的生命周期，比如在 Activity 或 Fragment 的生命周期发生变化时（如屏幕旋转等），Loader 可以自动重新加载数据，确保数据的一致性和连续性。例如，在一个音乐播放应用中，使用 CursorLoader 从本地数据库中获取音乐列表，即使设备屏幕旋转，音乐列表也能正确显示。

Volley：Volley 是谷歌推出的一个网络请求库，它专注于高效地处理网络请求。Volley 可以用于发送各种类型的网络请求，如 GET、POST 等，并且它具有自动缓存机制，可以根据请求的 URL 等参数对网络请求的结果进行缓存，提高网络请求的效率。同时，Volley 在处理并发网络请求时也表现出色，它可以通过设置请求队列等方式来合理安排网络请求的顺序和优先级。例如，在一个新闻应用中，使用 Volley 来发送多个网络请求，分别获取不同板块的新闻内容，并且利用其缓存机制来减少重复请求，提高应用的整体性能。

OkHttp：OkHttp 是一个功能强大的 HTTP 客户端，它在网络请求方面有着出色的表现。OkHttp 可以高效地建立网络连接，它拥有一个连接池，能够在多次网络请求时重复利用已有的连接，减少连接建立和断开的开销。OkHttp 还可以设置拦截器，比如设置日志拦截器可以记录网络请求和响应的详细信息，方便调试；设置缓存拦截器可以实现数据的缓存策略，提高网络请求的效率。例如，在一个电商应用中，使用 OkHttp 来发送网络请求，获取商品图片、价格等信息，通过连接池和拦截器的设置，优化了网络请求的过程，使得应用运行得更加流畅。

Retrofit：Retrofit 是一个基于 OkHttp 的网络请求框架，它进一步简化了网络请求的编写过程。Retrofit 通过定义接口的方式来发送网络请求，开发者只需要在接口中定义好请求的方法、参数等信息，Retrofit 会根据这些信息自动生成相应的网络请求代码。Retrofit 还可以与各种数据解析库（如 Gson）结合使用，方便地将网络请求的结果解析成所需的对象形式。例如，在一个旅游应用中，使用 Retrofit 来发送网络请求获取旅游景点的信息，结合 Gson 将获取到的 JSON 数据解析成景点对象，然后在 UI 上展示。

git 的一些提问；一般时用命令行

git init：这是创建一个新的 Git 仓库的命令。当你开始一个新的项目或者想要将一个现有的项目纳入 Git 的管理之下时，就可以使用 git init 命令。它会在当前目录下创建一个.git 目录，这个目录就是 Git 仓库的核心部分，里面包含了 Git 用来管理项目版本、跟踪文件变化等的各种信息。例如，你在本地电脑上有一个新编写的 Android 应用项目，想要用 Git 来管理它的开发过程，就可以在项目的根目录下执行 git init 命令，之后这个项目就成为了一个可以被 Git 跟踪和管理的项目。

git add：git add 命令用于将文件添加到 Git 的暂存区。在 Git 的工作流程中，我们首先需要把想要纳入版本控制的文件添加到暂存区，之后才能进行提交等操作。可以一次添加一个文件，比如 git add file.txt，也可以添加整个目录下的所有文件，如 git add.（注意这个点代表当前目录下的所有文件）。例如，在开发 Android 应用时，完成了一个新的功能模块的代码编写，想要把相关的代码文件添加到 Git 暂存区，就可以使用 git add 命令，将这些文件逐一添加或者一次性添加整个模块的文件。

git commit：git commit 命令是用于将暂存区的文件提交到 Git 仓库的本地分支上。在执行 git commit 之前，需要先通过 git add 将文件添加到暂存区。git commit 命令通常需要附带一个提交信息，这个信息用于描述本次提交的内容，方便自己和其他团队成员在查看版本历史时了解每一次提交的目的。例如，你可以使用 git commit -m "Added new feature for Android app: implemented user login functionality" 这样的格式，其中 - m 后面的内容就是提交信息。通过这样的提交操作，你就把新编写的用户登录功能代码正式提交到了 Git 仓库的本地分支上。

git push：git push 命令用于将本地 Git 仓库中的分支推送到远程 Git 仓库。在团队协作开发中，当你在本地完成了一系列的开发工作并进行了多次 git commit 操作后，就需要把本地分支上的成果推送到远程仓库，以便其他团队成员可以获取到你的工作成果并进行协作。例如，你在本地开发了一个 Android 应用的新功能，经过多次提交后，使用 git push origin master（假设远程仓库名为 origin，主分支为 master）这样的格式将本地主分支推送到远程仓库，这样其他团队成员就可以在远程仓库中看到你的新功能代码。

git pull：git pull 命令是用于将远程 Git 仓库中的分支拉取到本地 Git 仓库，并自动合并到当前正在使用的本地分支上。在团队协作开发中，当其他团队成员在远程仓库中进行了一些开发工作并推送到远程仓库后，你就需要通过 git pull 来获取他们的工作成果并合并到自己的本地分支上。例如，你的同事在远程仓库中添加了一个新的 Android 应用功能，你通过 git pull origin master（假设远程仓库名为 origin，主分支为 master）这样的格式将远程主分支拉取到本地并合并到自己的本地分支上，这样你就可以在本地看到并使用同事的新功能代码。

git clone：git clone 命令用于从远程 Git 仓库中复制一份完整的项目到本地电脑。当你想要参与一个已经存在的项目的开发，或者想要获取一个项目的最新版本以便学习等目的时，就可以使用 git clone 命令。例如，你想要参与一个开源的 Android 应用项目的开发，就可以通过 git clone https://github.com/xxxx/yyyy.git这样的格式（其中https://github.com/xxxx/yyyy.git是远程仓库的地址）从远程仓库中复制一份项目到本地电脑，之后你就可以在本地进行开发、测试等操作。

git branch：git branch 命令用于创建、查看和删除 Git 分支。在项目开发过程中，我们经常需要创建不同的分支来进行不同的工作，比如创建一个开发分支 dev 用于日常开发，一个测试分支 test 用于测试，一个主分支 master 用于发布等。可以使用 git branch dev 这样的格式来创建一个新的分支，使用 git branch -l（其中 - l 代表 list）来查看所有的分支，使用 git branch -d dev 这样的格式来删除一个已经存在的分支。例如，在开发一个 Android 应用时，为了便于管理和测试，创建了一个开发分支 dev，在开发过程中可以随时查看所有的分支情况，当开发完成后，可以根据需要删除不需要的分支。

git merge：git merge 命令用于将两个不同的分支合并到一起。在项目开发过程中，当我们完成了一个分支（比如开发分支 dev）的开发工作后，需要将其合并到主分支 master 上，就可以使用 git merge 命令。例如，在开发一个 Android 应用时，在开发分支 dev 上完成了所有的开发工作，然后使用 git merge dev master 这样的格式将开发分支 dev 合并到主分支 master 上，这样主分支 master 就包含了开发分支 dev 的所有成果。

git log：git log 命令用于查看 Git 仓库的版本历史。通过 git log 命令，我们可以看到每一次提交的日期、提交人、提交信息以及提交的文件等内容。例如，在开发一个 Android 应用时，通过 git log 命令可以查看从项目开始到现在的所有提交记录，了解项目的发展历程，比如哪个阶段添加了哪些功能，哪个阶段修复了哪些问题等。

对 Java 面向对象的理解

Java 是一种典型的面向对象编程语言，面向对象的思想贯穿于整个 Java 的设计和编程实践中。

从概念上讲，面向对象编程（OOP）围绕着几个核心要素展开：类、对象、属性、方法和继承、多态、封装。

类和对象：类是一种抽象的概念，它定义了一种类型的事物所具有的共同特征和行为。例如，在一个简单的学生管理系统中，我们可以定义一个 Student 类，这个类中可能包含学生的属性（如姓名、年龄、学号等）和方法（如学习方法、考试方法等）。而对象则是类的具体实例，当我们创建一个 Student 对象时，就相当于在现实生活中找到了一个具体的学生，这个对象会拥有类所定义的属性和方法。比如，我们可以创建一个名为 “小明” 的 Student 对象，这个对象的姓名属性值为 “小明”，年龄属性值为 18，学号属性值为 1001，并且可以调用学习方法和考试方法等。

属性和方法：属性是对象所具有的特征，它描述了对象的某种状态。在上面的 Student 类中，姓名、年龄、学号等就是属性。方法则是对象能够执行的行为，它定义了对象如何去做某件事。比如学习方法可能会涉及到一些逻辑，如根据课程内容进行学习、记录学习时间等。属性和方法共同构成了对象的完整行为和状态描述。

继承：继承是面向对象编程中的一个重要特性，它允许一个类继承另一个类的属性和方法。例如，在学生管理系统中，我们可以定义一个 GraduateStudent 类，它继承自 Student 类。这样，GraduateStudent 类就可以继承 Student 类的所有属性和方法，如姓名、年龄、学号等属性以及学习方法、考试方法等方法。同时，GraduateStudent 类还可以添加自己的特色属性和方法，比如研究方向属性和论文撰写方法等。继承的好处在于可以减少代码的重复编写，提高代码的可维护性和可扩展性。

多态：多态是指在不同的情况下，同一个方法可以有不同的表现形式。例如，在一个图形绘制系统中，我们可以定义一个 Shape 类，然后定义它的子类如 Circle 类、Rectangle 类等。Shape 类中可以有一个 draw 方法，当我们调用不同子类的 draw 方法时，会得到不同的结果。比如调用 Circle 类的 draw 方法会画出一个圆，调用 Rectangle 类的 draw 方法会画出一个矩形。多态使得程序能够更加灵活地处理不同类型的对象，提高了程序的灵活性和可维护性。

封装：封装是指将对象的属性和方法封装在一个类中，并对外部世界隐藏其内部实现细节。在 Student 类中，我们可以通过设置访问修饰符（如 private、public 等）来控制属性和方法的访问权限。例如，将学生的学号属性设置为 private，这样外部世界就不能直接访问学号属性，只有通过类内部定义的方法（如获取学号的方法）才能访问。封装的好处在于可以保护对象的内部结构和数据，防止外部世界的不当干预，提高了代码的稳定性和可维护性。

总之，Java 的面向对象特性使得代码的编写更加有条理、可维护和可扩展性强。通过合理运用类、对象、属性、方法、继承、多态和封装等要素，我们可以构建出复杂而高效的软件系统。

activity 启动流程是怎样的

当启动一个 Activity 时，整个流程涉及多个组件和系统层面的操作。

首先，从用户操作或者其他组件的请求开始。例如，用户点击应用图标，系统会接收到这个启动请求。如果应用进程尚未创建，系统会通过 Zygote 进程来创建一个新的应用进程。Zygote 进程是 Android 系统中的一个特殊进程，它预先加载了一些核心的库和资源，能够快速地通过复制自身的内存空间来创建新的应用进程，这一过程可以提高应用进程的创建效率。

在新的应用进程中，会创建一个 ActivityThread 对象。ActivityThread 是 Android 应用的主线程，它负责管理 Activity、广播接收器、服务等组件的生命周期。接着，系统会通过 ActivityThread 来加载并解析 Activity 的配置信息，包括布局文件、主题等。

之后，系统会创建 Activity 对象，并调用其一系列生命周期方法。首先是 onCreate 方法，在这个方法中，开发者可以进行一些初始化操作，比如设置布局、初始化成员变量等。在 onCreate 之后，会调用 onStart 方法，此时 Activity 变得可见，但还不能与用户进行交互。随后是 onResume 方法，当这个方法被调用后，Activity 完全可见并且可以接收用户的输入，如触摸、按键等操作。

在整个启动过程中，系统还会涉及到资源的分配，如内存分配、视图层次结构的构建等。并且，Activity 的启动还可能受到系统资源管理的影响。例如，当内存不足时，系统可能会回收一些处于后台的 Activity，以释放内存。这些 Activity 在重新回到前台时，会根据其保存的状态进行恢复，这也是 Activity 启动流程中的一个重要环节，涉及到 onSaveInstanceState 和 onRestoreInstanceState 等方法的使用。

hashmap 原理

HashMap 是 Java 中常用的一种数据结构，用于存储键值对（Key - Value）形式的数据。

从内部结构来看，HashMap 主要由数组和链表（在 Java 8 及以后，如果链表长度超过一定阈值，链表会转换为红黑树，以提高查找效率）组成。数组用于存储元素，每个数组元素称为一个桶（bucket）。当我们向 HashMap 中添加一个键值对时，首先会根据键（Key）的哈希值（hash code）计算出它在数组中的存储位置，这个位置就是桶的索引。计算桶索引的方法是通过对键的哈希值进行取模运算，模的值是数组的长度。

例如，假设有一个简单的 HashMap，数组长度为 16。当插入一个键值对时，计算键的哈希值，假设哈希值为 20，那么通过 20 % 16 得到桶索引为 4，这个键值对就会存储在索引为 4 的桶中。如果不同的键计算出的桶索引相同，就会在该桶中形成一个链表，新插入的元素会添加到链表的头部或者尾部（根据具体实现）。

在获取元素时，同样是先根据键的哈希值计算桶索引，然后在对应的桶中查找元素。如果桶中是链表，就需要遍历链表来找到匹配的键。如果是红黑树结构，就通过红黑树的查找方法来寻找元素。

HashMap 的容量（数组大小）和负载因子会影响其性能。负载因子是衡量 HashMap 填满程度的一个指标，当 HashMap 中元素的数量超过容量乘以负载因子时，就会触发扩容操作。扩容操作会创建一个新的更大的数组，并将原来数组中的元素重新哈希到新数组中，这个过程比较耗时，所以在使用 HashMap 时，要合理设置初始容量和负载因子，以平衡空间和性能。

你知道的 Android 虚拟机有哪些？怎么选择？

Android 虚拟机类型

Dalvik 虚拟机：这是早期 Android 系统使用的虚拟机。它采用了一种基于寄存器的架构，能够有效地利用内存和提高执行效率。Dalvik 虚拟机执行的是.dex 文件格式，它会将 Java 字节码转换为.dex 格式后再执行。在早期的 Android 设备中，Dalvik 虚拟机在处理资源有限的情况下发挥了较好的性能，但随着应用的复杂性增加和对性能要求的提高，它的一些局限性也逐渐显现出来。例如，在处理大量的内存密集型应用或者复杂的多线程应用时，Dalvik 虚拟机的性能可能会受到影响。
ART 虚拟机（Android Runtime）：ART 是 Android 系统目前主要使用的虚拟机。它在安装应用时就会将字节码编译为机器码，这种预编译的方式相比 Dalvik 虚拟机的即时编译（JIT）方式，可以提高应用的启动速度和执行效率。ART 虚拟机还支持更好的垃圾回收（GC）机制，能够更有效地管理内存，减少内存泄漏和应用卡顿的情况。例如，在运行大型游戏或者复杂的图形应用时，ART 虚拟机能够提供更流畅的体验。

选择方式

TCP 结束的四次挥手，什么情况下可以简化为三次

在 TCP 协议中，正常的连接断开需要经过四次挥手过程。

第一次挥手是客户端发送一个带有 FIN（结束标志）的 TCP 数据包，表示客户端想要关闭连接。这个数据包会包含客户端的序列号等信息。

第二次挥手是服务器收到客户端的 FIN 数据包后，会发送一个 ACK（确认）数据包给客户端，确认收到了客户端的关闭请求。此时，客户端到服务器方向的连接就进入了半关闭状态，客户端不会再向服务器发送数据，但服务器仍然可以向客户端发送数据。

第三次挥手是服务器在发送完剩余的数据后，也发送一个带有 FIN 标志的数据包，表示服务器也想要关闭连接。

第四次挥手是客户端收到服务器的 FIN 数据包后，发送一个 ACK 数据包给服务器，确认收到服务器的关闭请求，此时连接完全关闭。

在某些特殊情况下，四次挥手可以简化为三次。这种情况通常发生在服务器没有剩余数据要发送给客户端的时候。当服务器收到客户端的 FIN 数据包并发送 ACK 后，如果服务器没有其他数据要发送，就可以直接将 FIN 和 ACK 合并在一个数据包中发送给客户端，这样就省略了一次单独发送 FIN 的步骤，从而将四次挥手简化为三次。不过，这种情况相对较少，因为在大多数实际应用场景中，服务器在收到客户端的关闭请求后，可能还需要发送一些数据，如未处理完的响应数据等。

Arrays 了解吗，为什么使用快排而不是归并排序？（空间 o（logn））

Arrays 概述

在 Java 中，Arrays 是一个工具类，它提供了一系列用于操作数组的静态方法。这些方法涵盖了数组的排序、查找、填充、复制等多种操作，使得对数组的处理更加方便和高效。

例如，Arrays.sort 方法可以对基本数据类型数组（如 int []、double [] 等）和对象数组（如 String [] 等）进行排序。Arrays.fill 方法可以将数组中的所有元素填充为指定的值。Arrays.binarySearch 方法可以在已排序的数组中进行二分查找，快速找到指定元素的位置。

快排与归并排序对比

快速排序（Quick Sort）和归并排序（Merge Sort）都是经典的排序算法。

快速排序的基本思想是通过选择一个基准元素（pivot），将数组分为两部分，使得左边部分的元素都小于等于基准元素，右边部分的元素都大于等于基准元素。然后对这两部分分别进行快速排序，直到整个数组有序。

归并排序则是采用分治策略，将数组不断地分成两半，直到每个子数组只有一个元素，然后将这些子数组两两合并，在合并过程中对元素进行排序，直到合并成一个完整的有序数组。

在空间复杂度为 O (logn) 的情况下，选择快速排序而不是归并排序主要有以下原因。

从空间效率角度看，虽然归并排序在平均情况下的时间复杂度也是 O (nlogn)，与快速排序相当，但归并排序在合并过程中需要额外的辅助空间来存储临时数据。在最坏情况下，归并排序需要 O (n) 的辅助空间，而快速排序的空间复杂度在最好情况下为 O (logn)，这是因为快速排序是通过递归在原地进行交换元素操作，主要是利用栈空间来记录递归调用的信息，栈空间的深度最多为 O (logn)。

从性能方面考虑，快速排序在实际应用中通常表现出较好的性能。快速排序的内循环（划分操作）相对简单，并且可以通过优化选择合适的基准元素来提高性能。在数组元素已经基本有序或者随机分布的情况下，快速排序能够快速地将数组划分，减少比较和交换的次数。而归并排序在每次合并操作时都需要进行比较和复制元素，相对来说比较复杂，可能会导致性能下降。

不过，快速排序也有缺点，它在最坏情况下（例如数组已经有序或者逆序）的时间复杂度会退化为 O (n²)，但通过一些改进措施，如随机选择基准元素等，可以降低这种情况出现的概率。

优先队列数据结构

优先队列是一种特殊的数据结构，它与普通队列不同的是，队列中的元素具有优先级，每次出队操作取出的是队列中优先级最高的元素。

从实现角度来看，优先队列通常基于堆（Heap）来实现，常见的有二叉堆（Binary Heap），包括最小堆和最大堆。在最小堆中，每个节点的值都小于或等于它的子节点的值，所以堆顶元素就是整个堆中的最小值；而在最大堆中，每个节点的值都大于或等于它的子节点的值，堆顶元素即为最大值。

例如，在一个任务调度系统中，如果将任务按照优先级放入优先队列，优先级高的任务就相当于在堆顶（假设是最大堆的情况），每次执行任务时，就从优先队列中取出堆顶任务先执行，这样可以保证重要的任务先得到处理。

优先队列支持插入（offer）和删除（poll）等基本操作。插入一个元素时，会根据其优先级在堆中找到合适的位置插入，以维持堆的性质。删除操作则是移除堆顶元素，并通过调整堆结构来保持堆的有序性。

它在很多场景下都有应用，比如在操作系统的进程调度中，按照进程的优先级来安排执行顺序；在图算法中的 Dijkstra 最短路径算法中，用于存储待扩展的节点，每次选择距离源节点最近（优先级最高）的节点进行扩展。

10000 个数找最大 100 个，问时间复杂度

要从 10000 个数中找出最大的 100 个，可以采用多种方法，不同方法的时间复杂度也有所不同。

一种常见的方法是先对这 10000 个数进行排序，比如使用快速排序算法，其平均时间复杂度为 O (n log n)，这里 n = 10000。排序完成后，直接取最后 100 个数就是最大的 100 个。但这种方法整体时间复杂度主要由排序操作决定，即为 O (10000 log 10000)。

另一种更高效的方法是利用优先队列（假设是最小堆实现的优先队列）。具体步骤如下：首先，创建一个大小为 100 的最小堆，然后遍历这 10000 个数。对于每一个数，如果堆的大小小于 100，就直接将该数插入堆中。如果堆已经满了（大小为 100），就比较该数和堆顶元素（堆中当前最小的数）。如果该数大于堆顶元素，就删除堆顶元素并将该数插入堆中。

在遍历完所有 10000 个数后，堆中的 100 个数就是最大的 100 个。这个过程中，每次插入或删除操作在堆中的时间复杂度为 O (log k)，这里 k 是堆的大小，最大为 100。而遍历 10000 个数的时间复杂度为 O (n)，这里 n = 10000。所以总体时间复杂度为 O (n log k)，即 O (10000 log 100)。

相比之下，使用优先队列的方法时间复杂度更低，尤其是当要找的最大数的数量相对总数量较小时，这种优势更加明显。

给你大量的无序数字，我想在任何时候都知道这堆数字中哪个数字是最大的怎么做？

当面对大量的无序数字，并且要在任何时候都能快速知道其中最大的数字时，可以采用以下几种方法：

方法一：使用一个变量来记录最大值

可以先初始化一个变量，假设为 maxValue，将其初始值设为这堆数字中的第一个数。然后遍历这堆数字中的每一个数，对于每一个数 x，如果 x 大于 maxValue，就将 maxValue 更新为 x。这样，在遍历完所有数字后，maxValue 就始终记录着这堆数字中的最大值。

这种方法的时间复杂度为 O (n)，其中 n 是数字的总数。因为需要遍历每一个数字来比较并更新最大值。每次查询最大值时，直接返回 maxValue 即可，查询时间复杂度为 O (1)。

方法二：使用优先队列（最大堆）

构建一个基于最大堆的优先队列。将这堆无序数字依次插入到优先队列中。插入操作完成后，优先队列的堆顶元素就是这堆数字中的最大值。

在后续过程中，如果这堆数字有更新（比如增加或删除数字），相应地在优先队列中进行插入或删除操作，以保持优先队列能正确反映这堆数字的情况。插入和删除操作在最大堆中的时间复杂度为 O (log n)，其中 n 是当前优先队列中的元素数量。查询最大值时，直接返回堆顶元素，查询时间复杂度为 O (1)。

虽然使用优先队列在插入和删除操作上相对复杂一些，时间复杂度为 O (log n)，但它的优点是可以方便地应对数字集合动态变化的情况，并且始终能快速获取最大值。

由一亿个数字，其中所有数都出现两次，只有一个数出现一次，我想找到它怎么办？

对于一亿个数字，其中所有数都出现两次，只有一个数出现一次的情况，可以利用异或（XOR）运算的特性来找到这个唯一出现一次的数。

异或运算有以下几个重要特性：

任何数与自身异或结果为 0，即 a ^ a = 0。
0 与任何数异或结果为该数本身，即 0 ^ a = a。

基于这些特性，我们可以将这一亿个数字依次进行异或运算。具体步骤如下：设一个变量 result，初始值为 0。然后遍历这一亿个数字，对于每一个数字 num，将 result 与 num 进行异或运算，即 result = result ^ num。

在遍历完所有数字后，result 的值就是那个唯一出现一次的数。

因为所有出现两次的数在异或过程中都会相互抵消（a ^ a = 0），最后只剩下那个唯一出现一次的数与 0 进行异或，根据特性 2，就得到了这个唯一出现一次的数。

这种方法的时间复杂度为 O (n)，其中 n 是数字的总数，也就是一亿。只需要遍历一遍所有数字进行异或运算即可找到那个唯一出现一次的数。

如果所有数字都出现三次，只有一个数字出现了一次，那我想找到它怎么办？

当所有数字都出现三次，只有一个数字出现一次时，要找到这个唯一出现一次的数，可以采用以下方法：

考虑将每个数字用二进制表示，然后统计每一位上数字 1 出现的次数。

具体步骤如下：

创建一个长度为 32（假设数字是 32 位整数）的数组 count，用于统计每一位上数字 1 出现的次数，初始值全部设为 0。
遍历这组数字，对于每一个数字 num，将其转换为二进制表示。然后遍历这个二进制数的每一位，对于每一位 bit，如果 bit 为 1，就将 count [bit] 的值加 1。
遍历完所有数字后，对于 count 数组中的每一位 count [i]，将其除以 3 取余数。得到的余数就是那个唯一出现一次的数在相应位上的数字。
最后，根据 count 数组中得到的余数重新构建出那个唯一出现一次的数。

例如，假设数字是 8 位整数，有一组数字：1，1，1，2，2，2，3。将 1 转换为二进制为 00000001，统计每一位上 1 的次数后，count 数组可能变为 [3, 0, 0, 0, 0, 0, 0, 1]。将 2 转换为二进制为 00000010，再次统计后，count 数组变为 [3, 3, 0, 0, 0, 0, 0, 1]。将 3 转换为二进制为 00000011，最后 count 数组变为 [3, 3, 3, 0, 0, 0, 0, 2]。除以 3 取余数后，count 数组变为 [0, 0, 0, 0, 0, 0, 0, 2]，根据这个余数可以重建出唯一出现一次的数 3。

这种方法的时间复杂度为 O (n)，其中 n 是数字的总数，因为需要遍历所有数字两次（一次统计每一位上 1 的次数，一次根据余数重建数字）。通过这种方式可以准确找到那个唯一出现一次的数。

双链表反转

双链表是一种链表结构，每个节点除了有指向下一个节点的指针（next）外，还有指向前一个节点的指针（prev）。要实现双链表的反转，就是要将链表中节点的前后连接顺序完全颠倒过来。

以下是实现双链表反转的基本步骤：

首先，定义三个指针：当前指针（current）指向双链表的头节点，前一个指针（prev）初始化为空。

然后，通过循环遍历双链表。在每次循环中，先保存当前节点的下一个节点到一个临时指针（nextTemp）中，这是因为我们即将改变当前节点的 next 指针指向。

接着，将当前节点的 next 指针指向它的前一个节点（prev），实现节点连接方向的反转。同时，将当前节点的 prev 指针指向之前保存的下一个节点（nextTemp）。

之后，将前一个指针（prev）移动到当前节点的位置，以便下一次循环时使用。再将当前指针（current）移动到之前保存的下一个节点（nextTemp）的位置，继续下一轮循环。

当当前指针（current）为空时，说明已经遍历完整个双链表，此时的 prev 指针所指向的节点就是反转后的双链表的头节点。

例如，假设有一个双链表：1 <-> 2 <-> 3 <-> 4，其中数字表示节点的值，箭头表示节点间的指针连接方向。按照上述步骤进行反转操作后，就会得到 4 <-> 3 <-> 2 <-> 1 的双链表结构。

双链表反转的时间复杂度为 O (n)，其中 n 是双链表的节点个数。因为需要遍历每个节点一次来完成反转操作。

先解释一下完全二叉树是什么？然后## 再## 完全二叉树里面找两个子节点的最近的祖先节点。

完全二叉树的定义

完全二叉树是一种特殊的二叉树结构。它满足以下条件：除了最后一层外，每一层上的节点数都达到最大值；在最后一层上，节点从左到右依次排列，可能存在最左边的几个节点缺失，但不会出现中间或右边节点缺失而左边节点存在的情况。

简单来说，完全二叉树看起来就像是一个满二叉树（每一层节点数都达到该层能容纳的最大节点数），只是在最后一层可能少了一些节点，并且少的节点都是从右往左依次缺失的。

例如，下面是一个完全二叉树的示例：

1 / 2 3 / \ / 4 5 6 7

在完全二叉树中找两个子节点的最近的祖先节点

可以使用深度优先搜索（DFS）的方法来解决这个问题。

以下是一种常见的实现思路：

从根节点开始，分别对两个目标子节点进行深度优先搜索，记录下从根节点到每个目标子节点的路径。

例如，对于目标子节点 A 和 B，通过深度优先搜索得到路径 PathA 和 PathB。

然后，从两条路径的末尾开始，也就是从两个目标子节点开始，逐步向上比较两条路径上的节点。

当找到第一个相同的节点时，这个节点就是两个子节点的最近的祖先节点。

具体实现步骤如下：

定义两个列表 PathA 和 PathB，用于存储从根节点到目标子节点 A 和 B 的路径。
分别对目标子节点 A 和 B 进行深度优先搜索，在搜索过程中，将经过的节点依次添加到对应的路径列表中。
得到两条路径后，设指针 i 指向 PathA 的末尾，指针 j 指向 PathB 的末尾。
开始比较 PathA [i] 和 PathB [j]，如果它们相等，说明找到了最近的祖先节点，直接返回该节点；如果不相等，就将 i 和 j 都减 1，继续比较上一个节点，直到找到相等的节点为止。

这种方法的时间复杂度主要取决于深度优先搜索的时间复杂度，对于完全二叉树，深度优先搜索到一个节点的时间复杂度为 O (log n)，其中 n 是完全二叉树的节点个数。因为要对两个目标子节点分别进行深度优先搜索，所以总的时间复杂度为 O (2 log n)，即 O (log n)。