品茗论道说广播(Broadcast内部机制讲解)(下)
侯 亮
下面我们来看，递送广播动作中最重要的processNextBroadcast()。
3.2 最重要的processNextBroadcast()
从processNextBroadcast()的代码，我们就可以看清楚前面说的“平行广播”、“有序广播”和“动态receiver”、“静态receiver”之间的关系了。
我们在前文已经说过，所有的静态receiver都是串行处理的，而动态receiver则会按照发广播时指定的方式，进行“并行”或“串行”处理。能够并行处理的广播，其对应的若干receiver一定都已经存在了，不会牵扯到启动新进程的操作，所以可以在一个while循环中，一次性全部deliver。而有序广播，则需要一个一个地处理，其滚动处理的手段是发送事件，也就是说，在一个receiver处理完毕后，会利用广播队列（BroadcastQueue）的mHandler，发送一个BROADCAST_INTENT_MSG事件，从而执行下一次的processNextBroadcast()。
processNextBroadcast()的代码逻辑大体是这样的：先尝试处理BroadcastQueue中的“平行广播”部分。这需要遍历并行列表（mParallelBroadcasts）的每一个BroadcastRecord以及其中的receivers列表。对于平行广播而言，receivers列表中的每个子节点是个BroadcastFilter。我们直接将广播递送出去即可：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
while
(mParallelBroadcasts.size() >
0
)
{
r = mParallelBroadcasts.remove(
0
);
r.dispatchTime = SystemClock.uptimeMillis();
r.dispatchClockTime = System.currentTimeMillis();
final
int
N = r.receivers.size();
. . . . . .
for
(
int
i=
0
; i<N; i++)
{
Object target = r.receivers.get(i);
. . . . . .
deliverToRegisteredReceiverLocked(r, (BroadcastFilter)target,
false
);
}
. . . . . .
}
|
3.2.1 用deliverToRegisteredReceiverLocked()递送到平行动态receiver
deliverToRegisteredReceiverLocked()的代码截选如下：
【frameworks/base/services/java/com/android/server/am/BroadcastQueue.java】
|
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
|
private
final
void
deliverToRegisteredReceiverLocked(BroadcastRecord r,
BroadcastFilter filter,
boolean
ordered)
{
. . . . . .
. . . . . .
if
(!skip)
{
if
(ordered)
{
r.receiver = filter.receiverList.receiver.asBinder();
r.curFilter = filter;
filter.receiverList.curBroadcast = r;
r.state = BroadcastRecord.CALL_IN_RECEIVE;
if
(filter.receiverList.app !=
null
)
{
r.curApp = filter.receiverList.app;
filter.receiverList.app.curReceiver = r;
mService.updateOomAdjLocked();
}
}
. . . . . .
performReceiveLocked(filter.receiverList.app,
filter.receiverList.receiver,
new
Intent(r.intent), r.resultCode,
r.resultData, r.resultExtras,
r.ordered, r.initialSticky);
if
(ordered)
{
r.state = BroadcastRecord.CALL_DONE_RECEIVE;
}
. . . . . .
}
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
private
static
void
performReceiveLocked(ProcessRecord app, IIntentReceiver receiver,
Intent intent,
int
resultCode, String data, Bundle extras,
boolean
ordered,
boolean
sticky)
throws
RemoteException
{
// Send the intent to the receiver asynchronously using one-way binder calls.
if
(app !=
null
&& app.thread !=
null
)
{
// If we have an app thread, do the call through that so it is
// correctly ordered with other one-way calls.
app.thread.scheduleRegisteredReceiver(receiver, intent, resultCode,
data, extras, ordered, sticky);
}
else
{
receiver.performReceive(intent, resultCode, data, extras, ordered, sticky);
}
}
|
终于通过app.thread向用户进程传递语义了。注意scheduleRegisteredReceiver()的receiver参数，它对应的就是前文所说的ReceiverDispatcher的Binder实体——InnerReceiver了。
总之，当语义传递到用户进程的ApplicationThread以后，走到：
|
1
2
3
4
5
6
7
8
9
|
// This function exists to make sure all receiver dispatching is
// correctly ordered, since these are one-way calls and the binder driver
// applies transaction ordering per object for such calls.
public
void
scheduleRegisteredReceiver(IIntentReceiver receiver, Intent intent,
int
resultCode, String dataStr, Bundle extras,
boolean
ordered,
boolean
sticky)
throws
RemoteException
{
receiver.performReceive(intent, resultCode, dataStr, extras, ordered, sticky);
}
|
终于走到ReceiverDispatcher的InnerReceiver了：
|
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
|
static
final
class
ReceiverDispatcher
{
final
static
class
InnerReceiver
extends
IIntentReceiver.Stub
{
. . . . . .
. . . . . .
public
void
performReceive(Intent intent,
int
resultCode,
String data, Bundle extras,
boolean
ordered,
boolean
sticky)
{
LoadedApk.ReceiverDispatcher rd = mDispatcher.get();
. . . . . .
if
(rd !=
null
) {
rd.performReceive(intent, resultCode, data, extras,
ordered, sticky);
}
. . . . . .
}
}
. . . . . .
public
void
performReceive(Intent intent,
int
resultCode,
String data, Bundle extras,
boolean
ordered,
boolean
sticky)
{
. . . . . .
Args args =
new
Args(intent, resultCode, data, extras, ordered, sticky);
if
(!mActivityThread.post(args))
// 请注意这一句！
{
if
(mRegistered && ordered)
{
IActivityManager mgr = ActivityManagerNative.getDefault();
if
(ActivityThread.DEBUG_BROADCAST) Slog.i(ActivityThread.TAG,
"Finishing sync broadcast to "
+ mReceiver);
args.sendFinished(mgr);
}
}
}
}
|
请注意mActivityThread.post(args)一句，这样，事件泵最终会回调Args参数的run()成员函数：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
final
class
Args
extends
BroadcastReceiver.PendingResult
implements
Runnable
{
. . . . . .
. . . . . .
public
void
run()
{
final
BroadcastReceiver receiver = mReceiver;
. . . . . .
try
{
ClassLoader cl = mReceiver.getClass().getClassLoader();
intent.setExtrasClassLoader(cl);
setExtrasClassLoader(cl);
receiver.setPendingResult(
this
);
receiver.onReceive(mContext, intent);
// 回调具体receiver的onReceive()
}
catch
(Exception e) {
. . . . . .
}
if
(receiver.getPendingResult() !=
null
) {
finish();
}
. . . . . .
}
}
|
其中的那句receiver.onReceive(this)，正是回调我们具体receiver的onReceive()成员函数的地方。噢，终于看到应用程序员熟悉的onReceive()了。这部分的示意图如下：
3.2.2 静态receiver的递送
说完动态递送，我们再来看静态递送。对于静态receiver，情况会复杂很多，因为静态receiver所从属的进程有可能还没有运行起来呢。此时BroadcastRecord节点中记录的子列表的节点是ResolveInfo对象。
|
1
2
3
4
|
ResolveInfo info = (ResolveInfo)nextReceiver;
. . . . . .
r.state = BroadcastRecord.APP_RECEIVE;
String targetProcess = info.activityInfo.processName;
|
那么我们要先找到receiver所从属的进程的进程名。
processNextBroadcast()中启动进程的代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
ProcessRecord app = mService.getProcessRecordLocked(targetProcess,
info.activityInfo.applicationInfo.uid);
. . . . . .
if
(app !=
null
&& app.thread !=
null
)
{
. . . . . .
app.addPackage(info.activityInfo.packageName);
processCurBroadcastLocked(r, app);
return
;
. . . . . .
}
r.curApp = mService.startProcessLocked(targetProcess,
info.activityInfo.applicationInfo,
true
,
r.intent.getFlags() | Intent.FLAG_FROM_BACKGROUND,
"broadcast"
, r.curComponent,
(r.intent.getFlags()&Intent.FLAG_RECEIVER_BOOT_UPGRADE) !=
0
,
false
)
. . . . . .
mPendingBroadcast = r;
mPendingBroadcastRecvIndex = recIdx;
|
如果目标进程已经存在了，那么app.thread肯定不为null，直接调用processCurBroadcastLocked()即可，否则就需要启动新进程了。启动的过程是异步的，可能很耗时，所以要把BroadcastRecord节点记入mPendingBroadcast。
3.2.2.1 processCurBroadcastLocked()
我们先说processCurBroadcastLocked()。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
private
final
void
processCurBroadcastLocked(BroadcastRecord r,
ProcessRecord app)
throws
RemoteException
{
. . . . . .
r.receiver = app.thread.asBinder();
r.curApp = app;
app.curReceiver = r;
. . . . . .
. . . . . .
app.thread.scheduleReceiver(
new
Intent(r.intent), r.curReceiver,
mService.compatibilityInfoForPackageLocked(r.curReceiver.applicationInfo),
r.resultCode, r.resultData, r.resultExtras, r.ordered);
. . . . . .
started =
true
;
. . . . . .
}
|
其中最重要的是调用app.thread.scheduleReceiver()的那句。在IApplicationThread接口中，是这样定义scheduleReceiver()函数原型的：
|
1
2
3
4
5
|
void
scheduleReceiver(Intent intent, ActivityInfo info,
CompatibilityInfo compatInfo,
int
resultCode, String data,
Bundle extras,
boolean
sync)
throws
RemoteException;
|
其中ActivityInfo info参数，记录着目标receiver的信息。可以看到，递送静态receiver时，是不会用到RecevierDispatcher的。
用户进程里handleMessage()
|
1
2
3
4
5
6
|
case
RECEIVER:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER,
"broadcastReceiveComp"
);
handleReceiver((ReceiverData)msg.obj);
maybeSnapshot();
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break
;
|
ActivityThread中，会运用反射机制，创建出BroadcastReceiver对象，而后回调该对象的onReceive()成员函数。
|
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
|
private
void
handleReceiver(ReceiverData data)
{
. . . . . .
IActivityManager mgr = ActivityManagerNative.getDefault();
BroadcastReceiver receiver;
try
{
java.lang.ClassLoader cl = packageInfo.getClassLoader();
data.intent.setExtrasClassLoader(cl);
data.setExtrasClassLoader(cl);
receiver = (BroadcastReceiver)cl.loadClass(component).newInstance();
}
catch
(Exception e) {
. . . . . .
}
try
{
. . . . . .
receiver.setPendingResult(data);
receiver.onReceive(context.getReceiverRestrictedContext(), data.intent);
}
catch
(Exception e) {
. . . . . .
}
finally
{
sCurrentBroadcastIntent.set(
null
);
}
if
(receiver.getPendingResult() !=
null
) {
data.finish();
}
}
|
3.2.2.2 必要时启动新进程
现在我们回过头来看，在目标进程尚未启动的情况下，是如何完成递送的。刚刚我们已经看到调用startProcessLocked()的句子了，只要不出问题，目标进程成功启动后就会调用AMS的attachApplication()。
有关attachApplication()的详情，请参考其他关于AMS的文档，此处我们只需知道它里面又会调用attachApplicationLocked()函数。
|
1
|
private
final
boolean
attachApplicationLocked(IApplicationThread thread,
int
pid)
|
attachApplicationLocked()内有这么几句：
|
1
2
3
4
5
6
7
8
9
|
// Check if a next-broadcast receiver is in this process...
if
(!badApp && isPendingBroadcastProcessLocked(pid)) {
try
{
didSomething = sendPendingBroadcastsLocked(app);
}
catch
(Exception e) {
// If the app died trying to launch the receiver we declare it 'bad'
badApp =
true
;
}
}
|
它们的意思是，如果新启动的进程就是刚刚mPendingBroadcast所记录的进程的话，此时AMS就会执行sendPendingBroadcastsLocked(app)一句。
|
1
2
3
4
5
6
7
8
|
// The app just attached; send any pending broadcasts that it should receive
boolean
sendPendingBroadcastsLocked(ProcessRecord app) {
boolean
didSomething =
false
;
for
(BroadcastQueue queue : mBroadcastQueues) {
didSomething |= queue.sendPendingBroadcastsLocked(app);
}
return
didSomething;
}
|
BroadcastQueue的sendPendingBroadcastsLocked()函数如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
public
boolean
sendPendingBroadcastsLocked(ProcessRecord app) {
boolean
didSomething =
false
;
final
BroadcastRecord br = mPendingBroadcast;
if
(br !=
null
&& br.curApp.pid == app.pid) {
try
{
mPendingBroadcast =
null
;
processCurBroadcastLocked(br, app);
didSomething =
true
;
}
catch
(Exception e) {
. . . . . .
}
}
return
didSomething;
}
|
可以看到，既然目标进程已经成功启动了，那么mPendingBroadcast就可以赋值为null了。接着，sendPendingBroadcastsLocked()会调用前文刚刚阐述的processCurBroadcastLocked()，其内再通过app.thread.scheduleReceiver()，将语义发送到用户进程，完成真正的广播递送。这部分在上一小节已有阐述，这里就不多说了。
3.2.3 说说有序广播是如何循环起来的？
我们知道，平行广播的循环很简单，只是在一个while循环里对每个动态receiver执行deliverToRegisteredReceiverLocked()即可。而对有序广播来说，原则上每次processNextBroadcast()只会处理一个BroadcastRecord的一个receiver而已。当然，此时摘下的receiver既有可能是动态注册的，也有可能是静态的。
对于动态注册的receiver，目标进程处理完广播之后，会间接调用am.finishReceiver()向AMS发出反馈，关于这一步，其实在前面罗列ReceiverDispatcher的performReceive()时已经出现过了，我们再列一下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public
void
performReceive(Intent intent,
int
resultCode,
String data, Bundle extras,
boolean
ordered,
boolean
sticky)
{
. . . . . .
Args args =
new
Args(intent, resultCode, data, extras, ordered, sticky);
if
(!mActivityThread.post(args))
{
if
(mRegistered && ordered)
{
IActivityManager mgr = ActivityManagerNative.getDefault();
. . . . . .
args.sendFinished(mgr);
// 请注意这一句！
}
}
}
|
Args继承于BroadcastReceiver.PendingResult，它调用的sendFinished()就是PendingResult的sendFinished()：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
public
void
sendFinished(IActivityManager am)
{
synchronized
(
this
) {
if
(mFinished) {
throw
new
IllegalStateException(
"Broadcast already finished"
);
}
mFinished =
true
;
try
{
if
(mResultExtras !=
null
) {
mResultExtras.setAllowFds(
false
);
}
if
(mOrderedHint) {
am.finishReceiver(mToken, mResultCode, mResultData, mResultExtras,
mAbortBroadcast);
}
else
{
// This broadcast was sent to a component; it is not ordered,
// but we still need to tell the activity manager we are done.
am.finishReceiver(mToken,
0
,
null
,
null
,
false
);
}
}
catch
(RemoteException ex) {
}
}
}
|
代码中的am.finishReceiver()会通知AMS，表示用户侧receiver已经处理好了，或者至少告一段落了，请AMS进行下一步动作。
而对于动态注册的receiver，情况是类似的，最终也是调用am.finishReceiver()向AMS发出回馈的，只不过发起的动作是在ActivityThread的handleReceiver()动作中。前文已经列过这个函数了，大家注意下面的句子即可：
|
1
2
3
4
5
6
7
8
9
10
11
|
private
void
handleReceiver(ReceiverData data)
{
. . . . . .
receiver.setPendingResult(data);
receiver.onReceive(context.getReceiverRestrictedContext(),
data.intent);
. . . . . .
if
(receiver.getPendingResult() !=
null
) {
data.finish();
}
}
|
ReceiverData也是继承于BroadcastReceiver.PendingResult的，它调用的finish()是PendingResult的finish()：
|
1
2
3
4
5
6
7
8
9
10
11
|
public
final
void
finish()
{
if
(mType == TYPE_COMPONENT) {
. . . . . .
}
else
if
(mOrderedHint && mType != TYPE_UNREGISTERED) {
if
(ActivityThread.DEBUG_BROADCAST) Slog.i(ActivityThread.TAG,
"Finishing broadcast to "
+ mToken);
final
IActivityManager mgr = ActivityManagerNative.getDefault();
sendFinished(mgr);
}
}
|
此处的sendFinished()内部最终也会调用到am.finishReceiver()，向AMS通告receiver已经处理好了。
AMS侧在收到finishReceiver语义后，执行：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public
void
finishReceiver(IBinder who,
int
resultCode, String resultData,
Bundle resultExtras,
boolean
resultAbort)
{
. . . . . .
try
{
boolean
doNext =
false
;
BroadcastRecord r =
null
;
synchronized
(
this
) {
r = broadcastRecordForReceiverLocked(who);
if
(r !=
null
) {
doNext = r.queue.finishReceiverLocked(r, resultCode,
resultData, resultExtras, resultAbort,
true
);
}
}
if
(doNext) {
r.queue.processNextBroadcast(
false
);
}
trimApplications();
}
finally
{
Binder.restoreCallingIdentity(origId);
}
}
|
可以看到，如有必要，会继续调用processNextBroadcast()，从而完成有序广播的循环处理。
3.2.4 说说有序广播的timeout处理
因为AMS很难知道一次广播究竟能不能完全成功递送出去，所以它必须实现一种“时限机制”。前文在阐述broadcastIntentLocked()时，提到过new一个BroadcastRecord节点，并插入一个BroadcastQueue里的“平行列表”或者“有序列表”。不过当时我们没有太细说那个BroadcastQueue，现在我们多加一点儿说明。
实际上系统中有两个BroadcastQueue，一个叫做“前台广播队列”，另一个叫“后台广播队列”，在AMS里是这样定义的：
|
1
2
|
BroadcastQueue mFgBroadcastQueue;
BroadcastQueue mBgBroadcastQueue;
|
为什么要搞出两个队列呢？我认为这是因为系统对“广播时限”的要求不同导致的。对于前台广播队列而言，它里面的每个广播必须在10秒之内把广播递送给receiver，而后台广播队列的时限比较宽，只需60秒之内递送到就可以了。具体时限值请看BroadcastQueue的mTimeoutPeriod域。注意，这个10秒或60秒限制是针对一个receiver而言的。比方说“前台广播队列”的某个BroadcastRecord节点对应了3个receiver，那么在处理这个广播节点时，只要能在30秒（3 x 10）之内搞定就可以了。事实上，AMS系统考虑了更多东西，所以它给一个BroadcastRecord的总时限是其所有receiver时限之和的2倍，在此例中就是60秒（2 x 3 x 10）。
对于平行receiver而言，时限的作用小一点儿，因为动态receiver是直接递送到目标进程的，它不考虑目标端是什么时候处理完这个广播的。
然而对于有序receiver来说，时限就比较重要了。因为receiver之间必须是串行处理的，也就是说上一个receiver在没处理完时，系统是不会让下一个receiver进行处理的。从processNextBroadcast()的代码来看，在处理有序receiver时，BroadcastRecord里的nextReceiver域会记录“下一个应该处理的receiver”的标号。只有在BroadcastRecord的所有receiver都处理完后，或者BroadcastRecord的处理时间超过了总时限的情况下，系统才会把这个BroadcastRecord节点从队列里删除。因此我们在processNextBroadcast()里看到的获取当前BroadcastRecord的句子是写死为r = mOrderedBroadcasts.get(0)的。
在拿到当前BroadcastRecord之后，利用nextReceiver值拿到当前该处理的receiver信息：
|
1
2
3
|
int
recIdx = r.nextReceiver++;
. . . . . .
Object nextReceiver = r.receivers.get(recIdx);
|
当然，一开始，nextReceiver的值只会是0，表示第一个receiver有待处理，此时会给BroadcastRecord的dispatchTime域赋值。
|
1
2
3
4
5
6
|
int
recIdx = r.nextReceiver++;
r.receiverTime = SystemClock.uptimeMillis();
if
(recIdx ==
0
) {
r.dispatchTime = r.receiverTime;
r.dispatchClockTime = System.currentTimeMillis();
. . . . . .
}
|
也就是说，dispatchTime的意义是标记实际处理BroadcastRecord的起始时间，那么这个BroadcastRecord所能允许的最大时限值就是：
dispatchTime + 2 * mTimeoutPeriod * 其receiver总数
一旦超过这个时限，而BroadcastRecord又没有处理完，那么就强制结束这个BroadcastRecord节点：
|
1
2
3
4
5
6
7
8
|
if
((numReceivers >
0
) &&
(now > r.dispatchTime + (
2
*mTimeoutPeriod*numReceivers)))
{
. . . . . .
broadcastTimeoutLocked(
false
);
// forcibly finish this broadcast
forceReceive =
true
;
r.state = BroadcastRecord.IDLE;
}
|
此处调用的broadcastTimeoutLocked()的参数是boolean fromMsg，表示这个函数是否是在处理“时限消息”的地方调用的，因为当前是在processNextBroadcast()函数里调用broadcastTimeoutLocked()的，所以这个参数为false。从这个参数也可以看出，另一处判断“处理已经超时”的地方是在消息处理机制里，在那个地方，fromMsg参数应该设为true。
大体上说，每当processNextBroadcast()准备递送receiver时，会调用setBroadcastTimeoutLocked()设置一个延迟消息：
|
1
2
3
|
long
timeoutTime = r.receiverTime + mTimeoutPeriod;
. . . . . .
setBroadcastTimeoutLocked(timeoutTime);
|
setBroadcastTimeoutLocked()的代码如下：
|
1
2
3
4
5
6
7
8
|
final
void
setBroadcastTimeoutLocked(
long
timeoutTime)
{
if
(! mPendingBroadcastTimeoutMessage)
{
Message msg = mHandler.obtainMessage(BROADCAST_TIMEOUT_MSG,
this
);
mHandler.sendMessageAtTime(msg, timeoutTime);
mPendingBroadcastTimeoutMessage =
true
;
}
}
|
只要我们的receiver能及时处理广播，系统就会cancel上面的延迟消息。这也就是说，但凡事件泵的handleMessage()开始处理这个消息，就说明receiver处理超时了。此时，系统会放弃处理这个receiver，并接着尝试处理下一个receiver。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
final
Handler mHandler =
new
Handler()
{
public
void
handleMessage(Message msg) {
switch
(msg.what)
{
. . . . . .
case
BROADCAST_TIMEOUT_MSG:
{
synchronized
(mService)
{
broadcastTimeoutLocked(
true
);
}
}
break
;
}
}
};
|
broadcastTimeoutLocked()的代码截选如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
final
void
broadcastTimeoutLocked(
boolean
fromMsg)
{
if
(fromMsg) {
mPendingBroadcastTimeoutMessage =
false
;
}
if
(mOrderedBroadcasts.size() ==
0
) {
return
;
}
long
now = SystemClock.uptimeMillis();
BroadcastRecord r = mOrderedBroadcasts.get(
0
);
. . . . . .
. . . . . .
finishReceiverLocked(r, r.resultCode, r.resultData,
r.resultExtras, r.resultAbort,
true
);
scheduleBroadcastsLocked();
. . . . . .
}
|
可以看到，当一个receiver超时后，系统会放弃继续处理它，并再次调用scheduleBroadcastsLocked()，尝试处理下一个receiver。
4 尾声
有关Android的广播机制，我们就先说这么多吧。品一杯红茶，说一段代码，管他云山雾罩，任那琐碎冗长，我自冷眼看安卓，瞧他修短随化。
扫一扫
3438
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
