0. Background description
Previously, a small project was developed in Swift. Because it was used by the company's internal personnel, it was only signed with a corporate certificate and published on the Dandelion website. Therefore, the upgrade function is also directly used by Dandelion's official SDK-PgyUpdate.
Last month, a new requirement was added to the project, and the field for burying statistics was changed. Other codes did not change. However, after the development was completed, the newly opened test package had a problem of startup crash.
1. Problem finding
1.1. Positioning
After initial commissioning investigation found that the breakpoint error message is:
Thread 1: EXC_BAD_ACCESS (code=1, address=0x0).
The flash back problem occurs
PgyUpdateManager.sharedPgy().checkUpdate(withDelegete: self, selector: #selector(self.updateMethod(_:)))after the execution of this code, but did not enter the callback method specified here.
So it is suspected that the SDK of PgyUpdate has a null pointer exception. Then I verified the problem with a clean Demo and found that it could be reproduced, so I submitted a ticket to Dandelion and uploaded the demo code and the appid and appkey I used.
1.2. Law
While waiting for the official processing of the work order, I thought about whether the online package would have similar problems? But no one has ever responded, it should not be. I downloaded the online package to run it, and it did not crash. Then I found the rule:
when the project version <the latest version on the Dandelion platform, it will not crash;
when the project version=the latest version on the Dandelion platform, it will crash;
when the project version>the latest version on the Dandelion platform , it will flash back. Retreat.
This made me vomit blood, because the version of the online application and the version on the Dandelion platform must be the same, but it will not crash.
Therefore, it is doubly determined that there is a logic error in the SDK.
1.3. Investigation
Then Dandelion technical support personnel contacted me, read my calling code, and sent me a test SDK package.
After I tested it 当工程版本=蒲公英平台上最新版本时，会闪退, I found that it was gone. I thought that the BUG had been fixed, but soon discovered that 当工程版本>蒲公英平台上最新版本时，会闪退it still exists.
Continuing the investigation, the support staff found that the SDK would crash when calling the callback method func updateMethod(_ response: Any) {}because the passed parameter responsewas nil.
However, compared with the previous version that runs normally, neither the SDK code nor my business code has been changed. The only thing that has changed is the code in the Dandelion backend (they recently upgraded it).
2. The cause of the problem
At this point, the cause of the problem is clear. Because of the changes in the Dandelion background, when the SDK calls the checkUpdate method to check for updates, if there is no new version, the original background will return at least an empty object; but the current background directly returns nil.
So in the process of finding the problem, we found that the SDK side felt that there was no problem with the code, and the business side also felt that there was no problem with the code—because both parties could not enter the breakpoint of the crash when debugging and running.
Where is the mistake?
The error is in func updateMethod(_ response: Any) {}the declaration of the callback method. responseThe type of the parameter is Any. Any means it is a non-optional type and must have a value. Therefore, the system will force the nil value to be converted to a non-optional type when bridging the Swift and OC code. It causes a crash and a system exception occurs EXC_BAD_ACCESS.
3. Solution
The solution to this problem is also very simple, just responsedeclare the type of the parameter in the callback method as an Any?optional type.
4. Unsolved mystery
The problem has been completely solved, but the cause of the problem is still unreasonable, because one of the problem scenarios I verified in the demo 当工程版本=蒲公英平台上最新版本时，会闪退；cannot be explained?
This problem can be reproduced in the demo, but the online installation package has no such problem.
In the middle, I suspected that it was the reason for the package and compilation of debug mode and archive mode, but then I thought that my test packages were also typed in archive mode, and they would also crash, so I still couldn't explain it.
Perhaps this is another metaphysical mystery in the programming world...