Figure

Hi 刘强

请提供video的同时，提供对应的tlog日志及systrace文件

Thanks.

video+tlog+systrace
ftp://cdiot@192.168.87.46/Figure/video/performance/

Hi 曹覃刚

此问题与com.android.providers.media.module进程关系较大，请协调对应人员进行分析。

1.在图片push到device的过程中，MediaProvider 模块应该会建立一些索引，但日志中存在如下报错，这只是明显的报错，不排除需要debug查看索引是否ok
11-15 13:42:12.213 3537 4962 W MediaProvider: isAppCloneUserPair failed. Users: 0 and 0
11-15 13:42:12.213 3537 4962 W MediaProvider: isAppCloneUserPair for user 0: false
11-15 13:42:12.320 3537 4954 W MediaProvider: isAppCloneUserPair failed. Users: 0 and 0
11-15 13:42:12.320 3537 4954 W MediaProvider: isAppCloneUserPair for user 0: false

2.在通过FILE APP显示图片时，存在如下报错：
11-15 14:02:27.170 3537 8940 W MediaProvider: Failed to fetch original file descriptor
11-15 14:02:27.170 3537 8940 W MediaProvider: java.io.FileNotFoundException: Input file descriptor is already original
11-15 14:02:27.170 3537 8940 W MediaProvider: at com.android.providers.media.MediaProvider.getOriginalMediaFormatFileDescriptor(MediaProvider.java:5718)
11-15 14:02:27.170 3537 8940 W MediaProvider: at com.android.providers.media.MediaProvider.openTypedAssetFileCommon(MediaProvider.java:7134)
11-15 14:02:27.170 3537 8940 W MediaProvider: at com.android.providers.media.MediaProvider.openTypedAssetFile(MediaProvider.java:7115)
11-15 14:02:27.170 3537 8940 W MediaProvider: at android.content.ContentProvider$Transport.openTypedAssetFile(ContentProvider.java:548)
11-15 14:02:27.170 3537 8940 W MediaProvider: at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:327)
11-15 14:02:27.170 3537 8940 W MediaProvider: at android.os.Binder.execTransactInternal(Binder.java:1179)
11-15 14:02:27.170 3537 8940 W MediaProvider: at android.os.Binder.execTransact(Binder.java:1143)

3.进行搜索文件，问题复现时，并没有多余的异常日志吐出，但com.android.providers.media.module进程CPU占用率提升到了114%，需要进一步debug此服务

Thanks.

一.当前的状态
检查了问题发生的条件
①原生的文件应用:com.android.documentsui/.files.FilesActivity
②图片数量超过500张，500张时检索时间在一秒左右，数量越多时间会逐渐增加
在如上条件下会有问题

二.我的分析
使用联想Driver-only的平板做了对比测试(需要保证相同的条件)
Driver-only:除驱动外，没有投入联想任何定制的版本，基本与原生表现相同
在此设备上，也会发生检索时间长的问题，在图片数量为10000张时，检索时间大约3~4秒
另外使用测试的小新平板测试，使用联想自己定制的文件应用，没有此问题，检索速度较快

三.我的结论
从上面的条件与对比来看, 原生的文件应用都存在此问题

四.下一步解析计划
讨论是否有优化的必要
开发的观点是维持现状，原因如下
①从发生的条件看，车载娱乐副屏，拷贝超过500张图片的场景，这个我们认为是极其稀有的，可以说基本没人这么干
②这个问题属于原生的问题，在其它的平板中也一样存在
③问题发生的影响，检索时间两秒多，这是属于可接受的范围。影响较小
④优化的工作量与难度，这个问题涉及到多个模块，且整个流程复杂，工作量与修改难度都较高，需要长时间的投入
⑤对于99%的场景，图片数量都是很难超过500张的，是符合900ms这个需求的

基于上述理由，我们认为没有太大的必要去做这个优化。
请测试这边综合考虑一下

浩云，请从产品角度进行评估。

尽可能的缩短相应时间即可，10000张的场景，的确不是常规使用场景，本地检索需要一定的时间，900ms这个指标如果是客户给出的性能要求文档中明确有说，这个点可能需要和客户讨论一下900ms的一个范围，目前我这边不会认为这个bug的等级，以及紧急程度会很高，且需要花大量时间去优化。

此性能修改需后续跟客户进行商议，解决优先级先往后放

浩云 请帮忙确认下这个的合理范围

该问题，已和客户同步过了，大文件搜索的情况下，需要根据实际情况来更新验证标准，见附件，该bug可以关闭了

同类问题统一关闭，使用报告表格和客户沟通