java

使用场景 背景 不是每一种情况都需要使用 FileProvider 的。啥？你问行不行？有没有毛病？ 这…写了确实可以，没毛病！但是这没有必要啊。 如果不需要FileProvider就不需要定义啊，如

一、SharedPreference 1.1、使用 1.2、commit 和 apply 的区别 commit：直接在主线程中进行写入操作，属于同步提交，返回boolean值。容易阻塞主线程导致ANR

一、请求过程 首先来看一个最简单的Http请求是如何发送的。 这段代码看起来比较简单,OkHttp请求过程中最少只需要接触OkHttpClient、Request、Call、 Response，但是框

一、图片加载框架对比 首先，当下流行的图片加载框架有那么几个，可以拿 Glide 跟Fresco对比，例如这些： Glide： 多种图片格式的缓存，适用于更多的内容表现形式（如Gif、WebP、缩略图

一、单例模式种类 1.1、懒汉式V1 缺点：线程不安全。 1.2、懒汉式V2(线程安全) 这种方式线程安全，getInstance() 方法进行了线程同步，但是这种方式不推荐使用。 缺点：效率太低 1

什么时候用策略模式？我认为是情况比较多的时候。比如：情况1要怎么怎么样，情况2则要怎么怎么样。简单来说就是：不同的情况对应不同的方案。 什么时候用适配器模式？我认为非常适合那种功能相同，字段不同的情况

一、mvc 流程图如下： 缺点： C层单向调用M层和V层，大部分逻辑都集中在C层，代码量也集中在C层，这带给C层很大压力； V层和M层分离，数据感应依靠监听M层，这样V层就无法复用。 二、mvp 为了

Android中调用JS方法 首先在Android中新增一个按钮，并设置其点击事件 点击事件中调用了callJs方法，然后再activity中实现该方法 然后在JS中实现该方法 如果要传递参数，最简单

一、模块间调用思路 假设现有: app、login、common三个module，其中app跟login无关联，并且都依赖于common，其中app中有个MainActivity，login想要调用M

Activity(Fragment) 的 ViewModel 都存储在 ViewModelStore 中，每个 Activity(Fragment) 都会拥有一个 ViewModelStore 实例。

一、背景 我想在界面弹出toast，这个toast的内容我保存在ViewModel中的一个LiveData变量中： 然后在网络加载失败时给它赋值： 接着在View层进行observe，代码如下： 这里

一、背景 我们在处理Activity或者Fragment组件的生命周期相关时，不可避免会遇到这样的问题： 我们在Activity的onCreate()中初始化某些成员（比如MVP架构中的Present

一、自适应布局 分别为不同的屏幕分辨率定义布局，即创建多个静态布局，每个静态布局对应一个屏幕分辨率范围。改变屏幕分辨率可以切换不同的静态局部（页面元素位置发生改变），但在每个静态布局中，页面元素不随窗

一、前言 二、结论 RelativeLayout会让子View调用2次onMeasure，LinearLayout 在有weight时，也会调用子View2次onMeasure，否则只有一次。 Rel

Android是基于消息驱动的，当进程创建后，ActivityThread的main方法会创建Looper并调用loop()方法开启消息循环； 当handler调用sendMessage或者post方

一、volatile 一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义： 禁止进行指令重排序。 保证不同线程对这个变量进行操作时的可见性。即一个线程修

一、线程的创建 1.1、继承Thread 1.2、实现Runnable接口 因为 Runnable 没有给我们提供启动线程的方法，因此我们需要借助 Thread 类来启动。 1.3、实现Callabl

一、绘制入口源码分析 从Activity的startActivity开始，最终调用到ActivityThread的handleLaunchActivity方法来创建Activity，相关核心代码如下：

在系统启动过程中，通过zygote进程fork了一个SystemServer进程，而在这个进程中，启动了系统所必须的各种核心服务，其中AMS就是其中的重要的一个。 AMS会调用一个systemRead

一、用户空间和内核空间 我们知道操作系统采用的是虚拟地址空间，以32位操作系统举例，它的寻址空间为4G(2的32次方)。 os分配给每个进程一个独立的、连续的、虚拟的地址内存空间，该大小一般是4G（3