转载地址:http://blog.csdn.net/chenqian_lj/article/details/17956039
1) 对上面的方式进行总结
从AMS--> WMS-->PMS --> StatusbarManagerService--> CommandQueue(callback) -->
PhoneStatusBar
也许有人会说,这样的调用很繁琐,为啥不用广播呢?
原因很直接:广播显然是在不同的线程里面,这样做不能保证窗口同步刷新,layout以后的后果未知
2) 修改当然也会有问题,问题的发生在Launcher和应用切换间。Navigationbar的添加与否会影响Configuration的变化,这里的Configuration不单包括oritation的变化(其实这里没有oritation的变化),在实际中自写Launcher没有NV bar,android的原生应用有NV bar,发现一个问题,在从MMs返回自写Launcher时,会重新调用Launcher的onCreate函数,导致原本进入了GridView
的,结果停留在Home的壁纸界面;而其它的应用如计算器就会直接进如gridview页面。问题的原因就是由于应用的fullscreen和Launcher 的Configuration变化引起的。
a. 解释下MMs和计算器的区别,实际上就是fullscreen的区别,通常来说和透明度相关
详细参见ActivityRecord()@ActivityRecord.java
MMs: fullscreen == false
Caculator: fullscreen == true
b. 解释下上面问题的原因,想象一下这样的情景,从GridView进入MMS中,
1)Launcher(fullscreen) Paused
2)launch MMs, Resumed
3)由于MMs不是fullscreen,所以在ensureActivitiesVisibleLocked中会去检查当前的top应用是否全屏
,如果不是全屏,则会把下边的Acitivity show出来,此刻,下面的Activity为Launcher,而且Launcher一直是启动的,所以这里调用relaunchActivityLocked,这会导致重新的onCreate
: java.lang.Exceptioncom.android.server.am.ActivityStack.relaunchActivityLocked(ActivityStack.java:5374)
: at com.android.server.am.ActivityStack.ensureActivityConfigurationLocked(ActivityStack.java:5339)
: at com.android.server.am.ActivityStack.ensureActivitiesVisibleLocked(ActivityStack.java:1607)
: at com.android.server.am.ActivityStack.ensureActivitiesVisibleLocked(ActivityStack.java:1727)
: at com.android.server.am.ActivityStack.completeResumeLocked(ActivityStack.java:1538)
: at com.android.server.am.ActivityStack.realStartActivityLocked(ActivityStack.java:865)
: at com.android.server.am.ActivityManagerService.attachApplicationLocked(ActivityManagerService.java:4958)
: at com.android.server.am.ActivityManagerService.attachApplication(ActivityManagerService.java:5027)
: at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:387)
: at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1908)
: at android.os.Binder.execTransact(Binder.java:351)
: at dalvik.system.NativeStart.run(Native Method)
4) 正常情况下,就算对Launcher调用了ensureActivityConfigurationLocked
也不会刷新屏幕,从而进入launcher的onCeate流程,原因在下面就返回了:
if (r.configuration == newConfig && !r.forceNewConfig) {
if (DEBUG_SWITCH || DEBUG_CONFIGURATION) Slog.v(TAG,
"Configuration unchanged in " + r);
return true;
}
但是这里Navigation bar的从有到无必然会导致前面所说的Configuration的变化,Configuration的变化如下:
ensureActivityConfigurationLocked@ActivityStack.java
01-0410:05:30.888 617 1306 V kkkk :
newConfig = {1.0 ?mcc?mnc en_USldltr sw360dp w360dp h567dp 320dpi nrml port finger -keyb/v/h -nav/hskin=/system/framework/framework-res.apk s.9},
r.configuration = {1.0?mcc?mnc en_US ldltr sw360dp w360dp h615dp 320dpi nrml long portfinger -keyb/v/h -nav/h skin=/system/framework/framework-res.apks.8}, r.forceNewConfig = false
细心的读者可能发现屏幕的高度h567dp 和 h615dp 发生了变化,差别就是NavigationBar的高度,由于这样原因,这下真的就要调用relaunchActivityLocked来刷新后面的Activity了(Launcher)
问题的原因已经分析出来,修改也就简单了
final boolean ensureActivityConfigurationLocked(ActivityRecord r,
int globalChanges) {
if ((changes&(~r.info.getRealConfigChanged())) != 0 || r.forceNewConfig) {
if ((r.packageName.contains("com.your.packagename")
&& (changes == 0x500 || changes == 0x580))) {
// cancel relauncher ifyour package
r.configChangeFlags = 0;
//r.stopFreezingScreenLocked(false);
return true;
}
....
}
}