目录

CameraPicker拍摄的优势及常见问题

问题现象

在开发相机功能时，一般有两种方案可供选择：CameraPicker和自定义相机。相比较功能丰富的自定义相机而言，CameraPicker有什么优势，又可能会有哪些问题呢？

解决方案

CameraPicker核心优势

轻量级开发。
相比于自定义相机的开发流程而言，CameraPicker开发代码量极少，只要在配置好PickerProfile之后调用cameraPicker.pick接口即可，不需要对相机开发有太深的了解，“即插即用”，快速出结果。
无需申请相机权限。
CameraPicker的相机交互界面由系统提供，照片的拍摄和确认都是由用户进行主动确认，因此应用开发者可以不用申请操作相机的相关权限。
隐私安全。
CameraPicker封装的是系统相机能力，开发者仅能获取拍摄后的成片，对于终端用户而言该方式更为安全。

CameraPicker常见问题

系统已经开放地理位置权限，但是CameraPicker拍摄的图片依然看不到地理位置信息。
答：CameraPicker的隐私规格限制决定了其拍摄的图片不会带上地理位置信息。
如何获取CameraPicker拍照生成文件的格式？
答：通过pickerResult.resultUri的扩展名判断文件格式，或者使用image模块的ImageSource接口来获取文件的真实MIME类型，从而准确确定文件格式。
CameraPicker调起系统相机拍照时怎么获取拍摄时间？
答：一般可通过下述两种方案来解决：
- 使用@ohos.file.fs获取照片文件的创建时间。需要在相机拍摄完成后，拿到返回的resultUri，然后使用fileIo.statSync接口创建fileIo.Stat对象，Stat对象中的mtime属性即为该文件上次被修改的时间，一般来说就是拍摄完被覆写的时间。
- 在代码里直接记录时间戳。可根据业务实际需要，在调起Picker拍摄时或者拍摄动作完成后记录时间戳，作为照片拍摄时间。
使用CameraPicker拍照后无法使用uri生成ImagereSource。
答：在对PickerProfile的saveUri配置时，应用沙箱内的这个文件必须是一个存在的、可写的文件。这个文件的uri传入Picker接口之后，相当于应用给系统相机授权该文件的读写权限。系统相机在拍摄结束之后，会对此文件进行覆盖写入。

总结

CameraPicker和自定义相机优劣势对比可参见下表：

方案

优势

劣势

适用场景

CameraPicker

1. 快速上手，代码量极低，节约开发测试成本

2. 无需申请相机权限

3. 系统相机能力，用户的隐私安全更有保障

1. 拍摄页面无法定制，无法嵌入业务的页面布局

2. 功能简单，可调整的拍摄参数较少

快速开发场景，对拍摄效果要求不高。比如用户头像拍摄等场景。

自定义相机

1. 可自定义页面布局

2. 可自定义拍摄参数，改善拍摄效果

3. 可对预览流做二次加工处理

1. 开发测试成本较高，需要有一定相机开发基础

2. 需要自己处理相机权限

深度定制场景。如直播、美图相机等对拍摄效果和自由度要求较高的场景。