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. 需要自己处理相机权限	深度定制场景。如直播、美图相机等对拍摄效果和自由度要求较高的场景。

方案

优势

劣势

适用场景

CameraPicker

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

2. 无需申请相机权限

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

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

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

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

自定义相机

1. 可自定义页面布局

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

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

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

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

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