根据App包名 & uid 通过时间点附近的上下文找到App的pid
下面仅举例（其他方式获取也可以）
- Package [.weather2] (5c2d4cd):
userId=10072
表示天气的uid为10072
- 08-05 12:26:47.543 10072 26818 26818 I wm_on_create_called:[0,.,performCreate,86]
表示天气App的uid为10072,pid为26818,主线程tid为26818
查看主线程 相关时间点附近是否有耗时操作
- 明确的App的Activity的生命周期耗时（onCreate- onDestroy）
- 08-04 07:53:02.665 10219 4962 4962 W Activity: Slow Operation: Activity /.SetupWizardActivity onCreate took 724ms
客户端的onCreate方法耗时724ms - 08-05 12:26:47.566 10243 26840 26840 I am_lifecycle_sample: [0,,110,3038]
what=110的消息耗时3038ms
- 主线程执行消息耗时
8-05 12:26:47.449 10072 26818 26818 W Looper : Slow Looper main: Long Msg: seq=2 plan=12:26:44.465 late=5ms wall=2978ms running=109ms runnable=3ms h=
H
w
=
110
p
r
o
c
S
t
a
t
e
=
208
−
2812
:
49
:
47.2291030522812281
W
L
o
o
p
e
r
:
S
l
o
w
L
o
o
p
e
r
m
a
i
n
:
L
o
n
g
M
s
g
:
s
e
q
=
2362
p
l
a
n
=
12
:
49
:
39.186
l
a
t
e
=
2538
m
s
∗
∗
w
a
l
l
=
5435
m
s
∗
∗
r
u
n
n
i
n
g
=
316
m
s
r
u
n
n
a
b
l
e
=
59
m
s
∗
∗
i
o
=
4979
m
s
∗
∗
b
i
n
d
e
r
=
9
m
s
s
l
o
w
p
a
t
h
=
1
m
s
h
=
a
n
d
r
o
i
d
.
v
i
e
w
.
C
h
o
r
e
o
g
r
a
p
h
e
r
H w=110 procState=2 08-28 12:49:47.229 10305 2281 2281 W Looper : Slow Looper main: Long Msg: seq=2362 plan=12:49:39.186 late=2538ms **wall=5435ms** running=316ms runnable=59ms **io=4979ms** binder=9ms slowpath=1ms h=
Hw=110procState=208−2812:49:47.2291030522812281WLooper:SlowLoopermain:LongMsg:seq=2362plan=12:49:39.186late=2538ms∗∗wall=5435ms∗∗running=316msrunnable=59ms∗∗io=4979ms∗∗binder=9msslowpath=1msh=android.view.ChoreographerFrameHandler c=$FrameDisplayEventReceiver
主线程执行what为110（BIND_APPLICATION，去ActivityThread类查找what）耗时2978ms，但是running和runnable时间比较短，procState为miui加上的，代表进程优先级
- 主线程binder耗时
- 05-18 07:15:08.088 10104 30177 30177 W BpBinder: Slow Binder: BpBinder transact took 7742ms, interface=, code=1 oneway=false
调用IContentProvider的transaction code为1（去中查找1 ）的接口耗时7742ms - 03-24 09:57:04.057 1000 4243 4243 I binder_sample: [,48,**4001,**,100]
主线程4243 执行IWifiManager code 48 耗时 4001ms
- 掉帧
08-28 12:49:48.551 10305 2281 2281 I Choreographer: Skipped 602 frames! The application may be doing too much work on its main thread.
system server端dvm_lock_sample
如果客户端有与system server的binder耗时，可查看相关的system server等锁相关
-
03-24 10:23:40.280 1000 1664 1694 I dvm_lock_sample: [system_server,1,Binder:1664_1,15987,,9978, (),-,16089,void (, int, , , boolean, int),8878]
system server的binder 1664_1线程 在执行到() 行数为9978时一直在等待ams锁
该锁被同一个文件的finishReceiver 的 16089行持有，导致Binder:1664_1 线程阻塞15987ms（- 代表同一个文件），最后一个8878被miui修改成了tid -
monitor contention with owner Binder:1547_E (2818) at (, , , , , , boolean, int, boolean, int, int, , )(:213) waiters=8 in boolean () for 1420.999s