I believe you can always find a lot of this kind of Crash:
Can't add self as subview.
We also know that we will never write code like
add self as subview.
In fact, in most cases, the
pop pages with
no animation occur at the same time.
Because we all know that this is often caused by the complexity of the page hierarchy and the unpredictable page jumps. So often choose to shelve this Crash helplessly.
But we always think about how to eliminate this Crash. Whether it is from the perspective of user experience or from the aspect of Crash rate management.
Crash is often caused by the rapid simultaneous execution of the following similar codes:
push/pop with animation is not completed instantly, and includes a lot of intermediate state processing, animation processing, etc., so when there is
push/pop without animation at the same time, it is easy to cause inconsistency.
Usually in the same block of code, we do not write such code. But when the page jump is driven by the
routing system, and the page technology stack is composed of
RN, etc., things will become quite complicated.
Our team has tried a relatively complete solution. The main thing is to start with the
routing system and build a sufficiently
controllable routing system, including
encapsulating all page jumps, using
CATransaction to try to solve the consistency problem caused by
push/pop animation, and so on. I will try to introduce it later when I have time.
In fact, it is very effective. Although our goal is a
routing system, because it is sufficiently
serialized, routing concurrency is reduced, which greatly reduces the occurrence of this Crash.
But it needs to be admitted that there are still a small number of such crashes. The main possible reasons are:
- Some newly introduced technology stacks use a lot of
presentas a page jump scheme. And this one is harder to control.
- The newly introduced company-level frameworks and libraries are
notunder our routing system, thereby bypassing the control.
In the end, in order to reduce more and more such Crash, we have to take violent protection measures, the code is as follows
As a defense, it is concise and violent enough. At least this solution does protect against many extreme asynchronous routing scenarios.