字节跳动：飞书 （Android） 一面 （拷打）

为什么你的项目中要用到MVVM

在我的项目中之所以会选用MVVM架构，主要是因为这种架构模式在维护性、可测试性和扩展性这几个方面都有明显的优势。首先，MVVM把业务逻辑和UI展示层进行了很好的分离，这样一来，UI层只需要负责展示，而所有的数据处理和业务逻辑都放在ViewModel中。这种分离不仅让代码层次更清晰，而且当需求发生变化或需要做修改时，可以更方便、快速地定位问题和修改对应的部分。

其次，MVVM使得数据绑定变得非常方便，尤其在Android中，借助Data Binding框架，View和ViewModel之间的数据同步可以自动进行，不需要我们在每个Activity或者Fragment里写很多冗余的更新UI代码，也大大减少了出错的可能性。这样既提高了开发效率，也减少了UI和逻辑之间的耦合，有利于后期维护和单元测试。

另外，随着项目规模的不断扩大，逻辑复杂度逐步提升，如果没有一个良好的架构做支撑，各个模块之间的耦合将会非常混乱。而MVVM的设计理念正好遵循了开放-封闭原则和单一职责原则，使得每个模块都只负责自己的功能，这样整个项目更加模块化，也更容易进行团队协作开发。

最后，使用MVVM还能够较好地支持响应式编程和实时数据更新，对于一些动态数据比较多的应用来说，整个流程更直观，也能提前捕获和避免一些由于状态不一致带来的问题。我个人觉得在开发中，能够清晰地分离业务逻辑和UI层，不仅提升了代码的可读性和可维护性，也使得项目的长期迭代变得更高效。

它相比于MVC有什么优势

我觉得MVVM相比于传统的MVC有几个明显的优势。首先，在MVC中，Controller一般会和View耦合得比较紧密，业务逻辑和UI之间的界限其实不是很清晰，随着项目复杂性增加，很容易导致Controller变得庞大难以维护。而MVVM的设计让业务逻辑放到了ViewModel中，这样就把UI和逻辑彻底分离开来，职责更明确。

其次，MVVM天然支持数据绑定。借助Android的数据绑定框架，我们能够让View层通过观察者模式自动绑定ViewModel中的数据变化，这样一来，就不用在Activity或Fragment中手动写那么多更新UI的代码，不仅减少了样板代码，也降低了出错的概率。对我来说，这种方式大大提升了开发效率，而且让后期维护变得更加轻松。

再者，由于ViewModel完全独立于View层，所以它可以独立进行单元测试，不需要依赖Android的UI组件。这对于保证业务逻辑的正确性提供了很大的便利，而在MVC结构下，业务逻辑往往和界面交织在一起，单元测试会复杂很多。

另外，MVVM更容易进行模块化和扩展。在项目迭代中，如果需要增加新的功能或者修改原有业务逻辑，只要调整ViewModel就可以了，而不用牵一发动全身。这种松耦合的设计使得团队协作效率更高，可以各自独立开发、测试，再做整合。

用过MVP吗？为什么不用MVP

首先，随着项目的不断演进，我发现MVP会导致Presenter变得越来越臃肿，尤其在业务逻辑复杂的时候，Presenter容易变成一个“大控制器”，里面不仅包含了视图相关的逻辑，还要处理不少业务代码，后期维护就变得比较困难。

其次，MVP中View和Presenter的交互主要依靠接口来实现，这样的话，在实现上会出现大量的接口代码，不仅样板代码多，而且容易让代码结构显得繁琐。相比之下，像MVVM这种架构可以通过数据绑定减少不少中间环节，使得UI更新更加自动化和简洁，开发效率更高。

另外，MVP对View的依赖比较强，毕竟Presenter需要持有一个View的引用，在生命周期管理上可能存在一定隐患，特别是在Android这种环境中，如果处理不当，很容易导致内存泄露问题。对我来说，内存管理和组件拆分是非常重要的考虑因素，所以当时评估后觉得其它架构模式可能更安全、维护性更好。

最后，团队的协作和测试也是考虑的一个因素。MVP虽然在早期可以提高单元测试的可行性，但随着Presenter代码的复杂度增加，实际测试起来也会遇到不少难题。而一些更新的架构，比如MVVM，不仅能更好地支持单元测试，也让模块职责更加分明，这对团队协作和代码的长期维护都有好处。

总的来说，虽然MVP也有它的优点，比如清晰分离了层级，但在实际项目中，我觉得它在开发效率、代码简洁度以及后期维护等方面存在一些不足

ViewModel有什么特点

ViewModel主要就是为了处理和管理与UI相关的数据，同时能感知生命周期，从而避免出现内存泄露问题。简单讲，ViewModel能让我们把业务逻辑和UI控制分离开。它的主要特点有以下几点：

1. 它能很好地保存数据——当设备旋转或者发生配置变化的时候，Activity或者Fragment会被销毁，但相关的数据不会丢失，因为ViewModel是跟随生命周期之外（它的生命周期是针对整个屏幕范围的）的，这就解决了因为重建导致数据丢失的问题；

2. 它跟UI解耦——所有的业务逻辑数据都保存在ViewModel中，UI层只负责观察数据变化，展示相应的状态。这样一来，不仅代码更清晰，还能大大降低耦合度，有助于单元测试和维护；

3. 数据共享和处理——在一些情况下，多个界面可能需要共享相同的数据，比如在多Fragment的场景下，使用同一个ViewModel能让数据在不同界面间传递和共享，从而保证数据一致性；

4. 生命周期感知——ViewModel能感知Android的生命周期，确保当Activity或Fragment销毁时及时释放资源。同时在程序中，我们可以利用LiveData或者其他类似机制来实时告诉UI数据的变化，做出自动刷新，而这些机制与ViewModel配合起来使用，基本上可以做到响应式编程的效果；

5. 降低内存泄漏风险——因为它不是直接绑定在Activity或者Fragment的生命周期里，所以可以有效避免因为配置变化导致的内存持有问题。也就是说，避免了一些常见的内存泄漏场景，比如在Activity销毁后还存留对它的引用。

总的来说，我觉得ViewModel的优势在于它让我们在处理UI展示逻辑和数据持久性方面更加灵活，一方面能保证配置变化后的数据不丢失，另一方面还让代码结构更清晰，维护和测试起来都更方便。

不理解VIewModel和LiveData的强依赖关系，解释一下

其实我觉得ViewModel和LiveData之间所谓的“强依赖”关系，并不是说ViewModel非得搭配LiveData才能使用，而是说它们在设计理念上非常契合，互相弥补了各自的不足，也很好地解决了实际开发中的一些问题。

首先，ViewModel的主要作用就是将与UI相关的数据和业务逻辑分离出来，并在配置变化（比如屏幕旋转）时保存它们。而LiveData则是一个生命周期感知的数据持有者，能够帮助我们自动更新UI，同时避免内存泄露。很多时候，我们把数据放在ViewModel里，然后通过LiveData将数据的变化通知到UI层，这个组合能够让整个架构更加简洁和模块化。

其次，使用LiveData结合ViewModel可以大大降低开发者手动管理生命周期的复杂度。因为LiveData本身是感知生命周期的，当Activity或者Fragment处于活跃状态时才会通知数据变化，这样就不用在Activity中手动去判断或管理数据何时更新、何时需要处理异常状态问题。这种自动化的特性使得代码更加健壮，也更容易测试和维护。

此外，从团队协作和后期迭代的角度来看，使用ViewModel与LiveData也有很大的优势。我们在进行单元测试时，ViewModel可以独立于UI环境进行测试，而LiveData的数据流动性又使得UI层代码变得更简单，避免了大量的回调和状态检查。这样协作起来，各层之间的职责划分更明确，出错的可能性也降低了。

总结来说，虽然ViewModel不一定非要搭配LiveData，但在实际的Android开发中，这两者几乎成了标配。它们结合起来，不仅简化了数据管理和生命周期处理，还大大提高了代码的可读性、可维护性和可测试性。

那我把LiveData放在一个普通的类里不行吗？

LiveData 本身的设计就不是为了在普通类中任意使用，而是配合生命周期感知组件（像 Activity、Fragment）以及 ViewModel 来使用。虽然技术上讲，你可以把 LiveData 放在一个普通的类里，它依然能起到数据持有和通知观察者的作用，但你就会失去它很多重要的特性。

比如说，LiveData 的核心优势之一就是自动管理与生命周期的结合。当你将它放在 Activity 或 Fragment 中使用时，它会自动识别当前组件是否处于活跃状态，从而决定是否通知数据变化，这样就能避免内存泄露问题和不必要的 UI 更新。如果放在一个普通的类里，就没有这种生命周期的感知机制，你就需要额外处理观察者的注册与注销逻辑，容易出错。

另外，把 LiveData 搭配 ViewModel 一起使用，还能利用 ViewModel 在配置变化（比如设备旋转）时数据不丢失的优势。如果你单独在普通类里使用，就失去了这个优势，因为普通类不会因为配置变化而保留状态，所以管理起来就更复杂了。

总的来说，把 LiveData 放在普通类里虽然技术上可行，但这样做就无法享受到它与生命周期、ViewModel 强耦合所带来的好处，比如自动管理内存、轻松实现响应式更新等，也容易导致管理上的额外工作和潜在的内存隐患。

LiveData需要依赖ViewModel来取消订阅吗

其实LiveData本身是设计成生命周期感知型的组件，它会自动根据观察者的LifecycleOwner（比如Activity或者Fragment）的状态来管理订阅。也就是说，当观察者不在活跃状态时，它不会发送更新，而当观察者被销毁的时候，LiveData会自动取消订阅，避免内存泄漏。

那么，为什么很多情况下我们都会把LiveData放进ViewModel里呢？主要原因在于ViewModel能帮助我们在配置变化（像屏幕旋转）时保持数据不丢失，同时也将业务逻辑和UI分离。但这种做法并不是为了取消订阅而必须用ViewModel，而是为了更好地管理和缓存数据。LiveData的取消订阅功能完全是靠生命周期感知实现的，而不是依赖于ViewModel去手动取消。

所以，从本质上来说，即便你把LiveData放在普通的类里，只要你正确地用LifecycleOwner去观察它，LiveData也能自动处理订阅和取消订阅的问题。但是，在实际应用中，使用ViewModel可以保证数据的长期存活和一致性，更符合Android架构的设计思想。

我觉得重点在这两点：一是LiveData的自动感知生命周期，确保不会在Activity/Fragment销毁后还残留订阅；二是ViewModel作为数据持有者，帮助我们在复杂场景下管理数据，虽然它并不是用来取消订阅的，但它和LiveData配合起来能让整体开发更简单、更安全。

一个ViewModel在Fragment销毁时执行哪些方法

其实ViewModel本身并不像Activity或者Fragment那样有丰富的生命周期回调方法。ViewModel最主要的一个方法就是onCleared()。当一个Fragment最终被销毁，而且这个Fragment独立管理它自己的ViewModel时，也就是说这个ViewModel的生命周期结束了，系统就会调用它的onCleared()方法，用来做一些资源释放、取消异步操作这样的清理工作。

需要注意的是，Fragment的视图被销毁（比如在onDestroyView里）并不意味着关联的ViewModel会销毁，因为ViewModel的设计目的就是为了在一些短暂的UI销毁（比如配置变化）时仍保留数据。如果Fragment是因为配置变化而重建，ViewModel会继续存在。但是当Fragment彻底结束生命周期，不再被留存，ViewModel也就不需要存在了，这时onCleared()方法就会被调用。

所以，总体来说，一个在Fragment中使用的ViewModel，最终在Fragment的生命周期完全结束时，唯一在生命周期回调层面会执行的方法就是onCleared()。这也是为什么我们常说ViewModel是独立于视图生命周期的，因为它只负责数据的保存和管理，最后只需要在销毁时做一次清理，而其他像onCreate、onDestroy这类方法，ViewModel中并没有对应的回调。

解释一下LiveData

LiveData其实就是个数据持有者，它的设计主要目的是帮助我们处理数据和UI之间那种通知更新的过程，同时能自动感知生命周期，避免——比如在Activity或Fragment销毁后——不恰当地继续发送数据更新，从而导致内存泄露。简单说，LiveData让我们不用自己写一堆代码去监听生命周期，也不用担心UI组件不在活跃状态时还做更新，当观察者（比如界面）处于非活跃状态，LiveData就不会推送更新了。

我觉得，它的优势主要有几个点：一方面，它很容易理解和使用，就像个普通的数据容器，但又内置了观察者模式；另一方面，它更高效安全，因为它会自动取消对不活跃观察者的订阅，确保系统资源不会被无谓使用或滥用。此外，通过LiveData，数据层和UI层能够解耦，你只需要在ViewModel中管理数据变化，UI层只关心如何响应更新，这样代码更清晰，也更容易维护和测试。

总的来说，LiveData就是这么一个轻量级但是功能强大的组件，可以说是让数据更新变得更加简单、可靠，还自动帮你管理了很多生命周期的细节，让开发工作更加顺手。

它是怎么感知生命周期的

其实LiveData能感知生命周期，主要靠的是它内部会绑定一个LifecycleOwner，比如Activity或者Fragment。我们在调用observe()方法注册观察者时，其实就传入了一个LifecycleOwner，这是系统的一个接口，所有Activity和Fragment默认都会实现它。LiveData内部会利用这个LifecycleOwner来监控状态变化，比如当Activity变为STARTED或RESUMED状态时，LiveData就会通知观察者，而当Activity或Fragment进入STOP或DESTROYED状态时，它就不发送更新或者自动移除订阅，从而防止内存泄漏。

可以把它想象成一种自动机制：它在注册时就会跟踪Lifecycle，等到状态不再活跃时，自行暂停通知，从而省去了我们手动管理观察者的麻烦。这样也确保了UI更新只在合适的时机发生，既节省资源也避免了空指针或者内存泄漏之类的问题。总之，LiveData的生命周期感知依赖于LifecycleOwner和内部的观察者模式，这也是它的一大优势。

为什么要用RecyclerView

其实用RecyclerView主要是为了提升界面的性能和扩展性。首先RecyclerView实现了很好的Item复用（ViewHolder机制），这意味着当你滚动列表的时候，不必频繁地创建和销毁视图，这样一来就大幅降低了内存的开销，提高了流畅度，尤其是在显示大量数据的时候效果非常明显。

其次，RecyclerView比早期的ListView更灵活。它内置了一些可以自定义布局的功能，比如Grid、线性或者瀑布流布局，我们可以很容易地定制不同的布局方式，而且对布局管理器的支持使得整个列表结构更加清晰、逻辑分离。工作中，数据都能够很自然地通过数据适配器适配到界面上，这也让后续的维护和扩展变得不那么复杂。

再者，RecyclerView支持动画效果是内置的，比如Item的插入、删除之类的动画，这对用户体验也是非常友好的。相比传统的列表，这些动画都是自带的，开发者也可以根据需求进行自定义调整，让交互效果更自然。另外，由于RecyclerView的设计原则清晰，它也有着良好的分离关注点，让Adapter只关注数据和视图的绑定，而不需要处理太多的其他逻辑。

总结来说，选择RecyclerView主要是因为它解决了传统列表控件在效率、灵活性、动画效果和整体架构上存在的一些局限，让开发者能够更容易地构建高性能、可维护和用户体验良好的列表交互界面。

说说Room然后和SQlite的区别

其实Room和SQLite，简单来说就是SQLite的封装和抽象层。直接操作SQLite的话，我们需要自己写大量的SQL语句，使用Cursor去获取数据，还得注意字段的对应、数据类型转换这些问题。代码量大，出错的概率也相对高，而且错误往往只能在运行时才发现。

而Room就不一样了，它是一种更现代化的数据库解决方案，通过注解来管理数据库的表、实体和数据访问对象（DAO）。这就大大减少了样板代码，也提高了编译时检查能力，比如SQL语句的正确性能够在编译的时候就提示错误，而不用等到运行时再暴露问题。另外，Room还内置了对LiveData和Kotlin Coroutines的支持，这也方便我们进行异步数据操作和响应式UI开发。

Room提供了一层抽象，把数据库操作封装起来，开发时只需要关注业务逻辑，不必关心底层的一些细节，比如对象映射。它会自动把查询结果转换成我们定义的实体类，减少了手动解析Cursor的麻烦。这种设计不仅使代码更加简洁，也能让我们的应用更易维护。

总的来说，直接使用SQLite虽然灵活性很高，但开发起来容易出错、代码量大。而Room就像在SQLite之上再加了一层“保险”，既保证了性能，又减少了出错的可能性，同时兼容了Android官方的架构组件，让整个数据层的编写和维护都更高效。

那你知道shared_perference是什么吗？然后它有什么上位替代吗

SharedPreferences其实是Android系统内置的一个轻量级存储方案，用于以键值对的方式存储简单的数据，比如用户设置、一些状态标记或者少量配置信息。它的优点在于使用简单、读写速度快以及适合存储少量数据。我们大量使用SharedPreferences来保存一些不会频繁变更的配置信息或者用户登录状态之类的数据。

不过，随着业务需求的增多和对现代编码习惯的要求提升，SharedPreferences也暴露出一些不足，比如说它的API是同步的，数据读写如果处理不当可能会阻塞主线程，而且缺乏类型安全的检查和良好的错误处理机制。对于多人协作和更复杂的存储需求，我们期望能够有一种更现代的、异步并且类型安全的替代方案。

于是，Google推出了Jetpack DataStore作为SharedPreferences的上位替代方案。DataStore本质上也是用来存储键值对或者结构化数据的，但它的优势在于它基于Kotlin协程和Flow设计，天然支持异步操作，不会阻塞主线程，同时也能提供更加安全的数据读写机制。此外，DataStore在数据迁移、数据更新冲突处理等方面也比SharedPreferences更优，让代码的健壮性和可维护性都得到了提升。

简单来说，虽然SharedPreferences是一个非常简单且常用的工具，但当数据存储需求变得稍微复杂或者追求更现代化解决方案时，Jetpack DataStore就成为了一个更合适的替代品。

SharedPreferences 的数据并不是存储在内存中的，而是存储在设备的文件系统中，具体来说，是以 XML 文件的形式保存在应用的内部存储目录下。

你知道OkHTTP拦截器吗？

其实我对OkHTTP拦截器还是比较熟悉的。它的主要作用就是让我们可以在请求和响应的过程中截取和修改数据。比如你可以用它来添加公共的请求头，或者对请求参数进行一些统一的处理，然后呢，还可以在服务端返回数据之前先做个日志记录或者错误处理，这样就分离了针对网络请求的通用逻辑，不用每个请求逐个处理。

OkHTTP的拦截器采用了责任链模式，也就是说它把所有拦截器都组织成一个链条，每个拦截器都可以决定是否继续调用后面的拦截器或者直接返回响应。这样不仅让代码结构更清晰，还能方便地进行一些全局的行为管理，比如缓存策略、重试机制之类的。

另外，拦截器其实分为两种，应用级别和网络级别。应用级的拦截器主要用于在请求开始前或者接收到返回之前做一些逻辑处理，并且无论服务器返回结果怎样都会执行；而网络级别的拦截器则更多关注于实际网络请求的细节，比如低层的重定向、缓存等操作。

总的来说，OkHTTP拦截器为我们提供了一个非常灵活和强大的机制，使得网络请求相关的通用逻辑集中处理，不仅能减少重复代码，而且还能更容易地进行调试和维护。

讲讲OkHttp是怎么用的

OkHttp其实是一个用于网络请求的高效HTTP客户端库，在Android开发中应用非常广泛。它的使用其实很直观，基本上分成几个步骤。首先，我们会创建一个OkHttpClient对象，这个对象是用来维护网络连接池和整个请求过程的。创建的时候，我们可以对它进行一些定制，比如添加拦截器、配置超时或者缓存策略等。这样的话，后续的每个请求都能遵循这些统一的设定。

然后，具体的网络请求过程主要是通过构造一个Request对象来描述我们的请求信息，比如请求的URL、方法是GET还是POST，还可以设置头部信息、请求体等等。接着，我们就是通过OkHttpClient的newCall方法发起请求。有两种方式：一种是同步执行，也就是直接调用execute方法，这种方式会阻塞当前线程，所以一般在子线程中使用；另一种是异步执行，通过enqueue方法来回调，这样就不会阻塞主线程。异步方式里，我们只需要实现对请求成功或失败的处理。

除了基本的请求发送，OkHttp还有一个很重要的优点，就是它支持拦截器。拦截器非常灵活，可以让我们在网络请求过程中拦截、修改请求或者响应，这对做日志记录、统一添加认证Token、错误处理或者调试都非常有帮助。拦截器的设计采用了责任链模式，让每个拦截器可以决定把请求交给下一个处理，这也让我们能够按照需求组合各种处理逻辑，而不用在单个请求中写一长串的逻辑代码。

总的来说，OkHttp的使用非常灵活和强大。一方面它提供了简单直观的API，让我们能够很容易地发起HTTP请求；另一方面，它又支持各种高级特性，比如连接池、缓存、拦截器等，能有效提高网络请求的性能和控制力。而且因为它可以无缝与其他库搭配使用（比如Retrofit），所以在实际开发中可以根据项目需求选择不同的使用方式。这样既满足简单请求，也能应对复杂的网络交互需求。

OkHttp的HTTP响应缓存是放在磁盘上的，而连接池等其他机制可能会使用内存。这样设计可以提高缓存的持久性，同时也不会占用过多内存资源。

那这个拦截器是一个什么设计模式 （责任链模式）

其实，OkHttp的拦截器就实现了责任链模式。也就是说，我们可以把多个拦截器按照顺序排列，每个拦截器都可以对请求或者响应做一些处理，然后再把它传递给下一个拦截器。这样每个拦截器都有自己的职责，而且如果某个环节需要特殊处理，我们只需要在对应的位置插入一个拦截器即可。这种设计让代码非常解耦，也便于后期扩展和维护。每次请求进来都会沿着这个“链”逐步经过各个拦截器，从而实现数据的统一处理和逻辑分离。

拦截器是怎么实现的，然后如果我有多个拦截器的话，怎么协调它们的工作

其实，OkHttp拦截器内部是用责任链模式来实现的。也就是说，当请求发起时，它会构造一个拦截器链，每个拦截器都有机会呼叫下一个拦截器，直到最终完成网络请求然后返回响应。每个拦截器都接收一个请求，并决定怎么处理它，比如可以修改请求，或者记录日志，又或者直接返回一个模拟的响应，而不需要继续调用后面的拦截器。这样，每个拦截器就像链条中的一个“节点”，它既可以处理前面的逻辑，也可以把处理的请求传递给下一个节点。

如果我们有多个拦截器，协调它们的工作主要依赖于两个方面：拦截器的执行顺序和每个拦截器调用下一个拦截器的方式。拦截器的顺序是按照添加到OkHttpClient中的顺序来执行的，这个顺序很重要，因为前面拦截器的处理结果会影响后面拦截器看到的请求。比如，你可能先添加一个拦截器来统一添加某个认证Token，然后后面的拦截器拿到的就是已经附带了Token的请求，这样就保证了顺序。

此外，每个拦截器在调用chain.proceed的时候，会将处理过的请求传给下一个拦截器，直到所有拦截器都执行完毕，最后到达网络层，获取真实的响应。响应则会从下向上传递回来，每一个拦截器都有机会在响应返回之前做些处理，比如解析数据或者记录日志。

这种设计让我们可以灵活地按照需求模块化不同的处理逻辑，每个拦截器只关注自己那一部分的逻辑，整个拦截器链协同工作，保证请求和响应的处理井然有序。通过这种方式，我们就可以在整个请求过程中实现统一的错误处理、重试、缓存、日志记录等功能，而不必在每个请求代码中重复写逻辑。

总的来说，OkHttp的拦截器使用责任链模式，通过明确的顺序和统一的请求响应传递机制，来协调多个拦截器的工作。

那用Retrofit的网络请求库，我要去增加一个API调用我要去怎么做

其实增加一个新的 API 调用，其实主要就是扩展一下我们 Retrofit 定义接口的部分。我的流程通常是这样的：首先，我会确定一下这个 API 调用的基本信息，例如请求方式是 GET、POST 或者别的什么，然后看一下请求的参数和响应的数据结构。接着，我在定义 Retrofit 接口的地方增加一个方法，用注解来明确说明这个 API 的 URL 路径以及请求方法。这个接口方法的返回值通常会用 Call<T>（或者用 RxJava 的 Observable、Flowable，甚至 Kotlin 协程的 Deferred）来进行封装。

在确定接口方法之后，我们就要确保相关的请求实体（如果需要传递请求体）和响应实体都已经正确设计和映射了。通常我会和后端协商好返回的数据格式，然后在项目中建立对应的数据模型。在这一块，JSON 的转换就要依赖 Retrofit 配合使用的比如 GsonConverterFactory 或者其他转换工厂来做自动解析。

完成接口方法和模型类定义以后，就可以在项目中的网络层调用这个 API 了。调用的时候我通常会在一个 Repository 类中进行封装，保证 ViewModel 或 UI 层调用时不和底层网络请求细节耦合。这样处理不仅让代码变得更清晰，也便于在出问题时快速定位问题。

另外，如果这个新的 API 调用有特殊要求，比如需要额外的拦截器来处理身份认证或者错误码处理，我会在 OkHttpClient 上配置好相应的拦截器，然后传递给 Retrofit 使用。这样就保证每个调用过程中的通用逻辑能够统一处理，而不是在每个 API 方法里面重复写相关代码。

总结起来，增加一个新的 API 调用主要就是：

1. 修改 Retrofit 接口，新增一个方法来描述这个 API 的请求方式和路径。
2. 添加或更新对应的请求参数和响应数据的实体类，以便进行正确的序列化/反序列化处理。
3. 如果需要，调整网络客户端（比如添加拦截器或设置请求超时）来满足新的需求。
4. 在业务层（如 Repository）调用这一方法，并在 UI 层或者 ViewModel 里处理响应和错误。

Volatile关键字了解吗

其实，Volatile关键字在Java和Kotlin中主要用于多线程环境下的内存可见性问题。它的作用就是确保当一个线程修改了被volatile修饰的变量后，其他线程能立刻看到这个变化。因为在JVM里，每个线程都有自己的工作空间，可能会把变量缓存在线程内，如果没有使用volatile，修改过的变量可能不会马上同步到主内存，这就导致了线程间数据不一致的问题。

另外，volatile也能防止指令重排序。也就是说，编译器和处理器在执行代码时可能会重新排序指令，以提高效率，但volatile修饰的变量就能够确保指令执行的顺序不会乱，从而进一步保证多线程操作中的正确性。

不过需要注意的是，volatile虽然能保证可见性和禁止指令重排序，但它并不能保证操作的原子性。如果涉及到自增或者较复杂的操作，就得考虑使用synchronized或者Atomic系列类来确保线程安全。

总的来说，我理解volatile主要是在多线程环境下用来确保内存数据的稳定性和一致性，它很适合用在状态标识或者单个变量状态的更新上，但对于复杂的临界区还是需要用更严格的锁机制。这样设计可以提高整体代码的健壮性，避免因多线程导致一些难以调试的问题。

Java里面有哪些引用类型，讲讲

在Java中，引用类型主要有四种：强引用、软引用、弱引用和虚引用。

首先，最常用的就是强引用，也就是我们日常写的对象引用。只要一个对象有强引用链接，任何时候垃圾回收器都不会回收它。比如你通过new创建一个对象，把它赋值给一个变量，只要变量作用域内还存在，这个对象肯定不会被回收。

其次是软引用。软引用比较适合用于实现内存敏感的缓存场景。它的特点是，如果内存充足的话，软引用对象会保留，但是当系统内存不足时，垃圾回收器就会回收它。所以我们常用软引用来缓存一些占用内存比较大的数据，这样在内存吃紧的时候可以被回收，避免OOM风险。

再来是弱引用。弱引用就更“脆弱”一些了，只要系统进行垃圾回收，即便内存有剩余，这类对象也会被直接回收。弱引用常常用在一些映射或者缓存场景中，比如在实现Key-Value缓存的时候，如果使用弱引用来保存键或者值，一旦没有其他强引用存在，就会被GC回收，帮助我们避免内存泄露。

最后是虚引用，也叫幻影引用。虚引用和前面几种不太一样，它并不影响对象的生命周期，实际上它只是一个标记，用于在对象被回收时收到一个系统通知。我们通过引用队列可以感知对象何时被垃圾回收了，这在做一些资源释放或者清理工作的时候特别有用。虚引用无法通过它获取到对象的任何信息，也就是说调用它的get方法总是返回null。

总结来说，这几种引用可以根据具体场景选择合适的类型。强引用适合绝大多数业务对象，软引用适用于缓存、弱引用常用于防止内存泄露，而虚引用主要用于调试或者跟踪对象回收情况。

虚引用你在什么场景用过吗？

其实，虚引用在实际项目中用得比较少，但它能解决一些特定场景下的问题。我主要会在需要精确追踪对象何时被回收或者做一些资源清理的时候，考虑用到虚引用。比如说，我有过这样的场景：在处理一些大型缓存或复杂资源管理时，我希望在对象真正被垃圾回收时收到一个通知，这样就能做一些额外的清理工作，以避免内存泄露或者其他资源没有被及时释放的问题。

具体来说，我会结合引用队列一起使用虚引用。也就是说，在创建虚引用的同时，还把它注册在一个引用队列里。当垃圾回收器判断对象可以被回收时，会把对应的虚引用加入到这个队列中，这样我们就可以及时感知到这个对象已经结束了生命周期，从而在后台线程中安全地释放相关资源或者做一些后续处理。

虽然在日常开发中直接用虚引用的机会不多，多数情况下软引用和弱引用已经能满足需求，但在一些对资源管理要求特别精细的场景下，虚引用就显得特别有用，尤其是当我们希望对对象的销毁时机非常明确，并且能够做一些额外工作的时候。这样可以提高程序的健壮性，也能避免一些难以发现的内存问题。

讲讲Java中的锁

其实Java中的锁主要可以分为内置锁和显示锁。内置锁就是我们平时用的synchronized关键字，这个锁最早就是Java内置的一部分，比如通过synchronized修饰方法或者代码块，这样就能保证在同一时间内只有一个线程能进入被synchronized修饰的区域。它的好处是使用简单，不用手动释放锁，缺点就是灵活性不够，而且性能可能略微不如后来的显示锁。

然后就是显示锁，也就是java.util.concurrent.locks包下面的Lock接口和它的实现，比如ReentrantLock。在这类锁中，ReentrantLock可以说是最常见的。它的优势在于提供了更多高级功能，比如支持可中断锁、超时等待和公平锁。公平锁可以保证多个线程按照等待的顺序依次获得锁，虽然这样会略微影响性能，但能防止某个线程持续得不到锁。另外，ReentrantLock的锁释放需要显式调用unlock，这也就要求我们在使用时要特别小心，通常会放在finally代码块里面，以确保异常时锁也能被释放。

除此之外，还有一些其他形式的锁，比如读写锁（ReentrantReadWriteLock），它允许多个读线程同时获得锁，但写线程需要独占，这在读多写少的场景下能够大大提升并发性能。还有说到一些乐观锁的实现，比如CAS操作，这也是实现高性能并发编程的重要手段，虽然严格来说CAS不是锁，但是它可以在某些场景下取代传统的锁来实现原子更新数据，减少锁竞争。

总的来说，我会讲到Java中的锁设计既有基础的synchronized这种内置的轻量级锁，又有ReentrantLock这样的显示锁，以及读写锁这些细化的锁策略，加上CAS这样的无锁编程思想。

Synchronized lock 什么区别

我觉得关于synchronized和Lock的区别，其实可以从几个角度来说。首先，synchronized是Java里的内置关键字，属于JVM层面的支持。使用synchronized的时候，我们只需要在方法或者代码块前加上这个关键字，进入执行的时候自动获取锁，执行结束后自动释放。这种方式非常简单，不需要我们手动管理锁的释放，而且在异常情况下也能保证锁被释放，这样就减少了因忘记解锁而引起的问题。

而Lock接口，比如我们常用的ReentrantLock，则是来自java.util.concurrent.locks包，是一种显示锁。它的使用虽然需要显式地调用lock()和unlock()，因此在写代码时要特别小心，常常需要将unlock()放在finally代码块里，确保异常情况下锁能被释放。但它也给我们带来了更多的灵活性。比如，Lock可以支持可中断等待锁的获取，通过tryLock()方法还可以设置获取锁的超时时间，这样当竞争激烈或者可能出现死锁的时候，我们就有更多控制手段。同时，Lock还可以设置公平策略，让所有线程按照申请顺序获得锁，这在某些场景下可能是必须的。

再补充一点，synchronized的底层实现经历了多次演进，现在在JVM中已经做了不少优化，性能上大部分情况下已经足够优秀。但当有特殊的并发控制需求，比如需要非阻塞式尝试获取锁，或是需要明确的锁释放控制时，Lock就显得更加灵活和强大。

总结一下，我会这样表达：synchronized使用简单、自动管理锁的获取和释放，适合大多数简单场景；而Lock虽然需要手动释放锁，但提供了可中断、超时等待以及公平策略等高级功能，适用于需要更精细控制的场景。

如果一个方法加上Synchronized的修饰，一个静态方法加Synchronized有什么区别

其实，如果一个普通方法用synchronized修饰，那它锁的是该方法所在对象的实例锁，也就是说它会锁定当前对象，只有获得该对象锁的线程才能进入这个方法。如果同一个类创建了多个对象，那么各个对象之间的锁是相互独立的，一个对象调用这个同步方法，不会影响另外一个对象调用相同方法。

而对于静态方法加synchronized来说，它锁的是整个类的Class对象，而不是某个实例。所以无论这个类创建了多少个对象，静态同步方法实际上都只有一个锁。这样当一个线程在调用静态同步方法的时候，其它线程不论是调用同一个静态同步方法，还是调用这个类中其它使用静态synchronized修饰的方法，都会被阻塞，因为它们都共享同一个类锁。

简单来说，实例方法加锁的范围仅限于单个实例，而静态方法加锁的范围是整个类。这个区别非常关键，比如在设计的时候如果需要保护的是实例变量或者实例状态，用实例锁就足够；但如果涉及到类级别的共享资源，那么就需要使用静态锁来保证全局只有一个线程能操作。这样就能根据实际需求选择合适的锁策略，达到既保证线程安全，又避免不必要的竞争。

Android里面触摸事件的传递机制你了解吗

其实，Android 的触摸事件传递机制大体上可以分成几个步骤，从最外层往里层传递。首先我们点击屏幕，这个事件会先被系统捕获，然后传到当前 Activity 的 Window，再由 Window 传递到顶层的 ViewGroup，也就是布局的根View，比如 DecorView。之后，这个事件会经过每个 ViewGroup 的 dispatchTouchEvent 方法，这个方法内部会先调用 onInterceptTouchEvent。

onInterceptTouchEvent 的作用就相当于让父容器在事件传递过程中决定是否拦截事件。如果父容器认为自己需要处理这个事件（比如实现下拉刷新或者滑动删除等效果），就会在 onInterceptTouchEvent 返回 true，这样该事件就不会再传到子View；如果返回 false，那么事件就会继续传给其子控件的 dispatchTouchEvent 方法。

进入子控件后，子控件同样会在自身的 dispatchTouchEvent 中处理这个事件，如果它觉得自己满足处理要求，就会在 onTouchEvent 中处理。如果子控件不想或者不能处理，会返回 false，然后系统就会把事件传回到父控件，或者父控件的 onTouchEvent 来处理，以此来保证事件不会丢失。

另外，由于触摸事件涉及多点触控，还需要在 MotionEvent 对象中记录各种数据（比如 ACTION_DOWN、ACTION_MOVE 和 ACTION_UP 等），所以整个流程中，每个方法都需要对这些事件类型做出对应的处理。整个过程就像打电话一样，事件从上到下流淌，而每一级都可以选择截住电话或者传递下去，这个层层把关就保证了不同组件之间能够正确响应用户的触摸操作。

总的来说，我很清楚触摸事件从 Window 到 DecorView，再到 ViewGroup 的 dispatchTouchEvent、onInterceptTouchEvent，再到最终的子View 的 onTouchEvent 的整个传递流程，这个机制让我们可以灵活地在父容器层面拦截或者处理一些特定的手势，同时也能保证子控件能够响应细化的触摸事件。这样的设计帮助我们在复杂页面中更加精细地控制事件的分发和处理。

一个完整的事件，它有按下，然后移动，然后有抬起，然后再有抬起，如果VIew没有消费Touch_Down，那么后序的时间还能消费到吗

首先我们得知道，在Android的触摸事件传递机制里面，一个完整的触摸序列是从ACTION_DOWN开始的，接着才会有ACTION_MOVE、ACTION_UP等动作。系统在开始这个序列的时候，会先从ACTION_DOWN判断哪个View来响应整个事件。

所以，如果一个View在ACTION_DOWN这个阶段没有消费这个事件，也就是说它返回了false，那么系统就认为这个View对这个触摸事件序列不感兴趣。也正因为这个原因，对于后续的ACTION_MOVE、ACTION_UP或者其他相关事件，系统就不会再把它们传递给这个View了。换句话说，一旦ACTION_DOWN没被消费，整个事件序列就已经“流失”在这个View上，后面就没有办法靠这个View去处理。

从机制上来说，事件分发的时候最重要的一环就是ACTION_DOWN，这个事件决定了后续整个事件的走向。如果ACTION_DOWN不被消费，那么默认情况下后续的事件会交给父View或者其他可能的处理者，而不会再回到刚刚那个View。

所以总结一下：如果View不消费ACTION_DOWN，那么这个触摸事件序列就不会一路传递到它后续的MOVE、UP等事件，整个序列已经被“丢弃”给了当前View，这也是为什么我们在实际开发中必须保证第一个事件ACTION_DOWN被正确消费的原因，这样触摸事件才有连续性和可预见性。

手撕：多种方式实现单例

// 方式一：使用 Kotlin 的 object 关键字，最简单也是最推荐的方式
object SingletonObject {
    var value: Int = 0
}

// 定义一个单例类 SingletonLazy
// 这种单例模式使用 Kotlin 的 companion object 和 lazy 延迟加载特性来实现
class SingletonLazy private constructor() {
    // 1. `private constructor` 的作用：
    //    - 将构造函数设置为私有的(private)，防止外部类直接通过 `SingletonLazy()` 创建实例。
    //    - 单例模式的核心原则是整个应用中只能有一个实例，而这个私有化的构造函数确保了外部无法通过常规方式创建多个实例。
    //    - 只有在 companion object 内部，我们才可以通过 `SingletonLazy()` 调用构造函数创建实例，这样就能完全控制实例的创建过程。

    companion object {
        // 2. `companion object` 的作用：
        //    - Kotlin 中的 companion object 是一种伴生对象，它可以看作是一个与类相关的静态对象。
        //    - 在这里，companion object 提供了一个全局的 `instance` 属性，用于访问单例实例。
        //    - 相当于 Java 中的 "静态变量" 或 "静态方法"。

        // 3. 使用 lazy 延迟初始化 `instance`：
        //    - `by lazy` 是 Kotlin 提供的一种懒加载机制，只有在第一次访问 `instance` 时，才会创建 SingletonLazy 的实例。
        //    - 配合 `LazyThreadSafetyMode.SYNCHRONIZED`，可以保证在多线程环境下实例的创建是线程安全的。
        val instance: SingletonLazy by lazy(LazyThreadSafetyMode.SYNCHRONIZED) {
            // 4. 这里调用了 `SingletonLazy()` 构造函数：
            //    - 因为 `SingletonLazy` 的构造函数是私有的(private)，所以它只能在这个 companion object 内部被调用。
            //    - 这确保了单例对象的创建过程完全受控，不会被外部干扰。
            SingletonLazy()
        }
    }
}

// 定义一个单例类 SingletonDoubleChecked
// 使用双重检查（Double Checked Locking）来实现线程安全的单例模式
class SingletonDoubleChecked private constructor() {
    // 1. `private constructor()`：
    //    - 构造函数被设置为 private，防止外部通过 `SingletonDoubleChecked()` 创建实例。
    //    - 确保单例模式的核心原则——整个应用中只能有一个实例。
    //    - 只有类内部能够调用该构造函数，实例的创建完全由类自身控制。

    companion object {
        // 2. `@Volatile` 关键字：
        //    - `@Volatile` 保证变量的可见性。
        //    - 多线程环境下，所有线程对 `instance` 的读写操作都是立即可见的，防止出现线程缓存导致的旧值问题。
        //    - 它确保当一个线程修改了 `instance` 的值时，其他线程能够立即看到最新值。
        @Volatile private var instance: SingletonDoubleChecked? = null

        // 3. `getInstance()` 方法：
        //    - 提供一个全局访问点，用于获取单例对象。
        //    - 通过双重检查的方式，确保在多线程环境下高效且安全地创建单例实例。
        fun getInstance(): SingletonDoubleChecked {
            // 4. 第一层检查：
            //    - 检查 `instance` 是否已经被初始化。
            //    - 如果已经有实例，直接返回，避免进入同步块，提升性能。
            return instance ?: synchronized(this) {
                // 5. 第二层检查（同步块内部）：
                //    - 使用 `synchronized` 关键字对当前对象加锁，确保只有一个线程能够进入。
                //    - 再次检查 `instance` 是否为 null，防止多个线程通过第一层检查后同时进入同步块。
                instance ?: SingletonDoubleChecked().also {
                    // 6. 创建实例并赋值：
                    //    - 如果 `instance` 仍然为 null，则调用 private 构造函数创建实例。
                    //    - `also` 是 Kotlin 的作用域函数，用于在创建实例后同时将其赋值给 `instance`。
                    instance = it
                }
            }
        }
    }
}