1.APK 的打包过程是什么？
- aapt 工具打包资源文件，生成 R.java 文件
- aidl 工具处理 AIDL 文件，生成对应的 .java 文件
- javac 工具编译 Java 文件，生成对应的 .class 文件
- 把 .class 文件转化成 Davik VM 支持的 .dex 文件
- apkbuilder 工具打包生成未签名的 .apk 文件
- jarsigner 对未签名 .apk 文件进行签名
- zipalign 工具对签名后的 .apk 文件进行对齐处理 2.线程池分类，解释下几个核心参数？
FixedThreadPool
CachedThreadPool
ScheduledThreadPool
SingleThreadExecutor
SingleThreadScheduledExecutor
ForkJoinPool
拒绝任务的时机是什么呢？线程池会在以下两种情况下会拒绝新提交的任务。
第一种情况是当我们调用 shutdown 等方法关闭线程池后，即便此时可能线程池内部依然有没执行完的任务正在执行，但是由于线程池已经关闭，此时如果再向线程池内提交任务，就会遭到拒绝。
第二种情况是线程池没有能力继续处理新提交的任务，也就是工作已经非常饱和的时候。
工作饱和导致的拒绝。比如新建一个线程池，使用容量上限为 10 的 ArrayBlockingQueue 作为任务队列，并且指定线程池的核心线程数为 5，最大线程数为 10，假设此时有 20 个耗时任务被提交，在这种情况下，线程池会首先创建核心数量的线程，也就是5个线程来执行任务，然后往队列里去放任务，队列的 10 个容量被放满了之后，会继续创建新线程，直到达到最大线程数 10。此时线程池中一共有 20 个任务，其中 10 个任务正在被 10 个线程执行，还有 10 个任务在任务队列中等待，而且由于线程池的最大线程数量就是 10，所以已经不能再增加更多的线程来帮忙处理任务了，这就意味着此时线程池工作饱和，这个时候再提交新任务时就会被拒绝。
拒绝策略
第一种拒绝策略是 AbortPolicy，这种拒绝策略在拒绝任务时，会直接抛出一个类型为 RejectedExecutionException 的 RuntimeException，让你感知到任务被拒绝了，于是你便可以根据业务逻辑选择重试或者放弃提交等策略。
第二种拒绝策略是 DiscardPolicy，这种拒绝策略正如它的名字所描述的一样，当新任务被提交后直接被丢弃掉，也不会给你任何的通知，相对而言存在一定的风险，因为我们提交的时候根本不知道这个任务会被丢弃，可能造成数据丢失。
第三种拒绝策略是 DiscardOldestPolicy，如果线程池没被关闭且没有能力执行，则会丢弃任务队列中的头结点，通常是存活时间最长的任务，这种策略与第二种不同之处在于它丢弃的不是最新提交的，而是队列中存活时间最长的，这样就可以腾出空间给新提交的任务，但同理它也存在一定的数据丢失风险。
第四种拒绝策略是 CallerRunsPolicy，相对而言它就比较完善了，当有新任务提交后，如果线程池没被关闭且没有能力执行，则把这个任务交于提交任务的线程执行，也就是谁提交任务，谁就负责执行任务。这样做主要有两点好处。
第一点新提交的任务不会被丢弃，这样也就不会造成业务损失。
第二点好处是，由于谁提交任务谁就要负责执行任务，这样提交任务的线程就得负责执行任务，而执行任务又是比较耗时的，在这段期间，提交任务的线程被占用，也就不会再提交新的任务，减缓了任务提交的速度，相当于是一个负反馈。在此期间，线程池中的线程也可以充分利用这段时间来执行掉一部分任务，腾出一定的空间，相当于是给了线程池一定的缓冲期。
3.Java 的几种引用类型，弱引用的使用场景？
强：A a=new A(); 此时引用a强引用对象A；不会被GC 软：SoftReference.java，在内存不够时引用对象会被GC； 弱：WeakReference.java，每次GC都会被回收； 虚：PhantomReference.java，每次GC都会被回收；
WeakHashMap使用了弱引用，ThreadLocal类中也是用了弱引用。
强引用的特性：
如果一个对象具有强引用，它就不会被垃圾回收器回收。即使当前内存空间不足，JVM也不会回收它，而是抛出 OutOfMemoryError 错误，使程序异常终止。
如果想中断强引用和某个对象之间的关联，可以显式地将引用赋值为null，这样JVM在合适的时间就会回收该对象。
在Java中使用 SoftReference 来声明软引用
在使用软引用时，如果内存的空间足够，软引用就能继续被使用，而不会被垃圾回收器回收；只有在内存空间不足时，软引用才会被垃圾回收器回收。
利用软引用的特性，软引用是可以用来做缓存的。
在Java中使用 WeakReference 来声明弱引用
具有弱引用的对象拥有的生命周期更短暂。
因为当 JVM 进行垃圾回收，一旦发现弱引用对象，无论当前内存空间是否充足，都会将弱引用回收。不过由于垃圾回收器是一个优先级较低的线程，所以并不一定能迅速发现弱引用对象。
在Java中使用 PhantomReference 来声明虚引用 虚引用特性：
顾名思义，虚引用就是形同虚设，如果一个对象仅持有虚引用，那么它相当于没有引用，在任何时候都可能被垃圾回收器回收。虚引用不能单独使用，必须配合引用队列一起使用
虚引用必须和引用队列关联使用，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。
4.APK 为什么要签名？是否了解过具体的签名机制？
Android 为了确认 apk 开发者身份和防止内容的篡改，设计了一套 apk 签名的方案保证 apk 的安全性，即在打包时由开发者进行 apk 的签名，在安装 apk 时Android 系统会有相应的开发者身份和内容正确性的验证，只有验证通过才可以安装 apk，签名过程和验证的设计就是基于非对称加密的思想。
Android 在 7.0 以前使用的一套签名方案：在 apk 根目录下的 META-INF/ 文件夹下生成签名文件，然后在安装时在系统的 PackageManagerService 里进行签名文件的验证。
从 7.0 开始，Android 提供了新的 V2 签名方案：利用 apk(zip) 压缩文件的格式，在几个原始内容区之外增加了一块用于存放签名信息的数据区，然后同样在安装时在系统的 PackageManagerService 里进行 V2 版本的签名验证，
V2 方案会更安全、使校验更快安装更快。 当然 V2 签名方案会向后兼容，如果没有使用 V2 签名就会默认走 V1 签名方案的验证过程。
5.Java GC 的几种算法
标记清除算法（Mark and Sweep GC） 从”GC Roots”集合开始，将内存整个遍历一次，保留所有可以被 GC Roots 直接或间接引用到的对象，而剩下的对象都当作垃圾对待并回收
优点：实现简单，不需要将对象进行移动。
缺点：这个算法需要中断进程内其他组件的执行（stop the world），并且可能产生内存碎片，提高了垃圾回收的频率。
复制算法（Copying）
将现有的内存空间分为两快，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中。之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。
优点：按顺序分配内存即可，实现简单、运行高效，不用考虑内存碎片。
缺点：可用的内存大小缩小为原来的一半，对象存活率高时会频繁进行复制。
标记-压缩算法 (Mark-Compact)
需要先从根节点开始对所有可达对象做一次标记，之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。最后，清理边界外所有的空间
优点：这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。
缺点：所谓压缩操作，仍需要进行局部对象移动，所以一定程度上还是降低了效率。
