拒绝访问 | www. | 百度云加速
请打开cookies.
此网站 (www.) 的管理员禁止了您的访问。原因是您的访问包含了非浏览器特征(3a4b4a35f5ac436a-ua98).
重新安装浏览器，或使用别的浏览器ROS驱动摄像头时usb_cam包中设置的相机FPS与topic实际发布速率差很多，如何解决？ - 知乎1被浏览33分享邀请回答还没有回答怎么使用Altium Designer CAMtastic 反向生成PCB文件的详细教程_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
怎么使用Altium Designer CAMtastic 反向生成PCB文件的详细教程
0|0|暂无简介|
全国最专业的高速PCB设计培训机构，一直致力...|
总评分0.0|
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
你可能喜欢1017人阅读
Android Camera数据流分析全程记录
花了不少时间在这个数据流的分析上面，自己毕竟没怎么做过android，这里记录一下自己的见解，任何理解错误还望高人指教，以后还需慢慢纠正
整个分析过程从app的onCreate开始：packages/apps/OMAPCamera/src/com/ti/omap4/android/camera/Camera.java
在onCreate中做了很多的初始化，我们真正关注的是一下几条语句：
在这里我们实例化了一个SurfaceView对象，通过这个对象获取SurfaceHolder对象，实现这个addCallback方法，
其中SurfaceView的定义在以下路径：frameworks/base/core/java/android/view/SurfaceView.java
其中SurfaceHolder的定义在以下路径：frameworks/base/core/java/android/view/SurfaceHolder.java
这里看看这个文章的解释，写的很是不错：
SurfaceFlinger 是Android multimedia 的一个部分，在Android 的实现中它是一个service ，提供系统范围内的surface composer 功能，它能够将各种应用程序的2D，3D surface 进行组合。
在具体讲SurfaceFlinger 之前，我们先来看一下有关显示方面的一些基础知识 。
每个应用程序可能对应着一个或者多个图形界面，而每个界面我们就称之为一个surface ，或者说是window ，在上面的图中我们能看到4 个surface ，一个是home 界面，还有就是红、绿、蓝分别代表的3 个surface ，而两个button 实际是home surface 里面的内容。在这里我们能看到我们进行图形显示所需要解决
a 、首先每个surface 在屏幕上有它的位置，以及大小，然后每个surface 里面还有要显示的内容，内容，大小，位置 这些元素 在我们改变应用程序的时候都可能会改变，改变时应该如何处理&
b 、然后就各个surface 之间可能有重叠，比如说在上面的简略图中，绿色覆盖了蓝色，而红色又覆盖了绿色和蓝色以及下面的home ，而且还具有一定透明度。这种层之间的关系应该如何描述 & & &
我们首先来看第二个问题，我们可以想象在屏幕平面的垂直方向还有一个Z 轴，所有的surface 根据在Z 轴上的坐标来确定前后，这样就可以描述各个surface 之间的上下覆盖关系了，而这个在Z 轴上的顺序，图形上有个专业术语叫Z-order 。 &
对于第一个问题，我们需要一个结构来记录应用程序界面的位置，大小，以及一个buffer 来记录需要显示的内容，所以这就是我们surface 的概念，surface 实际我们可以把它理解成一个容器，这个容器记录着应用程序界面的控制信息，比如说大小啊，位置啊，而它还有buffer 来专门存储需要显示的内容。
在这里还存在一个问题，那就是当存在图形重合的时候应该如何处理呢，而且可能有些surface 还带有透明信息，这里就是我们SurfaceFlinger 需要解决问题，它要把各个surface 组合(compose/merge) 成一个main Surface ，最后将Main Surface 的内容发送给FB/V4l2 Output
，这样屏幕上就能看到我们想要的效果。
在实际中对这些Surface 进行merge 可以采用两种方式，一种就是采用软件的形式来merge ，还一种就是采用硬件的方式，软件的方式就是我们的SurfaceFlinger ，而硬件的方式就是Overlay 。
首先继承SurfaceView并实现SurfaceHolder.Callback接口
使用接口的原因：因为使用SurfaceView 有一个原则，所有的绘图工作必须得在Surface 被创建之后才能开始(Surface—表面，基本上我们可以把它当作显存的一个映射，写入到Surface 的内容可以被直接复制到显存从而显示出来，这使得显示速度会非常快)，而在Surface 被销毁之前必须结束。所以Callback 中的surfaceCreated
和surfaceDestroyed 就成了绘图处理代码的边界。
需要重写的方法
　（1）public void surfaceChanged(SurfaceHolder holder,int format,int width,int height){}//在surface的大小发生改变时激发
　（2）public void surfaceCreated(SurfaceHolder holder){}//在创建时激发，一般在这里调用画图的线程。
　（3）public void surfaceDestroyed(SurfaceHolder holder) {}&//销毁时激发，一般在这里将画图的线程停止、释放。
这几个方法在在app中都已经重新实现了，重点分析surfaceChanged
以上标注部分是关键，现在直接分心startPreview方法，这是第一次打开摄像头的处理函数，进行了一些初始换，而已经处于摄像头打开状态时不必使用startPreview方法，而是用上面的另外一个分支，重新开始显示即可
这里的思路是：先通过setPreviewDisplay方法将surface设定为window-player，这个方法会调用到HAL层，进行很重要的初始化，实现数据的回调
这里我必须得着重着重的进行分析，我一直在寻找是什么决定了overlay的使用与不适用，这里就这个setPreviewDisplay方法就是“罪魁祸首”
在setPreview方法中传入的参数是surfaceview，这个surfaceview传到底层HAL层是参数形式发生了改变，但是在我的理解下，就是人换衣服一样，
张三今天换了一身衣服，但这个张三跟昨天穿不同衣服的张三是同一个人，到了HAL层这个参数的形式是preview_stream_ops&，下面慢慢你就可以知道了，
在camerahal中的setPreviewDisplay方法中，是通过判断传下来的的preview_stream_ops&参数是否为空决定使用overlay还是不适用overlay的，很重要的
这篇文章只是在这里提及一下，下面不会提及overlay的内容，默认是以不适用overlay的方式分析数据流的整个过程的，这里可千万别混淆了
使用overl的数据回流方式将单独作为一章分析，同时会详细分析使用和不适用overlay的最终决定权
流程如下：app--&frameworks--&通过JNI--&camera client--&camera
service--&通过hardware-interface--&hal_module--&HAL
这里十分有必要看一下camera service层的调用过程：
这里其实我还是理解的不是很透彻，将我们从app传进来的surface转换为IBinder和ANativiWindow，然后以这两个变量为参数接着调用参数不同的setPreviewWindow
上面先调用到CameraHardwareInterface中的setPreview方法：
到这里为止，传输的参数已经由最初的surface--&ANativeWindow--&preview_stream_ops,传递到底层的参数已经发生了本质的变化，后面数据回调的时候还会见到这里变量，现在先记下它
其实我说的本质的变化这里也只能这么说，但往深入追究，这个preview_stream_ops也可以说只是surface的另外一种形式而已
这样才通过hardware调用到hal-module再调用到hal层
HAL层调用：
这里配置好显示数据来源，显示到目标，以及错误信息回调方法，最终开始preview
BaseCameraAdapter实现了父类的sendcommand方法：
这里我们接着分析startPreview方法，之前的文章中已经分析过，这里调用的startPreview方法不是BaseCameraAdapter中的startPreview,而是调用的V4LCameraAdapter中的startPreview方法：
现在我们就看看开启的preview线程都在干什么：
就上面这段代码做一下说明，这里在我看来就是整个数据回流过程的中转站了，上面棕色部分buffer中拿到就就是底层driver返回回来的视频数据了，
那么我不是很明白的是，driver中的视频数据是怎么和mPreviewBufs还有index关联在一起的，并且这里可以通过buffer&=&mPreviewBufs.keyAt(index)获取到CameraBuffer，这里待会会详细探究一下
先接着往下说，获取到视频数据之后，如果需要，会将数据经过转换保存到file中方便之后使用，
最后使用得到的camerabuffer填充CameraFrame，这个结构至关重要，在我的理解，最终是通过sendFrameToSubscribers(&frame);方法将数据回流的
这里就先追踪一下driver中的视频数据是怎么和mPreviewBufs还有index关联在一起的
到了这里就不得不提及上面已经说的一个很重要的方法，先看看这个方法：
他是startPreview的第一步，cameraPreviewInitialization
这里先为preview buffer申请内存，并将preview set进cameraAdapter通过方法mCameraAdapter-&sendCommand(CameraAdapter::CAMERA_USE_BUFFERS_PREVIEW,(&int&)&&desc)
在sendcommand中实现如下：
调用V4LCameraAdapter中的useBuffers方法，然后他会接着调用UseBuffersPreview方法：
在这里我们还是很有必要去深入研究一下mAppCallbackNotifier这个变量的初始化过程，他决定很多回调函数的初始化
的初始化是在哪里实现的呢？？在在camerahal文件的initial中初始化的
这里实例化了一些对象，我真正关注的是mAppCallbackNotifier这个对象，实例化这个对象，并且initialize，并且设置EventProvider和FrameProvider
我们就看一下setFrameProvider这个方法都做了什么事情，
实例化一个FrameProvider对象，并且enable响应notification，这里实例化的对象里面的参数中有一个frameCallbackRely是一个回调函数，这里我们暂且回过头看看previewthread中的那个方法sendFrameToSubscribers
这个方法只是调用了下面这个方法实现：
最重要的部分我在上面已经表示出来，通过subscribers这个全局KeyedVector变量找到相应的frame-&mCookie和callback方法，
这里所要获取到的callback方法就是上面setFrameProvider时引入的frameCallbackRelay这个函数，我们看看这个函数的具体实现
这个回调函数只是将数据装载入mag这个消息结构体，比且把这个消息put到mFrameQ这个全局消息中心，app就是从这个消息中心把数据取走的
我们可以看一下在AppCallbackNotifier初始化的时候就调用了initialize做一下初始设置
这个初始化的方法里面最重要就是开启了一个线程，用来监听HAL层发送来的一切消息，并在其中将消息或者数据告诉app，看看这个线程的具体实现
这里等待到有消息时，我们直接分析我需要的，preview，如果检测到mFrameQ中有消息，则调用notifyFrame方法
这里对不同的操作方式做了不同的处理，我们还是先通过preview过程作分析，如上面标注的那样处理，这里看看copyAndSendPreviewFrame的实现方法：
具体中间的实现过程这里就先不做具体分析，我们只看最后这一个标注的方法mDataCb，他的定义是这样的
camera_data_callback & mDataCb;
这个方法的实现很关键，其实他是在cameraservice中实现，过程如下：
1.cameraservice中调用mHardware-&setCallbacks(notifyCallback,dataCallback,&dataCallbackTimestamp,&(void *)cameraId);
2.camerahardwareinterface中调用mDevice-&ops-&set_callbacks(mDevice,__notify_cb,__data_cb,&__data_cb_timestamp,&__get_memory,&this);
3.camerahal_module中调用gCameraHals[ti_dev-&cameraid]-&setCallbacks(notify_cb, data_cb, data_cb_timestamp, get_memory, user);
4.camerahal中调用mAppCallbackNotifier-&setCallbacks(this,notify_cb,&data_cb,&data_cb_timestamp,&get_memory,&user);
5.这里就到了appcallbacknotifier中，我们就看看这个setcallbacks的实现吧
这里可以很清楚的看到mDataCb就是指向cameraservice中定义的回调函数，也就是通过这种机制，最终底层获取的数据现在已经传递到cameraservice层了
不过这里还是要很注意一点，我上面我说的mDataCb就是指向cameraservice中定义的回调函数也是不准确的说法，准确的说法应该是mDataCb的实现方法最红会调用到cameraservice中定义的回调函数，
这里还是花点时间说明一下这个回调过程：
mDataCb其实真正知道的是camerahardwareinterface中定义的__data_cb实现，这是由以下调用决定的
mDevice-&ops-&set_callbacks(mDevice,
& & & & & & & & & & & & & & & & & &__notify_cb,
& & & & & & & & & & & & & & & & & &__data_cb,
& & & & & & & & & & & & & & & & & &__data_cb_timestamp,
& & & & & & & & & & & & & & & & & &__get_memory,
& & & & & & & & & & & & & & & & & &this);
下面来看看的__data_cb定义
而这里这个mDataCb又是哪里来的
找里大家清楚的看到了mDataCb就指向cameraservice中定义的datacallback方法，这个过程只是稍微绕了下圈
这里还是继续分析吧，看看数据到底是怎样送到app的，下面看看cameraservice中的这个datacallback方法的定义
preview数据是通过上面的client-&handlePreviewData(msgType,&dataPtr,&metadata);方法继续往上走的，通过这种方式，数据由cameras层----&cameraclient层
接着看看cameraclent的实现
这里的listener到底是什么，还记得初始化的时候，在jni里面有设置listenerm吗？我们还是从新再看一下吧：frameworks/base/core/jni/android_hardware_Camera.cpp
由上面可以看出JNICameraContext是个监听类，同时set这个监听类，这个类的定义在：frameworks/base/core/jni/android_hardware_Camera.cpp
标注部分是我们在上面用到的postData，我们看一看postData的实现过程：
我们接着看看这个copyAndPost方法：
以上先建立一个byte数组obj，将data缓存数据存储进obj数组，CallStaticVoidMethod是C调用java函数，最后执行实在Camera.java(框架）的postEventFromNative（）
从这里开始，回调函数进入到camera framework层
frameworks/base/core/java/android/hardware/Camera.java
sendMessage之后由handle进行处理，定义同样在framework层
上面可以看出，这里处理了所有的回调，快门回调mShutterCallback.onShutter()，RawImageCallback.onPictureTaken（）拍照数据回调，自动对焦回调等。。
默认是没有previewcallback这个回调的，除非你的app设置了setPreviewCallback，可以看出preview的数据还是可以向上层回调，只是系统默认不回调，这里再说深一些：
由上面绿色标注的地方可以看出，我们需要做以下事情，检查PreviewCallback&这个在framework中定义的接口有没有设置了setPreviewCallback，设置则调用，这里接口中
的onPreviewFrame方法需要开发者自己实现，这里默认是没有实现的，需要特殊使用的要自己添加，这里是自己的理解，看一下PreviewCallback&接口的定义：frameworks/base/core/java/android/hardware/Camera.java
另数据采集区与显示区两个缓存区buffer preview数据的投递，以完成preview实时显示是在HAL层完成的。
到这里为止，整个过程大致走了一遍，中间必定有很多不多，这也只是自己的学习记录，难免有自己错误的见解，待修正
待续。。。。。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：118972次
积分：1370
积分：1370
排名：千里之外
转载：75篇
(21)(1)(18)(12)(2)(10)(4)(1)(2)(1)(7)(2)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'}