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