来源: 互联网  发布时间: 2014-02-18

Application Fundamentals--Component Lifecycles（组件生命周期）
Component Lifecycles--组件生命周期

Application components have a lifecycle — a beginning when Android instantiates them to respond to intents through to an end when the instances are destroyed. In between, they may sometimes be active or inactive,or, in the case of activities, visible to the user or invisible. This section discusses the lifecycles of activities, services, and broadcast receivers — including the states that they can be in during their lifetimes, the methods that notify you of transitions between states, and the effect of those states on the possibility that the process hosting them might be terminated and the instances destroyed.

翻译：组件是有生命周期的，一个组件的生命周期的起点是Android系统为了响应一个intent对象的请求而该组件的一个实例，终点是该组件实例被Android系统销毁。这期间，组件实例有时候是活动状态，有时候是处于睡眠状态，对于Activity组件实例而言所谓活动状态即用户可以看到该 Activity的用户界面，休眠状态就是用户看不到用户界面的时候。这一章节中我们将重点讨论组件生命周期、组件实例在生命周期中的各种可能状态、组件实例状态发生变换时将要触发的不同函数以及不同状态导致宿主进程终止并销毁该组件实例的可能性。
Activity lifecycle--Activity组件的生命周期

An activity has essentially three states:翻译：Activity组件有三种状态

    * It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user's actions.【翻译：活动状态或称之为运行状态，这时候Activity实例的界面显示在当前屏幕上，此时这个Activity实例在当前task堆栈中处于栈顶位置。】
    *

      It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen, so some of the paused activity can show through. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.【翻译：暂停状态，暂停状态的Activity实例失去了用户焦点，但是依然是用户可见状态,此时堆栈中已有了另一个Activity实例处于这个实例的上面，但是新的实例的用户界面还没有占据当前屏幕，暂停状态的 Activity依然持有所有自身状态信息并且与窗体管理对象依然保持关联，但是如果说系统出现内存极端不足的话，系统是可以销毁该实例的。】
    *

      It is stopped if it is completely obscured by another activity. It still retains all state and member information. However, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.【翻译：停止状态，停止状态的activity实例的用户界面已经完全被另外一个实例的界面所掩盖，但它依然持有所有的状态信息，不过，对于用户来说已经是不可见的了。如果说系统出现内存不足的话，系统是可以销毁该实例的。】

If an activity is paused or stopped, the system can drop it from memory either by asking it to finish (calling its finish() method), or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.

翻译：一旦一个activity的状态是暂停状态或是停止状态，系统就可以调用该实例的finish()方法以便从内存中销毁该实例，或者是直接杀死该实例的进程。之后如果该activity实例需要重新显示在屏幕上，必须彻底重新启动实例并恢复实例之前的状态。

As an activity transitions from state to state, it is notified of the change by calls to the following protected methods（翻译：activity的状态发生变化的时候，以下方法(七个)将被系统调用：）:

void onCreate(Bundle savedInstanceState)
void onStart()
void onRestart()
void onResume()
void onPause()
void onStop()
void onDestroy()

All of these methods are hooks that you can override to do appropriate work when the state changes. All activities must implement onCreate() to do the initial setup when the object is first instantiated. Many will also implement onPause() to commit data changes and otherwise prepare to stop interacting with the user.

翻译：这些方法可以被开发者override，以便当状态变化时执行相应的操作。所有的activity类都必须实现onCreate()方法，这个方法是实例的初始化方法，很多activity同时还实现了onPause() 方法，实现这个方法的目的是及时提交最新数据或者是为停止与用户交互做必要的准备（因为某个activity实例的状态切换到暂停状态的时候，系统将调用该实例的onPause()方法，换句话说activity实例在暂停与用户交互前，该方法将被系统调用执行。）。

Calling into the superclass

An implementation of any activity lifecycle method should always first call the superclass version. For example:【翻译：实现activity的任何生命周期方法的时候都必须首先调用父类的方法，例如：】

protected void onPause() {
    super.onPause();
    . . .
}

Taken together, these seven methods define the entire lifecycle of an activity. There are three nested loops that you can monitor by implementing them:

翻译：Activity整个生命周期中一共定义了七个方法，Activity整个生命周期中有三个内部状态循环圈，实现这七个方法可以监视这三个内部状态循环圈。

    * The entire lifetime of an activity happens between the first call to onCreate() through to a single final call to onDestroy(). An activity does all its initial setup of "global" state in onCreate(), and releases all remaining resources in onDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread in onDestroy().

      翻译：1、整个生命周期 ：activity的生命周期起于onCreate()方法被调用（建立初始状态），终止于onDestroy()被调用（释放持有的资源），例如：如果一个activity需要在另外一个线程中在后台下载网络数据，可以在 onCreate()方法中创建一个线程执行下载网络数据的操作，在onDestroy()方法中应该终止该线程。
    *

      The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time, the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods, you can maintain resources that are needed to show the activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user can no longer see what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity alternates between being visible and hidden to the user.

      翻译：2、可视生命周期：activity的可视生命周期起于onStart()方法被调用，终止于onStop()方法被调用。整个可视生命周期中，activity的界面在屏幕上是用户可见的，此时这个activity也许不在前台与用户发生交互。例如，你可以在onStart()方法中注册一个BroadcastReceiver用来监视当前界面的变化，在onStop()方法中注销曾经注册的那个BroadcastReceiver，因为这时候用户已经看不到这个组件的界面了。这两个方法可能被系统多次调用，这是因为activity的UI界面对于用户来说经常是时而可见，时而不可见。
    *

      The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states — for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered. Therefore, the code in these two methods should be fairly lightweight.

      翻译：3、前台生命周期：activity的前台生命周期起于onResume()方法被调用，终止于 onPause()方法被调用。整个前台生命周期中，此时的activity处于其他activity之前（task堆栈栈顶元素的角色）、显示在当前屏幕上与用户做交互，activity实例可以重复在继续和暂停状态之间切换，例如在手机进入休眠状态的时候或是一个新的activity实例被启动的时候，onPause()方法就被系统调用执行，onResume()方法被调用的时候是当这个activity期望的结果被返回的时候或是当一个新的intent请求对象发送给这个activity实例的时候。所以，通常这两个方法中的代码应该是很简洁的。

The following diagram illustrates these loops and the paths an activity may take between states. The colored ovals are major states the activity can be in. The square rectangles represent the callback methods you can implement to perform operations when the activity transitions between states.【翻译：下图显示了activity生命周期中的状态变换过程，带颜色的椭圆形表示activity状态，方框是发生状态变化时的回调方法。】















Note the Killable column in the table above. It indicates whether or not the system can kill the process hosting the activity at any time after the method returns, without executing another line of the activity's code. Three methods (onPause(), onStop(), and onDestroy()) are marked "Yes." Because onPause() is the first of the three, it's the only one that's guaranteed to be called before the process is killed — onStop() and onDestroy() may not be. Therefore, you should use onPause() to write any persistent data (such as user edits) to storage.

翻译：要注意的是 是否实例所在的进程可以被系统杀死，onPause(), onStop(),和 onDestroy()三个方法在这点上是有区别的，系统要杀死实例所在的进程之前，实例的onPause()方法一定是会被系统调用的，但是其他两个方法不保证一定被系统调用，所以，如果需要及时保存数据，避免数据丢失，一定是在onPause()方法中做数据保存操作。

Methods that are marked "No" in the Killable column protect the process hosting the activity from being killed from the moment they are called. Thus an activity is in a killable state, for example, from the time onPause() returns to the time onResume() is called. It will not again be killable until onPause() again returns.

As noted in a later section, Processes and lifecycle, an activity that's not technically "killable" by this definition might still be killed by the system — but that would happen only in extreme and dire circumstances when there is no other recourse.

    

    来源: 互联网  发布时间: 2014-02-18

Application Fundamentals--Clearing the stack（堆栈清理）
Clearing the stack--堆栈清理

If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, it's as the user left it, except that only the initial activity is present. The idea is that, after a time, users will likely have abandoned what they were doing before and are returning to the task to begin something new.

翻译：如果用户长时间不操作界面,系统将会清除当前task堆栈中除了根Activity以外的所有实例，如果这时候用户回来，显示的界面是根Activity的界面。

That's the default. There are some activity attributes that can be used to control this behavior and modify it:

翻译：这是这种场景下系统清理当前task堆栈的默认策略，不过我们还是可以通过设定Activity（尤其是根Activity）的以下属性值来改变系统默认的堆栈清理策略：（事实上还有另外一种途径：通过设定intent的flag属性值来修改系统默认执行的堆栈清理策略，后面我们将会讲到。）

The alwaysRetainTaskState--总是保留当前task状态 attribute
    If this attribute is set to "true" in the root activity of a task, the default behavior just described does not happen. The task retains all activities in its stack even after a long period.
    翻译：如果一个task的根Activity的这个属性被设定为 "true"， 系统默认的task堆栈清理规则将失效，即使用户长时间离开操作界面也不会发生清理当前task堆栈中的Activity实例的系统操作。

The clearTaskOnLaunch---在发射台上清除task堆栈 attribute
    the stack is cleared down to the root activity whenever the user leaves the task and returns to it. In other words, it's the polar opposite of alwaysRetainTaskState. The user always returns to the task in its initial state, even after a momentary absence.
    翻译：如果一个task的根Activity的这个属性被设定为 "true"，只要用户离开哪怕是短暂离开操作界面，系统将清除堆栈清除根activity以外所有实例，回到task的初始状态。这个属性的作用和alwaysRetainTaskState完全相反。

The finishOnTaskLaunch attribute
    This attribute is like clearTaskOnLaunch, but it operates on a single activity, not an entire task. And it can cause any activity to go away, including the root activity. When it's set to "true", the activity remains part of the task only for the current session. If the user leaves and then returns to the task, it no longer is present.
    翻译：这个属性的作用与clearTaskOnLaunch有点相似,也会导致当前task堆栈发生清理动作， 但是这个属性只会清除堆栈中的一个Activity，不会清除整个task中的Activity实例。如果某个Activity的这个属性被设定为"true", 这个Activity被请求的时候，对应的实例依然是被压入当前task堆栈响应用户，但是，如果用户离开当前task，重新再回到这个task时，这个 Activity将从这个task堆栈中清除，task堆栈中其他Activity依然保留，即使这个Activity是根Activity也将被清除。我们可以这样理解：一个task和用户交互的过程中，如果启动了一个clearTaskOnLaunch属性值是"true"的Activity实例，该实例进人当前task堆栈，如果之后用户离开该task（该task退到后台），下次用户再次启动该task的时候，该task堆栈中这个Activity实例不再存在。

There's another way to force activities to be removed from the stack. If an Intent object includes the FLAG_ACTIVITY_CLEAR_TOP flag, and the target task already has an instance of the type of activity that should handle the intent in its stack, all activities above that instance are cleared away so that it stands at the top of the stack and can respond to the intent. If the launch mode of the designated activity is "standard", it too will be removed from the stack, and a new instance will be launched to handle the incoming intent. That's because a new instance is always created for a new intent when the launch mode is "standard".

翻译：还有另外一种强制清除task堆栈中部分实例的途径：可以在intent对象中设定flag属性=FLAG_ACTIVITY_CLEAR_TOP, 如果被请求的Activity实例恰好在当前task堆栈已经存在，那么Android系统将会把堆栈中该实例之上的所有其他实例清除掉，这样一来该实例自然成为当前task堆栈中的栈顶实例，由它直接响应intent请求，如果此时被请求的Activity实例的启动属性是standard，那么连同当前堆栈中的这个同类实例会被Android系统一并清除，然后，Android系统创建一个新的被请求实例压入堆栈来应答intent请求。这是因为一旦被请求的Activity实例的启动属性被设定为standard的话，系统总是会新建一个实例压入堆栈来应答intent请求的。

FLAG_ACTIVITY_CLEAR_TOP is most often used in conjunction with FLAG_ACTIVITY_NEW_TASK. When used together, these flags are a way of locating an existing activity in another task and putting it in a position where it can respond to the intent.

翻译：FLAG_ACTIVITY_CLEAR_TOP 和 FLAG_ACTIVITY_NEW_TASK常常是配合在一起使用的，它们俩个这样配合使用的真正目的是要求android系统从当前task以外的后台task堆栈中定位到一个已经存在的Activity实例，直接用该实例或是新建的该实例来响应intent。

    

    来源: 互联网  发布时间: 2014-02-18

基本上已经无用的防破解方法

//First Method
#import <dlfcn.h>
#import <mach-o/dyld.h>
#import <TargetConditionals.h>

/* The encryption info struct and constants are missing from the iPhoneSimulator SDK, but not from the iPhoneOS or
 * Mac OS X SDKs. Since one doesn't ever ship a Simulator binary, we'll just provide the definitions here. */
#if TARGET_IPHONE_SIMULATOR && !defined(LC_ENCRYPTION_INFO)
#define LC_ENCRYPTION_INFO 0x21
struct encryption_info_command {
    uint32_t cmd;
    uint32_t cmdsize;
    uint32_t cryptoff;
    uint32_t cryptsize;
    uint32_t cryptid;
};
#endif

int main (int argc, char *argv[]);

static BOOL is_encrypted () {
    const struct mach_header *header;
    Dl_info dlinfo;
	
    /* Fetch the dlinfo for main() */
    if (dladdr(main, &dlinfo) == 0 || dlinfo.dli_fbase == NULL) {
        NSLog(@"Could not find main() symbol (very odd)");
        return NO;
    }
    header = dlinfo.dli_fbase;
	
    /* Compute the image size and search for a UUID */
    struct load_command *cmd = (struct load_command *) (header+1);
	
    for (uint32_t i = 0; cmd != NULL && i < header->ncmds; i++) {
        /* Encryption info segment */
        if (cmd->cmd == LC_ENCRYPTION_INFO) {
            struct encryption_info_command *crypt_cmd = (struct encryption_info_command *) cmd;
            /* Check if binary encryption is enabled */
            if (crypt_cmd->cryptid < 1) {
                /* Disabled, probably pirated */
                return NO;
            }
			
            /* Probably not pirated? */
            return YES;
        }
		
        cmd = (struct load_command *) ((uint8_t *) cmd + cmd->cmdsize);
    }
	
    /* Encryption info not found */
    return NO;
}

//Second Method
#if !TARGET_IPHONE_SIMULATOR
int root = getgid();
if (root == 0) {
	exit(0);
}
#endif

//Third Method
#import <dlfcn.h>
#import <sys/types.h>

#import <Foundation/Foundation.h>
#import <TargetConditionals.h>


// The iPhone SDK doesn't have <sys/ptrace.h>, but it does have ptrace, and it
// works just fine.
typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
#if !defined(PT_DENY_ATTACH)
#define  PT_DENY_ATTACH  31
#endif  // !defined(PT_DENY_ATTACH)


void ZNDebugIntegrity() {
	// If all assertions are enabled, we're in a legitimate debug build.
#if TARGET_IPHONE_SIMULATOR || defined(DEBUG) || (!defined(NS_BLOCK_ASSERTIONS) && !defined(NDEBUG))
	return;
#endif
	
	// Lame obfuscation of the string "ptrace".
	char* ptrace_root = "socket";
	char ptrace_name[] = {0xfd, 0x05, 0x0f, 0xf6, 0xfe, 0xf1, 0x00};
	for (size_t i = 0; i < sizeof(ptrace_name); i++) {
		ptrace_name[i] += ptrace_root[i];
	}
	
	void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
	ptrace_ptr_t ptrace_ptr = dlsym(handle, ptrace_name);
	ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
	dlclose(handle);
}

//Fourth Method
#define kInfoSize 500
//Place your NSLog Plist Size into the above Define statment
NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
NSString* path = [NSString stringWithFormat:@"%@/Info.plist", bundlePath ];
NSDictionary *fileInfo = [[NSBundle mainBundle] infoDictionary];
NSFileManager *fileManager = [NSFileManager defaultManager];
NSDictionary *fileAttributes = [fileManager fileAttributesAtPath:path traverseLink:YES];

if (fileAttributes != nil) {
	NSNumber *fileSize;
	if(fileSize = [fileAttributes objectForKey:NSFileSize]){
		NSLog(@"File Size:  %qi\n", [fileSize unsignedLongLongValue]);
		//Best to see the File Size and change it accordingly first
		NSString *cSID = [[NSString alloc] initWithFormat:@"%@%@%@%@%@",@"Si",@"gne",@"rIde",@"ntity",@""];
		BOOL checkedforPir = false;
		if([fileInfo objectForKey:cSID] == nil || [fileInfo objectForKey:cSID] != nil) {
			if([fileSize unsignedLongLongValue] == kInfoSize) {
				checkedforPir = true;
			}
		}
		if(!checkedforPir){
			//Pirated
		}
		[cSID release];
	}
}

//Fifth Method
NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
NSString* path = [NSString stringWithFormat:@"%@/Info.plist", bundlePath];
NSString* path2 = [NSString stringWithFormat:@"%@/AppName", bundlePath];
NSDate* infoModifiedDate = [[[NSFileManager defaultManager] fileAttributesAtPath:path traverseLink:YES] fileModificationDate];
NSDate* infoModifiedDate2 = [[[NSFileManager defaultManager] fileAttributesAtPath:path2 traverseLink:YES] fileModificationDate];
NSDate* pkgInfoModifiedDate = [[[NSFileManager defaultManager] fileAttributesAtPath:[[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:@"PkgInfo"] traverseLink:YES] fileModificationDate];
if([infoModifiedDate timeIntervalSinceReferenceDate] > [pkgInfoModifiedDate timeIntervalSinceReferenceDate]) {	
	//Pirated
}
if([infoModifiedDate2 timeIntervalSinceReferenceDate] > [pkgInfoModifiedDate timeIntervalSinceReferenceDate]) {	
	//Pirated
}

//Sixth Method
NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
BOOL fileExists = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/_CodeSignature", bundlePath)];
if (!fileExists) {
	//Pirated
	NSLog(@"Pirated");
}
BOOL fileExists2 = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/CodeResources", bundlePath)];
if (!fileExists2) {
	//Pirated
	NSLog(@"Pirated2");
}
BOOL fileExists3 = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/ResourceRules.plist", bundlePath)];
if (!fileExists3) {
	//Pirated
	NSLog(@"Pirated3");
}

//Covert exits
close(0);
[[UIApplication sharedApplication] terminate];
[[UIApplication sharedApplication] terminateWithSuccess];
UIWebView *a = [UIWebView alloc];
UIWindow *b = [UIWindow alloc];
UIView *c = [UIView alloc];
UILabel *d = [UILabel alloc];
UITextField *e = [UITextField alloc];
UIImageView *f = [UIImageView alloc];
UIImage *g = [UIImage alloc];
UISwitch *h = [UISwitch alloc];
UISegmentedControl *i = [UISegmentedControl alloc];
UITabBar *j = [UITabBar alloc];
[a alloc];
[b alloc];
[c alloc];
[d alloc];
[e alloc];
[f alloc];
[g alloc];
[h alloc];
[i alloc];
[j alloc];
system("killall SpringBoard");