极力推荐文章：欢迎收藏

和您一起终身学习，这里是程序员Android

不同的启动方式他们的生命周期是不一样.

3、Activity的启动过程（不要回答生命周期）

app启动的过程有两种情况
第一种是从桌面launcher上点击相应的应用图标

此处延伸：什么情况下用动态注册

Broadcast广播，注册方式主要有两种.
第一种是静态注册，也可成为常驻型广播，这种广播需要在Androidmanifest.xml中进行注册，这中方式注册的广播，不受页面生命周期的影响，即使退出了页面，也可以收到广播这种广播一般用于想开机自启动啊等等，由于这种注册的方式的广播是常驻型广播，所以会占用CPU的资源。

第二种是动态注册，而动态注册的话，是在代码中注册的，这种注册方式也叫非常驻型广播，受到生命周期的影响，退出页面后，就不会收到广播，我们通常运用在更新UI方面。这种注册方式优先级较高。最后需要解绑，否会会内存泄露

广播是分为有序广播和无序广播。

此处延伸：Volley里用的哪种请求方式

这两种方式都支持Https协议，都是以流的形式进行上传或者下载数据，也可以说是以流的形式进行数据的传输，还有ipv6,以及连接池等功能。HttpClient这个拥有非常多的API，所以如果想要进行扩展的话，并且不破坏它的兼容性的话，很难进行扩展，也就是这个原因，Google在Android6.0的时候，直接就弃用了这个HttpClient.

而HttpUrlConnection相对来说就是比较轻量级了，API比较少，容易扩展，并且能够满足Android大部分的数据传输。比较经典的一个框架volley，在Android 2.3版本以前都是使用Android

基于栈的机器必须使用指令来载入和操作栈上数据，所需指令更多更多。
2、java虚拟机运行的是java字节码。
java类会被编译成一个或多个字节码.class文件.

1、dalvik虚拟机是基于寄存器的
2、Dalvik运行的是自定义的.dex字节码格式。
java类被编译成.class文件后，会通过一个dx工具将所有的.class文件转换成一个.dex文件，然后dalvik虚拟机会从其中读取指令和数据.
3、常量池已被修改为只使用32位的索引，以 简化解释器。
4、一个应用，一个虚拟机实例，一个进程
所有android应用的线程都是对应一个linux线程，都运行在自己的沙盒中，不同的应用在不同的进程中运行。每个android dalvik应用程序都被赋予了一个独立的linux PID(app_*)

7、进程保活（不死进程）

此处延伸：进程的优先级是什么

当前业界的Android进程保活手段主要分为黑、白、灰三种，其大致的实现思路如下：
不同的app进程，用广播相互唤醒,包括利用系统提供的广播进行唤醒.

白色保活：启动前台Service
灰色保活：利用系统的漏洞启动前台Service

所谓黑色保活，就是利用不同的app进程使用广播来进行相互唤醒。举个3个比较常见的场景：
场景1：开机，网络切换、拍照、拍视频时候，利用系统产生的广播唤醒app
场景2：接入第三方SDK也会唤醒相应的app进程，如微信sdk会唤醒微信，支付宝sdk会唤醒支付宝。由此发散开去，就会直接触发了下面的 场景3
场景3：假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app，那么你打开任意一个阿里系的app后，有可能就顺便把其他阿里系的app给唤醒了。（只是拿阿里打个比方，其实BAT系都差不多）

白色保活手段非常简单，就是调用系统api启动一个前台的Service进程，这样会在系统的通知栏生成一个Notification，用来让用户知道有这样一个app在运行着，哪怕当前的app退到了后台。

灰色保活，这种保活手段是应用范围最广泛。它是利用系统的漏洞来启动一个前台的Service进程，与普通的启动方式区别在于，它不会在系统通知栏处出现一个Notification，看起来就如同运行着一个后台Service进程一样。这样做带来的好处就是，用户无法察觉到你运行着一个前台进程（因为看不到Notification）,但你的进程优先级又是高于普通后台进程的。那么如何利用系统的漏洞呢，大致的实现思路和代码如下：
熟悉Android系统的童鞋都知道，系统出于体验和性能上的考虑，app在退到后台时系统并不会真正的kill掉这个进程，而是将其缓存起来。打开的应用越多，后台缓存的进程也越多。在系统内存不足的情况下，系统开始依据自身的一套进程回收机制来判断要kill掉哪些进程，以腾出内存来供给需要的app。这套杀进程回收内存的机制就叫

了解完 Low Memory Killer，再科普一下oom_adj。什么是oom_adj？它是 linux内核分配给每个系统进程的一个值，代表进程的优先级，进程回收机制就是根据这个优先级来决定是否进行回收。对于oom_adj的作用，你只需要记住以下几点即可：

进程的oom_adj越大，表示此进程优先级越低，越容易被杀回收；越小，表示进程优先级越高，越不容易被杀回收

有些手机厂商把这些知名的app放入了自己的白名单中，保证了进程不死来提高用户体验（如微信、QQ、陌陌都在小米的白名单中）。如果从白名单中移除，他们终究还是和普通app一样躲避不了被杀的命运，为了尽量避免被杀，还是老老实实去做好优化工作吧。

所以，进程保活的根本方案终究还是回到了性能优化上，进程永生不死终究是个彻头彻尾的伪命题！

Context是一个抽象基类。在翻译为上下文，也可以理解为环境，是提供一些程序的运行环境基础信息。Context下有两个子类，ContextWrapper是上下文功能的封装类，而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类， Alert类型的Dialog），因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。

这个问题真的很不好回答。所以这里先来个算是比较恰当的比喻来形容下它们的关系吧。Activity像一个工匠（控制单元），Window像窗户（承载模型），View像窗花（显示视图）LayoutInflater像剪刀，Xml配置像窗花图纸。

1. 队列先进先出，栈先进后出

1. 对插入和删除操作的"限定"。 栈是限定只能在表的一端进行插入和删除操作的线性表。 队列是限定只能在表的一端进行插入和在另一端进行删除操作的线性表。

这是默认模式，每次激活Activity时都会创建Activity实例，并放入任务栈中。使用场景：大多数Activity。

如果在任务的栈顶正好存在该Activity的实例，就重用该实例( 会调用实例的 onNewIntent() )，否则就会创建新的实例并放入栈顶，即使栈中已经存在该Activity的实例，只要不在栈顶，都会创建新的实例。使用场景如新闻类或者阅读类App的内容页面。

)。重用时，会让该实例回到栈顶，因此在它上面的实例将会被移出栈。如果栈中不存在该实例，将会创建新的实例放入栈中。使用场景如浏览器的主界面。不管从多少个应用启动浏览器，只会启动主界面一次，其余情况都会走onNewIntent，并且会清空主界面上面的其他页面。

在一个新栈中创建该Activity的实例，并让多个应用共享该栈中的该Activity实例。一旦该模式的Activity实例已经存在于某个栈中，任何应用再激活该Activity时都会重用该栈中的实例( 会调用实例的 onNewIntent() )。其效果相当于多个应用共享一个应用，不管谁激活该 Activity 都会进入同一个应用中。使用场景如闹铃提醒，将闹铃提醒与闹铃设置分离。singleInstance不要用于中间页面，如果用于中间页面，跳转会有问题，比如：A -> B (singleInstance) -> C，完全退出后，在此启动，首先打开的是B。

1、组合控件。这种自定义控件不需要我们自己绘制，而是使用原生控件组合成的新控件。如标题栏。
2、继承原有的控件。这种自定义控件在原生控件提供的方法外，可以自己添加一些方法。如制作圆角，圆形图片。
3、完全自定义控件：这个View上所展现的内容全部都是我们自己绘制出来的。比如说制作水波纹进度条。

②、保存画布的图层（Layer）；
③、绘制View的内容；
④、绘制View子视图，如果没有就不用；
⑤、还原图层（Layer）；

4.当Acitivty接收到Touch事件时，将遍历子View进行Down事件的分发。ViewGroup的遍历可以看成是递归的。分发的目的是为了找到真正要处理本次完整触摸事件的View，这个View会在onTouchuEvent结果返回true。

指通过指定每一帧的图片和播放时间，有序的进行播放而形成动画效果，比如想听的律动条。

指通过指定View的初始状态、变化时间、方式，通过一系列的算法去进行图形变换，从而形成动画效果，主要有Alpha、Scale、Translate、Rotate四种效果。
注意：只是在视图层实现了动画效果，并没有真正改变View的属性，比如滑动列表，改变标题栏的透明度。

在Android3.0的时候才支持，通过不断的改变View的属性，不断的重绘而形成动画效果。相比于视图动画，View的属性是真正改变了。比如view的旋转，放大，缩小。

15、Android中跨进程通讯的几种方式

这种跨进程方式并不是访问内存的形式，它需要传递一个uri,比如说打电话。

这种形式，是使用数据共享的形式进行数据共享。

广播 包含静态广播，动态广播。

此处延伸：简述Binder

每一个进程都有自己的Dalvik VM实例，都有自己的一块独立的内存，都在自己的内存上存储自己的数据，执行着自己的操作，都在自己的那片狭小的空间里过完自己的一生。而aidl就类似与两个进程之间的桥梁，使得两个进程之间可以进行数据的传输，跨进程通信有多种选择，比如 BroadcastReceiver , Messenger 等，但是 BroadcastReceiver 占用的系统资源比较多，如果是频繁的跨进程通信的话显然是不可取的；Messenger 进行跨进程通信时请求队列是同步进行的，无法并发执行。

Manager运行在用户空间，Binder驱动程序是运行在内核空间的。而Binder就是把这4种组件粘合在一块的粘合剂，其中核心的组件就是Binder驱动程序，Service 之间的通信。其中Binder驱动程序提供设备文件/dev/binder与用户控件进行交互，

Android中主线程是不能进行耗时操作的，子线程是不能进行更新UI的。所以就有了handler，它的作用就是实现线程之间的通信。

Manager运行在用户空间，Binder驱动程序是运行在内核空间的。而Binder就是把这4种组件粘合在一块的粘合剂，其中核心的组件就是Binder驱动程序，Service

是加载类的dex文件，而他们加载类的时候都需要ClassLoader,ClassLoader有一个子BaseDexClassLoader，而BaseDexClassLoader下有一个数组——DexPathList，是用来存放dex文件，当BaseDexClassLoader通过调用findClass方法时，实际上就是遍历数组，找到相应的dex文件，找到，则直接将它return。而热修复的解决方法就是将新的dex添加到该集合中，并且是在旧的dex的前面，所以就会优先被取出来并且return返回。

(1)内存溢出（OOM）和内存泄露（对象无法被回收）的区别。 
(2)引起内存泄露的原因

是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；
比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。内存溢出通俗的讲就是内存不够用。

是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光

一、Handler 引起的内存泄漏。
解决：将Handler声明为静态内部类，就不会持有外部类SecondActivity的引用，其生命周期就和外部类无关，
如果Handler里面需要context的话，可以通过弱引用方式引用外部类

三、非静态内部类创建静态实例引起的内存泄漏。
解决：把内部类修改为静态的就可以避免内存泄漏了

四、非静态匿名内部类引起的内存泄漏。
解决：将匿名内部类设置为静态的。

五、注册/反注册未成对使用引起的内存泄漏。
注册广播接受器、EventBus等，记得解绑。

六、资源对象没有关闭引起的内存泄漏。
在这些资源不使用的时候，记得调用相应的类似close（）、destroy（）、recycler（）、release（）等方法释放。

七、集合对象没有及时清理引起的内存泄漏。
通常会把一些对象装入到集合中，当不使用的时候一定要记得及时清理集合，让相关对象不再被引用。

图片资源，不同图片的的分辨率，放在相应的文件夹下可使用百分比代替。

App启动的方式有三种：

App没有启动过或App进程被killed, 系统中不存在该App进程, 此时启动App即为冷启动。

热启动意味着你的App进程只是处于后台, 系统只是将其从后台带到前台, 展示给用户。

介于冷启动和热启动之间,
一般来说在以下两种情况下发生:

Application的onCreate（特别是第三方SDK初始化），首屏Activity的渲染都不要进行耗时操作，如果有，就可以放到子线程或者IntentService中。

(1)过于复杂的布局.
(2)UI线程的复杂运算
导致频繁GC有两个原因:
1、内存抖动, 即大量的对象被创建又在短时间内马上被释放.
2、瞬间产生大量的对象会严重占用内存区域。

App与Server之间的API设计要考虑网络请求的频次, 资源的状态等. 以便App可以以较少的请求来完成业务需求和界面的展示.

可以在获取图片时告知服务器需要的图片的宽高, 以便服务器给出合适的图片, 避免浪费.

适当的缓存, 既可以让我们的应用看起来更快, 也能避免一些不必要的流量消耗.

1. 通过WebView的loadUrl(),使用该方法比较简洁，方便。但是效率比较低，获取返回值比较困难。
2. 通过WebView的evaluateJavascript(),该方法效率高，但是4.4以上的版本才支持，4.4以下版本不支持。所以建议两者混合使用。

1. 通过WebView的addJavascriptInterface（）进行对象映射 ，该方法使用简单，仅将Android对象和JS对象映射即可，但是存在比较大的漏洞。

漏洞产生原因是：当JS拿到Android这个对象后，就可以调用这个Android对象中所有的方法，包括系统类（java.lang.Runtime 类），从而进行任意代码执行。

这种方式的优点：不存在方式1的漏洞；缺点：JS获取Android方法的返回值复杂。

垃圾收集算法的核心思想是：
对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。垃圾收集算法的选择和垃圾收集系统参数的合理调节直接影响着系统性能。

(1)不要在主线程中做耗时的操作，而应放在子线程中来实现。如onCreate()和onResume()里尽可能少的去做创建操作。
(3)避免在Intent Receiver里启动一个Activity，因为它会创建一个新的画面，并从当前用户正在运行的程序上抢夺焦点。
(4)service是运行在主线程的，所以在service中做耗时操作，必须要放在子线程中。

此处延伸：Double Check的写法被要求写出来。
单例模式：分为恶汉式和懒汉式

这个框架非常全面，可以进行网络请求，可以进行图片加载处理，可以数据储存，还可以对`view`进行注解，使用这个框架非常方便，但是缺点也是非常明显的，使用这个项目，会导致项目对这个框架依赖非常的严重，一旦这个框架出现问题，那么对项目来说影响非常大的。、
`Android`开发中是可以直接使用现成的`api`进行网络请求的。就是使用`HttpClient,HttpUrlConnection`进行操作。`okhttp`针对`Java`和`Android`程序，封装的一个高性能的`http`请求库，支持同步，异步，而且`okhttp`又封装了线程池，封装了数据转换，封装了参数的使用，错误处理等。`API`使用起来更加的方便。但是我们在项目中使用的时候仍然需要自己在做一层封装，这样才能使用的更加的顺手。
`Volley`是`Google`官方出的一套小而巧的异步请求库，该框架封装的扩展性很强，支持`HttpClient、HttpUrlConnection`， 甚至支持`OkHttp`，而且`Volley`里面也封装了`ImageLoader`，所以如果你愿意你甚至不需要使用图片加载框架，不过这块功能没有一些专门的图片加载框架强大，对于简单的需求可以使用，稍复杂点的需求还是需要用到专门的图片加载框架。
`Volley`也有缺陷，比如不支持`post`大数据，所以不适合上传文件。不过`Volley`设计的初衷本身也就是为频繁的、数据量小的网络请求而生。
`Retrofit`的封装可以说是很强大，里面涉及到一堆的设计模式,可以通过注解直接配置请求，可以使用不同的`http`客户端，虽然默认是用`http` ，可以使用不同`Json Converter` 来序列化数据，同时提供对`RxJava`的支持，使用`Retrofit + OkHttp + RxJava + Dagger2 `可以说是目前比较潮的一套框架，但是需要有比较高的门槛。
`Volley`的优势在于封装的更好，而使用`OkHttp`你需要有足够的能力再进行一次封装。而`OkHttp`的优势在于性能更高，因为 `OkHttp`基于`NIO`和`Okio` ，所以性能上要比` Volley`更快。`IO `和` NIO`这两个都是`Java`中的概念，如果我从硬盘读取数据，第一种方式就是程序一直等，数据读完后才能继续操作这种是最简单的也叫阻塞式`IO`,还有一种是你读你的,程序接着往下执行，等数据处理完你再来通知我，然后再处理回调。而第二种就是 `NIO` 的方式，非阻塞式， 所以`NIO`当然要比`IO`的性能要好了,而 `Okio`是` Square `公司基于`IO`和`NIO`基础上做的一个更简单、高效处理数据流的一个库。理论上如果`Volley`和`OkHttp`对比的话，更倾向于使用` Volley`，因为`Volley`内部同样支持使用`OkHttp`,这点`OkHttp`的性能优势就没了， 而且 `Volley` 本身封装的也更易用，扩展性更好些。
这两个库都做了不错的封装，但`Retrofit`解耦的更彻底,尤其`Retrofit2.0`出来，`Jake`对之前`1.0`设计不合理的地方做了大量重构， 职责更细分，而且`Retrofit`默认使用`OkHttp,`性能上也要比`Volley`占优势，再有如果你的项目如果采用了`RxJava `，那更该使用` Retrofit` 。所以这两个库相比，`Retrofit`更有优势，在能掌握两个框架的前提下该优先使用 `Retrofit`。但是`Retrofit`门槛要比`Volley`稍高些，要理解他的原理，各种用法，想彻底搞明白还是需要花些功夫的，如果你对它一知半解，那还是建议在商业项目使用Volley吧。
此处延伸：手写`mvp`例子，与`mvc`之间的区别，`mvp`的优势
 
(5)将动态链接库复制到`java`工程，在`java`工程中调用，运行`java`工程即可
 
`RecyclerView`可以完成`ListView,GridView`的效果，还可以完成瀑布流的效果。同时还可以设置列表的滚动方向（垂直或者水平）；
`RecyclerView`中`view`的复用不需要开发者自己写代码，系统已经帮封装完成了。
如果需要频繁的刷新数据，需要添加动画，则`RecyclerView`有较大的优势。
如果只是作为列表展示，则两者区别并不是很大。
 
是 `Facebook `推出的开源图片缓存工具，主要特点包括：两个内存缓存加上 `Native` 缓存构成了三级缓存，
1. 图片存储在安卓系统的匿名共享内存, 而不是虚拟机的堆内存中, 图片的中间缓冲数据也存放在本地堆内存, 所以, 应用程序有更多的内存使用, 不会因为图片加载而导致`oom`, 同时也减少垃圾回收器频繁调用回收` Bitmap `导致的界面卡顿, 性能更高。
2. 渐进式加载 `JPEG` 图片, 支持图片从模糊到清晰加载。
3. 图片可以以任意的中心点显示在 `ImageView,` 而不仅仅是图片的中心。
5. 很好的支持` GIF `图片的显示。
 
估计由于HttpClient被Google放弃，作者就放弃维护这个框架
3.默认实现多种内存缓存算法 这几个图片缓存都可以配置缓存算法，不过` ImageLoader `默认实现了较多缓存算法，如 `Size `最大先删除、使用最少先删除、最近最少使用、先进先删除、时间最长先删除等。
4.支持本地缓存文件名规则定义
 
1. 自带统计监控功能。支持图片缓存使用的监控，包括缓存命中率、已使用内存大小、节省的流量等。
2.支持优先级处理。每次任务调度前会选择优先级高的任务，比如 `App `页面中` Banner `的优先级高于` Icon `时就很适用。
3.支持延迟到图片尺寸计算完成加载
4.支持飞行模式、并发线程数根据网络类型而变。 手机切换到飞行模式或网络类型变换时会自动调整线程池最大并发数，比如 `wifi `最大并发为` 4，4g 为 3，3g 为 2`。 这里` Picasso `根据网络类型来决定最大并发数，而不是` CPU `核数。
1. 不仅仅可以进行图片缓存还可以缓存媒体文件。`Glide` 不仅是一个图片缓存，它支持 `Gif、WebP`、缩略图。甚至是 Video，所以更该当做一个媒体缓存。
2. 支持优先级处理。
5. 内存友好。`Glide `的内存缓存有个` active` 的设计，从内存缓存中取数据时，不像一般的实现用 `get`，而是用 `remove`，再将这个缓存数据放到一个` value `为软引用的 `activeResources map` 中，并计数引用数，在图片加载完成后进行判断，如果引用计数为空则回收掉。内存缓存更小图片，`Glide 以 url、view_width、view_height`、屏幕的分辨率等做为联合 key，将处理后的图片缓存在内存缓存中，而不是原始图片以节省大小与 `Activity/Fragment` 生命周期一致，支持 `trimMemory`。图片默认使用默认 RGB_565 而不是 `ARGB_888`，虽然清晰度差些，但图片更小，也可配置到 `ARGB_888。`
至此，本篇已结束，如有不对的地方，欢迎您的建议与指正。同时期待您的关注，感谢您的阅读，谢谢！