蒲公英 - 文档中心 - Crash Log 的查看分析
Our App QA Team have an extensive knowledge of testing a wide range of iPhone, Android and Tablet mobile apps. You can rely on our focus and attention to detail to ensure your app is the best that it can possibly be. Let us to assist you in the success of your development.
A Mobile App Testing professional is able to support the requirements team with the review of a mobile app, enhance the user experience through a strong understanding of usability and apply appropriate methods of testing that are unique to mobile devices.
A professional test team, in-depth know the project progress and development, will be directly assigned to your team. On the professional bug management cloud platform, track project progress, feedback Bug situations, and regression testing issues. Let the testing experts join in your team directly.
We have thousands of primary real machine, covering 90% of the market share. Depth compatibility test record the test procedure complete logs, screenshots, capture CPU, memory, traffic and other performance data. Help you locate Crash, flash back problems. The perfect solution to your App adapter compatibility issues in one day.
It's important to become familiar with the technical, content, and design criteria that we use to review all apps. We've controlled some of the most common issues that cause apps to get rejected to help you better prepare your apps before submitting them for review.
Help you come into the App Store release. Release your app in App Store in 48 hours.
We have vulnerability test and security risk test for your App, while the in-depth penetration test on the server(servers,communications) is also provided. Each test is carried out by our test experts. Help you solve security risks and provides specific recommendations for repair.
Crash Log 的查看分析
应用 Crash 异常
Crash 首页
在应用管理中心中，点击“Crash”，即可进入该应用的Crash页面，如图：
在应用 Crash 异常首页，开发者可以查看应用的Crash统计，包括错误率、待处理问题、已处理问题、Crash次数及影响用户数。
Crash 趋势统计图
通过查看Crash趋势统计图，开发者能够了解Crash变化情况，可以及时掌握待发布版本的质量状况，从而决定在发布前解决哪些问题，【图1】“3”位置。
处理 Crash
蒲公英为开发者提供了标记 Crash 状态的功能，Crash的状态分为以下两种：
如【图1】中“1”所在位置，开发者在判断 Crash 状态后，先将需要转换的状态勾选，然后点击【图1】中“2”的位置进行修改。
筛选 Crash 显示
在 Crash 列表上，开发者可以选择特定的版本、状态和时间，即可自动刷新Crash列表，输入关键字还可以筛选出关心的Crash问题，如【图1】中“4”的位置。
对于 Crash Log，符号化后，可以使得 Crash Log 显示出更详细的信息，非常有利于开发者进行错误的分析和定位。
如果需要以符号化的形式显示 Crash Log，开发者需要上传符号表问题，对于 IOS，目前只能查看Log信息。对于 Android，需要上传 mapping 文件，如【图1】中“5”的位置。
上传了符号表文件后，Crash Log就可以被符号化显示。
Crash Log 详细信息
在 Crash Log 的列表中，点选需要查看的某一条 Crash Log（如【图1】中“6”所在位置），进入详情页，在详情页里可以看到发生 crash 的设备和系统信息，crash 的出错线程堆栈，系统日志等信息。
要修改 Crash Log 处理状态，点击【图2】中“1”的位置；
要符号化显示，点击【图2】中“2”的位置；
查看 Crash Log ，点击【图2】中“3”的位置。
The Documents and FAQs, include app uploading, installation, manager, SDK, Open API and so on.
Add Tocket for more help
Pgyer is our dream and the stage we show the value.
Pgyer growth log, record every detail of our efforts.
Expert Test
PGYER's Expert Test Service provide you the most simple and efficient mobile app testing.
Product Services
Select Language获取普通用户 iOS 设备上的 Crash Log 的方法 . - 博客频道 - CSDN.NET
编程路上的野花
分类：IOS开发
http://www.yifeiyang.net/iphone-development-skills-of-debugging-articles-3-crash-after-debugging-skills-program/
当我们的程序突然死掉了，Xcode突然送出一段 &message sent to deallocated instance& 的错误，我们该怎样定位我们的程序bug呢？
又或者我们已经通过AdHoc发布了我们的β版程序，更甚至于我们的程序已经发布到了app store上；而当我们的程序突然在测试人员，或者是最终用户那里突然当掉，是否能收集到这样的日志信息，供我们解析bug呢？
下面的文章中我将逐步深入地说明这些技巧
模拟器上显示堆栈信息
当我们在模拟器上调试时，可能经常遇到下面的内存访问错误：
20:21:11.41 App[] *** -[Testedit retain]: message sent to deallocated instance 0x12e4b0
首先，我们为了定位问题，需要Xcode帮我们显示栈信息，可以通过Scode中执行文件的属性来设置。如下图所示，选中 MallocStackLogging 选项。该选项只能在模拟器上有效，并且如果你改变了iOS的版本后也需要再次设定该选项。
这之后，你就可以在终端输入 info malloc-history 命令，如下所示；
(gdb) info malloc-history 0x12e4b0
之后得到如下的堆栈信息，从此分析具体的问题所在。
除此之外，也可以使用下面的命令；
(gdb) shell malloc_history {pid/partial-process-name} {address}
例如下图所示；
另外，内存使用时“EXC_BAD_ACCESS”的错误信息也是经常遇到的，这时我们只要将上面执行文件属性中的 NSZombieEnabled 选上，也能定位该问题。
最后，这些设置信息都是可以在运行期确认的，如下；
NSLog(@&NSZombieEnabled: %s&, getenv(&NSZombieEnabled&));
在iPhone上输出日志
如果不是在模拟器上，又或者我们的设备没有连接到PC上，那么如何调试我们的程序呢？假如我们通过AdHoc发布了程序，希望随时得到测试人员的反馈，可以利用下面的方法，将标准出力（stderr）信息记录到文件中，然后通过邮件新式发给开发者。
1. 设置一个开关，用来清空日志文件内容，并切换输出位置；
- (BOOL)deleteLogFile {
[self finishLog];
BOOL success = [[NSFileManager defaultManager] removeItemAtPath:[self loggingPath] error:nil];
[self startLog];
当我们调用上面的deleteLogFile后，就会清空之前的日志，并设置新的输出。
- (void)finishLog {
fflush(stderr);
dup2(dup(STDERR_FILENO), STDERR_FILENO);
close(dup(STDERR_FILENO));
- (NSString*)loggingPath {
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *logPath = [documentsDirectory stringByAppendingPathComponent:@&console.log&];
return logP
- (void)startLog {
freopen([[self loggingPath] cStringUsingEncoding:NSASCIIStringEncoding],&a+&,stderr);
2. 当日志取得之后，可以通过下面的方式发送邮件给开发者
- (void)sendLogByMail {
MFMailComposeViewController *picker = [[MFMailComposeViewController alloc] init];
picker.mailComposeDelegate = self;
[picker setSubject:[NSString stringWithFormat:@&%@ - Log&, [self appName]]];
NSString *message = [NSString stringWithContentsOfFile:[self loggingPath] encoding:NSUTF8StringEncoding error:nil];
[picker setMessageBody:message isHTML:NO];
[self.navigationController presentModalViewController:picker animated:YES];
[picker release];
iPhone应用程序的CrashReporter机能
苹果在固件2.0发布的时候，其中一项特性是向iPhone开发者通过邮件发送错误报告，以便开发人员更好的了解自己的软件运行状况。不过不少开发者报告此服务有时无法获取到~/Library/Logs/CrashReporter/MobileDevice directory的错误信息。
现在苹果提供了一种更简单的方法，使iPhone开发者可以通过iTunes更容易的查看崩溃报告。具体方法使进入iTunesConnect(在进入之前确定你有iPhone开发者帐号)，点击管理你应用程序,之后就可以看到用户崩溃日志了。
这里我介绍一下从设备中取出CrashLog，并解析的方法。
CrashLog的位置
程序Crash之后，将设备与PC中的iTunes连接，设备中的CrashLog文件也将一并同步到PC中。其中位置如下；
~/Library/Logs/CrashReporter/MobileDevice
Windows Vista/7：
C:\Users\&user_name&\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice
Windows XP：
C:\Documents and Settings\&user_name&\Application Data\Apple computer\Logs\CrashReporter
在这些目录下，会有具体设备的目录，其下就是许多*.crash的文件。
比如程序TestEditor在iPhone1设备上的crashLog如下：
~Library/Logs/CrashReporter/MobileDevice/iPhone1/TestEditor_-454678_iPhone1.crash
Incident Identifier: CAF9ED40-2D59-45EA-96B0-52BDA1115E9F
CrashReporter Key:
30af939d26f6ecc5f0d08653b2aaf4e
TestEditor [12506]
/var/mobile/Applications/60ACEDBC-600E-42AF-88A044/TestEditor.app/TestEditor
Identifier:
TestEditor
Code Type:
ARM (Native)
Parent Process:
launchd [1]
Date/Time:
11:25:56.357 +0900
OS Version:
iPhone OS 3.1.3 (7E18)
Report Version:
Exception Type:
EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x
Crashed Thread:
Thread 0 Crashed:
0x332b98d8 0x331b2000 + 1079512
0x 0x331b2000 + 438696
0xx331b2000 + 438312
0x332bb2000 + 1078824
0xx331b2000 + 359792
0xx331b2000 + 359432
QuartzCore
0x324cc05c 0x324ae000 + 122972
QuartzCore
0x324cbe64 0x324ae000 + 122468
CoreFoundation
0x3244f4bc 0x323f8000 + 357564
CoreFoundation
0xx323f8000 + 355352
GraphicsServices
0x342e91c0 0x342e5000 + 16832
0x331b5c28 0x331b2000 + 15400
0x331bb2000 + 8744
TestEditor
0xx1000 + 7226
TestEditor
0xx1000 + 7172
... (以下略)
虽然我们看到了出为题时的堆栈信息，但是因为没有符号信息，仍然不知道到底哪里出问题了...
编译调试相关的符号信息都被包含在编译时的 xxxx.app.dSYM 文件当中，所以我们在发布程序前将它们保存起来，调试Crash问题的时候会很有用。
首先，我们来找到该文件。
用Xcode编译的程序，在其编译目录下都会生成 [程序名].app.dSMY 文件，比如 Xcode 4 的编译目录缺省的是
~Library/Developer/Xcode/DerivedData
$ cd ~/Library/Developer/Xcode/DerivedData
$ find . -name '*.dSYM'
另外，我们也可以通过 Xcode的Preferences... -& Locations -& Locations 的Derived Data来确认该目录的位置。
上面例子中的程序，我们就找到了其位置是
~/Library/Developer/Xcode/DerivedData/TestEditor-aahmlrjpobenlsdvhjppcfqhogru/ArchiveIntermediates/TestEditor/BuildProductsPath/Release-iphoneos/TestEditor.app.dSYM
※ 大家每次像App Store发布自己程序的时候都记着保存该文件哦，要不然出现Crash的时候，就无从下手了。
解决符号问题
接下来，我们再来介绍一下使用.dSYM文件来恢复程序符号的方法。
首先，使用一个Xcode提供的叫做 symbolicatecrash 的小工具，它可以实现我们在CrashLog中添加符号信息的机能。该文件位于下面的位置，为方便起见，可以把它拷贝到系统默认路径下。
Xcode4.3.1的位置好像在这&/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash
$ sudo cp /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash /usr/local/bin
使用下面的命令，可以在终端输出有符号信息的CrashLog
$ symbolicatecrash [CrashLog file] [dSYM file]
$ symbolicatecrash TestEditor_-454678_iPhone1.crash TestEditor.app.dSYM
Thread 0 Crashed:
0x332b98d8 -[UIWindowController transitionViewDidComplete:fromView:toView:] + 668
0x -[UITransitionView notifyDidCompleteTransition:] + 160
0x -[UITransitionView _didCompleteTransition:] + 704
0x332b9628 -[UITransitionView _transitionDidStop:finished:] + 44
0x33209d70 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 284
0x33209c08 -[UIViewAnimationState animationDidStop:finished:] + 60
QuartzCore
0x324cc05c _ZL23run_animation_callbacksdPv + 440
QuartzCore
0x324cbe64 _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv + 156
CoreFoundation
0x3244f4bc CFRunLoopRunSpecific + 2192
CoreFoundation
0x3244ec18 CFRunLoopRunInMode + 44
GraphicsServices
0x342e91c0 GSEventRunModal + 188
0x331b5c28 -[UIApplication _run] + 552
0x331b4228 UIApplicationMain + 960
TestEditor
0x00002c3a main (main.m:14)
TestEditor
0xx1000 + 7172
由此，我们可以具体定位程序中出问题的地方。
用StackTrace取得崩溃时的日志
异常处理机制
任何语言都有异常的处理机制，Objective-C也不例外。与C++/Java类似的语法，它也提供@try, @catch, @throw, @finally关键字。使用方法如下。
@catch (CustomException *ce) {
@catch (NSException *ne) {
@catch (id ue) {
@finally {
同时对于系统Crash而引起的程序异常退出，可以通过UncaughtExceptionHandler机制捕获；也就是说在程序中catch以外的内容，被系统自带的错误处理而捕获。我们要做的就是用自定义的函数替代该ExceptionHandler即可。
这里主要有两个函数
NSGetUncaughtExceptionHandler() 得到现在系统自带处理Handler；得到它后，如果程序正常退出时用来回复系统原先设置
NSSetUncaughtExceptionHandler() 红色设置自定义的函数
简单的使用例子如下所示
void MyUncaughtExceptionHandler(NSException *exception)
printf(&uncaught %s\n&, [[exception name] cString]);
NSArray *callStackArray = [exception callStackReturnAddresses];
int frameCount = [callStackArray count];
void *backtraceFrames[frameCount];
for (int i=0; i&frameC i++) {
backtraceFrames[i] = (void *)[[callStackArray objectAtIndex:i] unsignedIntegerValue];
int main()
NSUncaughtExceptionHandler *ueh = NSGetUncaughtExceptionHandler();
NSSetUncaughtExceptionHandler(&MyUncaughtExceptionHandler);
- (void)exit_processing:(NSNotification *)notification {
NSSetUncaughtExceptionHandler(ueh);
- (void)viewDidLoad {
UIApplication *app = [UIApplication sharedApplication];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(exit_processing:)
name:UIApplicationWillTerminateNotification
object:app]
处理signal
使用Objective-C的异常处理是不能得到signal的，如果要处理它，我们还要利用unix标准的signal机制，注册SIGABRT, SIGBUS, SIGSEGV等信号发生时的处理函数。该函数中我们可以输出栈信息，版本信息等其他一切我们所想要的。
例子代码如下
#include &signal.h&
void stacktrace(int sig, siginfo_t *info, void *context)
[mstr appendString:@&Stack:\n&];
void* callstack[128];
int i, frames = backtrace(callstack, 128);
char** strs = backtrace_symbols(callstack, frames);
for (i = 0; i &; ++i) {
[mstr appendFormat:@&%s\n&, strs[i]];
int main(int argc, char *argv[])
struct sigaction mySigAction;
mySigAction.sa_sigaction =
mySigAction.sa_flags = SA_SIGINFO;
sigemptyset(&mySigAction.sa_mask);
sigaction(SIGQUIT, &mySigAction, NULL);
sigaction(SIGILL , &mySigAction, NULL);
sigaction(SIGTRAP, &mySigAction, NULL);
sigaction(SIGABRT, &mySigAction, NULL);
sigaction(SIGEMT , &mySigAction, NULL);
sigaction(SIGFPE , &mySigAction, NULL);
sigaction(SIGBUS , &mySigAction, NULL);
sigaction(SIGSEGV, &mySigAction, NULL);
sigaction(SIGSYS , &mySigAction, NULL);
sigaction(SIGPIPE, &mySigAction, NULL);
sigaction(SIGALRM, &mySigAction, NULL);
sigaction(SIGXCPU, &mySigAction, NULL);
sigaction(SIGXFSZ, &mySigAction, NULL);
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return (retVal);
综上所述，我们可以看到用StackTrace取得崩溃时日志的手顺如下
用NSGetUncaughtExceptionHandler()取得当前系统异常处理Handler
用NSSetUncaughtExceptionHandler()注册自定义异常处理Handler
注册signal处理机制
注册Handler中打印堆栈，版本号等信息
必要的时候将其保存到dump.txt文件
异常程序退出
如果程序不是异常退出，则还原之前系统的异常处理函数句柄
如果下次程序启动，发现有dump.txt的异常文件，启动邮件发送报告机制
整体的代码框架如下
#include &signal.h&
void stacktrace(int sig, siginfo_t *info, void *context)
[mstr appendString:@&Stack:\n&];
void* callstack[128];
int i, frames = backtrace(callstack, 128);
char** strs = backtrace_symbols(callstack, frames);
for (i = 0; i &; ++i) {
[mstr appendFormat:@&%s\n&, strs[i]];
void MyUncaughtExceptionHandler(NSException *exception)
printf(&uncaught %s\n&, [[exception name] cString]);
NSArray *callStackArray = [exception callStackReturnAddresses];
int frameCount = [callStackArray count];
void *backtraceFrames[frameCount];
for (int i=0; i&frameC i++) {
backtraceFrames[i] = (void *)[[callStackArray objectAtIndex:i] unsignedIntegerValue];
int main(int argc, char *argv[])
struct sigaction mySigAction;
mySigAction.sa_sigaction =
mySigAction.sa_flags = SA_SIGINFO;
sigemptyset(&mySigAction.sa_mask);
sigaction(SIGQUIT, &mySigAction, NULL);
sigaction(SIGILL , &mySigAction, NULL);
sigaction(SIGTRAP, &mySigAction, NULL);
sigaction(SIGABRT, &mySigAction, NULL);
sigaction(SIGEMT , &mySigAction, NULL);
sigaction(SIGFPE , &mySigAction, NULL);
sigaction(SIGBUS , &mySigAction, NULL);
sigaction(SIGSEGV, &mySigAction, NULL);
sigaction(SIGSYS , &mySigAction, NULL);
sigaction(SIGPIPE, &mySigAction, NULL);
sigaction(SIGALRM, &mySigAction, NULL);
sigaction(SIGXCPU, &mySigAction, NULL);
sigaction(SIGXFSZ, &mySigAction, NULL);
NSUncaughtExceptionHandler *ueh = NSGetUncaughtExceptionHandler();
NSSetUncaughtExceptionHandler(&MyUncaughtExceptionHandler);
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return (retVal);
- (void)exit_processing:(NSNotification *)notification {
NSSetUncaughtExceptionHandler(ueh);
- (void)viewDidLoad {
UIApplication *app = [UIApplication sharedApplication];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(exit_processing:)
name:UIApplicationWillTerminateNotification
object:app]
输入的CrashLog如下
0 TestEditor 0x0006989d dump + 64
1 TestEditor 0x00069b4b signalHandler + 46
2 libSystem.B.dylib 0x31dcd60b _sigtramp + 26
3 TestEditor 0x -[PopClientcreateUnreadMessageWithUIDL:maxMessageCount:] + 76
4 TestEditor 0x00025b85 -[PopClientgetUnreadIdList:] + 348
5 TestEditor 0x000454dd -[Connection receiveMessages:] + 688
6 TestEditor 0x00042db1 -[Connection main] + 188
7 Foundation 0x __NSThread__main__ + 858
8 libSystem.B.dylib 0x31d6a5a8 _pthread_body + 28
AppVer:TestEditor 1.2.0
System:iPhone OS
OS Ver:3.0
Model:iPhoneDate:09/06/08 21:25:59JST
其中从_sigtramp函数下面开始进入我们的程序，即地址0x开始。其所对应的具体文件名和行号我们能知道吗？
利用之前介绍的dSYM文件和gdb，我们可以得到这些信息。
cd $PROJ_PATH$/build/Release-iphoneos/TestEditor.app.dSYM/
cd Contents/Resources/DWARF
gdb TestEditor
gdb&info line *0x
Line 333 of &~/IbisMail/Classes/Models/PopClient.m&;
starts at address 0x2a386 &-[PopClient retrieve:]+86& and
ends at 0x2a390 &-[PopClient retrieve:]+96&
排名：第5121名
（69）（112）（40）（1）（9）（2）（6）（4）（2）（1）（7）（17）（1）（8）（4）（16）（7）（9）（7）（4）
（102957）读懂苹果审核的那些坑 - 简书
下载简书移动应用
写了28068字，被92人关注，获得了128个喜欢
读懂苹果审核的那些坑
前几天苹果突然给我们发邮件，要和我们聊聊我们的app，这可吓坏了，在Google上搜了下，肯定不是什么好事，很可能是下架的事情，这可吓坏了我，等了几天，苹果终于打来电话了。
首先，遇到这种情况一定不要着急，打电话不一定是聊下架的事情，可能只是告诉你一些事情。但你要记住，这时候很可能你们的app已经被苹果顶上了，把容易被拒的东西先去掉，等过了大概2个月风波过了，再加这些功能。那么，苹果究竟给我们发了什么邮件呢？现在我们就研究一下。
Your app uses or references the following non-public APIs, which is a violation of the App Store Review .Guidelines:allInstalledApplications, defaultWorkspace
The use of non-public APIs is not permitted in the App Store because it can lead to a poor user experience should these APIs change.
Next StepsPlease revise your app to remove any non-public APIs. If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions.Additionally, if you are using third party libraries, please update to the most recent version of those libraries. If you do not have access to the libraries' source, you may be able to search the compiled binary using the "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These tools can help you narrow down where the problematic code resides. You could also use the "nm" tool to verify if any third party libraries are calling these APIs.ResourcesFor information on the "nm" tool, please see the "nm tool" Xcode manual page.If there are no alternatives for providing the functionality your app requires, you may wish to file an enhancement request.If you have difficulty reproducing a reported issue, please try testing the workflow described in Technical Q&A QA1764: How to reproduce bugs reported against App Store submissions.If you have code-level questions after utilizing the above resources, you may wish to consult with Apple Developer Technical Support. When the DTS engineer follows up with you, please be ready to provide:- complete details of your rejection issue(s)- screenshots- steps to reproduce the issue(s)- symbolicated crash logs - if your issue results in a crash logWe hope you will consider making the appropriate revisions to your app and resubmit.If you have any questions about this information, please reply to this message via Resolution Center on iTunes Connect.Thank you,JennyApp Store ReviewApple, Inc.
苹果是说，我们使用了私有api。你的app使用了或者涉及到死私有api,这些api苹果是禁止使用的：
allInstalledApplications, defaultWorkspace。就是这两个。
苹果是禁止使用这些私有api的，因为这些私有api会导致很不好的用户体验。
下一步：请从你的app中移除这些私有api.如果在你的项目源码中定义了和这些私有api相同的方法名，我们建议你们修改你们的方法名，否则会影响你们的提交结果。
此外，如果您使用的是第三方库，请升级到最新版本的库。如果您没有访问第三方框架的源代码，您可以搜索使用“strings”编译二进制或“otool”的命令行工具。在“strings”工具可以输出使用私有api的方法列表，库调用和“otool-ov”将输出Objective-C类结构及其定义的方法。这些工具可以帮助你缩小，其中有问题的代码驻留。如果任何第三方库调用这些API，你也可以使用“纳米”工具来验证。
如果没有提供您的应用程序需要的功能没有办法，你可以提交一个增强请求。如果你有困难再现报告的问题，请尝试测试在技术Q＆A QA1764介绍的工作流程：如何重现针对报道的App Store提交的bug。
如果你有利用上述资源后，代码级的问题，您可能希望与苹果公司开发人员技术支持咨询。当DTS工程师跟进你，请随时为：
你拒绝的问题的完整细节
步骤来重现问题
symbolicated崩溃日志 - 如果你的问题将导致崩溃日志
以上就是邮件的翻译，最后，我检测出是我们用的一个SDK中使用了私有api,为了保险起见，我们暂时去掉那个SDK了。我用的办法是用终端命令：1.首先打开终端：cd .....2.然后输入命令：grep -r xxx .(例如：grep -r advertisingIdentifier .)就会找出所有使用advertisingIdentifier方法的列表。
记住苹果审核人员打电话的时候千万要好好说，要诚实，不要态度强硬，不然害的还是自己。希望这些对大家有所帮助。
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
被以下专题收入，发现更多相似内容：
分享 iOS 开发的知识，解决大家遇到的问题，讨论iOS开发的前沿，欢迎大家投稿~
· 26536人關注
纪录开发的点点滴滴，相互学习，共同进步~
专题内容主要包括Object-C、Swift等开发技巧以及学习过程的内容
· 1984人关注
iOS开发技术分享，一砖一瓦垒砌一个属于自己的世界！
技术交流群：
推荐一个学习iOS开...
· 798人关注
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式：