Java中内部类为什么可以访问外部类
1.因为内部类创建的时候，需要外部类的对象，在内部类对象创建的时候会把外部类的引用传递进去
设计移动端的联系人存储与查询的功能，要求快速搜索联系人，可以用到哪些数据结构？
数据库索引，平衡二叉树(B树、红黑树)
红黑树特点
1.root节点和叶子节点是黑色
2.红色节点后必须为黑色节点
3.从root到叶子每条路径的黑节点数量相同
linux异步和同步i/o:
1.同步：对于client，client一直等待，但是client不挂起：主线程调用
2.异步：对于client，client发起请求，service好了再回调client：其他线程调用，调用完成之后进行回调
3.阻塞：对于service，在准备io的时候会将service端挂起，直至准备完成然后唤醒service：bio
3.非阻塞：对于service，在准备io的时候不会将service端挂起，而是service一直去轮询判断io是否准备完成，准备完成了就进行操作：nio、linux的select、poll、epoll
4.多路复用io：非阻塞io的一种优化，javanio，用一个线程去轮询多个 io端口是否可用，如果一个可用就通知对应的io请求，这使用一个线程轮询可以大大增强性能。
1）.我可以采用 多线程+ 阻塞IO达到类似的效果，但是由于在多线程+ 阻塞IO中，每个socket对应一个线程，这样会造成很大的资源占用。
2）.而在多路复用IO中，轮询每个socket状态是内核在进行的，这个效率要比用户线程要高的多。
5.异步io：aio，用户线程完全不感知io的进行，所有操作都交给内核，io完成之后内核通知用户线程。
1）.这种io才是异步的，2、3、4都是同步io，因为内核进行数据拷贝的过程都会让用户线程阻塞。
2）.异步IO是需要操作系统的底层支持，也就是内核支持，Java7中，提供AsynchronousIO
ConcurrentHashMap内部实现，HashTable的实现被废弃的原因:
1.HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线程都必须竞争同一把锁，那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。
2.ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成。Segment是一种可重入锁ReentrantLock，在ConcurrentHashMap里扮演锁的角色，HashEntry则用于存储键值对数据。一个ConcurrentHashMap里包含一个Segment数组，Segment的结构和HashMap类似，是一种数组和链表结构，一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素，每个Segment守护者一个HashEntry数组里的元素,当对
HashEntry数组的数据进行修改时，必须首先获得它对应的Segment锁。
HandlerThread是什么
1.MessageQueue+Looper+Handler
开发中我们经常会通过创建一个 Thread 去执行任务，有多个任务就多创建几个线程实现，这时候可能出现线程同步的问题。不过有时候我们并不需要很强的并发性，只需保证按照顺序地执行各个任务即可，有什么好办法实现呢？第一反应想到的可能是通过Executors.newSingleThreadExecutor() 方法来创建一个 SingleThreadExecutor，来统一所有的任务到一个线程中，然后按顺序执行。其实，除了这个方法之外，HandlerThread 也可以实现。
IntentService是什么
1.含有HandlerThread的Service，可以多次startService()来多次在子线程中进行 onHandlerIntent()的调用。
class和dex
1.dvm执行的是dex格式文件，jvm执行的是class文件，android程序编译完之后生产class文件。然后dex工具会把class文件处理成dex文件，然后把资源文件和.dex文件等打包成apk文件。
2.dvm是基于寄存器的虚拟机，而jvm执行是基于虚拟栈的虚拟机。寄存器存取速度比栈快的多，dvm可以根据硬件实现最大的优化，比较适合移动设备。
3.class文件存在很多的冗余信息，dex工具会去除冗余信息，并把所有的class文件整合到dex文件中。减少了I/O操作，提高了类的查找速度
内存泄漏
1.其他线程持有一个Listener，Listener操作activity。那么在线程么有完毕的时候，activity关闭了，原本是要被回收的但是，不能被回收。
2.例如Handler导致的内存泄漏，Handler就相当于Listener。
3.在activity关闭的时候注意停止线程，或者将Listener的注册取消
3.使用弱引用，这样即使Listener持有了activity，在GC的时候还是会被回收
4.工具:LeakCanary
过度绘制、卡顿优化:
1.过度绘制：
1）.移除Window默认的Background：getWidow.setBackgroundDrawable(null);2.移除XML布局文件中非必需的Background
3）.减少布局嵌套(扁平化的一个体现，减少View数的深度，也就减少了View树的遍历时间，渲染的时候，前后期的工作，总是按View树结点来)
4）.在引入布局文件里面，最外层可以用merge替代LinearLayout,RelativeLayout，这样把子UI元素直接衔接在include位置
5）.工具：HierarchyViewer 查看视图层级
2.卡顿优化：16ms数据更新，内存使用是否合理，是否出现内存抖动情况
apk瘦身:
1.classes.dex：通过代码混淆，删掉不必要的jar包和代码实现该文件的优化
2.资源文件：通过Lint工具扫描代码中没有使用到的静态资源
3.图片资源：使用tinypng和webP，下面详细介绍图片资源优化的方案,矢量图
4.SO文件将不用的去掉，目前主流app一般只放一个arm的so包
5，开启资源压缩
ANR的形成，各个组件上出现ARN的时间限制是多少
1.只要是主线程耗时的操作就会ARN如io
2.broadcast超时时间为10秒 按键无响应的超时时间为5秒 前台service无响应的超时时间为20秒，后台service为200秒
Serializable和Parcelable 的区别
1. Parcelable 消耗内存小
2.网络传输用Serializable 程序内使用Parcelable
3.Serializable将数据持久化方便
4.Serializable使用了反射 容易触发垃圾回收 比较慢
Sharedpreferences源码简述
1.储存于硬盘上的xml键值对，数据多了会有性能问题
2.ContextImpl记录着SharedPreferences的重要数据，文件路径和实 例的键值对
3.在xml文件全部内加载到内存中之前，读取操作是阻塞的，在xml文件全部内加载到内存中之后，是直接读取内存中的数据
4.apply因为是异步的没有返回值, commit是同步的有返回值能知道修改是否提交成功
5.多并发的提交commit时，需等待正在处理的commit数据更新到磁盘 文件后才会继续往下执行，从而降低效率; 而apply只是原子更新到内存，后调用apply函数会直接覆盖前面内存数据，从一定程度上提高很 多效率。3.edit()每次都是创建新的EditorImpl对象.
不过目前大部分都是MMKV
操作系统如何管理内存的：
1.使用寄存器进行将进程地址和物理内存进行映射
2.虚拟内存进行内存映射到硬盘上增大内存
3.虚拟内存是进行内存分页管理
4.页表实现分页，就是 页+地址偏移。
5.如果程序的内存在硬盘上，那么就需要用页置换算法来将其调入内存中：先进先出、最近使用最少等等
浏览器输入地址到返回结果发生了什么？
1.DNS解析
2.TCP连接
3.发送HTTP请求
4.服务器处理请求并返回HTTP报文
5.浏览器解析渲染页面
6.连接结束
