iPhone dev - точность NSTimer для времени вместо пересчета?

У меня есть небольшой проект, который представляет собой таймер, который отсчитывает время до полуночи, и мне было интересно, должен ли я оставить его как есть, вычисляя время до полуночи каждую секунду (внутри метода NSTimer, который вызывается каждую 1 секунду):

NSDate *now = [[NSDate alloc] init];
NSDateComponents *dateComponents = [[self gregorian] components:
                    (NSHourCalendarUnit |
                    NSMinuteCalendarUnit |
                    NSSecondCalendarUnit) fromDate:now];
[now release];
NSUInteger hour = 23 - [dateComponents hour];
NSUInteger min = 59 - [dateComponents minute];
NSUInteger sec = 59 - [dateComponents second];

NSString *time = [[NSString alloc] initWithFormat:@"%02d:%02d:%02d",
                  hour, min, sec];
[[self lblCountDown] setText:
 [time stringByReplacingOccurrencesOfString:@"1" withString:@" 1"]];
[time release];

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

Спасибо.


iphone optimization count nstimer
person mk12    schedule 02.10.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Утверждение «нет причин не оптимизировать» опасно. Вам нужна причина для оптимизации, а не отсутствие причин не делать этого! Этот код представляет собой довольно разумный небольшой фрагмент, выполнение которого не займет много времени.

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

Что касается оптимизации, профилируйте ее, посмотрите, насколько она быстрая, если она отстойная, исправьте ее, если нет, перейдите к чему-нибудь повеселее!

person Nick Veys    schedule 02.10.2009
comment
Я поставил оба пути и сделал журнал, если они были одинаковыми, и это продолжалось какое-то время, всегда верно. - person mk12; 02.10.2009
comment
Кажется разумным. Вы можете увидеть дрейф на микроконтроллере или чем-то еще, но не на быстром устройстве, подобном этому. - person Nick Veys; 03.10.2009

arrow_upward
2
arrow_downward

Преждевременная оптимизация всегда ПЛОХО, не пишите сегодня код, который не сможете отладить через год. Никогда не выполняйте оптимизацию, пока вы:

  1. Есть работающее приложение.
  2. Работающее приложение имеет плохую производительность.
  3. Вы сделали инструментарий, чтобы найти настоящую горловину бутла.
  4. Вы уверены, что используете лучший алгоритм.
  5. Разобрались, как оптимизировать, не жертвуя ясностью кода.

После всего сказанного и сделанного проверка текущего времени каждую секунду никогда не ухудшит вашу производительность. Таким образом, очевидно, вы даже не выполнили требование 2 для применения оптимизаций.

person PeyloW    schedule 02.10.2009