对android应用程序了解_android应用程序设计 android studio - CSDN
  • 对android应用程序的理解

    千次阅读 2016-04-07 08:53:10
    在判断一个应用程序是系统程序还是用户程序时,经常用到下面一端代码: int flags = packInfo.applicationInfo.flags;//应用程序信息的标记 if((flags&ApplicationInfo.FLAG_SYSTEM)==0){ //用户程序 appInfo....

    在判断一个应用程序是系统程序还是用户程序时,经常用到下面一端代码:

    int flags = packInfo.applicationInfo.flags;//应用程序信息的标记
                if((flags&ApplicationInfo.FLAG_SYSTEM)==0){
                    //用户程序
                    appInfo.setUserApp(true);
                }else{
                    //系统程序
                    appInfo.setUserApp(false);
                }

    为何获得应用程序的标记后,后面要用flags&ApplicationInfo.FLAG_SYSTEM的方式来判断是否为系统程序呢?
    点进packInfo.applicationInfo.flags的源码:

    ......
    public static final int FLAG_SYSTEM = 1<<0;
    
        /**
         * Value for {@link #flags}: set to true if this application would like to
         * allow debugging of its
         * code, even when installed on a non-development system.  Comes
         * from {@link android.R.styleable#AndroidManifestApplication_debuggable
         * android:debuggable} of the &lt;application&gt; tag.
         */
        public static final int FLAG_DEBUGGABLE = 1<<1;
    
        /**
         * Value for {@link #flags}: set to true if this application has code
         * associated with it.  Comes
         * from {@link android.R.styleable#AndroidManifestApplication_hasCode
         * android:hasCode} of the &lt;application&gt; tag.
         */
        public static final int FLAG_HAS_CODE = 1<<2;
    
        /**
         * Value for {@link #flags}: set to true if this application is persistent.
         * Comes from {@link android.R.styleable#AndroidManifestApplication_persistent
         * android:persistent} of the &lt;application&gt; tag.
         */
        public static final int FLAG_PERSISTENT = 1<<3;
    
        /**
         * Value for {@link #flags}: set to true if this application holds the
         * {@link android.Manifest.permission#FACTORY_TEST} permission and the
         * device is running in factory test mode.
         */
        public static final int FLAG_FACTORY_TEST = 1<<4;
        ......

    可以看到每个标记都是1<<序号的形式,即表示1向左位移动n位,即:

    1<<0=1;左移0位
    1<<1=2;左移1位
    1<<2=4;左移2位
    1<<3=8;左移3位
    ……

    为什么google要用这种方式设计呢?我们来看,上面几个标记位移后8位二进制数为:

    标记
    FLAG_SYSTEM 0000 0001
    FLAG_DEBUGGABLE 0000 0010
    FLAG_HAS_CODE 0000 0100
    FLAG_PERSISTENT 0000 1000

    而获得int flags = packInfo.applicationInfo.flags;//应用程序信息的标记后,拿flag与之相与,我们知道与操作,对应二进制位上全为1才为1。
    假设flag=0011,与上面系统标记相与,结果中:FLAG_DEBUGGABLE和FLAG_SYSTEM不为0,表示这个程序既有FLAG_DEBUGGABLE和FLAG_SYSTEM两个属性。

    所以,这种设计的方便之处在于,方便比较和一个flag能表示很多个状态。

    展开全文
  • Android应用程序启动过程源代码分析

    万次阅读 多人点赞 2017-01-06 14:32:12
    在Android系统中,应用程序是由Activity组成的,因此,应用程序的启动过程实际上就是应用程序中的默认Activity的启动过程,本文将详细分析应用程序框架层的源代码,了解Android应用程序的启动过程。 在上一篇文章...

            前文简要介绍了Android应用程序的Activity的启动过程。在Android系统中,应用程序是由Activity组成的,因此,应用程序的启动过程实际上就是应用程序中的默认Activity的启动过程,本文将详细分析应用程序框架层的源代码,了解Android应用程序的启动过程。

    《Android系统源代码情景分析》一书正在进击的程序员网(http://0xcc0xcd.com)中连载,点击进入!

            在上一篇文章Android应用程序的Activity启动过程简要介绍和学习计划中,我们举例子说明了启动Android应用程序中的Activity的两种情景,其中,在手机屏幕中点击应用程序图标的情景就会引发Android应用程序中的默认Activity的启动,从而把应用程序启动起来。这种启动方式的特点是会启动一个新的进程来加载相应的Activity。这里,我们继续以这个例子为例来说明Android应用程序的启动过程,即MainActivity的启动过程。

            MainActivity的启动过程如下图所示:


    点击查看大图

            下面详细分析每一步是如何实现的。

            Step 1. Launcher.startActivitySafely

            在Android系统中,应用程序是由Launcher启动起来的,其实,Launcher本身也是一个应用程序,其它的应用程序安装后,就会Launcher的界面上出现一个相应的图标,点击这个图标时,Launcher就会对应的应用程序启动起来。

            Launcher的源代码工程在packages/apps/Launcher2目录下,负责启动其它应用程序的源代码实现在src/com/android/launcher2/Launcher.java文件中:

    /**
    * Default launcher application.
    */
    public final class Launcher extends Activity
    		implements View.OnClickListener, OnLongClickListener, LauncherModel.Callbacks, AllAppsView.Watcher {
    
    	......
    
    	/**
    	* Launches the intent referred by the clicked shortcut.
    	*
    	* @param v The view representing the clicked shortcut.
    	*/
    	public void onClick(View v) {
    		Object tag = v.getTag();
    		if (tag instanceof ShortcutInfo) {
    			// Open shortcut
    			final Intent intent = ((ShortcutInfo) tag).intent;
    			int[] pos = new int[2];
    			v.getLocationOnScreen(pos);
    			intent.setSourceBounds(new Rect(pos[0], pos[1],
    				pos[0] + v.getWidth(), pos[1] + v.getHeight()));
    			startActivitySafely(intent, tag);
    		} else if (tag instanceof FolderInfo) {
    			......
    		} else if (v == mHandleView) {
    			......
    		}
    	}
    
    	void startActivitySafely(Intent intent, Object tag) {
    		intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    		try {
    			startActivity(intent);
    		} catch (ActivityNotFoundException e) {
    			......
    		} catch (SecurityException e) {
    			......
    		}
    	}
    
    	......
    
    }
            回忆一下前面一篇文章Android应用程序的Activity启动过程简要介绍和学习计划说到的应用程序Activity,它的默认Activity是MainActivity,这里是AndroidManifest.xml文件中配置的:

    <activity android:name=".MainActivity"  
          android:label="@string/app_name">  
           <intent-filter>  
            <action android:name="android.intent.action.MAIN" />  
            <category android:name="android.intent.category.LAUNCHER" />  
        </intent-filter>  
    </activity>  
            因此,这里的intent包含的信息为:action = "android.intent.action.Main",category="android.intent.category.LAUNCHER", cmp="shy.luo.activity/.MainActivity",表示它要启动的Activity为shy.luo.activity.MainActivity。Intent.FLAG_ACTIVITY_NEW_TASK表示要在一个新的Task中启动这个Activity,注意,Task是Android系统中的概念,它不同于进程Process的概念。简单地说,一个Task是一系列Activity的集合,这个集合是以堆栈的形式来组织的,遵循后进先出的原则。事实上,Task是一个非常复杂的概念,有兴趣的读者可以到官网http://developer.android.com/guide/topics/manifest/activity-element.html查看相关的资料。这里,我们只要知道,这个MainActivity要在一个新的Task中启动就可以了。

            Step 2. Activity.startActivity

            在Step 1中,我们看到,Launcher继承于Activity类,而Activity类实现了startActivity函数,因此,这里就调用了Activity.startActivity函数,它实现在frameworks/base/core/java/android/app/Activity.java文件中:

    public class Activity extends ContextThemeWrapper
    		implements LayoutInflater.Factory,
    		Window.Callback, KeyEvent.Callback,
    		OnCreateContextMenuListener, ComponentCallbacks {
    
    	......
    
    	@Override
    	public void startActivity(Intent intent) {
    		startActivityForResult(intent, -1);
    	}
    
    	......
    
    }
            这个函数实现很简单,它调用startActivityForResult来进一步处理,第二个参数传入-1表示不需要这个Actvity结束后的返回结果。

            Step 3. Activity.startActivityForResult

            这个函数也是实现在frameworks/base/core/java/android/app/Activity.java文件中:

    public class Activity extends ContextThemeWrapper
    		implements LayoutInflater.Factory,
    		Window.Callback, KeyEvent.Callback,
    		OnCreateContextMenuListener, ComponentCallbacks {
    
    	......
    
    	public void startActivityForResult(Intent intent, int requestCode) {
    		if (mParent == null) {
    			Instrumentation.ActivityResult ar =
    				mInstrumentation.execStartActivity(
    				this, mMainThread.getApplicationThread(), mToken, this,
    				intent, requestCode);
    			......
    		} else {
    			......
    		}
    
    
    	......
    
    }
             这里的mInstrumentation是Activity类的成员变量,它的类型是Intrumentation,定义在frameworks/base/core/java/android/app/Instrumentation.java文件中,它用来监控应用程序和系统的交互。

             这里的mMainThread也是Activity类的成员变量,它的类型是ActivityThread,它代表的是应用程序的主线程,我们在Android系统在新进程中启动自定义服务过程(startService)的原理分析一文中已经介绍过了。这里通过mMainThread.getApplicationThread获得它里面的ApplicationThread成员变量,它是一个Binder对象,后面我们会看到,ActivityManagerService会使用它来和ActivityThread来进行进程间通信。这里我们需注意的是,这里的mMainThread代表的是Launcher应用程序运行的进程。

             这里的mToken也是Activity类的成员变量,它是一个Binder对象的远程接口。

             Step 4. Instrumentation.execStartActivity
             这个函数定义在frameworks/base/core/java/android/app/Instrumentation.java文件中:

    public class Instrumentation {
    
    	......
    
    	public ActivityResult execStartActivity(
    	Context who, IBinder contextThread, IBinder token, Activity target,
    	Intent intent, int requestCode) {
    		IApplicationThread whoThread = (IApplicationThread) contextThread;
    		if (mActivityMonitors != null) {
    			......
    		}
    		try {
    			int result = ActivityManagerNative.getDefault()
    				.startActivity(whoThread, intent,
    				intent.resolveTypeIfNeeded(who.getContentResolver()),
    				null, 0, token, target != null ? target.mEmbeddedID : null,
    				requestCode, false, false);
    			......
    		} catch (RemoteException e) {
    		}
    		return null;
    	}
    
    	......
    
    }
             这里的ActivityManagerNative.getDefault返回ActivityManagerService的远程接口,即ActivityManagerProxy接口,具体可以参考Android系统在新进程中启动自定义服务过程(startService)的原理分析一文。

             这里的intent.resolveTypeIfNeeded返回这个intent的MIME类型,在这个例子中,没有AndroidManifest.xml设置MainActivity的MIME类型,因此,这里返回null。

             这里的target不为null,但是target.mEmbddedID为null,我们不用关注。

             Step 5. ActivityManagerProxy.startActivity

             这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中:

    class ActivityManagerProxy implements IActivityManager
    {
    
    	......
    
    	public int startActivity(IApplicationThread caller, Intent intent,
    			String resolvedType, Uri[] grantedUriPermissions, int grantedMode,
    			IBinder resultTo, String resultWho,
    			int requestCode, boolean onlyIfNeeded,
    			boolean debug) throws RemoteException {
    		Parcel data = Parcel.obtain();
    		Parcel reply = Parcel.obtain();
    		data.writeInterfaceToken(IActivityManager.descriptor);
    		data.writeStrongBinder(caller != null ? caller.asBinder() : null);
    		intent.writeToParcel(data, 0);
    		data.writeString(resolvedType);
    		data.writeTypedArray(grantedUriPermissions, 0);
    		data.writeInt(grantedMode);
    		data.writeStrongBinder(resultTo);
    		data.writeString(resultWho);
    		data.writeInt(requestCode);
    		data.writeInt(onlyIfNeeded ? 1 : 0);
    		data.writeInt(debug ? 1 : 0);
    		mRemote.transact(START_ACTIVITY_TRANSACTION, data, reply, 0);
    		reply.readException();
    		int result = reply.readInt();
    		reply.recycle();
    		data.recycle();
    		return result;
    	}
    
    	......
    
    }
            这里的参数比较多,我们先整理一下。从上面的调用可以知道,这里的参数resolvedType、grantedUriPermissions和resultWho均为null;参数caller为ApplicationThread类型的Binder实体;参数resultTo为一个Binder实体的远程接口,我们先不关注它;参数grantedMode为0,我们也先不关注它;参数requestCode为-1;参数onlyIfNeeded和debug均空false。

            Step 6. ActivityManagerService.startActivity

            上一步Step 5通过Binder驱动程序就进入到ActivityManagerService的startActivity函数来了,它定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:

    public final class ActivityManagerService extends ActivityManagerNative
    		implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
    
    	......
    
    	public final int startActivity(IApplicationThread caller,
    			Intent intent, String resolvedType, Uri[] grantedUriPermissions,
    			int grantedMode, IBinder resultTo,
    			String resultWho, int requestCode, boolean onlyIfNeeded,
    			boolean debug) {
    		return mMainStack.startActivityMayWait(caller, intent, resolvedType,
    			grantedUriPermissions, grantedMode, resultTo, resultWho,
    			requestCode, onlyIfNeeded, debug, null, null);
    	}
    
    
    	......
    
    }
            这里只是简单地将操作转发给成员变量mMainStack的startActivityMayWait函数,这里的mMainStack的类型为ActivityStack。

            Step 7. ActivityStack.startActivityMayWait

            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	final int startActivityMayWait(IApplicationThread caller,
    			Intent intent, String resolvedType, Uri[] grantedUriPermissions,
    			int grantedMode, IBinder resultTo,
    			String resultWho, int requestCode, boolean onlyIfNeeded,
    			boolean debug, WaitResult outResult, Configuration config) {
    
    		......
    
    		boolean componentSpecified = intent.getComponent() != null;
    
    		// Don't modify the client's object!
    		intent = new Intent(intent);
    
    		// Collect information about the target of the Intent.
    		ActivityInfo aInfo;
    		try {
    			ResolveInfo rInfo =
    				AppGlobals.getPackageManager().resolveIntent(
    				intent, resolvedType,
    				PackageManager.MATCH_DEFAULT_ONLY
    				| ActivityManagerService.STOCK_PM_FLAGS);
    			aInfo = rInfo != null ? rInfo.activityInfo : null;
    		} catch (RemoteException e) {
    			......
    		}
    
    		if (aInfo != null) {
    			// Store the found target back into the intent, because now that
    			// we have it we never want to do this again.  For example, if the
    			// user navigates back to this point in the history, we should
    			// always restart the exact same activity.
    			intent.setComponent(new ComponentName(
    				aInfo.applicationInfo.packageName, aInfo.name));
    			......
    		}
    
    		synchronized (mService) {
    			int callingPid;
    			int callingUid;
    			if (caller == null) {
    				......
    			} else {
    				callingPid = callingUid = -1;
    			}
    
    			mConfigWillChange = config != null
    				&& mService.mConfiguration.diff(config) != 0;
    
    			......
    
    			if (mMainStack && aInfo != null &&
    				(aInfo.applicationInfo.flags&ApplicationInfo.FLAG_CANT_SAVE_STATE) != 0) {
    				  
    		              ......
    
    			}
    
    			int res = startActivityLocked(caller, intent, resolvedType,
    				grantedUriPermissions, grantedMode, aInfo,
    				resultTo, resultWho, requestCode, callingPid, callingUid,
    				onlyIfNeeded, componentSpecified);
    
    			if (mConfigWillChange && mMainStack) {
    				......
    			}
    
    			......
    
    			if (outResult != null) {
    				......
    			}
    
    			return res;
    		}
    
    	}
    
    	......
    
    }
            注意,从Step 6传下来的参数outResult和config均为null,此外,表达式(aInfo.applicationInfo.flags&ApplicationInfo.FLAG_CANT_SAVE_STATE) != 0为false,因此,这里忽略了无关代码。

            下面语句对参数intent的内容进行解析,得到MainActivity的相关信息,保存在aInfo变量中:

        ActivityInfo aInfo;
        try {
    	ResolveInfo rInfo =
    	AppGlobals.getPackageManager().resolveIntent(
    		intent, resolvedType,
    		PackageManager.MATCH_DEFAULT_ONLY
    		| ActivityManagerService.STOCK_PM_FLAGS);
    	aInfo = rInfo != null ? rInfo.activityInfo : null;
        } catch (RemoteException e) {
    		......
        }
            解析之后,得到的aInfo.applicationInfo.packageName的值为"shy.luo.activity",aInfo.name的值为"shy.luo.activity.MainActivity",这是在这个实例的配置文件AndroidManifest.xml里面配置的。

            此外,函数开始的地方调用intent.getComponent()函数的返回值不为null,因此,这里的componentSpecified变量为true。

            接下去就调用startActivityLocked进一步处理了。

            Step 8. ActivityStack.startActivityLocked

            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	final int startActivityLocked(IApplicationThread caller,
    		    Intent intent, String resolvedType,
    		    Uri[] grantedUriPermissions,
    		    int grantedMode, ActivityInfo aInfo, IBinder resultTo,
    	            String resultWho, int requestCode,
    		    int callingPid, int callingUid, boolean onlyIfNeeded,
    		    boolean componentSpecified) {
    	        int err = START_SUCCESS;
    
    		ProcessRecord callerApp = null;
    		if (caller != null) {
    			callerApp = mService.getRecordForAppLocked(caller);
    			if (callerApp != null) {
    				callingPid = callerApp.pid;
    				callingUid = callerApp.info.uid;
    			} else {
    				......
    			}
    		}
    
    		......
    
    		ActivityRecord sourceRecord = null;
    		ActivityRecord resultRecord = null;
    		if (resultTo != null) {
    			int index = indexOfTokenLocked(resultTo);
    			
    			......
    				
    			if (index >= 0) {
    				sourceRecord = (ActivityRecord)mHistory.get(index);
    				if (requestCode >= 0 && !sourceRecord.finishing) {
    					......
    				}
    			}
    		}
    
    		int launchFlags = intent.getFlags();
    
    		if ((launchFlags&Intent.FLAG_ACTIVITY_FORWARD_RESULT) != 0
    			&& sourceRecord != null) {
    			......
    		}
    
    		if (err == START_SUCCESS && intent.getComponent() == null) {
    			......
    		}
    
    		if (err == START_SUCCESS && aInfo == null) {
    			......
    		}
    
    		if (err != START_SUCCESS) {
    			......
    		}
    
    		......
    
    		ActivityRecord r = new ActivityRecord(mService, this, callerApp, callingUid,
    			intent, resolvedType, aInfo, mService.mConfiguration,
    			resultRecord, resultWho, requestCode, componentSpecified);
    
    		......
    
    		return startActivityUncheckedLocked(r, sourceRecord,
    			grantedUriPermissions, grantedMode, onlyIfNeeded, true);
    	}
    
    
    	......
    
    }
            从传进来的参数caller得到调用者的进程信息,并保存在callerApp变量中,这里就是Launcher应用程序的进程信息了。

            前面说过,参数resultTo是Launcher这个Activity里面的一个Binder对象,通过它可以获得Launcher这个Activity的相关信息,保存在sourceRecord变量中。
            再接下来,创建即将要启动的Activity的相关信息,并保存在r变量中:

    ActivityRecord r = new ActivityRecord(mService, this, callerApp, callingUid,
    	intent, resolvedType, aInfo, mService.mConfiguration,
    	resultRecord, resultWho, requestCode, componentSpecified);
            接着调用startActivityUncheckedLocked函数进行下一步操作。

            Step 9. ActivityStack.startActivityUncheckedLocked

            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	final int startActivityUncheckedLocked(ActivityRecord r,
    		ActivityRecord sourceRecord, Uri[] grantedUriPermissions,
    		int grantedMode, boolean onlyIfNeeded, boolean doResume) {
    		final Intent intent = r.intent;
    		final int callingUid = r.launchedFromUid;
    
    		int launchFlags = intent.getFlags();
    
    		// We'll invoke onUserLeaving before onPause only if the launching
    		// activity did not explicitly state that this is an automated launch.
    		mUserLeaving = (launchFlags&Intent.FLAG_ACTIVITY_NO_USER_ACTION) == 0;
    		
    		......
    
    		ActivityRecord notTop = (launchFlags&Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP)
    			!= 0 ? r : null;
    
    		// If the onlyIfNeeded flag is set, then we can do this if the activity
    		// being launched is the same as the one making the call...  or, as
    		// a special case, if we do not know the caller then we count the
    		// current top activity as the caller.
    		if (onlyIfNeeded) {
    			......
    		}
    
    		if (sourceRecord == null) {
    			......
    		} else if (sourceRecord.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
    			......
    		} else if (r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE
    			|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK) {
    			......
    		}
    
    		if (r.resultTo != null && (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
    			......
    		}
    
    		boolean addingToTask = false;
    		if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
    			(launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
    			|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
    			|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
    				// If bring to front is requested, and no result is requested, and
    				// we can find a task that was started with this same
    				// component, then instead of launching bring that one to the front.
    				if (r.resultTo == null) {
    					// See if there is a task to bring to the front.  If this is
    					// a SINGLE_INSTANCE activity, there can be one and only one
    					// instance of it in the history, and it is always in its own
    					// unique task, so we do a special search.
    					ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE
    						? findTaskLocked(intent, r.info)
    						: findActivityLocked(intent, r.info);
    					if (taskTop != null) {
    						......
    					}
    				}
    		}
    
    		......
    
    		if (r.packageName != null) {
    			// If the activity being launched is the same as the one currently
    			// at the top, then we need to check if it should only be launched
    			// once.
    			ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
    			if (top != null && r.resultTo == null) {
    				if (top.realActivity.equals(r.realActivity)) {
    					......
    				}
    			}
    
    		} else {
    			......
    		}
    
    		boolean newTask = false;
    
    		// Should this be considered a new task?
    		if (r.resultTo == null && !addingToTask
    			&& (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
    				// todo: should do better management of integers.
    				mService.mCurTask++;
    				if (mService.mCurTask <= 0) {
    					mService.mCurTask = 1;
    				}
    				r.task = new TaskRecord(mService.mCurTask, r.info, intent,
    					(r.info.flags&ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH) != 0);
    				......
    				newTask = true;
    				if (mMainStack) {
    					mService.addRecentTaskLocked(r.task);
    				}
    
    		} else if (sourceRecord != null) {
    			......
    		} else {
    			......
    		}
    
    		......
    
    		startActivityLocked(r, newTask, doResume);
    		return START_SUCCESS;
    	}
    
    	......
    
    }
            函数首先获得intent的标志值,保存在launchFlags变量中。

            这个intent的标志值的位Intent.FLAG_ACTIVITY_NO_USER_ACTION没有置位,因此 ,成员变量mUserLeaving的值为true。

            这个intent的标志值的位Intent.FLAG_ACTIVITY_PREVIOUS_IS_TOP也没有置位,因此,变量notTop的值为null。

            由于在这个例子的AndroidManifest.xml文件中,MainActivity没有配置launchMode属值,因此,这里的r.launchMode为默认值0,表示以标准(Standard,或者称为ActivityInfo.LAUNCH_MULTIPLE)的方式来启动这个Activity。Activity的启动方式有四种,其余三种分别是ActivityInfo.LAUNCH_SINGLE_INSTANCE、ActivityInfo.LAUNCH_SINGLE_TASK和ActivityInfo.LAUNCH_SINGLE_TOP,具体可以参考官方网站http://developer.android.com/reference/android/content/pm/ActivityInfo.html

            传进来的参数r.resultTo为null,表示Launcher不需要等这个即将要启动的MainActivity的执行结果。

            由于这个intent的标志值的位Intent.FLAG_ACTIVITY_NEW_TASK被置位,而且Intent.FLAG_ACTIVITY_MULTIPLE_TASK没有置位,因此,下面的if语句会被执行:

        if (((launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0 &&
    	(launchFlags&Intent.FLAG_ACTIVITY_MULTIPLE_TASK) == 0)
    	|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_TASK
    	|| r.launchMode == ActivityInfo.LAUNCH_SINGLE_INSTANCE) {
    		// If bring to front is requested, and no result is requested, and
    		// we can find a task that was started with this same
    		// component, then instead of launching bring that one to the front.
    		if (r.resultTo == null) {
    			// See if there is a task to bring to the front.  If this is
    			// a SINGLE_INSTANCE activity, there can be one and only one
    			// instance of it in the history, and it is always in its own
    			// unique task, so we do a special search.
    			ActivityRecord taskTop = r.launchMode != ActivityInfo.LAUNCH_SINGLE_INSTANCE
    				? findTaskLocked(intent, r.info)
    				: findActivityLocked(intent, r.info);
    			if (taskTop != null) {
    				......
    			}
    		}
        }
            这段代码的逻辑是查看一下,当前有没有Task可以用来执行这个Activity。由于r.launchMode的值不为ActivityInfo.LAUNCH_SINGLE_INSTANCE,因此,它通过findTaskLocked函数来查找存不存这样的Task,这里返回的结果是null,即taskTop为null,因此,需要创建一个新的Task来启动这个Activity。

            接着往下看:

        if (r.packageName != null) {
    	// If the activity being launched is the same as the one currently
    	// at the top, then we need to check if it should only be launched
    	// once.
    	ActivityRecord top = topRunningNonDelayedActivityLocked(notTop);
    	if (top != null && r.resultTo == null) {
    		if (top.realActivity.equals(r.realActivity)) {
    			......
    		}
    	}
    
        } 
            这段代码的逻辑是看一下,当前在堆栈顶端的Activity是否就是即将要启动的Activity,有些情况下,如果即将要启动的Activity就在堆栈的顶端,那么,就不会重新启动这个Activity的别一个实例了,具体可以参考官方网站http://developer.android.com/reference/android/content/pm/ActivityInfo.html。现在处理堆栈顶端的Activity是Launcher,与我们即将要启动的MainActivity不是同一个Activity,因此,这里不用进一步处理上述介绍的情况。

           执行到这里,我们知道,要在一个新的Task里面来启动这个Activity了,于是新创建一个Task:

       if (r.resultTo == null && !addingToTask
    	&& (launchFlags&Intent.FLAG_ACTIVITY_NEW_TASK) != 0) {
    	// todo: should do better management of integers.
    	mService.mCurTask++;
    	if (mService.mCurTask <= 0) {
    		mService.mCurTask = 1;
    	}
    	r.task = new TaskRecord(mService.mCurTask, r.info, intent,
    		(r.info.flags&ActivityInfo.FLAG_CLEAR_TASK_ON_LAUNCH) != 0);
    	......
    	newTask = true;
    	if (mMainStack) {
    		mService.addRecentTaskLocked(r.task);
    	}
    
        }
            新建的Task保存在r.task域中,同时,添加到mService中去,这里的mService就是ActivityManagerService了。

            最后就进入startActivityLocked(r, newTask, doResume)进一步处理了。这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	private final void startActivityLocked(ActivityRecord r, boolean newTask,
    			boolean doResume) {
    		final int NH = mHistory.size();
    
    		int addPos = -1;
    
    		if (!newTask) {
    			......
    		}
    
    		// Place a new activity at top of stack, so it is next to interact
    		// with the user.
    		if (addPos < 0) {
    			addPos = NH;
    		}
    
    		// If we are not placing the new activity frontmost, we do not want
    		// to deliver the onUserLeaving callback to the actual frontmost
    		// activity
    		if (addPos < NH) {
    			......
    		}
    
    		// Slot the activity into the history stack and proceed
    		mHistory.add(addPos, r);
    		r.inHistory = true;
    		r.frontOfTask = newTask;
    		r.task.numActivities++;
    		if (NH > 0) {
    			// We want to show the starting preview window if we are
    			// switching to a new task, or the next activity's process is
    			// not currently running.
    			......
    		} else {
    			// If this is the first activity, don't do any fancy animations,
    			// because there is nothing for it to animate on top of.
    			......
    		}
    		
    		......
    
    		if (doResume) {
    			resumeTopActivityLocked(null);
    		}
    	}
    
    	......
    
    }
            这里的NH表示当前系统中历史任务的个数,这里肯定是大于0,因为Launcher已经跑起来了。当NH>0时,并且现在要切换新任务时,要做一些任务切的界面操作,这段代码我们就不看了,这里不会影响到下面启Activity的过程,有兴趣的读取可以自己研究一下。

            这里传进来的参数doResume为true,于是调用resumeTopActivityLocked进一步操作。

            Step 10. Activity.resumeTopActivityLocked

            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	/**
    	* Ensure that the top activity in the stack is resumed.
    	*
    	* @param prev The previously resumed activity, for when in the process
    	* of pausing; can be null to call from elsewhere.
    	*
    	* @return Returns true if something is being resumed, or false if
    	* nothing happened.
    	*/
    	final boolean resumeTopActivityLocked(ActivityRecord prev) {
    		// Find the first activity that is not finishing.
    		ActivityRecord next = topRunningActivityLocked(null);
    
    		// Remember how we'll process this pause/resume situation, and ensure
    		// that the state is reset however we wind up proceeding.
    		final boolean userLeaving = mUserLeaving;
    		mUserLeaving = false;
    
    		if (next == null) {
    			......
    		}
    
    		next.delayedResume = false;
    
    		// If the top activity is the resumed one, nothing to do.
    		if (mResumedActivity == next && next.state == ActivityState.RESUMED) {
    			......
    		}
    
    		// If we are sleeping, and there is no resumed activity, and the top
    		// activity is paused, well that is the state we want.
    		if ((mService.mSleeping || mService.mShuttingDown)
    			&& mLastPausedActivity == next && next.state == ActivityState.PAUSED) {
    			......
    		}
    
    		......
    
    		// If we are currently pausing an activity, then don't do anything
    		// until that is done.
    		if (mPausingActivity != null) {
    			......
    		}
    
    		......
    
    		// We need to start pausing the current activity so the top one
    		// can be resumed...
    		if (mResumedActivity != null) {
    			......
    			startPausingLocked(userLeaving, false);
    			return true;
    		}
    
    		......
    	}
    
    	......
    
    }
            函数先通过调用topRunningActivityLocked函数获得堆栈顶端的Activity,这里就是MainActivity了,这是在上面的Step 9设置好的,保存在next变量中。 

           接下来把mUserLeaving的保存在本地变量userLeaving中,然后重新设置为false,在上面的Step 9中,mUserLeaving的值为true,因此,这里的userLeaving为true。

           这里的mResumedActivity为Launcher,因为Launcher是当前正被执行的Activity。

           当我们处理休眠状态时,mLastPausedActivity保存堆栈顶端的Activity,因为当前不是休眠状态,所以mLastPausedActivity为null。

           有了这些信息之后,下面的语句就容易理解了:

        // If the top activity is the resumed one, nothing to do.
        if (mResumedActivity == next && next.state == ActivityState.RESUMED) {
    	......
        }
    
        // If we are sleeping, and there is no resumed activity, and the top
        // activity is paused, well that is the state we want.
        if ((mService.mSleeping || mService.mShuttingDown)
    	&& mLastPausedActivity == next && next.state == ActivityState.PAUSED) {
    	......
        }
            它首先看要启动的Activity是否就是当前处理Resumed状态的Activity,如果是的话,那就什么都不用做,直接返回就可以了;否则再看一下系统当前是否休眠状态,如果是的话,再看看要启动的Activity是否就是当前处于堆栈顶端的Activity,如果是的话,也是什么都不用做。

            上面两个条件都不满足,因此,在继续往下执行之前,首先要把当处于Resumed状态的Activity推入Paused状态,然后才可以启动新的Activity。但是在将当前这个Resumed状态的Activity推入Paused状态之前,首先要看一下当前是否有Activity正在进入Pausing状态,如果有的话,当前这个Resumed状态的Activity就要稍后才能进入Paused状态了,这样就保证了所有需要进入Paused状态的Activity串行处理。

            这里没有处于Pausing状态的Activity,即mPausingActivity为null,而且mResumedActivity也不为null,于是就调用startPausingLocked函数把Launcher推入Paused状态去了。

            Step 11. ActivityStack.startPausingLocked

            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	private final void startPausingLocked(boolean userLeaving, boolean uiSleeping) {
    		if (mPausingActivity != null) {
    			......
    		}
    		ActivityRecord prev = mResumedActivity;
    		if (prev == null) {
    			......
    		}
    		......
    		mResumedActivity = null;
    		mPausingActivity = prev;
    		mLastPausedActivity = prev;
    		prev.state = ActivityState.PAUSING;
    		......
    
    		if (prev.app != null && prev.app.thread != null) {
    			......
    			try {
    				......
    				prev.app.thread.schedulePauseActivity(prev, prev.finishing, userLeaving,
    					prev.configChangeFlags);
    				......
    			} catch (Exception e) {
    				......
    			}
    		} else {
    			......
    		}
    
    		......
    	
    	}
    
    	......
    
    }

            函数首先把mResumedActivity保存在本地变量prev中。在上一步Step 10中,说到mResumedActivity就是Launcher,因此,这里把Launcher进程中的ApplicationThread对象取出来,通过它来通知Launcher这个Activity它要进入Paused状态了。当然,这里的prev.app.thread是一个ApplicationThread对象的远程接口,通过调用这个远程接口的schedulePauseActivity来通知Launcher进入Paused状态。

           参数prev.finishing表示prev所代表的Activity是否正在等待结束的Activity列表中,由于Laucher这个Activity还没结束,所以这里为false;参数prev.configChangeFlags表示哪些config发生了变化,这里我们不关心它的值。

           Step 12. ApplicationThreadProxy.schedulePauseActivity

           这个函数定义在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件中:

    class ApplicationThreadProxy implements IApplicationThread {
    	
    	......
    
    	public final void schedulePauseActivity(IBinder token, boolean finished,
    	boolean userLeaving, int configChanges) throws RemoteException {
    		Parcel data = Parcel.obtain();
    		data.writeInterfaceToken(IApplicationThread.descriptor);
    		data.writeStrongBinder(token);
    		data.writeInt(finished ? 1 : 0);
    		data.writeInt(userLeaving ? 1 :0);
    		data.writeInt(configChanges);
    		mRemote.transact(SCHEDULE_PAUSE_ACTIVITY_TRANSACTION, data, null,
    			IBinder.FLAG_ONEWAY);
    		data.recycle();
    	}
    
    	......
    
    }

            这个函数通过Binder进程间通信机制进入到ApplicationThread.schedulePauseActivity函数中。

            Step 13. ApplicationThread.schedulePauseActivity

            这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中,它是ActivityThread的内部类:

    public final class ActivityThread {
    	
    	......
    
    	private final class ApplicationThread extends ApplicationThreadNative {
    		
    		......
    
    		public final void schedulePauseActivity(IBinder token, boolean finished,
    				boolean userLeaving, int configChanges) {
    			queueOrSendMessage(
    				finished ? H.PAUSE_ACTIVITY_FINISHING : H.PAUSE_ACTIVITY,
    				token,
    				(userLeaving ? 1 : 0),
    				configChanges);
    		}
    
    		......
    
    	}
    
    	......
    
    }
            这里调用的函数queueOrSendMessage是ActivityThread类的成员函数。

           上面说到,这里的finished值为false,因此,queueOrSendMessage的第一个参数值为H.PAUSE_ACTIVITY,表示要暂停token所代表的Activity,即Launcher。

           Step 14. ActivityThread.queueOrSendMessage

           这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    	
    	......
    
    	private final void queueOrSendMessage(int what, Object obj, int arg1) {
    		queueOrSendMessage(what, obj, arg1, 0);
    	}
    
    	private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) {
    		synchronized (this) {
    			......
    			Message msg = Message.obtain();
    			msg.what = what;
    			msg.obj = obj;
    			msg.arg1 = arg1;
    			msg.arg2 = arg2;
    			mH.sendMessage(msg);
    		}
    	}
    
    	......
    
    }
            这里首先将相关信息组装成一个msg,然后通过mH成员变量发送出去,mH的类型是H,继承于Handler类,是ActivityThread的内部类,因此,这个消息最后由H.handleMessage来处理。

            Step 15. H.handleMessage

            这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    	
    	......
    
    	private final class H extends Handler {
    
    		......
    
    		public void handleMessage(Message msg) {
    			......
    			switch (msg.what) {
    			
    			......
    			
    			case PAUSE_ACTIVITY:
    				handlePauseActivity((IBinder)msg.obj, false, msg.arg1 != 0, msg.arg2);
    				maybeSnapshot();
    				break;
    
    			......
    
    			}
    		......
    
    	}
    
    	......
    
    }

            这里调用ActivityThread.handlePauseActivity进一步操作,msg.obj是一个ActivityRecord对象的引用,它代表的是Launcher这个Activity。
            Step 16. ActivityThread.handlePauseActivity

            这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    	
    	......
    
    	private final void handlePauseActivity(IBinder token, boolean finished,
    			boolean userLeaving, int configChanges) {
    
    		ActivityClientRecord r = mActivities.get(token);
    		if (r != null) {
    			//Slog.v(TAG, "userLeaving=" + userLeaving + " handling pause of " + r);
    			if (userLeaving) {
    				performUserLeavingActivity(r);
    			}
    
    			r.activity.mConfigChangeFlags |= configChanges;
    			Bundle state = performPauseActivity(token, finished, true);
    
    			// Make sure any pending writes are now committed.
    			QueuedWork.waitToFinish();
    
    			// Tell the activity manager we have paused.
    			try {
    				ActivityManagerNative.getDefault().activityPaused(token, state);
    			} catch (RemoteException ex) {
    			}
    		}
    	}
    
    	......
    
    }
             函数首先将Binder引用token转换成ActivityRecord的远程接口ActivityClientRecord,然后做了三个事情:1. 如果userLeaving为true,则通过调用performUserLeavingActivity函数来调用Activity.onUserLeaveHint通知Activity,用户要离开它了;2. 调用performPauseActivity函数来调用Activity.onPause函数,我们知道,在Activity的生命周期中,当它要让位于其它的Activity时,系统就会调用它的onPause函数;3. 它通知ActivityManagerService,这个Activity已经进入Paused状态了,ActivityManagerService现在可以完成未竟的事情,即启动MainActivity了。

            Step 17. ActivityManagerProxy.activityPaused

            这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中:

    class ActivityManagerProxy implements IActivityManager
    {
    	......
    
    	public void activityPaused(IBinder token, Bundle state) throws RemoteException
    	{
    		Parcel data = Parcel.obtain();
    		Parcel reply = Parcel.obtain();
    		data.writeInterfaceToken(IActivityManager.descriptor);
    		data.writeStrongBinder(token);
    		data.writeBundle(state);
    		mRemote.transact(ACTIVITY_PAUSED_TRANSACTION, data, reply, 0);
    		reply.readException();
    		data.recycle();
    		reply.recycle();
    	}
    
    	......
    
    }
            这里通过Binder进程间通信机制就进入到ActivityManagerService.activityPaused函数中去了。

            Step 18. ActivityManagerService.activityPaused

            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:

    public final class ActivityManagerService extends ActivityManagerNative
    			implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
    	......
    
    	public final void activityPaused(IBinder token, Bundle icicle) {
    		
    		......
    
    		final long origId = Binder.clearCallingIdentity();
    		mMainStack.activityPaused(token, icicle, false);
    		
    		......
    	}
    
    	......
    
    }
           这里,又再次进入到ActivityStack类中,执行activityPaused函数。

           Step 19. ActivityStack.activityPaused

           这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	final void activityPaused(IBinder token, Bundle icicle, boolean timeout) {
    		
    		......
    
    		ActivityRecord r = null;
    
    		synchronized (mService) {
    			int index = indexOfTokenLocked(token);
    			if (index >= 0) {
    				r = (ActivityRecord)mHistory.get(index);
    				if (!timeout) {
    					r.icicle = icicle;
    					r.haveState = true;
    				}
    				mHandler.removeMessages(PAUSE_TIMEOUT_MSG, r);
    				if (mPausingActivity == r) {
    					r.state = ActivityState.PAUSED;
    					completePauseLocked();
    				} else {
    					......
    				}
    			}
    		}
    	}
    
    	......
    
    }
           这里通过参数token在mHistory列表中得到ActivityRecord,从上面我们知道,这个ActivityRecord代表的是Launcher这个Activity,而我们在Step 11中,把Launcher这个Activity的信息保存在mPausingActivity中,因此,这里mPausingActivity等于r,于是,执行completePauseLocked操作。

           Step 20. ActivityStack.completePauseLocked

           这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	private final void completePauseLocked() {
    		ActivityRecord prev = mPausingActivity;
    		
    		......
    
    		if (prev != null) {
    
    			......
    
    			mPausingActivity = null;
    		}
    
    		if (!mService.mSleeping && !mService.mShuttingDown) {
    			resumeTopActivityLocked(prev);
    		} else {
    			......
    		}
    
    		......
    	}
    
    	......
    
    }
            函数首先把mPausingActivity变量清空,因为现在不需要它了,然后调用resumeTopActivityLokced进一步操作,它传入的参数即为代表Launcher这个Activity的ActivityRecord。

            Step 21. ActivityStack.resumeTopActivityLokced
            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	final boolean resumeTopActivityLocked(ActivityRecord prev) {
    		......
    
    		// Find the first activity that is not finishing.
    		ActivityRecord next = topRunningActivityLocked(null);
    
    		// Remember how we'll process this pause/resume situation, and ensure
    		// that the state is reset however we wind up proceeding.
    		final boolean userLeaving = mUserLeaving;
    		mUserLeaving = false;
    
    		......
    
    		next.delayedResume = false;
    
    		// If the top activity is the resumed one, nothing to do.
    		if (mResumedActivity == next && next.state == ActivityState.RESUMED) {
    			......
    			return false;
    		}
    
    		// If we are sleeping, and there is no resumed activity, and the top
    		// activity is paused, well that is the state we want.
    		if ((mService.mSleeping || mService.mShuttingDown)
    			&& mLastPausedActivity == next && next.state == ActivityState.PAUSED) {
    			......
    			return false;
    		}
    
    		.......
    
    
    		// We need to start pausing the current activity so the top one
    		// can be resumed...
    		if (mResumedActivity != null) {
    			......
    			return true;
    		}
    
    		......
    
    
    		if (next.app != null && next.app.thread != null) {
    			......
    
    		} else {
    			......
    			startSpecificActivityLocked(next, true, true);
    		}
    
    		return true;
    	}
    
    
    	......
    
    }
            通过上面的Step 9,我们知道,当前在堆栈顶端的Activity为我们即将要启动的MainActivity,这里通过调用topRunningActivityLocked将它取回来,保存在next变量中。之前最后一个Resumed状态的Activity,即Launcher,到了这里已经处于Paused状态了,因此,mResumedActivity为null。最后一个处于Paused状态的Activity为Launcher,因此,这里的mLastPausedActivity就为Launcher。前面我们为MainActivity创建了ActivityRecord后,它的app域一直保持为null。有了这些信息后,上面这段代码就容易理解了,它最终调用startSpecificActivityLocked进行下一步操作。

           Step 22. ActivityStack.startSpecificActivityLocked
           这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	private final void startSpecificActivityLocked(ActivityRecord r,
    			boolean andResume, boolean checkConfig) {
    		// Is this activity's application already running?
    		ProcessRecord app = mService.getProcessRecordLocked(r.processName,
    			r.info.applicationInfo.uid);
    
    		......
    
    		if (app != null && app.thread != null) {
    			try {
    				realStartActivityLocked(r, app, andResume, checkConfig);
    				return;
    			} catch (RemoteException e) {
    				......
    			}
    		}
    
    		mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
    			"activity", r.intent.getComponent(), false);
    	}
    
    
    	......
    
    }
            注意,这里由于是第一次启动应用程序的Activity,所以下面语句:

    ProcessRecord app = mService.getProcessRecordLocked(r.processName,
    	r.info.applicationInfo.uid);
            取回来的app为null。在Activity应用程序中的AndroidManifest.xml配置文件中,我们没有指定Application标签的process属性,系统就会默认使用package的名称,这里就是"shy.luo.activity"了。每一个应用程序都有自己的uid,因此,这里uid + process的组合就可以为每一个应用程序创建一个ProcessRecord。当然,我们可以配置两个应用程序具有相同的uid和package,或者在AndroidManifest.xml配置文件的application标签或者activity标签中显式指定相同的process属性值,这样,不同的应用程序也可以在同一个进程中启动。

           函数最终执行ActivityManagerService.startProcessLocked函数进行下一步操作。

           Step 23. ActivityManagerService.startProcessLocked

           这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:

    public final class ActivityManagerService extends ActivityManagerNative
    		implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
    
    	......
    
    	final ProcessRecord startProcessLocked(String processName,
    			ApplicationInfo info, boolean knownToBeDead, int intentFlags,
    			String hostingType, ComponentName hostingName, boolean allowWhileBooting) {
    
    		ProcessRecord app = getProcessRecordLocked(processName, info.uid);
    		
    		......
    
    		String hostingNameStr = hostingName != null
    			? hostingName.flattenToShortString() : null;
    
    		......
    
    		if (app == null) {
    			app = new ProcessRecordLocked(null, info, processName);
    			mProcessNames.put(processName, info.uid, app);
    		} else {
    			// If this is a new package in the process, add the package to the list
    			app.addPackage(info.packageName);
    		}
    
    		......
    
    		startProcessLocked(app, hostingType, hostingNameStr);
    		return (app.pid != 0) ? app : null;
    	}
    
    	......
    
    }
            这里再次检查是否已经有以process + uid命名的进程存在,在我们这个情景中,返回值app为null,因此,后面会创建一个ProcessRecord,并存保存在成员变量mProcessNames中,最后,调用另一个startProcessLocked函数进一步操作:

    public final class ActivityManagerService extends ActivityManagerNative
    		implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
    
    	......
    
    	private final void startProcessLocked(ProcessRecord app,
    				String hostingType, String hostingNameStr) {
    
    		......
    
    		try {
    			int uid = app.info.uid;
    			int[] gids = null;
    			try {
    				gids = mContext.getPackageManager().getPackageGids(
    					app.info.packageName);
    			} catch (PackageManager.NameNotFoundException e) {
    				......
    			}
    			
    			......
    
    			int debugFlags = 0;
    			
    			......
    			
    			int pid = Process.start("android.app.ActivityThread",
    				mSimpleProcessManagement ? app.processName : null, uid, uid,
    				gids, debugFlags, null);
    			
    			......
    
    		} catch (RuntimeException e) {
    			
    			......
    
    		}
    	}
    
    	......
    
    }
            这里主要是调用Process.start接口来创建一个新的进程,新的进程会导入android.app.ActivityThread类,并且执行它的main函数,这就是为什么我们前面说每一个应用程序都有一个ActivityThread实例来对应的原因。

            Step 24. ActivityThread.main

            这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    
    	......
    
    	private final void attach(boolean system) {
    		......
    
    		mSystemThread = system;
    		if (!system) {
    
    			......
    
    			IActivityManager mgr = ActivityManagerNative.getDefault();
    			try {
    				mgr.attachApplication(mAppThread);
    			} catch (RemoteException ex) {
    			}
    		} else {
    
    			......
    
    		}
    	}
    
    	......
    
    	public static final void main(String[] args) {
    		
    		.......
    
    		ActivityThread thread = new ActivityThread();
    		thread.attach(false);
    
    		......
    
    		Looper.loop();
    
    		.......
    
    		thread.detach();
    		
    		......
    	}
    }
           这个函数在进程中创建一个ActivityThread实例,然后调用它的attach函数,接着就进入消息循环了,直到最后进程退出。

           函数attach最终调用了ActivityManagerService的远程接口ActivityManagerProxy的attachApplication函数,传入的参数是mAppThread,这是一个ApplicationThread类型的Binder对象,它的作用是用来进行进程间通信的。

          Step 25. ActivityManagerProxy.attachApplication

          这个函数定义在frameworks/base/core/java/android/app/ActivityManagerNative.java文件中:

    class ActivityManagerProxy implements IActivityManager
    {
    	......
    
    	public void attachApplication(IApplicationThread app) throws RemoteException
    	{
    		Parcel data = Parcel.obtain();
    		Parcel reply = Parcel.obtain();
    		data.writeInterfaceToken(IActivityManager.descriptor);
    		data.writeStrongBinder(app.asBinder());
    		mRemote.transact(ATTACH_APPLICATION_TRANSACTION, data, reply, 0);
    		reply.readException();
    		data.recycle();
    		reply.recycle();
    	}
    
    	......
    
    }
           这里通过Binder驱动程序,最后进入ActivityManagerService的attachApplication函数中。

           Step 26. ActivityManagerService.attachApplication

           这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:

    public final class ActivityManagerService extends ActivityManagerNative
    		implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
    
    	......
    
    	public final void attachApplication(IApplicationThread thread) {
    		synchronized (this) {
    			int callingPid = Binder.getCallingPid();
    			final long origId = Binder.clearCallingIdentity();
    			attachApplicationLocked(thread, callingPid);
    			Binder.restoreCallingIdentity(origId);
    		}
    	}
    
    	......
    
    }
            这里将操作转发给attachApplicationLocked函数。

            Step 27. ActivityManagerService.attachApplicationLocked

            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中:

    public final class ActivityManagerService extends ActivityManagerNative
    		implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
    
    	......
    
    	private final boolean attachApplicationLocked(IApplicationThread thread,
    			int pid) {
    		// Find the application record that is being attached...  either via
    		// the pid if we are running in multiple processes, or just pull the
    		// next app record if we are emulating process with anonymous threads.
    		ProcessRecord app;
    		if (pid != MY_PID && pid >= 0) {
    			synchronized (mPidsSelfLocked) {
    				app = mPidsSelfLocked.get(pid);
    			}
    		} else if (mStartingProcesses.size() > 0) {
    			......
    		} else {
    			......
    		}
    
    		if (app == null) {
    			......
    			return false;
    		}
    
    		......
    
    		String processName = app.processName;
    		try {
    			thread.asBinder().linkToDeath(new AppDeathRecipient(
    				app, pid, thread), 0);
    		} catch (RemoteException e) {
    			......
    			return false;
    		}
    
    		......
    
    		app.thread = thread;
    		app.curAdj = app.setAdj = -100;
    		app.curSchedGroup = Process.THREAD_GROUP_DEFAULT;
    		app.setSchedGroup = Process.THREAD_GROUP_BG_NONINTERACTIVE;
    		app.forcingToForeground = null;
    		app.foregroundServices = false;
    		app.debugging = false;
    
    		......
    
    		boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info);
    
    		......
    
    		boolean badApp = false;
    		boolean didSomething = false;
    
    		// See if the top visible activity is waiting to run in this process...
    		ActivityRecord hr = mMainStack.topRunningActivityLocked(null);
    		if (hr != null && normalMode) {
    			if (hr.app == null && app.info.uid == hr.info.applicationInfo.uid
    				&& processName.equals(hr.processName)) {
    					try {
    						if (mMainStack.realStartActivityLocked(hr, app, true, true)) {
    							didSomething = true;
    						}
    					} catch (Exception e) {
    						......
    					}
    			} else {
    				......
    			}
    		}
    
    		......
    
    		return true;
    	}
    
    	......
    
    }

            在前面的Step 23中,已经创建了一个ProcessRecord,这里首先通过pid将它取回来,放在app变量中,然后对app的其它成员进行初始化,最后调用mMainStack.realStartActivityLocked执行真正的Activity启动操作。这里要启动的Activity通过调用mMainStack.topRunningActivityLocked(null)从堆栈顶端取回来,这时候在堆栈顶端的Activity就是MainActivity了。

            Step 28. ActivityStack.realStartActivityLocked

            这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中:

    public class ActivityStack {
    
    	......
    
    	final boolean realStartActivityLocked(ActivityRecord r,
    			ProcessRecord app, boolean andResume, boolean checkConfig)
    			throws RemoteException {
    		
    		......
    
    		r.app = app;
    
    		......
    
    		int idx = app.activities.indexOf(r);
    		if (idx < 0) {
    			app.activities.add(r);
    		}
    		
    		......
    
    		try {
    			......
    
    			List<ResultInfo> results = null;
    			List<Intent> newIntents = null;
    			if (andResume) {
    				results = r.results;
    				newIntents = r.newIntents;
    			}
    	
    			......
    			
    			app.thread.scheduleLaunchActivity(new Intent(r.intent), r,
    				System.identityHashCode(r),
    				r.info, r.icicle, results, newIntents, !andResume,
    				mService.isNextTransitionForward());
    
    			......
    
    		} catch (RemoteException e) {
    			......
    		}
    
    		......
    
    		return true;
    	}
    
    	......
    
    }
            这里最终通过app.thread进入到ApplicationThreadProxy的scheduleLaunchActivity函数中,注意,这里的第二个参数r,是一个ActivityRecord类型的Binder对象,用来作来这个Activity的token值。

            Step 29. ApplicationThreadProxy.scheduleLaunchActivity
            这个函数定义在frameworks/base/core/java/android/app/ApplicationThreadNative.java文件中:

    class ApplicationThreadProxy implements IApplicationThread {
    
    	......
    
    	public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
    			ActivityInfo info, Bundle state, List<ResultInfo> pendingResults,
    			List<Intent> pendingNewIntents, boolean notResumed, boolean isForward)
    			throws RemoteException {
    		Parcel data = Parcel.obtain();
    		data.writeInterfaceToken(IApplicationThread.descriptor);
    		intent.writeToParcel(data, 0);
    		data.writeStrongBinder(token);
    		data.writeInt(ident);
    		info.writeToParcel(data, 0);
    		data.writeBundle(state);
    		data.writeTypedList(pendingResults);
    		data.writeTypedList(pendingNewIntents);
    		data.writeInt(notResumed ? 1 : 0);
    		data.writeInt(isForward ? 1 : 0);
    		mRemote.transact(SCHEDULE_LAUNCH_ACTIVITY_TRANSACTION, data, null,
    			IBinder.FLAG_ONEWAY);
    		data.recycle();
    	}
    
    	......
    
    }
            这个函数最终通过Binder驱动程序进入到ApplicationThread的scheduleLaunchActivity函数中。

            Step 30. ApplicationThread.scheduleLaunchActivity
            这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    
    	......
    
    	private final class ApplicationThread extends ApplicationThreadNative {
    
    		......
    
    		// we use token to identify this activity without having to send the
    		// activity itself back to the activity manager. (matters more with ipc)
    		public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
    				ActivityInfo info, Bundle state, List<ResultInfo> pendingResults,
    				List<Intent> pendingNewIntents, boolean notResumed, boolean isForward) {
    			ActivityClientRecord r = new ActivityClientRecord();
    
    			r.token = token;
    			r.ident = ident;
    			r.intent = intent;
    			r.activityInfo = info;
    			r.state = state;
    
    			r.pendingResults = pendingResults;
    			r.pendingIntents = pendingNewIntents;
    
    			r.startsNotResumed = notResumed;
    			r.isForward = isForward;
    
    			queueOrSendMessage(H.LAUNCH_ACTIVITY, r);
    		}
    
    		......
    
    	}
    
    	......
    }
             函数首先创建一个ActivityClientRecord实例,并且初始化它的成员变量,然后调用ActivityThread类的queueOrSendMessage函数进一步处理。

             Step 31. ActivityThread.queueOrSendMessage
             这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    
    	......
    
    	private final class ApplicationThread extends ApplicationThreadNative {
    
    		......
    
    		// if the thread hasn't started yet, we don't have the handler, so just
    		// save the messages until we're ready.
    		private final void queueOrSendMessage(int what, Object obj) {
    			queueOrSendMessage(what, obj, 0, 0);
    		}
    
    		......
    
    		private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) {
    			synchronized (this) {
    				......
    				Message msg = Message.obtain();
    				msg.what = what;
    				msg.obj = obj;
    				msg.arg1 = arg1;
    				msg.arg2 = arg2;
    				mH.sendMessage(msg);
    			}
    		}
    
    		......
    
    	}
    
    	......
    }
            函数把消息内容放在msg中,然后通过mH把消息分发出去,这里的成员变量mH我们在前面已经见过,消息分发出去后,最后会调用H类的handleMessage函数。

            Step 32. H.handleMessage

            这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    
    	......
    
    	private final class H extends Handler {
    
    		......
    
    		public void handleMessage(Message msg) {
    			......
    			switch (msg.what) {
    			case LAUNCH_ACTIVITY: {
    				ActivityClientRecord r = (ActivityClientRecord)msg.obj;
    
    				r.packageInfo = getPackageInfoNoCheck(
    					r.activityInfo.applicationInfo);
    				handleLaunchActivity(r, null);
    			} break;
    			......
    			}
    
    		......
    
    	}
    
    	......
    }
            这里最后调用ActivityThread类的handleLaunchActivity函数进一步处理。

            Step 33. ActivityThread.handleLaunchActivity

            这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    
    	......
    
    	private final void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    		......
    
    		Activity a = performLaunchActivity(r, customIntent);
    
    		if (a != null) {
    			r.createdConfig = new Configuration(mConfiguration);
    			Bundle oldState = r.state;
    			handleResumeActivity(r.token, false, r.isForward);
    
    			......
    		} else {
    			......
    		}
    	}
    
    	......
    }
            这里首先调用performLaunchActivity函数来加载这个Activity类,即shy.luo.activity.MainActivity,然后调用它的onCreate函数,最后回到handleLaunchActivity函数时,再调用handleResumeActivity函数来使这个Activity进入Resumed状态,即会调用这个Activity的onResume函数,这是遵循Activity的生命周期的。

            Step 34. ActivityThread.performLaunchActivity
            这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    
    	......
    
    	private final Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    		
    		ActivityInfo aInfo = r.activityInfo;
    		if (r.packageInfo == null) {
    			r.packageInfo = getPackageInfo(aInfo.applicationInfo,
    				Context.CONTEXT_INCLUDE_CODE);
    		}
    
    		ComponentName component = r.intent.getComponent();
    		if (component == null) {
    			component = r.intent.resolveActivity(
    				mInitialApplication.getPackageManager());
    			r.intent.setComponent(component);
    		}
    
    		if (r.activityInfo.targetActivity != null) {
    			component = new ComponentName(r.activityInfo.packageName,
    				r.activityInfo.targetActivity);
    		}
    
    		Activity activity = null;
    		try {
    			java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
    			activity = mInstrumentation.newActivity(
    				cl, component.getClassName(), r.intent);
    			r.intent.setExtrasClassLoader(cl);
    			if (r.state != null) {
    				r.state.setClassLoader(cl);
    			}
    		} catch (Exception e) {
    			......
    		}
    
    		try {
    			Application app = r.packageInfo.makeApplication(false, mInstrumentation);
    
    			......
    
    			if (activity != null) {
    				ContextImpl appContext = new ContextImpl();
    				appContext.init(r.packageInfo, r.token, this);
    				appContext.setOuterContext(activity);
    				CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
    				Configuration config = new Configuration(mConfiguration);
    				......
    				activity.attach(appContext, this, getInstrumentation(), r.token,
    					r.ident, app, r.intent, r.activityInfo, title, r.parent,
    					r.embeddedID, r.lastNonConfigurationInstance,
    					r.lastNonConfigurationChildInstances, config);
    
    				if (customIntent != null) {
    					activity.mIntent = customIntent;
    				}
    				r.lastNonConfigurationInstance = null;
    				r.lastNonConfigurationChildInstances = null;
    				activity.mStartedActivity = false;
    				int theme = r.activityInfo.getThemeResource();
    				if (theme != 0) {
    					activity.setTheme(theme);
    				}
    
    				activity.mCalled = false;
    				mInstrumentation.callActivityOnCreate(activity, r.state);
    				......
    				r.activity = activity;
    				r.stopped = true;
    				if (!r.activity.mFinished) {
    					activity.performStart();
    					r.stopped = false;
    				}
    				if (!r.activity.mFinished) {
    					if (r.state != null) {
    						mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
    					}
    				}
    				if (!r.activity.mFinished) {
    					activity.mCalled = false;
    					mInstrumentation.callActivityOnPostCreate(activity, r.state);
    					if (!activity.mCalled) {
    						throw new SuperNotCalledException(
    							"Activity " + r.intent.getComponent().toShortString() +
    							" did not call through to super.onPostCreate()");
    					}
    				}
    			}
    			r.paused = true;
    
    			mActivities.put(r.token, r);
    
    		} catch (SuperNotCalledException e) {
    			......
    
    		} catch (Exception e) {
    			......
    		}
    
    		return activity;
    	}
    
    	......
    }

           函数前面是收集要启动的Activity的相关信息,主要package和component信息:

       ActivityInfo aInfo = r.activityInfo;
       if (r.packageInfo == null) {
            r.packageInfo = getPackageInfo(aInfo.applicationInfo,
                    Context.CONTEXT_INCLUDE_CODE);
       }
    
       ComponentName component = r.intent.getComponent();
       if (component == null) {
           component = r.intent.resolveActivity(
               mInitialApplication.getPackageManager());
           r.intent.setComponent(component);
       }
    
       if (r.activityInfo.targetActivity != null) {
           component = new ComponentName(r.activityInfo.packageName,
                   r.activityInfo.targetActivity);
       }
           然后通过ClassLoader将shy.luo.activity.MainActivity类加载进来:

       Activity activity = null;
       try {
    	java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
    	activity = mInstrumentation.newActivity(
    		cl, component.getClassName(), r.intent);
    	r.intent.setExtrasClassLoader(cl);
    	if (r.state != null) {
    		r.state.setClassLoader(cl);
    	}
       } catch (Exception e) {
    	......
       }
          接下来是创建Application对象,这是根据AndroidManifest.xml配置文件中的Application标签的信息来创建的:

       Application app = r.packageInfo.makeApplication(false, mInstrumentation);
          后面的代码主要创建Activity的上下文信息,并通过attach方法将这些上下文信息设置到MainActivity中去:

       activity.attach(appContext, this, getInstrumentation(), r.token,
    	r.ident, app, r.intent, r.activityInfo, title, r.parent,
    	r.embeddedID, r.lastNonConfigurationInstance,
    	r.lastNonConfigurationChildInstances, config);
          最后还要调用MainActivity的onCreate函数:

       mInstrumentation.callActivityOnCreate(activity, r.state);
          这里不是直接调用MainActivity的onCreate函数,而是通过mInstrumentation的callActivityOnCreate函数来间接调用,前面我们说过,mInstrumentation在这里的作用是监控Activity与系统的交互操作,相当于是系统运行日志。

          Step 35. MainActivity.onCreate

          这个函数定义在packages/experimental/Activity/src/shy/luo/activity/MainActivity.java文件中,这是我们自定义的app工程文件:

    public class MainActivity extends Activity  implements OnClickListener {
    	
    	......
    
    	@Override
    	public void onCreate(Bundle savedInstanceState) {
    		......
    
    		Log.i(LOG_TAG, "Main Activity Created.");
    	}
    
    	......
    
    }
           这样,MainActivity就启动起来了,整个应用程序也启动起来了。

           整个应用程序的启动过程要执行很多步骤,但是整体来看,主要分为以下五个阶段:

           一. Step1 - Step 11:Launcher通过Binder进程间通信机制通知ActivityManagerService,它要启动一个Activity;

           二. Step 12 - Step 16:ActivityManagerService通过Binder进程间通信机制通知Launcher进入Paused状态;

           三. Step 17 - Step 24:Launcher通过Binder进程间通信机制通知ActivityManagerService,它已经准备就绪进入Paused状态,于是ActivityManagerService就创建一个新的进程,用来启动一个ActivityThread实例,即将要启动的Activity就是在这个ActivityThread实例中运行;

           四. Step 25 - Step 27:ActivityThread通过Binder进程间通信机制将一个ApplicationThread类型的Binder对象传递给ActivityManagerService,以便以后ActivityManagerService能够通过这个Binder对象和它进行通信;

           五. Step 28 - Step 35:ActivityManagerService通过Binder进程间通信机制通知ActivityThread,现在一切准备就绪,它可以真正执行Activity的启动操作了。

           这里不少地方涉及到了Binder进程间通信机制,相关资料请参考Android进程间通信(IPC)机制Binder简要介绍和学习计划一文。

           这样,应用程序的启动过程就介绍完了,它实质上是启动应用程序的默认Activity,在下一篇文章中,我们将介绍在应用程序内部启动另一个Activity的过程,即新的Activity与启动它的Activity将会在同一个进程(Process)和任务(Task)运行,敬请关注。

    老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注!

    展开全文
  • Android应用程序消息处理机制(Looper、Handler)分析

    万次阅读 多人点赞 2017-01-06 14:31:35
    应用程序的主线程不断地从这个消息队例中获取消息(Looper),然后这些消息进行处理(Handler),这样就实现了通过消息来驱动应用程序的执行,本文将详细分析Android应用程序的消息处理机制。 前面我们学习...

            Android应用程序是通过消息来驱动的,系统为每一个应用程序维护一个消息队例,应用程序的主线程不断地从这个消息队例中获取消息(Looper),然后对这些消息进行处理(Handler),这样就实现了通过消息来驱动应用程序的执行,本文将详细分析Android应用程序的消息处理机制。

    《Android系统源代码情景分析》一书正在进击的程序员网(http://0xcc0xcd.com)中连载,点击进入!

            前面我们学习Android应用程序中的Activity启动(Android应用程序启动过程源代码分析Android应用程序内部启动Activity过程(startActivity)的源代码分析)、Service启动(Android系统在新进程中启动自定义服务过程(startService)的原理分析Android应用程序绑定服务(bindService)的过程源代码分析)以及广播发送(Android应用程序发送广播(sendBroadcast)的过程分析)时,它们都有一个共同的特点,当ActivityManagerService需要与应用程序进行并互时,如加载Activity和Service、处理广播待,会通过Binder进程间通信机制来知会应用程序,应用程序接收到这个请求时,它不是马上就处理这个请求,而是将这个请求封装成一个消息,然后把这个消息放在应用程序的消息队列中去,然后再通过消息循环来处理这个消息。这样做的好处就是消息的发送方只要把消息发送到应用程序的消息队列中去就行了,它可以马上返回去处理别的事情,而不需要等待消息的接收方去处理完这个消息才返回,这样就可以提高系统的并发性。实质上,这就是一种异步处理机制。

            这样说可能还是比较笼统,我们以Android应用程序启动过程源代码分析一文中所介绍的应用程序启动过程的一个片断来具体看看是如何这种消息处理机制的。在这篇文章中,要启动的应用程序称为Activity,它的默认Activity是MainActivity,它是由Launcher来负责启动的,而Launcher又是通过ActivityManagerService来启动的,当ActivityManagerService为这个即将要启的应用程序准备好新的进程后,便通过一个Binder进程间通信过程来通知这个新的进程来加载MainActivity,如下图所示:


            它对应Android应用程序启动过程中的Step 30到Step 35,有兴趣的读者可以回过头去参考Android应用程序启动过程源代码分析一文。这里的Step 30中的scheduleLaunchActivity是ActivityManagerService通过Binder进程间通信机制发送过来的请求,它请求应用程序中的ActivityThread执行Step 34中的performLaunchActivity操作,即启动MainActivity的操作。这里我们就可以看到,Step 30的这个请求并没有等待Step 34这个操作完成就返回了,它只是把这个请求封装成一个消息,然后通过Step 31中的queueOrSendMessage操作把这个消息放到应用程序的消息队列中,然后就返回了。应用程序发现消息队列中有消息时,就会通过Step 32中的handleMessage操作来处理这个消息,即调用Step 33中的handleLaunchActivity来执行实际的加载MainAcitivy类的操作。

            了解Android应用程序的消息处理过程之后,我们就开始分样它的实现原理了。与Windows应用程序的消息处理过程一样,Android应用程序的消息处理机制也是由消息循环、消息发送和消息处理这三个部分组成的,接下来,我们就详细描述这三个过程。

            1. 消息循环

            在消息处理机制中,消息都是存放在一个消息队列中去,而应用程序的主线程就是围绕这个消息队列进入一个无限循环的,直到应用程序退出。如果队列中有消息,应用程序的主线程就会把它取出来,并分发给相应的Handler进行处理;如果队列中没有消息,应用程序的主线程就会进入空闲等待状态,等待下一个消息的到来。在Android应用程序中,这个消息循环过程是由Looper类来实现的,它定义在frameworks/base/core/java/android/os/Looper.java文件中,在分析这个类之前,我们先看一下Android应用程序主线程是如何进入到这个消息循环中去的。

            在Android应用程序进程启动过程的源代码分析一文中,我们分析了Android应用程序进程的启动过程,Android应用程序进程在启动的时候,会在进程中加载ActivityThread类,并且执行这个类的main函数,应用程序的消息循环过程就是在这个main函数里面实现的,我们来看看这个函数的实现,它定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {
    	......
    
    	public static final void main(String[] args) {
    		......
    
    		Looper.prepareMainLooper();
    
    		......
    
    		ActivityThread thread = new ActivityThread();
    		thread.attach(false);
    		
    		......
    
    		Looper.loop();
    
    		......
    
    		thread.detach();
    
    		......
    	}
    }
            这个函数做了两件事情,一是在主线程中创建了一个ActivityThread实例,二是通过Looper类使主线程进入消息循环中,这里我们只关注后者。

            首先看Looper.prepareMainLooper函数的实现,这是一个静态成员函数,定义在frameworks/base/core/java/android/os/Looper.java文件中:

    public class Looper {
    	......
    
    	private static final ThreadLocal sThreadLocal = new ThreadLocal();
    
    	final MessageQueue mQueue;
    
    	......
    
    	/** Initialize the current thread as a looper.
    	* This gives you a chance to create handlers that then reference
    	* this looper, before actually starting the loop. Be sure to call
    	* {@link #loop()} after calling this method, and end it by calling
    	* {@link #quit()}.
    	*/
    	public static final void prepare() {
    		if (sThreadLocal.get() != null) {
    			throw new RuntimeException("Only one Looper may be created per thread");
    		}
    		sThreadLocal.set(new Looper());
    	}
    
    	/** Initialize the current thread as a looper, marking it as an application's main 
    	*  looper. The main looper for your application is created by the Android environment,
    	*  so you should never need to call this function yourself.
    	* {@link #prepare()}
    	*/
    
    	public static final void prepareMainLooper() {
    		prepare();
    		setMainLooper(myLooper());
    		if (Process.supportsProcesses()) {
    			myLooper().mQueue.mQuitAllowed = false;
    		}
    	}
    
    	private synchronized static void setMainLooper(Looper looper) {
    		mMainLooper = looper;
    	}
    
    	/**
    	* Return the Looper object associated with the current thread.  Returns
    	* null if the calling thread is not associated with a Looper.
    	*/
    	public static final Looper myLooper() {
    		return (Looper)sThreadLocal.get();
    	}
    
    	private Looper() {
    		mQueue = new MessageQueue();
    		mRun = true;
    		mThread = Thread.currentThread();
    	}
    
    	......
    }
            函数prepareMainLooper做的事情其实就是在线程中创建一个Looper对象,这个Looper对象是存放在sThreadLocal成员变量里面的,成员变量sThreadLocal的类型为ThreadLocal,表示这是一个线程局部变量,即保证每一个调用了prepareMainLooper函数的线程里面都有一个独立的Looper对象。在线程是创建Looper对象的工作是由prepare函数来完成的,而在创建Looper对象的时候,会同时创建一个消息队列MessageQueue,保存在Looper的成员变量mQueue中,后续消息就是存放在这个队列中去。消息队列在Android应用程序消息处理机制中最重要的组件,因此,我们看看它的创建过程,即它的构造函数的实现,实现frameworks/base/core/java/android/os/MessageQueue.java文件中:

    public class MessageQueue {
    	......
    
    	private int mPtr; // used by native code
    
    	private native void nativeInit();
    
    	MessageQueue() {
    		nativeInit();
    	}
    
    	......
    }
            它的初始化工作都交给JNI方法nativeInit来实现了,这个JNI方法定义在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中:

    static void android_os_MessageQueue_nativeInit(JNIEnv* env, jobject obj) {
        NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
        if (! nativeMessageQueue) {
            jniThrowRuntimeException(env, "Unable to allocate native queue");
            return;
        }
    
        android_os_MessageQueue_setNativeMessageQueue(env, obj, nativeMessageQueue);
    }
            在JNI中,也相应地创建了一个消息队列NativeMessageQueue,NativeMessageQueue类也是定义在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中,它的创建过程如下所示:

    NativeMessageQueue::NativeMessageQueue() {
        mLooper = Looper::getForThread();
        if (mLooper == NULL) {
            mLooper = new Looper(false);
            Looper::setForThread(mLooper);
        }
    }
            它主要就是在内部创建了一个Looper对象,注意,这个Looper对象是实现在JNI层的,它与上面Java层中的Looper是不一样的,不过它们是对应的,下面我们进一步分析消息循环的过程的时候,读者就会清楚地了解到它们之间的关系。

            这个Looper的创建过程也很重要,不过我们暂时放一放,先分析完android_os_MessageQueue_nativeInit函数的执行,它创建了本地消息队列NativeMessageQueue对象之后,接着调用android_os_MessageQueue_setNativeMessageQueue函数来把这个消息队列对象保存在前面我们在Java层中创建的MessageQueue对象的mPtr成员变量里面:

    static void android_os_MessageQueue_setNativeMessageQueue(JNIEnv* env, jobject messageQueueObj,
            NativeMessageQueue* nativeMessageQueue) {
        env->SetIntField(messageQueueObj, gMessageQueueClassInfo.mPtr,
                 reinterpret_cast<jint>(nativeMessageQueue));
    }
            这里传进来的参数messageQueueObj即为我们前面在Java层创建的消息队列对象,而gMessageQueueClassInfo.mPtr即表示在Java类MessageQueue中,其成员变量mPtr的偏移量,通过这个偏移量,就可以把这个本地消息队列对象natvieMessageQueue保存在Java层创建的消息队列对象的mPtr成员变量中,这是为了后续我们调用Java层的消息队列对象的其它成员函数进入到JNI层时,能够方便地找回它在JNI层所对应的消息队列对象。

            我们再回到NativeMessageQueue的构造函数中,看看JNI层的Looper对象的创建过程,即看看它的构造函数是如何实现的,这个Looper类实现在frameworks/base/libs/utils/Looper.cpp文件中:

    Looper::Looper(bool allowNonCallbacks) :
    	mAllowNonCallbacks(allowNonCallbacks),
    	mResponseIndex(0) {
    	int wakeFds[2];
    	int result = pipe(wakeFds);
    	......
    
    	mWakeReadPipeFd = wakeFds[0];
    	mWakeWritePipeFd = wakeFds[1];
    
    	......
    
    #ifdef LOOPER_USES_EPOLL
    	// Allocate the epoll instance and register the wake pipe.
    	mEpollFd = epoll_create(EPOLL_SIZE_HINT);
    	......
    
    	struct epoll_event eventItem;
    	memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
    	eventItem.events = EPOLLIN;
    	eventItem.data.fd = mWakeReadPipeFd;
    	result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);
    	......
    #else
    	......
    #endif
    
    	......
    }
            这个构造函数做的事情非常重要,它跟我们后面要介绍的应用程序主线程在消息队列中没有消息时要进入等待状态以及当消息队列有消息时要把应用程序主线程唤醒的这两个知识点息息相关。它主要就是通过pipe系统调用来创建了一个管道了:

    int wakeFds[2];
    int result = pipe(wakeFds);
    ......
    
    mWakeReadPipeFd = wakeFds[0];
    mWakeWritePipeFd = wakeFds[1];
            管道是Linux系统中的一种进程间通信机制,具体可以参考前面一篇文章Android学习启动篇推荐的一本书《Linux内核源代码情景分析》中的第6章--传统的Uinx进程间通信。简单来说,管道就是一个文件,在管道的两端,分别是两个打开文件文件描述符,这两个打开文件描述符都是对应同一个文件,其中一个是用来读的,别一个是用来写的,一般的使用方式就是,一个线程通过读文件描述符中来读管道的内容,当管道没有内容时,这个线程就会进入等待状态,而另外一个线程通过写文件描述符来向管道中写入内容,写入内容的时候,如果另一端正有线程正在等待管道中的内容,那么这个线程就会被唤醒。这个等待和唤醒的操作是如何进行的呢,这就要借助Linux系统中的epoll机制了。 Linux系统中的epoll机制为处理大批量句柄而作了改进的poll,是Linux下多路复用IO接口select/poll的增强版本,它能显著减少程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。但是这里我们其实只需要监控的IO接口只有mWakeReadPipeFd一个,即前面我们所创建的管道的读端,为什么还需要用到epoll呢?有点用牛刀来杀鸡的味道。其实不然,这个Looper类是非常强大的,它除了监控内部所创建的管道接口之外,还提供了addFd接口供外界面调用,外界可以通过这个接口把自己想要监控的IO事件一并加入到这个Looper对象中去,当所有这些被监控的IO接口上面有事件发生时,就会唤醒相应的线程来处理,不过这里我们只关心刚才所创建的管道的IO事件的发生。

            要使用Linux系统的epoll机制,首先要通过epoll_create来创建一个epoll专用的文件描述符:

    mEpollFd = epoll_create(EPOLL_SIZE_HINT);
           传入的参数EPOLL_SIZE_HINT是在这个mEpollFd上能监控的最大文件描述符数。

           接着还要通过epoll_ctl函数来告诉epoll要监控相应的文件描述符的什么事件:

    struct epoll_event eventItem;
    memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
    eventItem.events = EPOLLIN;
    eventItem.data.fd = mWakeReadPipeFd;
    result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);
           这里就是告诉mEpollFd,它要监控mWakeReadPipeFd文件描述符的EPOLLIN事件,即当管道中有内容可读时,就唤醒当前正在等待管道中的内容的线程。
           C++层的这个Looper对象创建好了之后,就返回到JNI层的NativeMessageQueue的构造函数,最后就返回到Java层的消息队列MessageQueue的创建过程,这样,Java层的Looper对象就准备好了。有点复杂,我们先小结一下这一步都做了些什么事情:

           A. 在Java层,创建了一个Looper对象,这个Looper对象是用来进入消息循环的,它的内部有一个消息队列MessageQueue对象mQueue;

           B. 在JNI层,创建了一个NativeMessageQueue对象,这个NativeMessageQueue对象保存在Java层的消息队列对象mQueue的成员变量mPtr中;

           C. 在C++层,创建了一个Looper对象,保存在JNI层的NativeMessageQueue对象的成员变量mLooper中,这个对象的作用是,当Java层的消息队列中没有消息时,就使Android应用程序主线程进入等待状态,而当Java层的消息队列中来了新的消息后,就唤醒Android应用程序的主线程来处理这个消息。

           回到ActivityThread类的main函数中,在上面这些工作都准备好之后,就调用Looper类的loop函数进入到消息循环中去了:

    public class Looper {
    	......
    
    	public static final void loop() {
    		Looper me = myLooper();
    		MessageQueue queue = me.mQueue;
    
    		......
    
    		while (true) {
    			Message msg = queue.next(); // might block
    			......
    
    			if (msg != null) {
    				if (msg.target == null) {
    					// No target is a magic identifier for the quit message.
    					return;
    				}
    
    				......
    
    				msg.target.dispatchMessage(msg);
    				
    				......
    
    				msg.recycle();
    			}
    		}
    	}
    
    	......
    }
            这里就是进入到消息循环中去了,它不断地从消息队列mQueue中去获取下一个要处理的消息msg,如果消息的target成员变量为null,就表示要退出消息循环了,否则的话就要调用这个target对象的dispatchMessage成员函数来处理这个消息,这个target对象的类型为Handler,下面我们分析消息的发送时会看到这个消息对象msg是如设置的。

            这个函数最关键的地方便是从消息队列中获取下一个要处理的消息了,即MessageQueue.next函数,它实现frameworks/base/core/java/android/os/MessageQueue.java文件中:

    public class MessageQueue {
    	......
    
    	final Message next() {
    		int pendingIdleHandlerCount = -1; // -1 only during first iteration
    		int nextPollTimeoutMillis = 0;
    
    		for (;;) {
    			if (nextPollTimeoutMillis != 0) {
    				Binder.flushPendingCommands();
    			}
    			nativePollOnce(mPtr, nextPollTimeoutMillis);
    
    			synchronized (this) {
    				// Try to retrieve the next message.  Return if found.
    				final long now = SystemClock.uptimeMillis();
    				final Message msg = mMessages;
    				if (msg != null) {
    					final long when = msg.when;
    					if (now >= when) {
    						mBlocked = false;
    						mMessages = msg.next;
    						msg.next = null;
    						if (Config.LOGV) Log.v("MessageQueue", "Returning message: " + msg);
    						return msg;
    					} else {
    						nextPollTimeoutMillis = (int) Math.min(when - now, Integer.MAX_VALUE);
    					}
    				} else {
    					nextPollTimeoutMillis = -1;
    				}
    
    				// If first time, then get the number of idlers to run.
    				if (pendingIdleHandlerCount < 0) {
    					pendingIdleHandlerCount = mIdleHandlers.size();
    				}
    				if (pendingIdleHandlerCount == 0) {
    					// No idle handlers to run.  Loop and wait some more.
    					mBlocked = true;
    					continue;
    				}
    
    				if (mPendingIdleHandlers == null) {
    					mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
    				}
    				mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
    			}
    
    			// Run the idle handlers.
    			// We only ever reach this code block during the first iteration.
    			for (int i = 0; i < pendingIdleHandlerCount; i++) {
    				final IdleHandler idler = mPendingIdleHandlers[i];
    				mPendingIdleHandlers[i] = null; // release the reference to the handler
    
    				boolean keep = false;
    				try {
    					keep = idler.queueIdle();
    				} catch (Throwable t) {
    					Log.wtf("MessageQueue", "IdleHandler threw exception", t);
    				}
    
    				if (!keep) {
    					synchronized (this) {
    						mIdleHandlers.remove(idler);
    					}
    				}
    			}
    
    			// Reset the idle handler count to 0 so we do not run them again.
    			pendingIdleHandlerCount = 0;
    
    			// While calling an idle handler, a new message could have been delivered
    			// so go back and look again for a pending message without waiting.
    			nextPollTimeoutMillis = 0;
    		}
    	}
    
    	......
    }
            调用这个函数的时候,有可能会让线程进入等待状态。什么情况下,线程会进入等待状态呢?两种情况,一是当消息队列中没有消息时,它会使线程进入等待状态;二是消息队列中有消息,但是消息指定了执行的时间,而现在还没有到这个时间,线程也会进入等待状态。消息队列中的消息是按时间先后来排序的,后面我们在分析消息的发送时会看到。

            执行下面语句是看看当前消息队列中有没有消息:

    nativePollOnce(mPtr, nextPollTimeoutMillis);
            这是一个JNI方法,我们等一下再分析,这里传入的参数mPtr就是指向前面我们在JNI层创建的NativeMessageQueue对象了,而参数nextPollTimeoutMillis则表示如果当前消息队列中没有消息,它要等待的时候,for循环开始时,传入的值为0,表示不等待。

            当前nativePollOnce返回后,就去看看消息队列中有没有消息:

    final Message msg = mMessages;
    if (msg != null) {
    	final long when = msg.when;
    	if (now >= when) {
    		mBlocked = false;
    		mMessages = msg.next;
    		msg.next = null;
    		if (Config.LOGV) Log.v("MessageQueue", "Returning message: " + msg);
    		return msg;
    	} else {
    		nextPollTimeoutMillis = (int) Math.min(when - now, Integer.MAX_VALUE);
    	}
    } else {
    	nextPollTimeoutMillis = -1;
    }
            如果消息队列中有消息,并且当前时候大于等于消息中的执行时间,那么就直接返回这个消息给Looper.loop消息处理,否则的话就要等待到消息的执行时间:

    nextPollTimeoutMillis = (int) Math.min(when - now, Integer.MAX_VALUE);
            如果消息队列中没有消息,那就要进入无穷等待状态直到有新消息了:

    nextPollTimeoutMillis = -1;
            -1表示下次调用nativePollOnce时,如果消息中没有消息,就进入无限等待状态中去。

            这里计算出来的等待时间都是在下次调用nativePollOnce时使用的。

            这里说的等待,是空闲等待,而不是忙等待,因此,在进入空闲等待状态前,如果应用程序注册了IdleHandler接口来处理一些事情,那么就会先执行这里IdleHandler,然后再进入等待状态。IdlerHandler是定义在MessageQueue的一个内部类:

    public class MessageQueue {
    	......
    
    	/**
    	* Callback interface for discovering when a thread is going to block
    	* waiting for more messages.
    	*/
    	public static interface IdleHandler {
    		/**
    		* Called when the message queue has run out of messages and will now
    		* wait for more.  Return true to keep your idle handler active, false
    		* to have it removed.  This may be called if there are still messages
    		* pending in the queue, but they are all scheduled to be dispatched
    		* after the current time.
    		*/
    		boolean queueIdle();
    	}
    
    	......
    }
            它只有一个成员函数queueIdle,执行这个函数时,如果返回值为false,那么就会从应用程序中移除这个IdleHandler,否则的话就会在应用程序中继续维护着这个IdleHandler,下次空闲时仍会再执会这个IdleHandler。MessageQueue提供了addIdleHandler和removeIdleHandler两注册和删除IdleHandler。

            回到MessageQueue函数中,它接下来就是在进入等待状态前,看看有没有IdleHandler是需要执行的:

    // If first time, then get the number of idlers to run.
    if (pendingIdleHandlerCount < 0) {
    	pendingIdleHandlerCount = mIdleHandlers.size();
    }
    if (pendingIdleHandlerCount == 0) {
    	// No idle handlers to run.  Loop and wait some more.
    	mBlocked = true;
    	continue;
    }
    
    if (mPendingIdleHandlers == null) {
    	mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
    }
    mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
            如果没有,即pendingIdleHandlerCount等于0,那下面的逻辑就不执行了,通过continue语句直接进入下一次循环,否则就要把注册在mIdleHandlers中的IdleHandler取出来,放在mPendingIdleHandlers数组中去。

            接下来就是执行这些注册了的IdleHanlder了:

    // Run the idle handlers.
    // We only ever reach this code block during the first iteration.
    for (int i = 0; i < pendingIdleHandlerCount; i++) {
          final IdleHandler idler = mPendingIdleHandlers[i];
          mPendingIdleHandlers[i] = null; // release the reference to the handler
    
          boolean keep = false;
          try {
                keep = idler.queueIdle();
          } catch (Throwable t) {
                Log.wtf("MessageQueue", "IdleHandler threw exception", t);
          }
    
          if (!keep) {
                synchronized (this) {
                        mIdleHandlers.remove(idler);
                }
          }
    }
    
             执行完这些IdleHandler之后,线程下次调用nativePollOnce函数时,就不设置超时时间了,因为,很有可能在执行IdleHandler的时候,已经有新的消息加入到消息队列中去了,因此,要重置nextPollTimeoutMillis的值:

    // While calling an idle handler, a new message could have been delivered
    // so go back and look again for a pending message without waiting.
    nextPollTimeoutMillis = 0;
    
            分析完MessageQueue的这个next函数之后,我们就要深入分析一下JNI方法nativePollOnce了,看看它是如何进入等待状态的,这个函数定义在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中:

    static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
            jint ptr, jint timeoutMillis) {
        NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
        nativeMessageQueue->pollOnce(timeoutMillis);
    }
            这个函数首先是通过传进入的参数ptr取回前面在Java层创建MessageQueue对象时在JNI层创建的NatvieMessageQueue对象,然后调用它的pollOnce函数:

    void NativeMessageQueue::pollOnce(int timeoutMillis) {
        mLooper->pollOnce(timeoutMillis);
    }
            这里将操作转发给mLooper对象的pollOnce函数处理,这里的mLooper对象是在C++层的对象,它也是在前面在JNI层创建的NatvieMessageQueue对象时创建的,它的pollOnce函数定义在frameworks/base/libs/utils/Looper.cpp文件中:

    int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
    	int result = 0;
    	for (;;) {
    		......
    
    		if (result != 0) {
    			......
    
    			return result;
    		}
    
    		result = pollInner(timeoutMillis);
    	}
    }
            为了方便讨论,我们把这个函数的无关部分都去掉,它主要就是调用pollInner函数来进一步操作,如果pollInner返回值不等于0,这个函数就可以返回了。

            函数pollInner的定义如下:

    int Looper::pollInner(int timeoutMillis) {
    	......
    
    	int result = ALOOPER_POLL_WAKE;
    
    	......
    
    #ifdef LOOPER_USES_EPOLL
    	struct epoll_event eventItems[EPOLL_MAX_EVENTS];
    	int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
    	bool acquiredLock = false;
    #else
    	......
    #endif
    
    	if (eventCount < 0) {
    		if (errno == EINTR) {
    			goto Done;
    		}
    
    		LOGW("Poll failed with an unexpected error, errno=%d", errno);
    		result = ALOOPER_POLL_ERROR;
    		goto Done;
    	}
    
    	if (eventCount == 0) {
    		......
    		result = ALOOPER_POLL_TIMEOUT;
    		goto Done;
    	}
    
    	......
    
    #ifdef LOOPER_USES_EPOLL
    	for (int i = 0; i < eventCount; i++) {
    		int fd = eventItems[i].data.fd;
    		uint32_t epollEvents = eventItems[i].events;
    		if (fd == mWakeReadPipeFd) {
    			if (epollEvents & EPOLLIN) {
    				awoken();
    			} else {
    				LOGW("Ignoring unexpected epoll events 0x%x on wake read pipe.", epollEvents);
    			}
    		} else {
    			......
    		}
    	}
    	if (acquiredLock) {
    		mLock.unlock();
    	}
    Done: ;
    #else
    	......
    #endif
    
    	......
    
    	return result;
    }
            这里,首先是调用epoll_wait函数来看看epoll专用文件描述符mEpollFd所监控的文件描述符是否有IO事件发生,它设置监控的超时时间为timeoutMillis:

    int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
            回忆一下前面的Looper的构造函数,我们在里面设置了要监控mWakeReadPipeFd文件描述符的EPOLLIN事件。

            当mEpollFd所监控的文件描述符发生了要监控的IO事件后或者监控时间超时后,线程就从epoll_wait返回了,否则线程就会在epoll_wait函数中进入睡眠状态了。返回后如果eventCount等于0,就说明是超时了:

    if (eventCount == 0) {
        ......
        result = ALOOPER_POLL_TIMEOUT;
        goto Done;
    }
           如果eventCount不等于0,就说明发生要监控的事件:

    for (int i = 0; i < eventCount; i++) {
    	int fd = eventItems[i].data.fd;
    	uint32_t epollEvents = eventItems[i].events;
    	if (fd == mWakeReadPipeFd) {
    		if (epollEvents & EPOLLIN) {
    			awoken();
    		} else {
    			LOGW("Ignoring unexpected epoll events 0x%x on wake read pipe.", epollEvents);
    		}
    	} else {
    			......
    	}
    }
            这里我们只关注mWakeReadPipeFd文件描述符上的事件,如果在mWakeReadPipeFd文件描述符上发生了EPOLLIN就说明应用程序中的消息队列里面有新的消息需要处理了,接下来它就会先调用awoken函数清空管道中的内容,以便下次再调用pollInner函数时,知道自从上次处理完消息队列中的消息后,有没有新的消息加进来。

            函数awoken的实现很简单,它只是把管道中的内容都读取出来:

    void Looper::awoken() {
    	......
    
    	char buffer[16];
    	ssize_t nRead;
    	do {
    		nRead = read(mWakeReadPipeFd, buffer, sizeof(buffer));
    	} while ((nRead == -1 && errno == EINTR) || nRead == sizeof(buffer));
    }
            因为当其它的线程向应用程序的消息队列加入新的消息时,会向这个管道写入新的内容来通知应用程序主线程有新的消息需要处理了,下面我们分析消息的发送的时候将会看到。

            这样,消息的循环过程就分析完了,这部分逻辑还是比较复杂的,它利用Linux系统中的管道(pipe)进程间通信机制来实现消息的等待和处理,不过,了解了这部分内容之后,下面我们分析消息的发送和处理就简单多了。

            2. 消息的发送
            应用程序的主线程准备就好消息队列并且进入到消息循环后,其它地方就可以往这个消息队列中发送消息了。我们继续以文章开始介绍的Android应用程序启动过程源代码分析一文中的应用程序启动过为例,说明应用程序是如何把消息加入到应用程序的消息队列中去的。

            在Android应用程序启动过程源代码分析这篇文章的Step 30中,ActivityManagerService通过调用ApplicationThread类的scheduleLaunchActivity函数通知应用程序,它可以加载应用程序的默认Activity了,这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {  
      
        ......  
      
        private final class ApplicationThread extends ApplicationThreadNative {  
      
            ......  
      
            // we use token to identify this activity without having to send the  
            // activity itself back to the activity manager. (matters more with ipc)  
            public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,  
                    ActivityInfo info, Bundle state, List<ResultInfo> pendingResults,  
                    List<Intent> pendingNewIntents, boolean notResumed, boolean isForward) {  
                ActivityClientRecord r = new ActivityClientRecord();  
      
                r.token = token;  
                r.ident = ident;  
                r.intent = intent;  
                r.activityInfo = info;  
                r.state = state;  
      
                r.pendingResults = pendingResults;  
                r.pendingIntents = pendingNewIntents;  
      
                r.startsNotResumed = notResumed;  
                r.isForward = isForward;  
      
                queueOrSendMessage(H.LAUNCH_ACTIVITY, r);  
            }  
      
            ......  
      
        }  
      
        ......  
    }  
            这里把相关的参数都封装成一个ActivityClientRecord对象r,然后调用queueOrSendMessage函数来往应用程序的消息队列中加入一个新的消息(H.LAUNCH_ACTIVITY),这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {  
      
        ......  
      
        private final class ApplicationThread extends ApplicationThreadNative {  
      
            ......  
      
            // if the thread hasn't started yet, we don't have the handler, so just  
            // save the messages until we're ready.  
            private final void queueOrSendMessage(int what, Object obj) {  
                queueOrSendMessage(what, obj, 0, 0);  
            }  
      
            ......  
      
            private final void queueOrSendMessage(int what, Object obj, int arg1, int arg2) {  
                synchronized (this) {  
                    ......  
                    Message msg = Message.obtain();  
                    msg.what = what;  
                    msg.obj = obj;  
                    msg.arg1 = arg1;  
                    msg.arg2 = arg2;  
                    mH.sendMessage(msg);  
                }  
            }  
      
            ......  
      
        }  
      
        ......  
    }  
            在queueOrSendMessage函数中,又进一步把上面传进来的参数封装成一个Message对象msg,然后通过mH.sendMessage函数把这个消息对象msg加入到应用程序的消息队列中去。这里的mH是ActivityThread类的成员变量,它的类型为H,继承于Handler类,它定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {  
      
        ......  
      
        private final class H extends Handler {  
      
            ......  
      
            public void handleMessage(Message msg) {  
                ......  
                switch (msg.what) {    
                ......  
                }  
      
            ......  
      
        }  
      
        ......  
    } 

            这个H类就是通过其成员函数handleMessage函数来处理消息的了,后面我们分析消息的处理过程时会看到。
            ActivityThread类的这个mH成员变量是什么时候创建的呢?我们前面在分析应用程序的消息循环时,说到当应用程序进程启动之后,就会加载ActivityThread类的main函数里面,在这个main函数里面,在通过Looper类进入消息循环之前,会在当前进程中创建一个ActivityThread实例:

    public final class ActivityThread {
    	......
    
    	public static final void main(String[] args) {
    		......
    
    		ActivityThread thread = new ActivityThread();
    		thread.attach(false);
    
    		......
    	}
    }
            在创建这个实例的时候,就会同时创建其成员变量mH了:

    public final class ActivityThread {
    	......
    
    	final H mH = new H();
    
    	......
    } 
            前面说过,H类继承于Handler类,因此,当创建这个H对象时,会调用Handler类的构造函数,这个函数定义在frameworks/base/core/java/android/os/Handler.java文件中:

    public class Handler {
    	......
    
    	public Handler() {
    		......
    
    		mLooper = Looper.myLooper();
    		......
    
    		mQueue = mLooper.mQueue;
    		......
    	}
    
    
    	final MessageQueue mQueue;
    	final Looper mLooper;
    	......
    }
            在Hanlder类的构造函数中,主要就是初始成员变量mLooper和mQueue了。这里的myLooper是Looper类的静态成员函数,通过它来获得一个Looper对象,这个Looper对象就是前面我们在分析消息循环时,在ActivityThread类的main函数中通过Looper.prepareMainLooper函数创建的。Looper.myLooper函数实现在frameworks/base/core/java/android/os/Looper.java文件中:

    public class Looper {
    	......
    
    	public static final Looper myLooper() {
    		return (Looper)sThreadLocal.get();
    	}
    
    	......
    }
            有了这个Looper对象后,就可以通过Looper.mQueue来访问应用程序的消息队列了。

            有了这个Handler对象mH后,就可以通过它来往应用程序的消息队列中加入新的消息了。回到前面的queueOrSendMessage函数中,当它准备好了一个Message对象msg后,就开始调用mH.sendMessage函数来发送消息了,这个函数定义在frameworks/base/core/java/android/os/Handler.java文件中:

    public class Handler {
    	......
    
    	public final boolean sendMessage(Message msg)
    	{
    		return sendMessageDelayed(msg, 0);
    	}
    
    	public final boolean sendMessageDelayed(Message msg, long delayMillis)
    	{
    		if (delayMillis < 0) {
    			delayMillis = 0;
    		}
    		return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    	}
    
    	public boolean sendMessageAtTime(Message msg, long uptimeMillis)
    	{
    		boolean sent = false;
    		MessageQueue queue = mQueue;
    		if (queue != null) {
    			msg.target = this;
    			sent = queue.enqueueMessage(msg, uptimeMillis);
    		}
    		else {
    			......
    		}
    		return sent;
    	}
    
    	......
    }
            在发送消息时,是可以指定消息的处理时间的,但是通过sendMessage函数发送的消息的处理时间默认就为当前时间,即表示要马上处理,因此,从sendMessage函数中调用sendMessageDelayed函数,传入的时间参数为0,表示这个消息不要延时处理,而在sendMessageDelayed函数中,则会先获得当前时间,然后加上消息要延时处理的时间,即得到这个处理这个消息的绝对时间,然后调用sendMessageAtTime函数来把消息加入到应用程序的消息队列中去。

            在sendMessageAtTime函数,首先得到应用程序的消息队列mQueue,这是在Handler对象构造时初始化好的,前面已经分析过了,接着设置这个消息的目标对象target,即这个消息最终是由谁来处理的:

    msg.target = this;
            这里将它赋值为this,即表示这个消息最终由这个Handler对象来处理,即由ActivityThread对象的mH成员变量来处理。

            函数最后调用queue.enqueueMessage来把这个消息加入到应用程序的消息队列中去,这个函数实现在frameworks/base/core/java/android/os/MessageQueue.java文件中:

    public class MessageQueue {
    	......
    
    	final boolean enqueueMessage(Message msg, long when) {
    		......
    
    		final boolean needWake;
    		synchronized (this) {
    			......
    
    			msg.when = when;
    			//Log.d("MessageQueue", "Enqueing: " + msg);
    			Message p = mMessages;
    			if (p == null || when == 0 || when < p.when) {
    				msg.next = p;
    				mMessages = msg;
    				needWake = mBlocked; // new head, might need to wake up
    			} else {
    				Message prev = null;
    				while (p != null && p.when <= when) {
    					prev = p;
    					p = p.next;
    				}
    				msg.next = prev.next;
    				prev.next = msg;
    				needWake = false; // still waiting on head, no need to wake up
    			}
    
    		}
    		if (needWake) {
    			nativeWake(mPtr);
    		}
    		return true;
    	}
    
    	......
    }
            把消息加入到消息队列时,分两种情况,一种当前消息队列为空时,这时候应用程序的主线程一般就是处于空闲等待状态了,这时候就要唤醒它,另一种情况是应用程序的消息队列不为空,这时候就不需要唤醒应用程序的主线程了,因为这时候它一定是在忙着处于消息队列中的消息,因此不会处于空闲等待的状态。

            第一种情况比较简单,只要把消息放在消息队列头就可以了:

    msg.next = p;
    mMessages = msg;
    needWake = mBlocked; // new head, might need to wake up
            第二种情况相对就比较复杂一些了,前面我们说过,当往消息队列中发送消息时,是可以指定消息的处理时间的,而消息队列中的消息,就是按照这个时间从小到大来排序的,因此,当把新的消息加入到消息队列时,就要根据它的处理时间来找到合适的位置,然后再放进消息队列中去:

    Message prev = null;
    while (p != null && p.when <= when) {
    	prev = p;
    	p = p.next;
    }
    msg.next = prev.next;
    prev.next = msg;
    needWake = false; // still waiting on head, no need to wake up
            把消息加入到消息队列去后,如果应用程序的主线程正处于空闲等待状态,就需要调用natvieWake函数来唤醒它了,这是一个JNI方法,定义在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中:

    static void android_os_MessageQueue_nativeWake(JNIEnv* env, jobject obj, jint ptr) {
        NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
        return nativeMessageQueue->wake();
    }
            这个JNI层的NativeMessageQueue对象我们在前面分析消息循环的时候创建好的,保存在Java层的MessageQueue对象的mPtr成员变量中,这里把它取回来之后,就调用它的wake函数来唤醒应用程序的主线程,这个函数也是定义在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中:

    void NativeMessageQueue::wake() {
        mLooper->wake();
    }
            这里它又通过成员变量mLooper的wake函数来执行操作,这里的mLooper成员变量是一个C++层实现的Looper对象,它定义在frameworks/base/libs/utils/Looper.cpp文件中:

    void Looper::wake() {
    	......
    
    	ssize_t nWrite;
    	do {
    		nWrite = write(mWakeWritePipeFd, "W", 1);
    	} while (nWrite == -1 && errno == EINTR);
    
    	.......
    }
            这个wake函数很简单,只是通过打开文件描述符mWakeWritePipeFd往管道的写入一个"W"字符串。其实,往管道写入什么内容并不重要,往管道写入内容的目的是为了唤醒应用程序的主线程。前面我们在分析应用程序的消息循环时说到,当应用程序的消息队列中没有消息处理时,应用程序的主线程就会进入空闲等待状态,而这个空闲等待状态就是通过调用这个Looper类的pollInner函数来进入的,具体就是在pollInner函数中调用epoll_wait函数来等待管道中有内容可读的。

            这时候既然管道中有内容可读了,应用程序的主线程就会从这里的Looper类的pollInner函数返回到JNI层的nativePollOnce函数,最后返回到Java层中的MessageQueue.next函数中去,这里它就会发现消息队列中有新的消息需要处理了,于就会处理这个消息。

            3. 消息的处理

            前面在分析消息循环时,说到应用程序的主线程是在Looper类的loop成员函数中进行消息循环过程的,这个函数定义在frameworks/base/core/java/android/os/Looper.java文件中:

    public class Looper {
    	......
    
    	public static final void loop() {
    		Looper me = myLooper();
    		MessageQueue queue = me.mQueue;
    
    		......
    
    		while (true) {
    			Message msg = queue.next(); // might block
    			......
    
    			if (msg != null) {
    				if (msg.target == null) {
    					// No target is a magic identifier for the quit message.
    					return;
    				}
    
    				......
    
    				msg.target.dispatchMessage(msg);
    				
    				......
    
    				msg.recycle();
    			}
    		}
    	}
    
    	......
    }
            它从消息队列中获得消息对象msg后,就会调用它的target成员变量的dispatchMessage函数来处理这个消息。在前面分析消息的发送时说过,这个消息对象msg的成员变量target是在发送消息的时候设置好的,一般就通过哪个Handler来发送消息,就通过哪个Handler来处理消息。

            我们继续以前面分析消息的发送时所举的例子来分析消息的处理过程。前面说到,在Android应用程序启动过程源代码分析这篇文章的Step 30中,ActivityManagerService通过调用ApplicationThread类的scheduleLaunchActivity函数通知应用程序,它可以加载应用程序的默认Activity了,而ApplicationThread类的scheduleLaunchActivity函数最终把这个请求封装成一个消息,然后通过ActivityThread类的成员变量mH来把这个消息加入到应用程序的消息队列中去。现在要对这个消息进行处理了,于是就会调用H类的dispatchMessage函数进行处理。

            H类没有实现自己的dispatchMessage函数,但是它继承了父类Handler的dispatchMessage函数,这个函数定义在frameworks/base/core/java/android/os/ Handler.java文件中:

    public class Handler {
    	......
    
    	public void dispatchMessage(Message msg) {
    		if (msg.callback != null) {
    			handleCallback(msg);
    		} else {
    			if (mCallback != null) {
    				if (mCallback.handleMessage(msg)) {
    					return;
    				}
    			}
    			handleMessage(msg);
    		}
    	}
    
    	......
    }
            这里的消息对象msg的callback成员变量和Handler类的mCallBack成员变量一般都为null,于是,就会调用Handler类的handleMessage函数来处理这个消息,由于H类在继承Handler类时,重写了handleMessage函数,因此,这里调用的实际上是H类的handleMessage函数,这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {  
      
        ......  
      
        private final class H extends Handler {  
      
            ......  
      
            public void handleMessage(Message msg) {  
                ......  
                switch (msg.what) {  
                case LAUNCH_ACTIVITY: {  
                    ActivityClientRecord r = (ActivityClientRecord)msg.obj;  
      
                    r.packageInfo = getPackageInfoNoCheck(  
                        r.activityInfo.applicationInfo);  
                    handleLaunchActivity(r, null);  
                } break;  
                ......  
                }  
      
            ......  
      
        }  
      
        ......  
    }  
             因为前面在分析消息的发送时所举的例子中,发送的消息的类型为H.LAUNCH_ACTIVITY,因此,这里就会调用ActivityThread类的handleLaunchActivity函数来真正地处理这个消息了,后面的具体过程就可以参考Android应用程序启动过程源代码分析这篇文章了。

             至此,我们就从消息循环、消息发送和消息处理三个部分分析完Android应用程序的消息处理机制了,为了更深理解,这里我们对其中的一些要点作一个总结:

             A. Android应用程序的消息处理机制由消息循环、消息发送和消息处理三个部分组成的。

             B. Android应用程序的主线程在进入消息循环过程前,会在内部创建一个Linux管道(Pipe),这个管道的作用是使得Android应用程序主线程在消息队列为空时可以进入空闲等待状态,并且使得当应用程序的消息队列有消息需要处理时唤醒应用程序的主线程。

             C. Android应用程序的主线程进入空闲等待状态的方式实际上就是在管道的读端等待管道中有新的内容可读,具体来说就是是通过Linux系统的Epoll机制中的epoll_wait函数进行的。

             D. 当往Android应用程序的消息队列中加入新的消息时,会同时往管道中的写端写入内容,通过这种方式就可以唤醒正在等待消息到来的应用程序主线程。

             E. 当应用程序主线程在进入空闲等待前,会认为当前线程处理空闲状态,于是就会调用那些已经注册了的IdleHandler接口,使得应用程序有机会在空闲的时候处理一些事情。

    老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注!

    展开全文
  • Android应用程序线程消息循环模型分析

    万次阅读 多人点赞 2017-01-06 14:31:07
    我们知道,Android应用程序是通过消息来驱动的,即在应用程序的主线程(UI线程)中有一个消息循环,负责处理消息队列中的消息。我们也知道,Android应用程序是支持多线程的,即可以创建子线程来执行一些计算型的任务...

            我们知道,Android应用程序是通过消息来驱动的,即在应用程序的主线程(UI线程)中有一个消息循环,负责处理消息队列中的消息。我们也知道,Android应用程序是支持多线程的,即可以创建子线程来执行一些计算型的任务,那么,这些子线程能不能像应用程序的主线程一样具有消息循环呢?这些子线程又能不能往应用程序的主线程中发送消息呢?本文将分析Android应用程序线程消息处理模型,为读者解答这两个问题。

    《Android系统源代码情景分析》一书正在进击的程序员网(http://0xcc0xcd.com)中连载,点击进入!

            在开发Android应用程序中,有时候我们需要在应用程序中创建一些常驻的子线程来不定期地执行一些不需要与应用程序界面交互的计算型的任务。如果这些子线程具有消息循环,那么它们就能够常驻在应用程序中不定期的执行一些计算型任务了:当我们需要用这些子线程来执行任务时,就往这个子线程的消息队列中发送一个消息,然后就可以在子线程的消息循环中执行我们的计算型任务了。我们在前面一篇文章Android系统默认Home应用程序(Launcher)的启动过程源代码分析中,介绍Launcher的启动过程时,在Step 15(LauncherModel.startLoader)中,Launcher就是通过往一个子线程的消息队列中发送一个消息(sWorker.post(mLoaderTask)),然后子线程就会在它的消息循环中处理这个消息的时候执行从PackageManagerService中获取系统中已安装应用程序的信息列表的任务,即调用Step 16中的LoaderTask.run函数。

            在开发Android应用程序中,有时候我们又需要在应用程序中创建一些子线程来执行一些需要与应用程序界面进交互的计算型任务。典型的应用场景是当我们要从网上下载文件时,为了不使主线程被阻塞,我们通常创建一个子线程来负责下载任务,同时,在下载的过程,将下载进度以百分比的形式在应用程序的界面上显示出来,这样就既不会阻塞主线程的运行,又能获得良好的用户体验。但是,我们知道,Android应用程序的子线程是不可以操作主线程的UI的,那么,这个负责下载任务的子线程应该如何在应用程序界面上显示下载的进度呢?如果我们能够在子线程中往主线程的消息队列中发送消息,那么问题就迎刃而解了,因为发往主线程消息队列的消息最终是由主线程来处理的,在处理这个消息的时候,我们就可以在应用程序界面上显示下载进度了。

            上面提到的这两种情况,Android系统都为我们提供了完善的解决方案,前者可以通过使用HandlerThread类来实现,而后者可以使用AsyncTask类来实现,本文就详细这两个类是如何实现的。不过,为了更好地理解HandlerThread类和AsyncTask类的实现,我们先来看看应用程序的主线程的消息循环模型是如何实现的。

            1. 应用程序主线程消息循环模型

            在前面一篇文章Android应用程序进程启动过程的源代码分析一文中,我们已经分析应用程序进程(主线程)的启动过程了,这里主要是针对它的消息循环模型作一个总结。当运行在Android应用程序框架层中的ActivityManagerService决定要为当前启动的应用程序创建一个主线程的时候,它会在ActivityManagerService中的startProcessLocked成员函数调用Process类的静态成员函数start为当前应用程序创建一个主线程:

    public final class ActivityManagerService extends ActivityManagerNative    
            implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {    
        
        ......    
        
        private final void startProcessLocked(ProcessRecord app,    
                    String hostingType, String hostingNameStr) {    
        
            ......    
        
            try {    
                int uid = app.info.uid;    
                int[] gids = null;    
                try {    
                    gids = mContext.getPackageManager().getPackageGids(    
                        app.info.packageName);    
                } catch (PackageManager.NameNotFoundException e) {    
                    ......    
                }    
                    
                ......    
        
                int debugFlags = 0;    
                    
                ......    
                    
                int pid = Process.start("android.app.ActivityThread",    
                    mSimpleProcessManagement ? app.processName : null, uid, uid,    
                    gids, debugFlags, null);    
                    
                ......    
        
            } catch (RuntimeException e) {    
                    
                ......    
        
            }    
        }    
        
        ......    
        
    }    
            这里我们主要关注Process.start函数的第一个参数“android.app.ActivityThread”,它表示要在当前新建的线程中加载android.app.ActivityThread类,并且调用这个类的静态成员函数main作为应用程序的入口点。ActivityThread类定义在frameworks/base/core/java/android/app/ActivityThread.java文件中:

    public final class ActivityThread {  
        ......  
      
        public static final void main(String[] args) {  
            ......
      
            Looper.prepareMainLooper();  
             
            ......  
      
            ActivityThread thread = new ActivityThread();  
            thread.attach(false);  
      
            ...... 
            Looper.loop();  
      
            ...... 
      
            thread.detach();  
            ......  
        }  
      
        ......  
    }  
            在这个main函数里面,除了创建一个ActivityThread实例外,就是在进行消息循环了。

            在进行消息循环之前,首先会通过Looper类的静态成员函数prepareMainLooper为当前线程准备一个消息循环对象。Looper类定义在frameworks/base/core/java/android/os/Looper.java文件中:

    public class Looper {
    	......
    
    	// sThreadLocal.get() will return null unless you've called prepare().
    	private static final ThreadLocal sThreadLocal = new ThreadLocal();
    
    	......
    
    	private static Looper mMainLooper = null;
    
    	......
    
    	public static final void prepare() {
    		if (sThreadLocal.get() != null) {
    			throw new RuntimeException("Only one Looper may be created per thread");
    		}
    		sThreadLocal.set(new Looper());
    	}
    
    	......
    
    	public static final void prepareMainLooper() {
    		prepare();
    		setMainLooper(myLooper());
    		......
    	}
    
    	private synchronized static void setMainLooper(Looper looper) {
    		mMainLooper = looper;
    	}
    
    	public synchronized static final Looper getMainLooper() {
    		return mMainLooper;
    	}
    
    	......
    
    	public static final Looper myLooper() {
    		return (Looper)sThreadLocal.get();
    	}
    
    	......
    }

            Looper类的静态成员函数prepareMainLooper是专门应用程序的主线程调用的,应用程序的其它子线程都不应该调用这个函数来在本线程中创建消息循环对象,而应该调用prepare函数来在本线程中创建消息循环对象,下一节我们介绍一个线程类HandlerThread 时将会看到。

            为什么要为应用程序的主线程专门准备一个创建消息循环对象的函数呢?这是为了让其它地方能够方便地通过Looper类的getMainLooper函数来获得应用程序主线程中的消息循环对象。获得应用程序主线程中的消息循环对象又有什么用呢?一般就是为了能够向应用程序主线程发送消息了。

            在prepareMainLooper函数中,首先会调用prepare函数在本线程中创建一个消息循环对象,然后将这个消息循环对象放在线程局部变量sThreadLocal中:

    sThreadLocal.set(new Looper());
            接着再将这个消息循环对象通过调用setMainLooper函数来保存在Looper类的静态成员变量mMainLooper中:

    mMainLooper = looper;
           这样,其它地方才可以调用getMainLooper函数来获得应用程序主线程中的消息循环对象。

           消息循环对象创建好之后,回到ActivityThread类的main函数中,接下来,就是要进入消息循环了:

     Looper.loop(); 
            Looper类具体是如何通过loop函数进入消息循环以及处理消息队列中的消息,可以参考前面一篇文章Android应用程序消息处理机制(Looper、Handler)分析,这里就不再分析了,我们只要知道ActivityThread类中的main函数执行了这一步之后,就为应用程序的主线程准备好消息循环就可以了。

            2. 应用程序子线程消息循环模型

            在Java框架中,如果我们想在当前应用程序中创建一个子线程,一般就是通过自己实现一个类,这个类继承于Thread类,然后重载Thread类的run函数,把我们想要在这个子线程执行的任务都放在这个run函数里面实现。最后实例这个自定义的类,并且调用它的start函数,这样一个子线程就创建好了,并且会调用这个自定义类的run函数。但是当这个run函数执行完成后,子线程也就结束了,它没有消息循环的概念。

            前面说过,有时候我们需要在应用程序中创建一些常驻的子线程来不定期地执行一些计算型任务,这时候就可以考虑使用Android系统提供的HandlerThread类了,它具有创建具有消息循环功能的子线程的作用。

            HandlerThread类实现在frameworks/base/core/java/android/os/HandlerThread.java文件中,这里我们通过使用情景来有重点的分析它的实现。

            在前面一篇文章Android系统默认Home应用程序(Launcher)的启动过程源代码分析中,我们分析了Launcher的启动过程,其中在Step 15(LauncherModel.startLoader)和Step 16(LoaderTask.run)中,Launcher会通过创建一个HandlerThread类来实现在一个子线程加载系统中已经安装的应用程序的任务:

    public class LauncherModel extends BroadcastReceiver {
    	......
    
    	private LoaderTask mLoaderTask;
    
    	private static final HandlerThread sWorkerThread = new HandlerThread("launcher-loader");
    	static {
    		sWorkerThread.start();
    	}
    	private static final Handler sWorker = new Handler(sWorkerThread.getLooper());
    
    	......
    
    	public void startLoader(Context context, boolean isLaunching) {  
    		......  
    
    		synchronized (mLock) {  
    			......  
    
    			// Don't bother to start the thread if we know it's not going to do anything  
    			if (mCallbacks != null && mCallbacks.get() != null) {  
    				......
    
    				mLoaderTask = new LoaderTask(context, isLaunching);  
    				sWorker.post(mLoaderTask);  
    			}  
    		}  
    	}  
    
    	......
    
    	private class LoaderTask implements Runnable {  
    		......  
    
    		public void run() {  
    			......  
    
    			keep_running: {  
    				......  
    
    				// second step  
    				if (loadWorkspaceFirst) {  
    					......  
    					loadAndBindAllApps();  
    				} else {  
    					......  
    				}  
    
    				......  
    			}  
    
    			......  
    		}  
    
    		......  
    	} 
    
    	......
    }
            在这个LauncherModel类中,首先创建了一个HandlerThread对象:

    private static final HandlerThread sWorkerThread = new HandlerThread("launcher-loader");
            接着调用它的start成员函数来启动一个子线程:

    static {
        sWorkerThread.start();
    }
            接着还通过这个HandlerThread对象的getLooper函数来获得这个子线程中的消息循环对象,并且使用这个消息循环创建对象来创建一个Handler:

    private static final Handler sWorker = new Handler(sWorkerThread.getLooper());
            有了这个Handler对象sWorker之后,我们就可以往这个子线程中发送消息,然后在处理这个消息的时候执行加载系统中已经安装的应用程序的任务了,在startLoader函数中:

    mLoaderTask = new LoaderTask(context, isLaunching);  
    sWorker.post(mLoaderTask);  
            这里的mLoaderTask是一个LoaderTask对象,它实现了Runnable接口,因此,可以把这个LoaderTask对象作为参数传给sWorker.post函数。在sWorker.post函数里面,会把这个LoaderTask对象封装成一个消息,并且放入这个子线程的消息队列中去。当这个子线程的消息循环处理这个消息的时候,就会调用这个LoaderTask对象的run函数,因此,我们就可以在LoaderTask对象的run函数中通过调用loadAndBindAllApps来执行加载系统中已经安装的应用程序的任务了。

            了解了HanderThread类的使用方法之后,我们就可以重点地来分析它的实现了:

    public class HandlerThread extends Thread {
    	......
    	private Looper mLooper;
    
    	public HandlerThread(String name) {
    		super(name);
    		......
    	}
    
    	......
    
    	public void run() {
    		......
    		Looper.prepare();
    		synchronized (this) {
    			mLooper = Looper.myLooper();
    			......
    		}
    		......
    		Looper.loop();
    		......
    	}
    
    	public Looper getLooper() {
    		......
    		return mLooper;
    	}
    
    	......
    }
            首先我们看到的是,HandlerThread类继承了Thread类,因此,通过它可以在应用程序中创建一个子线程,其次我们看到在它的run函数中,会进入一个消息循环中,因此,这个子线程可以常驻在应用程序中,直到它接收收到一个退出消息为止。

            在run函数中,首先是调用Looper类的静态成员函数prepare来准备一个消息循环对象:

    Looper.prepare();
            然后通过Looper类的myLooper成员函数将这个子线程中的消息循环对象保存在HandlerThread类中的成员变量mLooper中:

    mLooper = Looper.myLooper();
            这样,其它地方就可以方便地通过它的getLooper函数来获得这个消息循环对象了,有了这个消息循环对象后,就可以往这个子线程的消息队列中发送消息,通知这个子线程执行特定的任务了。

            最在这个run函数通过Looper类的loop函数进入消息循环中:

    Looper.loop();
            这样,一个具有消息循环的应用程序子线程就准备就绪了。

            HandlerThread类的实现虽然非常简单,当然这得益于Java提供的Thread类和Android自己本身提供的Looper类,但是它的想法却非常周到,为应用程序开发人员提供了很大的方便。
            3. 需要与UI交互的应用程序子线程消息模型

            前面说过,我们开发应用程序的时候,经常中需要创建一个子线程来在后台执行一个特定的计算任务,而在这个任务计算的过程中,需要不断地将计算进度或者计算结果展现在应用程序的界面中。典型的例子是从网上下载文件,为了不阻塞应用程序的主线程,我们开辟一个子线程来执行下载任务,子线程在下载的同时不断地将下载进度在应用程序界面上显示出来,这样做出来程序就非常友好。由于子线程不能直接操作应用程序的UI,因此,这时候,我们就可以通过往应用程序的主线程中发送消息来通知应用程序主线程更新界面上的下载进度。因为类似的这种情景在实际开发中经常碰到,Android系统为开发人员提供了一个异步任务类(AsyncTask)来实现上面所说的功能,即它会在一个子线程中执行计算任务,同时通过主线程的消息循环来获得更新应用程序界面的机会。

            为了更好地分析AsyncTask的实现,我们先举一个例子来说明它的用法。在前面一篇文章Android系统中的广播(Broadcast)机制简要介绍和学习计划中,我们开发了一个应用程序Broadcast,其中使用了AsyncTask来在一个线程在后台在执行计数任务,计数过程通过广播(Broadcast)来将中间结果在应用程序界面上显示出来。在这个例子中,使用广播来在应用程序主线程和子线程中传递数据不是最优的方法,当时只是为了分析Android系统的广播机制而有意为之的。在本节内容中,我们稍微这个例子作一个简单的修改,就可以通过消息的方式来将计数过程的中间结果在应用程序界面上显示出来。

            为了区别Android系统中的广播(Broadcast)机制简要介绍和学习计划一文中使用的应用程序Broadcast,我们将本节中使用的应用程序命名为Counter。首先在Android源代码工程中创建一个Android应用程序工程,名字就为Counter,放在packages/experimental目录下。关于如何获得Android源代码工程,请参考在Ubuntu上下载、编译和安装Android最新源代码一文;关于如何在Android源代码工程中创建应用程序工程,请参考在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务一文。这个应用程序工程定义了一个名为shy.luo.counter的package,这个例子的源代码主要就是实现在这个目录下的Counter.java文件中:

    package shy.luo.counter;
    
    import android.app.Activity;
    import android.content.ComponentName;
    import android.content.Context;
    import android.content.Intent;
    import android.content.IntentFilter;
    import android.os.Bundle;
    import android.os.AsyncTask;
    import android.util.Log;
    import android.view.View;
    import android.view.View.OnClickListener;
    import android.widget.Button;
    import android.widget.TextView;
    
    public class Counter extends Activity implements OnClickListener {
    	private final static String LOG_TAG = "shy.luo.counter.Counter";
    
    	private Button startButton = null;
    	private Button stopButton = null;
    	private TextView counterText = null;
    
    	private AsyncTask<Integer, Integer, Integer> task = null;
    	private boolean stop = false;
    
    	@Override
    	public void onCreate(Bundle savedInstanceState) {
    		super.onCreate(savedInstanceState);
    		setContentView(R.layout.main);
    
    		startButton = (Button)findViewById(R.id.button_start);
    		stopButton = (Button)findViewById(R.id.button_stop);
    		counterText = (TextView)findViewById(R.id.textview_counter);
    
    		startButton.setOnClickListener(this);
    		stopButton.setOnClickListener(this);
    
    		startButton.setEnabled(true);
    		stopButton.setEnabled(false);
    
    
    		Log.i(LOG_TAG, "Main Activity Created.");
    	}
    
    
    	@Override
    	public void onClick(View v) {
    		if(v.equals(startButton)) {
    			if(task == null) {
    				task = new CounterTask();
    				task.execute(0);
    
    				startButton.setEnabled(false);
    				stopButton.setEnabled(true);
    			}
    		} else if(v.equals(stopButton)) {
    			if(task != null) {
    				stop = true;
    				task = null;
    
    				startButton.setEnabled(true);
    				stopButton.setEnabled(false);
    			}
    		}
    	}
    
    	class CounterTask extends AsyncTask<Integer, Integer, Integer> {
    		@Override
    		protected Integer doInBackground(Integer... vals) {
    			Integer initCounter = vals[0];
    
    			stop = false;
    			while(!stop) {
    				publishProgress(initCounter);
    
    				try {
    					Thread.sleep(1000);
    				} catch (InterruptedException e) {
    					e.printStackTrace();
    				}
    
    				initCounter++;
    			}
    
    			return initCounter;
    		}
    
    		@Override
    		protected void onProgressUpdate(Integer... values) {
    			super.onProgressUpdate(values);
    
    			String text = values[0].toString();
    			counterText.setText(text);
    		}
    
    		@Override
    		protected void onPostExecute(Integer val) {
    			String text = val.toString();
    			counterText.setText(text);
    		}
    	};
    }
            这个计数器程序很简单,它在界面上有两个按钮Start和Stop。点击Start按钮时,便会创建一个CounterTask实例task,然后调用它的execute函数就可以在应用程序中启动一个子线程,并且通过调用这个CounterTask类的doInBackground函数来执行计数任务。在计数的过程中,会通过调用publishProgress函数来将中间结果传递到onProgressUpdate函数中去,在onProgressUpdate函数中,就可以把中间结果显示在应用程序界面了。点击Stop按钮时,便会通过设置变量stop为true,这样,CounterTask类的doInBackground函数便会退出循环,然后将结果返回到onPostExecute函数中去,在onPostExecute函数,会把最终计数结果显示在用程序界面中。

           在这个例子中,我们需要注意的是:

           A. CounterTask类继承于AsyncTask类,因此它也是一个异步任务类;

           B. CounterTask类的doInBackground函数是在后台的子线程中运行的,这时候它不可以操作应用程序的界面;

           C. CounterTask类的onProgressUpdate和onPostExecute两个函数是应用程序的主线程中执行,它们可以操作应用程序的界面。

           关于C这一点的实现原理,我们在后面会分析到,这里我们先完整地介绍这个例子,以便读者可以参考做一下实验。

           接下来我们再看看应用程序的配置文件AndroidManifest.xml:

    <?xml version="1.0" encoding="utf-8"?>
    <manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="shy.luo.counter"
          android:versionCode="1"
          android:versionName="1.0">
        <application android:icon="@drawable/icon" android:label="@string/app_name">
            <activity android:name=".Counter"
                      android:label="@string/app_name">
                <intent-filter>
                    <action android:name="android.intent.action.MAIN" />
                    <category android:name="android.intent.category.LAUNCHER" />
                </intent-filter>
            </activity>
        </application>
    </manifest>
           这个配置文件很简单,我们就不介绍了。

           再来看应用程序的界面文件,它定义在res/layout/main.xml文件中:

    <?xml version="1.0" encoding="utf-8"?>  
    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"  
        android:orientation="vertical"  
        android:layout_width="fill_parent"  
        android:layout_height="fill_parent"   
        android:gravity="center">  
        <LinearLayout  
            android:layout_width="fill_parent"  
            android:layout_height="wrap_content"  
            android:layout_marginBottom="10px"  
            android:orientation="horizontal"   
            android:gravity="center">  
            <TextView    
            android:layout_width="wrap_content"   
                android:layout_height="wrap_content"   
                android:layout_marginRight="4px"  
                android:gravity="center"  
                android:text="@string/counter">  
            </TextView>  
            <TextView    
                android:id="@+id/textview_counter"  
            android:layout_width="wrap_content"   
                android:layout_height="wrap_content"   
                android:gravity="center"  
                android:text="0">  
            </TextView>  
        </LinearLayout>  
        <LinearLayout  
            android:layout_width="fill_parent"  
            android:layout_height="wrap_content"  
            android:orientation="horizontal"   
            android:gravity="center">  
            <Button   
                android:id="@+id/button_start"  
                android:layout_width="wrap_content"  
                android:layout_height="wrap_content"  
                android:gravity="center"  
                android:text="@string/start">  
            </Button>  
            <Button   
                android:id="@+id/button_stop"  
                android:layout_width="wrap_content"  
                android:layout_height="wrap_content"  
                android:gravity="center"  
                android:text="@string/stop" >  
            </Button>  
         </LinearLayout>    
    </LinearLayout>  
           这个界面配置文件也很简单,等一下我们在模拟器把这个应用程序启动起来后,就可以看到它的截图了。

           应用程序用到的字符串资源文件位于res/values/strings.xml文件中:

    <?xml version="1.0" encoding="utf-8"?>  
    <resources>  
        <string name="app_name">Counter</string>  
        <string name="counter">Counter: </string>  
        <string name="start">Start Counter</string>  
        <string name="stop">Stop Counter</string>  
    </resources> 
           最后,我们还要在工程目录下放置一个编译脚本文件Android.mk:

    LOCAL_PATH:= $(call my-dir)        
    include $(CLEAR_VARS)        
            
    LOCAL_MODULE_TAGS := optional        
            
    LOCAL_SRC_FILES := $(call all-subdir-java-files)        
            
    LOCAL_PACKAGE_NAME := Counter        
            
    include $(BUILD_PACKAGE)  
           接下来就要编译了。有关如何单独编译Android源代码工程的模块,以及如何打包system.img,请参考如何单独编译Android源代码中的模块一文。
           执行以下命令进行编译和打包:

    USER-NAME@MACHINE-NAME:~/Android$ mmm packages/experimental/Counter          
    USER-NAME@MACHINE-NAME:~/Android$ make snod
           这样,打包好的Android系统镜像文件system.img就包含我们前面创建的Counter应用程序了。
           再接下来,就是运行模拟器来运行我们的例子了。关于如何在Android源代码工程中运行模拟器,请参考在Ubuntu上下载、编译和安装Android最新源代码一文。
           执行以下命令启动模拟器:
    USER-NAME@MACHINE-NAME:~/Android$ emulator 
           最后我们就可以在Launcher中找到Counter应用程序图标,把它启动起来,点击Start按钮,就会看到应用程序界面上的计数器跑起来了:


            这样,使用AsyncTask的例子就介绍完了,下面,我们就要根据上面对AsyncTask的使用情况来重点分析它的实现了。

            AsyncTask类定义在frameworks/base/core/java/android/os/AsyncTask.java文件中:

    public abstract class AsyncTask<Params, Progress, Result> {
    	......
    
    	private static final BlockingQueue<Runnable> sWorkQueue =
    			new LinkedBlockingQueue<Runnable>(10);
    
    	private static final ThreadFactory sThreadFactory = new ThreadFactory() {
    		private final AtomicInteger mCount = new AtomicInteger(1);
    
    		public Thread newThread(Runnable r) {
    			return new Thread(r, "AsyncTask #" + mCount.getAndIncrement());
    		}
    	};
    
    	......
    
    	private static final ThreadPoolExecutor sExecutor = new ThreadPoolExecutor(CORE_POOL_SIZE,
    		MAXIMUM_POOL_SIZE, KEEP_ALIVE, TimeUnit.SECONDS, sWorkQueue, sThreadFactory);
    
    	private static final int MESSAGE_POST_RESULT = 0x1;
    	private static final int MESSAGE_POST_PROGRESS = 0x2;
    	private static final int MESSAGE_POST_CANCEL = 0x3;
    
    	private static final InternalHandler sHandler = new InternalHandler();
    
    	private final WorkerRunnable<Params, Result> mWorker;
    	private final FutureTask<Result> mFuture;
    
    	......
    
    	public AsyncTask() {
    		mWorker = new WorkerRunnable<Params, Result>() {
    			public Result call() throws Exception {
    				......
    				return doInBackground(mParams);
    			}
    		};
    
    		mFuture = new FutureTask<Result>(mWorker) {
    			@Override
    			protected void done() {
    				Message message;
    				Result result = null;
    
    				try {
    					result = get();
    				} catch (InterruptedException e) {
    					android.util.Log.w(LOG_TAG, e);
    				} catch (ExecutionException e) {
    					throw new RuntimeException("An error occured while executing doInBackground()",
    						e.getCause());
    				} catch (CancellationException e) {
    					message = sHandler.obtainMessage(MESSAGE_POST_CANCEL,
    						new AsyncTaskResult<Result>(AsyncTask.this, (Result[]) null));
    					message.sendToTarget();
    					return;
    				} catch (Throwable t) {
    					throw new RuntimeException("An error occured while executing "
    						+ "doInBackground()", t);
    				}
    
    				message = sHandler.obtainMessage(MESSAGE_POST_RESULT,
    					new AsyncTaskResult<Result>(AsyncTask.this, result));
    				message.sendToTarget();
    			}
    		};
    	}
    
    	......
    
    	public final Result get() throws InterruptedException, ExecutionException {
    		return mFuture.get();
    	}
    
    	......
    
    	public final AsyncTask<Params, Progress, Result> execute(Params... params) {
    		......
    
    		mWorker.mParams = params;
    		sExecutor.execute(mFuture);
    
    		return this;
    	}
    
    	......
    
    	protected final void publishProgress(Progress... values) {
    		sHandler.obtainMessage(MESSAGE_POST_PROGRESS,
    			new AsyncTaskResult<Progress>(this, values)).sendToTarget();
    	}
    
            private void finish(Result result) {
                    ......
                    onPostExecute(result);
                    ......
            }
    
    	......
    
    	private static class InternalHandler extends Handler {
    		@SuppressWarnings({"unchecked", "RawUseOfParameterizedType"})
    		@Override
    		public void handleMessage(Message msg) {
    			AsyncTaskResult result = (AsyncTaskResult) msg.obj;
    			switch (msg.what) {
    		        case MESSAGE_POST_RESULT:
    			     // There is only one result
    			     result.mTask.finish(result.mData[0]);
    			     break;
    		        case MESSAGE_POST_PROGRESS:
    			     result.mTask.onProgressUpdate(result.mData);
    			     break;
    		        case MESSAGE_POST_CANCEL:
    			     result.mTask.onCancelled();
    			     break;
    			}
    		}
    	}
    
    	private static abstract class WorkerRunnable<Params, Result> implements Callable<Result> {
    		Params[] mParams;
    	}
    
    	private static class AsyncTaskResult<Data> {
    		final AsyncTask mTask;
    		final Data[] mData;
    
    		AsyncTaskResult(AsyncTask task, Data... data) {
    			mTask = task;
    			mData = data;
    		}
    	}
    }

            从AsyncTask的实现可以看出,当我们第一次创建一个AsyncTask对象时,首先会执行下面静态初始化代码创建一个线程池sExecutor:

    private static final BlockingQueue<Runnable> sWorkQueue =
    	new LinkedBlockingQueue<Runnable>(10);
    
    private static final ThreadFactory sThreadFactory = new ThreadFactory() {
    	private final AtomicInteger mCount = new AtomicInteger(1);
    
    	public Thread newThread(Runnable r) {
    		return new Thread(r, "AsyncTask #" + mCount.getAndIncrement());
    	}
    };
    
    ......
    
    private static final ThreadPoolExecutor sExecutor = new ThreadPoolExecutor(CORE_POOL_SIZE,
    	MAXIMUM_POOL_SIZE, KEEP_ALIVE, TimeUnit.SECONDS, sWorkQueue, sThreadFactory);
            这里的ThreadPoolExecutor是Java提供的多线程机制之一,这里用的构造函数原型为:

    ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, 
        BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory)
            各个参数的意义如下:

            corePoolSize -- 线程池的核心线程数量

            maximumPoolSize -- 线程池的最大线程数量

            keepAliveTime -- 若线程池的线程数数量大于核心线程数量,那么空闲时间超过keepAliveTime的线程将被回收

            unit -- 参数keepAliveTime使用的时间单位

            workerQueue -- 工作任务队列

            threadFactory -- 用来创建线程池中的线程
            简单来说,ThreadPoolExecutor的运行机制是这样的:每一个工作任务用一个Runnable对象来表示,当我们要把一个工作任务交给这个线程池来执行的时候,就通过调用ThreadPoolExecutor的execute函数来把这个工作任务加入到线程池中去。此时,如果线程池中的线程数量小于corePoolSize,那么就会调用threadFactory接口来创建一个新的线程并且加入到线程池中去,再执行这个工作任务;如果线程池中的线程数量等于corePoolSize,但是工作任务队列workerQueue未满,则把这个工作任务加入到工作任务队列中去等待执行;如果线程池中的线程数量大于corePoolSize,但是小于maximumPoolSize,并且工作任务队列workerQueue已经满了,那么就会调用threadFactory接口来创建一个新的线程并且加入到线程池中去,再执行这个工作任务;如果线程池中的线程量已经等于maximumPoolSize了,并且工作任务队列workerQueue也已经满了,这个工作任务就被拒绝执行了。

            创建好了线程池后,再创建一个消息处理器:

    private static final InternalHandler sHandler = new InternalHandler();
            注意,这行代码是在应用程序的主线程中执行的,因此,这个消息处理器sHandler内部引用的消息循环对象looper是应用程序主线程的消息循环对象,消息处理器的实现机制具体可以参考前面一篇文章Android应用程序消息处理机制(Looper、Handler)分析

            AsyncTask类的静态初始化代码执行完成之后,才开始创建AsyncTask对象,即执行AsyncTask类的构造函数:

    public AsyncTask() {
    	mWorker = new WorkerRunnable<Params, Result>() {
    		public Result call() throws Exception {
    			......
    			return doInBackground(mParams);
    		}
    	};
    
    	mFuture = new FutureTask<Result>(mWorker) {
    		@Override
    		protected void done() {
    			Message message;
    			Result result = null;
    
    			try {
    				result = get();
    			} catch (InterruptedException e) {
    				android.util.Log.w(LOG_TAG, e);
    			} catch (ExecutionException e) {
    				throw new RuntimeException("An error occured while executing doInBackground()",
    					e.getCause());
    			} catch (CancellationException e) {
    				message = sHandler.obtainMessage(MESSAGE_POST_CANCEL,
    					new AsyncTaskResult<Result>(AsyncTask.this, (Result[]) null));
    				message.sendToTarget();
    				return;
    			} catch (Throwable t) {
    				throw new RuntimeException("An error occured while executing "
    					+ "doInBackground()", t);
    			}
    
    			message = sHandler.obtainMessage(MESSAGE_POST_RESULT,
    				new AsyncTaskResult<Result>(AsyncTask.this, result));
    			message.sendToTarget();
    		}
    	};
    }
            在AsyncTask类的构造函数里面,主要是创建了两个对象,分别是一个WorkerRunnable对象mWorker和一个FutureTask对象mFuture。

            WorkerRunnable类实现了Callable接口,此外,它的内部成员变量mParams用于保存从AsyncTask对象的execute函数传进来的参数列表:

    private static abstract class WorkerRunnable<Params, Result> implements Callable<Result> {
    	Params[] mParams;
    }
            FutureTask类也实现了Runnable接口,所以它可以作为一个工作任务通过调用AsyncTask类的execute函数添加到sExecuto线程池中去:

    public final AsyncTask<Params, Progress, Result> execute(Params... params) {
    	......
    
    	mWorker.mParams = params;
    	sExecutor.execute(mFuture);
    
    	return this;
    }

           这里的FutureTask对象mFuture是用来封装前面的WorkerRunnable对象mWorker。当mFuture加入到线程池中执行时,它调用的是mWorker对象的call函数:

    mWorker = new WorkerRunnable<Params, Result>() {
    	public Result call() throws Exception {
    	       ......
    	       return doInBackground(mParams);
            }
    };
            在call函数里面,会调用AsyncTask类的doInBackground函数来执行真正的任务,这个函数是要由AsyncTask的子类来实现的,注意,这个函数是在应用程序的子线程中执行的,它不可以操作应用程序的界面。

            我们可以通过mFuture对象来操作当前执行的任务,例如查询当前任务的状态,它是正在执行中,还是完成了,还是被取消了,如果是完成了,还可以通过它获得任务的执行结果,如果还没有完成,可以取消任务的执行。

            当工作任务mWorker执行完成的时候,mFuture对象中的done函数就会被被调用,根据任务的完成状况,执行相应的操作,例如,如果是因为异常而完成时,就会抛异常,如果是正常完成,就会把任务执行结果封装成一个AsyncTaskResult对象:

    private static class AsyncTaskResult<Data> {
    	final AsyncTask mTask;
    	final Data[] mData;
    
    	AsyncTaskResult(AsyncTask task, Data... data) {
    		mTask = task;
    		mData = data;
    	}
    }
            其中,成员变量mData保存的是任务执行结果,而成员变量mTask指向前面我们创建的AsyncTask对象。
            最后把这个AsyncTaskResult对象封装成一个消息,并且通过消息处理器sHandler加入到应用程序主线程的消息队列中:

    message = sHandler.obtainMessage(MESSAGE_POST_RESULT,
    	new AsyncTaskResult<Result>(AsyncTask.this, result));
    message.sendToTarget();
            这个消息最终就会在InternalHandler类的handleMessage函数中处理了:

    private static class InternalHandler extends Handler {
    	@SuppressWarnings({"unchecked", "RawUseOfParameterizedType"})
    	@Override
    	public void handleMessage(Message msg) {
    		AsyncTaskResult result = (AsyncTaskResult) msg.obj;
    		switch (msg.what) {
    		case MESSAGE_POST_RESULT:
    			// There is only one result
    			result.mTask.finish(result.mData[0]);
    			break;
    		......
    		}
    	}
    }
            在这个函数里面,最终会调用前面创建的这个AsyncTask对象的finish函数来进一步处理:

    private void finish(Result result) {
           ......
           onPostExecute(result);
           ......
    }
            这个函数调用AsyncTask类的onPostExecute函数来进一步处理,AsyncTask类的onPostExecute函数一般是要由其子类来重载的,注意,这个函数是在应用程序的主线程中执行的,因此,它可以操作应用程序的界面。
            在任务执行的过程当中,即执行doInBackground函数时候,可能通过调用publishProgress函数来将中间结果封装成一个消息发送到应用程序主线程中的消息队列中去:

    protected final void publishProgress(Progress... values) {
    	sHandler.obtainMessage(MESSAGE_POST_PROGRESS,
    		new AsyncTaskResult<Progress>(this, values)).sendToTarget();
    }
            这个消息最终也是由InternalHandler类的handleMessage函数来处理的:

    private static class InternalHandler extends Handler {
    	@SuppressWarnings({"unchecked", "RawUseOfParameterizedType"})
    	@Override
    	public void handleMessage(Message msg) {
    		AsyncTaskResult result = (AsyncTaskResult) msg.obj;
    		switch (msg.what) {
    		......
    		case MESSAGE_POST_PROGRESS:
    			     result.mTask.onProgressUpdate(result.mData);
    			     break;
    		......
    		}
    	}
    }
            这里它调用前面创建的AsyncTask对象的onPorgressUpdate函数来进一步处理,这个函数一般是由AsyncTask的子类来实现的,注意,这个函数是在应用程序的主线程中执行的,因此,它和前面的onPostExecute函数一样,可以操作应用程序的界面。

           这样,AsyncTask类的主要实现就介绍完了,结合前面开发的应用程序Counter来分析,会更好地理解它的实现原理。

           至此,Android应用程序线程消息循环模型就分析完成了,理解它有利于我们在开发Android应用程序时,能够充分利用多线程的并发性来提高应用程序的性能以及获得良好的用户体验。

    老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注!

    展开全文
  • 在前文中,我们简要介绍了Android应用程序窗口的框架。Android应用程序窗口在运行的过程中,需要访问一些特定的资源或者类。这些特定的资源或者类构成了Android应用程序的运行上下文环境,Android应用程序窗口可以...
  • Android 会同一系列核心应用程序包一起发布,该应用程序包包括 email 客户端, SMS 短消息程序,日历, 地图,浏览器,联系人管理程序等。所有的应用程序都是使用 JAVA 语言编写的。 应用程序框架 开发人员也可以...
  • Android应用程序资源的编译和打包过程分析

    万次阅读 多人点赞 2017-01-06 12:50:10
    我们知道,在一个APK文件中,除了有代码文件之外,还有很多资源文件。这些资源文件是通过Android...在本文中,我们就详细分析XML资源文件的编译和打包过程,为后面深入了解Android系统的资源管理框架打下坚实的基础。
  • 在前面一篇文章中,我们分析了Android应用程序资源的编译和打包过程,最终得到的应用程序资源就与应用程序代码一起打包在一个APK文件中。Android应用程序在运行的过程中,是通过一个称为AssetManager的资源管理器来...
  • 解开Android应用程序组件Activity的"singleTask"之谜

    万次阅读 多人点赞 2017-01-06 14:32:03
    Android应用程序中,可以配置Activity以四种方式来启动,其中最令人迷惑的就是"singleTask"这种方式了,官方... 在解开这个谜之前,我们先来简单了解一下在Android应用程序中,任务(Task)是个什么样的概念。我们
  • Android应用程序资源的查找过程分析

    万次阅读 多人点赞 2017-01-06 12:49:51
    我们知道,在Android系统中,每一个应用程序一般都会配置很多资源,用来适配不同密度、大小和方向的屏幕,以及适配不同的国家、地区和语言等等。这些资源是在应用程序运行时自动根据设备的当前配置信息进行适配的。...
  • 对Android应用程序来说,订阅消息其实就是注册广播接收器,本文将探讨Android应用程序是如何注册广播接收器以及把广播接收器注册到哪里去的。 在Android的广播机制中,ActivityManagerService扮演着广播中心的...
  • Android应用程序进程管理

    千次下载 热门讨论 2020-07-30 10:19:45
    这个PPT讲Android应用程序进程的启动和回收,主要涉及到Zygote进程、System Server进程,以及组件管理服务ActivityManagerService、窗口服务WindowManagerService,还有专用驱动Low Memory Killer。通过了解Android...
  • Android应用程序键盘(Keyboard)消息处理机制分析

    万次阅读 多人点赞 2017-01-06 14:31:14
    在上一篇文章《Android应用程序消息处理机制(Looper、Handler)分析》中,我们分析了Android应用程序的消息处理机制,本文将结合这种消息处理机制来详细分析Android应用程序是如何获得键盘按键消息的。
  • Android经典应用程序开发

    千次阅读 2012-02-20 15:48:43
    Android经典应用程序开发 韩超 编著 ISBN978-7-121-15586-4 2012年2月出版 定价:59.00元 16开 428页 宣传语:具有清晰的主线,知识点全面,内容简洁实用 理论,文档和代码三者结合,以通用理念指引Android...
  • Android应用程序组件Content Provider应用实例

    万次阅读 多人点赞 2017-01-06 14:32:12
    上文简要介绍了Android应用程序组件Content Provider在应用程序间共享数据的原理,但是没有进一步研究它的实现。本文将实现两个应用程序,其中一个以Content Provider的形式来提供数据访问入口,另一个通过这个...
  • 一点关于Android应用程序发布过程的东西,用来告诉那些想发布自己的应用程序的朋友们,在发布过程中会遇到哪些的事情。 (1) 发布应用程序之前,首先要做的事是为你的应用做数字化签名认证。在Google的Android...
  • 官方文档原文地址应用程序原理Android应用程序是通过Java编程语言来写。Android软件开发工具把你的代码和其他数据、资源文件一起编译、打包成一个APK文件,这个文档以.apk为后缀,保存了一个Android应用程序所有的...
  • 从前文可知道,每一个Activity组件都有一个关联的Window对象,用来描述一个应用程序窗口。每一个应用程序窗口内部又包含有一个View对象,用来描述应用程序窗口的视图。应用程序窗口视图是真正用来实现UI内容和布局的...
  • Android应用程序运行原理(部分)

    千次阅读 2011-02-19 20:15:00
    应用程序运行原理(Application Fundamentals) Android 的应用程序是由Java语言编写。... 在很多情况下,单个的Android应用程序都有其独自的运行空间: · 默认情况下,所有的应用程序都在其
  • android应用程序版本介绍

    千次阅读 2011-05-05 09:06:00
    <br /> 用户需要了解安装到设备上的应用程序的版本信息,以及了解哪些版本可以进行升级。其它应用程序——包括你发布的其它程序——需要向系统查询你的应用程序的版本,来确定相互之间的兼容性。你的应用...
1 2 3 4 5 ... 20
收藏数 126,039
精华内容 50,415
关键字:

对android应用程序了解