相信大家都有面试的经历，相对比面试官的问的一些问题其实都是基础的知识，但就是一些基础的知识我们也不是很完美的回答出来，我们也知道现在的开发人员很多，一家公司一个岗位就会有很多的开发者投递，在那么多开发者中你如何让面试官很深的认识你，给面试官一个很深的印象，能让他在技术水平差不多的情况的下第一个想起的是你。
从这篇文章对整个面试中所问到的问题进行梳理，查缺补漏。
JAVA
String，StringBuffer，StringBuilder区别？
一般回答是这样的：
String 字符串常量
StringBuffer 字符串变量（线程安全）
StringBuilder 字符串变量（非线程安全）
面试的时候千万不要这么说，这样说会让面试官你还只停留在会用的层面，不知道原理，你应该这么说：
String，StringBuffer，StringBuilder最终底层存储与操作的都是char数组，但是String里面的char数组是final的，而StringBuffer,StringBuilder不是，也就是说,String是不可变的，想要新的字符串只能重新生成String；而StringBuffer和StringBuilder只需要修改底层的char数组就行，相对来说，开销要小很多，String的大多数方法都是重新new一个新String对象返回，频繁重新生成容易生成很多垃圾。
为什么StringBuffer 是线程安全的？
StringBuffer是线程安全的，StringBuilder是线程不安全的，因为StringBuffer的方法是加了synchronized锁起来了的，而StringBuilder没有
增删比较多时用StringBuffer或StringBuilder（注意单线程与多线程）。
Serializable与Parcelable的区别？
1）Serializable接口是javaSE的，而Parcelable接口是Android特有的
2）Serializable接口实现简单，Parcelable略显复杂
3）Parcelable存储到磁盘上，Parcelable存储到内存中
HashMap的实现机制？
HashMap实际上是一个“链表散列”的数据结构，即数组和链表的结合体。HashMap底层就是一个数组结构，数组中的每一项又是一个链表。当新建一个HashMap的时候，就会初始化一个数组。
/**
* The table, resized as necessary. Length MUST Always be a power of two.
*/
transient Entry[] table;
static class Entry<K,V> implements Map.Entry<K,V> {
final K key;
V value;
Entry<K,V> next;
final int hash;
……
}可以看出，Entry就是数组中的元素，每个 Map.Entry 其实就是一个key-value对，它持有一个指向下一个元素的引用，这就构成了链表。
HashMap如果Hash冲突了怎么解决？
可以看下这篇文章
https://blog.csdn.net/qq_27093465/article/details/52269862
如何线程安全的使用HashMap？
无非就三种实现方式：
1）Hashtable
2）ConcurrentHashMap
3）Synchronized Map
//Hashtable
Map<String, String> hashtable = new Hashtable<>();
//synchronizedMap
Map<String, String> synchronizedHashMap = Collections.synchronizedMap(new HashMap<String, String>());
//ConcurrentHashMap
Map<String, String> concurrentHashMap = new ConcurrentHashMap<>();HashTable源码中是使用synchronized来保证线程安全的
public synchronized V get(Object key) {
// 省略实现
}
public synchronized V put(K key, V value) {
// 省略实现
}所以当一个线程访问HashTable的同步方法时，其他线程如果也要访问同步方法，会被阻塞住。举个例子，当一个线程使用put方法时，另一个线程不但不可以使用put方法，连get方法都不可以，好霸道啊！！！so~~，效率很低，现在基本不会选择它了。
ConcurrentHashMap(以下简称CHM)是JUC包中的一个类，Spring的源码中有很多使用CHM的地方。CHM的一些重要特性和什么情况下应该使用CHM。需要注意的是，上面博客是基于Java 7的，和8有区别,在8中CHM摒弃了Segment（锁段）的概念，而是启用了一种全新的方式实现,利用CAS算法。
// synchronizedMap方法
public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {
return new SynchronizedMap<>(m);
}
// SynchronizedMap类
private static class SynchronizedMap<K,V>
implements Map<K,V>, Serializable {
private static final long serialVersionUID = 1978198479659022715L;
private final Map<K,V> m; // Backing Map
final Object mutex; // Object on which to synchronize
SynchronizedMap(Map<K,V> m) {
this.m = Objects.requireNonNull(m);
mutex = this;
}
SynchronizedMap(Map<K,V> m, Object mutex) {
this.m = m;
this.mutex = mutex;
}
public int size() {
synchronized (mutex) {return m.size();}
}
public boolean isEmpty() {
synchronized (mutex) {return m.isEmpty();}
}
public boolean containsKey(Object key) {
synchronized (mutex) {return m.containsKey(key);}
}
public boolean containsValue(Object value) {
synchronized (mutex) {return m.containsValue(value);}
}
public V get(Object key) {
synchronized (mutex) {return m.get(key);}
}
public V put(K key, V value) {
synchronized (mutex) {return m.put(key, value);}
}
public V remove(Object key) {
synchronized (mutex) {return m.remove(key);}
}
// 省略其他方法
}synchronizedMap从源码中可以看出调用synchronizedMap()方法后会返回一个SynchronizedMap类的对象，而在SynchronizedMap类中使用了synchronized同步关键字来保证对Map的操作是线程安全的。
HasMap为什么会线程不安全？
个人觉得HashMap在并发时可能出现的问题主要是两方面,
首先如果多个线程同时使用put方法添加元素，而且假设正好存在两个put的key发生了碰撞(hash值一样)，那么根据HashMap的实现，这两个key会添加到数组的同一个位置，这样最终就会发生其中一个线程的put的数据被覆盖。
第二就是如果多个线程同时检测到元素个数超过数组大小*loadFactor，这样就会发生多个线程同时对Node数组进行扩容，都在重新计算元素位置以及复制数据，但是最终只有一个线程扩容后的数组会赋给table，也就是说其他线程的都会丢失，并且各自线程put的数据也丢失。
HashMap出现死循环的原因？
因为多线程会导致HashMap的Entry节点形成环链，这样当遍历集合时Entry的next节点用于不为空，从而形成死循环
Activity：
当面试官问你什么Activity，你是不是会觉得一阵懵* ？
在日常应用中，Android是用户交互的接口，他提供了一个界面，让用户进行点击，各种滑动操作等。
Activity的四种状态：
running / paused / stopped / killed
running：点击屏幕，屏幕做出响应，处于activity栈顶的状态
paused：失去焦点不能进行操作，或者是一个透明的在栈顶的Activity，注意并不是被销毁了啊，它的成员信息和变量都还在，当然还有另外一种状态，当内存紧张的时候会北回收掉
stopped：当一个Activity被另外一个Activity完全覆盖的时候，被覆盖的那个处于stopped状态，不可见，成员信息和变量都还在，如果内存紧张也是会被回收的
killed：已经被系统回收
生命周期：
启动：onCreate >> onStart >> onResume
点击HOME键回到主界面：onPause >> onStop
再次回到远Activity：onResrart>>onStart >> onResume
退出当前Activity：onPause >> onStop >> onDestroy
进程优先级：
前台 / 可见 /服务 /后台 / 空
前台：正在进行交互的Activity或者与前台activity绑定的services
可见：一个activity可见但并处于前台，不能点击
服务：在后台开启的服务
后台：当一个Activity被点击home键，退居后台，没有=被回收
空 ：不属于前面四种进程的任意一种，处于缓存的目的而保留
启动模式：
standard / singletop / singletask / singleinstance
如何配置Activity的启动模式?
直接在AndroidManifest.xml配置的android:launchMode属性为以上四种之一即可
standrd：标准模式，每次启动都会重新创建一个activity实例加入到任务栈中，不会考虑是不是有此实例存在，不会复用，消耗内存资源
singletop ：栈顶复用模式，只检测任务栈栈顶，只有在栈顶的Activity不会被创建，就算是在第二位也是会被创建
singletask：栈内复用模式，也是一个单例模式，检测整个任务栈，如果有并把在之上的实例全部移除掉，回掉onNewIntent方法
singleinstance：一个activity如果在整个系统中只存在一个实例，而且这个activity独享整个任务栈
应用场景：
singleTop：适合接收通知启动的内容显示页面。例如，某个新闻客户端的新闻内容页面，如果收到10个新闻推送，每次都打开一个新闻内容页面是很烦人，另外，singleTop启动模式适合于一些不常用的Activity页面，比如“找回密码”、“设置界面”等。
singleTask：最典型的样例就是应用中展示的主页（Home页），假设用户在主页跳转到其他页面，运行多次操作后想返回到主页，假设不使用SingleTask模式，在点击返回的过程中会多次看到主页，这明显就是设计不合理了。
singleInstance：比如说，使用微信调起自己的客户端某个页面，不做任何处理的情况下，按下回退或者当前Activity.finish()，页面不会停留在自己的客户端而是返回到微信的客户端页面。但是如果这个页面的启动模式设置为singleTask，当按下返回键或者Activity。finish（），页面都会停留在自己的客户端（因为自己的Application回退栈不为空），这明显不符合逻辑的。产品的要求是，回退必须回到微信客户端,而且要保证不杀死自己的Application.因此，显然其他的其他的启动模式都不具备这个功能。
使用方法：
方法一：
android:launchMode="standard|singleInstance|single Task|singleTop使用android:launchMode=”standard|singleInstance|single Task|singleTop”来控制Acivity任务栈。
方法二：
Intent Flags：
Intent intent=new Intent();
intent.setClass(MainActivity.this, MainActivity2.class);
intent.addFlags(Intent. FLAG_ACTIVITY_CLEAR_TOP);
startActivity(intent);Flags有很多，比如：
Intent.FLAG_ACTIVITY_NEW_TASK 相当于singleTask
Intent. FLAG_ACTIVITY_CLEAR_TOP 相当于singleTop
scheme(sigeimo)跳转协议：
android中的scheme是一种页内跳转协议，是一种非常好的实现机制，通过定义自己的scheme协议，可以非常方便的在app内部跳转到各个界面；通过scheme协议，服务器可以定制化告诉app跳转到哪个页面，可以通过通知栏消息栏定制化跳转页面，也可以通过H5页面中定义连接跳转指定的activity页面等
应用场景：
1 服务端下发一个url路径，客户端根据下方的路径跳转到指定界面
2 从H5跳转到App内
3 App根据url挑战到另外的一个App
两个 Activity 之间跳转时必然会执行的是哪几个方法?
一般情况下比如说有两个 activity,分别叫 A,B,当在 A 里面激活 B 组件的时候, A 会调用 onPause()方法,然后 B 调用 onCreate() ,onStart(), onResume()。
这个时候 B 覆盖了窗体, A 会调用 onStop()方法. 如果 B 是个透明的,或者 是对话框的样式, 就不会调用 A 的 onStop()方法。
横竖屏切换时 Activity 的生命周期？
此时的生命周期跟清单文件里的配置有关系。
1.不设置 Activity 的 android:configChanges 时,切屏会重新调用各个生命周期默认首先销毁当前 activity,然后重新加载。
2.设置 Activity android:configChanges=”orientation|keyboardHidden|screenSize”时,切 屏不会重新调用各个生命周期,只会执行 onConfigurationChanged 方法。
通常在游戏开发, 屏幕的朝向都是写死的。
如何将一个 Activity 设置成窗口的样式？
只需要给我们的 Activity 配置如下属性即可。
android:theme=”@android:style/Theme.Dialog”
Android 中的 Context, Activity,Appliction 有什么区别?
相同:Activity 和 Application 都是 Context 的子类。
Context 从字面上理解就是上下文的意思,在实际应用中它也确实是起到了管理 上下文环境中各个参数和变量的总用,方便我们可以简单的访问到各种资源。
不同:维护的生命周期不同。Context 维护的是当前的 Activity 的生命周期, Application 维护的是整个项目的生命周期。使用 context 的时候,小心内存泄露,防止内存泄露,注意一下几个方面:
1）不要让生命周期长的对象引用 activity context,即保证引用 activity 的对 象要与 activity 本身生命周期是一样的。
2 )对于生命周期长的对象,可以使用 application,context。
3 )避免非静态的内部类,尽量使用静态类,避免生命周期问题,注意内部类 对外部对象引用导致的生命周期变化。
如何获取当前屏幕Activity的对象？
使用ActivityLifecycleCallbacks
应用场景：可以利用ActivityLifecycleCallbacks 做一些数据埋点，统计之类的应用，对其统一做处理。这样对减少Activity的代码入侵。尽量简化和模块化的注入生命周期方法。
ActivityLifecycleCallbacks 是什么？
见名知意，Activity生命周期回调，Application通过此接口提供了一套回调方法，用于让开发者对Activity的生命周期事件进行集中处理。
但是这个要求API 14+ （Android 4.0+）以上使用，幸好我们这个最低支持，满足需求。
ActivityLifecycleCallbacks 怎么使用？
重写Application的onCreate()方法，或在Application的无参构造方法内，调用Application.registerActivityLifecycleCallbacks()方法，并实现ActivityLifecycleCallbacks接口
知道onNewIntent吗？
如果IntentActivity处于任务栈的顶端，也就是说之前打开过的Activity，现在处于onPause、onStop 状态的话，其他应用再发送Intent的话，执行顺序为：
onNewIntent，onRestart，onStart，onResume。
除了用Intent 去启动一个Activity，还有其他方法吗？
使用adb shell am 命令
1）ams启动一个activity
adb shell am start com.example.fuchenxuan/.MainActivity
2）am发送一个广播，使用action
adb shell am broadcast -a magcomm.action.TOUCH_LETTER
Android Service与Activity之间通信的几种方式？
通过Binder对象
1）当Activity通过调用bindService(Intent service, ServiceConnection conn,int flags),得到一个Service的一个对象，通过这个对象我们可以直接访问Service中的方法。
2）通过Broadcast Receiver(广播)的形式
3）EventBus 是一个Android开源事件总线框架 后面我们会有专门的讲解。
TaskAffinity 是什么？
标识Activity任务栈名称的属性：TaskAffinity，默认为应用包名
如果新Activity是透明主题时，旧Activity会不会走onStop？
不会！
android完全退出应用程序的三种方式？
第一种方法：首先获取当前进程的id，然后杀死该进程。 建议使用这种方式
android.os.Process.killProcess(android.os.Process.myPid())第二种方法：终止当前正在运行的Java虚拟机，导致程序终止
System.exit(0);
第三种方法：强制关闭与该包有关联的一切执行
ActivityManager manager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
manager.restartPackage(getPackageName());使用这种方式关闭应用程序需要加上权限
<uses-permission android:name="android.permission.RESTART_PACKAGES" />介绍下Android应用程序启动过程
1）Launcher通过Binder进程间通信机制通知ActivityManagerService，它要启动一个Activity；
2）ActivityManagerService通过Binder进程间通信机制通知Launcher进入Paused状态；
3）Launcher通过Binder进程间通信机制通知ActivityManagerService，它已经准备就绪进入Paused状态，于是ActivityManagerService就创建一个新的进程，用来启动一个ActivityThread实例，即将要启动的Activity就是在这个ActivityThread实例中运行；
4）ActivityThread通过Binder进程间通信机制将一个ApplicationThread类型的Binder对象传递给ActivityManagerService，以便以后ActivityManagerService能够通过这个Binder对象和它进行通信；
5）ActivityManagerService通过Binder进程间通信机制通知ActivityThread，现在一切准备就绪，它可以真正执行Activity的启动操作了。
如果想深入研究的可以查看罗升阳大神的博客https://blog.csdn.net/luoshengyang/article/details/6689748
Fragment：
三个小问题看你能完美解答几个
1 Fragment为什么被称为第五大组件？
2 Fragment的生命周期 ？
3 Fragment之间的通信 ？
1 Fragment为什么被称为第五大组件？
首先Fragment的使用频率并不低于其他四大组件，他有自己的生命周期，同时可以动态灵活的加载到Activity中，所以说Fragment可以被称为第五大组件
加载到Activity的两种方式：
1）添加Fragment到Activity的布局文件当中，也叫静态加载，name属性哦
2）动态的在activity中添加fragment ，也叫动态加载
步骤：
FragmentManage用来管理所有要启动的fragment，并用FragmentTransaction添加和替换相对应的fragment，并用容器资源来作为标志位来设置fragment所要显示到activity当中的位置，最后提交commit方法
(1)创建待添加的碎片实例
(2)获取FragmentManager，在活动中可以直接通过调用 getSupportFragmentManager（）方法得到。
(3)开启一个事务，通过调用beginTransaction()方法开启。
(4)向容器内添加或替换碎片，一般使用repalce()方法实现，需要传入容器的id和待添加的碎片实例。
(5)提交事务，调用commit()方法来完成。
FragmentPageAdapter与FragmentStatePageAdapter的区别？
1 FragmentStatePageAdapter适合界面多，FragmentPageAdapter适合界面少
2 FragmentStatePageAdapter比FragmentPageAdapter更节省内存
源码分析：
FragmentPageAdapter适用于页面较少的情况下，因为只对ui分离并没有回收内存， 因为源码里面destoryItem是detach方法（）只是对fragment和activity的ui脱离开来，并不回收内存
FragmentStatePageAdapter用于界面较多的情况下，界面多也就意味着更加的消耗内存，FragmentStatePageAdapter在每次切换fragment的时候，他是回收内存的，因为源码里面destoryItem的remove方法真正的释放的内存
Fragement的生命周期：
onAttach >> onCreate >> onCreateView >> onActivityCreated >>onStart >> onResume >> onPause >> onStop >> onDestoryView >> onDestory >>onDetach
很显然你要是像背书似的将上面的生命周期说一遍，你认为你跟其他的竞争者有什么优势？
你应该将Activity与Fragment的生命周期结合起来说：
首先，调用Activity的onCreate方法
当Fragment创建的时候会执行onAttach，是在Activity与fragment关联之后调用的
在之后执行onCreate方法，也就是在fragment创建的时候调用，注意，此时的activity还没有创建完毕
在调用fragment的onCreateView方法，系统首次绘制用户界面的时候调用
调用fragment的onActivityCreated方法，也就是activity被渲染绘制成功后调用，
现在是要调用activity的onStart的方法，当activity可见之后调用，
fragment的onStart方法，表示fragment也可见了
接着调用activity的onResume的方法，表示当前activity可以与用户交互了，当activity可见之后调用
fragment的onResume方法，表示当前fragment也可以与用户进行交互操作了，以上步骤完成了从创建到交互的所有步骤
在之后，Fragment的onPause
Activity的onPause
Fragment的onStop
Activity的onStop
现在来到了Frament的onDestoryView方法，表示当前fragment不在被使用，界面销毁，紧接着来到onDestory方法，表示fragment已经销毁了，最后调用onDetach来解除与activity的联系
最后调用Activity的onDestory方法
Fragment通信：
1）在Fragment中调用Activity的方法 geyActivity
2）在Activity中调用Fragment的方法 接口回调（在Fragment创建接口，在Activity实现）
3）在Fragment调用Fragment的方法 getActivity.findFragmentById 或者广播
Fragment的replace、add、remove？
add：将一个fragment实例添加到Activity的最上层，一般在使用add的时候会配合 hide,show一起使用，为了避免Fragment的重复创建节省资源。
remove：将fragment从fragment队列中删除
replace：替换fragment的实例，replace是FragmentManager的方法
commitAllowingStateLoss与commit的区别？
Activity被系统回收(界面已经不存在了),为了能在下次打开的时候恢复原来的样子，系统为我们保存界面的所有状态，这个时候再去修改界面理论上肯定是不被允许的，为了避免这种异常可以使用:
transaction.commitAllowingStateLoss();来提交添加Fragment到Activity的事务，与commit()不同的是使用这种方法允许丢失界面的状态和信息。
ViewPager与Fragment结合使用时的懒加载问题?
所谓的 “懒加载” 就是数据只有在Fragment对于用户可见的时才进行加载,我们需要判定Fragment在什么时候是处于可见的状态。一般我们通常是通过Fragment中的生命周期方法onResume来判断Fragment是否可见，但是由于ViewPager预加载的特性,Fragment即便不可见也会执行onResume方法,可以通过setUserVisibleHint（）方法来进行判断：
什么时候被调用?
当fragment被创建的时,setUserVisibleHint(boolean isVisibleToUser)方法会被调用,且传入参数值为false。
当fragment可见时,setUserVisibleHint(boolean isVisibleToUser)方法会被调用，且传入参数值为true。
当fragment由 可见 -> 不可见 时,setUserVisibleHint(boolean isVisibleToUser)方法会被调用，且传入参数值为false。所以我们只需要当setUserVisibleHint(boolean isVisibleToUser)方法中的 isVisibleToUser 参数的值为true的时候我们才开始进行数据的加载就可以了。
但是有一点需要需要注意的是 setUserVisibleHint(boolean isVisibleToUser)方法在Fragment的生命周期方法onCreate 之前调用的，也就是说他并不在Fragment的生命周期中。既然是在 onCreate 方法之前被调用，这样就存在许多不确定因素，如果Fragmnet的View还没有完成初始化之前，就在setUserVisibleHint()方法中进行UI的操作，这样显然会导致空指针的出现。因此我们需要对Fragment创建的View进行缓存,确保缓存的View不为空的情况下我们才可以在setUserVisibleHint方法中进行UI操作。
Service
Service是什么？
四大组件之一，可以在后台处理一些耗时的逻辑，也可以执行某些长时间运行的任务，而且看不到界面，包括在程序退出的时候依然能在继续运行
Service与Broadcastrecevier有一个共同点，都是运行在主线程当中，都不能进行长耗时操作
Service与Thread的区别？
Thread程序最小的执行单元，Thread可以进行异步操作，相对独立；而Service是Android的一种机制，如果是本地的Service，依赖与它所在的主线程之上，相比Thread没有那么独立
为什么要用Service而不是Thread呢?
Thread的运行是独立于Activity的，也就是当一个Activity被finish之后，如果没有主动停止Thread或者Thread中的run没有执行完毕时那么这个线程会一直执行下去。因此这里会出现一个问题：当 Activity 被 finish 之后，你不再持有该 Thread 的引用。另一方面，你没有办法在不同的 Activity 中对同一 Thread 进行控制。
Service 是否在 main thread 中执行, service 里面是否 能执行耗时的操作?
默认情况,如果没有显示的指 servic 所运行的进程, Service 和 activity 是运 行在当前 app 所在进程的 main thread(UI 主线程)里面。
service 里面不能执行耗时的操作(网络请求,拷贝数据库,大文件 )
特殊情况 ,可以在清单文件配置 service 执行所在的进程 ,让 service 在另 外的进程中执行
<service android:name="com.baidu.location.f" android:enabled="true" android:process=":remote" >
</service>
Service 里面可以弹吐司么？
可以的。弹吐司有个条件就是得有一个 Context 上下文,而 Service 本身就是 Context 的子类,因此在 Service 里面弹吐司是完全可以的。比如我们在 Service 中完成下载任务后可以弹一个吐司通知用户
Service 的 onStartCommand 方法有几种返回值?各代表什么意思?
有四种返回值,不同值代表的意思如下:
START_STICKY:如果 service 进程被 kill 掉,保留 service 的状态为开始状态,但不保留递送的 intent 对象。随 后系统会尝试重新创建 service,由于服务状态为开始状态,所以创建服务后一定会调用 onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到 service,那么参数 Intent 将为 null。
START_NOT_STICKY:“非粘性的”。使用这个返回值时,如果在执行完 onStartCommand 后,服务被异常 kill 掉,系统不会自动重启该服务。
START_REDELIVER_INTENT:重传 Intent。使用这个返回值时,如果在执行完
onStartCommand 后,服务被异 常 kill 掉,系统会自动重启该服务,并将 Intent 的值传入。
START_STICKY_COMPATIBILITY:START_STICKY 的兼容版本,但不保证服务被 kill 后一定能重启。
Service 的 onRebind(Intent)方法在什么情况下会执行?
如果在 onUnbind()方法返回 true 的情况下会执行,否则不执行。
Activity 调用 Service 中的方法都有哪些方式?
Binder：
通过 Binder 接口的形式实现,当 Activity 绑定 Service 成功的时候 Activity 会在 ServiceConnection 的类 的 onServiceConnected()回调方法中获取到 Service 的 onBind()方法 return 过来的 Binder 的子类，然后通过对象调用方法。
Aidl:
aidl 比较适合当客户端和服务端不在同一个应用下的场景。
Messenger：
它引用了一个Handler对象，以便others能够向它发送消息(使用mMessenger.send(Message msg)方法)。该类允许跨进程间基于Message的通信(即两个进程间可以通过Message进行通信)，在服务端使用Handler创建一个Messenger，客户端持有这个Messenger就可以与服务端通信了。一个Messeger不能同时双向发送，两个就就能双向发送了
如何提高service的优先级？
可以用 setForeground(true) 来设置 Service 的优先级。
service 如何定时执行？
使用AlarmManager，根据AlarmManager的工作原理，alarmmanager会定时的发出一条广播，然后在自己的项目里面注册这个广播，重写onReceive方法，在这个方法里面启动一个service，然后在service里面进行网络的访问操作，当获取到新消息的时候进行推送，同时再设置一个alarmmanager进行下一次的轮询，当本次轮询结束的时候可以stopself结束改service。这样即使这一次的轮询失败了，也不会影响到下一次的轮询。这样就能保证推送任务不会中断
在 service 的生命周期方法 onstartConmand()可不可以执行网络操作?如何在 service 中执行网络操作?
可以直接在 Service 中执行网络操作,在 onStartCommand()方法中可以执行网络操作
Service 和 Activity 在同一个线程吗？
对于同一 app 来说默认情况下是在同一个线程中的,main Thread (UI Thread)。
什么是 IntentService?有何优点?
会创建独立的工作线程来处理所有的 Intent 请求;
会创建独立的工作线程来处理 onHandleIntent()方法实现的代码,无需
处理多线程问题;
所有请求处理完成后,IntentService 会自动停止,无需调用 stopSelf()方法
停止 Service;
为 Service 的 onBind()提供默认实现,返回 null;
为 Service 的 onStartCommand 提供默认实现,将请求 Intent 添加到队列
中;
Activity 怎么和 Service 绑定,怎么在 Activity 中启动自 己对应的 Service?
Activity 通过 bindService(Intent service, ServiceConnection conn, int flags)跟 Service 进行绑定,当绑定成功的时候 Service 会将代理对象通过回调 的形式传给 conn,这样我们就拿到了 Service 提供的服务代理对象。
在 Activity 中可以通过 startService 和 bindService 方法启动 Service。一 般情况下如果想获取 Service 的服务对象那么肯定需要通过 bindService()方 法,比如音乐播放器,第三方支付等。如果仅仅只是为了开启一个后台任务那么 可以使用 startService()方法。
IntentService 适用场景
IntentService 内置的是 HandlerThread 作为异步线程，每一个交给 IntentService 的任务都将以队列的方式逐个被执行到，一旦队列中有某个任务执行时间过长，那么就会导致后续的任务都会被延迟处理
正在运行的 IntentService 的程序相比起纯粹的后台程序更不容易被系统杀死，该程序的优先级是介于前台程序与纯后台程序之间的
Broadcast Receiver
广播的定义：
在Android中，Broadcast是一种广泛运用在程序之间的传输信息的机制，Android中我们要发送的广播内容中是一个Intent，这个Intent可以携带我们要传输的数据
广播的使用场景：
1)在同一个App具有多个进程的不同组件之间的消息传递
2）不同app之间的消息通信
广播的种类：
1）普通广播
2）系统广播 （sendOrderedBroadcast）
3 ) 本地广播（只在app内部传播）
不同注册方式广播接收器回调onReceive(context, intent)中context类型不一致？
manifest静态注册的ContextReceiver，回调onReceive(context, intent)中的context是ReceiverRestrictedContext；
代码动态注册的ContextReceiver，回调onReceive(context, intent)中的context是Activity Context；
内部实现机制？
1）自定义广播接受者Broadcast Receiver，并复写onRecvice方法
2）通过Binder机制像AMS进行注册
3）广播发送者通过Binder机制像AMS发送广播
4）AMS查找符合相应条件（IntentFilter/Permission等）的Broadcast Receiver，将广播发送到Broadcast Receiver相应的消息队列循环当中去（一般是Activity中）
5）消息循环拿到此广播，回调Broadcast Receiver中的onReceive方法、
如何让自己的广播只让指定的 app 接收？
通过自定义广播权限来保护自己发出的广播。 在清单文件里receiver必须有这个权限才能收到广播。 首先，需要定义权限： 然后，声明权限： 这时接收者就能收到发送的广播。
广播的优先级对无序广播生效吗?
生效的**
动态注册的广播优先级谁高?
谁先注册谁优先级高。
如何判断当前 BroadcastReceiver 接收到的是有序广播还是无序广播?
在 BroadcastReceiver 类中 onReceive()方法中,可以调用
boolean b = isOrderedBroadcast();判断接收到的广播是否为有序广播。
粘性广播有什么作用？怎么使用？
粘性广播主要为了解决，在发送完广播之后，动态注册的接收者，也能够收到广播。举个例子首先发送一广播，我的接收者是通过程序中的某个按钮动态注册的。如果不是粘性广播，我注册完接收者肯定无法收到广播了。这是通过发送粘性广播就能够在我动态注册接收者后也能收到广播。
网络
HttpConnection 与HttpURLConnection的区别？
在Android 2.2版本之前，HttpClient拥有较少的bug，因此使用它是最好的选择
2.3之后使用HttpURLConnection，它的API简单，体积较小，压缩和缓存机制可以有效地减少网络访问的流量，在提升速度和省电方面也起到了较大的作用，利于维护与优化
TCP与UDP的区别？
1）基于连接与无连接
2）对系统资源的要求（TCP较多，UDP较少）
3）UDP程序结构较简单一些
4）流模式与数据包模式
5）TCP保证数据的顺序性以及正确性，UDP不能保证，可能存在丢包
Socket：
soket是套接字，我们可以先在服务端初始化ServerSocket，然后对指定的端口进行绑定与监听，通过调用accept方法与getInputstream方法进行等待客户端的连接与数据的接收。现在客户端进行创建socket对象传入ip和端口号，通过getOutputStream进行数据的输入，并且制定结束字符，否则服务端会一直处于阻塞状态。
socket.close() 与socket.shutdownOutput()的区别？
1）在客户端或者服务端通过socket.shutdownOutput()都是单向关闭的，即关闭客户端的输出流并不会关闭服务端的输出流，所以是一种单方向的关闭流；
2）通过socket.shutdownOutput()关闭输出流，但socket仍然是连接状态，连接并未关闭
3）如果直接关闭输入或者输出流，即：in.close()或者out.close()，会直接关闭socket
socket长连接？
在不关闭流的情况下，开启循环线程进行定时发送与服务端约定的心跳包数据
http1.0与http1.1的区别：
1）缓存处理（缓存处理策略不同1.1更丰富）
2）带宽优化及网络连接的使用（1.1允许只请求某一部分的数据，不会浪费带宽）
3）Host头处理 （1.1请求消息支持Host头改进 ）
4）长连接（1.1支持长连接 ，默认开启KeepAlive ，避免创建浪费的资源）
http1.1与1.0的存在问题：
a. 1.0在传输数据时，每次都需要重新建立连接，无疑增加了大量的延迟时间
b. 1.1在传输数据的时候传输的都是明文，客户端和服务端都无法验证对方的身份（https）
c. 1.1在使用的时候 ，header里携带的内容过大，在一定程度上增加了传输的成本
d. 虽然1.1支持了keep-alive来弥补多次创建连接产生的延迟，但是keep-alive使多了同样会给服务端带来大量的性能压力
get与post 的区别？
主要区别：get获取资源，post提供来更新服务器上的资源
a、提交的数据（get数据一般放在url之后用？分隔，post提交数据放在http包的body中）
b、提交数据大小限制问题（get有限制，url有限制，post没有限制）
c、取得变量值Requst.QueryStrig 与 Requst.Form的区别
d、安全问题（get用户名密码暴露在url上，不安全；post则不然）
cookie与session的区别？？
a、存放位置不同（cookie保存在客户端，session保存在服务端）
b、存取方式不同（cookie保存的ASCII字符串，session可以存取任何类型的字符串）
c、安全性的不同（cookie存在客户端可能会被修改数据）
d、有效期上的不同（cookie可以设置很长的时间，session依赖id）
e、对服务器造成的压力不同（并发很多的时候可以选择cookie，服务器压力小）
Handler
什么是Handler？
handler通过发送和处理Message和Runnable对象来关联相对应线程的MessageQueue
作用：
1）可以让对应的Message和Runnable在未来的某个时间点进行相应处理
2）让自己想要处理的耗时操作放在子线程，让更新ui的操作放在主线程
Handler发送消息的几种方式？
1）post（Runnable）延迟消息处理
2）sendMessage（message）
PS：post（Runnable）的Runnable中可以更新UI吗？
可以的 ，因为经常会post一个Runnable，处理的代码直接写在Runnable的run方法中，其实就是将这个Runnable发送到Handler所在线程（一般是主线程）的消息队列中。sendMessage方法主线程处理方法一般则是写在handleMessage中
Handler处理消息有哪几种方式？
直接看dispatchMessage()源码
//1. post()方法的最终处理方法
private static void handleCallback(Message message) {
message.callback.run();
}
//2. sendMessage()方法的最终处理方法
public void handleMessage(Message msg) {
}
Handler、Message、Looper、MessageQueue
Message（消息）
定义：Handler接收和处理的消息对象（Bean对象）
作用：通信时相关信息的存放和传递
ThreadLocal
定义：ThreadLocal是线程内部的存储类，通过它可以实现在每个线程中存储自己的私有数据。即数据存储以后，只能在指定的线程中获取这个存储的对象，而其它线程则不能获取到当前线程存储的这个对象。
作用：负责存储和获取本线程的Looper
MessageQueue（消息队列）
定义：采用单链表的数据结构来存储消息列表
作用：用来存放通过Handler发过来的Message，按照先进先出执行
Handler（处理者）
定义：Message的主要处理者
作用：负责发送Message到消息队列&处理Looper分派过来的Message
Looper（循环器）
定义：扮演Message Queue和Handler之间桥梁的角色
作用：
消息循环：循环取出Message Queue的Message
消息派发：将取出的Message交付给相应的Handler
首先知道定义人，然后结合关系说清楚一些在加上HandlerThread基本上Handler这块是没什么大问题了
Message、Handler、MessageQueue、Looper的之间的关系？
首先，是这个MessagQueue，MessageQueue是一个消息队列，它可以存储Handler发送过来的消息，其内部提供了进队和出队的方法来管理这个消息队列，其出队和进队的原理是采用单链表的数据结构进行插入和删除的，即enqueueMessage()方法和next()方法。这里提到的Message，其实就是一个Bean对象，里面的属性用来记录Message的各种信息。
然后，是这个Looper，Looper是一个循环器，它可以循环的取出MessageQueue中的Message，其内部提供了Looper的初始化和循环出去Message的方法，即prepare()方法和loop()方法。在prepare()方法中，Looper会关联一个MessageQueue，而且将Looper存进一个ThreadLocal中，在loop()方法中，通过ThreadLocal取出Looper，使用MessageQueue的next()方法取出Message后，判断Message是否为空，如果是则Looper阻塞，如果不是，则通过dispatchMessage()方法分发该Message到Handler中，而Handler执行handlerMessage()方法，由于handlerMessage()方法是个空方法，这也是为什么需要在Handler中重写handlerMessage()方法的原因。这里要注意的是Looper只能在一个线程中只能存在一个。这里提到的ThreadLocal，其实就是一个对象，用来在不同线程中存放对应线程的Looper。
最后，是这个Handler，Handler是Looper和MessageQueue的桥梁，Handler内部提供了发送Message的一系列方法，最终会通过MessageQueue的enqueueMessage()方法将Message存进MessageQueue中。我们平时可以直接在主线程中使用Handler，那是因为在应用程序启动时，在入口的main方法中已经默认为我们创建好了Looper。
Handler引起的内存泄漏以及解决办法？
HandlerThread作用
当系统有多个耗时任务需要执行时，每个任务都会开启一个新线程去执行耗时任务，这样会导致系统多次创建和销毁线程，从而影响性能。为了解决这一问题，Google提供了HandlerThread，HandlerThread是在线程中创建一个Looper循环器，让Looper轮询消息队列，当有耗时任务进入队列时，则不需要开启新线程，在原有的线程中执行耗时任务即可，否则线程阻塞。
HandlerThread是什么？有哪些特点
1）HandlerThread本质上是一个线程类，它继承了Thread
2）HandlerThread有自己内部Looper对象，可以进行Looper循环
3）通过获取HandlerThread的looper对象传递给Handler对象，可以在handlerMessage方法中执行异步任务
4）优点是不会阻塞，减少对性能的消耗，缺点是不能同时进行多任务的处理，需要等待进行处理
5）与线程池注重并发不同，HandlerThread是一个串行队列，HandlerThread背后只有一个线程
子线程为什么不能开启handler？
handler在调用sendMessage或者post（Runnable）的时候都需要一个MessageQueue 消息队列来保存发送的消息，而默认子线程中是没有开启Looper轮循器的，而消息队列又是由Looper来进行管理的，所以是没有办法开启的，
如果子线程想要开启，需要初始化looper，并且调用loop.loopers开启一个循环
如果简历中写了AsyncTask，就看一下，没写的直接跳过上Rxjava
AsyncTask是什么
AsyncTask是一种轻量级的异步任务类，它可以在线程池中执行后台任务，然后把执行的进度和最终结果传递给主线程并主线程中更新UI，通过AsyncTask可以更加方便执行后台任务以及在主线程中访问UI，但是AsyncTask并不适合进行特别耗时的后台任务，对于特别耗时的任务来说，建议使用线程池。
AsyncTask使用方法
三个参数
Params：表示后台任务执行时的参数类型，该参数会传给AysncTask的doInBackground()方法
Progress：表示后台任务的执行进度的参数类型，该参数会作为onProgressUpdate()方法的参数
Result：表示后台任务的返回结果的参数类型，该参数会作为onPostExecute()方法的参数
五个方法
onPreExecute()：异步任务开启之前回调，在主线程中执行
doInBackground()：执行异步任务，在线程池中执行
onProgressUpdate()：当doInBackground中调用publishProgress时回调，在主线程中执行
onPostExecute()：在异步任务执行之后回调，在主线程中执行
onCancelled()：在异步任务被取消时回调
AsyncTask引起的内存泄漏
原因：非静态内部类持有外部类的匿名引用，导致Activity无法释放
解决：
AsyncTask内部持有外部Activity的弱引用
AsyncTask改为静态内部类
Activity的onDestory()中调用AsyncTask.cancel()
结果丢失
屏幕旋转或Activity在后台被系统杀掉等情况会导致Activity的重新创建，之前运行的AsyncTask会持有一个之前Activity的引用，这个引用已经无效，这时调用onPostExecute()再去更新界面将不再生效。
AsyncTask并行or串行
AsyncTask在Android 2.3之前默认采用并行执行任务，AsyncTask在Android 2.3之后默认采用串行执行任务
如果需要在Android 2.3之后采用并行执行任务，可以调用AsyncTask的executeOnExecutor();
AsyncTask内部的线程池
private static volatile Executor sDefaultExecutor = SERIAL_EXECUTOR;
sDefaultExecutor是SerialExecutor的一个实例，而且它是个静态变量。也就是说，一个进程里面所有AsyncTask对象都共享同一个SerialExecutor对象。
ListView+RecyclerView
既然RecyclerView在很多方面能取代ListView，Google为什么没把ListView划上一条过时的横线？
ListView采用的是RecyclerBin的回收机制在一些轻量级的List显示时效率更高
ListView怎么和ScrollView兼容？
方法一：重写ListView, 覆盖onMeasure()方法
方法二：动态设置listview的高度，不需要重写ListView
方法三：在xml文件中，直接将Listview的高度写死
listview怎么优化？
1)、convertView复用，对convetView进行判空，当convertView不为空时重复使用，为空则初始化，从而减少了很多不必要的View的创建
2)定义一个ViewHolder，封装Listview Item条目中所有的组件，将convetView的tag设置为ViewHolder,不为空时通过ViewHolder的属性获取对应组件即可
3)、当ListView加载数据量较大时可以采用分页加载和图片异步加载
上拉加载和下拉刷新怎么实现？
实现OnScrollListener 接口重写onScrollStateChanged 和onScroll方法，
使用onscroll方法实现”滑动“后处理检查是否还有新的记录，如果有，调用 addFooterView，添加记录到adapter, adapter调notifyDataSetChanged 更新数据;如果没有记录了，把自定义的mFooterView去掉。使用onScrollStateChanged可以检测是否滚到最后一行且停止滚动然后执行加载
listview失去焦点怎么处理？
在listview子布局里面写，可以解决焦点失去的问题
android:descendantFocusability=”blocksDescendants”
ListView图片异步加载实现思路？
1.先从内存缓存中获取图片显示（内存缓冲）
2.获取不到的话从SD卡里获取（SD卡缓冲，，从SD卡获取图片是放在子线程里执行的，否则快速滑屏的话会不够流畅）
3.都获取不到的话从网络下载图片并保存到SD卡同时加入内存并显示（视情况看是否要显示）
你知道Listview里有Button就点不动了你知道吗？
原因是button强制获取了item的焦点，只要设置button的focusable为false即可。
listview分页加载的步骤？
通常实现分页加载有两种方式，一种是在ListView底部设置一个按钮，用户点击即加载。另一种是当用户滑动到底部时自动加载。
当用户滑动到底部时自动加载实现思路:
实现OnScrollListener 接口重写onScrollStateChanged 和onScroll方法，使用onscroll方法实现”滑动“后处理检查是否还有新的记录，如果有,添加记录到adapter, adapter调用 notifyDataSetChanged 更新数据;如果没有记录了，则不再加载数据。使用onScrollStateChanged可以检测是否滚到最后一行且停止滚动然后执行加载.
ViewHolder内部类非得要声明成static的呢？
因为非静态成员类的实例会包含一个额外的指向外围对象的引用，保存这份引用要消耗时间和空间，并且导致外围类实例符合垃圾回收时仍然被保留。如果没有外围实例的情况下，也需要分配实例，就不能使用非静态成员类，因为非静态成员类的实例必须要有一个外围实例。
ScrollView嵌套ListView和GridView冲突的方法
重写ListView的onMeasure方法，来自定义高度：
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
int expandSpec = MeasureSpec.makeMeasureSpec(Integer.MAX_VALUE >> 2, MeasureSpec.AT_MOST);
super.onMeasure(widthMeasureSpec, expandSpec);
}BaseAdapter四个关键方法的含义？
1） getCount()
返回数据源中数据的个数,如果该方法的返回值为0，那么适配器就不用生成布局对象了，提高了程序性能
2）getItem(int position)
根据位置返回数据项
3）getItemId(int position)
返回数据项的位置
4）getView(int position, View convertView, ViewGroup parent)
RecyclerView滑动删除原理实现？
两种方法：
一种就是通过重写RecyclerView的onTouchEvent()方法来检测手势的变化实现的，大致的流程如下：
1、根据手指触摸的坐标点找到对应Item的ViewHolder，进而得到相应的Item布局View。
2、手指继续移动，在条件满足的情况下，通过scrollBy()使Item布局View内容跟随手指一起移动，当然要注意边界检测。
3、手指抬起时，根据Item布局View内容移动的距离以及手指的滑动速度，判断是否显示删除按钮，进而通过startScroll()使Item布局View自动滑动到目标位置。
4、点击删除按钮则删除对应Item，点击其它区域则隐藏删除按钮。
另外一种：
实现原理
主要是借助 ItemTouchHelper.Callback 类来实现，我们要关注的方法为
* getMovementFlags( )
* onMove（）
* onSwiped（）
* onSelectedChanged（）
* clearView（）
* isLongPressDragEnabled（）
首先自定义一个MyCallback类继承 ItemTouchHelper.Callback ，定义两个int变量dragFlags 与 swipeFlags并实现下方法。这个方法主要是为了获取我们当前的事件是拖动还是滑动
其他：
Android View刷新机制？
在Android的布局体系中，父View负责刷新、布局显示子View；而当子View需要刷新时，则是通知父View来完成
RelativeLayout和LinearLayout性能比较？
1.RelativeLayout会让子View调用2次onMeasure，LinearLayout 在有weight时，也会调用子View2次onMeasure
2.RelativeLayout的子View如果高度和RelativeLayout不同，则会引发效率问题，当子View很复杂时，这个问题会更加严重。如果可以，尽量使用padding代替margin。
3.在不影响层级深度的情况下,使用LinearLayout和FrameLayout而不是RelativeLayout。
View和ViewGroup什么区别？
Android的UI界面都是由View和ViewGroup及其派生类组合而成的。其中，View是所有UI组件的基类，而ViewGroup是容纳这些组件的容器，其本身也是从View派生出来的
自定义View优化策略
为了加速你的view，对于频繁调用的方法，需要尽量减少不必要的代码。先从onDraw开始，需要特别注意不应该在这里做内存分配的事情，因为它会导致GC，从而导致卡顿。在初始化或者动画间隙期间做分配内存的动作。不要在动画正在执行的时候做内存分配的事情。
你还需要尽可能的减少onDraw被调用的次数，大多数时候导致onDraw都是因为调用了invalidate().因此请尽量减少调用invaildate()的次数。如果可能的话，尽量调用含有4个参数的invalidate()方法而不是没有参数的invalidate()。没有参数的invalidate会强制重绘整个view。
另外一个非常耗时的操作是请求layout。任何时候执行requestLayout()，会使得Android UI系统去遍历整个View的层级来计算出每一个view的大小。如果找到有冲突的值，它会需要重新计算好几次。另外需要尽量保持View的层级是扁平化的，这样对提高效率很有帮助。
如果你有一个复杂的UI，你应该考虑写一个自定义的ViewGroup来执行他的layout操作。与内置的view不同，自定义的view可以使得程序仅仅测量这一部分，这避免了遍历整个view的层级结构来计算大小。这个PieChart 例子展示了如何继承ViewGroup作为自定义view的一部分。PieChart 有子views，但是它从来不测量它们。而是根据他自身的layout法则，直接设置它们的大小
View树的绘制流程？
measure>layout>draw
View树的绘制流程就像是一个递归过程，在onMeasure方法中，它的view会对它的所有子元素进行测量，测量过程就从它的父的ViewGroup传递到子的view，经过子元素的递归，测量好了所有的子元素的长度之后，进行一个递归，反复之后就完成了整个父元素ViewGroup的测量，而layout也是相类似树的递归过程
onMeasure：
ViewGroup.LayoutParams:用来指定视图高度个宽度的参数。
MeasureSpec：测量规格，32位的int值，前两位是测量模式，后者表示在这种模式下的尺寸的大小
开始于我们的父控件ViewGroup，它会不断的遍历子控件的measure方法，然后根据ViewGroup的MeasureSpec和子View的LayoutParams来决定我们的子视图的MeasureSpec测量规格，通过这个测量规格，MeasureSpec进一步获取到子View的宽高，然后一层一层的向下传递，不断的保存父控件的测量宽高，整个Measure的测量流程就是一个树型的递归流程
layout：
layout其实也是一个树形的结构，所以当它进行数据摆放的时候，他会以此的从ViewGroup调用它的子控件，所以也是依次进行的数据摆放，这就是layout与measure的相同的地方
onDraw：
经过测量和摆放之后进行绘制，需要注意两个容易混淆的方法：
invalidate：invalidate()是用来刷新View的，必须是在UI线程中进行工作。比如在修改某个view的显示时，调用invalidate()才能看到重新绘制的界面。invalidate()的调用是把之前的旧的view从主UI线程队列中pop掉。
requestlayout：当布局发生变化的时候，方向变化或者尺寸变化，某些情况下重新测量view的大小啊，调用完改方法后就会触发它的measure onlayout过程，但是不会调用onDraw方法。
音视频
SurfaceView是什么 ？
它继承自类View，因此它本质上是一个View。但与普通View不同的是，它有自己的Surface。有自己的Surface，在WMS中有对应的WindowState，在SurfaceFlinger中有Layer。我们知道，一般的Activity包含的多个View会组成View hierachy的树形结构，只有最顶层的DecorView，也就是根结点视图，才是对WMS可见的。这个DecorView在WMS中有一个对应的WindowState。相应地，在SF中对应的Layer。而SurfaceView自带一个Surface，这个Surface在WMS中有自己对应的WindowState，在SF中也会有自己的Layer。虽然在App端它仍在View hierachy中，但在Server端（WMS和SF）中，它与宿主窗口是分离的。这样的好处是对这个Surface的渲染可以放到单独线程去做，渲染时可以有自己的GL context。这对于一些游戏、视频等性能相关的应用非常有益，因为它不会影响主线程对事件的响应。但它也有缺点，因为这个Surface不在View hierachy中，它的显示也不受View的属性控制，所以不能进行平移，缩放等变换，也不能放在其它ViewGroup中，一些View中的特性也无法使用。
SurfaceView优点及缺点？
优点：可以在一个独立的线程中进行绘制，不会影响主线程。使用双缓冲机制，播放视频时画面更流畅
缺点：Surface不在View hierachy中，它的显示也不受View的属性控制，所以不能进行平移，缩放等变换，也不能放在其它ViewGroup中。SurfaceView 不能嵌套使用
SurfaceView中双缓冲？
双缓冲：在运用时可以理解为：SurfaceView在更新视图时用到了两张Canvas，一张frontCanvas和一张backCanvas，每次实际显示的是frontCanvas，backCanvas存储的是上一次更改前的视图，当使用lockCanvas（）获取画布时，得到的实际上是backCanvas而不是正在显示的frontCanvas，之后你在获取到的backCanvas上绘制新视图，再unlockCanvasAndPost（canvas）此视图，那么上传的这张canvas将替换原来的frontCanvas作为新的frontCanvas，原来的frontCanvas将切换到后台作为backCanvas。例如，如果你已经先后两次绘制了视图A和B，那么你再调用lockCanvas（）获取视图，获得的将是A而不是正在显示的B，之后你讲重绘的C视图上传，那么C将取代B作为新的frontCanvas显示在SurfaceView上，原来的B则转换为backCanvas。
TextureView是什么？
在4.0(API level 14)中引入，与SurfaceView一样继承View， 它可以将内容流直接投影到View中，它可以将内容流直接投影到View中，可以用于实现Live preview等功能。和SurfaceView不同，它不会在WMS中单独创建窗口，而是作为View hierachy中的一个普通View，因此可以和其它普通View一样进行移动，旋转，缩放，动画等变化。值得注意的是TextureView必须在硬件加速的窗口中。它显示的内容流数据可以来自App进程或是远端进程。从类图中可以看到，TextureView继承自View，它与其它的View一样在View hierachy中管理与绘制。TextureView重载了draw()方法，其中主要SurfaceTexture中收到的图像数据作为纹理更新到对应的HardwareLayer中。SurfaceTexture.OnFrameAvailableListener用于通知TextureView内容流有新图像到来。SurfaceTextureListener接口用于让TextureView的使用者知道SurfaceTexture已准备好，这样就可以把SurfaceTexture交给相应的内容源。Surface为BufferQueue的Producer接口实现类，使生产者可以通过它的软件或硬件渲染接口为SurfaceTexture内部的BufferQueue提供graphic buffer。
TextureView优点及缺点？
优点：支持移动、旋转、缩放等动画，支持截图
缺点：必须在硬件加速的窗口中使用，占用内存比SurfaceView高，在5.0以前在主线程渲染，5.0以后有单独的渲染线程。
谁的性能更优？
播放器应该选择谁？
从性能和安全性角度出发，使用播放器优先选SurfaceView。
1、在android 7.0上系统surfaceview的性能比TextureView更有优势，支持对象的内容位置和包含的应用内容同步更新，平移、缩放不会产生黑边。 在7.0以下系统如果使用场景有动画效果，可以选择性使用TextureView
2、由于失效(invalidation)和缓冲的特性，TextureView增加了额外1~3帧的延迟显示画面更新
3、TextureView总是使用GL合成，而SurfaceView可以使用硬件overlay后端，可以占用更少的内存带宽，消耗更少的能量
4、TextureView的内部缓冲队列导致比SurfaceView使用更多的内存
5、SurfaceView： 内部自己持有surface，surface 创建、销毁、大小改变时系统来处理的，通过surfaceHolder 的callback回调通知。当画布创建好时，可以将surface绑定到MediaPlayer中。SurfaceView如果为用户可见的时候，创建SurfaceView的SurfaceHolder用于显示视频流解析的帧图片，如果发现SurfaceView变为用户不可见的时候，则立即销毁SurfaceView的SurfaceHolder，以达到节约系统资源的目的
视频编码标准两大系统是什么？
视频编码标准有两大系统：MPEG和ITU-T，如下
视频编码标准
MPEG标准由MPEG制定
MPEG-1 | MPEG-2 | (MPEG-3) | MPEG-4 | MPEG-7 | MPEG-21
ITU-T标准由VCEG制定
H.261 | (H.262) | H.263 | H.263v2 | H.264
什么是音视频编码格式？什么是音视频封装格式？
常见的AVI、RMVB、MKV、ASF、WMV、MP4、3GP、FLV等文件其实只能算是一种封装标准。
一个完整的视频文件是由音频和视频2部分组成的。H264、Xvid等就是视频编码格式，MP3、AAC等就是音频编码格式。
例如：将一个Xvid视频编码文件和一个MP3视频编码文件按AVI封装标准封装以后，就得到一个AVI后缀的视频文件，这个就是我们常见的AVI视频文件了。
由于很多种视频编码文件、音频编码文件都符合AVI封装要求，则意味着即使是AVI后缀，也可能里面的具体编码格式不同。因此出现在一些设备上，同是AVI后缀文件，一些能正常播放，还有一些就无法播放。
同样的情况也存在于其他容器格式。即使RMVB、WMV等也不例外，事实上，很多封装容器对音频编码和视频编码的组合方式放的很开，如AVI还可以使用H.264+AAC组合，可以在具体使用中自己体会。尤其是MKV封装容器，基本无论什么样的组合都可以！但一般MKV用的最多的就是H.264+AAC组合，此组合文件体积最小，清晰度最高。因此网上很多MKV视频都是高清晰度的。
因此，视频转换需要设置的本质就是：A设置需要的视频编码、B设置需要的音频编码、C选择需要的容器封装。一个完整的视频转换设置都至少包括了上面3个步骤。
平时说的软解和硬解，具体是什么？
硬解就是硬件解码，指利用GPU来部分代替CPU进行解码，软解就是软件解码，指利用软件让CPU来进行解码。两者的具体区别如下所示：
硬解码：是将原来全部交由CPU来处理的视频数据的一部分交由GPU来做，而GPU的并行运算能力要远远高于CPU，这样可以大大的降低对CPU的负载，CPU的占用率较低了之后就可以同时运行一些其他的程序了，当然，对于较好的处理器来说，比如i5 2320，或者AMD 任何一款四核心处理器来说，硬解和软件的区别只是个人偏好问题了吧。
软解码：即通过软件让CPU来对视频进行解码处理；而硬解码：指不借助于CPU，而通过专用的子卡设备来独立完成视频解码任务。曾经的VCD/DVD解压卡、视频压缩卡等都隶属于硬解码这个范畴。而现如今，要完成高清解码已经不再需要额外的子卡，因为硬解码的模块已经被整合到显卡GPU的内部，所以目前的主流显卡（集显）都能够支持硬解码技术。
何为直播？何为点播？
直播：是一个三方交互(主播、服务器、观众)，这个交互式实时的！尽管会根据选择的协议不同而有一些延迟，但我们仍认为它直播是实时的！—>主播在本地发送音视频给服务器（推流），观众从服务器实时解码（拉流）收看收听主播发送给服务器的音视频（直播内容）。直播是不能快进的
点播：首先一定要明确的一点，点播不存在推流这一过程，你本身你的流已经早就推给服务器了，或者这么说也不对，应该是你的音视频早就上传到了服务器，观众只需要在线收看即可，由于你的音视频上传到了服务器，观众则可以通过快进，快退，调整进度条等方式进行收看！
简述推流、拉流的工作流程？
推流：在直播中，一方向服务器发送请求，向服务器推送自己正在实时直播的数据，而这些内容在推送到服务器的这一过程中是以 “流” 的形式传递的，这就是“推流”，把音视频数据以流的方式推送（或上传）到服务器的过程就是“推流”！推流方的音视频往往会很大，在推流的过程中首先按照 aac音频-编码 和 h264视频-编码的标准把推过来的音视频压缩 ，然后合并成 MP4或者 FLV格式，然后根据直播的封装协议，最后传给服务器完成推流过程。
拉流：与推流正好相反，拉流是用户从服务器获取推流方给服务器的音视频的过程，这就是“拉流”！拉流首先aac音频-解码 和 h.264视频-解码的内部把推过来的音视频解压缩，然后合成 MP4或者 FLV 格式，再解封装，最后到我们的客户端与观众进行交互。
常见的直播协议有哪些？之间有什么区别？
常见的直播协议有三种 RTMP、HLS、FLV…
1）RTMP：real time messaging protocol~实时传输协议，RTMP协议比较全能，既可以用来推送又可以用来直播，其核心理念是将大块的视频帧和音频帧“剁碎”，然后以小数据包的形式在互联网上进行传输，而且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时也容易出现一些不可预期的稳定性问题。
2）FLV：FLV协议由Adobe公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种极致的简洁，在延迟表现和大规模并发方面都很成熟。唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端APP直播协议却异常合适。
3）HLS：苹果原生：HTTP Live Streaming，遵循的是 HTTP 超文本传输协议，端口号8080，将视频分成5-10秒的视频小分片，然后用m3u8索引表进行管理，由于客户端下载到的视频都是5-10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS的一般延迟在10-30s左右）。
点播中常见的数据传输协议主要有哪些？
常见的点播协议：HLS，HTTP
何为Nginx？有什么特点？
Nginx 是一个遵循 HTTP 协议的服务器！内存占用少，并发能力强！ 还有等等的优点，可自行google
何为homebrew？你用它安装过什么？常用命令有哪些？
homebrew是一个 Mac系统下所独有的套件管理器，我要做直播，需要 rtmp 和 nginx ，单独安装很复杂，只要在终端里输入简单的安装相应的套件命令即可完成安装，复杂的过程都靠 homebrew 规避掉了！
我用它安装过很多东西，比如nginx 搭建流媒体服务器等。
常用命令：brew install 、brew uninstall、brew search、brew list、brew update、brew help 等~
FFmpeg是什么？
FFmpeg是一套用来记录和转换数字音视频，并能将其转化为流的开源计算机程序。拉流和推流离不开 FFmpeg 的帮助！
RTMP、HLS协议各自的默认端口号是？
RTMP端口号：1935
HLS端口号 ：8080
m3u8构成是？直播中m3u8、ts如何实时更新？
是一个索引地址/播放列表，通过FFmpeg将本地的xxx.mp4进行切片处理，生成m3u8播放列表（索引文件）和N多个 .ts文件，并将其（m3u8、N个ts）放置在本地搭建好的webServer服务器的指定目录下，我就可以得到一个可以实时播放的网址，我们把这个m3u8地址复制到 VLC 上就可以实时观看！
在 HLS 流下，本地视频被分割成一个一个的小切片，一般10秒一个，这些个小切片被 m3u8管理，并且随着终端的FFmpeg 向本地拉流的命令而实时更新，影片进度随着拉流的进度而更新，播放过的片段不在本地保存，自动删除，直到该文件播放完毕或停止，ts 切片会相应的被删除，流停止，影片不会立即停止，影片播放会滞后于拉流一段时间
PS: FFmpeg推流至Nginx：可以推两种流：RTMP流，推流至rtmplive；HLS流，推流至hls；其中，HLS流表现较明显，在nginx的临时目录下，直观的可看到m3u8索引文件和N多个.ts文件。m3u8列表会实时更新，且会动态更改当前播放索引切片（.ts）。这种实时更新的机制，不会使得.ts文件长时间存在于Nginx服务器上，且当推流结束之后，该目录下的内容会被全部清除，这样无形中减缓了nginx服务器的压力。另外，也阐释了HLS这种流媒体播放相较RTMP延时较高的原因。
说说你平时在播放过程中做的优化工作
预加载，弱网优化，播放出错重试机制，运营商劫持引起的起播慢，mediaserver的cpu占有率很高，引起播放卡顿。起播时，只保留播放进程，kill 其他进程 。
未完待续
650
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
