安卓原生相机：APK提取与Camera2自研实战

有人问我，安卓上那个“android原生相机apk”到底是个什么东西，是能从系统里扒出来的安装包，还是自己拿源码编译一个“原生模式相机APP”。这两个理解都对，也都有人在做，只是目的完全不同。前者多出现在定制ROM、行业设备、老旧机型补功能这些场景里，想要的是那套跟系统深度绑定的成像管线；后者是开发者自己想拿到最干净的画面、最完整的手动参数，不想被厂商的算法“美颜”和过度锐化糊一脸。我这几年在这两件事上都踩过坑，从拆包看资源到一行行调CaptureRequest，掉过的头发不算少，所以这篇就把我知道的、验证过的、被坑过的，一次性摊开讲。适合已经能写安卓基础界面、想深入相机管线的开发者，也适合只想搞明白“为什么我的手机拍出来的照片跟我眼睛看到的不一样”的折腾党。

1. 搞清“原生”指什么：三条技术路线先分清

“原生”这个词在相机语境里非常含糊，不同人嘴里的意思能差出十万八千里。有人指的是出厂预装的那个相机应用，有人指的是不叠加任何算法处理的原始图像数据，还有人指的是走系统标准API而不是厂商私有SDK的开发方式。这三种理解对应三条完全不同的技术路线，选错了方向，后面所有工作都是白费。所以动手之前，先把目标定死在某一类上，比急着写代码重要得多。

1.1 系统相机APK的提取与替换路线

这条路线的核心诉求通常是“我就要那个原厂相机”。常见场景包括：某台设备刷了第三方系统之后相机功能残缺，想找回原来的拍照体验；行业定制设备需要预装一个稳定的相机应用，但厂商给的精简版功能太少；或者纯粹是好奇，想看看原厂相机里到底藏了哪些参数开关。

技术上要做的事情大致分四步。第一步是定位安装包，通过包名查询拿到APK路径，再用备份工具导出；第二步是反编译看结构，重点看AndroidManifest.xml里的权限声明、uses-feature声明，以及res/xml目录下有没有相机相关的配置文件；第三步是判断依赖，很多原厂相机不是独立应用，它依赖厂商私有框架类、私有HAL扩展、甚至依赖特定的系统签名权限，这类APK搬到别的设备上要么直接崩溃，要么能打开但功能大面积失效；第四步才是实际测试。

这里有个必须提前说清楚的事实：绝大多数原厂相机APK是不可移植的。原因不复杂，它们在AndroidManifest.xml里通常声明了一堆signature级别或privileged级别的权限，普通应用装上去根本拿不到；它们调用的很多接口来自厂商自己的框架层，标准Android SDK里压根没有这些类；还有一部分功能直接走私有HAL通道，换了芯片平台就是一片空白。

所以如果你的目标是“搬一个原厂相机到另一台机器”，我的建议是先做可行性判断，别一头扎进去。判断方法很直接：把APK反编译出来，搜索import语句里有没有非android.*、非java.*、非androidx.*的包名，如果有大量厂商私有包，基本可以放弃了。

提示：提取出来的APK只适合在本机做研究和个人学习用途，不要拿去做二次分发，也不要用于任何商业场景。签名校验、资源授权这些边界问题，提前想清楚比事后补救省事得多。

另外还有一个常被忽略的点：即使APK能跑起来，相机功能的实际表现也取决于HAL层。同一个APK在两台设备上，一台拍出来是正常的，另一台可能对焦死活不触发，因为对焦算法有一部分是在HAL里实现的，应用层只能发起请求，管不了执行细节。这一点在做兼容性评估时必须纳入考量。

1.2 基于Camera2自己写原生模式相机

这条路线才是真正意义上的“原生模式相机APP”——走系统标准相机API，不依赖任何厂商私有扩展，把控制权尽可能拿回到自己手里。它的价值在于可控：你想让快门速度停在哪就停在哪，想让ISO固定在100就固定在100，想输出RAW就输出RAW，不会有一层看不见的算法在背后偷偷给你锐化、降噪、拉饱和度。

这条路线的前提是设备支持Camera2的LEGACY以上级别。CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL这个字段会告诉你答案，取值从LEGACY、LIMITED、FULL到LEVEL_3。LEGACY基本等于只能当个普通相机用，手动参数大面积为空；LIMITED能拿到部分控制；FULL和LEVEL_3才是真正能玩手动模式的级别。很多中低端机型标称支持Camera2，实际是LEGACY，你兴冲冲写了个手动曝光面板，跑起来发现SENSOR_INFO_EXPOSURE_TIME_RANGE返回的是[0,0]，白忙一场。

我个人的经验是，做这类应用首先要写一个能力探测页，把所有关键特性一次性列出来：支持的硬件级别、可用分辨率列表、是否支持RAW、曝光时间范围、ISO范围、是否支持手动对焦、是否支持逻辑多摄。这个页面看似只是个调试工具，实际是整个项目的地基，后面所有的功能开关都要依赖它做降级处理。

1.3 三条路线的选型对照

把前面两条加上“只做预览和简单拍照的轻量封装”这第三条，做个横向对照会更清楚。

选型的关键不是哪个“更高级”，而是你的目标是什么。要最干净的画质和最完整的手动控制，只有Camera2这条路；要快速上线一个能用的相机功能，CameraX省下来的时间够你多睡好几觉；要找回原厂体验，那就老老实实做提取和兼容性验证，别指望能跨设备通用。

2. 相机管线的技术底座：从应用到Sensor的完整链路

在动手写代码之前，脑子里得有一张完整的链路图，否则调起参数来完全是盲人摸象。安卓相机的数据流向大致是：应用层发起CaptureRequest，经过相机服务，下到HAL层，HAL再跟驱动和Sensor打交道，图像数据从Sensor出来之后，一部分回流到应用层的Surface，一部分产生CaptureResult元数据回传给应用。理解这个“请求-结果”的双向模型，是后面所有调优工作的前提。

2.1 Camera2的请求-结果模型到底怎么跑

Camera2的模型可以用一句话概括：你不断下发请求，系统不断回传结果。请求是CaptureRequest，它描述“这一次我想要的参数组合是什么”；结果是CaptureResult，它告诉你“实际执行时用的是什么参数”。

打开相机的标准流程是固定的几步。先通过CameraManager拿到相机ID列表，用getCameraCharacteristics()读取能力；然后调用openCamera()，在StateCallback的onOpened回调里拿到CameraDevice；接着创建会话，Android 9及以上推荐用SessionConfiguration，之前的版本用createCaptureSession(List<Surface>, ...)；会话建立后，构造预览请求并用setRepeatingRequest()持续下发。

// 预览请求的典型构造，注意每个 set 都可能返回 false val request = device.createCaptureRequest(CameraDevice.TEMPLATE_PREVIEW).apply { addTarget(previewSurface) set(CaptureRequest.CONTROL_AF_MODE, CaptureRequest.CONTROL_AF_MODE_CONTINUOUS_PICTURE) set(CaptureRequest.CONTROL_AE_MODE, CaptureRequest.CONTROL_AE_MODE_ON) set(CaptureRequest.CONTROL_AWB_MODE, CaptureRequest.CONTROL_AWB_MODE_AUTO) } session.setRepeatingRequest(request.build(), captureCallback, backgroundHandler)

这段代码里有个很容易被忽略的细节：set()方法的返回值是布尔值，表示这个key在当前设备上是否被接受。很多人直接忽略返回值，结果设了个设备不支持的参数，界面显示设置成功了，实际拍出来纹丝不动，排查半天以为是API有问题。养成检查返回值的习惯，不接受就说明这个能力不可用，界面上直接置灰，比让用户白点强。

另一个关键点是CaptureResult的读取。TotalCaptureResult里带着这一次实际生效的曝光时间、ISO、对焦距离、测光结果。手动模式做“所见即所得”的难点就在这——你设了1/8秒快门，但实际生效可能是1/8秒加上若干帧的延迟，尤其是高像素模式下，Sensor读出时间本身就有限制。

2.2 CameraX的封装边界在哪里

CameraX把上面那套流程包成了三个用例：Preview、ImageCapture、ImageAnalysis，通过bindToLifecycle()一次性绑定，生命周期自动管理，确实省事。它的封装边界在Camera2Interop这里——你想设置一些Camera2层面的参数，可以通过Camera2Interop.Extender往用例上挂CaptureRequest.Key。

但封装就是封装，它帮你省掉的是样板代码，同时也限制了你对时序的精细控制。举几个实际例子：想做一个“按下快门后立即锁曝光再拍”的连拍逻辑，CameraX里你得绕一圈用Interop去关AE；想严格控制ImageReader的缓冲区数量和格式来做实时处理，CameraX的ImageAnalysis给你的是封装后的ImageProxy，格式和背压策略的调整空间有限。

我的判断标准很朴素：如果你的需求能用“预览+拍照+分析”三个词完整描述，用CameraX；一旦出现“我要在某个精确时刻改变某个参数”这类需求，直接上Camera2。半途从CameraX迁到Camera2的成本，比一开始就选Camera2再慢慢补功能要高得多。

2.3 硬件能力预检：别等跑起来才发现不支持

能力预检这块，我整理了一份必查清单，每次新项目开工先把这些读一遍，打印到日志里存档。

这些数据拿到之后，记得做降级设计。比如某设备曝光时间范围很窄，那手动快门面板就不要给出1/2000秒到1/4秒的完整滑块，直接按实际范围生成档位，用户拖到边界也不会出现无效值。这类“按能力生成UI”的做法，比写死一套参数然后到处加if判断要清爽得多。

3. 动手搭一个原生模式相机APP：完整实操主线

理论铺垫够了，接下来是实打实的搭建过程。我会按我实际做项目的顺序走一遍，从工程骨架到拍照、录像、RAW输出，每一步都给出关键代码和参数计算过程。这里假设你的目标是“一个能手动控制、画质干净、支持专业参数”的相机应用，也就是标题里说的原生模式相机APP。

3.1 工程骨架与预览链路的落地

预览是整条链路里最容易出问题的环节，因为它同时涉及Surface管理、宽高比适配和帧率控制。

Surface的选择上，SurfaceView和TextureView各有取舍。SurfaceView性能更好，因为它在独立的合成层上渲染，不参与View的绘制流程，功耗低、延迟小；缺点是它不支持变换动画、层级关系处理麻烦。TextureView可以像普通View一样做变换，适合需要动画或者叠加复杂UI的场景，但多一层纹理拷贝，功耗会高一些。做相机应用我一般选SurfaceView，只有在必须做预览变形的场景才换TextureView。

创建ImageReader用于预览时，格式选ImageFormat.YUV_420_888还是直接把Surface交给SurfaceHolder，差别很大。能够直接给Surface的情况下，绝对不要走ImageReader做预览。原因很实在：YUV数据从HAL拷到应用层，再从应用层转成纹理显示，多两次拷贝，30fps下每帧1080p的YUV420数据约3.1MB，一秒钟接近100MB的内存带宽开销，中低端机直接卡成幻灯片。

// 直接用 SurfaceHolder 的 Surface 做预览目标 val previewSurface = surfaceView.holder.surface // 关键：设置默认缓冲区尺寸，尺寸不匹配是预览拉伸的头号元凶 surfaceView.holder.setFixedSize(previewSize.width, previewSize.height)

预览尺寸的选取有一套固定逻辑：从StreamConfigurationMap里拿到支持的所有预览尺寸，优先选宽高比与屏幕（或预览容器）最接近的，尺寸不低于容器实际像素尺寸的最小值。举个具体例子，容器是1080×1920，候选里有1280×720、1920×1080、2560×1440，那就选1920×1080，因为它的宽高比是16:9，跟容器一致，且尺寸刚好够用不浪费。如果直接拿2560×1440去渲染到1080的容器里，虽然清晰度不会变差，但每帧多处理70%的像素，功耗和发热都会明显上升。

还有一个细节：预览的宽高比和拍照的宽高比不一定一致。很多设备支持的拍照最大分辨率是4:3，而预览是16:9，切换时如果只是改Surface尺寸，会出现画面跳变。我的做法是拍照完成后按拍照比例裁剪，或者在拍照瞬间短暂冻结预览。前者实现简单，后者体验更连贯，看你愿意投入多少。

3.2 拍照参数的计算与手动模式落地

手动模式的核心就是曝光三要素的联动：曝光时间、ISO、光圈。手机的光圈基本是固定的（少数机型有可变光圈），所以实际能调的就是快门和ISO。

先把曝光量的关系理清楚。曝光值用EV表示，公式是：

EV = log2(N² / t) - log2(S / 100)

其中N是光圈值，t是快门时间（秒），S是ISO。这个公式在手机上的实用意义不在于精确计算，而在于换算补偿关系。举个具体的：当前光圈f/1.8，快门1/60秒，ISO 100，算出来EV约等于11.5。如果你想把快门提到1/120秒（快一档，曝光量少一半），要维持同样的亮度，ISO就得从100提到200。这就是“快门和ISO互抵”的直觉来源，理解了这一点，手动模式调起来就不会手忙脚乱。

实际写代码时，参数设置是这样的：

val request = device.createCaptureRequest(CameraDevice.TEMPLATE_MANUAL).apply { addTarget(captureSurface) // 关闭自动曝光，才能手动设定 set(CaptureRequest.CONTROL_AE_MODE, CaptureRequest.CONTROL_AE_MODE_OFF) // 曝光时间单位是纳秒 set(CaptureRequest.SENSOR_EXPOSURE_TIME, exposureNs) set(CaptureRequest.SENSOR_SENSITIVITY, iso) // 帧间隔要大于等于曝光时间，否则请求会被丢弃 set(CaptureRequest.SENSOR_FRAME_DURATION, frameDurationNs) // 自动白平衡也关掉，改用固定色温 set(CaptureRequest.CONTROL_AWB_MODE, CaptureRequest.CONTROL_AWB_MODE_OFF) set(CaptureRequest.COLOR_CORRECTION_MODE, CaptureRequest.COLOR_CORRECTION_MODE_TRANSFORM_MATRIX) }

这里有两个坑必须提前规避。第一个是SENSOR_FRAME_DURATION和曝光时间的关系：帧间隔必须不小于曝光时间，否则这个请求会被直接丢弃。假设你要拍1/4秒的长曝光，帧间隔就至少得设成250毫秒，这时预览帧率会掉到4fps，界面上必须给出提示，别让用户以为卡死了。第二个坑是CONTROL_AE_MODE_OFF之后有些设备的SENSOR_SENSITIVITY会被限制在一个更窄的范围内，因为自动增益关掉了，这个要去读SENSOR_INFO_SENSITIVITY_RANGE的实际可用区间，不能想当然按最大值设。

对焦的手动控制用的是LENS_FOCUS_DISTANCE，单位是屈光度，也就是焦距的倒数。0表示无穷远，数值越大表示焦点越近。多数设备支持从0到10左右的范围，对应10厘米到无穷远。这个值的直观映射不好做，因为它不是线性的，做UI滑块的时候建议按“近-中-远”分段映射，别直接用线性滑块，用户会疯掉。

提示：手动对焦滑块拖动过程中不要每帧都下发请求，用防抖节流，比如60毫秒一次。高频下发对焦请求会让HAL反复重启对焦马达，声音难听还费电。

3.3 录像链路的码率、帧率与编码器选择

录像这条链路比拍照复杂，因为它涉及编码器、音频采集、封装容器三个额外环节。先从码率算起，这是最容易被忽略但直接影响文件体积和画质的参数。

视频码率的经验公式是：

目标码率 = 宽 × 高 × 帧率 × bpp

bpp（bits per pixel）取0.07到0.15之间，具体看内容复杂度。按1080p30、bpp取0.1算：1920 × 1080 × 30 × 0.1 ≈ 6.2 Mbps。这个值偏低，实际做相机应用建议留足余量，1080p30用15到20 Mbps，4K30用50到60 Mbps。为什么留这么大余量？因为bpp公式算的是理论值，实际场景里快速运动、复杂纹理、画面噪点都会让编码器吃紧，余量给不够就会出现运动场景的马赛克。

编码器的选择上，MediaRecorder开箱即用，适合功能简单的场景；MediaCodec灵活但工作量大。我现在的习惯是拍照和简单录像用MediaRecorder，需要同时输出录像文件和实时分析帧的时候才上MediaCodec加ImageReader的组合。

// MediaRecorder 的关键配置顺序不能乱，错一步就抛异常 recorder.setAudioSource(MediaRecorder.AudioSource.CAMCORDER) recorder.setVideoSource(MediaRecorder.VideoSource.SURFACE) recorder.setOutputFormat(MediaRecorder.OutputFormat.MPEG_4) recorder.setVideoEncoder(MediaRecorder.VideoEncoder.H264) recorder.setVideoSize(videoSize.width, videoSize.height) recorder.setVideoFrameRate(30) recorder.setVideoEncodingBitRate(18_000_000) recorder.setOrientationHint(orientationDegrees)

setOrientationHint这个调用经常被忘掉，导致竖着拍的视频在电脑上播放时是横的。它的取值要从SENSOR_ORIENTATION和当前屏幕方向一起算，前置摄像头还要额外考虑镜像。

高帧率录制（60fps、120fps）需要单独处理，不是简单改个数字就行。要通过CamcorderProfile查询设备是否支持，或者用CONTROL_AE_TARGET_FPS_RANGE指定帧率区间。高帧率模式下曝光时间上限会被压缩，因为它必须在更短的帧间隔内完成读出。120fps下每帧间隔只有8.3毫秒，快门最长也就到1/120秒，这时候拍暗光环境基本废掉，界面上要给出明确提示。

3.4 RAW/DNG与专业参数面板

RAW输出是“原生模式”最有说服力的功能。它的价值在于保留传感器最原始的线性数据，白平衡、色调曲线、锐化这些都是“未烘焙”的状态，后期空间远大于JPEG。

实现上，先确认设备支持RAW——REQUEST_AVAILABLE_CAPABILITIES里包含RAW。然后创建输出目标为ImageFormat.RAW_SENSOR的ImageReader，拍完拿到Image对象，用DngCreator写入DNG文件。

val rawReader = ImageReader.newInstance( rawSize.width, rawSize.height, ImageFormat.RAW_SENSOR, 2 ) // 拿到 Image 之后 val dngCreator = DngCreator(characteristics, captureResult) FileOutputStream(dngFile).use { out -> dngCreator.writeImage(out, image) } dngCreator.close() image.close()

DNG文件的体积要有心理准备。以12bit、4000×3000的RAW为例，理论数据量是4000 × 3000 × 12 / 8 = 18MB，加上元数据和内嵌预览图，单个文件20MB上下很正常。连拍十张就是200MB，存储管理必须提前设计。

专业参数面板的设计上，我的原则是只暴露设备真实支持的能力，并且给出实时反馈。面板上至少要有这几项：快门、ISO、对焦距离、白平衡色温、曝光补偿。每项旁边显示当前实际生效值，从CaptureResult里读，而不是从你设置的请求里读——这两者经常不一致，读结果才真实。

参数联动也要做。用户拖快门的时候，如果补偿掉太多，ISO应该自动跟着变，旁边给个“自动”开关让用户选择是保持曝光还是保持ISO。这种细节决定了这个APP是“能用”还是“好用”。

4. 画质与体验打磨：那些跑通之后才暴露的问题

功能跑通只是开始，真正拉开差距的是画质调优和异常处理。这一章讲的都是“功能已经能用了，但拍出来还是不对劲”的那一类问题，也是我自己踩得最多的部分。

4.1 3A行为的调优

3A指的是自动对焦（AF）、自动曝光（AE）、自动白平衡（AWB）。它们默认的行为各有各的毛病。

自动曝光最常见的症状是画面亮度“呼吸”，也就是取景时亮度忽明忽暗。原因是默认AE会持续调整，遇到画面里有大面积高光或者移动物体时，测光结果来回震荡。解决办法是设置测光区域和测光权重，用CONTROL_AE_REGIONS指定一个区域，坐标要归一化到[-1000, 1000]的坐标系里，同时配合CONTROL_AE_PRECAPTURE_TRIGGER在拍照前做一次预曝光锁定。

自动对焦的问题是“拉风箱”，尤其是在低对比度场景下，对焦马达来回找。可以切换到CONTROL_AF_MODE_AUTO（单次对焦）而不是连续对焦，拍照前主动触发一次对焦，等CONTROL_AF_STATE变成FOCUSED_LOCKED再拍。这样牺牲一点速度，换来的是成片率。

自动白平衡的坑在于同场景多张照片色温不一致。这在连拍时特别明显，第一张偏暖第二张偏冷。要解决就关掉AWB，改用固定的COLOR_CORRECTION_GAINS。计算方法是：先用自动模式拍一张，从CaptureResult里读出实际生效的增益，锁定这组值，后续拍摄都用它。这个技巧在需要色彩一致性的场景里非常好用。

4.2 变焦、多摄与防抖

变焦这块，Android 11之后有了CONTROL_ZOOM_RATIO，直接设倍率，比自己算裁剪区域方便得多。但底层实现差异很大：有些设备是真正的光学变焦，有些是切换物理镜头，有些纯粹是数码裁切。用户看到的是“2倍”，实际可能是另一颗镜头在工作，画质、色彩、对焦表现全变了。

判断当前是哪颗镜头在工作，可以读CaptureResult里的SENSOR_INFO_ACTIVE_ARRAY_SIZE或者直接看物理相机ID。做多摄切换的时候，最大的问题是切换瞬间画面会跳——不同镜头的色彩、亮度、甚至视角都有差异。缓解办法是在切换前先做一次短暂的遮罩过渡，或者在应用层做色彩匹配。

防抖分成光学防抖（OIS）和电子防抖（EIS）。OIS通过LENS_OPTICAL_STABILIZATION_MODE控制，EIS通过CONTROL_VIDEO_STABILIZATION_MODE控制。两者可以同时开，但要注意：EIS开启后会裁切一部分画面来做补偿余量，所以实际视野会变小，这一点要在UI上说明，不然用户会觉得“开了防抖怎么变窄了”。

提示：录制高帧率视频时不要开EIS，因为EIS需要更大的裁切余量，高帧率下每帧可用时间短，补偿效果反而差，还额外增加功耗。

4.3 GPU实时滤镜管线

想在预览上叠加实时滤镜，标准的做法是把预览Surface替换成SurfaceTexture，用OpenGL做渲染，再把处理后的纹理输出到SurfaceView。这条链路的关键是SurfaceTexture的setDefaultBufferSize必须跟相机输出尺寸一致，不一致就是各种拉伸和变形。

一个简化但实用的实现思路是：相机输出到SurfaceTexture，SurfaceTexture在GL线程里更新纹理，着色器做处理，渲染到屏幕。滤镜参数通过uniform变量传入，避免每帧重建着色器。

性能上有几个硬指标要盯住：GL线程必须是独立的，不能占用主线程；纹理更新要处理好时间戳，避免不同步导致的画面撕裂；滤镜复杂度要控制，多pass滤镜在1080p下很容易把中端机的GPU跑满，帧率掉到20以下就得不偿失了。我一般会准备两套着色器，一套轻量版给预览用，一套完整版只用于拍照瞬间的单帧处理，这样两头都能兼顾。

5. 问题排查实录与兼容性速查

相机开发最消耗时间的部分不是写功能，是排查各种“在A机器上正常、在B机器上崩溃”的问题。这一章把我遇到过的高频问题和定位路径整理出来，希望能帮你少熬几个夜。

5.1 黑屏、绿屏、拉伸的定位路径

黑屏是最常见的症状，原因按概率从高到低排：权限没给全（相机权限、存储权限都要检查）、Surface还没准备好就发起会话、相机被其他应用占用、onOpened回调没触发。定位顺序建议是先看日志里有没有CameraAccessException，再看Surface.isValid()，最后才怀疑HAL。

绿屏或者紫边，八成是YUV格式处理错了。YUV_420_888的plane排列在不同设备上可能不同，rowStride和pixelStride必须从Image.Plane里读，不能假设是紧凑排列。如果做NV21转换，务必按实际的stride来处理每一行，直接假设width == rowStride就会错位，表现出来就是颜色错乱或者画面斜切。

预览拉伸，几乎都是宽高比不匹配。检查两件事：SurfaceHolder的setFixedSize是否设成了预览尺寸；容器的布局是否强制了某个固定的宽高比。这两者不一致时，画面就会被硬拉伸。正确做法是按预览的实际宽高比调整容器尺寸，或者用裁剪的方式填充。

还有一种情况是预览方向不对，横屏拍出来是正的，竖屏拍出来是横的。这涉及SENSOR_ORIENTATION、屏幕旋转角度、前置镜像三个变量，计算公式要用到设备方向和传感器方向，别自己瞎试，按标准公式算一遍就对。

5.2 常见问题速查表

这张表我基本随身带着，遇到问题先对一遍，能省掉大半的猜测时间。

5.3 功耗与发热控制

相机是手机上最费电的模块之一，Sensor、ISP、编码器、屏幕全都在高负载运转。做原生模式相机应用尤其要注意，因为手动模式下的长曝光、高ISO降噪、RAW写入都会显著拉高功耗。

几个实用的控制手段：预览帧率不要盲目追高，30fps对绝大多数场景足够，60fps只在需要流畅取景时才开；预览分辨率选够用就好，不要拿4K去做1080容器的预览；手动长曝光结束后立即回到正常预览，不要让Sensor一直挂在长曝光状态；RAW写入放到后台线程，别阻塞相机管线。

还有个容易被忽略的点是相机会话的生命周期。很多人只在onPause里关相机，但onStop、onDestroy也要处理，尤其是横竖屏切换的时候，旧会话没关干净，新会话就建不起来，表现出来就是“转个屏相机就废了”。

我做这类项目时的体会是，相机应用的稳定性不取决于你写了多少功能，而取决于你对异常路径覆盖了多少。正常流程可能只占代码量的三成，剩下七成都在处理“设备不支持”“会话失败”“参数越界”这些情况。把这些兜底逻辑写扎实，用户才不会在关键时刻掉链子。