Превышен лимит NSLog для обхода, расширения или захвата

Question

Я пишу твик Mobilesubstrate, чтобы зафиксировать функции, связанные с выполнением конкретной задачи на MobileSafari, вместе с отметкой времени, когда она вызывается.Я создал этот твик и перенаправил вывод в NSLog и увидел много следующего сообщения:

process 778 exceeded 500 log message per second limit  -  remaining messages this second discarded

Когда я использовал собственный файл журнала вместо NSLog, MobileSafari слишком долго запускался и был убит.Можно ли перехватить функцию и зарегистрировать ее аргументы функции (logify для функций на основе c) и время / данные, где она вызывается с использованием метода с минимальными издержками?Возможно ли использование настраиваемой функции ведения журналов на iPhone (jailbroken) с использованием доступных методов, таких как библиотеки ASL?

РЕДАКТИРОВАТЬ: я попытался обойти эту проблему, создав NSOperationQueue, NSOperation под названием LoggingOperation и внедрить право классав файле Tweak.xm.Я считаю, что это может облегчить основной поток, чтобы обновить пользовательский интерфейс и завершить запуск MobileSafari.Подстройка может быть скомпилирована, но когда функция нажата, LoggingOperation не записал в файл, в результате чего пустой файл журнала:

//LoggingOperation.h
@interface LoggingOperation : NSOperation {
NSString *event;
}

@property(retain) NSString *Event;

- (id)initWithEvent:(NSString*)ev;

@end

Внутри реализации NSOperation:

//LoggingOperation.m
@implementation LoggingOperation

@synthesize Event;

- (id)initWithEvent:(NSString*)ev;
{
    if (![super init]) return nil;
    [self setEvent:ev];
    return self;
}

- (void)dealloc {
    [Event release], Event = nil;
    [super dealloc];
}

- (void)main {

    NSString *serverError = event;
    if (![[NSFileManager defaultManager] fileExistsAtPath:@"/var/mobile/mylog.log"])
    {
            NSString *statusFileName = [NSString stringWithFormat:@"/var/mobile/mylog.log"];    
            NSFileManager *fileManager = [NSFileManager defaultManager];
            [fileManager createFileAtPath:statusFileName contents:nil attributes:nil];
    }
    serverError = [serverError stringByAppendingString:@"\n"];
    NSString *serverFile = [NSString stringWithFormat:@"/var/mobile/mylog.log"];
    NSData *serverText= [serverError dataUsingEncoding:NSUTF8StringEncoding];
    NSFileHandle *serverFileHandle = [NSFileHandle fileHandleForUpdatingAtPath:serverFile]; 
    if (serverFileHandle)
    {
        [serverFileHandle seekToEndOfFile];
            // this NSLog output appears in syslog but serverText is not written to mylog
        NSLog(@"WRITING TO THE LOG FILE!");
        [serverFileHandle writeData:serverText]; 
        [serverFileHandle closeFile];
    }
}

@end

Iтакже создал удобный метод для каждого подключенного метода, вызываемого для создания журнала:

void mylog(NSString* serverError)
{
    NSOperationQueue *queue = [[NSOperationQueue alloc] init];
    LoggingOperation *op = [[LoggingOperation alloc] initWithEvent:serverError];
    [queue addOperation:op];
    [op release];
}

В самом методе ловушки:

CGRect replaced_CGRectIntegral (CGRect rect)
{
    mylog(@"CGRectIntegral(rect)");
    return o_CGRectIntegral(rect);
}

Интересно, почему я пишу в файл вNSOperation и файл пуст?

Answer 1

Я знаю, что это не тот ответ, который вы ищете, но я бы посоветовал переосмыслить ваше ведение журнала и уменьшить количество создаваемых операторов журнала. Я хотел бы задать вопросы, почему вы регистрируете эти вещи? они действительно говорят тебе что-то важное? и если вы действительно нуждаетесь в них для сеанса отладки - как настроить так, чтобы задача выполнялась только один раз для теста?

Очевидно, что в версии выпуска вы не включили бы это ведение журнала.

Я видел, как люди писали в мире Java собственные регистраторы, чтобы подключать вызовы методов и регистрировать их и все их параметры. В любом случае это было пустой тратой времени из-за огромного количества производимых данных и генерируемых замедлений системы. Ведение журнала очень полезно, когда нацелено хорошо. Он должен быть кратким, содержать информацию, которая полезна и генерируется только тогда, когда о чем-то стоит сказать.