[Android] 【深圳校区】问答网经典集锦--Activity

大家好，新的一期深圳校区问答网集锦又来啦。这一期的问题焦点是Activity。

Acitivity作为Android Framwork层提供的四大组件的老大，是最重要、最常用的组件。从字面意思看，是“活动”的意思。可是“活动”到底是shen me gui？对于初学者来说，有点难以理解。只知道往Activity里边写布局，写监听事件，就能向用户展示界面并进行UI交互了，好神奇。

其实要理解我们的Activity，还要从Java的main方法开始说起。大家都知道，Android的应用其实也是跑在虚拟机的，Dalvik、ART和JAM一样也是虚拟机的一种。而虚拟机的入口就是main方法，在main方法起了一条UI线程，然后在里边创建了Activity，最后给分配了的windows对象给这个Acitivty。这样Activity就显示出来了。然而，onCreate这些生命周期方法到底是谁调用的？既然对象是在main法里创建的，其实就是从main方法里面进来的虚拟机在调用，只是调用的方式是反射啦。这么一说，是不是好像明白了一些。不过，在真正掌握Acitivty之前，知道这些还远远不够，这期我们把深圳校区里关于Activity的各种琐碎问题集合起来，给大家参考关于Acitivty的问题，在深圳校区问答网，有么多：

下面就来看看关于深圳校区学员在Activity里遇到的各种奇葩问题吧：-------------------------------------------------------华丽的分割线------------------------------------------------------一、onKeyUp方法和onKeyDown方法有什么区别？答：Activity.onKeyDown(); 当某个键被按下时会触发，但不会被任何的该Activity内的任何view处理。
默认按下KEYCODE_BACK键后会回到上一个Activity。
Activity.onKeyUp():
当某个按键被按下，松开后触发，但不会被任何的该Activity内的任何view处理。
默认没有执行任何操作，只是简单的给一个false作为返回值。

-------------------------------------------------------------------------------------------------------

二、我在activity中执行startActivityForResult，并且重写了onActivityResult()，但是没等到被调用的 Activity 返回，onActivityResult() 就被执行了。也就是说，在startActivityForResult被调用后startActivityForResult立即被执行了，这是怎么回事？

答：针对这个问题，在调用startActivityForResult之后，onActivityResult无响应或立即响应

有两种现象：
## 现象一： ##
执行startActivityForResult，没等到被调用的 Activity 返回，onActivityResult() 就被执行了。
## 原因： ##
这与 Activity 的加载模式（launchMode）有关，该属性可以在 AndroidManifest.xml 中设置。
原先将其设为 singleInstance或singleTask，经测试，所有需要传递或接收的 Activity 不允许设置该属性，**或只能设为标准模式**，否则系统将在 startActivityForResult() 后直接调用 onActivityResult()。
## 现象一： ##
两个activity传递数据和返回数据时，请求方的onActivityResult始终无响应，通过debug调试模式也没见调用该方法。查看了各种配置和程序代码，均未发现有错误之处。
## 原因 ##
后来仔细阅读API说明，恍然大悟，原来是调用startActivityForResult的参数问题，即调用时这样：
startActivityForResult(intent, 0);
**是第二个参数的问题，该参数必须大于0才能在返回值，并激活onActivityResult方法。**
-------------------------------------------------------------------------------------------------------
三、最后来一个给力的，直接上代码，精彩问答：
学生问题：我居然可以在子线程中成功更新UI？

我在activity的oncreate方法中，创建了一个子线程，并且在子线程中去更改了button的显示内容，居然还成功了，没有报错，这是为什么？不是说子线程不能更新UI吗？

具体代码如下：

public class MainActivity extends ActionBarActivity {
Button btn = null;
/** Called when the activity is first created. */
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
btn = (Button) findViewById(R.id.Button01);
TestThread2 t = new TestThread2(btn);
t.start();
}
class TestThread2 extends Thread {
Button btn = null;
public TestThread2(Button btn) {
this.btn = btn;
}
@Override
public void run() {
btn.setText("TestThread2.run");
}
}
}

复制代码

精彩答案：

Android官方呢也建议我们不要在非UI线程直接更新UI，为什么呢？借助Android官方的一句话来说就是：

“The Android UI toolkit is not thread-safe and the view must always be manipulated on the UI thread.”

因此，很多童鞋会有这么一个惯性思维：在非UI线程中不能更新UI！既然Android不建议我们这么做，那其必定会对我们在code时做一些限制

Android通过检查我们当前的线程是否为UI线程从而抛出一个自定义的AndroidRuntimeException来提醒我们“Only the original thread that created a view hierarchy can touch its views”并强制终止程序运行，具体的实现在ViewRootImpl类的checkThread方法中：

@SuppressWarnings({"EmptyCatchBlock", "PointlessBooleanExpression"})
public final class ViewRootImpl implements ViewParent,
View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks {
// 省去海量代码…………………………
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
// 省去巨量代码……………………
}

复制代码

这就是Android在4.0后对我们做出的一个限制

OK，这里我们再来看一下上面的一段代码，在线程中我调用了Thread.sleep(200);来让我们的匿名线程暂停了200ms。假如……我们去掉它的会发生什么？来试试：

/**
* 主界面
*
* @author Aige {@link http://blog.csdn.net/aigestudio}
* @since 2014/11/17
*/
public class MainActivity extends Activity {
private TextView tvText;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
tvText = (TextView) findViewById(R.id.main_tv);
new Thread(new Runnable() {
@Override
public void run() {
tvText.setText("OtherThread");
}
}).start();
}
}

复制代码

这时你会发现我们的代码正确执行了！而且我们的TextView正确显示出了“OtherThread”文本！看到屏幕上的这11个英文字母我相信小伙伴们惊呆了，我们成功地在非UI线程中更新了UI。其实这里最最根本的原因是我们并没有checkThread我们的当前线程，而我在文章最开始的代码中通过Thread.sleep(200)暂停了一小段时间，这里为什么回暂停线程一段时间？在这段时间的背后Android背地里背着我们都干了什么？这一切的背后，是人性的扭曲还是道德的沦丧？抱歉……磕个药，上面我们讲到，我们能正确以上述代码的方式在非UI线程中更新UI而不报错，那么原因也许只有一个，那就是没有执行checkThread方法去检查我们的当前线。但是，细看调用checkThread方法的调用方法们你就会发现，全是跟View创建生成相关：

也就是说一旦我们尝试去对我们的控件进行生成，这些方法其中一个必然会被调用，这时候很多学员就会蛋疼。但是，请不要被checkThread方法的思维所束缚，这时候你该扩大你的思维范畴，既然checkThread方法属于ViewRootImpl的成员方法，那么会不会是此时我们的ViewRootImpl根本就没被创建呢？怀着这个出发点，我们再度审视ActivtyThread调度Activity生命周期的各个环节，首先看看performLaunchActivity方法中的处理：

public final class ActivityThread {
// 省去海量代码…………………………
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
ActivityInfo aInfo = r.activityInfo;
// 省去对packageInfo的逻辑处理
// 省去对ComponentName的逻辑处理
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
// 通过Instrumentation对象生成Activity类的实例
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
// 省去三行代码…………
} catch (Exception e) {
// 省去对异常的捕获处理
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
// 省去多行无关代码
if (activity != null) {
Context appContext = createBaseContextForActivity(r, activity);
CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
Configuration config = new Configuration(mCompatConfiguration);
// 省去多行无关代码
if (customIntent != null) {
activity.mIntent = customIntent;
}
r.lastNonConfigurationInstances = null;
activity.mStartedActivity = false;
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
activity.setTheme(theme);
}
/*
* 调用callActivityOnCreate方法处理Create逻辑
*/
activity.mCalled = false;
mInstrumentation.callActivityOnCreate(activity, r.state);
if (!activity.mCalled) {
// 省去多行无关代码
}
r.activity = activity;
r.stopped = true;
/*
* 调用performStart方法处理Start逻辑
*/
if (!r.activity.mFinished) {
activity.performStart();
r.stopped = false;
}
// 省去多行无关代码
}
// 省去两行无关代码
} catch (SuperNotCalledException e) {
// 省去对异常的捕获处理
} catch (Exception e) {
// 省去对异常的捕获处理
}
return activity;
}
// 省去巨量代码……………………
}

复制代码

performLaunchActivity方法中目测没有我们想要的信息，其创建了Activity并调度了Create和Start的逻辑处理，那我们看看callActivityOnCreate方法呢：

public class Instrumentation {
// 省去海量代码…………………………
public void callActivityOnCreate(Activity activity, Bundle icicle) {
// 省去某些逻辑……
activity.performCreate(icicle);
// 省去某些逻辑……
}
// 省去巨量代码……………………
}

复制代码

callActivityOnCreate中除了对MQ的一些调度外最重要的还是通过Activity的实例调用了performCreate方法：

public class Activity extends ContextThemeWrapper
implements LayoutInflater.Factory2,
Window.Callback, KeyEvent.Callback,
OnCreateContextMenuListener, ComponentCallbacks2 {
// 省去海量代码…………………………
final void performCreate(Bundle icicle) {
onCreate(icicle);
mVisibleFromClient = !mWindow.getWindowStyle().getBoolean(
com.android.internal.R.styleable.Window_windowNoDisplay, false);
mFragments.dispatchActivityCreated();
}
// 省去巨量代码……………………
}

复制代码

performCreate方法逻辑就更干脆了，最主要的还是调用了我们Activity的onCreate方法，我们没在这里找到我们想要的东西，那再来看performStart：

public class Activity extends ContextThemeWrapper
implements LayoutInflater.Factory2,
Window.Callback, KeyEvent.Callback,
OnCreateContextMenuListener, ComponentCallbacks2 {
// 省去海量代码…………………………
final void performStart() {
mFragments.noteStateNotSaved();
mCalled = false;
mFragments.execPendingActions();
mInstrumentation.callActivityOnStart(this);
if (!mCalled) {
throw new SuperNotCalledException(
"Activity " + mComponent.toShortString() +
" did not call through to super.onStart()");
}
mFragments.dispatchStart();
if (mAllLoaderManagers != null) {
final int N = mAllLoaderManagers.size();
LoaderManagerImpl loaders[] = new LoaderManagerImpl[N];
for (int i=N-1; i>=0; i--) {
loaders[i] = mAllLoaderManagers.valueAt(i);
}
for (int i=0; i<N; i++) {
LoaderManagerImpl lm = loaders[i];
lm.finishRetain();
lm.doReportStart();
}
}
}
// 省去巨量代码……………………
}

复制代码

performStart相对于performCreate有更多的逻辑处理，但依然木有我们想要的结果，其最终还是同过Instrumentation对象调用callActivityOnStart：

public class Instrumentation {
// 省去海量代码…………………………
public void callActivityOnStart(Activity activity) {
activity.onStart();
}
// 省去巨量代码……………………
}

复制代码

callActivityOnStart仅仅是调用了Activity的onStart方法，同杨，onStart方法中也没有我们想要的结果。我们抱着即将从埃菲尔铁塔顶端做自由落体的心态继续看onResume方法的调度，其在ActivityThread中通过handleResumeActivity调度：

public final class ActivityThread {
// 省去海量代码…………………………
final void handleResumeActivity(IBinder token, boolean clearHide, boolean isForward,
boolean reallyResume) {
unscheduleGcIdler();
ActivityClientRecord r = performResumeActivity(token, clearHide);
if (r != null) {
final Activity a = r.activity;
// 省去无关代码…………
final int forwardBit = isForward ?
WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION : 0;
boolean willBeVisible = !a.mStartedActivity;
if (!willBeVisible) {
try {
willBeVisible = ActivityManagerNative.getDefault().willActivityBeVisible(
a.getActivityToken());
} catch (RemoteException e) {
}
}
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (a.mVisibleFromClient) {
a.mWindowAdded = true;
wm.addView(decor, l);
}
} else if (!willBeVisible) {
// 省去无关代码…………
r.hideForNow = true;
}
cleanUpPendingRemoveWindows(r);
if (!r.activity.mFinished && willBeVisible
&& r.activity.mDecor != null && !r.hideForNow) {
if (r.newConfig != null) {
// 省去无关代码…………
performConfigurationChanged(r.activity, r.newConfig);
freeTextLayoutCachesIfNeeded(r.activity.mCurrentConfig.diff(r.newConfig));
r.newConfig = null;
}
// 省去无关代码…………
WindowManager.LayoutParams l = r.window.getAttributes();
if ((l.softInputMode
& WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION)
!= forwardBit) {
l.softInputMode = (l.softInputMode
& (~WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION))
| forwardBit;
if (r.activity.mVisibleFromClient) {
ViewManager wm = a.getWindowManager();
View decor = r.window.getDecorView();
wm.updateViewLayout(decor, l);
}
}
r.activity.mVisibleFromServer = true;
mNumVisibleActivities++;
if (r.activity.mVisibleFromClient) {
r.activity.makeVisible();
}
}
if (!r.onlyLocalRequest) {
r.nextIdle = mNewActivities;
mNewActivities = r;
// 省去无关代码…………
Looper.myQueue().addIdleHandler(new Idler());
}
r.onlyLocalRequest = false;
// 省去与ActivityManager的通信处理
} else {
// 省略异常发生时对Activity的处理逻辑
}
}
// 省去巨量代码……………………
}

复制代码

handleResumeActivity方法逻辑相对要复杂一些，对当前显示Window的逻辑判断以及没创建的初始化等等工作外其在最终会调用Activity的makeVisible方法：

public class Activity extends ContextThemeWrapper
implements LayoutInflater.Factory2,
Window.Callback, KeyEvent.Callback,
OnCreateContextMenuListener, ComponentCallbacks2 {
// 省去海量代码…………………………
void makeVisible() {
if (!mWindowAdded) {
ViewManager wm = getWindowManager();
wm.addView(mDecor, getWindow().getAttributes());
mWindowAdded = true;
}
mDecor.setVisibility(View.VISIBLE);
}
// 省去巨量代码……………………
}

复制代码

在makeVisible方法中逻辑相当简单，获取一个窗口管理器对象并将我们曾在自定义控件其实很简单7/12中提到过的根视图DecorView添加到其中，addView的具体实现在WindowManagerGlobal中：

public final class WindowManagerGlobal {
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
// 省去很多代码
ViewRootImpl root;
// 省去一行代码
synchronized (mLock) {
// 省去无关代码
root = new ViewRootImpl(view.getContext(), display);
// 省去一行代码
// 省去一行代码
mRoots.add(root);
// 省去一行代码
}
// 省去部分代码
}
}

复制代码

在addView生成了一个ViewRootImpl对象并将其保存在了mRoots数组中，每当我们addView一次，就会生成一个ViewRootImpl对象，其实看到这里我们还可以扩展一下问题一个APP是否可以拥有多个根视图呢？答案是肯定的，因为只要我调用了addView方法，我们传入的View参数就可以被认为是一个根视图，但是！在framework的默认实现中有且仅有一个根视图，那就是我们上面makeVisible方法中addView进去的DecorView，所以为什么我们可以说一个APP虽然可以有多个Activity，但是每个Activity只会有一个Window一个DecorView一个ViewRootImpl，看到这里很多童鞋依然会问，也就是说在onResume方法被执行后我们的ViewRootImpl才会被生成对吧，但是为什么下面的代码依然可以正确运行呢：

public class MainActivity extends ActionBarActivity {
Button btn = null;
/** Called when the activity is first created. */
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
btn = (Button) findViewById(R.id.Button01);
TestThread2 t = new TestThread2(btn);
t.start();
}
class TestThread2 extends Thread {
Button btn = null;
public TestThread2(Button btn) {
this.btn = btn;
}
@Override
public void run() {
btn.setText("TestThread2.run");
}
}
}

复制代码

没错，可以执行！首先我们这里的是一条线程，其次这里要涉及framework对UI事件处理的方式，Android对UI事件的处理需要依赖于Message Queue，当一个Msg被压入MQ到处理这个过程并非立即的，它需要一段事件，我们在线程中通过Thread.sleep(200)在等，在等什么呢？在等ViewRootImpl的实例对象被创建.

那么最后总结一下：

到底子线程中能不能更新UI呢？答案是可以的，前提条件是它要拥有自己的ViewRoot

那ViewRoot什么时候建立的呢，

答案就是在Activity.onResume前，它是在ActivityThread.java的final void handleResumeActivity(IBinder token, boolean clearHide, boolean isForward)里创建的。ViewRoot实例没有建立，所以没有ViewRoot.checkThread检查。而btn.setText时设定的文本却保留了下来，所以当ViewRoot真正去刷新界面时，就把"TestThread2.run"刷了出来！

-------------------------------------------------------华丽的分割线------------------------------------------------------

看完这些解答后，才知道原来非UI线程在特定情况也能更新UI，反正我是信了。真心感谢就业指导老师的认真回答，认真查阅资料。

jiuyeban · jiuyeban

赞赞赞赞赞赞赞赞赞赞赞赞

帐号		自动登录	找回密码
密码			加入黑马

[Android] 【深圳校区】问答网经典集锦--Activity

1 个回复