1如何正确使用Handler？

Handler的工作是依赖于Looper的，而Looper（与消息队列）又是属于某一个线程（ThreadLocal是线程内部的数据存储类，通过它可以在指定线程中存储数据，其他线程则无法获取到），其他线程不能访问。因此Handler就是间接跟线程是绑定在一起了。因此要使用Handler必须要保证Handler所创建的线程中有Looper对象并且启动循环。因为子线程中默认是没有Looper的，所以会报错。正确的使用方法是：

2自定义控件优化方案

1 为了加速你的view，对于频繁调用的方法，需要尽量减少不必要的代码。先从onDraw开始，需要特别注意不应该在这里做内存分配的事情(创建对象)，因为它会导致GC，从而导致卡顿。在初始化或者动画间隙期间做分配内存的动作。不要在动画正在执行的时候做内存分配的事情。

2 你还需要尽可能的减少onDraw被调用的次数，大多数时候导致onDraw都是因为调用了invalidate().因此请尽量减少调用invaildate()的次数。如果可能的话，尽量调用含有4个参数的invalidate()方法而不是没有参数的invalidate()。没有参数的invalidate会强制重绘整个view。

3 另外一个非常耗时的操作是请求layout。任何时候执行requestLayout()，会使得Android UI系统去遍历整个View的层级来计算出每一个view的大小。如果找到有冲突的值，它会需要重新计算好几次。另外需要尽量保持View的层级是扁平化的，这样对提高效率很有帮助。 如果你有一个复杂的UI，你应该考虑写一个自定义的ViewGroup来执行他的layout操作。与内置的view不同，自定义的view可以使得程序仅仅测量这一部分，这避免了遍历整个view的层级结构来计算大小。这个PieChart 例子展示了如何继承ViewGroup作为自定义view的一部分。PieChart 有子views，但是它从来不测量它们。而是根据他自身的layout法则，直接设置它们的大小。

3谈谈Android的事件分发机制

1、如果事件不被中断，整个事件流向是一个类U型图，我们来看下这张图，可能更能理解U型图的意思。所以如果我们没有对控件里面的方法进行重写或更改返回值，而直接用super调用父类的默认实现，那么整个事件流向应该是从Activity---->ViewGroup--->View 从上往下调用dispatchTouchEvent方法，一直到叶子节点（View）的时候，再由View--->ViewGroup--->Activity从下往上调用onTouchEvent方法。

2、dispatchTouchEvent 和 onTouchEvent 一旦return true,事件就停止传递了（到达终点）（没有谁能再收到这个事件）。看下图中只要return true事件就没再继续传下去了，对于return true我们经常说事件被消费了，消费了的意思就是事件走到这里就是终点，不会往下传，没有谁能再收到这个事件了。

3、dispatchTouchEvent 和 onTouchEvent return false的时候事件都回传给父控件的onTouchEvent处理。

点击事件的穿透：我曾经遇到这样一个情况，就是有两个布局叠加在一起，上层的ListView控件在滑动的时候，有可能会出发下层控件的点击相应效果。这个时候，就需要让上层ViewGroup做相应的事件拦截和处理，只允许上层中的view相应相应的事件，然后传递到上层的ViewGroup时候，就终止再继续向下回传了。可以将上层的ViewGroup的onTouchEvent直接返回true，就可以阻止事件向下传递，但是同时又不影响上层view的事件处理。

4Android动画有几种，对其理解

1 视图动画。视图移动、view自身的实际位置并未移动。

2帧动画。就和放电影一样，一帧一帧的播

3属性动画。视图移动、其位置也会随着移动。

4触摸返回动画。发生触摸事件时有反馈效果。比如波纹效果

5揭露动画。从某一个点向四周展开或者从四周向某一点聚合起来。

6转场动画 & 共享元素。比如切换activity。共享元素一般我们使用在转换的前后两个页面有共同元素时。

7视图状态动画。就是 View 在状态改变时执行的动画效果

补间动画使用完会自动被释放掉，但是属性动画在使用完后一定要记得手动释放资源。否则会造成内存泄露。

5Android 内存泄漏的原因以及解决方案

1 内存泄漏指对象不再使用，本该被回收，却因为有其他正在使用的对象持有该对象的引用，而无法被JVM回收

2 内存泄漏的影响：

    a 应用可用内存减少，增加堆内存压力

    b 频繁触发GC，会降低了应用的性能

    c 到一定程序会导致内存溢出错误

3 Android开发中常见内存泄漏及解决办法

    a 静态变量生命周期与应用的生命周期一样，如果静态变量持有某个Activity的上下文，则对应Activity无法释放，导致内存泄漏（单例模式） 解决办法：使用Application的上下文

    b 匿名内部类与非静态内部类因为都会持有外部类引用，当执行异步操作易导致内存泄漏 解决办法：将非静态内部类转为静态内部类+WeakReferenct的方式

    c Handler消息队列存在延时消息导致内存泄漏 在onDestroy方法中调用Handler相应的方法移除回调和删除消息

    d 各种注册的监听器忘记移除导致内存泄漏 解决办法：在onDestroy方法中取消注册

    e 资源对象未关闭导致内存泄漏，如(IO,数据库，Bitmap等) 解决办法：及时关闭资源

    f 属性动画未取消导致内存泄漏(如无限轮播图效果) 解决办法：onDestroy方法中取消动画

    g 其他解决办法：使用AAC框架

4 内存泄漏排查工具： AS Monitor,MAT,LeakCanary

5 扩展： Java内存管理，GC

6 Handler引起的内存泄漏 原因：该线程持有Handler的引用，而Handler也持有Activity的引用，这就导致了Activity不再使用时，GC回收不了Activity 解决：Handler持有的引用最好使用弱引用，在Activity被释放的时候要记得清空Message，取消Handler对象的Runnable

7 单例模式引起的内存泄漏 原因：构建该单例的一个实例时需要传入一个Context，如果此时传入的是Activity，由于Context会被创建的实例一直持有，当Activity进入后台或者开启设置里面的不保留活动时，Activity会被销毁，但是单例持有它的Context引用，Activity没法销毁 解决：对于生命周期比Activity长的对象，要避免直接引用Activity的context，可以考虑使用ApplicationContext

8 非静态内部类创建静态实例引起的内存泄漏 原因：非静态的内部类会自动持有外部类的引用，创建的静态实例就会一直持有的引用 解决：可以考虑把内部类声明为静态的

9 非静态匿名内部类引起的内存泄漏 原因：如果匿名内部类被异步线程使用，可能会引起内存泄漏 解决：可以考虑把内部类声明为静态的

10 资源对象没有关闭引起的内存泄漏 原因：资源性对象比如Cursor、File、Bitmap、视频等，系统都用了一些缓冲技术，在使用这些资源之后没有关闭 解决：处理完资源对象的逻辑记得关闭，最好是形成习惯现写一开一关

11 集合对象没有及时清理引起的内存泄漏 原因：如果集合是static、不断的往里面添加东西、又忘记去清理，肯定会引起内存泄漏 解决：集合里面的东西、有加入就应该对应有相应的删除