史上最全的Android面试题集锦在这里，一定要收藏！（Android基本篇）(2)

onStartCommand

onStartCommand: 在执行了startService方法之后，有可能会调用Service的onCreate方法，在这之后一定会执行Service的onStartCommand回调方法。也就是说，如果多次执行了Context的startService方法，那么Service的onStartCommand方法也会相应的多次调用。onStartCommand方法很重要，我们在该方法中根据传入的Intent参数进行实际的操作，比如会在此处创建一个线程用于下载数据或播放音乐等。

public @StartResult int onStartCommand(Intent intent, @StartArgFlags int flags, int startId) {
}

当Android面临内存匮乏的时候，可能会销毁掉你当前运行的Service，然后待内存充足的时候可以重新创建Service，Service被Android系统强制销毁并再次重建的行为依赖于Service中onStartCommand方法的返回值。我们常用的返回值有三种值，START_NOT_STICKY、START_STICKY和START_REDELIVER_INTENT，这三个值都是Service中的静态常量。

START_NOT_STICKY

如果返回START_NOT_STICKY，表示当Service运行的进程被Android系统强制杀掉之后，不会重新创建该Service，当然如果在其被杀掉之后一段时间又调用了startService，那么该Service又将被实例化。那什么情境下返回该值比较恰当呢？如果我们某个Service执行的工作被中断几次无关紧要或者对Android内存紧张的情况下需要被杀掉且不会立即重新创建这种行为也可接受，那么我们便可将 onStartCommand的返回值设置为START_NOT_STICKY。举个例子，某个Service需要定时从服务器获取最新数据：通过一个定时器每隔指定的N分钟让定时器启动Service去获取服务端的最新数据。当执行到Service的onStartCommand时，在该方法内再规划一个N分钟后的定时器用于再次启动该Service并开辟一个新的线程去执行网络操作。假设Service在从服务器获取最新数据的过程中被Android系统强制杀掉，Service不会再重新创建，这也没关系，因为再过N分钟定时器就会再次启动该Service并重新获取数据。

START_STICKY

如果返回START_STICKY，表示Service运行的进程被Android系统强制杀掉之后，Android系统会将该Service依然设置为started状态（即运行状态），但是不再保存onStartCommand方法传入的intent对象，然后Android系统会尝试再次重新创建该Service，并执行onStartCommand回调方法，但是onStartCommand回调方法的Intent参数为null，也就是onStartCommand方法虽然会执行但是获取不到intent信息。如果你的Service可以在任意时刻运行或结束都没什么问题，而且不需要intent信息，那么就可以在onStartCommand方法中返回START_STICKY，比如一个用来播放背景音乐功能的Service就适合返回该值。

START_REDELIVER_INTENT

如果返回START_REDELIVER_INTENT，表示Service运行的进程被Android系统强制杀掉之后，与返回START_STICKY的情况类似，Android系统会将再次重新创建该Service，并执行onStartCommand回调方法，但是不同的是，Android系统会再次将Service在被杀掉之前最后一次传入onStartCommand方法中的Intent再次保留下来并再次传入到重新创建后的Service的onStartCommand方法中，这样我们就能读取到intent参数。只要返回START_REDELIVER_INTENT，那么onStartCommand重的intent一定不是null。如果我们的Service需要依赖具体的Intent才能运行（需要从Intent中读取相关数据信息等），并且在强制销毁后有必要重新创建运行，那么这样的Service就适合返回START_REDELIVER_INTENT。

onBind

Service中的onBind方法是抽象方法，所以Service类本身就是抽象类，也就是onBind方法是必须重写的，即使我们用不到。在通过startService使用Service时，我们在重写onBind方法时，只需要将其返回null即可。onBind方法主要是用于给bindService方法调用Service时才会使用到。

onDestroy

onDestroy: 通过startService方法启动的Service会无限期运行，只有当调用了Context的stopService或在Service内部调用stopSelf方法时，Service才会停止运行并销毁，在销毁的时候会执行Service回调函数。

2.3、bindService生命周期

bindService方式启动Service主要有以下几个生命周期函数：

• **onCreate()：**首次创建服务时，系统将调用此方法。如果服务已在运行，则不会调用此方法，该方法只调用一次。
• **onStartCommand()：**当另一个组件通过调用startService()请求启动服务时，系统将调用此方法。
• **onDestroy()：**当服务不再使用且将被销毁时，系统将调用此方法。
• **onBind()：**当另一个组件通过调用bindService()与服务绑定时，系统将调用此方法。
• **onUnbind()：**当另一个组件通过调用unbindService()与服务解绑时，系统将调用此方法。
• **onRebind()：**当旧的组件与服务解绑后，另一个新的组件与服务绑定，onUnbind()返回true时，系统将调用此方法。

3、fragemnt

3.1、创建方式

（1）静态创建

首先我们需要创建一个xml文件，然后创建与之对应的java文件，通过onCreatView()的返回方法进行关联，最后我们需要在Activity中进行配置相关参数即在Activity的xml文件中放上fragment的位置。

（2）动态创建

动态创建Fragment主要有以下几个步骤：

1. 创建待添加的fragment实例。
2. 获取FragmentManager，在Activity中可以直接通过调用 getSupportFragmentManager（）方法得到。
3. 开启一个事务，通过调用beginTransaction()方法开启。
4. 向容器内添加或替换fragment，一般使用repalce()方法实现，需要传入容器的id和待添加的fragment实例。
5. 提交事务，调用commit()方法来完成。

3.2、Adapter对比

FragmnetPageAdapter在每次切换页面时，只是将Fragment进行分离，适合页面较少的Fragment使用以保存一些内存，对系统内存不会多大影响。

FragmentPageStateAdapter在每次切换页面的时候，是将Fragment进行回收，适合页面较多的Fragment使用，这样就不会消耗更多的内存

3.3、Activity生命周期

Activity的生命周期如下图：

（1）动态加载：

动态加载时，Activity的onCreate()调用完，才开始加载fragment并调用其生命周期方法，所以在第一个生命周期方法onAttach()中便能获取Activity以及Activity的布局的组件；

（2）静态加载：

1.静态加载时，Activity的onCreate()调用过程中，fragment也在加载，所以fragment无法获取到Activity的布局中的组件，但为什么能获取到Activity呢？

2.原来在fragment调用onAttach()之前其实还调用了一个方法onInflate()，该方法被调用时fragment已经是和Activity相互结合了，所以可以获取到对方，但是Activity的onCreate()调用还未完成，故无法获取Activity的组件；

3.Activity的onCreate()调用完成是，fragment会调用onActivityCreated()生命周期方法，因此在这儿开始便能获取到Activity的布局的组件；

3.4、与Activity通信

fragment不通过构造函数进行传值的原因是因为横屏切换的时候获取不到值。

Activity向Fragment传值：

Activity向Fragment传值，要传的值放到bundle对象里；
在Activity中创建该Fragment的对象fragment，通过调用setArguments()传递到fragment中；
在该Fragment中通过调用getArguments()得到bundle对象，就能得到里面的值。

Fragment向Activity传值：

第一种：

在Activity中调用getFragmentManager()得到fragmentManager,，调用findFragmentByTag(tag)或者通过findFragmentById(id)，例如：

FragmentManager fragmentManager = getFragmentManager()；

Fragment fragment = fragmentManager.findFragmentByTag(tag)；

第二种：

通过回调的方式，定义一个接口（可以在Fragment类中定义），接口中有一个空的方法，在fragment中需要的时候调用接口的方法，值可以作为参数放在这个方法中，然后让Activity实现这个接口，必然会重写这个方法，这样值就传到了Activity中

Fragment与Fragment之间是如何传值的：

第一种：

通过findFragmentByTag得到另一个的Fragment的对象，这样就可以调用另一个的方法了。

第二种：

通过接口回调的方式。

第三种：

通过setArguments，getArguments的方式。

3.5、api区别

add

一种是add方式来进行show和add，这种方式你切换fragment不会让fragment重新刷新，只会调用onHiddenChanged(boolean isHidden)。

replace

而用replace方式会使fragment重新刷新，因为add方式是将fragment隐藏了而不是销毁再创建，replace方式每次都是重新创建。

commit/commitAllowingStateLoss

两者都可以提交fragment的操作，唯一的不同是第二种方法，允许丢失一些界面的状态和信息，几乎所有的开发者都遇到过这样的错误：无法在activity调用了onSaveInstanceState之后再执行commit（），这种异常时可以理解的，界面被系统回收（界面已经不存在），为了在下次打开的时候恢复原来的样子，系统为我们保存界面的所有状态，这个时候我们再去修改界面理论上肯定是不允许的，所以为了避免这种异常，要使用第二种方法。

3.懒加载

我们经常在使用fragment时，常常会结合着viewpager使用，那么我们就会遇到一个问题，就是初始化fragment的时候，会连同我们写的网络请求一起执行，这样非常消耗性能，最理想的方式是，只有用户点开或滑动到当前fragment时，才进行请求网络的操作。因此，我们就产生了懒加载这样一个说法。

Viewpager配合fragment使用，默认加载前两个fragment。很容易造成网络丢包、阻塞等问题。

在Fragment中有一个setUserVisibleHint这个方法，而且这个方法是优于onCreate()方法的，它会通过isVisibleToUser告诉我们当前Fragment我们是否可见，我们可以在可见的时候再进行网络加载。

从log上看setUserVisibleHint（）的调用早于onCreateView，所以如果在setUserVisibleHint（）要实现懒加载的话，就必须要确保View以及其他变量都已经初始化结束，避免空指针。

使用步骤：

申明一个变量isPrepare=false，isVisible=false,标明当前页面是否被创建了
在onViewCreated周期内设置isPrepare=true
在setUserVisibleHint（boolean isVisible）判断是否显示，设置isVisible=true
判断isPrepare和isVisible，都为true开始加载数据，然后恢复isPrepare和isVisible为false，防止重复加载。

关于Android Fragment的懒加载，可以参考下面的链接：Fragment的懒加载

4、Activity

4.1、 Activity启动流程

用户从Launcher程序点击应用图标可启动应用的入口Activity，Activity启动时需要多个进程之间的交互，Android系统中有一个zygote进程专用于孵化Android框架层和应用层程序的进程。还有一个system_server进程，该进程里运行了很多binder service。例如ActivityManagerService，PackageManagerService，WindowManagerService，这些binder service分别运行在不同的线程中，其中ActivityManagerService负责管理Activity栈，应用进程，task。

点击Launcher图标来启动Activity

用户在Launcher程序里点击应用图标时，会通知ActivityManagerService启动应用的入口Activity，ActivityManagerService发现这个应用还未启动，则会通知Zygote进程孵化出应用进程，然后在这个dalvik应用进程里执行ActivityThread的main方法。应用进程接下来通知ActivityManagerService应用进程已启动，ActivityManagerService保存应用进程的一个代理对象，这样ActivityManagerService可以通过这个代理对象控制应用进程，然后ActivityManagerService通知应用进程创建入口Activity的实例，并执行它的生命周期方法。

Android绘制流程窗口启动流程分析

4.2、Activity生命周期
[图片上传失败…(image-5d39aa-1563437438372)]

（1）Activity的形态

Active/Running:

Activity处于活动状态，此时Activity处于栈顶，是可见状态，可与用户进行交互。

Paused：

当Activity失去焦点时，或被一个新的非全屏的Activity，或被一个透明的Activity放置在栈顶时，Activity就转化为Paused状态。但我们需要明白，此时Activity只是失去了与用户交互的能力，其所有的状态信息及其成员变量都还存在，只有在系统内存紧张的情况下，才有可能被系统回收掉。

Stopped：

当一个Activity被另一个Activity完全覆盖时，被覆盖的Activity就会进入Stopped状态，此时它不再可见，但是跟Paused状态一样保持着其所有状态信息及其成员变量。

Killed：

当Activity被系统回收掉时，Activity就处于Killed状态。

Activity会在以上四种形态中相互切换，至于如何切换，这因用户的操作不同而异。了解了Activity的4种形态后，我们就来聊聊Activity的生命周期。

Activity的生命周期

所谓的典型的生命周期就是在有用户参与的情况下，Activity经历从创建，运行，停止，销毁等正常的生命周期过程。

onCreate

该方法是在Activity被创建时回调，它是生命周期第一个调用的方法，我们在创建Activity时一般都需要重写该方法，然后在该方法中做一些初始化的操作，如通过setContentView设置界面布局的资源，初始化所需要的组件信息等。

onStart

此方法被回调时表示Activity正在启动，此时Activity已处于可见状态，只是还没有在前台显示，因此无法与用户进行交互。可以简单理解为Activity已显示而我们无法看见摆了。

onResume

当此方法回调时，则说明Activity已在前台可见，可与用户交互了（处于前面所说的Active/Running形态），onResume方法与onStart的相同点是两者都表示Activity可见，只不过onStart回调时Activity还是后台无法与用户交互，而onResume则已显示在前台，可与用户交互。当然从流程图，我们也可以看出当Activity停止后（onPause方法和onStop方法被调用），重新回到前台时也会调用onResume方法，因此我们也可以在onResume方法中初始化一些资源，比如重新初始化在onPause或者onStop方法中释放的资源。

onPause

此方法被回调时则表示Activity正在停止（Paused形态），一般情况下onStop方法会紧接着被回调。但通过流程图我们还可以看到一种情况是onPause方法执行后直接执行了onResume方法，这属于比较极端的现象了，这可能是用户操作使当前Activity退居后台后又迅速地再回到到当前的Activity，此时onResume方法就会被回调。当然，在onPause方法中我们可以做一些数据存储或者动画停止或者资源回收的操作，但是不能太耗时，因为这可能会影响到新的Activity的显示——onPause方法执行完成后，新Activity的onResume方法才会被执行。

onStop

一般在onPause方法执行完成直接执行，表示Activity即将停止或者完全被覆盖（Stopped形态），此时Activity不可见，仅在后台运行。同样地，在onStop方法可以做一些资源释放的操作（不能太耗时）。

onRestart

表示Activity正在重新启动，当Activity由不可见变为可见状态时，该方法被回调。这种情况一般是用户打开了一个新的Activity时，当前的Activity就会被暂停（onPause和onStop被执行了），接着又回到当前Activity页面时，onRestart方法就会被回调。

onDestroy

此时Activity正在被销毁，也是生命周期最后一个执行的方法，一般我们可以在此方法中做一些回收工作和最终的资源释放。

小结

到这里我们来个小结，当Activity启动时，依次会调用onCreate(),onStart(),onResume()，而当Activity退居后台时（不可见，点击Home或者被新的Activity完全覆盖），onPause()和onStop()会依次被调用。当Activity重新回到前台（从桌面回到原Activity或者被覆盖后又回到原Activity）时，onRestart()，onStart()，onResume()会依次被调用。当Activity退出销毁时（点击back键），onPause()，onStop()，onDestroy()会依次被调用，到此Activity的整个生命周期方法回调完成。现在我们再回头看看之前的流程图，应该是相当清晰了吧。嗯，这就是Activity整个典型的生命周期过程。

2、 View部分知识点

Android的Activity、PhoneWindow和DecorView的关系可以用下面的图表示：
[图片上传失败…(image-3d13cc-1563437438372)]

2.1、DecorView浅析

例如，有下面一个视图，DecorView为整个Window界面的最顶层View，它只有一个子元素LinearLayout。代表整个Window界面，包含通知栏、标题栏、内容显示栏三块区域。其中LinearLayout中有两个FrameLayout子元素。
[图片上传失败…(image-688f39-1563437438372)]

DecorView的作用

DecorView是顶级View，本质是一个FrameLayout它包含两部分，标题栏和内容栏，都是FrameLayout。内容栏id是content，也就是activity中设置setContentView的部分，最终将布局添加到id为content的FrameLayout中。
获取content：ViewGroup content=findViewById（android.id.content）
获取设置的View：getChildAt(0).

使用总结

每个Activity都包含一个Window对象，Window对象通常是由PhoneWindow实现的。
PhoneWindow：将DecorView设置为整个应用窗口的根View，是Window的实现类。它是Android中的最基本的窗口系统，每个Activity均会创建一个PhoneWindow对象，是Activity和整个View系统交互的接口。
DecorView：是顶层视图，将要显示的具体内容呈现在PhoneWindow上，DecorView是当前Activity所有View的祖先，它并不会向用户呈现任何东西。

2.2、View的事件分发

View的事件分发机制可以使用下图表示：
[图片上传失败…(image-53f251-1563437438372)]
如上图，图分为3层，从上往下依次是Activity、ViewGroup、View。

1. 事件从左上角那个白色箭头开始，由Activity的dispatchTouchEvent做分发
2. 箭头的上面字代表方法返回值，（return true、return false、return super.xxxxx(),super
   的意思是调用父类实现。
3. dispatchTouchEvent和 onTouchEvent的框里有个【true---->消费】的字，表示的意思是如果方法返回true，那么代表事件就此消费，不会继续往别的地方传了，事件终止。
4. 目前所有的图的事件是针对ACTION_DOWN的，对于ACTION_MOVE和ACTION_UP我们最后做分析。
5. 之前图中的Activity 的dispatchTouchEvent 有误（图已修复），只有return 
   super.dispatchTouchEvent(ev) 才是往下走，返回true 或者 false 事件就被消费了（终止传递）。

ViewGroup事件分发

当一个点击事件产生后，它的传递过程将遵循如下顺序：

Activity -> Window -> View

事件总是会传递给Activity，之后Activity再传递给Window，最后Window再传递给顶级的View，顶级的View在接收到事件后就会按照事件分发机制去分发事件。如果一个View的onTouchEvent返回了FALSE，那么它的父容器的onTouchEvent将会被调用，依次类推，如果所有都不处理这个事件的话，那么Activity将会处理这个事件。

对于ViewGroup的事件分发过程，大概是这样的：如果顶级的ViewGroup拦截事件即onInterceptTouchEvent返回true的话，则事件会交给ViewGroup处理，如果ViewGroup的onTouchListener被设置的话，则onTouch将会被调用，否则的话onTouchEvent将会被调用，也就是说：两者都设置的话，onTouch将会屏蔽掉onTouchEvent，在onTouchEvent中，如果设置了onClickerListener的话，那么onClick将会被调用。如果顶级ViewGroup不拦截的话，那么事件将会被传递给它所在的点击事件的子view，这时候子view的dispatchTouchEvent将会被调用

View的事件分发

dispatchTouchEvent -> onTouch(setOnTouchListener) -> onTouchEvent -> onClick

onTouch和onTouchEvent的区别
两者都是在dispatchTouchEvent中调用的，onTouch优先于onTouchEvent，如果onTouch返回true，那么onTouchEvent则不执行，及onClick也不执行。

2.3、View的绘制

在xml布局文件中，我们的layout_width和layout_height参数可以不用写具体的尺寸，而是wrap_content或者是match_parent。这两个设置并没有指定真正的大小，可是我们绘制到屏幕上的View必须是要有具体的宽高的，正是因为这个原因，我们必须自己去处理和设置尺寸。当然了，View类给了默认的处理，但是如果View类的默认处理不满足我们的要求，我们就得重写onMeasure函数啦~。

onMeasure函数是一个int整数，里面放了测量模式和尺寸大小。int型数据占用32个bit，而google实现的是，将int数据的前面2个bit用于区分不同的布局模式，后面30个bit存放的是尺寸的数据。
onMeasure函数的使用如下图：
[图片上传失败…(image-976764-1563437438372)]
MeasureSpec有三种测量模式：
[图片上传失败…(image-173c13-1563437438372)]

match_parent—>EXACTLY。怎么理解呢？match_parent就是要利用父View给我们提供的所有剩余空间，而父View剩余空间是确定的，也就是这个测量模式的整数里面存放的尺寸。

wrap_content—>AT_MOST。怎么理解：就是我们想要将大小设置为包裹我们的view内容，那么尺寸大小就是父View给我们作为参考的尺寸，只要不超过这个尺寸就可以啦，具体尺寸就根据我们的需求去设定。

固定尺寸（如100dp）—>EXACTLY。用户自己指定了尺寸大小，我们就不用再去干涉了，当然是以指定的大小为主啦。

[图片上传失败…(image-d2d240-1563437438372)]
[图片上传失败…(image-302ec-1563437438372)]

2.4、ViewGroup的绘制

自定义ViewGroup可就没那么简单啦~，因为它不仅要管好自己的，还要兼顾它的子View。我们都知道ViewGroup是个View容器，它装纳child View并且负责把child View放入指定的位置。

1. 首先，我们得知道各个子View的大小吧，只有先知道子View的大小，我们才知道当前的ViewGroup该设置为多大去容纳它们。
2. 根据子View的大小，以及我们的ViewGroup要实现的功能，决定出ViewGroup的大小
3. ViewGroup和子View的大小算出来了之后，接下来就是去摆放了吧，具体怎么去摆放呢？这得根据你定制的需求去摆放了，比如，你想让子View按照垂直顺序一个挨着一个放，或者是按照先后顺序一个叠一个去放，这是你自己决定的。
4. 已经知道怎么去摆放还不行啊，决定了怎么摆放就是相当于把已有的空间”分割”成大大小小的空间，每个空间对应一个子View，我们接下来就是把子View对号入座了，把它们放进它们该放的地方去。

[图片上传失败…(image-e5bc1a-1563437438372)]
[图片上传失败…(image-bba240-1563437438372)]

自定义ViewGroup可以参考：Android自定义ViewGroup

3、系统原理

3.1、打包原理

Android的包文件APK分为两个部分：代码和资源，所以打包方面也分为资源打包和代码打包两个方面，这篇文章就来分析资源和代码的编译打包原理。

具体说来：

1. 通过AAPT工具进行资源文件（包括AndroidManifest.xml、布局文件、各种xml资源等）的打包，生成R.java文件。
2. 通过AIDL工具处理AIDL文件，生成相应的Java文件。
3. 通过Javac工具编译项目源码，生成Class文件。
4. 通过DX工具将所有的Class文件转换成DEX文件，该过程主要完成Java字节码转换成Dalvik字节码，压缩常量池以及清除冗余信息等工作。
5. 通过ApkBuilder工具将资源文件、DEX文件打包生成APK文件。
6. 利用KeyStore对生成的APK文件进行签名。
7. 如果是正式版的APK，还会利用ZipAlign工具进行对齐处理，对齐的过程就是将APK文件中所有的资源文件举例文件的起始距离都偏移4字节的整数倍，这样通过内存映射访问APK文件的速度会更快。

[图片上传失败…(image-4212d0-1563437438372)]

3.2、安装流程

Android apk的安装过程主要氛围以下几步：

1. 复制APK到/data/app目录下，解压并扫描安装包。
2. 资源管理器解析APK里的资源文件。
3. 解析AndroidManifest文件，并在/data/data/目录下创建对应的应用数据目录。
4. 然后对dex文件进行优化，并保存在dalvik-cache目录下。
5. 将AndroidManifest文件解析出的四大组件信息注册到PackageManagerService中。
6. 安装完成后，发送广播。

可以使用下面的图表示：
[图片上传失败…(image-f88862-1563437438372)]

4、 第三方库解析

4.1、Retrofit网络请求框架

概念：Retrofit是一个基于RESTful的HTTP网络请求框架的封装，其中网络请求的本质是由OKHttp完成的，而Retrofit仅仅负责网络请求接口的封装。

原理：App应用程序通过Retrofit请求网络，实际上是使用Retrofit接口层封装请求参数，Header、URL等信息，之后由OKHttp完成后续的请求，在服务器返回数据之后，OKHttp将原始的结果交给Retrofit，最后根据用户的需求对结果进行解析。

retrofit使用

1.在retrofit中通过一个接口作为http请求的api接口

public interface NetApi {
@GET(“repos/{owner}/{repo}/contributors”)
Call contributorsBySimpleGetCall(@Path(“owner”) String owner, @Path(“repo”) String repo);
}

2.创建一个Retrofit实例

Retrofit retrofit = new Retrofit.Builder()
.baseUrl(“https://api.github.com/”)
.build();

3.调用api接口

NetApi repo = retrofit.create(NetApi.class);

//第三步：调用网络请求的接口获取网络请求
retrofit2.Call call = repo.contributorsBySimpleGetCall(“username”, “path”);
call.enqueue(new Callback() { //进行异步请求
@Override
public void onResponse(Call call, Response response) {
//进行异步操作
}

@Override
public void onFailure(Call call, Throwable t) {
//执行错误回调方法
}
});

retrofit动态代理

retrofit执行的原理如下：
1.首先，通过method把它转换成ServiceMethod。
2.然后，通过serviceMethod，args获取到okHttpCall对象。
3.最后，再把okHttpCall进一步封装并返回Call对象。
首先，创建retrofit对象的方法如下：

Retrofit retrofit = new Retrofit.Builder()
.baseUrl(“https://api.github.com/”)
.build();

在创建retrofit对象的时候用到了build()方法，该方法的实现如下：

public Retrofit build() {
if (baseUrl == null) {
throw new IllegalStateException(“Base URL required.”);
}

okhttp3.Call.Factory callFactory = this.callFactory;
if (callFactory == null) {
callFactory = new OkHttpClient(); //设置kHttpClient
}

Executor callbackExecutor = this.callbackExecutor;
if (callbackExecutor == null) {
callbackExecutor = platform.defaultCallbackExecutor(); //设置默认回调执行器
}

// Make a defensive copy of the adapters and add the default Call adapter.
List<CallAdapter.Factory> adapterFactories = new ArrayList<>(this.adapterFactories);
adapterFactories.add(platform.defaultCallAdapterFactory(callbackExecutor));

// Make a defensive copy of the converters.
List<Converter.Factory> converterFactories = new ArrayList<>(this.converterFactories);

return new Retrofit(callFactory, baseUrl, converterFactories, adapterFactories,
callbackExecutor, validateEagerly); //返回新建的Retrofit对象
}

该方法返回了一个Retrofit对象，通过retrofit对象创建网络请求的接口的方式如下：

NetApi repo = retrofit.create(NetApi.class);

retrofit对象的create()方法的实现如下：‘

public T create(final Class service) {
Utils.validateServiceInterface(service);
if (validateEagerly) {
eagerlyValidateMethods(service);
}
return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class<?>[] { service },
new InvocationHandler() {
private final Platform platform = Platform.get();

@Override public Object invoke(Object proxy, Method method, Object… args)
throws Throwable {
// If the method is a method from Object then defer to normal invocation.
if (method.getDeclaringClass() == Object.class) {
return method.invoke(this, args); //直接调用该方法
}
if (platform.isDefaultMethod(method)) {
return platform.invokeDefaultMethod(method, service, proxy, args); //通过平台对象调用该方法
}
ServiceMethod serviceMethod = loadServiceMethod(method); //获取ServiceMethod对象
OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args); //传入参数生成okHttpCall对象
return serviceMethod.callAdapter.adapt(okHttpCall); //执行okHttpCall
}
});
}

4.2、图片加载库对比

Picasso：120K

Glide：475K

Fresco：3.4M

Android-Universal-Image-Loader：162K

图片函数库的选择需要根据APP的具体情况而定，对于严重依赖图片缓存的APP，例如壁纸类，图片社交类APP来说，可以选择最专业的Fresco。对于一般的APP，选择Fresco会显得比较重，毕竟Fresco3.4M的体量摆在这。根据APP对图片的显示和缓存的需求从低到高，我们可以对以上函数库做一个排序。

Picasso < Android-Universal-Image-Loader < Glide < Fresco

2.介绍:

Picasso ：和Square的网络库一起能发挥最大作用，因为Picasso可以选择将网络请求的缓存部分交给了okhttp实现。

Glide：模仿了Picasso的API，而且在他的基础上加了很多的扩展(比如gif等支持)，Glide默认的Bitmap格式是RGB_565，比 Picasso默认的ARGB_8888格式的内存开销要小一半；Picasso缓存的是全尺寸的(只缓存一种)，而Glide缓存的是跟ImageView尺寸相同的(即5656和128128是两个缓存) 。

FB的图片加载框架Fresco：最大的优势在于5.0以下(最低2.3)的bitmap加载。在5.0以下系统，Fresco将图片放到一个特别的内存区域(Ashmem区)。当然，在图片不显示的时候，占用的内存会自动被释放。这会使得APP更加流畅，减少因图片内存占用而引发的OOM。为什么说是5.0以下，因为在5.0以后系统默认就是存储在Ashmem区了。

3.总结：

Picasso所能实现的功能，Glide都能做，无非是所需的设置不同。但是Picasso体积比起Glide小太多如果项目中网络请求本身用的就是okhttp或者retrofit(本质还是okhttp)，那么建议用Picasso，体积会小很多(Square全家桶的干活)。Glide的好处是大型的图片流，比如gif、Video，如果你们是做美拍、爱拍这种视频类应用，建议使用。

Fresco在5.0以下的内存优化非常好，代价就是体积也非常的大，按体积算Fresco>Glide>Picasso

不过在使用起来也有些不便（小建议：他只能用内置的一个ImageView来实现这些功能，用起来比较麻烦，我们通常是根据Fresco自己改改，直接使用他的Bitmap层）

4.3、各种json解析库使用

参考链接：https://www.cnblogs.com/kunpe…

（1）Google的Gson

Gson是目前功能最全的Json解析神器，Gson当初是为因应Google公司内部需求而由Google自行研发而来，但自从在2008年五月公开发布第一版后已被许多公司或用户应用。Gson的应用主要为toJson与fromJson两个转换函数，无依赖，不需要例外额外的jar，能够直接跑在JDK上。而在使用这种对象转换之前需先创建好对象的类型以及其成员才能成功的将JSON字符串成功转换成相对应的对象。类里面只要有get和set方法，Gson完全可以将复杂类型的json到bean或bean到json的转换，是JSON解析的神器。Gson在功能上面无可挑剔，但是性能上面比FastJson有所差距。

（2）阿里巴巴的FastJson

Fastjson是一个Java语言编写的高性能的JSON处理器,由阿里巴巴公司开发。

无依赖，不需要例外额外的jar，能够直接跑在JDK上。FastJson在复杂类型的Bean转换Json上会出现一些问题，可能会出现引用的类型，导致Json转换出错，需要制定引用。FastJson采用独创的算法，将parse的速度提升到极致，超过所有json库。

综上Json技术的比较，在项目选型的时候可以使用Google的Gson和阿里巴巴的FastJson两种并行使用，如果只是功能要求，没有性能要求，可以使用google的Gson，如果有性能上面的要求可以使用Gson将bean转换json确保数据的正确，使用FastJson将Json转换Bean

5、热点技术

参考链接- Android组件化方案

5.1、组件化

（1）概念：

组件化：是将一个APP分成多个module，每个module都是一个组件，也可以是一个基础库供组件依赖，开发中可以单独调试部分组件，组件中不需要相互依赖但是可以相互调用，最终发布的时候所有组件以lib的形式被主APP工程依赖打包成一个apk。

（2）由来：

1. APP版本迭代，新功能不断增加，业务变得复杂，维护成本高
2. 业务耦合度高，代码臃肿，团队内部多人协作开发困难
3. Android编译代码卡顿，单一工程下代码耦合严重，修改一处需要重新编译打包，耗时耗力。
4. 方便单元测试，单独改一个业务模块，不需要着重关注其他模块。

（3）优势：

1. 组件化将通用模块独立出来，统一管理，以提高复用，将页面拆分为粒度更小的组件，组件内部出了包含UI实现，还可以包含数据层和逻辑层
2. 每个组件度可以独立编译、加快编译速度、独立打包。
3. 每个工程内部的修改，不会影响其他工程。
4. 业务库工程可以快速拆分出来，集成到其他App中。
5. 迭代频繁的业务模块采用组件方式，业务线研发可以互不干扰、提升协作效率，并控制产品质量，加强稳定性。
6. 并行开发，团队成员只关注自己的开发的小模块，降低耦合性，后期维护方便等。

（4）考虑问题：

模式切换：如何使得APP在单独调试跟整体调试自由切换

组件化后的每一个业务的module都可以是一个单独的APP（isModuleRun=false）， release 包的时候各个业务module作为lib依赖，这里完全由一个变量控制，在根项目 gradle.properties里面isModuleRun=true。isModuleRun状态不同，加载application和AndroidManifest都不一样，以此来区分是独立的APK还是lib。

在build.grade里面配置：

[图片上传失败…(image-a2acff-1563437438371)]

资源冲突

当我们创建了多个Module的时候，如何解决相同资源文件名合并的冲突，业务Module和BaseModule资源文件名称重复会产生冲突，解决方案在于：

每个 module 都有 app_name，为了不让资源名重名，在每个组件的 build.gradle 中增加 resourcePrefix “xxx_强行检查资源名称前缀。固定每个组件的资源前缀。但是 resourcePrefix 这个值只能限定 xml 里面的资源，并不能限定图片资源。

依赖关系

多个Module之间如何引用一些共同的library以及工具类

组件通信

组件化之后，Module之间是相互隔离的，如何进行UI跳转以及方法调用，具体可以使用阿里巴巴ARouter或者美团的WMRouter等路由框架。

各业务Module之前不需要任何依赖可以通过路由跳转，完美解决业务之间耦合。

入口参数

我们知道组件之间是有联系的，所以在单独调试的时候如何拿到其它的Module传递过来的参数

Application

当组件单独运行的时候，每个Module自成一个APK，那么就意味着会有多个Application，很显然我们不愿意重复写这么多代码，所以我们只需要定义一个BaseApplication即可，其它的Application直接继承此BaseApplication就OK了，BaseApplication里面还可定义公用的参数。

关于如何进行组件化，可以参考：安居客Android项目架构演进

5.2、插件化

参考链接- 插件化入门

（1）概述

提到插件化，就不得不提起方法数超过65535的问题，我们可以通过Dex分包来解决，同时也可以通过使用插件化开发来解决。插件化的概念就是由宿主APP去加载以及运行插件APP。

面试宝典

面试必问知识点、BATJ历年历年面试真题+解析

学习经验总结

（一）调整好心态
心态是一个人能否成功的关键，如果不调整好自己的心态，是很难静下心来学习的，尤其是现在这么浮躁的社会，大部分的程序员的现状就是三点一线，感觉很累，一些大龄的程序员更多的会感到焦虑，而且随着年龄的增长，这种焦虑感会越来越强烈，那么唯一的解决办法就是调整好自己的心态，要做到自信、年轻、勤奋。这样的调整，一方面对自己学习有帮助，另一方面让自己应对面试更从容，更顺利。

（二）时间挤一挤，制定好计划
一旦下定决心要提升自己，那么再忙的情况下也要每天挤一挤时间，切记不可“两天打渔三天晒网”。另外，制定好学习计划也是很有必要的，有逻辑有条理的复习，先查漏补缺，然后再系统复习，这样才能够做到事半功倍，效果才会立竿见影。

（三）不断学习技术知识，更新自己的知识储备
对于一名程序员来说，技术知识方面是非常重要的，可以说是重中之重。要面试大厂，自己的知识储备一定要非常丰富，若缺胳膊少腿，别说在实际工作当中，光是面试这一关就过不了。对于技术方面，首先基础知识一定要扎实，包括自己方向的语言基础、计算机基础、算法以及编程等等。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
]

学习经验总结

（一）调整好心态
心态是一个人能否成功的关键，如果不调整好自己的心态，是很难静下心来学习的，尤其是现在这么浮躁的社会，大部分的程序员的现状就是三点一线，感觉很累，一些大龄的程序员更多的会感到焦虑，而且随着年龄的增长，这种焦虑感会越来越强烈，那么唯一的解决办法就是调整好自己的心态，要做到自信、年轻、勤奋。这样的调整，一方面对自己学习有帮助，另一方面让自己应对面试更从容，更顺利。

（二）时间挤一挤，制定好计划
一旦下定决心要提升自己，那么再忙的情况下也要每天挤一挤时间，切记不可“两天打渔三天晒网”。另外，制定好学习计划也是很有必要的，有逻辑有条理的复习，先查漏补缺，然后再系统复习，这样才能够做到事半功倍，效果才会立竿见影。

（三）不断学习技术知识，更新自己的知识储备
对于一名程序员来说，技术知识方面是非常重要的，可以说是重中之重。要面试大厂，自己的知识储备一定要非常丰富，若缺胳膊少腿，别说在实际工作当中，光是面试这一关就过不了。对于技术方面，首先基础知识一定要扎实，包括自己方向的语言基础、计算机基础、算法以及编程等等。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！