Android系列基础知识总结

四大组件

Activity

Activity生命周期

在这里插入图片描述

不同场景下Activity生命周期的变化过程

启动Activity： onCreate()—>onStart()—>onResume()，Activity进入运行状态。
Activity退居后台：当前Activity转到新的Activity界面或按Home键回到主屏： onPause()—>onStop()，进入停滞状态。
Activity返回前台： onRestart()—>onStart()—>onResume()，再次回到运行状态。
Activity退居后台，且系统内存不足，系统会杀死这个后台状态的Activity，若再次回到这个Activity,则会走onCreate()–>onStart()—>onResume()
锁定屏与解锁屏幕只会调用onPause()，而不会调用onStop方法，开屏后则调用onResume()

Activity 四中launchMode

standard
singleTop
singleTask
singleInstance
我们可以在AndroidManifest.xml配置的android:launchMode属性为以上四种之一。

standard standard模式是默认的启动模式，不用为配置android:launchMode属性即可，当然也可以指定值为standard。standard启动模式，不管有没有已存在的实例，都生成新的实例。
singleTop 我们在上面的基础上为指定属性android:launchMode=”singleTop”，系统就会按照singleTop启动模式处理跳转行为。跳转时系统会先在栈结构中寻找是否有一个Activity实例正位于栈顶，如果有则不再生成新的，而是直接使用。如果系统发现存在有Activity实例,但不是位于栈顶，重新生成一个实例。这就是singleTop启动模式，如果发现有对应的Activity实例正位于栈顶，则重复利用，不再生成新的实例。
singleTask 如果发现有对应的Activity实例，则使此Activity实例之上的其他Activity实例统统出栈，使此Activity实例成为栈顶对象，显示到幕前。
singleInstance 这种启动模式比较特殊，因为它会启用一个新的栈结构，将Acitvity放置于这个新的栈结构中，并保证不再有其他Activity实例进入。

LaunchMode使用场景

singleTop适合接收通知启动的内容显示页面。例如，某个新闻客户端的新闻内容页面，如果收到10个新闻推送，每次都打开一个新闻内容页面是很烦人的。
singleTask适合作为程序入口点。例如浏览器的主界面。不管从多少个应用启动浏览器，只会启动主界面一次，其余情况都会走onNewIntent，并且会清空主界面上面的其他页面。
singleInstance应用场景：闹铃的响铃界面。你以前设置了一个闹铃：上午6点。在上午5点58分，你启动了闹铃设置界面，并按 Home 键回桌面；在上午5点59分时，你在微信和朋友聊天；在6点时，闹铃响了，并且弹出了一个对话框形式的 Activity(名为 AlarmAlertActivity) 提示你到6点了(这个 Activity 就是以 SingleInstance 加载模式打开的)，你按返回键，回到的是微信的聊天界面，这是因为 AlarmAlertActivity 所在的 Task 的栈只有他一个元素，因此退出之后这个 Task 的栈空了。如果是以 SingleTask 打开 AlarmAlertActivity，那么当闹铃响了的时候，按返回键应该进入闹铃设置界面。

fragment

在这里插入图片描述

问题

若Activity已经销毁,此时AsynTask执行完并返回结果,会报异常么? 当一个App旋转时，整个Activity会被销毁和重建。当Activity重启时，AsyncTask中对该Activity的引用是无效的，因此onPostExecute()就不会起作用，若AsynTask正在执行，折会报 view not attached to window manager 异常.同样也是生命周期的问题，在 Activity 的onDestory()方法中调用Asyntask.cancal方法，让二者的生命周期同步
内存不足时,系统会杀死后台的Activity,如果需要进行一些临时状态的保存,在哪个方法进行:Activity的 onSaveInstanceState() 和 onRestoreInstanceState()并不是生命周期方法,不同于 onCreate()、onPause()等生命周期方法，它们并不一定会被触发。当应用遇到意外情况（如：内存不足、用户直接按Home键）由系统销毁一个Activity，onSaveInstanceState() 会被调用。但是当用户主动去销毁一个Activity时，例如在应用中按返回键，onSaveInstanceState()就不会被调用。除非该activity是被用户主动销毁的，通常onSaveInstanceState()只适合用于保存一些临时性的状态，而onPause()适合用于数据的持久化保存。
Android两个应用能在同一个任务栈吗？栈一般以包名命名，两个应用的签名和udid要相同

Service

保证Service在后台不被kill的方法

Service设置成START_STICKY kill 后会被重启（等待5秒左右），重传Intent，保持与重启前一样
通过 startForeground将进程设置为前台进程，做前台服务，优先级和前台应用一个级别，除非在系统内存非常缺，否则此进程不会被 kill
双进程Service：让2个进程互相保护**，其中一个Service被清理后，另外没被清理的进程可以立即重启进程
QQ黑科技: 在应用退到后台后，另起一个只有 1 像素的页面停留在桌面上，让自己保持前台状态，保护自己不被后台清理工具杀死
在已经root的设备下，修改相应的权限文件,将App伪装成系统级的应用 Android4.0系列的一个漏洞，已经确认可行
用C编写守护进程(即子进程) : Android系统中当前进程(Process)fork出来的子进程，被系统认为是两个不同的进程。当父进程被杀死的时候，子进程仍然可以存活，并不受影响。鉴于目前提到的在Android->- Service层做双守护都会失败，我们可以fork出c进程，多进程守护。死循环在那检查是否还存在，具体的思路如下（Android5.0以上的版本不可行）
用C编写守护进程(即子进程)，守护进程做的事情就是循环检查目标进程是否存在，不存在则启动它。
在NDK环境中将1中编写的C代码编译打包成可执行文件(BUILD_EXECUTABLE)。主进程启动时将守护进程放入私有目录下，赋予可执行权限，启动它即可。
联系厂商，加入白名单

Service进程优先级

在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = “1000”这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时适用于广播。

IntentServices

IntentService是Service的子类，是一个异步的，会自动停止的服务，很好解决了传统的Service中处理完耗时操作忘记停止并销毁Service的问题

生成一个默认的且与线程相互独立的工作线程执行所有发送到onStartCommand()方法的Intent,可以在onHandleIntent()中处理.

串行队列,每次只运行一个任务,不存在线程安全问题,所有任务执行完后自动停止服务,不需要自己手动调用stopSelf()来停止.

BroadcastReceiver

Android引入广播机制原因

从MVC的角度考虑(应用程序内) 其实回答这个问题的时候还可以这样问，android为什么要有那4大组件，现在的移动开发模型基本上也是照搬的web那一套MVC架构，只不过是改了点嫁妆而已。android的四大组件本质上就是为了实现移动或者说嵌入式设备上的MVC架构，它们之间有时候是一种相互依存的关系，有时候又是一种补充关系，引入广播机制可以方便几大组件的信息和数据交互。
程序间互通消息(例如在自己的应用程序内监听系统来电)
效率上(参考UDP的广播协议在局域网的方便性)
设计模式上(反转控制的一种应用，类似监听者模式)

注册广播的两种方法

静态注册:在清单文件中注册，常见的有监听设备启动，常驻注册不会随程序生命周期改变
动态注册:在代码中注册，随着程序的结束，也就停止接受广播了

补充一点：有些广播只能通过动态方式注册，比如时间变化事件、屏幕亮灭事件、电量变更事件，因为这些事件触发频率通常很高，如果允许后台监听，会导致进程频繁创建和销毁，从而影响系统整体性能

两种广播类型

普通广播为全局广播,LocalBroadcastManager是Android Support包提供了一个工具，是用来在同一个应用内的不同组件间发送Broadcast的。

使用LocalBroadcastManager有如下好处：

发送的广播只会在自己App内传播，不会泄露给其他App，确保隐私数据不会泄露
其他App也无法向你的App发送该广播，不用担心其他App会来搞破坏
比系统全局广播更加高效

和系统广播使用方式类似：
先通过LocalBroadcastManager lbm = LocalBroadcastManager.getInstance(this); 获取实例,然后通过函数 registerReceiver来注册监听器

ContentProvider

实现数据共享

当一个应用程序需要把自己的数据暴露给其他程序使用时，该就用程序就可通过提供ContentProvider来实现；其他应用程序就可通过ContentResolver来操作ContentProvider暴露的数据。一旦某个应用程序通过ContentProvider暴露了自己的数据操作接口，那么不管该应用程序是否启动，其他应用程序都可以通过该接口来操作该应用程序的内部数据，包括增加数据、删除数据、修改数据、查询数据等。

ContentProvider以某种Uri的形式对外提供数据，允许其他应用访问或修改数据；其他应用程序使用ContentResolver根据Uri去访问操作指定数据。步骤：

定义自己的ContentProvider类，该类需要继承Android提供的ContentProvider基类。
在AndroidManifest.xml文件中注册个ContentProvider，注册ContenProvider时需要为它绑定一个URL。例： android:authorities=”com.myit.providers.MyProvider” /> 说明：authorities就相当于为该ContentProvider指定URL。注册后，其他应用程序就可以通过该Uri来访问MyProvider所暴露的数据了。
接下来，使用ContentResolver操作数据，Context提供了如下方法来获取ContentResolver对象。一般来说，ContentProvider是单例模式，当多个应用程序通过ContentResolver来操作 ContentProvider提供的数据时，ContentResolver调用的数据操作将会委托给同一个ContentProvider处理。使用ContentResolver操作数据只需两步： 1、调用Activity的ContentResolver获取ContentResolver对象。 2、根据需要调用ContentResolver的insert()、delete()、update()和query（）方法操作数据即可

ContentProvider的主要还是用于数据共享，其可以对Sqlite，SharePreferences，File等进行数据操作用来共享数据。而sql的可以理解为数据库的一门语言，可以使用它完成CRUD等一系列的操作

View与布局

LinearLayout和RelativeLayout性能对比

RelativeLayout会让子View调用2次onMeasure，LinearLayout 在有weight时，也会调用子View2次onMeasure
RelativeLayout的子View如果高度和RelativeLayout不同，则会引发效率问题，当子View很复杂时，这个问题会更加严重。如果可以，尽量使用padding代替margin。
在不影响层级深度的情况下,使用LinearLayout和FrameLayout而不是RelativeLayout。
最后再思考一下文章开头那个矛盾的问题，为什么Google给开发者默认新建了个RelativeLayout，而自己却在DecorView中用了个LinearLayout。因为DecorView的层级深度是已知而且固定的，上面一个标题栏，下面一个内容栏。采用RelativeLayout并不会降低层级深度，所以此时在根节点上用LinearLayout是效率最高的。而之所以给开发者默认新建了个RelativeLayout是希望开发者能采用尽量少的View层级来表达布局以实现性能最优，因为复杂的View嵌套对性能的影响会更大一些。

绘制

自定义view的基本流程

明确需求，确定你想实现的效果
确定是使用组合控件的形式还是全新自定义的形式，组合控件即使用多个系统控件来合成一个新控件，你比如titilebar，这种形式相对简单，参考
如果是完全自定义一个view的话，你首先需要考虑继承哪个类，是View呢，还是ImageView等子类。
根据需要去复写View#onDraw、View#onMeasure、View#onLayout方法
根据需要去复写dispatchTouchEvent、onTouchEvent方法
根据需要为你的自定义view提供自定义属性，即编写attr.xml,然后在代码中通过TypedArray等类获取到自定义属性值
需要处理滑动冲突、像素转换等问题

View的绘制流程

在这里插入图片描述

measure()方法，layout()，draw()三个方法主要存放了一些标识符，来判断每个View是否需要再重新测量，布局或者绘制，主要的绘制过程还是在onMeasure，onLayout，onDraw这个三个方法中

onMesarue() 为整个View树计算实际的大小，即设置实际的高(对应属性:mMeasuredHeight)和宽(对应属性: mMeasureWidth)，每个View的控件的实际宽高都是由父视图和本身视图决定的。
onLayout() 为将整个根据子视图的大小以及布局参数将View树放到合适的位置上。
onDraw() 开始绘制图像，绘制的流程如下
1. 首先绘制该View的背景
2. 调用onDraw()方法绘制视图本身 (每个View都需要重载该方法，ViewGroup不需要实现该方法)
3. 如果该View是ViewGroup，调用dispatchDraw ()方法绘制子视图
  绘制滚动条

自定义View执行invalidate()方法,不会回调onDraw()可能的原因

自定义一个view时，重写onDraw。调用view.invalidate(),会触发onDraw和computeScroll()。前提是该view被附加在当前窗口.
view.postInvalidate(); //是在非UI线程上调用的
自定义一个ViewGroup，重写onDraw。onDraw可能不会被调用，原因是需要先设置一个背景(颜色或图)。表示这个group有东西需要绘制了，才会触发draw，之后是onDraw。因此，一般直接重写dispatchDraw来绘制viewGroup.自定义一个ViewGroup,dispatchDraw会调用drawChild.

事件传递机制

事件从Activity.dispatchTouchEvent()开始传递，只要没有被停止或拦截，从最上层的View(ViewGroup)开始一直往下(子View)传递。子View可以通过onTouchEvent()对事件进行处理。
事件由父View(ViewGroup)传递给子View，ViewGroup可以通过onInterceptTouchEvent()对事件做拦截，停止其往下传递。
如果事件从上往下传递过程中一直没有被停止，且最底层子View没有消费事件，事件会反向往上传递，这时父View(ViewGroup)可以进行消费，如果还是没有被消费的话，最后会到Activity的onTouchEvent()函数。
如果View没有对ACTION_DOWN进行消费，之后的其他事件不会传递过来。
OnTouchListener优先于onTouchEvent()对事件进行消费。

上面的消费即表示相应函数返回值为true。
View中setOnTouchListener中的onTouch,onTouchEvent,onClick的执行顺序:onTouch优于onTouchEvent,onTouchEvent优于onClick

Android下滑冲突的常见解决思路:相关的滑动组件重写onInterceptTouchEvent，然后判断根据xy值，来决定是否要拦截当前操作

动画

三种动画

逐帧动画(Drawable Animation)：加载一系列Drawable资源来创建动画，简单来说就是播放一系列的图片来实现动画效果，可以自定义每张图片的持续时间
补间动画(Tween Animation)： Tween可以对View对象实现一系列简单的动画效果，比如位移，缩放，旋转，透明度等等。但是它并不会改变View属性的值，只是改变了View的绘制的位置，比如，一个按钮在动画过后，不在原来的位置，但是触发点击事件的仍然是原来的坐标。
属性动画(Property Animation)：动画的对象除了传统的View对象，还可以是Object对象，动画结束后，Object对象的属性值被实实在在的改变了

动画原理

Animation框架定义了透明度，旋转，缩放和位移几种常见的动画，而且控制的是整个View，实现原理是每次绘制视图时View所在的ViewGroup中的drawChild函数获取该View的Animation的Transformation值，然后调用canvas.concat(transformToApply.getMatrix())，通过矩阵运算完成动画帧，如果动画没有完成，继续调用invalidate()函数，启动下次绘制来驱动动画，动画过程中的帧之间间隙时间是绘制函数所消耗的时间，可能会导致动画消耗比较多的CPU资源，最重要的是，动画改变的只是显示，并不能相应事件

属性动画特性

如果你的需求中只需要对View进行移动、缩放、旋转和淡入淡出操作，那么补间动画确实已经足够健全了。但是很显然，这些功能是不足以覆盖所有的场景的，一旦我们的需求超出了移动、缩放、旋转和淡入淡出这四种对View的操作，那么补间动画就不能再帮我们忙了，也就是说它在功能和可扩展方面都有相当大的局限性，那么下面我们就来看看补间动画所不能胜任的场景。
注意上面我在介绍补间动画的时候都有使用“对View进行操作”这样的描述，没错，补间动画是只能够作用在View上的。也就是说，我们可以对一个Button、TextView、甚至是LinearLayout、或者其它任何继承自View的组件进行动画操作，但是如果我们想要对一个非View的对象进行动画操作，抱歉，补间动画就帮不上忙了。可能有的朋友会感到不能理解，我怎么会需要对一个非View的对象进行动画操作呢？这里我举一个简单的例子，比如说我们有一个自定义的View，在这个View当中有一个Point对象用于管理坐标，然后在onDraw()方法当中就是根据这个Point对象的坐标值来进行绘制的。也就是说，如果我们可以对Point对象进行动画操作，那么整个自定义View的动画效果就有了。显然，补间动画是不具备这个功能的，这是它的第一个缺陷。
然后补间动画还有一个缺陷，就是它只能够实现移动、缩放、旋转和淡入淡出这四种动画操作，那如果我们希望可以对View的背景色进行动态地改变呢？很遗憾，我们只能靠自己去实现了。说白了，之前的补间动画机制就是使用硬编码的方式来完成的，功能限定死就是这些，基本上没有任何扩展性可言。
最后，补间动画还有一个致命的缺陷，就是它只是改变了View的显示效果而已，而不会真正去改变View的属性。什么意思呢？比如说，现在屏幕的左上角有一个按钮，然后我们通过补间动画将它移动到了屏幕的右下角，现在你可以去尝试点击一下这个按钮，点击事件是绝对不会触发的，因为实际上这个按钮还是停留在屏幕的左上角，只不过补间动画将这个按钮绘制到了屏幕的右下角而已。

优化

布局优化

避免OverDraw过渡绘制
优化布局层级
避免嵌套过多无用布局
当我们在画布局的时候，如果能实现相同的功能，优先考虑相对布局，然后在考虑别的布局，不要用绝对布局。
使用<include />标签把复杂的界面需要抽取出来
使用<merge />标签，因为它在优化UI结构时起到很重要的作用。目的是通过删减多余或者额外的层级，从而优化整个Android Layout的结构。核心功能就是减少冗余的层次从而达到优化UI的目的！
ViewStub 是一个隐藏的，不占用内存空间的视图对象，它可以在运行时延迟加载布局资源文件。

ListView卡顿的原因以及优化策略

重用converView：通过复用converview来减少不必要的view的创建，另外Infalte操作会把xml文件实例化成相应的View实例，属于IO操作，是耗时操作。
减少findViewById()操作：将xml文件中的元素封装成viewholder静态类，通过converview的setTag和getTag方法将view与相应的holder对象绑定在一起，避免不必要的findviewbyid操作
避免在 getView 方法中做耗时的操作: 例如加载本地 Image 需要载入内存以及解析 Bitmap ，都是比较耗时的操作，如果用户快速滑动listview，会因为getview逻辑过于复杂耗时而造成滑动卡顿现象。用户滑动时候不要加载图片，待滑动完成再加载，可以使用这个第三方库glide
Item的布局层次结构尽量简单，避免布局太深或者不必要的重绘
尽量能保证 Adapter 的 hasStableIds() 返回 true 这样在 notifyDataSetChanged() 的时候，如果item内容并没有变化，ListView 将不会重新绘制这个 View，达到优化的目的
在一些场景中，ScollView内会包含多个ListView，可以把listview的高度写死固定下来。由于ScollView在快速滑动过程中需要大量计算每一个listview的高度，阻塞了UI线程导致卡顿现象出现，如果我们每一个item的高度都是均匀的，可以通过计算把listview的高度确定下来，避免卡顿现象出现
使用 RecycleView 代替listview：每个item内容的变动，listview都需要去调用notifyDataSetChanged来更新全部的item，太浪费性能了。RecycleView可以实现当个item的局部刷新，并且引入了增加和删除的动态效果，在性能上和定制上都有很大的改善
ListView 中元素避免半透明：半透明绘制需要大量乘法计算，在滑动时不停重绘会造成大量的计算，在比较差的机子上会比较卡。在设计上能不半透明就不不半透明。实在要弄就把在滑动的时候把半透明设置成不透明，滑动完再重新设置成半透明。
尽量开启硬件加速：硬件加速提升巨大，避免使用一些不支持的函数导致含泪关闭某个地方的硬件加速。当然这一条不只是对 ListView。

ViewHolder为什么要被声明成静态内部类
这个是考静态内部类和非静态内部类的主要区别之一。非静态内部类会隐式持有外部类的引用，就像大家经常将自定义的adapter在Activity类里，然后在adapter类里面是可以随意调用外部activity的方法的。当你将内部类定义为static时，你就调用不了外部类的实例方法了，因为这时候静态内部类是不持有外部类的引用的。声明ViewHolder静态内部类，可以将ViewHolder和外部类解引用。大家会说一般ViewHolder都很简单，不定义为static也没事吧。确实如此，但是如果你将它定义为static的，说明你懂这些含义。万一有一天你在这个ViewHolder加入一些复杂逻辑，做了一些耗时工作，那么如果ViewHolder是非静态内部类的话，就很容易出现内存泄露。如果是静态的话，你就不能直接引用外部类，迫使你关注如何避免相互引用。所以将 ViewHolder内部类定义为静态的，是一种好习惯

内存泄露问题

资源对象没有关闭造成,如查询数据库没有关闭游标
构造Adapter时,没有使用缓存ConvertView
Bitmap对象在不使用时调用recycle()释放内存
context逃逸问题
注册没有取消,如动态注册广播在Activity销毁前没有unregisterReceiver
集合对象未清理,如无用时没有释放对象的引用
在Activity中使用非静态的内部类，并开启一个长时间运行的线程，因为内部类持有Activity的引用，会导致Activity本来可以被gc时却长期得不到回收

OOM发生情况

类的静态变量持有大数据对象静态变量长期维持到大数据对象的引用，阻止垃圾回收。
非静态内部类存在静态实例非静态内部类会维持一个到外部类实例的引用，如果非静态内部类的实例是静态的，就会间接长期维持着外部类的引用，阻止被回收掉。
资源对象未关闭资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。解决办法：比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭），如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭。程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险，记得try catch后，在finally方法中关闭连接
Handler内存泄漏 Handler作为内部类存在于Activity中，但是Handler生命周期与Activity生命周期往往并不是相同的，比如当Handler对象有Message在排队，则无法释放，进而导致本该释放的Acitivity也没有办法进行回收。解决办法:声明handler为static类，这样内部类就不再持有外部类的引用了，就不会阻塞Activity的释放.如果内部类实在需要用到外部类的对象，可在其内部声明一个弱引用引用外部类
一些不良代码习惯有些代码并不造成内存泄露，但是他们的资源没有得到重用，频繁的申请内存和销毁内存，消耗CPU资源的同时，也引起内存抖动解决方案如果需要频繁的申请内存对象和和释放对象，可以考虑使用对象池来增加对象的复用。例如ListView便是采用这种思想，通过复用converview来避免频繁的GC

避免oom

使用更加轻量的数据结构例如，我们可以考虑使用ArrayMap/SparseArray而不是HashMap等传统数据结构。通常的HashMap的实现方式更加消耗内存，因为它需要一个额外的实例对象来记录Mapping操作。另外，SparseArray更加高效，在于他们避免了对key与value的自动装箱（autoboxing），并且避免了装箱后的解箱。
避免在Android里面使用Enum Android官方培训课程提到过“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”，具体原理请参考《Android性能优化典范（三）》，所以请避免在Android里面使用到枚举。
减小Bitmap对象的内存占用 Bitmap是一个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，，通常来说有以下2个措施： inSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。 decode format：解码格式，选择ARGB_6666/RBG_545/ARGB_4444/ALPHA_6，存在很大差异
Bitmap对象的复用缩小Bitmap的同时，也需要提高BitMap对象的复用率，避免频繁创建BitMap对象，复用的方法有以下2个措施 LRUCache : “最近最少使用算法”在Android中有极其普遍的应用。ListView与GridView等显示大量图片的控件里，就是使用LRU的机制来缓存处理好的Bitmap，把近期最少使用的数据从缓存中移除，保留使用最频繁的数据， inBitMap高级特性:利用inBitmap的高级特性提高Android系统在Bitmap分配与释放执行效率。使用inBitmap属性可以告知Bitmap解码器去尝试使用已经存在的内存区域，新解码的Bitmap会尝试去使用之前那张Bitmap在Heap中所占据的pixel data内存区域，而不是去问内存重新申请一块区域来存放Bitmap。利用这种特性，即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量的内存大小
使用更小的图片在涉及给到资源图片时，我们需要特别留意这张图片是否存在可以压缩的空间，是否可以使用更小的图片。尽量使用更小的图片不仅可以减少内存的使用，还能避免出现大量的InflationException。假设有一张很大的图片被XML文件直接引用，很有可能在初始化视图时会因为内存不足而发生InflationException，这个问题的根本原因其实是发生了OOM。
StringBuilder 在有些时候，代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代频繁的“+”。
避免在onDraw方法里面执行对象的创建类似onDraw等频繁调用的方法，一定需要注意避免在这里做创建对象的操作，因为他会迅速增加内存的使用，而且很容易引起频繁的gc，甚至是内存抖动。

ANR

ANR全称Application Not Responding，意思就是程序未响应。如果一个应用无法响应用户的输入，系统就会弹出一个ANR对话框，用户可以自行选择继续等待亦或者是停止当前程序。一旦出现下面两种情况，则弹出ANR对话框

应用在5秒内未响应用户的输入事件（如按键或者触摸）
BroadcastReceiver未在10秒内完成相关的处理

Service在特定的时间内无法处理完成
超时的原因一般有两种：
(1)当前的事件没有机会得到处理（UI线程正在处理前一个事件没有及时完成或者looper被某种原因阻塞住）
(2)当前的事件正在处理，但没有及时完成
UI线程尽量只做跟UI相关的工作，耗时的工作（数据库操作，I/O，连接网络或者其他可能阻碍UI线程的操作）放入单独的线程处理，尽量用Handler来处理UI thread和thread之间的交互。
UI线程主要包括如下：

Activity:onCreate(), onResume(), onDestroy(), onKeyDown(), onClick()
AsyncTask: onPreExecute(), onProgressUpdate(), onPostExecute(), onCancel()
Mainthread handler: handleMessage(), post(runnable r)

如何定位ANR错误

开发机器上,查看/data/anr/traces.text.最新的ANR信息在最开始部分.

如何避免ANR

避免ANR最核心的一点就是在主线程减少耗时操作.通常需要从以下几个方案下手:

使用子线程处理耗时IO操作。
降低子线程优先级使用Thread或者HandlerThread时，调用Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)设置优先级，否则仍然会降低程序响应，因为默认Thread的优先级和主线程相同。
使用Handler处理子线程结果，而不是使用Thread.wait()或者Thread.sleep()来阻塞主线程。
Activity的onCreate和onResume回调中尽量避免耗时的代码
BroadcastReceiver中onReceive代码也要尽量减少耗时操作建议使用IntentService处理。IntentService是一个异步的，会自动停止的服务，很好解决了传统的Service中处理完耗时操作忘记停止并销毁Service的问题

native

Dalvik,JVM,ART区别

什么是Dalvik？

Dalvik是Google公司自己设计用于Android平台的虚拟机。
Dalvik虚拟机是Google等厂商合作开发的Android移动设备平台的核心组成部分之一。
它可以支持已转换为**.dex格式**的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。
Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux 进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。
很长时间以来，Dalvik虚拟机一直被用户指责为拖慢安卓系统运行速度不如IOS的根源。
2014年6月25日，Android L 正式亮相于召开的谷歌I/O大会，Android L 改动幅度较大，谷歌将直接删除Dalvik，代替它的是传闻已久的ART。

什么是ART？

即Android Runtime
ART 的机制与 Dalvik 不同。在Dalvik下，应用每次运行的时候，字节码都需要通过即时编译器（just in time ，JIT）转换为机器码，这会拖慢应用的运行效率，而在ART 环境中，应用在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。这个过程叫做预编译（AOT,Ahead-Of-Time）。这样的话，应用的启动(首次)和执行都会变得更加快速。

ART优缺点
优点：

系统性能的显著提升。
用启动更快、运行更快、体验更流畅、触感反馈更及时。
更长的电池续航能力。
支持更低的硬件。
缺点：
机器码占用的存储空间更大，字节码变为机器码之后，可能会增加10%-20%（不过在应用包中，可执行的代码常常只是一部分。比如最新的 Google+ APK 是 28.3 MB，但是代码只有 6.9 MB。）
应用的安装时间会变长。

JVM

JVM其核心目的，是为了构建一个真正跨OS平台，跨指令集的程序运行环境(VM)。DVM的目的是为了将android OS的本地资源和环境，以一种统一的界面提供给应用程序开发。严格来说，DVM不是真正的VM，它只是开发的时候提供了VM的环境，并不是在运行的时候提供真正的VM容器。这也是为什么JVM必须设计成stack-based的原因。

Dalvik和JVM有啥关系？

主要区别：

Dalvik是基于寄存器的，而JVM是基于栈的。
Dalvik运行dex文件，而JVM运行java字节码

自Android 2.2开始，Dalvik支持JIT（just-in-time，即时编译技术）。优化后的Dalvik较其他标准虚拟机存在一些不同特性:

占用更少空间
为简化翻译，常量池只使用32位索引
标准Java字节码实行8位堆栈指令,Dalvik使用16位指令集直接作用于局部变量。局部变量通常来自4位的“虚拟寄存器”区。这样减少了Dalvik的指令计数，提高了翻译速度。

当Android启动时，Dalvik VM 监视所有的程序（APK），并且创建依存关系树，为每个程序优化代码并存储在Dalvik缓存中。Dalvik第一次加载后会生成Cache文件，以提供下次快速加载，所以第一次会很慢。
Dalvik解释器采用预先算好的Goto地址，每个指令对内存的访问都在64字节边界上对齐。这样可以节省一个指令后进行查表的时间。为了强化功能, Dalvik还提供了快速翻译器（Fast Interpreter）。

一般来说,基于堆栈的机器必须使用指令才能从堆栈上的加载和操作数据,因此,相对基于寄存器的机器，它们需要更多的指令才能实现相同的性能。但是基于寄存器机器上的指令必须经过编码,因此,它们的指令往往更大。

Dalvik虚拟机既不支持Java SE 也不支持Java ME类库(如：Java类,AWT和Swing都不支持)。相反,它使用自己建立的类库（Apache Harmony Java的一个子集）。

JVM：所有的jar程序，其运行环境完全是由JVM来提供，包括运行时，各类资源的调度，而JVM的架构，其设计为一个JVM里面可以运行多个java程序，JVM就像一个真正的“机器”，可以跑着多个程序。如果去看看一些企业级的JVM(例如tom cat，WAS)，从OS的进程管理中，一般你只能看见一个JVM的进程(当然，你也可以起多个JVM，但JVM架构就是OS-JVM-APP的3层运行时模式)，而看不见JVM里面运行的程序，而一个JVM里，可以跑多个java app。简单得说，JVM完全屏蔽了应用程序和OS之间的联系，而改用JVM充当了中间层，这也是一个真正跨平台运行时VM必须要做到的。只要是相同的 JDK，JVM为所有在其中运行的程序，提供了完全一致的运行环境，而不论你是什么样的底层OS和硬件条件。因此这也是我在其他一篇答案中提到，JVM的特点是取底层OS和硬件环境的交集，从而保障这种一致性。而所有应用程序和底层资源的互动，一定是依赖JVM的传递和转换来实现。JVM真正实现了一个 OS对应用程序运行时管理的所有功能。从开发环境角度和运行时角度，都是完全一致的真正VM

DVM：而DVM的特点在于使用了Zygote，Zygote有几个非常有意思的特点。

一是Zygote采用预加载，由其首先判定安装的APK的需要以及相互依存树，以及OS及硬件环境的特点，在每次启动的时候进行预加载(现在你明白为什么 android的app在应用管理里你能轻易查到它都调用了那些重庆肛肠科关键性的本地资源的原因了吧?)，这就意味着，你安装的应用越多，Zygote的加载就越慢，一般来说你的手机启动就会越慢。另外来说，在不同的硬件环境里(例如有无GPS芯片)Zygote初始化的实例是不同的。也就是说，zygote并不提供一个统一的运行环境，具有更好的弹性，这种机制意味着DVM可以取底层资源的合集来提供上层应用使用，差别只是在程序安装或者启动的过程中，DVM可以提示程序需求资源，本地环境可能未能满足而导致无法运行。DVM的Zygote并不是提供一个运行时容器，它提供的只是一个用于共享的进程，所有的应用程序运行，都是独立的，OS级别的进程，直接受到OS层面的资源控制以及调度的影响，只是他们共享Zygote说预加载的类而已。这也就是我为什么说，DVM就像是给每个应用程序在底层加了个套子，而不是提供了一个真正的运行时的VM。也就是说，DVM在开发环境中说提供的VM平台，和运行时的环境是很有可能不一致的。开发环境中提供的VM平台，是一个各种运行时可能环境的合集。

从这点上来说，一般我们认为，JVM中的JAVA程序的崩溃，最多导致JVM的崩溃，而不会导致OS崩溃，但是apk的崩溃，可以直接导致OS崩溃，android手机会因为应用程序死机，大家应该是很常见了。但是大家一般是不会看到java程序导致死机吧?因为运行时中间隔着一个JVM。(当然，其实还是有些小门道可以用java程序让OS崩溃，因为这个，我和某些JAVA大拿打赌赢过饭局，呵呵，不过这是其他话题，不在这里展开了)

除此之外，在JVM的机制中，不同的程序，打包以后，他们都是在运行层级真正独立的程序(指程序应用重庆妇科医院他们相互之间的关系，而不是和JVM的关系)，即便他们在包里使用了同样的类，运行时都是单独加载，单独运行的(及加载多遍)。

DVM这种预加载-共享的机制，使得不同应用之间，在运行时，是共享相同的类的，一般来说，在系统资源消耗方面，拥有更高的效率。

最后，补充一点，byte code并不意味着就是解释执行，也能是加载编译，安装编译，预编译等等。实际上，不同的byte code的程序，不同的技术，不同的具体语言，其真正执行的情况挺复杂，难以一概而论的，好多都是混合技术的案例。

在智能手机大部分都可以让用户选择使用Dalvik还是ART模式。当然默认还是使用Dalvik模式。
用法：设置-辅助功能-开发者选项（开发人员工具）-选择运行环境（不同的手机设置的步骤可能不一样）。

问题整理

1.View 的onDraw与dispatchDraw

绘制View本身的内容，通过调用View.onDraw(canvas)函数实现
绘制自己的孩子通过dispatchDraw（canvas）实现
View组件的绘制会调用draw(Canvas canvas)方法，draw过程中主要是先画Drawable背景，对 drawable调用setBounds()然后是draw(Canvas c)方法.有点注意的是背景drawable的实际大小会影响view组件的大小，drawable的实际大小通过getIntrinsicWidth()和getIntrinsicHeight()获取，当背景比较大时view组件大小等于背景drawable的大小

画完背景后，draw过程会调用onDraw(Canvas canvas)方法，然后就是dispatchDraw(Canvas canvas)方法, dispatchDraw()主要是分发给子组件进行绘制，我们通常定制组件的时候重写的是onDraw()方法。值得注意的是ViewGroup容器组件的绘制，当它没有背景时直接调用的是dispatchDraw()方法, 而绕过了draw()方法，当它有背景的时候就调用draw()方法，而draw()方法里包含了dispatchDraw()方法的调用。因此要在ViewGroup上绘制东西的时候往往重写的是dispatchDraw()方法而不是onDraw()方法，或者自定制一个Drawable，重写它的draw(Canvas c)和 getIntrinsicWidth(),

getIntrinsicHeight()方法，然后设为背景。

2.opengl可编程管线与固定区别

1）、固定渲染管线 ——这是标准的几何&光照(T&L)管线，功能是固定的，它控制着世界、视、投影变换及固定光照控制和纹理混合。T&L管线可以被渲染状态控制，矩阵，光照和采制参数。
2）、顶点着色器——图形开发人员可以对渲染管线中的顶点运算和像素运算分别进行编程处理了，而无须象以前那样套用一些固定函数，取代设置参数来控制管线，最早出现与DX8，包括PS和VS两部分。

3.光照

4.深度测试

像素归属测试：这一步骤由OpenGL ES内部进行，不由开发人员控制；测试确定帧缓冲区的位置的像素是否归属当前OpenGL ES所有，如不属于或被另一个窗口遮挡，从而完全不显示这些像素。

裁剪测试：判断像素是否在由 glScissor 定义的剪裁矩形内，不在该剪裁区域内的像素就会被剪裁掉；

模板和深度测试：测试输入片段的模板和深度值上进行，以确定片段是否应该被拒绝；深度测试比较下一个片段与帧缓冲区中的片段的深度，从而决定哪一个像素在前面，哪一个像素被遮挡；

混合：是将片段的颜色和帧缓冲区中已有的颜色值进行混合，并将混合所得的新值写入帧缓冲；

抖动：可用于最小化因为使用有限精度在帧缓冲区中保存颜色值而产生的伪像。

Framebuffer：这是流水线的最后一个阶段，Framebuffer 中存储这可以用于渲染到屏幕或纹理中的像素值，也可以从Framebuffer 中读回像素值，但不能读取其他值（如深度值，模版值等）。

5.Intent为什么可序列化的数据

大家都知道进行Android开发的时候，无法将对象的引用传给Activities或者Fragments，我们需要将这些对象放到一个Intent或者Bundle里面，然后再传递
序列化的原因基本三种情况：

永久性保存对象，保存对象的字节序列到本地文件中；
对象在网络中传递；
对象在IPC间传递。

6.SharedPreference

之前为了解决应用的内存压力，在同一个应用中使用了多进程，但在程序自测的过程中发现不同进程之间的SharedPreferences数据不能共享，但应用内很多数据都是通过SharedPreferences来保存的，如果改成其它多进程通信的方式改动比较大。通过查看源码发现，在API Level>=11即Android 3.0可以通过Context.MODE_MULTI_PROCESS属性来实现SharedPreferences多进程共享，具体使用方式如下：

public class PreferencesUtils {
    public static String PREFERENCE_NAME = "SharedPreferencesDemo";

    private PreferencesUtils(){

    }

    public static boolean putString(Context context, String key, String value) {
        SharedPreferences settings = context.getSharedPreferences(PREFERENCE_NAME, Context.MODE_MULTI_PROCESS);
        SharedPreferences.Editor editor = settings.edit();
        editor.putString(key, value);
        return editor.commit();
    }

    public static String getString(Context context, String key, String defaultValue) {
        SharedPreferences settings = context.getSharedPreferences(PREFERENCE_NAME, Context.MODE_MULTI_PROCESS);
        return settings.getString(key, defaultValue);
    }
}

本来以为通过MODE_MULTI_PROCESS属性使用SharedPreferences就可以解决不同进程之间不能共享数据的问题了，但SQA总是反馈一些随机但出现频率比较大的bug，比如在使用过程中没有清除程序数据的前提下，会出现欢迎界面和操作指引，这是通过保存在SharedPreferences的标志来判断用户是否是第一次启动程序的，分析发现保存在SharedPreferences中的数据丢失了，但代码中并没有去清除这些数据，所以推测可能是不同进程同一时间对SharedPreferences操作导致的，经验证确实如此，去掉多进程就不会再出现这个问题了。

由于进程间是不能内存共享的，每个进程操作的SharedPreferences都是一个单独的实例，上述的问题并不能通过锁来解决，这导致了多进程间通过SharedPreferences来共享数据是不安全的，这个问题只能通过多进程间其它的通信方式或者是在确保不会同时操作SharedPreferences数据的前提下使用SharedPreferences来解决。

apply和commit都是提交保存，区别在于apply是异步执行的，不需要等待。不论删除，修改，增加都必须调用apply或者commit提交保存。