来源: 互联网  发布时间: 2014-02-18

canvas.drawBitmap()使图片全屏显示

有时候我们这使用canvas.drawBitmap()时，需要使图片全屏显示，这个时候我们可以这样：

Rectf rectF = new RectF(0, 0, w, h); //w和h分别是屏幕的宽和高，也就是你想让图片显示的宽和高 canvas.drawBitmap(bitmap, null, rectF, null);

 

    

    来源: 互联网  发布时间: 2014-02-18

【Objective-c算法】 A*自动寻路算法

A*算法适合在静态环境中寻路，也就是说周围的物体不会动态的移动。

需要2个表，分别保存待检测和已检测的格子：

@interface AStarFinder : NSObject { NSMutableArray *openTable;//尚未走过的格子 NSMutableArray *closeTable;//已经走过的格子 }openTable保存的就是当前格子四周的格子（最多为8个），只保存满足条件的格子，不能是障碍物 或者出屏幕了。

你可以这样来初始化它们：

CCTMXTiledMap *map = [CCTMXTiledMap tiledMapWithTMXFile:@"tile_map.tmx"];//加载地图 <pre name="code" >//mapSize是一个CGSize保存的是地图中Tile(格子)的数量openTable = [[NSMutableArray alloc] initWithCapacity:map.mapSize.width*map.mapSize.height];
closeTable = [[NSMutableArray alloc] initWithCapacity:map.mapSize.width*map.mapSize.height];

看看A*算法的核心代码：

- (void)start:(TilePoint *)startPoint_ EndPoint:(TilePoint *)endPoint_{ [openTable addObject:startPoint_];//一开始就把起始位置放进openTable TilePoint *curr=nil; while ([openTable count] > 0){//该循环用来找到最短路径,openTable要是没东西了 就表示无法到达目的地！ curr = [self bestTilePoint:curr];//从openTable找取出最合适的格子，下一步应该向哪里走 if (curr != nil) { [closeTable addObject:curr];//检测过了 就放到closeTable if ([self nextTile:curr X:curr.x Y:curr.y-1] == YES) {//该函数用来判断是否到达终点                  return;              } ...... }

看看 bestTilePoint 函数：

- (TilePoint *)bestTilePoint:(TilePoint *)p{ TilePoint *best = nil; if ([openTable count] == 0) { return nil; }else { for (NSInteger i = 0; i < [openTable count]; i++) {//遍历openTable if (best == nil) { best = [openTable objectAtIndex:i];//取出格子 if (best != nil && [self isComparePoint:best.parent And:p] == NO) { best = nil; } }else { TilePoint *best2 = [openTable objectAtIndex:i]; if ([self isComparePoint:best2.parent And:p] == YES) { best = best.f >= best2.f ? best2 : best;//得到f值小的格子,f值越小路线则越可靠 } } } [best retain]; [openTable removeObject:best];//从openTable中删除 一会还要加入到closeTable return best; } }

总之 bestTilePoint函数就是用来找到最合适的移动方向。

看看 是如何处理每一个格子的：

- (BOOL)nextTile:(TilePoint *)curr X:(NSInteger)x Y:(NSInteger)y{ TilePoint *next = [[TilePoint alloc] createTilePoint:x Y:y]; next.parent = curr;//父亲当然是当前的格子 if ([self isComparePoint:next And:endPoint]) {//先判断是否已到目的地 [closeTable addObject:next]; NSLog(@"find end point !!!!!!!\n"); return YES; //到了目的地 就不需要在检测其它格子了。。 } //这里检测的是格子是否为有效，包括：障碍物 出屏幕 已经检测过。。 if ([self isInCloseTable:next] == NO && [self isEnableTile:next.x Y:next.y] == YES) { if ([self isInOpenTable:next] == NO) { //计算f、g值 next.g = 14 + next.parent.g; next.f = next.g + [self calculateHPower:next]; [openTable addObject:next];//然后就可以加入到openTable了 }else { TilePoint *next2 = [self getFromOpenPath:next]; if (next2.f > next.f) { next2.parent = curr; next2.g = 14 + next2.parent.g; next2.f = next2.g + [self calculateHPower:next2]; } } } return NO; }
DEMO下载

    

    来源: 互联网  发布时间: 2014-02-18

启动MixerThread
今天想改变一下MixerThread的优先级。
看了下，原来在Thread的run函数中可以指定线程的优先级。
接下来就需要找到哪个地方调用了MixerThread的run函数，也就是启动了MixerThread。


想到，调用AudioTrack的start函数，可以开始播放。MixerThread的启动是不是由这儿驱动的呢？


看了下函数AudioTrack::start，有两个地方可疑：
           t->run("AudioTrackThread", THREAD_PRIORITY_AUDIO_CLIENT);
            status = mAudioTrack->start();


不过第一处指明了thread名称为AudioTrackThread，并非Mixer Thread。
既然看了，也就看看t是个嘛东东吧：
    sp<AudioTrackThread> t = mAudioTrackThread;
mAudioTrackThread在AudioTrack::set函数中被赋值：
        mAudioTrackThread = new AudioTrackThread(*this, threadCanCallJava);
AudioTrackThread::threadLoop函数的实现：
    return mReceiver.processAudioBuffer(this);
也就是调用了函数AudioTrack::processAudioBuffer。
看了看AudioTrack::processAudioBuffer函数的处理，感觉也就前面对callback的处理有用点。
比如，原来如果调用过SetMarkerPosition，而此时如果满足了条件，就会调用相应的回调函数。
后面的处理，没看明白什么意思，唯一的数据copy发生在16bit与8bit的转换。


那就看看mAudioTrack->start()吧。
函数AudioTrack::createTrack对mAudioTrack进行了赋值：
    mAudioTrack = track;

track的来历：
    sp<IAudioTrack> track = audioFlinger->createTrack(getpid(),
                                                      streamType,
                                                      sampleRate,
                                                      format,
                                                      channelCount,
                                                      frameCount,
                                                      ((uint16_t)flags) << 16,
                                                      sharedBuffer,
                                                      output,
                                                      &mSessionId,
                                                      &status);
 
函数AudioFlinger::createTrack返回的是一个TrackHandle对象：
        trackHandle = new TrackHandle(track);


函数AudioFlinger::TrackHandle::start的实现也不复杂：
    return mTrack->start();


mTrack就是刚才传入的track。
        track = thread->createTrack_l(client, streamType, sampleRate, format,
                channelCount, frameCount, sharedBuffer, lSessionId, &lStatus);


函数 AudioFlinger::PlaybackThread::createTrack_l返回的是一个Track对象：
        track = new Track(this, client, streamType, sampleRate, format,
                channelCount, frameCount, sharedBuffer, sessionId);


函数AudioFlinger::PlaybackThread::Track::start调用了函数AudioSystem::startOutput。
层层调用，最终调到了函数AudioPolicyManagerBase::startOutput。
不过，并没有看到有启动MixerThread的地方。


先小结一下。


创建AudioTrack对象的时候，会先根据stream type获取一个output。
获取的方法是调用函数AudioSystem::getOutput。
函数AudioSystem::getOutput中，会调用函数AudioSystem::get_audio_policy_service来获取AudioPolicyService。
AudioPolicyService对象若尚未被创建，函数AudioSystem::get_audio_policy_service会创建一个。
在AudioPolicyService的构造函数中调用了AudioPolicyManagerBase的构造函数。
AudioPolicyManagerBase的构造函数中打开了输出用的output。
打开方法是通过调用函数AudioPolicyService::openOutput最终调用到了函数AudioFlinger::openOutput。
函数AudioFlinger::openOutput中调用到了HAL层中的函数openOutputStream。
HAL层中通过调用ALSA Lib的接口，根据device name最终打开了output stream。


回到AudioPolicyManagerBase的构造函数中。
其中打开了output之后，为每个output创建了一个playback thread。
也就是说，底层的每个device对应了一个playback thread。


AudioTrack的构造函数获取到output之后，接下来调用函数AudioFlinger::createTrack来创建track。
track最终对应到了playback thread中的track。


调用函数AudioTrack::write往AudioTrack中写数据的时候，其实是写到了AudioTrack中的audio_track_cblk_t对象中。
调用函数AudioTrack::start最终调用到了函数AudioFlinger::PlaybackThread::Track::start，其中将track自己设置为有效，并将自己追加到对应的playback thread的track列表中。
MixerThread的threadloop函数中，会处理所有的active 的track，进行mix，并将数据写入到硬件。


还是回去看看Mixer Thread是怎么启动的吧。
搜了下，发现函数AudioFlinger::PlaybackThread::onFirstRef中有调用run。
PlaybackThread是MixerThread的父类。
估计MixerThread也就是在这儿启动的了。
查了下资料，onFirstRef是在创建第一个强连接是被创建，在创建对象的时候会被调用。


由前面所知，AudioPolicyManagerBase的构造函数中创建了playback thread，这里的playback thread其实是MixerThread。
打log验证了一下，果然，在AudioPolicyManagerBase的构造函数中引起了AudioFlinger::PlaybackThread::onFirstRef函数的调用，并最终启动了MixerThread。