1，android:process
解决访问SharedPreferences，不在同一进程
private SharedPreferencesDB(Context cxt) {
this.context = cxt;
Context context;
try {
context = cxt.createPackageContext(cxt.getPackageName(), Context.CONTEXT_IGNORE_SECURITY);
prefs = context.getSharedPreferences(PREFS_FILE, Context.MODE_WORLD_READABLE + Context.MODE_WORLD_WRITEABLE);//可读可写
} catch (NameNotFoundException e) {
e.printStackTrace();
}
}
如果该属性指定名称以“：”开头，则一个新的专属于该应用的进程将会被创建。
如果该进程名以小写字母开头，则为该activity提供权限以让其在一个全局的进程中运行。这样会允许多个应用的不同组件共用一个进程，以便节省资源。
2，applicationContext与context的区别
ApplicationContext，它的生命周期和我们的单例对象一致。
Context和Application Context的区别是很大的，也就是说，他们的应用场景（你也可以认为是能力）是不同的，并非所有Activity为Context的场景，Application Context都能搞定。
大家注意看到有一些NO上添加了一些数字，其实这些从能力上来说是YES，但是为什么说是NO呢？下面一个一个解释：
数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。
数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。
数字3：在receiver为null时允许，在4.2或以上的版本中，用于获取黏性广播的当前值。（可以无视）
注：ContentProvider、BroadcastReceiver之所以在上述表格中，是因为在其内部方法中都有一个context用于使用。
和UI相关的方法基本都不建议或者不可使用Application，并且，前三个操作基本不可能在Application中出现。
3、notifyDataSetChanged与notifyDataSetInvalidated
notifyDataSetInvalidated：更新数据并把列表组件移到顶部
notifyDataSetChanged：容易使列表闪动
4，android4.0前与后对于flash的处理
4.0需要硬件加速
mainfest.xml设置android:hardwareAccelerated="true"
5，防止睡眠
<uses-permission android:name="android.permission.WAKE_LOCK" />
private void acquireWakeLock() {
if (wakeLock == null) {
PowerManager pm = (PowerManager) getActivity().getSystemService(Context.POWER_SERVICE);
wakeLock = pm.newWakeLock(PowerManager.SCREEN_BRIGHT_WAKE_LOCK, this.getClass().getCanonicalName());
wakeLock.acquire();
}
}
private void releaseWakeLock() {
if (wakeLock != null && wakeLock.isHeld()) {
wakeLock.release();
wakeLock = null;
}
}
6，电话状态监听
TelephonyManager telephonyManager = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE); telephonyManager.listen(new MobliePhoneStateListener(), PhoneStateListener.LISTEN_CALL_STATE);
private class MobliePhoneStateListener extends PhoneStateListener {
@Override
public void onCallStateChanged(int state, String incomingNumber) {
if (currentMusic == null)
return;
MediaPlayer mPlayer = playerMap.get(currentMusic.getPlayUrl());
switch (state) {
case TelephonyManager.CALL_STATE_IDLE: /* 无任何状态时 */
break;
case TelephonyManager.CALL_STATE_OFFHOOK: /* 接起电话时 */
break;
case TelephonyManager.CALL_STATE_RINGING: /* 电话进来时 */
break;
default:
break;
}
}
}
7，监听耳机插拔
IntentFilter filter = new IntentFilter(AudioManager.ACTION_AUDIO_BECOMING_NOISY); this.registerReceiver(new AudioBroadCastReceiver(), filter);
public class AudioBroadCastReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (AudioManager.ACTION_AUDIO_BECOMING_NOISY.equals(intent.getAction())) {/*耳机被拔出*/
}
}
}
8，监控apk安装
<receiver
android:enabled="true"
android:name="com.mobcent.ad.android.ui.activity.receiver.AdBootReceiver" >
<intent-filter >
<action android:name="android.intent.action.PACKAGE_ADDED" />
<action android:name="android.intent.action.PACKAGE_REMOVED" />
<action android:name="android.intent.action.PACKAGE_REPLACED" />
<data android:scheme="package" />
</intent-filter>
</receiver>
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
String packageName = intent.getData().getSchemeSpecificPart();
adService = new AdServiceImpl(context);
if (Intent.ACTION_PACKAGE_ADDED.equals(action)) {//添加
}else if(Intent.ACTION_PACKAGE_REMOVED.equals(action)){//移除
}else if(Intent.ACTION_PACKAGE_INSTALL.equals(action)){//安装
}
}
9,Android本身的api并未声明会抛出异常，则其在运行时有无可能抛出runtime异常，你遇到过吗？诺有的话会导致什么问题？如何解决？
会，比如nullpointerException。我遇到过，比如textview.setText()时，textview没有初始化。会导致程序无法正常运行出现forceclose。打开控制台查看logcat信息找出异常信息并修改程序。
10,android系统会自动派发各种事件，事件触发到对应的派发顺序是
答案1：EventHub-keyInputQueue-windowManagerService-ViewRoot
答案2：windowsManager-phoneWindow-activity\
11,lauchmode及应用场景
standard，创建一个新的Activity。
singleTop，栈顶不是该类型的Activity，创建一个新的Activity。否则，onNewIntent。
singleTask，回退栈中没有该类型的Activity，创建Activity，否则，onNewIntent+ClearTop。
singleInstance，回退栈中，只有这一个Activity，没有其他Activity。
singleTop适合接收通知启动的内容显示页面。
例如，某个新闻客户端的新闻内容页面，如果收到10个新闻推送，每次都打开一个新闻内容页面是很烦人的。
singleTask适合作为程序入口点。
例如浏览器的主界面。不管从多少个应用启动浏览器，只会启动主界面一次，其余情况都会走onNewIntent，并且会清空主界面上面的其他页面。
singleInstance适合需要与程序分离开的页面。
例如闹铃提醒，将闹铃提醒与闹铃设置分离。
singleInstance不要用于中间页面，如果用于中间页面，跳转会有问题，比如：A -> B (singleInstance) -> C，完全退出后，在此启动，首先打开的是B。
12,谈谈对android的理解
android应用开发一般来说由四大块构成
activity
intent
provider
broadcastreciver
从这种结构上来看，android系统是提供了从显示层到数据层到消息机制的一整套的应用开发方案，而且是一种比较先进的解决方案。
从写android代码的过程中，我感觉到android project是一种典型的MVC结构，非常类似于主要用于WEB开发的J2EE架构，xml布局文件是view相当于JSP页面；activity和intent起到了controller的作用；provider对数据层做了良好的封装，而且provider把数据管理的范畴从数据库泛化到了数据的概念，不光管理数据记录，只要是数据文件（图片、视频、声音文件、所有其他的一切的file）都纳入管理，且提供了数据共享的机制，这是比较出彩的地方；broadcastreceiver提供了一种良好的消息机制，使得一个应用不再是一个信息孤岛，而是和其他的应用、服务等构成了信息网络，从而极大的丰富了应用的开发空间，给了应用开发者极大的想象创造的可能。
13,如何保证service在后台不被kill
拥有service的进程具有较高的优先级
官方文档告诉我们，Android系统会尽量保持拥有service的进程运行，只要在该service已经被启动(start)或者客户端连接(bindService)到它。当内存不足时，需要保持，拥有service的进程具有较高的优先级。
1． 如果service正在调用onCreate,onStartCommand或者onDestory方法，那么用于当前service的进程则变为前台进程以避免被killed。
2． 如果当前service已经被启动(start)，拥有它的进程则比那些用户可见的进程优先级低一些，但是比那些不可见的进程更重要，这就意味着service一般不会被killed.
3． 如果客户端已经连接到service (bindService),那么拥有Service的进程则拥有最高的优先级，可以认为service是可见的。
4． 如果service可以使用startForeground(int, Notification)方法来将service设置为前台状态，那么系统就认为是对用户可见的，并不会在内存不足时killed。
5． 如果有其他的应用组件作为Service,Activity等运行在相同的进程中，那么将会增加该进程的重要性。
onStartCommand方法，返回START_STICKY
StartCommond几个常量参数简介：
1、START_STICKY
在运行onStartCommand后service进程被kill后，那将保留在开始状态，但是不保留那些传入的intent。不久后service就会再次尝试重新创建，因为保留在开始状态，在创建 service后将保证调用onstartCommand。如果没有传递任何开始命令给service，那将获取到null的intent。
2、START_NOT_STICKY
在运行onStartCommand后service进程被kill后，并且没有新的intent传递给它。Service将移出开始状态，并且直到新的明显的方法（startService）调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动，也就是期间onstartCommand不会接收到任何null的intent。
3、START_REDELIVER_INTENT
在运行onStartCommand后service进程被kill后，系统将会再次启动service，并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent，那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
flags = START_STICKY;
return super.onStartCommand(intent, flags, startId);
}
【结论】 手动返回START_STICKY，亲测当service因内存不足被kill，当内存又有的时候，service又被重新创建，比较不错，但是不能保证任何情况下都被重建，比如进程被干掉了....
提升service优先级
在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = "1000"这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时适用于广播。
<service
android:name="com.dbjtech.acbxt.waiqin.UploadService"
android:enabled="true" >
<intent-filter android:priority="1000" >
<action android:name="com.dbjtech.myservice" />
</intent-filter>
</service>
【结论】目前看来，priority这个属性貌似只适用于broadcast，对于Service来说可能无效
提升service进程优先级
Android中的进程是托管的，当系统进程空间紧张的时候，会依照优先级自动进行进程的回收。Android将进程分为6个等级,它们按优先级顺序由高到低依次是:
1.前台进程( FOREGROUND_APP)
2.可视进程(VISIBLE_APP )
3. 次要服务进程(SECONDARY_SERVER )
4.后台进程 (HIDDEN_APP)
5.内容供应节点(CONTENT_PROVIDER)
6.空进程(EMPTY_APP)
当service运行在低内存的环境时，将会kill掉一些存在的进程。因此进程的优先级将会很重要，可以使用startForeground将service放到前台状态。这样在低内存时被kill的几率会低一些。
在onStartCommand方法内添加如下代码：
Notification notification = new Notification(R.drawable.ic_launcher, getString(R.string.app_name), System.currentTimeMillis()); PendingIntent pendingintent = PendingIntent.getActivity(this, 0, new Intent(this, AppMain.class), 0); notification.setLatestEventInfo(this, "uploadservice", "请保持程序在后台运行", pendingintent); <span style="color:#ff0000;"> startForeground(0x111, notification);</span>
注意在onDestroy里还需要stopForeground(true)
【结论】如果在极度极度低内存的压力下，该service还是会被kill掉，并且不一定会restart
onDestroy方法里重启service
service +broadcast 方式，就是当service走ondestory的时候，发送一个自定义的广播，当收到广播的时候，重新启动service；
【结论】当使用类似口口管家等第三方应用或是在setting里-应用-强制停止时，APP进程可能就直接被干掉了，onDestroy方法都进不来，所以还是无法保证~.~
Application加上Persistent属性
看Android的文档知道，当进程长期不活动，或系统需要资源时，会自动清理门户，杀死一些Service，和不可见的Activity等所在的进程。但是如果某个进程不想被杀死（如数据缓存进程，或状态监控进程，或远程服务进程），可以这么做：
<application
android:name="com.test.Application"
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
<span style="color:#ff0000;"> android:persistent="true"</span>
android:theme="@style/AppTheme" >
</application>
【结论】据说这个属性不能乱设置，不过设置后，的确发现优先级提高不少，或许是相当于系统级的进程，但是还是无法保证存活
监听系统广播判断Service状态
通过系统的一些广播，比如：手机重启、界面唤醒、应用状态改变等等监听并捕获到，然后判断我们的Service是否还存活，别忘记加权限啊。
<receiver android:name="com.dbjtech.acbxt.waiqin.BootReceiver" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<action android:name="android.intent.action.USER_PRESENT" />
<action android:name="android.intent.action.PACKAGE_RESTARTED" />
<action android:name="com.dbjtech.waiqin.destroy" />
</intent-filter>
</receiver>
BroadcastReceiver中：
@Override
public void onReceive(Context context, Intent intent) {
if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) {
System.out.println("手机开机了....");
startUploadService(context);
}
if (Intent.ACTION_USER_PRESENT.equals(intent.getAction())) {
startUploadService(context);
}
}
【结论】这也能算是一种措施，不过感觉监听多了会导致Service很混乱，带来诸多不便
14,Broadcast生命周期
Broadcast的生命周期只有一个回调方法：void onReceive(Context curContext,Intent broadcastMsg)。当broadcast消息到达接收者时，Android会调用他的onReceive（）方法，并且传递包含这个信息的intent对象。broadcast接收者在执行这个方法时，被认为是活动的。当onReceive（）方法返回时，它停止的活动状态。
一个活动的广播接受者进程是不能被杀死的，但是当他所消耗的内存被别的进程需要时，一个非活动状态的进程可以被系统随时杀死。
这带来一个问题，相应一个广播消息是非常耗时的，因此，很多事情需要在一个独立的线程中执行，而不是在主线程里。如果onReceive（）方法启动一个线程，那么整个进程包括刚启动的新线程，是非活动状态的，（除非进程里其他应用程序组件有活动的），所以有被系统销毁的危险。这个问题的解决方法是在onReceive（）方法里启动一个服务然后处理一些事情，所以系统会知道在这个进程里仍然有处于活动状态的任务需要被处理。
Android操作系统尝试尽可能长时间的保持应用的进程，但当可用内存很低时最终要移走一部分进程。怎样确定那些程序可以运行，那些要被销毁，Android让每一个进程在一个重要级的基础上运行，重要级低的进程最有可能被淘汰，一共有五级，下面这个列表就是按照重要性排列的：
l 第一级
前台进程显示的是用户此时需要处理和显示的。下列的条件有任何一个成立，这个进程都被认为是在前台运行的。
与用户正发生交互的。
它控制一个与用户交互的必须的基本的服务。
有一个正在调用生命周期的回调函数的Service（如onCreate（）、onStar（）、onDestroy（））
它有一个正在运行onReceive（）方法的广播接收对象。
只有少数的前台进程可以在任何给定的时间内运行，销毁他们是系统万不得已的、最后的选择——当内存不够系统继续运行下去时。通常，在这一点上，设备已经达到了内存分页状态，所以杀掉一些前台进程来保证能够响应用户的需求。
l 第二级
一个可用的进程没有任何前台组件，但它仍然可以影响到用户的界面。下面两种情况发生时，可以称该进程为可用进程。
它是一个非前台的activity，但对用户仍然可用，（onPause（）方法已经被调用）。这是可能发生的，例如：前台的activity是一个允许上一个activity可见的对话框，即当前activity半透明，能看到前一个activity的界面。
它是一个服务于可用activity的服务。
l 第三级
一个服务进程是一个通过调用startService（）方法启动的服务，并且不属于前两种情况。尽管服务进程没有直接被用户看到，但他们确实是用户所关心的，比如后台播放音乐或网络下载数据。所以系统保证他们的运行，直到不能保证所有的前台可见程序都正常运行时才会终止他们。
l 第四级
一个后台进程就是一个非当前正在运行的activity（activity的onStop（）方法已经被调用），他们不会对用户体验造成直接的影响，当没有足够内存来运行前台可见程序时，他们将会被终止。通常，后台进程会有很多个在运行,所以他们维护一个LRU最近使用程序列表来保证经常运行的activity能最后一个被终止。如果一个activity正确的实现了生命周期的方法，并且保存它当前状态，杀死这些进程将不会影响到用户体验。
l 第五级
一个空线程没有运行任何可用应用程序组，保留他们的唯一原因是为了设立一个缓存机制，来加快组件启动的时间。系统经常杀死这些内存来平衡系统的整个系统的资源，进程缓存和基本核心缓存之间的资源。
Android把进程里优先级最高的activity或服务，作为这个进程的优先级。例如，一个进程拥有一个服务和一个可见的activity，那么这个进程将会被定义为可见进程，而不是服务进程。
此外，如果别的进程依赖某一个进程的话，那么被依赖的进程会提高优先级。一个进程服务于另一个进程，那么提供服务的进程不会低于获得服务的进程。例如，如果进程A的一个内容提供商服务于进程B的一个客户端，或者进程A的一个Service被进程B的一个组件绑定，那么进程A至少拥有和进程B一样的优先级，或者更高。
操作来启动一个服务，而不是启动一个线程--尤其是这个操作可能会拖垮这个activity。例如后台播放音乐的同时，通过照相机向服务器发送一张照片。启动一个服务会保证这个操作至少运行在service 进程的优先级下，无论这个activity发生了什么，广播接收者应该作为一个空服务而不是简单的把耗时的操作单独放在一个线程里。
15,Invalidate和postInvalidate的区别
android中实现view的更新有两组方法，一组是invalidate，另一组是postInvalidate，其中前者是在UI线程自身中使用，而后者在非UI线程中使用。
Android提供了Invalidate方法实现界面刷新，但是Invalidate不能直接在线程中调用，因为他是违背了单线程模型：Android UI操作并不是线程安全的，并且这些操作必须在UI线程中调用。
Android程序中可以使用的界面刷新方法有两种，分别是利用Handler和利用postInvalidate()来实现在线程中刷新界面。
16,setContentView的原理
首先初始化mDecor,即DecorView为FrameLayout的子类。就是我们整个窗口的根视图了。
然后，根据theme中的属性值，选择合适的布局，通过infalter.inflater放入到我们的mDecor中。
在这些布局中，一般会包含ActionBar，Title，和一个id为content的FrameLayout。
最后，我们在Activity中设置的布局，会通过infalter.inflater压入到我们的id为content的FrameLayout中去。
17，ViewGroup事件分发
MyLinearLayout的dispatchTouchEvent -> MyLinearLayout的onInterceptTouchEvent -> MyButton的dispatchTouchEvent ->Mybutton的onTouchEvent
在View上触发事件，最先捕获到事件的为View所在的ViewGroup，然后才会到View自身
26行：进行判断：if(disallowIntercept || !onInterceptTouchEvent(ev))
两种可能会进入IF代码段
1、当前不允许拦截，即disallowIntercept =true，
2、当前允许拦截但是不拦截，即disallowIntercept =false,但是onInterceptTouchEvent(ev)返回false ;
注：disallowIntercept 可以通过viewGroup.requestDisallowInterceptTouchEvent(boolean);进行设置，后面会详细说；而onInterceptTouchEvent(ev)可以进行复写。
41行：进行判断当前的x,y坐标是否落在子View身上，如果在，47行，执行child.dispatchTouchEvent(ev)，就进入了View的dispatchTouchEvent代码中了’
正常情况下，即我们上例整个代码的流程我们已经走完了：
1、ACTION_DOWN中，ViewGroup捕获到事件，然后判断是否拦截，如果没有拦截，则找到包含当前x,y坐标的子View，赋值给mMotionTarget，然后调用mMotionTarget.dispatchTouchEvent
2、ACTION_MOVE中，ViewGroup捕获到事件，然后判断是否拦截，如果没有拦截，则直接调用mMotionTarget.dispatchTouchEvent(ev)
3、ACTION_UP中，ViewGroup捕获到事件，然后判断是否拦截，如果没有拦截，则直接调用mMotionTarget.dispatchTouchEvent(ev)
当然了在分发之前都会修改下坐标系统，把当前的x，y分别减去child.left 和 child.top ，然后传给child;
1、如果ViewGroup找到了能够处理该事件的View，则直接交给子View处理，自己的onTouchEvent不会被触发；
2、可以通过复写onInterceptTouchEvent(ev)方法，拦截子View的事件（即return true），把事件交给自己处理，则会执行自己对应的onTouchEvent方法
3、子View可以通过调用getParent().requestDisallowInterceptTouchEvent(true); 阻止ViewGroup对其MOVE或者UP事件进行拦截；
18，View事件分发机制
不管是DOWN，MOVE，UP都会按照下面的顺序执行：
1、dispatchTouchEvent
2、 setOnTouchListener的onTouch
3、onTouchEvent
直接看13行：首先判断mOnTouchListener不为null，并且view是enable的状态，然后 mOnTouchListener.onTouch(this, event)返回true，这三个条件如果都满足，直接return true ; 也就是下面的onTouchEvent(event）不会被执行了；
1、整个View的事件转发流程是：
View.dispatchEvent->View.setOnTouchListener->View.onTouchEvent
在dispatchTouchEvent中会进行OnTouchListener的判断，如果OnTouchListener不为null且返回true，则表示事件被消费，onTouchEvent不会被执行；否则执行onTouchEvent。
2、onTouchEvent中的DOWN,MOVE,UP
DOWN时：
a、首先设置标志为PREPRESSED，设置mHasPerformedLongPress=false ;然后发出一个115ms后的mPendingCheckForTap；
b、如果115ms内没有触发UP，则将标志置为PRESSED，清除PREPRESSED标志，同时发出一个延时为500-115ms的，检测长按任务消息；
c、如果500ms内（从DOWN触发开始算），则会触发LongClickListener:
此时如果LongClickListener不为null，则会执行回调，同时如果LongClickListener.onClick返回true，才把mHasPerformedLongPress设置为true;否则mHasPerformedLongPress依然为false;
MOVE时：
主要就是检测用户是否划出控件，如果划出了：
115ms内，直接移除mPendingCheckForTap；
115ms后，则将标志中的PRESSED去除，同时移除长按的检查：removeLongPressCallback();
UP时：
a、如果115ms内，触发UP，此时标志为PREPRESSED，则执行UnsetPressedState，setPressed(false);会把setPress转发下去，可以在View中复写dispatchSetPressed方法接收；
b、如果是115ms-500ms间，即长按还未发生，则首先移除长按检测，执行onClick回调；
c、如果是500ms以后，那么有两种情况：
i.设置了onLongClickListener，且onLongClickListener.onClick返回true，则点击事件OnClick事件无法触发；
ii.没有设置onLongClickListener或者onLongClickListener.onClick返回false，则点击事件OnClick事件依然可以触发；
d、最后执行mUnsetPressedState.run()，将setPressed传递下去，然后将PRESSED标识去除；
19,AsyncTask原理
18行：设置当前AsyncTask的状态为RUNNING，上面的switch也可以看出，每个异步任务在完成前只能执行一次。
20行：执行了onPreExecute()，当前依然在UI线程，所以我们可以在其中做一些准备工作。
22行：将我们传入的参数赋值给了mWorker.mParams ,mWorker为一个Callable的子类，且在内部的call()方法中，调用了doInBackground(mParams)，然后得到的返回值作为postResult的参数进行执行；postResult中通过sHandler发送消息，最终sHandler的handleMessage中完成onPostExecute的调用。
23行：exec.execute(mFuture)，mFuture为真正的执行任务的单元，将mWorker进行封装，然后由sDefaultExecutor交给线程池进行执行。
20，LayoutInflate原理
Inflate(resId , null ) 只创建temp ,返回temp
Inflate(resId , parent, false )创建temp，然后执行temp.setLayoutParams(params);返回temp
Inflate(resId , parent, true ) 创建temp，然后执行root.addView(temp, params);最后返回root
由上面已经能够解释：
Inflate(resId , null )不能正确处理宽和高是因为：layout_width,layout_height是相对了父级设置的，必须与父级的LayoutParams一致。而此temp的getLayoutParams为null
Inflate(resId , parent,false ) 可以正确处理，因为temp.setLayoutParams(params);这个params正是root.generateLayoutParams(attrs);得到的。
Inflate(resId , parent,true )不仅能够正确的处理，而且已经把resId这个view加入到了parent，并且返回的是parent，和以上两者返回值有绝对的区别
21，说说View的刷新机制
在Android的布局体系中，父View负责刷新、布局显示子View；而当子View需要刷新时，则是通知父View来完成。
子View调用invalidate时，首先找到自己父View(View的成员变量mParent记录自己的父View)，然后将AttachInfo中保存的信息告诉父View刷新自己。
View的父子关系的建立分为两种情况：
1) View加入ViewGroup中
2)DecorView注册给WindowManagerImpl时，产生一个ViewRoot作为其父View
AttachInfo是在View第一次attach到Window时，ViewRoot传给自己的子View的。这个AttachInfo之后，会顺着布局体系一直传递到最底层的View。
并且在新的View被加入ViewGroup时，也会将该AttachInfo传给加入的View
在invalidate中，调用父View的invalidateChild，这是一个从底向上回溯的过程，每一层的父View都将自己的显示区域与传入的刷新Rect做交集
这个向上回溯的过程直到ViewRoot那里结束，由ViewRoot对这个最终的刷新区域做刷新scheduleTraversals();
22,ClassLoader委托机制
Bootstrap ClassLoader、Extension ClassLoader、App ClassLoader三者的关系如下：
Bootstrap ClassLoader是Extension ClassLoader的parent，Extension ClassLoader是App ClassLoader的parent。
但是这并不是继承关系，只是语义上的定义，基本上，每一个ClassLoader实现，都有一个Parent ClassLoader。
可以通过ClassLoader的getParent方法得到当前ClassLoader的parent。Bootstrap ClassLoader比较特殊，因为它不是java class所以Extension ClassLoader的getParent方法返回的是NULL。
由于classloader 加载类用的是全盘负责委托机制。所谓全盘负责，即是当一个classloader加载一个Class的时候，这个Class所依赖的和引用的所有 Class也由这个classloader负责载入，除非是显式的使用另外一个classloader载入。
23，Suface与SurfaceView
简单地说Surface对应了一块屏幕缓冲区，每个window对应一个Surface，任何View都是画在Surface上的，传统的view共享一块屏幕缓冲区，所有的绘制必须在UI线程中进行
什么是SurfaceView？
说SurfaceView是一个View也许不够严谨，然而从定义中 public class SurfaceView extends View {...}显示SurfaceView确实是派生自View，但是SurfaceView却有着自己的Surface
每个SurfaceView创建的时候都会创建一个MyWindow，new MyWindow(this)中的this正是SurfaceView自身，因此将SurfaceView和window绑定在一起，而前面提到过每个window对应一个Surface，所以SurfaceView也就内嵌了一个自己的Surface，可以认为SurfaceView是来控制Surface的位置和尺寸。大家都知道，传统View及其派生类的更新只能在UI线程，然而UI线程还同时处理其他交互逻辑，这就无法保证view更新的速度和帧率了，而SurfaceView可以用独立的线程来进行绘制，因此可以提供更高的帧率，例如游戏，摄像头取景等场景就比较适合用SurfaceView来实现。
什么是SurfaceHolder.Callback？
SurfaceHolder.Callback主要是当底层的Surface被创建、销毁或者改变时提供回调通知，由于绘制必须在surface被创建后才能进行，因此SurfaceHolder.Callback中的surfaceCreated 和surfaceDestroyed 就成了绘图处理代码的边界。SurfaceHolder,可以把它当成Surface的容器和控制器，用来操纵Surface。处理它的Canvas上画的效果和动画，控制表面，大小，像素等。
24，Invalidate()原理
invalidate()函数的主要作用是请求View树进行重绘，该函数可以由应用程序调用，或者由系统函数间接调用，例如setEnable(), setSelected(), setVisiblity()都会间接调用到invalidate()来请求View树重绘，更新View树的显示。
注：requestLayout()和requestFocus()函数也会引起视图重绘
下面我们来具体进行分析invalidate(true)函数的执行流程：
1、首先调用skipInvalidate()，该函数主要判断该View是否不需要重绘，如果不许要重绘则直接返回，不需要重绘的条件是该View不可见并且未进行动画
2、接下来的if语句是来进一步判断View是否需要绘制，其中表达式 (mPrivateFlags & (DRAWN | HAS_BOUNDS)) == (DRAWN | HAS_BOUNDS)的意思指的是如果View需要重绘并且其大小不为0，其余几个本人也未完全理解，还望高手指点～～如果需要重绘，则处理相关标志位
3、对于开启硬件加速的应用程序，则调用父视图的invalidateChild函数绘制整个区域，否则只绘制dirty区域（r变量所指的区域），这是一个向上回溯的过程，每一层的父View都将自己的显示区域与传入的刷新Rect做交集。
接下来看invalidateChild()的 实现过程：
大概流程如下，我们主要关注dirty区域不是null（非硬件加速）的情况：
1、判断子视图是否是不透明的（不透明的条件是isOpaque()返回true，视图未进行动画以及child.getAnimation() == null），并将判断结果保存到变量isOpaque中，如果不透明则将变量opaqueFlag设置为DIRTY_OPAQUE，否则设置为DIRTY。
2、定义location保存子视图的左上角坐标
3、如果子视图正在动画，那么父视图也要添加动画标志，如果父视图是ViewGroup，那么给mPrivateFlags添加DRAW_ANIMATION标识，如果父视图是ViewRoot，则给其内部变量mIsAnimating赋值为true
4、设置dirty标识，如果子视图是不透明的，则父视图设置为DIRTY_OPAQUE，否则设置为DIRTY
5、调用parent.invalidateChildInparent()，这里的parent有可能是ViewGroup，也有可能是ViewRoot（最后一次while循环），首先来看ViewGroup, ViewGroup中该函数的主要作用是对dirty区域进行计算
以上过程的主体是一个do{}while{}循环，不断的将子视图的dirty区域与父视图做运算来确定最终要重绘的dirty区域，最终循环到ViewRoot（ViewRoot的parent为null）为止，并将dirty区域保存到ViewRoot的mDirty变量中
具体分析如下： 1、判断此次调用是否在UI线程中进行
2、将dirty的坐标位置转换为ViewRoot的屏幕显示区域
3、更新mDirty变量，并调用scheduleTraversals发起重绘请求
至此一次invalidate()就结束了
总结：invalidate主要给需要重绘的视图添加DIRTY标记，并通过和父视图的矩形运算求得真正需要绘制的区域，并保存在ViewRoot中的mDirty变量中，最后调用scheduleTraversals发起重绘请求，scheduleTraversals会发送一个异步消息，最终调用performTraversals()执行重绘，performTraversals()的具体过程以后再分析。
25，Android 2D动画框架实现原理
RootView 只有一个孩子就是 DecorView，这里整个 View Tree 都是 DecorView 的子 View，它们是从 android1.5/frameworks/base/core/res/res/layout/screen_title.xml 这个 layout 文件 infalte 出来的，感兴趣的读者可以参看 frameworks\policies\base\phone\com\android\internal\policy\Imp\PhoneWindow.java 中 generateLayout
函数部分的代码。我们可以修改布局文件和代码来做一些比较 cool 的事情，如象 Windows 的缩小 / 关闭按钮等。标题窗口以下部分的 FrameLayou 就是为了让程序员通过 setContentView 来设置用户需要的窗口内容。因为整个 View 的布局就是一棵树，所以绘制的时候也是按照树形结构遍历来让每个 View 进行绘制。ViewRoot.java 中的 draw 函数准备好 Canvas 后会调用 mView.draw(canvas)，其中 mView 就是调用 ViewRoot.setView
时设置的 DecorView。然后看一下 View.java 中的 draw 函数：
递归的绘制整个窗口需要按顺序执行以下几个步骤：
- 绘制背景；
- 如果需要，保存画布（canvas）的层为淡入或淡出做准备；
- 绘制 View 本身的内容，通过调用 View.onDraw(canvas) 函数实现，通过这个我们应该能看出来 onDraw 函数重载的重要性，onDraw 函数中绘制线条 / 圆 / 文字等功能会调用 Canvas 中对应的功能。下面我们会 drawLine 函数为例进行说明；
- 绘制自己的孩子（通常也是一个 view 系统），通过 dispatchDraw(canvas) 实现，参看 ViewGroup.Java 中的代码可知，dispatchDraw->drawChild->child.draw(canvas) 这样的调用过程被用来保证每个子 View 的 draw 函数都被调用，通过这种递归调用从而让整个 View 树中的所有 View 的内容都得到绘制。在调用每个子 View 的 draw 函数之前，需要绘制的 View 的绘制位置是在 Canvas 通过 translate
函数调用来进行切换的，窗口中的所有 View 是共用一个 Canvas 对象 - 如果需要，绘制淡入淡出相关的内容并恢复保存的画布所在的层（layer）
- 绘制修饰的内容（例如滚动条），这个可知要实现滚动条效果并不需要 ScrollView，可以在 View 中完成的，不过有一些小技巧，具体实现可以参看我们的 TextViewExample 示例代码
当一个 ChildView 要重画时，它会调用其成员函数 invalidate() 函数将通知其 ParentView 这个 ChildView 要重画，这个过程一直向上遍历到 ViewRoot，当 ViewRoot 收到这个通知后就会调用上面提到的 ViewRoot 中的 draw 函数从而完成绘制。View::onDraw() 有一个画布参数 Canvas, 画布顾名思义就是画东西的地方，Android 会为每一个 View 设置好画布，View 就可以调用 Canvas 的方法，比如：drawText,
drawBitmap, drawPath 等等去画内容。每一个 ChildView 的画布是由其 ParentView 设置的，ParentView 根据 ChildView 在其内部的布局来调整 Canvas，其中画布的属性之一就是定义和 ChildView 相关的坐标系，默认是横轴为 X 轴，从左至右，值逐渐增大，竖轴为 Y 轴，从上至下，值逐渐增大 , 见下图 :
Android 动画就是通过 ParentView 来不断调整 ChildView 的画布坐标系来实现的，下面以平移动画来做示例，见下图 4，假设在动画开始时 ChildView 在 ParentView 中的初始位置在 (100,200) 处，这时 ParentView 会根据这个坐标来设置 ChildView 的画布，在 ParentView 的 dispatchDraw 中它发现 ChildView 有一个平移动画，而且当前的平移位置是 (100, 200)，于是它通过调用画布的函数 traslate(100,
200) 来告诉 ChildView 在这个位置开始画，这就是动画的第一帧。如果 ParentView 发现 ChildView 有动画，就会不断的调用 invalidate() 这个函数，这样就会导致自己会不断的重画，就会不断的调用 dispatchDraw 这个函数，这样就产生了动画的后续帧，当再次进入 dispatchDraw 时，ParentView 根据平移动画产生出第二帧的平移位置 (500, 200)，然后继续执行上述操作，然后产生第三帧，第四帧，直到动画播完。
以上是以平移动画为例子来说明动画的产生过程，这其中又涉及到两个重要的类型，Animation 和 Transformation，这两个类是实现动画的主要的类，Animation 中主要定义了动画的一些属性比如开始时间、持续时间、是否重复播放等，这个类主要有两个重要的函数：getTransformation 和 applyTransformation，在 getTransformation 中 Animation 会根据动画的属性来产生一系列的差值点，然后将这些差值点传给 applyTransformation，这个函数将根据这些点来生成不同的
Transformation，Transformation 中包含一个矩阵和 alpha 值，矩阵是用来做平移、旋转和缩放动画的，而 alpha 值是用来做 alpha 动画的（简单理解的话，alpha 动画相当于不断变换透明度或颜色来实现动画），以上面的平移矩阵为例子，当调用 dispatchDraw 时会调用 getTransformation 来得到当前的 Transformation，这个 Transformation 中的矩阵如下
所以具体的动画只需要重载 applyTransformation 这个函数即可，类层次图如下：
用户可以定义自己的动画类，只需要继承 Animation 类，然后重载 applyTransformation 这个函数。对动画来说其行为主要靠差值点来决定的，比如，我们想开始动画是逐渐加快的或者逐渐变慢的，或者先快后慢的，或者是匀速的，这些功能的实现主要是靠差值函数来实现的，Android 提供了 一个 Interpolator 的基类，你要实现什么样的速度可以重载其函数 getInterpolation，在 Animation 的 getTransformation 中生成差值点时，会用到这个函数。
从上面的动画机制的分析可知某一个 View 的动画的绘制并不是由他自己完成的而是由它的父 view 完成，所有我们要注意上面 TextView 旋转一周的动画示例程序中动画的效果并不是由 TextView 来绘制的，而是由它的父 View 来做的。findViewById(R.id.TextView01).startAnimation(anim) 这个代码其实是给这个 TextView 设置了一个 animation，而不是进行实际的动画绘制，代码如下 :
public void startAnimation(Animation animation) { animation.setStartTime(Animation.START_ON_FIRST_FRAME); setAnimation(animation); invalidate(); }
26，对多态的理解
多态的定义：指允许不同类的对象对同一消息做出响应。即同一消息可以根据发送对象的不同而采用多种不同的行为方式。（发送消息就是函数调用）
多态存在的三个必要条件
一、要有继承；
二、要有重写；
三、父类引用指向子类对象。
27，接口与抽象类的区别
- Java接口和Java抽象类最大的一个区别，就在于Java抽象类可以提供某些方法的部分实现，而Java接口不可以（就是interface中只能定义方法，而不能有方法的实现，而在abstract class中则可以既有方法的具体实现，又有没有具体实现的抽象方法），这大概就是Java抽象类唯一的优点吧，但这个优点非常有用。如果向一个抽象类里加入一个新的具体方法时，那么它所有的子类都一下子都得到了这个新方法，而Java接口做不到这一点，如果向一个Java接口里加入一个
新方法，所有实现这个接口的类就无法成功通过编译了，因为你必须让每一个类都再实现这个方法才行，这显然是Java接口的缺点。这个在我的另外一篇博客mapreduce 新旧API 区别中有提到类似的问题，在新的mapreduce api中更倾向于使用抽象类，而不是接口，因为这更容易扩展。原因就是上面划线部分所说的。 - 一个抽象类的实现只能由这个抽象类的子类给出，也就是说，这个实现处在抽象类所定义出的继承的等级结构中，而由于Java语言的单继承性，所以抽象类作为类型定义工具的效能大打折扣。在这一点上，Java接口的优势就出来了，任何一个实现了一个Java接口所规定的方法的类都可以具有这个接口的类型，而一个类可以实现任意多个Java接口，从而这个类就有了多种类型。（使用抽象类，那么继承这个抽象类的子类类型就比较单一，因为子类只能单继承抽象类；而子类能够同时实现多个接口，因为类型就比较多。接口和抽象类都可以定义对象，但是只能用他们的具体实现类来进行实例化。）
- 从第2点不难看出，Java接口是定义混合类型的理想工具，混合类表明一个类不仅仅具有某个主类型的行为，而且具有其他的次要行为。
- 结合1、2点中抽象类和Java接口的各自优势，具精典的设计模式就出来了：声明类型的工作仍然由Java接口承担，但是同时给出一个Java 抽象类，且实现了这个接口，而其他同属于这个抽象类型的具体类可以选择实现这个Java接口，也可以选择继承这个抽象类，也就是说在层次结构中，Java 接口在最上面，然后紧跟着抽象类，这下两个的最大优点都能发挥到极至了。这个模式就是“缺省适配模式”。在Java语言API中用了这种模式，而且全都遵循一定的命名规范：Abstract
＋接口名。（A extends AbstractB implements interfaceC，那么A即可以选择实现(@Override)接口interfaceC中的方法，也可以选择不实现；A即可以选择实现(@Override)抽象类AbstractB中的方法，也可以选择不实现）