EditText 限定中文8个英文16个的解决方法。在EditText上控件提供的属性中有限定最大最小长度的方法。可是，对于输入时，限定中文8个英文16个时，怎么办？相当于一个中文的长度是两个英文的长度。原理就不说了。自己看一下android的源代码。以上直接上代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

private final int maxLen = 16;
private InputFilter filter = new InputFilter() {@Override
    public CharSequence filter(CharSequence source, int start, int end, Spanned dest, int dstart, int dend) {int dindex = 0;
        int count = 0;
        while (count <= maxLen && dindex < dest.length()) {char c = dest.charAt(dindex++);
            if (c < 128) {count = count + 1;
            } else {count = count + 2;
            }}if (count > maxLen) {return dest.subSequence(0, dindex - 1);
        }int sindex = 0;
        while (count <= maxLen && sindex < source.length()) {char c = source.charAt(sindex++);
            if (c < 128) {count = count + 1;
            } else {count = count + 2;
            }}if (count > maxLen) {sindex--;
        }return source.subSequence(0, sindex);
    }};

使用例如以下：

1

editText.setFilters(new InputFilter[]{filter});

1.onStart 和 onResume、onPause和onStop从描述上来看差不多，对我们来说有什么实质的不同？
onStart 和 onStop是从Activity是否可见这个角度来回调的，而onResume和onPause是从Activity是否位于前台这个角度来回调的，除了这种区别，没有其他区别

2.假设当前Activity为A，如果这时用户打开一个新Activity B，那么 B 的onResume()和 A 的onPaus()哪个先执行呢？
启动Activity的请求会由Instrumentation来处理，然后它通过Binder向AMS发请求，AMS内部维护着一个ActivityStack并负责栈内的Activvity的状态，AMS通过
ActivityThread去同步Activity的状态从而完成生命周期方法的调用。在ActivityStack中的resumeTopActivityInnerLocked方法中，在新Acctivity启动之前，
栈顶的Activity需要先onPause()后，新Activity才能启动。最终在ActivityStackSupervisor中的realStartActivityLocked方法会调用scheduleLaunchActivity，
接着完成新Activity的onCreate、onStart、onResume的调用过程。因此，可以得到结论，是旧Activity先onPause，然后新Activity再启动。

3.Activity被销毁并重建后，我们去获取之前的存储字符串，接受的位置可以是onRestoreInstanceState 或者 onCreate 方法，两者区别是？
onRestoreInstanceState一旦被调用，其参数Bundle savedInstanceState 一定是有值的，我们不用额外的拍断是否为空；
但是onCreate不行，onCreate如果正常启动的话，其参数Bundle savedInstanceState为null, 所以必须要额外判断。

4.onSaveInstanceState和onRestoreInstanceState，在正常流程下会出发么？
系统只在Activity异常种植的时候才会调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据，其他情况不会出发这个过程。

5.比如目前任务栈S1中的情况为ABC，这个时候Activity D 以singleTask模式请求启动，其所需要的任务栈为 S2，由于S2和D的实例均不存在，所以系统会先创建
任务栈S2，然后在创建D的实例并将其入栈到S2.

6.TaskAffinity任务相关性。
这个参数标识一个Activity所需要的任务栈的名字，默认情况下，所有Activity所需的任务栈的名字为应用的包名。可以为每个Activity都单独制定TaskAffinity属性，
这个属性必须不能和包名相同，否则就相当于没有制定。TaskAffinity属性主要和singleTask启动模式或者allTaskReparenting属性配对使用。当TaskAffinity和singleTask启动模式配对使用的时候，它是具有该模式的Activity的目前任务栈的名字，待启动的Activity回运行在名字和TaskAffinity相同的任务栈中。
当TaskAffinity和allowTaskReparenting结合的时候，会产生特殊的效果。当一个应用A启动了应用B的某个Activity后，如果这个Activity的allTaskReparenting属性为true的话，那么当应用B被启动后，词Activity回直接从应用A的任务栈转移到应用B的任务栈中。

7.SharedPerences是否安全？
SharedPreferences不支持两个进程同时去执行写操作，否则会导致一定几率的数据丢失，因为SharedPreferences底层是通过读/写XML文件来实现的，并发会出问题。
每个应用的SharedPreferences文件都在当前包所在的data目录下查看到，目录位于 /data/data/pacakage name/shared_prefs目录下。
SharedPreferences也属于文件的一种，但是由于系统对他的读/写有一定的缓存策略，即在内存中有一份ShareePreferences文件的缓存，因此在多进程下，系统对它的读写诗不可靠的，当面对高并发的读/写访问，有很大几率丢失文件。

8.Serializable接口的原理及serialVersionUID作用？
想让一个对象实现序列化，只需要这个类实现Serializable接口并声明一个serialVersionUID即可。实际上，甚至连这个serialVersionUID也不是必须的。如何进行对象的序列化和反序列化也很简单，只需要采用ObjectOutputStream和ObjectInputStream，readObject()writeObject()函数。
serialVersionUID是用来辅助序列化和反序列化过程的，原则上序列化后的数据中的serialVersionUID只有和当前累的serialVersionUID相同时才能够正常的被反序列化。
serialVersionUID的详细工作机制时这样的：序列化的时候系统把当前类的serialVersionUID写入序列化文件中，当反序列化时候系统回去检测文件中的serialVersionUID，看它是否和当前类的serialVersionUID一致，如果一致就说明序列化的类的版本和当前类的版本时相同的，这个时候可以成功反序列化；否则就说明当前类和序列化的类相比发生了某些变化，比如成员变量的数量、类型可能发生了改变，这个时候时无法正常反序列化的。

9.Parcelable接口原理？
Parcelable也是一个接口，只要实现这个接口，一个类的对象就可以实现序列化并通过Intent和Binder传递。
Parcel内部包装了可序列化的数据，可以在Binder中自由传输。
序列化的功能由writeToParcel方法来完成，最终时通过Parcel的一系列write方法来完成的；
反序列化功能由CREATOR来完成，其内部表明了如何创建序列化对象和数组，并通过Parcel的一系列read方法来完成反序列化过程。

从这篇文章中我们开始分析android系统的事件分发流程，其实网上已经有了很多关于android系统的事件分发流程的文章，奈何看了很多但是印象还不是很深，所以这里总结一番。
android系统的事件分发流程分为很多部分：

• Native层 –> ViewRootImpl层 –> DecorView层 –> Activity层 –> ViewGroup层 –> View层

所以android系统的事件分发流程是从Native层开始的，然后分发到ViewRootImpl中，然后分发到DecorView层，然后分发到ViewGroup层，最后分发到View层中。下面我们将从Native层开始分析事件的分发流程。

在Native层android系统的事件流程：

• Android系统是从从底层驱动中获取各种原始的用户消息，包括按键、触摸屏、鼠标、滚迹球等用户事件消息。

• 在获取用户消息之后，android系统会对最原始的消息进行预处理，包括两个方面：一方面，将消息转化成系统可以处理的消息事件；另一方面，处理一些特殊的事件，比如HOME、MENU、POWER键等处理（前面的几篇文章中我们已经分析了系统按键处理逻辑的执行流程）。

• 将处理后的消息事件分发到各个应用进程，这个需要使用IPC机制，Android系统使用管道来进行消息的传递。

• Android系统使用InputManager类来管理消息，而具体的功能则是通过InputReaderThread和InputDispatcherThread两个线程来实现。其中InputReaderThread线程负责消息的读取，而InputDispatcherThread则负责消息的预处理和分发到各个应用进程中。

• Acitivty系统在SystemServer进程中启动WindowManagerService服务，然后在WindowManagerService服务中启动InputManagerService服务。

可以看到在Native层，主要创建了两个两个线程，其中一个用于读取消息，另一个用于分发消息，消息经过分发最终会上传至App中。

在ViewRootImpl层android系统的事件流程

在Native层的事件分发线程中，经过事件的分发流程，最终会调用InputEventSender的dispatchInputEventFinished方法，可以看一下具体代码的实现：

1
2
3

private void dispatchInputEventFinished(int seq, boolean handled) {
        onInputEventFinished(seq, handled);
    }

在dispatchInputEventFinished方法中我们最终调用的是onInputEventFinished方法，然后我们查看onInputEventFinished方法的实现，发现其是一个空方法。。。，好吧，经过分析我们发现，Native层最终调用的并不是InputEventSender，而是调用InputEventSender的子类ImeInputEventSender，即ImeInputEventSender的onInputEventFinished方法，该类定义在源文件InputMethodManager中：

上篇文章中我们分析了Activity的onSaveInstanceState方法执行时机，知道了Activity在一般情况下，若只是执行onPause方法则不会执行onSaveInstanceState方法，而一旦执行了onStop方法就会执行onSaveInstanceState方法，具体的信息，可以参见onSaveInstanceState方法执行时机：android源码解析（二十四）–>onSaveInstanceState执行时机 这篇文章中同样的我们分析一下Actvity（当然不只是Activity，同样包含Servier，ContentProvider，Application等）的另一个内部方法：onLowMemory。该方法主要用于当前系统可用内存比较低的时候回调使用。

这里简单介绍一下Android系统的内存分配机制。Android系统中一个个的App都是一个个不同的应用进程，拥有各自的JVM与运行时，每个App的进程可使用的内存大小都是固定的，当系统中App打开数量过多时，就会使Android系统的可用内存降低，对于当前正在使用的App而言，可能还需要继续申请系统内存，而我们的剩余系统内存已经不足以被当前App所申请了，这时候系统会自动的清理那些后台进程，进而释放出可用内存用于前台进程的使用，当然这里系统清理后台进程的算法不是我们讨论的重点。这里我们只是大概的分析Android系统回调Activity的onLowMemory方法的流程。

通过前面关于Activity的启动流程分析我们知道ActivityManagerService是整个Android系统的管理中枢，负责Activity，Servier等四大组件的启动与销毁等工作，同样的对于应用进程的管理工作也是在ActivityMaangerServier中完成的，我们知道android系统中有两个比较重要的进程Zygote进程和SystemServer进程，其中Zygote进程是整个Android系统的根进程，其他所有的进程都是通过Zygote进程fork出来的。而SystemServer进程则用于运行各种服务，为其他的应用进程提供各种功能接口等，在前面我们分析过SystemServer进程的启动流程（参考： android源码解析之（九）–>SystemServer进程启动流程）其中在SystemServer的startBootService方法中我们调用了：

1
2

// Set up the Application instance for the system process and get started.
        mActivityManagerService.setSystemProcess();

方法，看其注释说明，说的是为System进程初始化Application实例，这里我们可以看一下该方法的具体实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public void setSystemProcess() {
        try {
            ServiceManager.addService(Context.ACTIVITY_SERVICE, this, true);
            ServiceManager.addService(ProcessStats.SERVICE_NAME, mProcessStats);
            ServiceManager.addService("meminfo", new MemBinder(this));
            ServiceManager.addService("gfxinfo", new GraphicsBinder(this));
            ServiceManager.addService("dbinfo", new DbBinder(this));
            if (MONITOR_CPU_USAGE) {
                ServiceManager.addService("cpuinfo", new CpuBinder(this));
            }
            ServiceManager.addService("permission", new PermissionController(this));
            ServiceManager.addService("processinfo", new ProcessInfoService(this));

            ApplicationInfo info = mContext.getPackageManager().getApplicationInfo(
                    "android", STOCK_PM_FLAGS);
            mSystemThread.installSystemApplicationInfo(info, getClass().getClassLoader());

            synchronized (this) {
                ProcessRecord app = newProcessRecordLocked(info, info.processName, false, 0);
                app.persistent = true;
                app.pid = MY_PID;
                app.maxAdj = ProcessList.SYSTEM_ADJ;
                app.makeActive(mSystemThread.getApplicationThread(), mProcessStats);
                synchronized (mPidsSelfLocked) {
                    mPidsSelfLocked.put(app.pid, app);
                }
                updateLruProcessLocked(app, false, null);
                updateOomAdjLocked();
            }
        } catch (PackageManager.NameNotFoundException e) {
            throw new RuntimeException(
                    "Unable to find android system package", e);
        }
    }

这里简单介绍一下ServierManager是一个管理服务的服务，而其addServier方法就是注册各种服务（服务注册到JNI层，具体的关于是如何注册到JNI层的这里暂不做过多的解释）。可以发现在方法体中我们注册了名称为：memInfo的服务MemBinder，MemBinder是一个Binder类型的服务，主要用于检测系统内存情况，这里可以看一下其具体的实现逻辑：

我们已经分析过Activity的启动流程，从中也分析了Activity的生命周期。而其中有一个生命周期方法:onSaveInstanceState方法，今天我们主要讲解一下onSaveInstanceState方法的执行时机。
可能部分同学对Activity的onSaveInstanceState方法不是特别熟悉，这里我们简单介绍一下。onSaveInstanceState方法是Activity的成员方法，主要用于在Activity销毁时保存Activity相关的对象信息，而其执行的时机不是我们主动调用的，而是Android系统的framework帮忙调用的，而其调用的时机，可以参考android系统的介绍：

This method is called before an activity may be killed so that when it comes back some time in the future it can restore its state. For example, if activity B is launched in front of activity A, and at some point activity A is killed to reclaim resources, activity A will have a chance to save the current state of its user interface via this method so that when the user returns to activity A, the state of the user interface can be restored via {@link #onCreate} or {@link #onRestoreInstanceState}.

可以发现onSaveInstanceState方法会在Activity将要被kill的时候执行。O(∩_∩)O哈哈~，可能跟以前讲解的内容不是太对，我们看过不少文章都是说onSaveInstanceStatex方法会在Activity容易被销毁的时候执行。那么这里明明说的是当Activity被销毁的时候就会执行onSaveInstanceState方法，那么具体的情况是如何的呢?我们具体看一下源码吧，哈哈。

通过分析Activity的生命周期方法，我们知道onSaveInstanceState方法在onPause方法之后执行在onStop方法之前执行。这里我们首先看一下onPause方法的源码逻辑。

Activity在执行onPause方法的时候回回调ActivityThread的handlePauseActivity方法，不太熟悉的同学可以参考: android源码解析之（十四）–>Activity启动流程，文章中有对Activity生命周期的详细讲解。

好吧，先具体看一下ActivityThread.handlePauseActivity的源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

private void handlePauseActivity(IBinder token, boolean finished,
            boolean userLeaving, int configChanges, boolean dontReport) {
        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;
            performPauseActivity(token, finished, r.isPreHoneycomb());

            // Make sure any pending writes are now committed.
            if (r.isPreHoneycomb()) {
                QueuedWork.waitToFinish();
            }

            // Tell the activity manager we have paused.
            if (!dontReport) {
                try {
                    ActivityManagerNative.getDefault().activityPaused(token);
                } catch (RemoteException ex) {
                }
            }
            mSomeActivitiesChanged = true;
        }
    }

在方法体中我们除了执行一些其他的操作，然后在handlePauseActivity方法体中调用了performPauseActivity方法，这个方法就是具体执行回调pauseActivity操作的方法，既然这样我们在看一下performPauseActivity方法的实现：

1
2
3
4
5

final Bundle performPauseActivity(IBinder token, boolean finished,
            boolean saveState) {
        ActivityClientRecord r = mActivities.get(token);
        return r != null ? performPauseActivity(r, finished, saveState) : null;
    }

可以发现在performPauseActivity方法中首先判断ActivityClientRecord是否为空，然后又调用了performPauseActivity方法的重载方法：

前面我们分析了Activity、Dialog、PopupWindow的加载绘制流程，相信大家对整个Android系统中的窗口绘制流程已经有了一个比较清晰的认识了，这里最后再给大家介绍一下Toast的加载绘制流程。

其实Toast窗口和Activity、Dialog、PopupWindow有一个不太一样的地方，就是Toast窗口是属于系统级别的窗口，他和输入框等类似的，不属于某一个应用，即不属于某一个进程，所以自然而然的，一旦涉及到Toast的加载绘制流程就会涉及到进程间通讯，看过前面系列文章的同学应该知道，Android间的进程间通讯采用的是Android特有的Binder机制，所以Toast的加载绘制流程也会涉及到Binder进程间通讯。

Toast的显示流程其实内部还是通过Window的窗口机制实现加载绘制的，只不过由于是系统级别的窗口，在显示过程中涉及到了进程间通讯等机制。

下面我们来具体看一下Toast窗口的简单使用。

1

Toast.makeText(context, msg, Toast.LENGTH_SHORT).show();

上面的代码是Toast的典型使用方式，通过makeText方法创建出一个Toast对象，然后调用show方法将Toast窗口显示出来。

下面我们来看一下makeText方法的具体实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public static Toast makeText(Context context, CharSequence text, @Duration int duration) {
        Toast result = new Toast(context);

        LayoutInflater inflate = (LayoutInflater)
                context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
        View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);
        TextView tv = (TextView)v.findViewById(com.android.internal.R.id.message);
        tv.setText(text);
        
        result.mNextView = v;
        result.mDuration = duration;

        return result;
    }

方法体不是很长，在makeText方法中，我们首先通过Toast对象的构造方法，创建了一个新的Toast对象，这样我们就先来看一下Toast的构造方法做了哪些事。

1
2
3
4
5
6
7
8

public Toast(Context context) {
        mContext = context;
        mTN = new TN();
        mTN.mY = context.getResources().getDimensionPixelSize(
                com.android.internal.R.dimen.toast_y_offset);
        mTN.mGravity = context.getResources().getInteger(
                com.android.internal.R.integer.config_toastDefaultGravity);
    }

可以看到这里初始化了Toast对象的成员变量mContext和mTN，这里的mContext是一个Context类型的成员变量，那mTN是什么东西呢？

1

private static class TN extends ITransientNotification.Stub

从类的源码定义来看，我们知道TN是一个继承自ITransientNotification.Stub的类，这里我们暂时只用知道他的继承关系就好了，知道其是一个Binder对象，可以用于进程间通讯，然后回到我们的makeText方法，在调用了Toast的构造方法创建了Toast对象之后，我们又通过context.getSystemService方法获取到LayoutInflater，然后通过调用LayoutInflater的inflate方法加载到了Toast的布局文件：

在前面的几篇文章中我们分析了Activity与Dialog的加载绘制流程，取消绘制流程，相信大家对Android系统的窗口绘制机制有了一个感性的认识了，这篇文章我们将继续分析一下PopupWindow加载绘制流程。

在分析PopupWindow之前，我们将首先说一下什么是PopupWindow？理解一个类最好的方式就是看一下这个类的定义，这里我们摘要了一下Android系统中PopupWindow的类的说明：

A popup window that can be used to display an arbitrary view. The popup window is a floating container that appears on top of the current
activity.

一个PopupWindow能够被用于展示任意的View，PopupWindow是一个悬浮的容易展示在当前Activity的上面。
简单来说PopupWindow就是一个悬浮在Activity之上的窗口，可以用展示任意布局文件。

在说明PopupWindow的加载绘制机制之前，我们还是先写一个简单的例子用于说明一下PopupWindow的简单用法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public static View showPopupWindowMenu(Activity mContext, View anchorView, int layoutId) {
        LayoutInflater inflater = (LayoutInflater) mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
        View view = inflater.inflate(layoutId, null);
        popupWindow = new PopupWindow(view, DisplayUtil.dip2px(mContext, 148), WindowManager.LayoutParams.WRAP_CONTENT);
        popupWindow.setBackgroundDrawable(mContext.getResources().getDrawable(R.drawable.menu_bg));
        popupWindow.setFocusable(true);
        popupWindow.setOutsideTouchable(true);

        int[] location = new int[2];
        anchorView.getLocationOnScreen(location);
        popupWindow.setAnimationStyle(R.style.popwin_anim_style);
        popupWindow.showAtLocation(anchorView, Gravity.NO_GRAVITY,
                location[0] - popupWindow.getWidth() + anchorView.getWidth() - DisplayUtil.dip2px(mContext, 12),
                location[1] + anchorView.getHeight() - DisplayUtil.dip2px(mContext, 10));

        popupWindow.setOnDismissListener(new PopupWindow.OnDismissListener() {
            @Override
            public void onDismiss() {
                popupWindow = null;
            }
        });
        return view;
    }

可以看到我们首先通过LayoutInflater对象将布局文件解析到内存中View对象，然后创建了一个PopupWindow对象，可以看到传递了三个参数，一个是View对象，一个是PopupWindow的宽度和高度。

这里就是PopupWindow的初始化流程的开始了，好吧，我们来看一下PopupWindow的构造方法的实现：

1
2
3

public PopupWindow(View contentView, int width, int height) {
        this(contentView, width, height, false);
    }

可以看到这里调用了PopupWindow的重载构造方法，好吧，继续看一下这个重载构造方法的实现逻辑：

这篇文章是承接上一篇文章(Android布局加载流程：android源码解析（十七）–>Activity布局加载流程)来写的，大家都知道Activity在Android体系中扮演者一个界面展示的角色，通过上一篇文章的分析，我们知道Activity是通过Window来控制界面的展示的，一个Window对象就是一个窗口对象，而每个Activity中都有一个相应的Window对象，所以说一个Activity对象也就可以说是一个窗口对象，而Window只是控制着界面布局文件的加载过程，那么界面布局文件的绘制流程是如何的呢？这篇文章主要就是顺着上篇文章的思路，看一下在android系统中Activity的布局文件是如何绘制的。

顺便在这里多说几句，android中所有能显示的东西都是通过Window对象实现了，无论Activity，Dialog，PopupWindow，Toast等。后期我可能也会讲一下Dialog，PopupWindow，Toast等组件的显示过程。

前面有一篇文章中我们介绍过Activity的启动流程，可参考：android源码解析之（十四）–>Activity启动流程
在执行ActivityThread的handleLauncherActivity方法中通过Window对象控制了布局文件的加载流程，而Android体系在执行Activity的onResume方法之前会回调ActivityThread的handleResumeActivity方法：

好吧，终于要开始讲讲Activity的布局加载流程了，大家都知道在Android体系中Activity扮演了一个界面展示的角色，这也是它与android中另外一个很重要的组件Service最大的不同，但是这个展示的界面的功能是Activity直接控制的么？界面的布局文件是如何加载到内存并被Activity管理的？android中的View是一个怎样的概念？加载到内存中的布局文件是如何绘制出来的？

要想回答这些问题，我们就需要对android的界面加载与绘制流程有所了解，这里我们先来学习一下Activity的布局加载的流程。而至于Acitivty的布局绘制流程我们在下一篇中在做介绍。

其实Activity对界面布局的管理是都是通过Window对象来实现的，Window对象，顾名思义就是一个窗口对象，而Activity从用户角度就是一个个的窗口实例，因此不难想象每个Activity中都对应着一个Window对象，而这个Window对象就是负责加载显示界面的。至于window对象是如何展示不同的界面的，那是通过定义不同的View组件实现不同的界面展示。

废话不多说了，不知道大家是否还记得我们讲过的Activity的启动流程么？不熟悉的童鞋可以参考： android源码解析之（十四）–>Activity启动流程 ，在文章中我们介绍到当ActivityManagerService接收到启动Activity的请求之后会通过IApplicationThread进程间通讯告知ApplicationThread并执行handleLauncherActivity方法，这里我们可以下其具体实现：

今天讲讲应用进程Context的创建流程，相信大家平时在开发过程中经常会遇到对Context对象的使用，Application是Context，Activity是Context，Service也是Context，所以有一个经典的问题是一个App中一共有多少个Context？

这个问题的答案是Application + N个Activity + N个Service。

还有就是我们平时在使用Context过程中许多时候由于使用不当，可能会造成内存泄露的情况等等，这个也是需要我们注意的。这里有篇不错的文章：
Android Context 是什么？

好吧，什么叫应用进程Context呢？这是指的是Application所代表的Context的创建流程，还记得我们前几篇写的应用进程创建流程么？
android源码解析之（十一）–>应用进程启动流程
最后我们得出结论，应用进程的起始方法是ActivityThread.main方法，好吧，

由于还未讲解Service相关知识，这里暂时讲解一下Activity与Application中Context对象的创建过程。

首先我们就从ActivityThread.main方法开始看一下Application的创建流程。。。

1
2
3
4
5
6

public static void main(String[] args) {
        ...
        ActivityThread thread = new ActivityThread();
        thread.attach(false);
        ...
    }

这里我们发现在方法体中我们创建了一个ActivityThread对象并执行了attach方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

private void attach(boolean system) {
        sCurrentActivityThread = this;
        mSystemThread = system;
        if (!system) {
            ViewRootImpl.addFirstDrawHandler(new Runnable() {
                @Override
                public void run() {
                    ensureJitEnabled();
                }
            });
            android.ddm.DdmHandleAppName.setAppName("<pre-initialized>",
                                                    UserHandle.myUserId());
            RuntimeInit.setApplicationObject(mAppThread.asBinder());
            final IActivityManager mgr = ActivityManagerNative.getDefault();
            try {
                mgr.attachApplication(mAppThread);
            } catch (RemoteException ex) {
                // Ignore
            }
            // Watch for getting close to heap limit.
            BinderInternal.addGcWatcher(new Runnable() {
                @Override public void run() {
                    if (!mSomeActivitiesChanged) {
                        return;
                    }
                    Runtime runtime = Runtime.getRuntime();
                    long dalvikMax = runtime.maxMemory();
                    long dalvikUsed = runtime.totalMemory() - runtime.freeMemory();
                    if (dalvikUsed > ((3*dalvikMax)/4)) {
                        if (DEBUG_MEMORY_TRIM) Slog.d(TAG, "Dalvik max=" + (dalvikMax/1024)
                                + " total=" + (runtime.totalMemory()/1024)
                                + " used=" + (dalvikUsed/1024));
                        mSomeActivitiesChanged = false;
                        try {
                            mgr.releaseSomeActivities(mAppThread);
                        } catch (RemoteException e) {
                        }
                    }
                }
            });
        } else {
          ...  
        }
    }

这里看一下重点实现，我们可以发现在方法体中调用了ActivityManagerNative.getDefault().attachApplication(mAppThread)
看过我的前几篇文章的童鞋应该知道这里就是一个Binder进程间通讯，其实上执行的是ActivityManagerService.attachApplication方法，具体的可以参考前几篇文章的介绍，好吧，既然这样我们看一下ActivityManagerService.attachApplication方法的具体实现。