怎么控制一个APK让其隐藏不显示（后台运行不销毁）和最大化运行（前台运行不再创建），并且这样切换不重新加载APK

Question

怎么控制一个APK让其隐藏不显示（后台运行不销毁）和最大化运行（前台运行不再创建），并且这样切换不重新加载APK

Answer 1

如果是activity的话，可以把主要非UI功能部分都放在线程或者service里执行，这样就算应用切换到后台，服务和线程还是在后台跑的。

Answer 2

如果为了缓存加载activity速度，可以考虑一开始onCreate就执行finish，如果后台内存不吃紧的话，短期内不会被kill掉，关键你要干什么，帮你分析下

Answer 3

我就是为了实现多个APK来回自如地在前后台切换！！！

Answer 4

这就是android应用程序的默认行为啊
只要你机器内存够的话，就是这样的。如果内存不足，系统会杀掉后台的activity。
当然，如果系统内存不够的话，你还想要这样的效果，不杀后台程序，那只能是系统死机了或当前程序不能运行了 ：）

Answer 5

那里，你如果用INTENT去不断STARTACTIVITY（ ）一个APK的话，会创建这个APK的很多实例，那怕这个APK被设置为SIGNLEINSTANCE属性。

Answer 6

虽然每次恢复运行会进入OnCreate( )但带进来的saveInstanceState参数是不一样的，通过判断这个saveInstanceState参数我们可以知道是不是第1次运行还是简单的直接恢复运行。//【eoeAndroid特刊】第五期 Android widget.pdf中提到了C/C++ code
7.3 首先，我们来说1——如何动态更新当前显示的Activity
如果是传统的开发，或许您会说那很简单，把每个屏幕上元素的字符都重设一遍就好了。是的，
这么做是很简单，但我不得不说，它的工作量和维护成本实在是不可预知的；而且，除了字符，
在其它方面，如layout、drawable 等，都可能受Locale 影响。所以，我们需要一种更通用、
更简洁的方法。
应该注意，下面我介绍的方法，是即使在Google 的android 讨论组里也搜不到的。那么这个
方法是什么呢？那就是重新启动一个Activity。
或许您会觉得这个方法消耗过大，但如果您想到，其实android 屏幕方向改变都能导致Activity
重起也就释然了。而且，这个方法我其实借用了一个假设，那就是大家都已经了解、考虑并且为
了Activity 的生命周期做出了一定的努力， 已经良好的实现了
onRestoreInstanceState(savedInstanceState) 和onSaveInstanceState(bundle)。当
然，如果您的应用根本不担心生命周期，那么你就更没问题了。但如果您的应用在生命周期这一
问题上，还有问题，那很遗憾，您最好还是先把生命周期这个严重的问题搞好吧。下面我们就来
看代码，实现方法如下。
首先，在用户改变语言区域后，调用如下代码
Locale locale = getLocaleFormPreference(this);
Configuration cfg = getResources().getConfiguration();
if(locale!=null && !locale.equals(cfg.locale)) {
Bundle bundle = new Bundle();
onSaveInstanceState(bundle);
Intent intent = getIntent();
intent.putExtra("InstanceState", bundle);
intent.addFlags(Intent.FLAG_ACTIVITY_FORWARD_RESULT);
startActivity(intent);
finish();
}
之后，在被启动的Activity 的onCreate(Bundle savedInstanceState)的最后位置运行下面
的代码：
if(savedInstanceState == null) {
savedInstanceState =
getIntent().getBundleExtra("InstanceState");
if(savedInstanceState != null) {
onRestoreInstanceState(savedInstanceState);
}
}
下面，我再为大家一行一行的，讲解一下这两段代码：
• 首先，我们在第1 段代码的前4 行对Locale 进行了一下判断，使得只在Locale 发生
变化的情况下，才重起Activity。
• 之后，5~8 行，我们手动调了的onSaveInstanceState(bundle)方法，获得了恢复
Activity 所需要的信息，并以"InstanceState"为Key 存入了Intent。
• 第9 行，我们为Intent 添加了一个flag——FLAG_ACTIVITY_FORWARD_RESULT。
这一步，是可选的，目的是如果当前的Activity 需要给启动它的Activity 一个回复的
code 时，由它新启动的Activity 来回复。
• 最后10~11 行是启动新的Activity 并终止当前的。
• 而第2 段代码则是通过判断savedInstanceState 来选择和模拟系统restart 一个
Activity 的过程。因为默认新启动Activity 时，savedInstanceState 是空的，而重启
动时savedInstanceState 会带有信息，因此我们可以这样去模拟。
这里，同样有两点需要注意：
1. 这段代码需要在根Activity 上执行，如果您应用了ActivityGroup 并需要在child 上执
行更新操作。请相应更改第一段代码的第6、7 行，调用根Activity 上的方法。而第2
段代码，仍然放在根Activity 的onCreate(Bundle savedInstanceState)里。
2. 如果您处理生命周期的操作，除了在onRestoreInstanceState()里，其他地方，也有
操作，请自行想办法，按照您需要的顺序模拟restart 操作。

Answer 7

可能真的是这样，看来还没理解ANDROID的机制啊！！！

Answer 8

今天观察了一下，其实也不是这样的。随便跑几个小的APK来做来回切换的实验，还就是会看到有些APK被反复的ONDESTROY（ ）+ONCREATE（ ）。但有些就只是onPause( )+onResume( )而已。这样的情况有可以发生于同一个APK上。比如：A+B做来回切换，A会不断ONDESTROY（ ）+ONCREATE（ ）----被推毁下次只能重新创建运行。      A+C做来回切换，A会只是不断onPause( )+onResume( )而已

Answer 9

不过同时也看到了ANDROID系统报内存不足出来，在进行内存的动态调整，也许真的就是因为内存不够从而倒致有的APK被杀掉了，被ONDESTROY（）掉了。

Answer 10

报下面的内存调整消息E/SurfaceComposerClient(  182): surface (id=6, identity=9) is invalid, err=-12 (Out of memory)
W/WindowManager(  182): Failure showing surface Surface(native-token=2564352) in Window{43a8d9d0 Starting com.KT.MAP100_AppSwitch paused=false}
I/WindowManager(  182): Out of memory for surface!  Looking for leaks...
W/WindowManager(  182): No leaked surfaces; killing applicatons!
W/ActivityManager(  182): Killing processes for memory at adjustment 7
W/ActivityManager(  182): Killing for memory: ProcessRecord{439d71e8 325:com.KT.MAP100_MainProc/10023} (adj 7)
I/Process (  182): Sending signal. PID: 325 SIG: 9
W/WindowManager(  182): Looks like we have reclaimed some memory, clearing surface for retry.
W/SurfaceComposerClient(  182): Destroying surface while a transaction is open. Client 0x1feab0: destroying surface 6, mTransactionOpen=1
E/SurfaceFlinger(  182): not enough memory for layer bitmap size=770048 (w=800, h=480, stride=800, format=4)
D/MemoryDealer(  182):   LayerBitmap (0x1febf0, size=8388608)
D/MemoryDealer(  182):     0: 001fec28 | 0x00000000 | 0x000B2000 | A 
D/MemoryDealer(  182):     1: 0024ec70 | 0x000B2000 | 0x0000A000 | A 
D/MemoryDealer(  182):     2: 00233328 | 0x000BC000 | 0x000BC000 | A 
D/MemoryDealer(  182):     3: 00200870 | 0x00178000 | 0x000BC000 | A 
D/MemoryDealer(  182):     4: 00235420 | 0x00234000 | 0x000B2000 | A 
D/MemoryDealer(  182):     5: 002013f8 | 0x002E6000 | 0x0000A000 | F 
D/MemoryDealer(  182):     6: 0023fd80 | 0x002F0000 | 0x0000A000 | A 
D/MemoryDealer(  182):     7: 0024ec28 | 0x002FA000 | 0x000BC000 | A 
D/MemoryDealer(  182):     8: 0023bb28 | 0x003B6000 | 0x000BC000 | A 
D/MemoryDealer(  182):     9: 0025c068 | 0x00472000 | 0x000BC000 | A 
D/MemoryDealer(  182):    10: 002064f8 | 0x0052E000 | 0x000BC000 | A 
D/MemoryDealer(  182):    11: 00209b08 | 0x005EA000 | 0x000BC000 | A 
D/MemoryDealer(  182):    12: 00258858 | 0x006A6000 | 0x000BC000 | A 
D/MemoryDealer(  182):    13: 00277be0 | 0x00762000 | 0x0009E000 | F 
D/MemoryDealer(  182):   size allocated: 7700480 (7520 KB)
E/SurfaceFlinger(  182): createNormalSurfaceLocked() failed (Out of memory)
W/WindowManager(  182): OutOfResourcesException creating surface
I/WindowManager(  182): Out of memory for surface!  Looking for leaks...
W/WindowManager(  182): No leaked surfaces; killing applicatons!
W/ActivityManager(  182): Killing processes for memory at adjustment 7也许内存不是很够！！！才会造成上面的现象----有的APK必须被反复KILL（因为它太占内存了，不杀它其它的APK压根没空间运行），而有的APK因为不怎么占内存，所以系统也就不去过问了，也就不KILL它了。

Answer 11

看到这个消息又像是因为不能加载800*480的图片一样！！！我的800*480的图片也不大啊！才373KB的样子。E/SurfaceFlinger(  182): not enough memory for layer bitmap size=770048 (w=800, h=480, stride=800, format=4)
D/MemoryDealer(  182):   LayerBitmap (0x1febf0, size=8388608)