腾讯视频 （Android） 一面

安卓四大组件

安卓四大组件主要就是指Activity、Service、BroadcastReceiver和ContentProvider。每个组件都有它主要的职责和使用场景。

首先，Activity是我们最常用的组件，基本上代表了一个界面或者一个屏幕。比如说，当用户启动一个应用后看到的界面，这就是一个Activity。它负责与用户做交互，同时管理界面的生命周期。平时我们在做用户交互的时候，比如跳转、数据传输，都会用到Activity。它的生命周期很重要，因为不正确的管理可能会导致内存泄露或者用户体验不佳。

接下来是Service，服务组件。Service主要是在后台运行的，不需要直接与用户交互。比如说处理一些耗时操作、后台下载、播放音乐这种持续运行的任务。因为它能够在后台长时间运行，所以开发的时候就需要特别注意它的生命周期和资源管理，保证不会因为长时间运行造成性能问题。我们可以把Service看做是一个工作者，专门负责执行那些不需要界面交互的任务。

第三个就是BroadcastReceiver，广播接收器。它的作用是接收系统或者其他应用发送的广播消息，然后做出相应处理。比如说系统开机、网络状态变化等，这些广播消息都会通过BroadcastReceiver接收。开发中如果要对某些系统事件做出响应，就可以注册一个BroadcastReceiver。因为它本身只是起到一个触发作用，处理完广播后就会很快释放，所以说它的生命期相对较短。

最后一个是ContentProvider，内容提供者。这个组件主要用于跨应用的数据共享。在实际开发中，我们可能需要在多个应用、或者应用内部不同模块间共享数据，比如联系人、日历或者一些自定义的数据时，就会用到ContentProvider。它提供了一个统一的数据访问接口，屏蔽了底层数据存储的细节，保证数据可以被其他应用安全地访问。当然，设计ContentProvider的时候也要注意权限管理和数据安全问题。

总的来说，这四大组件分别承担了用户界面、后台任务、广播响应和数据共享的职责。

HTTP HTTPS TCP UDP GET POST HTTP状态码

其实这些都涉及到网络协议和通信基本原理，我会这样讲：

首先谈一下HTTP和HTTPS。这两者最核心的区别在于安全性。HTTP是超文本传输协议，主要用于浏览器、客户端和服务器之间传输数据，它本身是不加密的，数据都是明文传输，所以可能会存在中间人攻击风险。而HTTPS是基于HTTP加上SSL/TLS协议的传输方式，所以所有的数据传输都是经过加密的，保障了数据安全和防止被篡改。面试中，如果问到这个问题，我会强调在需要涉及敏感数据传输或者支付等场景中，肯定会使用HTTPS协议来保障数据的机密性和完整性。

再说一下TCP和UDP，这两个都是传输层的协议。TCP是面向连接的，在数据传输之前需要三次握手建立可靠连接，而且传输过程中还提供了确认、重传、顺序控制等机制，所以可以确保数据可靠、完整送达，但相对开销大一些。UDP则是无连接的，简单、开销小但不保证数据能否到达和顺序，适用于那些对实时性要求高，偶尔丢包不会影响整体体验的场景，比如视频、语音传输。面试时我会说，选择TCP还是UDP需要根据具体需求而定，如果是对数据完整性要求严格的场景，一般用TCP；如果更注重时延和效率，就会考虑UDP。

接下来聊一下GET和POST，这两个是HTTP协议中最常用的请求方式。GET请求通常用于获取资源，在请求时参数会直接拼接在URL之后，所以适合传递一些不敏感、较少量数据；而POST请求更多用于提交数据，比如表单提交、上传文件等，因为数据是放在请求体中，相对安全一些，而且传输数据量上限也比GET大。正常情况下，我们在获取一些简单信息时使用GET，而在涉及到数据修改或提交操作时，就会选择POST。面试中也可以提到，GET请求还具有缓存友好性，但POST请求在实现幂等性的时候需要更多考虑。

最后说一说HTTP状态码，这是服务器响应客户端请求的一个反馈机制。常见的状态码比如200，表示请求成功；404代表找不到请求的资源；500则是服务器内部错误。除此之外，也有重定向状态码像301、302，代表资源位置移动，让客户端自动跳转，常用于SEO优化。理解这些状态码有助于我们在调试和开发时判断问题所在，比如说如果频繁返回500，说明服务端可能存在逻辑错误；而出现404则说明资源路径错误或者访问不正确。

OKHTTP

其实OKHTTP是我们在Android开发中非常常用的一个HTTP客户端库，它主要由Square开发，目的就是简化网络请求的处理。首先，它支持同步和异步两种请求方式，这样我们可以根据具体的需求来选择是阻塞当前线程等待数据，还是通过回调机制在获取数据后再处理下一步操作。对我来说，这种设计非常灵活，既能满足一些简单场景，也能应对高并发或者UI线程不阻塞的需求。

另外，我觉得OKHTTP的一个比较突出的特点是它内置了连接池管理。就是说，当你进行多次网络请求时，它会自动复用连接，这样就能减少重复创建连接的消耗，提升整个应用的性能。同时，这个连接池还可以帮我们实时管理连接的生命周期，有效避免资源浪费或者连接过多的问题。

还有一点就是，OKHTTP提供了非常好用的拦截器机制。拦截器让我们在请求发送前或者响应接收后可以插入自己的逻辑。举个例子，我们可以用拦截器去统一添加一些请求头、做日志记录、调试错误、甚至做一些缓存处理。这一点我非常看重，因为它让我们的网络层代码更加模块化，也便于后期维护和扩展。

当然，还有一点必须提到的是它对HTTP/2的支持，这在提升请求效率和并发处理上是非常有利的。HTTP/2允许多路复用，也就是说一个连接能处理多个请求，非常适合移动端网络环境，经常有网络不稳定或者资源有限的情况。

retrofit

Retrofit其实就是一个非常流行的网络请求库，由Square团队开发，用在Android和Java项目中。它的核心目标是帮我们把HTTP接口调用变得非常简单，转换成调用接口中定义的抽象方法，看起来就像调用普通的Java方法一样。比方说，我们只需要定义一个接口，并用注解标注请求路径、参数、请求方式（比如GET、POST）之类的信息，Retrofit就会根据这些定义生成对应的实现，不需要我们去手动拼接URL或者处理底层的网络连接。

我觉得Retrofit最吸引人的地方首先就是它有非常好的可扩展性。比如说，我们可以通过提供转换器（Converter）来决定如何将服务器端返回的数据转换成自己想要的实体对象，常见的如Gson或者Moshi转换库。这样一来，我们在拿到数据之后就直接可以使用已经解析好的Java对象去处理，不用手动解析JSON，节省了不少繁琐的工作。

另外，Retrofit还很好地支持异步调用和同步调用，这对于处理网络请求尤为重要。它允许我们根据业务需求在后台线程中进行网络交互，然后在主线程中更新UI。同时，它还能很好地与OkHttp这个底层的网络库搭配使用，利用OkHttp的连接池、拦截器等功能来提升整体的网络性能和健壮性。

从设计角度来看，Retrofit遵循了接口化编程的理念，把网络请求封装成透明而易于调用的接口，它的注解也让代码变得非常直观，这些都大大降低了维护成本。虽然在一些场景下可能会因为转换器的问题或者异步请求错误处理带来一些挑战，但总体来说，它使得网络请求的代码更为规范，模块化也更好，减少了很多重复劳动。

分辨率 ，dp ，px

其实这几个概念在Android中都是非常关键的，关系到我们的UI适配问题。首先，分辨率通常指的是设备屏幕上像素的总数，比如说1920×1080，这就是设备的分辨率。它决定了屏幕展示细节的多少，也说明了屏幕的精细程度。

接下来是px，也就是像素。它是一个具体的单位，代表屏幕上最小的可独立显示的点。iPhone和Android手机的像素可能不同，即使屏幕尺寸相同，像素密度也不一样，这就会影响UI在不同设备上的显示效果。直接使用px作为单位，可能会导致在高像素密度的设备上看起来太小，而在低像素密度的设备上又太大。

这时就引入了dp（density independent pixels），也叫做dip，即与屏幕密度无关的像素单位。使用dp可以让开发者抽象出一层，定义相对的大小，根据设备的屏幕密度进行转换，确保在不同设备上UI显示比例一致。比如说，我们定义一个按钮宽度为100dp，那么在不同密度下，系统会自动把它转换为对应的实际像素，比如在密度较高的设备上可能转换成更多的px，而在低密度设备上转换成较少的px。

我还会提到，转换公式一般是：px = dp * （density factor），density factor这个值由设备的屏幕密度决定，比如常见的mdpi，hdpi等。这样来看，dp的目的主要就是为了解决不同屏幕密度设备之间的不一致性问题。所以，我们在布局文件中通常推荐使用dp而不是px，这样可以更好地适配各种分辨率的设备。

总结一下，就是分辨率指的是设备屏幕的像素总数，而px是物理像素单位，而dp则是一种抽象单位，它帮助我们在不同密度屏幕中保持UI一致的视觉效果。这样的设计理念既解决了兼容性问题，又能在不同设备上提供更佳的用户体验。

公钥，私钥

其实公钥和私钥主要是我们非对称加密中用到的一对密钥。简单来说，公钥是可以公开的部分，而私钥就绝对不能泄露，必须妥善保管。一般来说，公钥用来加密数据或者验证数字签名，而私钥主要用来解密数据或者生成签名。

具体到我们开发中，比如说在安全通信或者数据传输方案中，我们会用公钥把敏感信息进行加密，然后只有持有私钥的服务端或者客户端才能解密。比如，在Android开发中，如果我们不得不把一些敏感的数据传输到服务器，就可以利用这种机制来防止中间人攻击，因为即便数据在传输过程中被截获，由于是经过公钥加密，没有私钥的人还是无法读取内容。

另外，数字签名是另一个重点应用场景。比如说，服务端使用私钥对数据进行签名，然后客户端利用公钥验证数据的完整性和来源，这就保证了数据没有被篡改，同时也证明了数据确实是由服务端发布的。这在很多需要认证数据来源的场景下都很有用。

设计模式

见前面博客

观察者模式

观察者模式其实就是一种行为设计模式，它主要的作用是用来解耦我们的对象之间的依赖关系。当某个对象状态发生改变时，它可以通知所有依赖于它的对象，让这些对象自动更新和做出相应的处理。

举个例子来说，我们可以把它想象成我们平时订阅新闻的过程。你订阅了某个新闻频道，当新闻频道有新的消息发布时，你就能收到通知更新信息。这种订阅和通知的机制，在软件中就体现在观察者和被观察者之间。被观察者持有一系列观察者对象的引用，当自身状态改变时，遍历这些观察者，然后触发它们的更新方法。

在实际开发中，比如在Android项目中，我们可能会用这种模式来处理界面和数据的变化。举个常见的例子，比如我们设计一个推送消息的功能，当消息数据改变时，各个界面或模块会收到通知，自动刷新数据，而不需要手动轮询或依赖紧耦合的代码来做更新。这样既提升了系统的响应性，又能让代码结构更清晰、模块间的耦合度降低。

从架构上来说，使用观察者模式我们可以将核心数据和使用数据的视图解耦开来。比如说我们在处理网络请求数据和UI更新时，可以把请求数据的部分作为被观察者，而多个界面组件则作为观察者，当数据更新时，统一通知它们去刷新界面。这样不仅便于维护，还能让系统扩展更加容易，因为添加新的观察者不会影响到数据发布者的实现。

当然，观察者模式虽然优点不少，但也需要注意避免出现过多的观察者，造成内存泄露或者过渡通知风险，所以在实际使用时，我们还需要添加一些管理机制，比如及时注销不再需要的观察者，确保系统性能不受影响。

总的来说，观察者模式通过将状态变化的通知与具体的处理逻辑分离，实现了一种低耦合、高扩展性的设计方式。

线程池组成部分

线程池其实就是用来管理和复用线程的一个机制，主要由几个部分构成，每个部分都有它的作用和设计考虑。

首先，我们会看到核心线程数（corePoolSize），这部分线程是一直存在的，当任务到来时，线程池首先会使用核心线程来处理任务。如果任务量持续增加，那么线程池就会考虑增加线程数，直到达到设置的最大线程数。

然后就是最大线程数（maximumPoolSize），这是线程池可以容纳的最大线程数量。通常当工作队列满了，而核心线程已经忙不过来时，线程池会根据需要创建新的线程，不过不会超过这个最大值。

接下来是工作的任务队列（work queue）。这其实就是一个队列，用于存放等待执行的任务。我们一般会选择合适的队列类型，比如无界队列、有限队列或者优先级队列，来根据任务的实际需求决定如何存储等待中的任务。队列的选择直接关系到线程池的性能和任务调度策略。

还有一个很重要的组件是线程工厂（thread factory）。线程工厂主要用于在创建线程的时候进行统一的配置，比如给线程命名、设置线程优先级或者配置线程为守护线程等。这样，我们在调试或者监控程序的时候，就能根据线程名字快速定位问题。

最后还有拒绝策略（rejected execution handler）。当任务太多，超过了队列和线程池所能接受的范围时，线程池就会根据预设的拒绝策略来处理这些额外的任务。常见的策略有直接抛出异常、丢弃任务、丢弃最旧的任务或由调用线程处理。合理选择拒绝策略很重要，能帮助我们避免任务无限堆积导致内存溢出。

总的来说，线程池的这些组成部分协同工作，保证了在任务量大时既能利用资源高效执行任务，又能在资源有限的情况下防止系统过载和崩溃。通过对这些参数的合理配置，我们能更好地控制线程数、防止线程频繁创建销毁，同时保证任务都能按需完成。

sycronized

synchronized 是 Java 里用来实现线程安全的一种关键字，它的作用就是在多线程环境下通过加锁来确保同一时刻只有一个线程可以访问某个代码块或者方法，这样就避免了数据竞争的问题。简单来说，就是让多个线程之间协调访问共享资源，不至于同时修改数据导致线程不安全。

具体讲，synchronized 可以用在方法上，也可以用在代码块上。用在方法上的话，锁住的是整个对象（或者是类的 Class 对象，如果是 static 方法），而用在代码块上则可以更精细地控制锁的范围，我们可以指定具体的对象作为监视器。比如说，如果某段代码只涉及到局部共享资源，我们可以只锁定这一部分代码，而不是整个方法，这样会提高并发性能。

工作原理上，synchronized 实现的方式是利用对象头中的锁标志来判断当前对象是否被占用。当线程进入同步代码块时，就会试图获取这个对象的锁，如果拿到锁就能执行，其他线程则得等待，直到锁被释放。这样就确保了代码的互斥执行。此外，synchronized 还保证了内存可见性，也就是说，当一个线程修改了共享变量，其他线程通过锁的机制一定能看到这些修改。

不过，在使用 synchronized 时也要注意一些问题。第一是锁粒度，如果过于粗大，会影响性能，因为锁住了过多的代码，导致多个线程等待；第二就是可能会引发死锁问题，如果多个线程相互等待对方释放锁，就会系统停滞；还有一个就是单纯的锁会增加线程上下文切换的开销，所以在高并发场景下，我们可能会考虑使用更高级的并发工具类，比如 Lock，或者一些设计模式来优化。

总的来说，synchronized 是一种非常直接且简单的解决并发问题的手段，它内部依赖 JVM 的实现机制来管理对象锁和线程调度。对于一些标准的同步场景来说，使用 synchronized 相对来说非常方便，且安全，但开发时要留心可能带来的性能问题和死锁隐患，要根据具体情况选择合适的工具和方案。

java的扩展机制

首先，我会提到Java的类加载机制，这是Java扩展最基础的一环。Java的类加载器分为几个层次——最顶层是Bootstrap ClassLoader，它负责加载Java核心类库；接下来是Extension ClassLoader（之前常说的ExtClassLoader），它负责加载JRE扩展目录中的类；然后是应用程序的ClassLoader，用来加载我们的项目类、第三方jar等。通过这套层次分明的加载机制，Java可以动态地在运行时加载类，甚至可以通过自定义ClassLoader实现插件化扩展，按需加载或替换部分代码，提高应用的灵活性和扩展性。

再往上看，就是Java提供的SPI（Service Provider Interface）机制，这是一种约定俗成的扩展机制。SPI允许我们定义接口和服务，然后将具体实现打包成独立的jar放在特定目录下，通过ServiceLoader进行动态查找和加载。这样我们在框架设计时就可以让用户自定义实现，或者在不同环境中提供不同的服务，而不需要改变核心代码。

除此之外，还有像Java Agent这样利用Instrumentation API的机制，它允许我们在JVM启动或运行过程中动态地修改字节码，从而实现监控、调试或一些动态增强功能。这种机制也是一种扩展思路，它让我们可以在不修改源代码的情况下对已有系统进行插桩、扩展。

最后，从整体来看，Java的扩展机制体现了设计上的开放封闭原则：对扩展开放、对修改封闭。这种设计不仅让我们可以提前定义好扩展点，还能在运行时通过新加载类或服务的方式来扩展系统功能。在大型系统和框架中，这种机制极大地提高了可维护性和可插拔性。

安卓怎么本地保存数据

其实在Android开发中，本地数据存储有很多方式，具体选哪一种主要看业务需求和数据特性。

首先我们可以用SharedPreferences，它是Android提供的一个简单的键值对存储解决方案。一般来说，对于一些简单的数据，比如用户的配置信息、登录状态或者一些小的偏好设置，我通常会用SharedPreferences来存储。它的优点是使用起来非常方便，操作简单，而且是线程安全的。不过它适用于存的内容比较少，而且数据结构也简单的情况。

如果我们要存储的是文件，比如用户图片、缓存数据或其他二进制数据，就可以用File I/O。直接操作文件系统来读写数据是一个比较低层次的存储方式。可以通过Context提供的文件目录，比如getFilesDir或者getExternalFilesDir来存储应用私有的文件。这样可以保证数据的私密性，不过需要自己管理文件的读写和异常处理。

当然，对于需要存储一些结构化数据，比如较复杂的数据或者需要联动查询的时候，SQLite数据库还是很有用的。Android系统内置了SQLite，可以直接操作数据库，通过SQL语句来插入、删除、更新和查询数据。通常我也会采用开源库，比如Room这个框架，它是SQLite的一个抽象层，通过注解方式更容易的处理数据库操作，同时也可以帮助我们在编译时期检查SQL问题，提高代码健壮性。

再有一点，还有个方案是使用ContentProvider，这个主要是在跨应用间共享数据或者在应用内部对数据提供统一的访问接口时使用。虽然这不是最常见的需求，但在一些特殊业务比如联系人、媒体库这类需要提供数据给系统或者其他应用访问的场景下，ContentProvider是必须的选择。