豆包 （Android） 一，二，三面

算法：不适用乘除mod 移位实现整数除法

线程和进程的区别

首先，进程就像是一个运行中的独立程序，它有自己独立的内存空间、各自的资源（比如文件句柄、系统资源等），而线程是在进程内部运行的，是进程调度的基本单位。通俗点说，进程相当于一个小工厂，工厂内部有许多个工人，而线程就是这些工人在厂里干活。

1. 内存和资源隔离：
   进程之间是完全隔离的，每个进程都有它独立的地址空间，这样一个进程出问题不会直接影响到另一个进程。而线程共享同一个进程的内存空间和资源，这也意味着如果线程之间没有做好同步处理，很容易出现数据混乱或者竞争条件。

2. 创建和切换开销：
   创建一个进程的开销比较大，因为不仅要分配独立的内存空间，还要初始化很多各自的资源。而线程的创建成本就低很多，因为它们共享了进程的内存和资源，线程切换时也比进程切换更快，所以多线程编程在提高响应速度和性能上更加轻量。

3. 互相通信：
   由于进程各自独立，所以进程间通信（IPC）相对复杂，需要借助操作系统提供的特定机制，比如管道、Socket、Shared Memory等。而线程之间直接共享内存，通信起来就简单多了，但同时必须考虑线程安全的问题。

4. 稳定性和安全性：
   由于进程之间隔离开来，一个进程崩溃一般不会影响到其他进程，整个系统的稳定性更好。线程因为共享内存，一个线程出问题有可能会导致整个进程崩溃，所以在设计时要特别小心。

在Android中，这个区别也比较重要。比如，一个Android应用通常就是一个进程，而我们可以在这个进程内使用多线程来处理UI线程以外的耗时任务，这样就不会阻塞UI。但如果我们需要在不同的工作之间保持绝对的独立性，可能会考虑启动额外的进程来运行，比如一些后台服务或者独立的模块，这样就能在一个模块崩溃的时候不会影响到整个应用的运行。

总的来说，进程更注重的是资源隔离和稳定性，而线程则更注重轻量、效率和并发处理。

单核和多核调度有没有什么不一样的地方

单核和多核调度上，主要区别在于调度的策略和效率上。简单来说，单核只有一个处理器核心，所以所有任务必须轮流使用这个核心，这样就只能靠时间片来进行任务之间的切换，换句话说，每个任务只能在规定的时间内运行，然后操作系统就得保存上下文，切换到下个任务，来达到“同时”运行的效果。那种情况，任务间如果有阻塞、或者某个任务执行时间太长，就可能影响整个系统的响应能力。

而在多核系统中，因为有多个核心，所以多个线程或任务能够真正地实现并行同时执行。调度器就可以把任务分布到不同核心上，这样不仅提高了效率，还减少了频繁上下文切换的开销。比如，在Android应用中，我们经常看到在UI线程之外开子线程去处理耗时操作，多核就能更好地利用系统资源，真正做到后台任务和主线程并行运行，而不会互相抢占同一个核心。

另外，多核调度里，调度策略也会更加复杂，因为不仅仅是任务轮流的问题，还涉及到如何把任务均匀分布到各个核心上，防止有的核心超负荷而有的核心空闲。调度器可能会采用一些诸如负载均衡、线程亲和性（Affinity）之类的策略，让和谐运行更高效。同时，多核的并发问题也更需要考虑，比如内存屏障、一致性问题，这些都是单核环境不太会遇到的。

总结下来说，单核调度强调的是时间片轮转和上下文切换，任务是真正串行执行的；而多核调度能够在硬件上实现真正的并行，调度策略更灵活，效率也更高，但同时在并发方面也要更多考虑数据同步和资源共享的问题。这也是为什么在Android开发中，我们尽量把耗时操作放在子线程里运行，因为这样在多核环境下才能更充分发挥多核优势，提升用户体验。

现场调度都是分时的吗

现场调度（也就是处理器调度）不全是简单的分时调度。分时调度是比较常见的一种方式，它把处理器时间划分成一个个时间片，然后按照一定的规则来分配给各个任务；这种方法在多任务系统里可以让每个任务看起来都在“同时”运行。但实际上，现场调度还有很多其他因素和策略，并不是所有调度都只是单纯轮换时间片这么简单。

首先，很多操作系统（比如Linux在Android中常用的调度器）不仅仅依赖时间片轮转，而是采用一种“完全公平调度”（Completely Fair Scheduler）的方式。当任务数量较多时，调度器会根据每个任务已经消耗的CPU时间、优先级等因素来尽量公平地分配处理器时间，而不只是单一地按照固定的时间片来切换。这样做的好处就是能够在系统负载较高时保持响应速度，同时兼顾任务的重要性和紧急性。

其次，也要考虑实时任务。对于某些要求高度响应和确定性的任务，操作系统可能会使用先到先服务或者固定优先级抢占的方式来调度，这样可以确保这些任务在需要的时候能够迅速获得处理器的使用权，而不会受到其他低优先级任务的影响。所以现场调度是根据不同场景和任务特点来采用不同策略的。

再者，在Android中，虽然一般应用层任务大多采用的是分时调度，但系统层和内核层的一些关键调度策略会结合事件处理、I/O等待以及中断处理等多种因素来优化性能和响应时间。比如，当一个任务需要等待用户输入或者网络响应时，它就不会占用CPU，而系统会把资源调度给那些有实际需求的任务，这样可以提高整体效率。也就是说，现场调度跟单纯的分时机制相比，是多层次、多维度的调度策略和保障机制的集合。

总的来说，我认为现场调度在实践中不仅限于传统的分时调度，而是根据系统需求、任务类型、优先级等多方面因素来灵活调整的

进程是怎么同步的

进程同步这个问题其实核心在于“如何保证多个独立进程之间的数据协调和一致性”。因为进程之间是隔离的，它们各自有独立的内存空间，不能像线程那样简单地共享变量，所以我们必须借助操作系统提供的跨进程通信和同步机制。

首先，进程同步有几种常见方式：

1. 共享内存：这是最常见的一种方式，把一块内存区域映射到多个进程的地址空间，通过读写这块共享内存来传递数据。因为多进程如果同时操作这块内存就容易导致数据不一致，所以需要配合一些同步机制，比如信号量（Semaphore）或者互斥锁（Mutex），来控制对共享内存的读写顺序。

2. 信号量和互斥锁：这类机制主要是用来做访问控制。比如说，如果两个进程需要同时访问共享资源，那么就可以先申请一个信号量，只有拿到信号量才能去访问资源。使用完毕后再释放。这样就能避免两个进程同时修改数据导致竞态条件。

3. 消息队列和管道：这是一种通过消息传递来实现同步的方法。进程A和进程B之间可以通过管道或者消息队列来交换信息。这样一个进程写消息，另一个进程从队列中读取消息，就可以通过这一消息的发送和接收顺序来确保操作的顺序性，而不直接访问共享的数据空间。当然这以后系统也会负责消息的缓冲和顺序保证。

4. 文件锁和数据库锁：有时候多个进程需要访问持久化存储，比如文件或者数据库，这个时候就可以利用文件锁或者数据库自带的锁机制来确保同一时刻只有一个进程在操作数据，防止数据冲突。

在Android开发中，我们虽然平时搞应用可能更关注多线程，但底层也是受益于操作系统的进程间同步机制。比如系统服务和应用之间通信，通常使用Binder机制，这其实是一种专门为进程间通信设计的IPC，底层会用到共享内存，再结合锁机制、消息通知等手段来同步通信过程。

总结来说，进程同步体现了在独立内存空间中如何借助操作系统的IPC机制和专门的同步原语来协调多个进程的合作。关键点在于：因为进程之间天然隔离，所以我们必须有一种额外的机制来确保数据的一致性和操作的顺序性，而这往往涉及到共享内存的保护、信号量、管道或者其他通信手段。

信号量（Semaphore）是一种用于线程同步的机制，它允许多个线程对共享资源进行受控访问。信号量维护了一个计数器，用于表示可用资源的数量。线程可以通过信号量申请资源（acquire）或释放资源（release），从而实现对共享资源的访问控制。

信号量的核心思想是计数器和信号通知。它是一种更通用的同步机制，可以用于解决互斥锁无法覆盖的多线程问题。

----

• 互斥锁适用场景：

  • 确保某一时刻只有一个线程访问资源。
  • 简单的线程互斥问题。

• 信号量适用场景：

  • 限制多个线程对资源的并发访问。
  • 线程间的复杂协调与同步（如生产者-消费者模型）。
  • 灵活控制资源分配（如动态调整并发数量）。

信号量的灵活性和计数机制，使它能够解决互斥锁无法覆盖的多线程问题，尤其是在需要部分并发或线程间复杂同步的场景中。

-----

hashmap有没有线程同步问题

HashMap 本身是非线程安全的，也就是说，在多线程环境下，如果多个线程同时对 HashMap 进行写操作或者读写操作，就可能会出现线程安全问题。这个问题就是因为多个线程可能同时修改内部结构，导致数据不一致或者出现竞争状态。

从我的实践经验来看，如果你的应用会在多线程环境中共享同一个 HashMap，那么就必须注意同步问题。否则可能会出现数据丢失、死循环甚至崩溃的问题。比如说，在 Android 开发中，如果你在多个子线程中同时往一个 HashMap 添加或更新数据，而没有任何额外的同步措施，就可能有线程安全隐患。

另一方面，很多情况下我们会选择用 ConcurrentHashMap，这个类是专门为多线程设计的，内部做了很多分段锁的优化，可以有效避免并发访问时出现的问题。或者直接在业务逻辑上对 HashMap 进行同步处理，比如用同步代码块或者锁来控制访问，这样也能确保线程安全。

总的来说，HashMap 在多线程环境下确实存在同步问题，所以在设计多线程访问共享数据的时候，不应该直接使用原始的 HashMap，而应选择线程安全的版本或者加上必要的同步机制。这样能更好地保证数据一致性，提高运行时的稳定性。

------

分段锁（Segmented Lock 或 Striped Lock）是一种**细粒度锁（Fine-Grained Lock）**的实现机制，用于提高多线程环境下对共享资源的并发访问性能。它将一个大范围的锁拆分为多个小范围的锁（即分段），从而允许多个线程同时访问不同的分段资源，而不会相互阻塞。

hashmap怎么解决冲突的

首先，HashMap 会通过调用 key 的 hashCode 方法来获得一个哈希值，根据这个值再通过一些位运算（譬如和容量减一做与运算）确定放置到数组的哪个桶里。这样理论上每个 key 都会对应到一个数组索引位置。

但是现实中不同的 key 可能会计算出同一个索引位置，这就造成了冲突。为了解决这个问题，HashMap 采用了“链地址法”，也就是说，每个数组的桶其实是一个链表，所有映射到同一桶里的数据都会挂在这个链表上，这样就可以存储多个条目。

而且，从 Java 8 开始，当某个桶里的链表过长，比如说达到一定阈值（一般是 8 个元素），HashMap 会把这个链表转换成红黑树，以提高查找性能。这样，即便在最坏的情况下，查找的复杂度也不会退化成为遍历一个长链表。

另外，HashMap 还会不断检测整体的负载因子，当达到一定比例时会触发扩容。扩容时会重新计算每个 key 的位置，这样也能减少冲突的概率。

总的来说，HashMap 解决冲突依赖于先利用哈希函数将 key 分布到数组的不同桶里，如果不幸碰到冲突，则把冲突的元素放到桶内部的链表中，而在链表过长时再转化为红黑树以提高访问效率。这样就保证了即使发生冲突，整体的查找、插入、删除操作还是能在比较高的效率下运行。

java里的多线程同步是怎么做的

在 Java 里，多线程的同步主要是通过协作机制来保证多个线程在访问共享资源时不会出现竞争条件和数据不一致的问题。我在开发过程中，一般会使用下面这些常见方式：

首先是 synchronized 关键字。synchronized 可以用在方法声明上或者代码块中，主要作用就是为某个对象加上一个监视器锁（monitor），紧接着执行的线程就得到了这个对象的锁，这样其他线程就无法进入这个同步区域，直到锁被释放。注意，这个锁是可重入的，也就是说同一个线程在一个锁内可以再次获得这个锁，不会造成死锁。

然后就是 wait 和 notify/notifyAll。它们是在 synchronized 块中配合使用的。当一个线程持有锁进入同步代码块，并调用 wait 方法时，它会主动将锁释放并进入等待状态，等待其他线程调用 notify 或者 notifyAll 唤醒。这个机制主要用于线程之间对某个条件的协调和通信，比如一个生产者等待消费，或者消费者等待生产者唤醒，这样可以有效地控制线程之间的执行顺序。

另外，我在一些场景下会选择使用 java.util.concurrent 锁，比如 ReentrantLock。相比于 synchronized，ReentrantLock 提供了更加灵活的锁机制，比如能够尝试获取锁（tryLock）、在获取不到锁时进行中断或者设置超时，这在实际项目中有时对调试和优化很有帮助。

还有就是一些基于原子操作的类，例如 AtomicInteger、AtomicBoolean 这些，这些类通过底层的 CAS（Compare-And-Swap）机制实现无锁的线程安全操作。不需要加显式锁的情况下就可以实现线程安全，这对性能要求比较高的部分有一定好处。

总得来说，Java 的多线程同步机制实际上是通过这些不同级别的方法来控制线程的进出临界区，从而保证共享资源的安全访问。

reentrantlock 和 synchronized哪个锁的颗粒细

ReentrantLock 的控制粒度会比 synchronized 更细一些。用 synchronized 的话，我们大多数情况下是直接锁住整个代码块或者一个方法，这样锁的范围比较笼统，不能针对特定操作做一些更精细的控制；而 ReentrantLock 提供了更多扩展功能，例如可以尝试性获取锁、设置超时时间、还有条件变量（Condition）用来实现等待/通知机制，这些都是 synchronized 所不具备的。

实际开发中，如果我们把共享资源拆分出来，用多个 ReentrantLock 分别控制不同的部分，就能实现更细粒度的同步控制，这样并发度会更高，性能也可能会有提升。当然，这也会让代码复杂一些，需要开发者更仔细地管理锁的使用和释放。

总的来说，我个人更倾向于说，ReentrantLock 提供了更多灵活性，所以可以实现更加细粒度的锁控制，而 synchronized 更适合简单、原子性比较强、整体锁住代码块的场景。

粒度细意味着性能更好吗

我觉得锁的粒度细不一定直接就等于性能更好，这得看具体情况和场景。细粒度锁的优势在于它允许多个线程在并发环境下同时访问不同的资源部分，这样可以减少不必要的阻塞和等待，从而提高整体并发性能。但同时，这也带来了更多的设计和管理复杂性，因为你需要非常小心地确保不同锁之间不会产生死锁或者其他同步问题。

举个例子，在一个高并发系统中，如果把所有共享资源都用一个大锁来保护，虽然设计和实现上比较简单，但就会导致很多线程在等待这个锁，从而降低了系统的响应能力。而如果能将大任务拆分成几个独立的小任务，各自使用独立的锁进行保护，那么多个线程可以同时操作不同的资源部分，这样就能更充分地利用多核 CPU 的优势，整体性能可能就会提升。

不过，细粒度锁并非在所有场景下都是最优解。如果细化得过度，锁的管理和获取开销自己也会成为性能瓶颈，而且代码也会变得难以维护。所以在设计锁机制的时候，我们往往需要在锁的粒度和系统的复杂性之间找到一个平衡点。最终是否能提高性能，还得看竞争的程度、实际的并发访问模式以及锁本身的开销。

总的来说，细粒度锁有潜力提高性能，尤其是在高并发场景下，但这不是绝对的，还需要结合具体业务场景和系统架构来判断如何设计来才能达到最好的性能优化效果。

java内存模型

Java内存模型其实就是一套规范，主要解决多个线程之间共享数据时出现的不一致、可见性问题和顺序问题。可以把它想象成是一个说明书，告诉我们在多线程环境下，变量是如何在线程之间传递和更新的。

首先，它把内存分成了主内存和工作内存。主内存就是所有变量存放的地方，而每个线程都有自己的工作内存，会从主内存复制变量到自己的工作内存，然后在那边进行操作。线程对变量的修改，最后需要写回到主内存。如果没有同步机制，这就导致不同线程看到的数据可能不一致，因为它们操作的是本地拷贝。

其次，Java内存模型规定了“happens-before”关系。这种关系决定了操作的顺序和可见性。比如在同一个线程里面，代码本来就是按照顺序执行的，但当涉及多个线程时，这个规则就显得特别重要。通过happens-before规则，例如使用synchronized、volatile等关键字，我们可以确保一个线程的写操作对其他线程是可见的，并且按照预期的顺序执行。

再一个点是关于原子性。Java内存模型会告诉我们哪些基本操作是原子的，比方说普通的变量读写在某些场景下是原子的，但一些复合操作（比如自增操作）就不是，这就需要借助同步机制或者是使用一些原子类，比如AtomicInteger，来保证这些操作在并发条件下正确执行。

还有一个重点是指令重排序的问题。为了提升性能，JVM和编译器会对指令进行重排序，但这种重排序不能破坏原有的程序逻辑。Java内存模型做了限制，确保在同步控制下不会出现乱序的问题。比如说volatile修饰的变量可以防止特定的重排序，保证写操作的顺序性和可见性。

总的来说，Java内存模型给我们定义了一系列关于数据在多个线程间如何“复制”、“同步”的规则，来保证并发程序的正常运行。

java内存泄漏

Java内存泄漏其实不是“内存用了多了”这种简单的情况，而是指那些本来应该被回收的对象，由于某种原因还被引用着，导致垃圾回收器没法回收这些对象。通常引起内存泄漏的原因可以归结为以下几点：

首先，最常见的就是一些长生命周期的对象（比如单例对象或者某些静态对象）持有对短生命周期对象的引用，导致这些本该回收的对象依然留在内存中。如果不小心，就很容易把一些本应该在Activity或者Fragment结束时销毁的资源给挂在那里，长此以往就会积累成泄漏。

其次，还会遇到内部类和匿名类的问题。比如说，一些非静态的内部类会隐式地持有外部类的引用，如果这个内部类的生命周期超出了外部类的生命周期，那么外部类就无法释放，这样也会造成内存泄漏。这在Android开发中尤其容易出现，比如一些回调或者监听器没有及时取消注册。

再者，集合类也是潜在的泄漏点。比如在代码中如果不断往一个List或者Map中添加对象而没有适时地清理，或者对使用过期数据的引用没有及时移除，也会导致内存泄漏。尤其是一些缓存设计，如果没有合理的清理策略，就会把内存占满。

还有一些特殊情况，比如多线程环境中，某个线程意外地长期持有对象引用，或者线程池没能恰当地关闭，导致线程中的数据一直存在，从而带来内存泄漏问题。

HTTPS加密过程

首先，在我们发起一个HTTPS请求的时候，客户端（比如浏览器或者App）会先和服务器建立一个连接，这个连接是通过TCP建立起来的。但在TCP连接建立之后，并不是直接就传输加密数据，而是通过一个叫TLS（传输层安全协议，也就是SSL后继版本）的握手过程来协商安全参数。

在握手阶段，客户端会向服务器发送一个“ClientHello”消息，这个消息里会包括一些加密算法的候选列表，还有一个随机数。服务器收到这个信息后会回复一个“ServerHello”，在里面确定了双方实际使用的加密算法，并且也包含了服务器生成的随机数。

接下来的关键一步是服务器会把自己的数字证书发给客户端，这个证书里面包含了服务器的公钥，由受信任的CA签发。客户端收到证书后，会去验证证书是否真实可信，主要通过验证证书的签名和证书链来确认，这样就确保了我们连接的服务器确实是它声称的那个服务器，而不是别人伪造的。

验证之后，客户端会生成一个预主密钥（Pre-Master Secret），利用之前收到的服务器公钥来加密传输给服务器，确保只有服务器能解密。服务器使用它的私钥解密这个预主密钥。然后客户端和服务器各自根据预主密钥以及交换的随机数，计算出一个对称加密密钥，也就是会话密钥，用来后续的数据传输。

一旦会话密钥双方都明确了，接下来所有传输的数据就采用这种对称加密方式进行加密和解密。对称加密虽然在理论上安全性稍逊于非对称加密，但是加密解密的效率更高，适合大量数据传输。

总的来说，HTTPS采用了一种混合的加密方式：在握手阶段用非对称加密（公钥和私钥）来实现身份验证和安全地协商密钥，然后用对称加密来保护会话期间的数据传输。这样既确保了安全性，也兼顾了性能。

5层协议模型

第一层是物理层，主要负责电信号、光信号这些物理传输方式。比如说，网线、无线电波这些，全部都是物理层在做工作。它只是负责把比特流传输过去，其实并不关心数据的内容。

第二层是数据链路层，这一层主要负责把数据组帧、校验错误，还有一些流量控制。这一层会做错误检测，确保传输过程中如果有误码能够被检测出来，也会处理一些点对点的连接，比如以太网协议就在这一层。

第三层是网络层，这一层最核心的功能就是实现不同网络之间的互联，同时负责数据包的路由和转发。最典型的协议就是IP协议，它会通过地址信息来确定数据包的走向，把数据从一台设备传送到另一台设备。

第四层是传输层，在这层里通常会用到TCP或者UDP。传输层主要负责端到端的通信管理，确保数据传输可靠性（TCP的话）或者追求速度和效率（UDP的话）。TCP的话会有重传、流量控制、拥塞控制这些机制，来保证数据子包按照正确顺序并且完整到达目的地。

最后一层是应用层，这一层直接面向用户和应用，提供具体的服务，比如HTTP、FTP、SMTP等协议，都是在这一层实现的。应用层负责把底层传输过来的数据解析成应用能理解的格式，然后或者反过来，把应用业务数据封装成数据包送到底层传输。

总的来说，这个5层模型从物理传输到最终用户服务，每一层各司其职。这样的分层好处在于，每一层都可以独立进行升级和优化，同时协议和接口也相对固定，方便开发和维护。

IP协议在哪一层

IP 协议主要工作在网络层，这层负责处理数据的路由和转发。简单来说，我们在发送数据时，会先经过物理层把比特流发送出去，然后数据链路层会将这些比特流打包成帧，而IP协议就在网络层负责把这些数据包封装成IP包，并根据目标地址决定数据包从源头到达目的地的路由路径。

在实际的网络通信过程中，IP层主要处理的是逻辑地址（也就是IP地址）的问题，通过查找路由表确定数据包的下一跳，这个机制使得不同网络之间能够互相通信。实际上，网络层的设计让我们的数据能够跨过局域网，经过多个路由器，到达远端的主机。所以，总结来说，IP协议正是在网络层发挥它的作用，保证了数据通信的可靠转发和路由选择。

传输层和网络层可以合并吗

我觉得传输层和网络层虽然在整个传输过程中都是紧密协作的，但从设计角度来看，这两层的角色和责任还是不一样的，所以一般来说是不会合并在一起的。网络层主要负责数据包的路由和寻址，也就是通过 IP 地址来决定数据包经过哪些路由器才能到达目标主机。而传输层则负责端到端的通信管理，比如保证数据的完整性、顺序以及可靠性（像 TCP 就有重传、流量控制、拥塞控制这些机制）。

如果把这两个层级合并，虽然可能会在某些特定场景下减少一点开销，但会带来很多问题。首先，分层设计的优势在于每一层都有清晰的职责，一旦出问题我们也更容易定位和排查错误。其次，各层的设计思路、优化方向和实现难度都不同，合并后会导致代码和设计变得非常复杂，并且灵活性和可扩展性也会受到影响。

总的来说，虽然从理论上或某些专用系统中可以尝试将这些功能合并，但在主流的网络协议设计和实际开发中，保持传输层和网络层的分离能够更好地实现模块化，更容易维护和升级，所以不会合并。这也是为什么我们常见的 TCP/IP 协议栈中，网络层和传输层是两个独立但互相关联的层次。

单例模式的优缺点

单例模式啊，我个人觉得它有很明确的优点，也有不少注意的地方。优点首先就是能确保在整个应用中只存在一个实例，这在一些需要全局共享数据或者资源管理上面就很方便了，比如配置管理、线程池或者数据库连接池这种场景。采用单例模式之后，一方面可以节省内存，因为不会创建多个实例；另一方面还可以确保共享资源的一致性和统一的访问入口，避免了多处各自维护状态的不一致问题。

另外，如果设计得当，还能保证线程安全。而在具体实现上，比如用双重检查锁或者静态内部类的方式，都能保证在并发环境下单例对象能正确初始化，避免了竞争条件。

不过，单例模式也有一些潜在的缺点。首先就是过度使用单例会导致代码之间的耦合度升高，因为很多地方都直接依赖那个单例对象，这样如果以后有需求的变化或者测试的时候就会比较麻烦。再者，单例模式往往需要管理好它的生命周期，如果处理不当可能造成内存泄漏或者资源一直被占用。尤其在一些移动平台上，长生命周期的对象需要谨慎管理。

还有一点，有些人认为单例模式对面向对象的设计原则（比如单一职责、依赖倒置等）是一种违背，因为它隐藏了依赖关系，让测试和扩展变得比较困难，所以出现在一些设计评审中，可能会被拿出来讨论是否滥用单例导致设计僵化。比如在单元测试中，如果依赖了单例对象，就很难进行模拟，进而需要额外的设计和解耦措施。

多线程资源共享

首先，多线程共享资源会面临两个主要问题：数据一致性和数据可见性。数据一致性就是说，当多个线程同时读写同一个变量或者对象时，如果没有适当的同步机制，就会出现数据紊乱或者顺序错乱，最终导致错误的数据状态。比如说，一个线程在写数据，另一个线程正好在读，这时如果没有同步，很有可能读到中间状态的数据，造成逻辑错误。

数据可见性则是指一个线程对共享变量的修改，其他线程能否及时看到。安卓或者Java中，我们可能会遇到一些变量更新后，新线程还是用旧的缓存值来操作，这时就需要依靠同步的手段，比如使用volatile关键字、synchronized关键字，或者Lock来确保当一个线程修改了变量后，其他线程能立刻看到这个变化。

再者，资源共享还涉及到锁竞争和线程安全问题。为了保证线程安全，我们通常会用到锁机制（比如synchronized或ReentrantLock）。这就引出了一个平衡的问题：锁的粒度如果设置太细的话，可以提高并发度，但会增加锁管理和调度的复杂度；反之，如果锁的粒度过粗，虽然实现简单，但会让很多线程都在等待锁，导致性能下降。所以根据实际需求，我们通常需要在性能和安全之间做出一个折中。

另外，还有一些经典的问题，比如死锁。死锁发生在两个或者多个线程在等待彼此释放资源，最终都陷入了等待状态，这种情况需要在设计上尽量避免，或者采用超时机制来降低风险。

OS进程和线程的区别

简单来说，进程可以看作是一个应用程序的实例，它有自己独立的地址空间和资源，比如内存、文件句柄和系统变量。而线程就像是在进程内部的一个执行单元，多个线程共享进程内的内存和资源，但每个线程又有自己的执行堆栈和寄存器状态。

从实际开发的角度讲，使用进程意味着相对隔离的资源管理，这样就能提高安全性，比如每个进程崩溃不会直接影响其他进程。但代价就是进程间通信（IPC）会比较麻烦，而且切换进程相对来说开销更大。

至于线程，就更轻量级一些，在同一个进程内启动多个线程可以并行执行任务，而且线程之间共享进程的内存，通信起来更高效。但是，线程共享资源也意味着必须注意同步问题，否则就容易引发竞争条件和数据不一致的问题。很多时候我们在开发中会细致设计线程之间的访问策略，比如加锁或者使用线程安全的数据结构。

从系统调度角度看，操作系统能够独立调度进程、给它分配内存和系统资源；而线程则是在一个进程内进行调度，更细粒度的执行控制也让多线程并发成为可能，但同时要面对调度开销和一致性保障。

总的来说，我觉得在服务端开发或者桌面应用中，分成多个进程可以更好地隔离风险和提高稳定性；而在一些对并发性能要求较高的场景，比如Android开发中，我们更倾向于使用多线程解决耗时操作与界面流畅间的问题。当然，不论是选择多进程还是多线程，设计时都必须仔细考虑资源共享与通信的代价和风险。

线程间的通信方式

在线程间通信这块，我个人觉得主要有两大类方式：传统的基于共享内存的通信和基于消息传递的通信。下面我来具体说说这两种方式的细节和我在工作中怎么应用的。

首先，基于共享内存的通信，多线程都运行在同一个进程内部，所以它们可以共享一些数据。我们最常用的是利用Java中的对象监视器（也就是通过synchronized关键字）配合wait、notify或者notifyAll这几个方法。比如说，一个线程生产数据后，通过notify唤醒等待的消费者线程，这种经典的生产者消费者场景就是用这个机制实现的。这里比较重要的一点就是，一定要在同步块内操作，因为只有持有同一个监视器锁，才能调用这些方法，而且需要设计好通信逻辑，避免出现死锁或者伪唤醒等问题。另外，还有条件队列这种方式，Java的Lock配合Condition对象也是非常常见的，它在功能上和wait/notify类似，但更灵活，看上去也更清晰一些，因为不同的Condition可以对应不同的等待队列，这样就可以精细控制哪些线程需要被唤醒。

再来说说基于消息传递的方式，这在实际开发中也相当常用。特别是在Android开发里，我们经常使用Handler来实现线程间的通信。Handler机制本质上也是把任务封装为消息，通过消息队列传递，到达目标线程后再进行处理。这样就避免了在多个线程之间直接访问共享数据带来的那些同步问题。除了Handler之外，还有一些基于事件或者Observer模式的实现，比如RxJava这种响应式编程框架也会把数据转换成流，然后在不同线程间传递数据，利用线程切换来实现并发操作。

从使用上来说，选择哪一种方式其实得看具体业务场景。如果是简单的生产者消费者或者任务调度场景，使用synchronized、wait/notify还是挺直接且高效的；但一旦需要更灵活或者对并发要求更高的时候，引入Lock及Condition会更好，毕竟它们能针对不同的情况做更细粒度的控制；而像Android这种界面操作与后台逻辑分离的情况，使用Handler和消息队列更符合设计思路，也能避免线程上下文切换过于频繁带来的性能问题。

总的来说，我觉得线程间通信的核心目的是为了让不同线程协同工作，同时避免僵局和数据不一致等问题。

Java里面怎么控制共享资源

在Java中控制共享资源主要靠几种同步机制来保证线程安全，防止多个线程同时修改同一数据时产生错误。一般来说，我会这么理解和使用：

首先是用synchronized关键字。这是最直接的方式，我们可以把需要访问共享资源的代码块或者方法加上synchronized，确保在同一时刻只有一个线程能执行这些代码，从而防止数据竞争。但这方式有个缺点，就是如果锁的粒度设置过大，会导致线程频繁阻塞，影响性能。

另外一种方式是使用Lock接口，比如ReentrantLock。相比synchronized，Lock提供了更多灵活性，我们可以尝试获取锁、设置超时、甚至支持多个条件变量。这样一来，在复杂场景下比如需要分段解锁或者读写分离的时候就更容易做细粒度控制了。同时，也可以避免一些synchronized可能带来的局限，比如无法中断等待锁的线程。

此外，还有volatile关键字。它不是用来控制并发访问的“锁”，而是确保多个线程对一个变量的读写是一致的。比如一些标志变量，我们会用volatile来声明，这样当某个线程修改这个变量时，其他线程能马上看到变化。不过，volatile不能保证操作的原子性，所以一般用于状态标识而不是复合操作。

在JDK并发包中，还有一些更高级的工具，比如AtomicInteger、AtomicReference这类原子操作类。这些工具利用底层CPU的CAS指令来实现原子性操作，适合在竞争不太激烈的情况下替代锁操作，既保证了线程安全，又能提高性能。

还有一种情况，比如在读多写少的场景，我也会考虑用ReadWriteLock，让多个线程可以同时读共享数据，但写的时候确保只有一个线程写。这样的机制可以提高并发度，又保护了数据不被不恰当修改。

数组和链表的区别

我觉得数组和链表的区别主要在于它们存储数据的方式和各自的操作效率。简单来说，数组是在内存中一块连续的区域中存储数据的，所以我可以通过索引直接访问任意一个元素，这个随机访问速度非常快，也正是数组的优势。但缺点是一旦定义了数组的大小之后，数组的长度就固定了，如果想插入或者删除某个元素，就比较麻烦了，因为可能需要移动后面的所有数据，总体来说操作起来并不是很灵活。

相比之下，链表就采用了节点和指针的结构，它并不是把所有数据放在一块连续的内存中，而是每个元素都有一个指向下一个节点的指针。这个结构使得在插入和删除元素时只需要调整相邻节点的指针，很灵活，效率也不错，特别是在处理频繁的增删操作的时候优势明显。但链表的随机访问就不太方便了，比如说我想访问第10个元素，需要从头开始逐个遍历，性能比较低。所以，链表在读操作上相比数组来说要慢一些，而且每个节点还需要额外存储指针信息，可能会占用更多内存空间。

在实际开发中，比如在Android里面，如果是场景中对数据的读取操作比较多，而且确定数据规模比较固定，我就会倾向于使用数组或者基于数组的集合类；而如果场景中需要频繁地插入、删除数据，可能链表就会更合适一些。总结来说，数组的优势在于随机访问方便和内存紧凑，而链表则在于操作灵活，特别是插入和删除效率更高。选择哪一种主要还是看具体的业务需求和数据操作特性。

application的oncreate 和activity的oncreate有什么区别

首先，application 的 onCreate 是在整个应用程序进程创建的时候被调用的，也就是说它只会被调用一次。通常我们会在这个方法里做一些全局性的初始化工作，比如初始化第三方库、配置全局异常处理或者设置一些共享的资源和状态。这种初始化都只要执行一次，而且它的状态会贯穿整个应用的生命周期，所以对于需要全局作用的东西就很合适放在这里。

而 activity 的 onCreate 则是每个界面（activity）创建时调用的。每个 activity 的 onCreate 中一般都会设置布局、绑定 UI 控件、初始化界面相关的数据。它是针对单个界面进行初始化的，每当用户进入某个界面时，这个方法就会被调用，而当界面被销毁之后，对应的 onCreate 又不会被保留。这种按需初始化就适用于界面级别的处理，比如根据不同的 activity 做各自的初始化逻辑和特定功能设置。

所以，从开发的角度来说，application onCreate 更像是做一些全局、一次性的设置，而 activity onCreate 则是为具体的界面做初始化工作。这样分层也有助于我们更清晰地划分代码，既不会让全局的初始化逻辑混在每个 activity 里，又能保证每个界面在展示之前做好自己需要的准备工作。

一个点击事件结束后是怎么销毁的

在我看来，一个点击事件的结束和销毁其实涉及到事件分发与生命周期管理这两个方面。首先，当用户点击屏幕时，这个动作会被系统捕捉成一个事件对象，类似于 MotionEvent（尽管这里不涉及代码，但你可以理解为这是系统内部会创建的一个事件对象）。这个事件对象会沿着整个View树传递，经过dispatchTouchEvent，逐层传递到最终在我们设置了点击监听器的那个控件（比如Button）上。在这个过程中，事件对象充当了一个临时的数据载体，它包含了点击的位置、时间、行为等信息。

一旦这个点击事件被目标控件的onTouchEvent或者onClickListener消费了，也就是说活动或者控件已经处理了这个点击事件，这个事件就在逻辑上完成了它的使命。这里“销毁”更多的是指这个事件对象不再被引用，没有更多地方需要去处理、存储或者修改这个事件，它的内存会等待垃圾回收器回收。通常系统会自动管理这些短生命周期的对象。一旦它超出了作用范围，并且没有被任何引用持有，它就成为了垃圾回收的候选对象。

另外，很多时候我们关注的不是事件本身的销毁，而是响应事件的回调生命周期。当点击事件触发后，相关回调，比如 onClick，会在主线程上被触发执行，等到逻辑执行完成之后，也就不再持有对这个事件对象的引用。这个过程其实很迅速，也基本上是透明的，对我们来说主要是设置好监听，等着回调发生就行了。

总的来说，点击事件在完成分发和回调调用后，只要没有其他的引用指向这个事件对象，垃圾回收机制就会在合适的时机把它销毁。也就是说，从开发者的角度来说，我们并不需要去手动销毁这个事件；整个生命周期管理都是由系统自动处理的，这也体现了Java和Android框架设计中的内存管理和对象生命周期自动管理的优点。

Looper的睡眠机制对应linux的哪个操作

Android中Looper在没有消息时进入睡眠状态，这个机制其实主要是在底层调用了Linux的poll系统调用。简单点说，当Looper发现队列里没有立即要处理的消息，它会调用类似ALooper_pollOnce这样的native方法，而这个方法底层就会用poll来进行阻塞等待。也就是说，poll这个系统调用会让线程进入休眠状态，等待文件描述符上的事件，当有事件发生或者达到超时时间的时候，才会把线程唤醒继续执行后续代码。

我觉得这种设计主要是为了提高效率和降低CPU消耗，在没有事情做的时候，不需要不断地轮询消息队列，而是等到有新的事件进来时再处理。所以，从Linux的角度来看，Looper的睡眠与唤醒其实就是依赖于poll系统调用来实现的。

poll 是 Linux 系统中用于多路复用 I/O的一种系统调用（System Call），它的主要作用是监视多个文件描述符（File Descriptor，简称 FD），以便在这些文件描述符上有事件（如可读、可写、异常）发生时通知应用程序进行处理。

Looper最多能开几个线程

首先，每个线程里面只能有一个Looper，也就是说如果我们想让线程能够通过消息队列的方式处理消息，就得在那个线程里调用 Looper.prepare()，然后启动消息循环。而一个线程在这一过程中只能绑定一个Looper，所以“Looper最多能开几个线程”实际上并不是指Looper能开几个线程，而是说每个线程只能有一个Looper。

从整体来说，Android中没有硬性限制最多能创建多少个线程——实际上，可以通过系统资源的限制来决定你能开多少个线程，而每个需要消息处理的线程都可以创建一个自己的Looper。就是说，从理论上来说，只要系统资源允许，你就可以创建很多线程，每个线程都可以有一个Looper。然而，现实中我们通常不会这么做，因为线程的创建会带来资源开销和调度压力，多线程之间的竞争会影响应用性能，如果线程太多，内存压力和CPU切换开销都会变得非常大。

所以总结下来，Looper本身并没有规定一个上限，而是由每个线程只能拥有一个Looper这个设计决定了你需要为每个需要消息循环的线程单独创建。如果你的应用程序创建的线程数超过了系统能承受的范围，那么就会受到系统资源限制。平时在开发中，我们会比较慎重地设计线程和消息队列，尽量复用已有的机制，比如HandlerThread或者使用线程池，而不是盲目地创建大量带Looper的线程。

从面试的角度看，我会强调：Looper的设计不是为了无限扩展，而是提供一种在单个线程内处理消息的机制，实际中能创建多少个就取决于系统资源和合理的架构设计。

上下滑动和左右滑动事件的冲突如何处理

我觉得处理上下滑和左右滑的冲突，其实就是要判断用户手势的意图到底是要滚动列表还是滑动页面，核心思路就是在事件分发过程中判断手势的方向，然后有针对性地拦截或者让下层控件消费事件。

通常我们会在onInterceptTouchEvent或者dispatchTouchEvent里做这个判断：当用户手指刚刚按下或者稍微滑动时，我们先记录下初始的位置和位移，然后通过计算水平和垂直方向位移的比例来判断到底用户是偏向于上下滑动还是左右滑动。如果水平位移远大于垂直位移说明是想横向滑动，那么我们就让相应的容器（比如ViewPager之类的）接管事件，而如果垂直位移占优势，那就交给ListView或者RecyclerView来处理。

在实际处理时，有时候我们也会遇到一些复杂场景，比如某些子View既支持横向滑动又支持一定的垂直拖拽，这时候需要细致调整拦截的时机和范围。我一般会根据实际效果调整判断条件，比如增加一个角度判断或者阈值，以过滤一些猛然滑动或者滑动方向不明确的情况。还有一种做法就是在子View里主动调用requestDisallowInterceptTouchEvent来通知父View不要拦截，这样就能保证子控件能接收到完整的事件序列。

总的来说，这个冲突的处理关键在于在手势刚刚开始的时候就判断清楚用户真正想要的方向，然后合理分配事件的消费逻辑。这样既能避免上下滑带来的卡顿，也能让左右滑动的体验流畅。对我来说，重点是不断调试这些阈值和判断策略，保证在不同场景下都能达到比较自然的交互效果。

RecyclerVIew了解吗

我觉得 RecyclerView 是 Android 开发中的一个非常灵活且高效的控件，主要用来显示长列表或网格数据。相比 ListView，它的优势在于更好的性能和更高的可扩展性。在使用 RecyclerView 的时候，我经常会想到几个重点：

首先是它的 ViewHolder 模式。RecyclerView 强制使用 ViewHolder 来缓存 item 的子视图，这样能大大减少 findViewById 的频繁调用，提高列表滑动时的流畅度。另外，因为 RecyclerView 的 ViewHolder 是强制性的，所以开发者在设计 item 布局的时候就能更有目的地将控件缓存好。

其次，RecyclerView 的布局管理器（LayoutManager）也是一个亮点。它不仅支持线性布局（Vertical 或 Horizontal），还支持网格布局甚至瀑布流布局。这个设计让 RecyclerView 可以适应各种不同的布局场景，并且还能自定义，比如自己实现一个特殊的布局管理器来满足更复杂的需求。

再一个是 RecyclerView 的动画处理和 ItemDecoration。系统提供了默认的动画效果，当我们增删数据时，RecyclerView 会自动用动画展示这些变化。当然，我们也可以自定义动画效果，甚至通过 ItemDecoration 来增加一些分割线、间距或者其他装饰效果，让界面看起来更精致。

总体来说，我觉得 RecyclerView 的设计思路体现了 Android 对性能优化和灵活性的追求。它的回收复用机制使得对大数据集的展示非常高效，同时通过扩展接口和自定义组件，让实现复杂列表变得非常便捷。

它是如何复用视图的

在RecyclerView里，系统不会为每个数据项都反复创建全新的视图，而是通过一种叫做ViewHolder的模式来复用那些已经创建过的视图。

具体来说，当你滚动列表时，屏幕上那些已经离开显示区域的item就不会被销毁，而是被放进一个回收池里面。当有新的数据需要显示时，RecyclerView就会先从这个回收池中拿出一个可用的item，然后把数据绑定上去，这样就避免了反复的布局加载和控件实例化。这个过程主要分为两步：一是创建，当没有可用的视图时，才调用适配器里的创建方法；二是绑定，每次需要展示时都会调用绑定方法来刷新内容。

这种设计思路让我觉得非常高效，特别是在数据量比较大的场景下，它能大大减少内存的频繁分配和GC。整个过程完全由RecyclerView和LayoutManager来管理，我们只需要关心数据的绑定就行，剩下的视图回收和复用逻辑都交给系统去处理了。总的来说，这种视图复用机制让我在开发过程中获得很好的用户体验，同时也能保持性能上的稳定。

讲讲Ibinder

IBinder是Android中一个非常核心的接口，它主要用于进程间通信，也就是IPC。简单来说，IBinder就像是一座桥梁，连接了不同进程之间的数据交换和调用。当我们需要让一个服务可以跨进程被调用时，IBinder就会发挥作用。

首先，IBinder的设计理念就是让跨进程的调用变得类似于本地方法调用。Android采用了AIDL（Android Interface Definition Language）来定义接口，编译之后生成的Stub和Proxy其实都是基于IBinder来进行操作的。从一个角度上来说，服务端实现了IBinder接口，然后把它传递给客户端。客户端通过这个IBinder对象就能调用服务端的方法，就像是本地方法调用一样，只不过底层实际是通过Binder机制来完成的。

另外，IBinder除了在IPC时进行数据传递外，它还能帮你管理连接，例如绑定和解绑服务。通过这个机制，系统还可以确保当一个进程崩溃或者退出时，所有使用到该IBinder对象的资源都能被正确回收，这就大大减少了资源泄漏的风险。对于我来讲，理解这一点非常关键，因为它不仅仅是一个通信接口，更是一种保证进程间安全和稳定性的机制。

此外，Binder机制相对于传统的Socket和其他IPC机制，它的设计非常高效，不仅能高效地序列化数据，还采用了共享内存与消息队列的方式以降低系统调用的频率，从而提高性能。这也是为什么我们看到Binder在Android中被广泛使用，比如系统服务、ActivityManager、窗口管理等各个角度都会涉及到IBinder的使用。

activity和fragment之间怎么通信

“其实Activity和Fragment之间的通信主要有几种方式，关键在于让它们之间保持一定的解耦，既能灵活应对需求，又不会把两者紧紧耦合在一起。首先可以想到的一种方式是，通过Activity作为中介，因为Fragment本身不应该直接与其他Fragment通信。通常我们在Fragment里可以通过接口回调的方式，把事件传递给Activity，然后让Activity再去通知另一个Fragment，这样做其实是基于解耦的设计思想。我可以举例说明，我在以前的项目中，就是在Fragment中定义了一个接口，然后Activity实现这个接口，这样Fragment内部的某个点击事件或者操作触发接口回调，Activity自然就能抓住这个事件，然后根据情况去调用另一个Fragment的方法或者直接进行数据交换。

另外，随着Android架构的发展，现在我们更多使用共享ViewModel的方法进行通信。通过架构组件中的ViewModel，再配合LiveData或者StateFlow这种响应式的数据类型，Activity和Fragment可以共享同一个ViewModel数据，这样，一个Fragment发生变化以后，另一个Fragment订阅到数据变化，然后做出响应。这里的好处就是，不需要硬编码接口，代码结构也变得更加干净，更符合单一职责和解耦的原则。

还有一种方式可能会在简单场景下使用，就是通过FragmentManager直接通过传递Bundle参数，这种方式一般用于第一次加载Fragment时传递一些初始化数据，但是这种方法相对比较局限，只适合初始化时的传递，而不是实时的双向或多向通信。

其实我觉得所有这些方式都各有特点，具体选哪种方式取决于项目的需求和团队的技术架构。比如，我在一些较为简单的用例中，会选择直接回调接口，这样比较直观，而且Android官方也推荐这种方式。而在需要跨多个Fragment，甚至Activity和Fragment之间需要长期保持数据同步时，我更倾向于使用ViewModel和LiveData的方式，因为这样可以降低出现内存泄露和耦合过高的风险，而且能更好地响应生命周期，在配置变更时还能避免重建数据传递的困扰。

进程切换开销为什么打（从操作系统的层面讲讲）

“从操作系统的角度来说，进程切换开销之所以大，主要是因为进程之间是完全隔离的，每个进程都有自己独立的地址空间和所有的资源。这就意味着，当发生进程切换的时候，内核必须做很多额外的工作来保存和恢复上下文状态。

首先，进程切换的时候，需要保存当前进程的寄存器状态，包括程序计数器、栈指针、通用寄存器等等，这些信息必须在切出去的时候保存下来，以便下次切回时能继续执行。然后，操作系统还要加载下一个进程的寄存器状态，这个过程本身就需要一定的时间。

另外，由于每个进程都有独立的虚拟内存地址空间，切换进程还涉及到切换页表和更新 CPU 的内存管理单元（MMU）。这通常会导致TLB（Translation Lookaside Buffer，即地址转换高速缓存）的缓存失效，迫使处理器重新加载页表信息，而这也是个昂贵的操作，因为会导致更多的缓存未命中。

还有一个很关键的点是，进程切换会从用户态转到内核态，再从内核态返回到用户态。这个模式切换（也就是上下文切换的核心之一）会带来一定的软件和硬件开销。整个过程中，操作系统的调度器需要确定哪个进程下一个获得CPU，这个调度决策过程本身也需要时间。

最后，还涉及到对系统资源的保护和隔离，确保进程间互不干扰。比如，很多进程间的数据和资源的切换，还需要额外的硬件指令保证各个进程的信息不会被混淆。这些都是确保系统稳定性和安全性需要的开销。

简单总结就是，进程切换不仅仅是简单的保存和恢复寄存器，更牵涉到整个内存管理、缓存刷新、用户态与内核态之间的跨越，以及调度器的工作。相比之下，同一进程内的线程切换，因为共享地址空间和大部分资源，所以开销会明显小很多。”

现在的操作系统的调度方式用的是哪种

现在操作系统的调度方式其实主要是抢占式调度，也可以说是基于时间片和优先级的多任务处理方式。以Android来说，因为它使用Linux内核，所以它的调度基本上就是Linux的调度策略。

具体来说，现代操作系统很少再用那种非抢占式的调度方式，而是普遍采用抢占式调度，这就是当一个任务运行时间过长或者有更高优先级的任务出现时，系统会把正在运行的任务挂起，然后把CPU分配给其他任务。Linux内核里面，目前比较主流的就是“完全公平调度器”（CFS）。这个调度器通过比较每个任务实际获得的CPU时间（或者说虚拟运行时间）来保证每个任务都能得到公平的CPU分配，这样就不会出现有些任务长期得不到CPU资源的情况。

另一方面，操作系统也不是单一只用一种策略，它往往会结合多层次的调度，比如说先区分实时任务和普通任务。实时任务会用一些专门的调度策略，比如FIFO或者轮转方式（SCHED_FIFO和SCHED_RR）来确保那些对时间要求特别敏感的任务能够及时响应。而普通任务则由CFS来调度，保证整体的公平性和系统响应速度。

再者，现在的操作系统在多核、多CPU的环境下，还会做负载均衡调度，也就是在多个CPU核心之间动态地将任务分配，确保每个CPU的负载是比较均衡的。这样做的目的是在多核系统中达到更高的并发性能。

总体来说，我觉得现在的调度方式就是以抢占式调度为主，配合公平调度机制和实时调度保证特殊应用需要，再加上多核的负载均衡。这种设计既能保证系统整体的响应和效率，又能够满足实时任务的特殊要求

优先级调度有什么区别

“优先级调度其实主要就是根据任务的优先级来决定哪个任务先执行、哪个后执行。也就是说，不同的线程或进程会有不同的优先级，系统调度器会优先把CPU让给优先级高的任务。

其实这个调度方式跟我们常说的时间片轮转调度不一样。时间片轮转调度主要就是每个任务分到固定的时间片，然后轮流执行，比较公平。但优先级调度就不一样了，主要还是为了满足一些任务对响应时间或者处理速度有严格要求，像实时任务就需要更高的优先级，保证它们不会因为等待而延迟。

具体地说，有两个方面的区别。第一，静态优先级和动态优先级。静态优先级就是在任务创建的时候就设定好优先级，之后不变。不过很多系统为了防止低优先级任务一直饿死，会引入优先级老化机制，也就是动态调整任务的优先级，使得长时间得不到处理的任务优先级会逐渐提高。第二，在实际的调度中，高优先级任务通常能够抢占低优先级任务的CPU资源。比如在Linux内核里面，就有实时调度策略（比如SCHED_FIFO、SCHED_RR）针对实时任务，而其余大部分任务则用的是CFS（完全公平调度器），这个调度器内部会用虚拟运行时间来动态分配CPU，这种设计确保了即使设置了优先级，但长时间没运行的低优先级任务，系统也会做出一定的平衡。

对于我们开发者来说，如果通过setPriority()这种接口调整线程优先级，一般来说，我们能做的其实只是在应用层给线程一些提示，但最终调度还是要依赖操作系统底层调度器的策略。比如说，在Android中，由于Android运行的是Linux内核，所以调度基本上也是靠内核来管理的，高优先级的线程在抢占上面自然比低优先级线程更占优势。但实际效果往往也需要看任务的实际运行情况和负载情况。

所以，总的来说，优先级调度区别主要在于它优先保证高优先级任务的及时执行，而不是依次按照固定时间片来调度。这样设计的初衷就是为了在多任务的环境下，能满足某些关键任务的及时响应需要，同时又通过一些动态调整机制来防止低优先级任务长期挂起，从而达到一个相对平衡的状态。”

方法A调用方法B，在操作系统或者JVM层面发生了什么，然后方法B的返回值是保存在哪里的

“当一个方法A调用方法B时，从JVM的角度来看，会发生很多隐蔽但很重要的一系列动作。首先，JVM会为方法B创建一个新的栈帧，也就是说，在调用方法B时，系统会把传递的参数、局部变量、返回地址等信息放在新的栈帧中，这个栈帧位于当前线程的调用栈（Stack）中。JVM采用的是基于栈的数据结构来管理方法调用，所以每调用一次新方法，就会在栈上压入一个新的栈帧，而方法执行完毕就会弹出该栈帧。

从操作系统层面上，看待这一过程其实有点不同。一般来说，方法之间的调用是一种用户态的操作，不会触发任何进程切换或者内核态与用户态的切换。操作系统在这时只会关注整个线程的执行，当线程切换时（比如因为时间片耗尽或者有更高优先级的任务），OS才会介入。但在方法调用的过程中，主要是JVM管理栈帧和执行指令的细粒度操作，并不涉及系统的上下文切换。

继续说到返回值。当方法B执行完毕以后，返回值就会被放到相应的栈帧中，具体来说，会被放在JVM操作时的操作数栈上，或特定的寄存器中，这取决于JVM内部如何实现这个细节。之后，栈帧被销毁，返回值会传递给方法A，也就是调用者之后会把这个返回值从栈或者寄存器中取出来使用。简单来说，就是：返回值在方法B结束前被放在返回槽（返回值的这个存放区域里）或者称为操作数栈，当方法B退出后，这个值被直接传递到调用方法的栈帧中。

这种设计确保了方法间的调用是高效和内存管理上很轻量的。每个方法调用都只是对调用栈进行一次压栈和弹栈操作，所有这一切都是在同一个线程内完成的，不会导致跨进程的昂贵的切换操作。

此外，JVM的即时编译器（JIT）可能会通过内联（Inlining）优化避免方法调用的真正存在，直接将方法代码嵌入调用者，从而减少这些栈帧管理的开销，但这属于运行时的优化策略，不改变整个调用的基本原理。”

TCP三次握手知道吧，然后发送的第一个带有数据的包是第几个包，然后为什么

“其实关于TCP三次握手，我认为关键是理解每个包在握手中的作用。通常我们说的三次握手是这样的：第一包是客户端发送的SYN，第二包是服务端回复的SYN+ACK，第三包是客户端发送的ACK。至于第一个能带有数据的包，实际上是在第三次握手的时候。我的解释是这样的：在三次握手中，第一和第二包都是专门用于建立连接的，主要关注的是同步双方的初始序列号和状态确认。等到第三包发出，也就是ACK包，连接就正式建立了。根据TCP协议的设计，在这个ACK包中其实是允许携带数据的，这也是一种优化手段，叫做“piggybacking”，目的是减少一次单独发送数据的呼叫和网络包的数量。所以，在理论上，第一个带有应用层数据的包就是第三个包，也就是那个带有ACK的包，客户端在确认服务端的SYN后，如果马上有数据要发送，它就可以把数据附带在ACK里一并发送出去。

值得一提的是，虽然协议允许在第三个包中携带数据，但在实际情况中，由于实现和各种操作系统网络栈的优化策略，有些系统可能会把第三包保持得尽可能简单，仅作为连接确认，然后后续再发专门的数据包。所以这也是一个实现细节的问题，但从协议角度来说，第一个可以携带数据的包就是第三个包，因为它既完成了连接的建立，同时又具备发送数据的条件，这样做实际上可以降低延迟，提高传输效率。”

滑动窗口知道吧，然后滑动窗口的过程，窗口大小是怎么变化的

“TCP的滑动窗口主要是用来进行流量控制，确保发送方不会以超出接收方处理能力的速度发送数据，同时也用来辅助实现拥塞控制。这个窗口本身是一个动态调整的概念，意味着它在整个数据传输过程中会根据网络状况和双方的处理能力不断变化。

基本上，一开始发送方和接收方会协商一个固定值作为初始窗口大小，也就是接收窗口大小，这个值表示接收方还能接受多少字节的数据。然后，在数据传输过程中，发送方会一直保持一个未应答数据的集合在这个窗口内。当发送方发送了窗口内所有允许的数据之后，它就得等到收到对部分数据的确认（ACK），这样才能将窗口向前滑动，也就是腾出一部分空间允许发送新的数据。

窗口大小变化的关键在于两方面，一是流量控制，二是拥塞控制。流量控制主要是根据接收方当前的缓冲能力调整，比如接收方会在每个包的ACK中告诉发送方它还能接受多少数据。在这种情况下，窗口大小就直接反映了接收方的缓冲区可用空间。如果网络状况良好且接收方有足够的缓冲，窗口就能保持一个较大值，从而提高数据传输率。

而拥塞控制是发送方为了避免网络拥堵引入的一套算法，比如慢启动、拥塞避免、快速重传和快速恢复。刚开始通常处于慢启动阶段，发送方一开始会设置一个比较小的拥塞窗口，然后每经过一个往返时间就会指数增长，直到达到一个阈值。达到阈值后，拥塞窗口就会转变为线性增长，也就是每个往返时间增幅较小，这样可以避免网络过载。如果在传输过程中检测到丢包或者延时急剧增加，这就被认为网络已经拥塞，此时拥塞窗口就会被大幅度减小（通常减半），然后再以较慢的速度增长。这种调整让整个窗口大小动态地反映了当前网络的状况。

在这个过程中，可以把滑动窗口看作是一种平衡措施，一方面利用所有可用的网络资源，一方面又避免网络过载。发送方的窗口由两部分共同决定：一部分是由接收方通告的窗口大小（反映接收方缓冲能力），另一部分则是由拥塞控制算法管理的拥塞窗口。实际上传输中，发送方采用的是这两个中的最小值作为实际的发送窗口大小。

总结来说，TCP的滑动窗口机制不仅帮助不断推进数据传输，通过左边的ACK确认腾出空间，同时右边的数据不断加入，让整个窗口不断向前滑动。在这个过程中，窗口的大小是动态变化的——初始阶段快速增长，然后在网络状况好时稳定增大，在遇到问题时迅速收缩，之后再缓慢恢复增长。这样既保证了高效的数据传输，又能很快响应网络拥塞或其他异常情况，确保通信的整体稳定性和可靠性。”

Java类加载机制是如何实现的，如果自定义一个String类，会怎么加载？自定义的String类会加载成功吗？

“Java的类加载机制其实挺巧妙的，它主要依赖于类加载器来把.class文件加载到JVM中，然后按照双亲委派模型去加载类。整个过程大体上分成加载、链接（验证、准备、解析）和初始化这三个阶段。简单来说，就是当你第一次用到一个类时，JVM会检查这个类有没有被加载过，如果没有就开始加载，这个加载过程要通过类加载器，比如启动类加载器、扩展类加载器和应用类加载器，按照双亲委派的思路，先让父加载器试着加载，如果找不到再由子加载器加载，从而保证核心类库不会被随意替换。

那么比如你自定义一个String类，假设你写了一个跟java.lang.String同名的类，问题就来了，因为核心类库里已经存在了java.lang.String，而且这个类是由启动类加载器加载的。双亲委派模型规定了，任何加载java.lang包的类都是由启动类加载器加载，这个加载器会首先尝试加载核心库里面的类，结果是登录安全、稳定。自定义的String类，往往会被其他类加载器，比如应用类加载器所加载，但实际上在使用过程中，JVM会首先从父加载器那儿找到java.lang.String，所以你的自定义的String类实际上会被忽略。

具体来说，如果你真的在你的项目中写一个java.lang.String，那么在编译期间会成功生成class文件，但是一旦运行时加载过程就会出现问题，很有可能不会加载你这个类，因为JVM所用的双亲委派机制会优先从引导类加载器加载核心库的String类。也就是说，自定义的String类基本上是加载不进来的，或者说即使加载了，也不会被正确引用，因为所有对String的引用都会指向已经存在的系统核心库中的那个String。

讲讲注解  ，好了对你刚提到的注解有哪些是编译时那些是运行时的，哪些是通过反射实现的呢？

“注解其实就是在代码里加入一些元数据，告诉编译器或者运行时环境怎么处理对应的代码。简单来说，根据注解的 Retention 策略，可以分为三种主要情况。

第一类是 SOURCE 级别的注解，这类注解只在源码阶段存在，编译时会被丢弃，不会出现在 .class 文件中。比如你常见的 @Override 注解，它主要是告诉编译器你打算重写一个方法，帮助编译器检查，但最终并不会用到它。

第二类是 CLASS 级别的注解，这些注解会编译进 class 文件中，但是在运行时通过反射是拿不到的。也就是说，编译后的字节码里保存了这些注解的信息，但 JVM 加载时不会保留给运行时用，所以这类注解主要是为了编译期或者工具处理。

第三类就是 RUNTIME 级别的注解，顾名思义，这类注解在运行时仍然存在，可以通过反射来获取和解析它们。很多框架都依赖于这种注解，比如依赖注入、AOP、注解驱动的路由或者 ORM 框架等，它们在运行时根据反射拿到具体的注解，然后执行相应的逻辑。

总的来说，具体哪些注解是编译时处理的，哪些是运行时处理的，就看它在定义时的 Retention 策略。如果你写一个注解时加了 @Retention(RetentionPolicy.RUNTIME)，那这注解就是在运行时有效的，可以用反射拿出来做处理；如果是 RetentionPolicy.CLASS，那注解只存放在class文件里，但反射时拿不到；而 RetentionPolicy.SOURCE 则根本只在源码中存在，编译完就消失了。

所以在实际开发中，我们就要根据用途选择正确的 Retention 策略。例如，有的注解只是辅助编译检查，就没必要在运行时保留，而像依赖注入、路由这类就必须在运行时生效，就需要 RetentionPolicy.RUNTIME。所以，注解通过反射实现的，多半就是那些运行时注解。”

泛型机制讲解一下

“泛型机制其实在Java和Kotlin中都是用来解决代码复用和类型安全的问题。以前我们如果写集合之类的代码，经常会用Object，然后还得做大量的类型转换，既容易出错也不够优雅。有了泛型，我们就可以在编译期就指定集合中存放的元素类型，确保数据类型正确，这样也能避免在运行时出现ClassCastException的问题。

从实现机制上来说，以Java为例，泛型是通过一个叫‘类型擦除’的技术来实现的。编译器在编译的时候会用实际传入的类型来替换泛型参数，然后在生成class文件的时候，将这些泛型信息擦除掉，换成Object或者它们的边界。这样做一方面保证了向下兼容，以前写的代码都可以继续运行；另一方面也意味着在运行时，我们无法获取到具体的泛型类型信息，比如你写了List<String>其实在运行时只是在操作List。所以很多场景下，我们不能像C++那样做真正的泛型实例化，而只能在编译期进行类型检查。

除了类型擦除，还有一点需要注意，就是泛型的上界和下界限制（比如通配符？extends和? super），这些都是为了让我们在泛型类或方法中能够灵活的控制类型的范围，从而做到既灵活又保证类型安全。对于很多库，比如在Android开发中广泛使用的RXJava或者LiveData，这些都大量使用了泛型来保证数据流转的正确类型，从而减少运行时出错的可能性。

另外，对于Kotlin来说，它对泛型做了一些改进，比如引入了声明处型变（in/out）和星投影这些概念，并且在某些情况下允许使用内联函数和reified类型参数来做一些在Java中没办法实现的操作。这样在Kotlin中我们能在运行时获取泛型类型信息（通过reified关键字），这又打开了另一个优化的可能性。

所以总结来说，泛型机制就是利用编译时的类型检查和编译器的类型擦除机制，既能让我们写出灵活、复用性高、类型安全的代码，又保证了与旧版本Java类库的兼容性。

讲讲Koltin扩展函数

“关于Kotlin的扩展函数，其实就是一种在不改变已有类源码的情况下，为类增加新的功能的方法，可以看成是对类的一种‘补充’。举个简单的例子，假设我们有一个类或者说是一个无法修改的第三方类，我们就可以为它写一个扩展函数，让这个类看上去就像自带了某个功能。

扩展函数底层其实不是直接修改类，而是在编译时会将它转化为静态方法。举个例子，你写了一个String类型的扩展函数，编译后会生成一个静态方法，这个方法第一个参数就是原先的String对象。所以它本质上还是一个静态方法，只不过在语法糖的帮助下，看起来特别像是对对象的方法调用。这不仅保持了代码的整洁，还达到了增强已有类功能的效果。

另外，扩展函数本身遵循静态解析的规则，也就是说，它不是真正意义上的‘添加到对象上’，而是在编译阶段通过静态分发来调用的。如果类里面已经有了同名、同参数的成员方法，那么会优先调用类中已有的方法。所以这也是在使用扩展函数时需要注意的一点。

扩展函数的好处是明显的。它能增强代码可读性和可维护性，让你不用去继承或者修改原有类，就能根据需求扩展功能。这在Android开发中就非常实用，因为我们有大量第三方库或者系统类，我们有时候都希望能在不破坏原有代码的基础上，为它们添加一些定制化的方法；比如对View进行扩展，可以写个扩展函数来处理常见的点击事件或者动画效果，这样就显得代码非常清晰。

最后值得提的还包括，Kotlin不仅支持扩展函数，还支持扩展属性，不过扩展属性不会有真实的字段，它只是通过get/set方法来操作。所以在实际的开发中，看场景合理使用扩展函数可以让代码更简洁、更直观，但同时也要注意，扩展函数是静态解析的，不支持动态多态，不能作为依赖多态调用的那种方式去设计。

Java面向对象体现在哪些方面

首先是封装性。封装性就是把数据和操作数据的方法整合到一个类中，同时通过访问修饰符（public、private、protected）来控制数据的访问权限，这样就保证了数据的完整性和安全性。例如，你在设计一个类的时候，会把一些对外不需要公开的属性设为private，只对外暴露必要的方法，这样客户端就不能随意更改对象内部的状态。

其次是继承性。继承能够让我们通过已有的类创建新的类，从而达到代码复用，同时也便于构建层次化的类体系。在Java中，你可以通过继承父类来获取父类已经实现的功能，同时可以重写一些方法来提供特定的行为，这也是程序设计中一种重要的抽象设计手段。

再一个就是多态性。多态性允许一个父类的引用指向子类的对象，这样在调用方法时能根据实际对象的类型来执行对应的方法实现。多态不仅体现在方法重写，还可以通过接口来实现，这使得程序具有更好的扩展性和灵活性。比如你可能写一个方法接收一个接口作为参数，而具体传入的对象可以是任何实现这个接口的类，这样就能在运行时根据实际类型调用正确的实现。

当然还有抽象性。抽象性主要体现为抽象类和接口的使用。这两种机制让我们可以定义一组行为的规范，不依赖于具体的实现细节，使得设计更加清晰和模块化。抽象类可以封装一些通用的操作，而接口则更关注规定方法签名，以便多个不相关的类可以实现同一套行为。

此外，Java中还有很多面向对象的设计原则，比如“单一职责”、“里氏替换”等，这些原则都是在长期实践中总结出来的。它们不仅帮助我们理解面向对象思想，而且在实际开发中也能有效提高代码的可维护性、扩展性和复用性。

GC机制

“GC，即垃圾回收机制，在Java虚拟机中非常重要，因为它主要负责自动管理内存，回收那些不再使用的对象，避免程序手动释放内存可能出现的错误。讲得简单点就是，GC帮我们去找那些‘没人要’的对象，然后把它们占用的内存收回来给程序继续使用。

首先，GC机制采用的是分代收集策略，一般会把堆内存划分成新生代和老年代。新生代里面对象的生命周期通常比较短，我们大部分对象在创建后很快就变得不再被引用。所以新生代的垃圾回收比较频繁，采用的是复制算法，把对象从Eden区复制到Survivor区，如果对象在新生代经过多次GC还能存活，就会晋升到老年代。而老年代里对象的存活时间比较长，所以垃圾回收的频率相对低，通常采用标记-清除或标记-整理的算法来回收内存。

另外，GC在运行时会触发‘Stop-The-World’，也就是暂停其它线程进行回收工作。这个停顿时间肯定会影响到应用的响应速度，所以不同的垃圾回收器，比如CMS、G1、ZGC等都是为了在不同的应用场景下平衡吞吐量和延迟，尽量缩短这个暂停时间。

还有一点需要讲的是，GC也不是全自动万能的，它有各种参数可以调优，比如堆大小、垃圾收集器的策略等。作为开发者，我们并不需要关心内存何时回收，但了解这些机制可以帮助我们写出更高效的代码，减少内存泄漏或大对象频繁分配造成的GC压力。

总体来说，GC机制通过不断扫描对象的引用关系，自动识别哪些内存空间可以被重复利用，从而减少了因为手动释放内存而引发的各种bug，同时也提高了系统的稳定性。不过它也会带来一些性能上的停顿问题，所以优化和选择合适的垃圾回收器也是实际开发中需要考虑的一个方面。”

讲讲内存泄漏

“内存泄漏其实是指程序中本应该释放的内存由于某些原因没有被释放，导致内存占用不断增加，长时间运行下来可能会引发应用崩溃或者系统性能下降。在Java或者Kotlin这些使用自动垃圾回收的语言中，我们更多是由于程序设计上的问题导致一些对象的生命周期被不恰当地延长，从而无法被GC回收，而不是像C/C++那样需要手动free内存。

举个例子，内存泄漏在Android中比较常见，比如说你在Activity里面注册了一些监听器、或者启动了一些耗时的后台任务，但是在Activity销毁的时候没有正确地解绑或者取消这些任务。这时候，这些对象还持有Activity的引用，导致整个Activity和它的资源不能被GC回收。再比如静态变量持有了Context或View的引用，也会造成长时间的内存泄漏，进而导致整个应用的内存占用不断攀升。

从底层的工作原理来看，其实垃圾回收器是根据对象之间的引用关系来决定哪些对象可以被回收的。所以只要有无意间的引用链存在，就会导致那些本来可以释放的对象依然处于‘活跃’状态，进而形成内存泄漏。这种泄漏不是直接因为内存分配失败，而是因为某些对象本应该被清理却一直占据内存，累积下来就会造成问题。

在实际开发中，我们通常会通过一些工具，比如Android Studio自带的LeakCanary或者其他性能监控工具，来检测和定位这些内存泄漏的问题。除此之外，开发者也需要在代码设计上规避这类现象，比如尽量使用Application Context代替Activity Context（在生命周期要求不是特别严格的情况下），及时注销回调、监听器，避免使用内存敏感的静态变量等。关键是要时刻关注对象的生命周期管理，确保不必要的引用能够及时断开，这样才能让垃圾回收器正常工作，保证应用的稳定和内存使用的高效。”

Activity和Handler如果没有正确处理，然后发生GC的时候谁会泄露

“其实这个问题核心在于Activity和Handler之间隐藏的引用关系。很多人不知道，其实当我们在Activity中创建Handler，如果我们没有正确处理，就容易导致内存泄漏。主要原因是，Handler常常作为内部类存在的话，它默认会持有外部Activity的引用。如果Activity销毁了，但是Handler队列中还有没处理完的消息或者任务，这时即使GC运行了，因为Handler内部仍然持有对Activity的引用，就会导致Activity无法被回收，从而发生内存泄漏。

所以说，在这种情况下，真正泄漏的是Activity。也就是说，如果没正确处理Handler里的消息队列，比如在onDestroy中没有移除所有的消息、回调或者使用静态内部类加弱引用的做法，那么当GC发生时，Activity就因为被Handler阻止而泄漏。这样的设计泄漏情况，往往隐藏得比较深，进而引起一些难以发现的问题，比如App长时间运行后内存不断攀升。

总结来说，关键在于当不正确管理Handler时，它会无意中持有Activity的引用，从而使得Activity对象无法被GC清理，最终导致内存泄漏。因此，我们在开发中一定要注意将Handler设计成静态内部类，或者在Activity销毁时及时清理消息队列，确保Activity可以正常释放。”

讲讲Handler机制

“Handler机制在Android里面其实是个非常核心的概念，主要用来做线程之间的通信和处理异步消息。基本原理是，Handler本身关联着一个Looper和一个MessageQueue，简单来说，Looper就是一个不停循环的线程执行者，而MessageQueue就是它的任务队列。Handler让我们可以把要执行的任务或者消息放进这个消息队列里，然后让Looper在合适的时候把这些消息取出来，分发执行，从而实现线程间的消息传递和处理任务。

具体来说，我们往Handler里发送消息或者Runnable，实际上就是添加到这个消息队列里。这个队列按照先进先出的原则，Looper会不停地拿出队列里挂起的消息，然后调用对应的Handler回调方法来处理。这就解决了我们不直接在子线程操作UI的问题，因为通常Handler会在主线程创建并绑定主线程的Looper，这样我们就可以在子线程处理完任务后通过Handler把结果传递到主线程进行UI更新。

另外，Handler的内部实现也是有一些细节需要注意。像Handler在内部其实是个匿名内部类，它有可能持有Activity的隐式引用，所以如果你不注意管理消息队列里的消息，比如没有在onDestroy时移除消息回调，很容易造成内存泄漏问题。这也是为什么在一些场景下，我们建议使用静态内部类或者弱引用的方式来处理Handler，以避免长时间持有Activity或Context的引用。

从整体架构来看，Handler机制让我们不用自己去写各种繁琐的线程同步代码，它用消息队列和Looper来串联起异步任务的执行，这不仅让代码更简洁，还保证了任务执行的顺序性和线程安全性。对于我们在Android开发过程中，尤其是涉及到一些UI更新、定时任务或者后台线程和主线程之间的协作，Handler都是一个很好的工具。

所以总结下，Handler机制主要包括三个关键点：消息队列、Looper和Handler本身，这三者配合工作，实现了异步消息的传递和线程间通信，通过这种方式，让我们可以非常灵活地将任务分发到对应线程执行，同时也要注意避免由于Handler写法不当而引起的内存泄漏问题。”

View事件传递

“在Android的View事件传递中，本质就是设计了一套分层次的分发机制，保证事件能够按需传递到正确的View。整个过程主要分为三步：分发、拦截和处理。

首先，我们有dispatchTouchEvent方法，这是事件传递的入口，每个View或ViewGroup都会重写这个方法。它主要的任务就是把触摸事件从Activity的顶层窗口开始，一层一层往下传递。对于ViewGroup来说，它会先调用自己的dispatchTouchEvent，而这个方法中通常会先执行onInterceptTouchEvent方法。

接下来，onInterceptTouchEvent就起到了拦截的作用。对于ViewGroup来说，这个方法允许我们判断是否要拦截当前传进来的事件。比如说，一个复杂的滑动控件可能需要判断用户手势是轻微滑动还是需要消费事件，然后决定是否让子View接收到事件。如果我们返回true，就表示拦截了事件，子View就拿不到；如果返回false，那事件就继续传递给子View处理。

最后，到了真正的处理阶段，也就是onTouchEvent。这个方法在View或ViewGroup中会被重写来处理具体的各种触摸事件，比如ACTION_DOWN、ACTION_MOVE、ACTION_UP之类的操作。如果View本身需要对事件响应，onTouchEvent就会在这里处理。如果处理了，就返回true，表示事件消费掉；要是返回false，就可能会沿着父View链逐层回退，或者传达到其他组件。

需要注意的一点是，整个传递过程是递归和分层的。比如说，事件先从Activity派发到Window，再到DecorView，然后再分发到最底层的View。在这个过程中，每个ViewGroup都可以选择是否拦截，保证了那些需要单独处理的区域能够独立响应事件，同时也防止了事件的不必要浪费。这种机制让我们的UI既具有灵活性也有统一的事件管理机制。

总结来说，View事件传递就是通过dispatchTouchEvent实现事件的传递，然后利用onInterceptTouchEvent进行过滤和拦截，最后在onTouchEvent中处理剩下的事件。

代码题：计算器简易版 只有 + - 没有乘除 然后没有括号

 

思考题：有一本很厚的英语书，如何使用最少得内存找出书中里面出现次数最多的单词

“这个问题问的是如何在内存特别有限的情况下，找出一本厚英语书中出现次数最多的单词。我们不能简单地把整个词表加载到内存中做统计，因为如果书有成千上万个不同的单词，这样内存消耗就很大。所以我的思路是用流式处理的方式，一边读取一边统计，而且要避免存储所有单词的完整列表。

一种比较经典的做法是用类似Misra-Gries算法的思想。具体来说，就是我们限定内存中只能保存固定数量的候选单词及它们的计数，比如说只保存k个候选项。然后我们遍历书中的每个单词：

  如果当前单词已经在候选列表中，就让它的计数加一；   如果当前单词不在候选列表，而且候选列表还没有满，就把这个单词加入，并让计数设为1；   但如果候选列表已满而且当前单词又不在其中，那就对候选列表中所有的计数做一次减一操作，如果某个计数减到0了，就把那个候选项移除。

这样做的效果是：频率相对较高的词在整个过程中更容易存活下来，而那些出现频率较低的词则被淘汰掉。遍历完书以后，候选列表里面的单词虽然不一定完全精确，但肯定包含那个出现次数最多的单词。为了保证精度，我们可以再做一次遍历，重新统计候选单词的实际出现次数，最终确定出现次数最多的那个。

这种方法的好处是，我们在整个过程中只需要维护一个固定大小的候选集，而不必保存所有单词，大大降低了内存消耗。这个思路很适合处理数据量巨大、内存又很有限的场景。如果对精度要求极高的话，还可以在最后做一次完整的计数过滤，但这通常只针对候选集里的几个单词，而不是所有单词，从而不需要太多内存。

场景题：如果现在有一个自动驾驶的数据通信场景，使用什么协议通信 （QUIC）

“自动驾驶的数据通信对实时性和安全性要求非常高。传统的协议，比如TCP，在建立连接时需要三次握手、重传控制等，这些机制虽然保证了可靠性，但可能会引入额外的延迟；而UDP虽然低延迟，但本身不保证消息到达和顺序。QUIC正是建立在UDP之上，同时融合了类似TCP的可靠传输和现代的低延迟设计。

QUIC具有0-RTT握手的优势，也就是说可以在短时间内就建立起安全连接，这在自动驾驶这种需要即时反应的场景下非常有用。另外，QUIC内置了加密和多路复用机制，能有效解决头阻塞问题，确保即便在高并发通信场景下，每个数据流的传输仍然及时、高效。

当然，在自动驾驶中，每一毫秒都很关键，所以我们还要考虑网络的丢包、拥塞情况。在这方面，QUIC的拥塞控制和重传机制，虽然也是适当的延时补救措施，但相较于传统协议来说已经做了很多优化。所以，使用QUIC可以更好地在低延迟和数据安全之间找到平衡点，特别是如果系统能够在底层支持QUIC的话。

场景题：大量数据访问服务器，怎么解决

“面对大量数据请求服务器这个场景，咱们得用一整套综合措施来解决这个问题，既包括硬件层面的扩容和负载均衡，也需要软件层面的优化。首先，我会考虑使用负载均衡器，把流量分发到多个服务器上，这样就不会把请求都集中到一台机器上，避免单点压力过大。负载均衡可以是硬件上的，也可以是软件上的，比如Nginx或者专门的云服务负载均衡。

其次，在数据访问这块，我们可以用缓存技术来大大减少对数据库的直接访问。比如说，把频繁访问、变化不大的数据放到Redis或Memcached里，这样客户端访问就直接从缓存拿，响应速度快很多，也减轻了数据库的压力。

再有，对于数据量极大的情况，我会考虑使用分布式架构，比如数据分库分表。这样一来，我们根据业务场景，把数据拆分成多个独立的分片，每个数据库只存储一部分数据，可以大大提高查询的效率。同时，还能实现故障隔离，避免单库故障影响整体服务。

另外，我觉得需要有完善的限流和熔断机制，比如说在高并发请求时能自动限制某些请求的频率，或者当某个服务负载超标时能迅速切换到备用策略，保证系统整体的稳定性，同时对客户端也能以友好的方式告知或重试。

还有一个思路，就是异步处理。如果不是所有请求都必须同步返回结果，可以考虑采用消息队列，比如Kafka或者RabbitMQ，把部分流量异步地处理，把请求先做缓存、先记录日志，等到后续批量处理。另外，API层也可以做一些分页加载、按需加载、数据压缩等手段，减少传输的数据量，加快响应速度。

场景题：热点数据存储怎么控制

“当我们说到热点数据存储的控制时，主要就是面对一部分数据被频繁访问、写入压力很大的情况，我们要想办法让系统流量均衡，避免一个点出现性能瓶颈。首先，我会考虑缓存策略，比如用Redis作为缓存，把热点数据提前加载到内存里。这样一旦有请求到来，直接从缓存读取，不仅减少了数据库的压力，也能快速响应请求。这种方式常常配合一些缓存失效策略，比如说LRU或者设置合理的过期时间，这样可以防止缓存雪崩的问题。

其次，针对写入操作的热点问题，我们可以运用数据分片或者限流的措施。比如说，对于写请求比较密集的热点数据，可以先在业务层做限流，把请求排队或采取异步处理，确保系统不过载。另外，热点数据可以考虑做分离处理，不至于所有请求都落在同一个数据库实例上，可以通过数据拆分或者多副本存储来解决。

还有一种思路是使用读写分离，通过主从数据库架构，将读请求分散到多个从库上处理，这样就不会让主库因为热点访问而成为瓶颈。当然这个方式也得考虑数据的一致性问题。

总的来说，热点数据存储的控制重点在于用缓存降低直接访问数据库的频率，利用限流、异步和分布式存储来分散压力，并且针对可能的缓存穿透、缓存雪崩要有预防措施。