Usually client products will have at least two compilation configurations: Debug and Release, and some optimizations will be made in compiling the Release version to reduce the size of the final product.
For example, in the Release version, the code execution steps (such as O1, O2, etc.) will be optimized, which will cause some codes to be omitted from optimization and sometimes unable to single-step debugging; in addition, the symbol information will be removed, which will lead to breakpoint debugging There is no symbol information, so there will be CallStack's capture and parsing content .
Since there will be different versions of the iOS terminal of Qianniu, they are respectively for internal developers, external ISVs and end users. Especially after integrating the QAP project, a special development and debugging version needs to be provided to QAP developers, so a new QAPDistribution Scheme is added, and this Scheme is copied from the Debug Scheme, so it is reasonable to debug and view symbol information. of. As a result, in the process of developing and debugging using this Scheme, it is found that the symbol information is missing, and the console outputs the following information:
AppName was compiled with optimization - stepping may behave oddly; variables may not be available.This makes it inconvenient for us to troubleshoot the problem. Although you can switch to Debug to debug and check, but because the version for ISV is not Debug, the environment is inconsistent, which may lead to some omissions. So I reconfirmed the compilation configuration information:
It is indeed consistent with Debug, which brings confusion.
Later, it was further found that there is symbolic information in Qianniu's own code, but it is missing when it is followed up to the Pod dependency, so I suspect that there is a problem with the compilation configuration of the Pod project:
It was found that the compilation configuration of the Pods project has optimized the QAPDistribution Scheme. So the question is, if I modify it manually, pod updatewill it recover again? It is verified that this is the case, so the problem can only be solved by the configuration of the Pod itself. Searched online and found the following solutions :
post_install do |installer|
installer.pods_project.build_configurations.each do |config|
if config.name.include?("QapDistribution")
config.build_settings['GCC_OPTIMIZATION_LEVEL'] = '0'
end
end
end
Validated.