About seconds back?

1 Why do many IOS apps have a second fallback? Is there any good way to avoid it?
Is there any good way to avoid this phenomenon?

In the problem of "seconds back" if I do not understand the wrong, it should mean that the program displays the default boot image after the initialization phase of the crash (or can be called "flash back", but the recent "flash" The word has been widely used in various program crashes, so it may be "seconds back" more accurate?) ）。

This situation should not be related to the so-called memory shortage, very few programs will load a large amount of content during initialization to crash, and such problems can easily be found in the development phase, so memory is less likely to cause the likelihood of a second fallback (memory is not enough to retire, usually the program took some time to switch a few pictures after the occurrence).

And the second step is in the beginning of the program, in the development, Apple audit phase is not found the biggest possibility is that this problem will only occur in the old version of the system, the old version of the model.

For many developers (especially for individual developers), all iOS versions are hard to cover for all iOS models, and Apple audits only focus on reviewing the application's operation under the new machine, the new version, and not on the old system. So this is why the second program can also pass the Apple audit.

For normal apps on new iOS, the most common reason for PST fallback on older versions of iOS is that the system dynamic link library or the framework cannot be found. This usually happens because the app refers to a dynamic library in a new operating system (or a new version of a dynamic library) or only the Framework supported by the new IOS, and does not test the old system, so when the app is running on the old system, it is not found and seconds back. The workaround is to upgrade the program after the developer discovers the problem, or to upgrade its operating system by the user itself.

There is also a common second fallback is the program in the upgrade, modified the local storage of the data structure, but the user's existing old data is not upgraded, resulting in initialization because the user data can not be read correctly and the second fallback. This kind of problem usually can be solved by simply removing the program and reinstalling it again. The downside is that the user's existing data is lost--even if a backup may not help, because the old data that is backed up is not properly upgraded. If the old data is important, then you need to contact the developer to ask for a program fix.

Another reason that has become less common is that the APP is not set up correctly. For example, there is no compile-ARMv6 version at compile time, but the settings allow the APP to run on the ARMV6 processor's machine (e.g. iphone 1, iphone 3g,ipod touch 1, 2 generation, and 3 Gen 8G). This problem in addition to waiting for developers to upgrade outside the user's own no way to solve. Of course it is best to change the new machine, and the problem is now checked out when it is submitted to the App Store, so it should be less common in the future.

There is a class of seconds to retire or use a feature in the APP will be retired, is developed using only the new version of the operating system is supported by a method, and does not have the method exists in the old system to make judgments. For example, when the program starts with Game center, and does not determine whether the user's machine supports game center, then the second is back.

The main second retreat is so many, these are based on the APP's new version of the system can run as a prerequisite.

Problems such as out-of-memory, bad_access, and so on, usually exist on both the old and new IOS, and it is not uncommon to find that the seconds that are caused by such problems are usually found in the test and audit phases.

(2) Anxious to go online, testing is not enough, mainly in the code memory management problems. Even low memory can be resolved by releasing the cache and other related operations.

(3) I think most of the time because the back end of the data is empty, iOS does not make a judgment to go straight down, so it must crash

(4) According to my development experience if the problem of excluding memory is mostly because of multithreading problems, such as core data, this framework does not support multi-threaded synchronization is very troublesome

(5) I think the average user's so-called second fallback should be the program crash.
From a development perspective, there are several reasons:
1. Manipulate objects that should not be manipulated, such as wild pointers.
2. Improper handling of memory warnings.
3. The main thread UI dies for a long time and is killed by the system.
4. Internal exception logic is not handled properly.
5.SDK version differences are not handled well.

Wait a minute...

About seconds back?