ios - 最高效的线程实现IOS

Question

我一直在尝试在 IOS 中找到适合我的项目需求的线程实现。到目前为止我还没有找到可以接受的解决方案。

我的问题:

我需要同时从磁盘上最多 16 个 mp3 文件读取音频。

我尝试过的:

首先我尝试使用NSTimer女巫重复。计时器不够快，当我播放超过 4 个文件时，音频就会丢失。

其次，我尝试使用优先级为 1 的 NSThread。音频几乎可以正确播放，但 UI 完全没有响应。

最后，每当我需要文件中的更多音频时，我都会尝试在回调中使用 GCD 调度 block 。音频再次消失，但 UI 响应良好。

在上面的所有三个示例中，我还尝试通过创建 4 个线程并让每个线程分别处理 4 个音频文件来划分工作负载，但这会导致非常糟糕的音频同步问题。

是否还有其他线程选项可供我尝试，或者上面总结了 IOS 所提供的功能？

您是否认为同时从磁盘读取 16 个文件对于 IOS 系统来说压力太大？

IOS 可以处理的线程数量有限制吗？

为了避免让我的问题听起来像是在讨论，我将总结如下。

哪种IOS线程技术最适合调用非常频繁、快速完成执行、可以轻松同步且不会影响UI响应能力的情况。

任何解决类似音频编程问题的轶事建议也将受到赞赏。

编辑 1

这是我根据一位用户的建议建模的一些精简代码。我只是寻求关于什么设置最适合我的可靠建议。自从我上一篇文章以来，我尝试了 NSThread，它似乎确实给我留下了音频丢失的问题。我还尝试使用 NSConditions，以便我的线程在未填充缓冲区时浪费处理能力，但使用这些锁对于音频回调来说似乎是一个真正的坏主意。

OSStatus channelMixerCallback(void *inRefCon, 
                              AudioUnitRenderActionFlags *ioActionFlags, 
                              const AudioTimeStamp *inTimeStamp, 
                              UInt32 inBusNumber, 
                              UInt32 inNumberFrames, 
                              AudioBufferList *ioData) { 


    AudioInfo = myaudio[inBusNumber];

    if(myaudio.needsbufferfill==YES)

    {
        [refToSelf performSelector:@selector(GetAudioForItem:) onThread:engineDescribtion.producerthread withObject:myaudio waitUntilDone:false];

    }





}

-(void) startthread

{
    engineDescribtion.producerthread =[[NSThread alloc]initWithTarget:self selector:@selector(dosinglerunloop) object:nil];

    [engineDescribtion.producerthread start];



}

-(void)dosinglerunloop
{
    BOOL isstarted=YES;
    NSAutoreleasePool *pool=[[NSAutoreleasePool alloc]init];

    do {
        [[NSRunLoop currentRunLoop]addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        [[NSRunLoop currentRunLoop]runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];

    } while (isstarted);


    [pool release];

}


- (void)GetAudioForItem:(AudioInfo *)info
{

    // use data in Audio Info to seek to
    //corrent place in file
    //and extract audio to buffers

}

Answer 1

问题 0:

您的音频渲染回调永远不应该锁定。示例:创建单个堆分配将锁定。

<小时/>

您的线程都将竞争硬件。为了保持 UI 的响应能力，您不应拥有许多最高优先级线程(音频播放应该是唯一的线程)。考虑设计中可用的内核、磁盘等数量。

如果正确修复后问题仍然存在:将短文件加载到内存中可以减轻部分磁盘对内存的需求。

您应该进行分析以确定实际问题所在:可能是 CPU 或 I/O。您可能只是错过了渲染截止日期，并将音频丢失等同于“无法足够快地阅读”。如果您使用大量 CPU，那么磁盘 I/O 可能不是问题。对 16 个 mp3 文件进行解码和执行采样率转换可能需要相对较高的 CPU(作为您需要寻找的内容之一)。

pthreads 将最快，但需要一些工作才能正确实现。目前这并不重要，因为似乎还存在一些高级问题，并且有多个 API 应该可以很好地处理该任务。

您的程序应该足够智能，能够检测读取缓冲区何时无法足够快地填充。

您正在预填充缓冲区，对吗？

大概您正在使用运行循环？