3

我正在为 iPhone 使用 Cocos2d，我想知道使用这种方法构建我的代码逻辑以产生敌人是否更有效：

-(void) schedule:(SEL)selector interval:(ccTime)interval

或在 EnemyCache 类中使用更新，并每次验证是否满足时间间隔。下面是在 EnemyCache 类的 update 方法中调用的代码片段（相对时间是一个整数值，在 GameScene 类中每次更新时由 GameScene 更新 - GameScene 更新方法调用以 1 的间隔调度第二）：

-(void) checkForPlayerCollisionsAndSpwanTime
{


    int count = [elements count];
    //CCLOG(@"count %i", count);
    Element* element;
    for(int i=0; i<count;i++){

        element = [elements objectAtIndex:i];
        NSAssert(element!=nil, @"Nil enemy");

        if (element.visible)
        {
            [element justComeDown];
            ShipEntity * ship = [[GameScene sharedGameScene]defaultShip];
            CGRect rect = [ship boundingBox];

            if (CGRectIntersectsRect([element boundingBox], rect)){
                [element doWhatever]; 
                element.visible=FALSE;
                [element stopAllActions];
            }       
        }
        else{
            if(element.spawnTime == relativeTime) {
                [self addChild:element]; 
                element.visible=TRUE;
            }
        }
    }
}

不同之处在于，在每次更新时，checkForPlayerCollisionsAndSpwanTime方法都会通过敌人数组。第一种方式，通过调度一个选择器调用类似的方法，可以减少CPU查看数组和条件的时间。

我不确定这个电话的成本有多大：

[self schedule:selector interval:interval repeat:kCCRepeatForever delay:0];

通过查看，我看到调用了这个方法（见下文），但我想问一下你解决这个问题的方法是什么，以及我是否应该继续使用 EnemyCache 更新方法或使用 scheduleSelector 方法。

-(void) scheduleSelector:(SEL)selector forTarget:(id)target interval:(ccTime)interval paused:(BOOL)paused repeat:(uint) repeat delay:(ccTime) delay
{
    NSAssert( selector != nil, @"Argument selector must be non-nil");
    NSAssert( target != nil, @"Argument target must be non-nil");

    tHashSelectorEntry *element = NULL;
    HASH_FIND_INT(hashForSelectors, &target, element);

    if( ! element ) {
        element = calloc( sizeof( *element ), 1 );
        element->target = [target retain];
        HASH_ADD_INT( hashForSelectors, target, element );

        // Is this the 1st element ? Then set the pause level to all the selectors of this target
        element->paused = paused;

    } else
        NSAssert( element->paused == paused, @"CCScheduler. Trying to schedule a selector with a pause value different than the target");


    if( element->timers == nil )
        element->timers = ccArrayNew(10);
    else
    {
        for( unsigned int i=0; i< element->timers->num; i++ ) {
            CCTimer *timer = element->timers->arr[i];
            if( selector == timer->selector ) {
                CCLOG(@"CCScheduler#scheduleSelector. Selector already scheduled. Updating interval from: %.4f to %.4f", timer->interval, interval);
                timer->interval = interval;
                return;
            }
        }
        ccArrayEnsureExtraCapacity(element->timers, 1);
    }

    CCTimer *timer = [[CCTimer alloc] initWithTarget:target selector:selector interval:interval repeat:repeat delay:delay];
    ccArrayAppendObject(element->timers, timer);
    [timer release];
}
4

1 回答 1

4

您的应用程序是否存在性能问题？如果没有，答案是：没关系。如果你这样做了，你是否测量过它，问题是否来自所讨论的方法？如果没有，答案是：你找错地方了。

换句话说：过早优化是万恶之源。

如果您仍然想知道，只有一种方法可以找出答案：测量代码的两种变体并选择速度更快的一种。如果速度差异很小（我怀疑会如此），请选择更容易使用的版本。您应该考虑另一种性能：作为人类，您阅读、理解、更改代码。在几乎所有情况下，代码的可读性和可维护性都比性能更重要。

没有人可以（或不会）看到这么多代码并得出结论“是的，A 肯定快 30-40%，使用 A”。如果您担心该方法的速度，请不要让任何人告诉您哪个更快。测量它。这是唯一可以确定的方法。

原因是这样的：程序员对代码性能做出假设是臭名昭著的。很多时候他们是错误的，因为在他们上次测量时，语言、硬件或对该主题的理解已经有了很大的飞跃。但是他们更有可能记住他们学到的东西，因为一旦他们问了一个和你一样的问题，其他人给了他们一个答案，他们从那时起就接受了这个答案。

但回到你的具体例子：这真的没关系。由于渲染太多敌人而不是确定何时生成敌人的代码，您更有可能遇到性能问题。然后真的，真的，真的，真的，真的，如果代码是在预定的选择器中运行，还是在每帧增加一个计数器的预定更新方法中运行，这并不重要。这归结为一个主观的编码风格偏好问题，而不是关于性能的决定。

于 2012-07-12T19:41:58.320 回答