Camera知识问答

  1. I2C不通的情况下怎么检查?

    I2C地址,址的宽度,总线配
    确认sensor的i2c地址是否配置正确,由于i2c通信地址是7bit,而不同的平台可能存在差异。有些配置7bit;有些则配置8bit,最后一位是读写标志。

    检查上电时序
    确认驱动中,是否在上电过程中,都按照sensor datasheet的上电流程配置电源和将reset,pwdn拉到相应的电平状态

    检查上电电压是否正确
    检查mclk
    硬件测量是否正确
    是否与别的I2C地址冲突

  2. mipi不通的情况下怎么检查?

    确认硬件mipi lane上是否有正确数据
    检查mipi端口
    降低mipi Rate
    降低mclk
    bandwidth不足,降帧率
    mipi是几lane

  3. 时序不通的情况下怎么检查?

    vblank是否满足平台要求
    settle cnt
    grabwindow与sensor seting是否匹配
    init setting 中要standby
    mipi时序是否满足协议要求

  4. Qcom或MTK平台下如何bring up 一个sensor/af/flash/pdaf ?

    点亮senrsor
    根据项目要求,掌握和sensor FAE沟通的一些技术细节
    preview、capture、video setting 的常见要求:mipi lane、fps、mipi速率
    平台要求的vblank细节,hts/vts,gain/shutter,上电时序要求

    根据软、硬件接口文档查看camera外围硬件接口,包括:i2c/mipi lane/AVDD/DVDD/IOVDD/AFVDD/PWD/RESET等
    根据原理图check CAMERA外围接口,包括GPIO端口分配、I2C端口号,mipi端口及mipi lane数量,mclk(24m/19m)
    根据camera模组资料查看模组基本信息,包括:I2C地址,模组光圈、焦距、FOV等EXIF信息
    根据软硬件接口文档,配置camera设备树DTSI信息,包括:I2C地址、PWD、RESET、AVDD、DVDD、IOVDD、AFVDD、MCLK等。
    根据DataSheet中的信息,配置驱动配置参数,重点包括:
        slaver info 相关信息
        mipi相关信息
        上下电时序
        曝光相关设置信息
        preview、capture、video setting相关信息
        hts/vts/vt_pixel/op_pixel_clk等分辨率和时钟相关信息
        outinfo输出相关信息
    

    点亮PDAF
    和FAE沟通一下pd像素点坐标输出
    确定preview、video、capture的vc输出通道
    确定分辨率大小
    确定平台支持哪种类型(type1、type2、type3)
    打开pdaf的log开关,查看线性度和可信度。

  5. CTS说几个常见问题?

    CtsAppSecurityHostTestCases
    需要插入高速SD/TF卡(class 10以上)

    CtsCarrierApiTestCases
    需要使用CTS测试专用白卡(sim卡)。

    CtsJobSchedulerTestCases
    需要插入有费的sim卡
    打开流量开关

    CtsKeystoreTestCases
    待测设备需要Lock

    CtsLibcoreTestCases
    需要IPV6网络。

    CtsLocationTestCases
    去室外GPS信号较强的地方,或者在室内放置GPS信号放大器测试
    一般需要多次retry,直至all pass或者Faild不再减少

    CtsMediaTestCases
    连接翻墙网络
    对网速有要求(建议专线2M以上带宽)
    多次retry,直至all pass或者Failed不再减少

    CtsNetTestCases
    需要漫游sim卡或者香港sim卡
    需要IPV6网络

    CtsSecurityTestCases
    使用自己项目的key替换Google原生的key。
    修改路径: build/make/target/product/security/release

    CtsTelephonyTestCases
    sim卡需要写入本机号码
    双卡机型需要插2张sim卡
    sim卡必须有费

    白卡相关的Module
    以下这些Module需要使用CTS专用白卡测试:
    CtsOmapiTestCases
    CtsSecureElementAccessControlTestCases1
    CtsSecureElementAccessControlTestCases2
    CtsSecureElementAccessControlTestCases3
    signed-CtsSecureElementAccessControlTestCases1
    signed-CtsSecureElementAccessControlTestCases2
    signed-CtsSecureElementAccessControlTestCases3
    这些Module是跟NFC相关的,如果设备不支持NFC,可以在固件中把这个feature移除。

  6. OTP的作用是什么?如何调试OTP?

    OTP消除模组之间的差异性,一种是从sensor中读出otp golden校正参数的值,传给isp,由isp自己去处理。另外一种是从sensor中读出otp的值,经过代码校正,将校正后的值写入寄存器中,再传给isp,isp收到数据就是校正后的数据。
    确定当前平台端OTP是sensor端还是平台端。文件.c-函数-判断后->truesensor端加载,false 平台端加载
    拿到机器时,先确认机器是否可以开机,拍jpg图、raw图,然后分别换上Isggolden awb golden模组并记录对应编号,然后执行otp dump的命令,抓取rebot log保存。此log中会有otp类型及是否输出otp信息的关键字。
    给手机换上模组后dump otp
    adb root
    adb remount
    adb shell setprop persist.camrea.cal.dump1
    adb reboot(开机后才会读取rebot,所以需要重启一遍手机读取otp)
    重启后重复1-2 步骤,将数据pull到电脑里面

    验证dump出的isc otp
    中心数据1023,从中心向四周分布数据递减是否满足规律

    验证dump出的wb otp
    验证awb的golden模组开机log或dump出的数据换算后典型数据是否与模组厂提供的报告数据差距多大

    查看OTP指导书的数据
    存储 Lens shading 参数由于各方面因素的影响,摄像头模组在 shading 方面都存在一定的差异性,如果用同一套参 数去校准 lens shading,效果往往不尽人意。如果模组在出厂的时候,分别对每一个进行lens shading 的校准,并且将这些校准参数烧入到 OTP 中,那么客户端在显示图像时只要从 OTP 中读取这些参数并且应用到图像上,他们得到的将是一致性非常好的成像效果。
    存储 AWB 参数同 Lens shading 一样,白平衡设置的好坏同样是评价 camera成像效果好坏的重要因素。 在模组在出厂的时候,分别计算每一个模组 R/G,B/G 等比值,并且将这些比值烧入到 OTP 中,那么客户端在显示图像时只要从 OTP 中读取这些比值并且计算最终的 gain 值,将他们 设置到图像中,就不容易出现偏色的现象。
    存储 AF position 将每一个模组的 AF position 存储到 OTP 中,可以快速提升模组 AF 对焦的速度和准确性。
    其它 在 OTP 中存储 Module ID 可以有效地管理产品的版本控制,当发生问题时可以及时地得到 有效信息以分析问题产生的背景和原因。同样在 OTP 中存储 Lens ID 也可以方便客户区分不 同的模组厂商和采用的不同的 lens,以方便他们对产品的控制。 综上所述,OTP 以其低廉的价格,方便快速的使用在高像素摄像头中得到了越来越多的应用,它如同一个幕后英雄,虽不起眼,却为高像素摄像头品质起到了很大的作用。

  7. PDAF的原理讲解一下,PDAF的三种类型都有哪些区别?如何调试PDAF?PDAF的PD数据里面都有啥?

    pd有L和R两种像素点的个数,每个像素点的位置,pd块的位置
    原理:
    通过遮蔽因子遮蔽住图像传感器的左右两个部分像素,使遮住右边的传感器只能接收到左边的图像,遮蔽住左边的传感器只能接收到右边的图像,这些像素点都是成对出现的。通过计算左右两边像素点之间的相位差来判断音圈马达移动的位置。

    三种类型:
    Type1:PD像素通过传感器校正,PD之通过传感器计算。(主要通过sensor计算)
    Type2:PD像素通过传感器校正,PD像素通过vc输出到ISP(通过ISP+sensor计算)
    Type3:PD像素通过ISP校正,PD像素通过isp从原始图像中提取PD像素由ISP3.0上的PDAF算法提取。(主要通过isp计算)

    调试
    在sensor中有很多的PD像素点,和FAE沟通确定一下PD像素的坐标点
    确定一下preview、video、capture 的vc通道
    确定分辨率的大小
    看平台支持哪一种类型(Type1、Type2、Type3)
    打开log开关,查看PD线性度(log文件里查找pdvalue与af位置,看他们是否呈线性关系)
    可信度,log里读取confidence数据,confidence是一组数据,查看数据是否变化较大。

  8. CTS/ITS问题如何解决,解决思路是什么?

    CTS问题
    CTS测试失败后:android-cts/results/20xx-xx-xx/test_result.html产生一个测试目录。
    根据日志找出错误原因,具体问题具体分析。以下是举例:
    观察fail结果,都是帧率相关的测试项,比如:
    testCameraToSurfaceTextureMetadata
    testPreviewFpsRange
    再查看result/log,发现fail都出现在测试前摄时。

    打开系统相机,查看前摄的帧率在室内光/打灯条件下是不是正常,能不能达到30fps。结果:前摄帧率最大只跑到了15fps,这显然是一个异常状态
    强制固定帧率为30fps(改代码/设置属性),查看实时log依然只有15fps。
    直接看内核驱动代码的log,实际设置的shutter/framelength的值是多少,这里有两个个计算公式:
        实时帧率 = pclk/linelength/framelength;pclk与linelength来自于驱动中配置的imgsensor info。
        framelength = ((shutter+ margin)< min_framelength)?(min_framelength):(shutter + margin);shutter来自效果参数的一系列计算,margin来自驱动代码的配置,min_framelength即为imgsensor info中设置的framelength。
        然而从实际打印的内核Log看,shutter与framelength的值违反了第二个公式,shutter值在2000左右波动,framelength一直固定在4164.
        从对应的imgsensor info中查找到pclk与linelength的值计算实时帧率,结果大概在15帧,同时发现imgsensor info里面设置的framelength = 4164,但最大帧率写的是30fps。
    
    此处framelength显然是一个异常值,那么应该修改成什么值呢?
        从write_shutter中可以看到framelength的值最终被写入寄存器0x0006中,查找对应setting(cap)中0x0006写入的值:0x0822,转换成十进制就是2082。所以将imgsensor info中的framelength修改成2082验证。
    
    修改后系统相机室内亮光环境下可以达到30帧,复测cts fail项,都可以pass。
    找FAEdouble check后提交修改。
    

    ITS问题
    ITS全测完之后,会在控制台上显示pass、fail、skip项。需要吧fail继续测试,保存所有fail项的结果到txt文档。
    根据日志找出错误原因,具体问题具体分析。以下是举例:
    查看fail项,基本都是曝光相关的测试项,如:
    test_exposure
    test_latching……

    test_latching是其中比较典型的一个测试项,查看测试脚本可以看出,此测试项内容是:
        获取IC支持的sensitivity和exposuretime
        然后设置预设的一系列值来获取图片:
        然后遍历获取到的图片数据中g的值是否大于平均值。要求图片组中g值大于平均值的情况符合预设的序列:
    
     对比脚本和生成的图片结果就可以发现,前两次获取图片时设置的sensitivity exposureTime值一模一样,但是获取到的两张图片亮度不一致。
    查看0x004e寄存器,功能是打开preframe功能,如果不打开这个功能,曝光生效时间会有延迟。
    按照提示修改后ITS测试全部pass。
    

    解决思路
    看测试结果和测试log,对比脚本,得出该条测试用例要测啥。
    根据测试脚本的目的来找出兼容性测试失败的代码,进行改正
    出厂前,CTS所有用例都是已经pass,出现问题,对照demo查看是否是引入问题。检查配置,引入是否正确。是否修改底层流程。从gerrit查看是否已有相关修改,在从谷歌官方查看有没有相关说明。
    ITS测试图片效果,出现问题查看效果参数是否没有配好。

  9. AE震荡(画面闪烁)是如何产生的,解决思路是什么?

    确认曝光和增益值设置的准确性,分别测试曝光和增益的线性度,确认效果是线性递增。
    先通过曝光测试确定gain、shutter线性度,考虑固定帧数步进,对比前后亮度,确认sensor AEC/AGC是否正常

    group on和group off是保证gain、shutter同时生效的一种机制,如果gain、shutter不能同时生效,会导致AE震荡。

    曝光表设置增益值超出驱动设置范围,导致不能收敛。

    确认sensor datasheet上的exposure gain延时生效帧数与ISP中的配置是否一致
    在sensor datasheet上,一般会描述曝光和增益之后多少帧生效,这个参数需要与ISPAE设置曝光、增益的延时帧数匹配。

    确认ISP AE参数,降低AE调节速度。
    AE过快,导致来回震荡。

    加大AE容忍度
    部分场景,亮度变化较小,AE参数是在不断的微小变化从而导致画面闪烁,可以考虑加大AE容忍度,在外界变化微弱的情况下不进行AE调节。加大ae调节的容忍度,防止环境光变化很小的情况下,ae不断调节。

    降低isp ae的调节速度,ae调节速度快,理论上收敛速度加快,也可能导致来回震荡的情况出现。
    使用sensor的group hold确保expose gain和快门生效时机一致
    设定的值超过曝光表的范围

  10. systrace讲解一下,如何定位性能问题?

**Systrace颜色:**
    绿色:正在运行-->线程正在完成 与某个进程相关的工作或正在相应中断。
    蓝色:可运行-->线程可以运行但目前未进行调度。
    灰色:休眠-->线程没有可执行的任务,可能是因为线程在遇到斥锁时被阻止(内核阻塞)
    橙色:不可中断的休眠-->线程在遇到I/O操作时被阻止或正在等待磁盘操作完成。
    紫色:可中断的休眠-->线程在遇到另一项内核操作(通常是内存管理)时被阻止。

**CPU频率对于性能的影响**
    性能是超大内核>大内核>小内核 因此确定cpu策略,会影响camera性能,一般我们希望camera跑在大核,甚至启动的时候可以满频率跑在超大内核上加快启动速度,因此启动电流比较大。因此在项目之初应该对camera启动、处理流程、后期处理算法流程的cpu策略进行确定。

**CPU对调度性能的影响**
    高通CAMX架构相机处理:USERCASE_FEATURE_SESSION_PIPELINE_NODE,一个node才是它的最小处理单元,node处理超时直接导致卡顿,对于一个30fps的camera相机耗时应该是在7ms左右比较合理(高通建议值)

一个node长时间处于runable(蓝色)或者sleep(休眠)状态,整个处理时间很久或许是十几ms或者几十ms,要怀疑这是个cpu调度引起的性能问题。看cpu负载情况,从调度的方向入手
     如果负载已经满了,想办法降低负载,拿掉多余处理,或者某些负载提前处理或者稍后处理。
    优先级,适当时间提高线程的优先级
    任务过多挤在某个内核上,需要适当调节upmigrate downmigrate分散任务。
    如果是算法 可以考虑是否放硬件处理(GPU/DSP)降低CPU负载。

**常见丢帧问题(30fps)为例1s不足30帧情况**
     从IFE fence callback确认KMD apply request 是否丢帧(33MS问题)
    CameraApp 从surfacetexture确认HAL callback是否正常,注意一下1s帧数目,帧间隔是否均匀。
     CameraApp drawframe是否丢帧(trace上有F标记),帧间隔是否正常

丢帧是因为手机运行内存比较低的时候,一个手机的运行内存只有500m,但是camera其实占用内存很大,大多数手机处于性能比较差的时候。这个时候系统会触发LMK机制,清理有效内存空间,如果是这种情况需要系统资源去调配,杀掉一些除了系统进程以外一些比较不重要进程,优化出更大的内存,给camera使用。
卡顿的场景,并抓取卡顿发生时的systrace文件;
通过对比正常机器systrace文件,得到问题的应用进程的主线程,找到发生问题的问题帧;
放大和高亮去判断具体是哪一个细节点发生了耗时情况
  1. Flicker产生的原理是什么?
CMOS是按行曝光的,交流电的频率50hz,60hz,上图是60hz为例,它的能量累计的周期频率是120Hz,周期时间是T=1/120 =8.33ms,当曝光时间是8.33ms的整数倍时,每行获取到的能量是一致的,当曝光时间小于8.33ms时,会导致每行获取到的能量不一致,会导致明暗相间的水波纹,50hz同理
修改方案
    将曝光周期调整为10ms/8.33ms整数倍,曝光时间的加长,就会造成一些信息的丢失,也就是动态范围会缩小,导致图像一些信息丢失。

在这里插入图片描述

  1. 有没有遇到过tombstone问题,tombstone问题如何定位?
先看logcat打印,同时把崩溃的tombstone拉出来一起分析,
从log可以看到是哪个进程的哪个线程在哪个so库里发生了崩溃和tombstone保存目录
打开tombstone,找到应用崩溃的backtrace,崩溃是从底下向上看的
再找到崩溃对应的地址,用linux上的addr2line工具配合崩溃的地址来查对应的函数,同时配合工具链提供的objdump,来看反汇编代码找对应的崩溃点.
找到对应崩溃的函数,根据出现问题的操作来初步排查分析原因
  1. Camera启动时间过长
检查Sensor上电时序要求的延时,是否有偏长的情况;
去掉多余的I2C地址,因为大部分驱动会多添加一些地址;
OTP的加载调整到每次开机时第一次打开加载,之后不加载;
sensorInit如果时间过长,可以调节I2C speed(400->1000);
  1. preview阶段耗时
检查streamOn/Off的耗时;
preview_init是否有较长时间的耗时
以及延时操作使用mdelay代替msleep;
pre_delay_frame/cap_delay_frame丢帧操作是否合适;
  1. 低电流、功耗相关问题
检查电压是否都有下电成功,防止漏电;
对于共pin的sensor,在操作时是否有做好workaround;
将I2C寄存器单个读写,调整为连续读写的方式也有一定优化;
sensor的PIN是否有被其他模块占用,异常操作的行为;
  1. 一般的影像问题
解析度不够
过曝
shadding
noise
失真
Banding
Camera的摆设:Sensor的长边方向与lCD的长边方向同向
  1. Sensor porting 的步骤
根据软硬件接口文档、原理图、模组资料(光圈、焦距、FOV)查看sensor 电路pin连接及AVDD、DVDD、PWD、MCLK、RESET等电压分配是否合理。根据分辨率、fps、mipi lane、vblank、i2c地址宽度、mipi速率(包含snap、prebiew、video)向FAE获取setting配置参数;阅读sensor datasheet
完成以上准备工作,在kernel/arch/dts/平台/xxx.dtsi中配置硬件参数,如镜头的标识、位置、安装角度,i2c 、flash、马达、avdd、iovdd、gpio等;同时在vendor目录下发配置上下电、setting、mipi、i2c、output输出参数;
根据product、module、sensor属性匹配,其中当从sensor中读取出chipid,说明i2c通了。
I2c通了之后且sensor匹配成功,mipi输出SOF数据信号说明sensor点亮了。
  1. 讲解一下V4l2,v4l2的工作流程是什么?
为什么存在这个框架,它是Linux系统下提供给MTK,高通平台操作音视频设备的通道。
通过它来操作音视频设备。
它有一套流程 linux下分用户态(UMD usermodule drive)跟内核态(KMDkernel module drive) 。
UMD有一套操作流程 OpenCamera   StreamON  ConfigStream  ProcessCaptureRequest(发起一个请求)   ProcessCaptureRequestResult(返回一个结果) flush(类似Close)
V4L2是解决这一套流程下发到KMD,(用户态切换到内核态有三种方式  中断 异常 系统调用)
所谓的系统调用对于V4L2来说 假设OpenCamera 内部实际就是通过ioctl系统调用下发到KMD。
OpenCamera最终会映射到V4L2的open操作;
这一系列UMD的操作最终会映射到V4L2里面的一些系统调用里面去
HAL层只不过是封装的一层,最终落实的实体是到V4L2里面去的;
暴露给UMD的一般是int fd=open("/dev/video0",O_RDWR); video设备
比如Camera模组包括 sensor flash AFisp  jepg(编解码)  这个整体就代表一个V4L2设备
给UMD暴露的Video0就是V4L2的设备节点,而个个子设备也会暴漏相应的节点接口,来让UMD进行操作比如Video1,
V4L2就是一个module   它是对模组的抽象  而sub_dev 是具体的一个设备 
识别流程当中的 在sensor配置文件中也就相当于UMD用户态配置的sensor_id,跟sensor寄存器中的sensor_id去比较找到这个设备了,前提是你怎么去找这个设备,这个设备在不在  你这个设备有几个sensor,比如前置,后置,广角,景深,你去识别的话前提是硬件得存在这个设备。V4L2很大的一个作用就是在识别之前把这些设备给枚举出来 通过media节点接口暴露给用户态让用户来使用。
整个V4L2框架是linux内核中实现的,按照内核驱动的运行机制,系统启动的过程中就通过标准的module_init进行了初始化, 过程就是初始化一个V4L2_device结构体,通过v4l2_device_register向系统注册并创建video设备节点,然后根据dtsi设备树文件初始化子模块(sensor  AF  flash isp  jepg等等)设备硬件信息这些子模块会创建v4l2_subdev,通过v4l2_device_register_subdev 向系统注册并将其挂载到v4l2_device 设备之,然后创建media_entity添加到media controller中进行管理,同时也会创建对应的子设备节点,供UMD使用。这就相当于把存在的硬件设备给枚举出来了 这样就知道有哪些设备了就可以去识别了。
流程: 
    打开设备
        int fd=open("/dev/video0",O_RDWR);

    取得设备的capability,看看设备具有什么功能,比如是否具有视频输入,或者音频输入输出等。
        VIDIOC_QUERYCAP,struct v4l2_capability(可选)

    选择视频输入,一个视频设备可以有多个视频输入。
        VIDIOC_S_INPUT,struct v4l2_input

    设置视频的制式和帧格式,制式包括PAL,NTSC,帧的格式个包括宽度和高度等。
          VIDIOC_S_STD,VIDIOC_S_FMT,struct v4l2_std_id,struct v4l2_format

     向驱动申请帧缓冲,一般不超过5个。
        struct v4l2_requestbuffers

    将申请到的帧缓冲映射到用户空间,这样就可以直接操作采集到的帧了,而不必去复制。
    将申请到的帧缓冲全部入队列,以便存放采集到的数据.
        VIDIOC_QBUF,struct v4l2_buffer

    开始视频的采集。
        VIDIOC_STREAMON

    出队列以取得已采集数据的帧缓冲,取得原始采集数据。
        VIDIOC_DQBUF

    将缓冲重新入队列尾,这样可以循环采集。
        VIDIOC_QBUF

    停止视频的采集。
        VIDIOC_STREAMOFF

    关闭视频设备。
        close(fd);
  1. 遇到问题怎么定位硬件、效果、驱动、应用、Hal、算法?
首先Camera 分为APK,FrameWork, HAL,驱动,FrameWork是相当成熟的一个层面不到万不得已是不会去修改FrameWork框架的。
硬件层就需要反复确认电路的连接,gpio引脚接对没有,i2c,mipi,线路是否接对,可以使用示波器查看相应的波形。
剩下的APK,HAL,驱动层面就需要逐层根据日志来分析问题定界问题,首先先查看通过APK下发的Request以及参数经过FrameWork,HAL,驱动,是否正确的层层传递,其次就是查看数据的返回是否正确,驱动层的数据是经过sensor输出,isp等一些处理最终通过V4L2的mmap映射使得用户空间可以拿到数据,检查用户空间是否能得到数据。
HAL层的高通的框架是具有特定功能实现的算法,可以先屏蔽这些算法查看是否正常,以达到排除算法问题的目的。
HAL层的数据是通过回调上传至FrameWork,看日志分析数据是否送达FrameWork,如果正常,再去查看FrameWork是否正确的将数据上传至APK层面。逐层分析日志来确定问题所在的层面。
  1. sensor setting注意哪些事项?
sensor的I2C地址(八位还是七位);
sensor的id跟sensor寄存机内存储的id的地址要配对;
上电时序电压以及延迟要配对;
sensor的位置(前摄还是后摄),snesor的安装角度;
sensor内部存储数据的寄存器地址要配对(比如输出寄存器地址,曝光时间地址,gain地址,start,stop,groupon,groupoff)sensor模式拍照,预览,录像设定的寄存器地址;
mipi是几lan ,端口的配置;
sensor的拍照,预览,录像输出的设置。
  1. pclk、mclk、opcolk是什么东西?
Pclk: 模组传输数据所产生的时钟。
Mclk:系统提供给摄像头模组的时钟。
Opclk:高通
  1. 第三方(微信)预览卡顿、录像卡顿怎么排查?
首先查看log分析,预览 录像时的帧率
    第三方应用自身固定了帧率,帧率太低,就会预览卡顿不流畅和 弱光下预览偏暗
    若固定帧率,可联系app应用更该成动态或者采用规避方案下发过程中获取包名重新设定动态帧率
    第三方应用设置了动态帧率

若动态帧率还是卡顿
    app性能:预览过程是否加载了自己本身的算法,导致处理速度慢,存在掉帧卡顿
    手机内存,低内存的手机性能可能比较差,一些app对手机内存性能有一定要求
    2手机芯片平台自身的问题,其他平台正常,该平台存在问题
  1. sensor常见模组厂家、sensor厂家有哪些?
模组厂家:BYD、富士康、欧菲光
Sensor厂家:索尼、三星、欧菲
  1. 什么叫大光圈?
大光圈指的是镜头的进光指数,一般用F1.0,F1.2,F2.8,F8,F32等数字表示,数字越小代表光圈越大,数字越大光圈越小。一般大光圈是指F2.8以上。大光圈会让照片的背景非常的虚化,拍摄人像、花卉、有意境。
  1. monkey稳定性?
**原理**
    利用socket通讯的方式来模拟用户的按键输入、触摸屏输入、手势输入等。

**目的**
    进行压力测试,是一种随机测试和稳定性测试。结合monkey打印的日志和系统打印的日志来分析测试的结果。

**命令**
    常用选项、事件选项、约束选项、调试选项。
        常用项:
            -help 打印monkey帮助日志,介绍monkey命令的用法。adb shell monkey –help
            -v 指定反馈信息级别,总共分为3级
            日志级别 leve1 adb shell monkey –p com.htc.Weather –v 100
            日志级别 leve2 adb shell monkey –p com.htc.Weather –v –v 100
            日志级别 leve3 adb shell monkey –p com.htc.Weather –v –v –v 100

        事件选项:
            --s指定伪随机数生成器的seed值,如果seed相同,两次monkey测试产生的事件序列也相同。
             --throttle 每个事件结束后的间隔事件---降低系统的压力(不指定,系统会尽快的发送事件序列)
            --throttle 100
             --pct-touch 指定触摸事件的百分比,比如:--pct-touch 5%
             --pct-motion 滑动事件
             --pct-trackball 轨迹球事件
            --pct-nav 导航事件up/down/left/right
             --pct-majornav 主要导航事件 back key/ menu key
             --pct-syskeys 系统按键事件 Home、Back、startCall、endCall、volumeControl
              --pct-anyevent 任意事件

        约束选项:
            -c activity必须至少包含一个指定的category,才能启动,否则无法启动。
               -p 用于约束限制,用此参数指定一个或多个包
            例:指定一个包 adb shell monkey –p com.xxx.xxx 100
            指定多个包 adb shell monkey –p com.xxx.xxx –p com.xxx.xx 100
            说明
                让monkey模拟100次随机用户事件


        调试选项:
            --dbg-no-events 初始化activity,但是不产生任何事件。
            --hprof 指定该项后在事件序列发送前后会立即生成分析报告
              --ignore-crashes 忽略崩溃
             --ignore-timeouts 忽略超时
            --ignore-security-exceptions 忽略安全异常
             --kill-process-after-error 发生错误后直接杀掉进程
            --monitor-native-crashes 跟踪本地方法的崩溃问题
              --wait-dbg 直接连接了调试器才能执行monkey测试

        调试示例:
            monkey -s 12 --throttle 450 -pcom.android.cameraswitch --kill-process-after-error --ignore-timeouts--ignore-security-exceptions -v 10000
            说明:在camera模块中产生1万次伪随机操作(包括触摸、按键、手势等)

        步骤:
            不忽略异常
                adb shell monkey -p com.thunderst.radio --throttle 500-s 600 -v -v -v 800000 >C:\long_radio_report.txt
                指令的含义:测试的应用程序为FM,事件间的延时为500毫秒,种子seed的值为600,三个v表示输出的MonkeyLog的级别为最高,即输出最详尽的Monkey Log,测试的事件次数为800000次 ,Log保存在C盘的ong_radio_report.txt里

            忽略异常
                adb shell monkey -p com.thunderst.radio --throttle 500-s 600 --ignore-crashes --ignore-timeouts --ignore-security-exceptions--ignore-native-crashes --monitor-native-crashes -v -v -v 800000>C:\long_radio_report.txt
  1. Camera常见的测试手段有哪些?
**自测试手段**
    单元自测试checklist、MMI、monkey测试、压力测试、CTS测试、ITS测试
    Monkey:通常会在最后一行打印出当前执行事件的次数和时间),程序无响应搜anr,程序崩溃搜exception
    **Monkey如何确定内存泄漏?**
         内存泄漏弹出out ofmemory对话框
        对于有内存泄漏但是没有单出outof memory对话框的情况,可以通过logcat文件GC出信息,(GC:java的垃圾回收机制)
            GC_FOR_ALLOC: 因为在分配内存时候内存不够引起的
             GC_EXPLICIT 表明GC被显式请求触发的,如System.gc调用,
            GC_CONCCURRENT: 表明GC在内存使用率达到一定的警戒值时候,自动触发
             GC_BEFORE_OOM 表明在虚拟机抛出内存不够异常oom之前,执行最后一次回收内存垃圾
  1. 配置参数对FE提出哪些要求?
输出拍照、预览的尺寸大小和分辨率多少
fpx帧率多少 小于30会引起水波纹
需要几lane(1、2、3、4)
vblank的平台要求
i2c的地址,7位还是8位
mipi速率多大,拍照、预览、录像的速率
  1. isp pipeline 的流程,每个模块分别在那个数据领域以及主要功能是什么?
Raw—>DBS—>OBC—>BPC—>LENS SHADING—>PGN—>RNR—>UDM—>CCM—>LTM —>GMA—>ANR—>EE—>ANR2—>HFG—>COLOR 
    DBS:校准经过 ob 之前不同 pixel 的暗电流值的差异
    OBC:校准 cmos 的暗电流,输出信号的正确基准值。 
    Bpc:坏点校正作用 
    Lens shading:校准镜头自身中心和四周的亮度差和颜色差 
    PGN:3a 的统计计算模块 
    RNR:raw 域的降噪模块 Udm:demosaic 和 rgb 域的降噪锐化模块
    CCM:颜色增强模块,主要用于提升色块的准确性和饱和度。 
    Gma:gamma 校正(校准 cmos 的亮度相应和人眼相应相近)。
    ANR 和 ANR2:yuv域的降噪模块 
    EE:YUV 域的锐化模块,主要边缘增强的作用 
    HFG:yuv 域高频混加模块,主要作用叠加高频噪声,改善画面细节。 
    Color:在 hsv 色彩空间处理颜色块的亮度、hue、饱和度
  • 8
    点赞
  • 64
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值