android44截屏

❶ 安卓系统手机中各文件夹的中文意思

1、android 比较重要的文件夹，里面是一些程序数据，比如google map的地图缓存。

2、AndroidOptimizer 安装“安卓手机优化大师”后生成的文件夹 3、AndroidSDLPAL 解压AndroidSDLPAL_95.zip，得到AndroidSDLPAL文件夹 4、babyplan_caches 宝贝全计划缓存文件 5、 顾名思义，掌上网络、网络输入法之类程序的缓存文件夹。

6、BaiMap 网络地图文件夹 7、BcgmDict ! 8、Beats 跳舞机之类的游戏 9、boyaa_texas_v2 得克萨斯扑克游戏 10、cache ! 11、camera360 12、chinapay 13、DCIM 相机的缓存文件夹。

14、documents Documents To Go 的相关文件夹。

15、DomobInterstitial 是水果忍者里面弹出广告和一些照片 16、download 下载文件夹 17、downloaded_rom 系统更新文件夹 18、droidhen 用手机当电脑摄象头软件的文件夹 19、DX-Theme 点心桌面软件文件夹 20、ea EA出品的游戏（我的是极品飞车） 21、gameloft gameloft/games文件夹是存放游戏数据的。

Gameloft的大型游戏都有几十MB到上百MB的游戏数据与主程序分开存放。

你安装完相应的游戏后，可以打开wifi（省流量）再运行游戏，会自动下载游戏数据资料到这个文件夹；或者也可以不开wifi，从网上下载相应的游戏数据包解压后放到gameloft/games文件夹下面。

22、gfan 机锋市场 23、Go NoteWidget 透明便签软件的文档记录 24、GOLauncherEX GO桌面的缓存文件夹，想换字体的话，字体文件放在这个文件夹的fonts目录下。

25、GoStore GO桌面留下的文件夹 26、果合移动广告,是个广告软件的文件夹！一般可能是缓存的软件在里面！如果他自动生成的话就可能不好删除了！ 27、iReader 顾名思义，ireader的缓存文件夹。

28、LiveBeautyle 腿模 29、LOST.DIR 卡上丢失或出错的文件会跑这里，此目录无用，删了会自动生成。

30、miliao 顾名思义，米聊的缓存文件夹 31、MIUI 顾名思义，MIUI的缓存文件夹。

32、mosecurity 这个应该是金山卫士的文件夹！ 33、Movies 顾名思义，电影的缓存文件夹。

34、msf 手机QQ产生的 35、muwan 顾名思义，拇指玩的缓存文件夹。

36、NceEnglish 新概念英译缓存文件夹 37、Notifications 在SD卡任意位置建立名为“notifications”的文件夹，把自己的铃音扔进去 指手机内存（网上查的，我没太看懂） 38、openfeint 顾名思义，openfeint的缓存文件夹。

39、p2pcache 手机快播视频缓存文件夹，（目前快播安卓手机版使用小文件策略，所以下载完也还是！mv文件，关于下载完合成完整视频的需求已经提交给开发人员评估是否在后续版本优化改进） 40、persist_images 一款拍照软件图片存放文件夹 41、Pictures 截屏图片存放处 42、Podcasts 播客文件夹，删了不影响 ! 43、QDReader 起点读书缓存文件夹 44、QuickPai 顾名思义，QuickPai的缓存文件夹条。

45、qvod 顾名思义，qvod的缓存文件夹 46、ringtones 网上下载 *** 存放文件夹 47、RMS 这是一个你进入木马清理或者系统优化时的临时备份文件 48、ROMs 模拟器文件夹 49、sgsupdate 是三国杀的升级文件安装包 50、snda 盛大网络公司出的游戏，如果你卸载了产品这个也可以删掉。

51、spbshell_log SPB主题日志 52、svox一款中文语音插件，可以支持多种语言阅读，第三方语音识别软件 53、TalkingFriends 会说话的tom猫录制的视频文件所保存的目录。

54、Tencent ，腾讯软件的缓存目录。

55、tmpcache 酷我音乐下载时缓存文件夹 56、ttpod ttpod是天天动听的安装目录，里面会有一些文件夹都是相关功能的目录，一般会有：data——系统目录，skin——皮肤目录，lyrics——歌词目录，log——日志文件目录（有关天天动听运行的一些记录，如果运行有问题，log.txt这个文件可以很直观的看出是哪一个环节出了问题。

）57、UCDownloads UCweb浏览器下载文件缓存的保存目录。

58、UCMobileConfig UC浏览器中的配置文件 59、youmicache 这是一个广告联盟的广告缓存文件 不是我原创的，网上找的 1、.android_secure 是官方app2sd的产物，删了之后装到sd卡中的软件就无法使用了，小心别误删。

2、.Bluetooth 用蓝牙之后就会有这个。

3、.mobo Moboplayer的缓存文件 4、.QQ QQ的缓存文件，定期清除。

**** Hidden Message ***** 24、KingReader 开卷有益的缓存文件夹。

25、LazyList Appla（黑市场）的缓存目录，也许和其他程序也有关，暂时不太清楚，慎重使用。

26、LOST.DIR 卡上丢失或出错的文件会跑这里，此目录无用，删了会自动生成。

27、moji 顾名思义，墨迹天气的缓存目录。

28、MusicFolders poweramp产生的缓存文件夹。

29、openfeint 顾名思义，openfeint的缓存文件夹。

30、Picstore 图片浏览软件建立的一个目录。

31、Playlists 播放列表的缓存文件夹。

32、renren 顾名思义，人人网客户端的缓存文件夹。

33、screenshot 貌似是截屏图片保存的目录，不过我不记得自己装过screenshot这个软件，或许不好用删了。

34、ShootMe 顾名思义 shootme截屏后图片文件保存的目录。

35、SmartpixGames Smartpix Games出品游戏的缓存文件夹，比如Jewellust。

36、sogou 顾名思义，搜狗拼音输入法的随机缓存文件夹 37、SpeedSoftware RE文件管理器的缓存文件夹。

38、SystemAppBackup SystemApp remove （深度卸载）备份系统文件后，备份文件保存的目录。

39、TalkingFriends talking tom（ 会说话的tom猫）录制的视频文件所保存的目录。

40、Tencent 顾名思义，腾讯软件的缓存目录，比如QQ 41、TitaniumBackup 钛备份备份的程序所保存的目录。

42、TunnyBrowser 海豚浏览器的缓存目录 43、UCDLFiles UC迅雷下载文件的保存目录。

44、UCDownloads UCweb浏览器下载文件缓存的保存目录。

45、VIE Vigte 的缓存目录。

46、V"PN 顾名思义，V|PN数据的缓存目录 47、yd_historys 有道词典搜索历史的缓存目录 48、yd_speech 有道词典单词发音的缓存目录。

49、youmicache 删掉后还会自动生成，悠米广告的缓存目录，广告程序内嵌在其程序中，没用别装有米。

50、Glu Glu系列游戏的资料包存放地，如3D猎鹿人，勇猛二兄弟等。

51、apadqq-images QQ for pad 的缓存目录。

52、DunDef 地牢守护者的数据包。

53、KuwoMusic 顾名思义，酷我音乐的相关文件夹。

54、MxBrowser 遨游的缓存目录。

55、Camera360 相机camera360的随机缓存目录，可以定期清除。

56、TTPod 顾名思义，天天动听的缓存目录。

57. My documents 自己手机启用各种程序任务记录文档 定期清除 时间长了会积累很多 占用SD卡内存。

58. .nomedia 手机中隐藏的音频 图片文件夹 可以自设在相关文件夹中。

59. media（媒体文档） 使用电话通话录音 或在线浏览视频等媒体 产生的音频文件 记录存档的目录。

60. digua 地瓜软件的相关文件 61. 机锋市场的相关文件（下面apk子文件夹里是机锋市场下载软件的缓存文件，LPNS里是机锋云推送的文件） 62. 如果你用了“截图助手”软件，截图保存在data.edwardkim.android.screenshotitfullscreenshots里 63. sogou下的sga文件夹是放搜狗皮肤的，你下载好搜狗皮肤后放到该路径下，在皮肤设置里安装启用就好 64. 如果你刷了MIUI,自动升级时的ZIP刷机包默认保存在downloaded_rom下 65. NoteWidget 透明便签软件的文档记录

❷ 安卓手机怎么截图

您慎孙旁好，不同的手机具体的截屏方法大都大同小异，以小米手机为例介绍截屏方法：

1、传统截屏方法：

在需要截屏的界面同时按下音量键和关屏键即可对当前页面进行截屏操作了。

2、任务栏截屏

下拉手机的任务栏，然后找到截屏选项，点击截屏即可截取当前页面了。

❸ Android—ADB命令

1、查看最上层成activity名字:

adb shell mpsys activity | findstr "mFocusedActivity"
或者 adb shell mpsys window w | findstr / | findstr name=
2、查看Activity的任务栈：

3、显示所有的activities的信息,包括任务栈等:

adb shell mpsys activity
4、查看Android应用包名package和入口activity名称 ：

aapt mp badging E:\apk\es3.apk
5、显示accounts信息:

adb shell mpsys account
5、显示CPU信息 :

adb shell mpsys cpuinfo
查看CPU使用信息

adb shell top -n 1 -d 0.5 | findstr proc_ id
6、显示键盘，窗口和它们的关系

adb shell mpsys window
当我们需要知道设备的分辨率时

adb shell mpsys window displays
查看UI绘制的各个层级信息

adb shell mpsys SurfaceFlinger
7、显示wifi信息

adb shell mpsys wifi
8、电量信息及CPU 使用时长

adb shell mpsys batteryinfo $package_name
9、获取安装包信息

adb shell mpsys package packagename
10、每个应用的启动次数和时间

adb shell mpsys usagestats
11、显示状态栏相关的信息

adb shell mpsys statusbar
12、内存信息（meminfo package_name or pid 使用程序的包名或者进程id显示内存信息）

adb shell mpsys meminfo
得到com.teleca.robin.test进程使用的内存的信息 adb shell mpsys meminfo com.teleca.robin.test
13、磁盘相关信息

adb shell mpsys diskstats
14、电池相关信息

adb shell mpsys battery
15、显示Alarm信息

adb shell mpsys alarm
统计系统耗电量

adb shell mpsys batterystats
设置线程的优先级

adb shell mpsys activity|grep oom_adj
16、强制关闭一个应用程序；

adb shell am force-stop <PACKAGE>
17、查看内存信息

adb shell cat proc/meminfo
指定进程内存地址映射

adb shell cat proc/pid/maps
指定进程内存详细使用信息

adb shell cat proc/pid/smaps
VSS. RSS. PSS. USS 信息

adb shell procrank
指定进程VSS. RSS. PSS. USS 详细信息

adb shell procmem pid
18、查看可输入的设备

adb shell getevent -p
19、获得特定设备的输入信息

adb shell getevent /dev/input/event0
20、点击

adb shell input tap x y
21、发送按键

adb shell input keyevent 82(keycode)
22、输入文本

adb shell input text XXXX
23、查看报名中包含mobileqq的进程

adb shell ps | findstr mobileqq
24、远程进程ID

adb jdwp
25、获取序列号

adb get-serialno
26、重启到bootloader，即刷机模式

adb reboot bootloader
27、重启到recovery，即恢复模式

adb reboot recovery
28、获取机器MAC地址：

adb shell cat /sys/class/net/wlan0/address
29、获取CPU序列号

adb shell cat /proc/cpuinfo
30、覆盖安装（保留数据和缓存文件，重新安装apk）

adb install -r <apkfile>
31、安装apk到sd卡

adb install -s <apkfile>
32、卸载app但保留数据和缓存文件

adb uninstall -k <package>
33、查看设备cpu和内存占用情况

adb shell top
34、查看占用内存前6的app

adb shell top -m 6
35、刷新一次内存信息，然后返回

adb shell top -n 1
36、查询各进程内存使用情况

adb shell procrank
37、查看指定进程状态

adb shell ps -x [PID]
38、查看后台services信息

adb shell service list
39、查看当前内存占用（该方式只能得出系统整个内存的大概使用情况） 车
如果你想查看所有进程的内存使用情况

adb shell procrank
40、查看IO内存分区

adb shell cat /proc/iomem
41、查看wifi密码

adb shell cat /data/misc/wifi/*.conf
42、清除log缓存

adb logcat -c
43、查看设备信息

adb shell cat /system/build.prop
44、跑monkey

adb shell monkey -v -p your.package.name 500
45、列出目标设备上安装的所有app的包名

adb shell pm list packages
46、截屏命令：

adb shell screencap -p /sdcard/screen.png

adb pull /sdcard/screen.png

adb shell rm /sdcard/screen.png
录制手机屏幕,视频格式为mp4,存放到手机sd卡里，默认录制时间为180s：

adb shell screenrecord
限制视频录制时间为10s,如果不限制,默认180s:

adb shell screenrecord --time-limit 10 /sdcard/demo.mp4
指定视频分辨率大小:

adb shell screenrecord --size 1280*720 /sdcard/demo.mp4
指定视频的比特率:

adb shell screenrecord --bit-rate 6000000 /sdcard/demo.mp4
在命令行显示log:

adb shell screenrecord --time-limit 10 --verbose /sdcard/demo.mp4
47、设置、获取属性信息

adb shell getprop [key]

adb shell setprop [key] [value]
监听系统属性的变化，如果期间系统的属性发生变化则把变化的值显示出来

adb shell watchprops
48、adb logcat 每一条日志消息都有一个标记和优先级与其关联。
（1）标记是一个简短的字符串，用于标识原始消息的来源 (例如"View" 来源于显示系统)。优先级是下面的字符，顺序是从低到高：

V — 明细 (最低优先级)
D — 调试
I — 信息
W — 警告
E — 错误
F — 严重错误
S — 无记载 (最高优先级，没有什么会被记载)
（2）查看过滤日志

adb logcat ActivityManager:I *:S
*:S 用于设置所有标记的日志优先级为S，可以确保输出符合指定的过滤器设置的一种推荐的方式，
这样过滤器就成为了日志输出的“白名单”
显示所有优先级大于等于“warning”的日志

adb logcat *:W
（3）日志消息在标记和优先级之外还有很多元数据字段，这些字段可以通过修改输出格式来控制输出结果， -v 选项加上下面列出的内容可以控制输出字段：

brief — 显示优先级/标记和原始进程的PID (默认格式)
process — 仅显示进程PID
tag — 仅显示优先级/标记
thread — 仅显示进程：线程和优先级/标记
raw — 显示原始的日志信息，没有其他的元数据字段
time — 显示日期，调用时间，优先级/标记，PID
long —显示所有的元数据字段并且用空行分隔消息内容
使用 thread 输出格式

adb logcat -v thread
（4）Android日志系统为日志消息保持了多个循环缓冲区，而且不是所有的消息都被发送到默认缓冲区，要想查看这些附加的缓冲区，可以使用-b 选项，以下是可以指定的缓冲区：

radio — 查看包含在无线/电话相关的缓冲区消息
events — 查看事件相关的消息
main — 查看主缓冲区 (默认缓冲区)
查看radio缓冲区

adb logcat -b radio
48、打印应用程序的log

adb logcat -b main -v time>app.log
49、打印射频相关的log，SIM STK也会在里面，modem相关的ATcommand等，当然跟QXDM差的很远了

adb logcat -b radio -v time> radio.log
50、打印系统事件的日志，比如触屏事件

adb logcat -b events -v time
51、tcpmp 是很有用的，对于TCP/IP协议相关的都可以使用这个来抓

adb shell tcpmp -s 10000 -w /sdcard/capture.pcap
52、状态信息，里面包含有dmesg，mpstate和mpsys

adb bugreport>bugreport.log
53、kernel的log凡是跟kernel相关的，比如driver出了问题（相机，蓝牙，usb，启动，等等吧）

adb shell dmesg > ldmesg_kernel.log
54、mpstate是系统状态信息，里面比较全，包括手机当前的内存信息、cpu信息、logcat缓存，kernel缓存等等 。

adb shell mpstate
55、关于系统service的内容都在这个里面

adb shell mpsys
56、显示内存信息

adb shell mpsys meminfo system

❹ EMUI9.1有没有必要升级

我在用的mate 20申请了EMUI 9.1的公测版，使用之后，最明显的体会就是流畅度的提升。我个人觉得EMUI 9.1很有必要升级，下文具体说一说。

华为的EMUI 9.1支持方舟编译器， 底层对安卓系统进行了优化，提升了系统运行的流畅度。

传统的安卓编译器需要依靠java虚拟机，采用“边解释，边执行”的方式，首先需要将java编写代码编译为java虚拟机认识的dex码，然后java虚拟机翻译成机器认识的二进制机器码。 两道工序，影响了应用程序的执行效率。

方舟编译器实现了代码的静态编译， 直接将java源码编译成机器认识的二进制机器码 ，提升了执行效率。根据实验数据，经过方舟编译器编译的系统组件，系统流畅度提升了24%，响应时间提升了44%，第三方应用流畅度提升了60%。

传统的安卓系统采用了linux的ext4文件系统，升级到EMUI 9.1之后可以使用华为的EROFS文件系统。

EROFS是一种压缩文件系统，采用了固定大小（4K）压缩输出，提升了闪存随机读取的速度，同时节省了手机存储空间。根据测试，同等条件下， 文件的随机读取速度提升了20%，存储空间节省了2GB，可以多存储1000多张照片。

这次EMUI 9.1，华为的图形加速技术升级到了GPU Turbo 3.0，支持更多的主流 游戏 ，累计支持60款国内 游戏 。 相比上一代2.0技术，性能提升了60%，同时功耗降低了10% ，在玩 游戏 时可以实现高帧率，同时降低了功耗。

上述只是列举了EMUI 9.1的三项“黑 科技 ”，通过方舟编译器、EROFS文件系统、GPU Turbo 3.0三个底层技术提升了系统运行流畅度。此外，EMUI 9.1还支持“华为一碰传”，传输1GB的文件只需要几秒；支持BMW手机钥匙等等。总之，EMUI 9.1是值得升级的。

华为最近升更新了EMUI9版本，这个版本是基于Android9.0的版本。如果你的设备在设备支持范围之内我当然强烈建议升级，不过很遗憾的是，华为EMUI从来对于老机型的支持都不够良心，这一点跟小米比起来确实做得很差，MIUI10对于很多小米老机型都支持了。

抛开EMUI9对于老机型的支持不够，我们来看一下EMUI9到底有哪些功能上的亮点。

华为前不久发布了方舟编译器，在底层编译优化和AI精准预测技术，EMUI9运行效率提升，经过实际测试，系统响应速度25.8%，应用启动时间缩短了102毫秒，整体操作流畅度提升了12.9%。

尤其是在极速射击、闪躲移动这些 游戏 场景的时候，GPU Turbo2.0能够让你的操作反馈快人一步。针对于目前热门手游，采用AI 游戏 场景负载预测和AI触控智能调度，提升 游戏 流畅度，触控延迟降低36%，与此同时只能温控系统能够高效降低机身温度，屏幕热点温度能够下降3.6摄氏度。

iOS的照片故事集一直都做得挺好的，现在EMUI9也把这个功能逐渐做得更加强大，众多人物中锁定主角，更加聪明的从冗长的剧情剪辑精彩片段。AI能力能够扩展到视频编辑领域，只能检测人脸片段，老友聚会、孩子生日party等等不同场景故事集。

AI识物帮助你解密名车萌宠，还可以像 健康 小助手一样，迅速对食物进行体积建模，帮助你迅速推算出苹果或者汉堡包的卡路里。看剧、逛街、游玩的时候，或者你在网上浏览的时候，看见心动的物品，随手扫一扫就可以快速获得精选购买链接，买遍全球。

AI语音功能加入了更多使用的功能，比如查机票、放歌曲、发微信、打电话，你也可以自定义一些功能，当然这跟三星的Bixby相比，还是有比较大的差距。切换为驾驶场景，你可以用指令通讯、 娱乐 、导航进行操控，这样你能够专注于驾驶，行车更加安全。

华为是少数优化了无线投屏功能的厂商，一键快速投屏，并且支持语音控制、涂鸦笔、一键截屏等功能，你在使用演示的时候来电和信息不会在大屏上显示，这样能够更好的保护你的个人隐私。

通过华为share自动发现打印机，无需安装任何应用，就能迅速连接打印。通过一键换机功能，可以迅速将通讯录、照片、视频资料等迅速迁移至新的手机，并且安卓或iOS都可以实现，操作简单。

邮件功能内置了一键翻译，译文可以一键插入正文，外文邮件能够更加轻松的回复。外文菜单只要随手拍一拍就能了然于兄。支持通话实时翻译，通话语音实时翻译成文字并播报。

智能备忘录支持语音、键盘、手写、拍照等多种记录方式。全剧侧边栏开关，一步直达记录即时灵感。除此之外，通过AI进行安全防范，对App敏感权限进行管理，适配了更多的手势操作，尤其是适配了很多单手操作手势。

作为华为手机的忠实用户，也收到9.1.312版本推送！但看到部分创作者发布华为EMUI9.1不实的内容，专门咨询了下官方客服并得到了相关的答复，目前华为mate20、p20系列并不支持方舟编译器以及EROFS 文件系统，下边附上相关咨询截图！

希望这部分"优质"创作者@Geek视界 @LeoGo 科技 @小锋玩智能 能删除或更改已发布的不实内容，你们都是优秀的创作者，拥有很多的粉丝，希望在发布内容前要进行必要的核实和验证！

客服表示mate20系列计划近期推送，但此次并不支持！我也非常期待这些技术对手机的适配，但华为新技术的确对老版本手机系统的支持非常不给力啊，尤其是mate和p系列都是华为的旗舰手机！你们怎么看呢？

很高兴回答你的问题。

众所周知EMUI操作系统是华为根据安卓通过自家的深层制订的操作系统。今年已经升级到EMUI9.1了，这套操作系统凝结了华为公司的技术结晶，早在这套操作系统用在mate9上面时，华为就对外宣布可以做到18个人月不卡，对于当时普遍认为苹果iOS系统强于安卓系统，尤其是流畅成都上，一直是安卓系统追赶的标杆。华为经过制定后的EMUI操作系统能够保证18月不卡顿已经是非常大的进步了。经过3年的市场检验，也确实做到了18个月不卡顿。足以见这套操作系统确实已经成熟。

今年这套操作系统已经升级到了EMUI9.1版本，现在这套操作系统已经搭载到华为生产的大部分机型上。今年更是对这套操作系统进行了优化，比以往在流畅方面更近一步，并且对于 游戏 进行了归纳，让用户的 游戏 体验也有所增加了。而EMUI9.1版本比上一个版本主要是在相机方面进行了优化，如超级夜景的升级和抖动方面的升级。所以可以放心升级，我现在用的就是EMUI9.1版本，目前没有什么大问题。希望可以帮到你。

除了手机的自带输入法我非常不习惯之外，EMUI9.1是目前华为手机系统中最流畅的系统，没有之一。

如果你的手机可以升级EMUI9.1系统，那么我确实建议你升级！华为mate 20 pro头一批参与内测的用户，使用以后确实能够感觉到： 流畅！

我们知道它的流畅是建立在：

总结：我是建议考虑升级的，流畅度确实提升，续航比之前要好一些，也没有感觉到发热。

完全没有必要升级！！！

我是p10p用户，总是给我推送9.1通知。

不胜其烦，置之不理。

可惜有一天。脑子短路，手指抽筋。

点了升级！！！经过漫长等待。自动重启

界面似乎花哨了一点点！！！

但是！但是！弊端太明显了！！！

一。掉电很快！以前玩一天到晚上也有电。

现在升级以后，电量撑不到晚上就10%下

二。运行很慢！以前运行微信qq很轻松

现在升级以后。打开微信就提示没响应！

哎呀！我去！去年带了个表！真是无语！

真想回到升级以前的版本！怎么实现呢！

只怪自己太手贱！好好的你升级干什么！

都是经验和教训啊！如果手机配置不高，

千万别升级！否则你哭都来不及！真的！

完全是自己的真实感受！千万别乱喷！！

@潍坊五好青年

EMUI9.1有没有必要升级？我将从几点分析

在动画过渡方面相比上代的EMUI 8.2来说，全面屏手势返回桌面等操作一改以往掉帧的坏印象，可用流畅丝滑来形容。这是由于采用了EROFS系统，使随机读取性能提升20%，让系统空间节省了2GB。

GPU Turbo 3.0就是大家说的“很吓人的技术”迎来了第三代升级，覆盖了国内外热门60款 游戏 ，而和平精英、荒野行动，王者荣耀，崩坏3等均进行了底层优化体验，在保持低功耗下满帧体验。

一碰传得到了升级，可以实现手机与笔记本之间的互传互通，轻碰一下，即能将图片、文档、视频等疾速互传。笔者尝试了下几百张高清图片，也就1分钟多点的时间即能传完，相比还要蓝牙配对，有线连电脑实在省时省力。

从耗电方面来看，笔者的P30 Pro能满负荷地使用12小时，中底使用可以是一天多一点，证明很是省电。

4G双卡双待的用户，现在有着智能切换移动信号，即当其中一张信号不好，会智能切换到另一张上。

智能语音助手，现在长按电源键3秒即可开启，对于有车一族或者放在口袋连接蓝牙耳机的用户更方便。

EMUI9.1很是值得升级，在流畅度有很大的提升，对于智能家居和省电方面也造成很大的努力。

首先对于我来说系统每次推出系统更新我本人基本耐不住体验的诱惑感。当然决定权是取决于你要不要升。升级好处是可以体验新版的安卓系统毕竟有些人想体验新鲜感，升级后修复了部分中的bug，提高了手机安全性。不过还得看手机机型还适不适合在度升级，相比以往的机型内部设备老化升级后可能会运行不起来导致手机卡顿。

Mate10 pro已升级9.1

为什么P20Pro没有这个系统升级呢。目前最高只到9.0.187版本。

❺ Android P 系统稳定性问题分析方法总结

Android系统最开始是为手机设计的，在机顶盒，电视，带屏音箱等大屏上运行后，芯片厂家做些适配，产品厂家也会做系统客制化，有时候还要适配第三方应用..等待
这种适配容易引人系统的稳定性问题，系统稳定性对于用户体验至关重要，很多问题也都比较类似，android系统对系统性能，稳定性分析工具也比较多，下面根据工作中遇到的问题做个总结。

从表现来看有: 死机重启, 自动关机, 无法开机,冻屏,黑屏以及闪退, 无响应等情况;

从技术层面来划分无外乎两大类: 长时间无法执行完成(Timeout) 以及异常崩溃(crash). 主要分类如下:

ANR(Application Not responding)，是指普通app进程超过一定时间没有执行完，系统会弹出应用无响应对话框. 如果
该进程运行在system进程, 更准确的来说,应该是(System Not Responding, SNR)

ANR产生的原因可能是各种各样的，但常见的原因可以分为：

1.logcat日志
2.trace文件(保存在/data/anr/traces.txt)
从logcat里可以看到死锁的打印
从traces.txt可以看到线程的函数调用栈

10-16 00:50:10 820 907 E ActivityManager: ANR in com.android.systemui, time=130090695
10-16 00:50:10 820 907 E ActivityManager: Reason: Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50000114 (has extras) }
10-16 00:50:10 820 907 E ActivityManager: Load: 30.4 / 22.34 / 19.94
10-16 00:50:10 820 907 E ActivityManager: Android time :[2015-10-16 00:50:05.76] [130191,266]
10-16 00:50:10 820 907 E ActivityManager: CPU usage from 6753ms to -4ms ago:
10-16 00:50:10 820 907 E ActivityManager: 47% 320/netd: 3.1% user + 44% kernel / faults: 14886 minor 3 major
10-16 00:50:10 820 907 E ActivityManager: 15% 10007/com.sohu.sohuvideo: 2.8% user + 12% kernel / faults: 1144 minor
10-16 00:50:10 820 907 E ActivityManager: 13% 10654/hif_thread: 0% user + 13% kernel
10-16 00:50:10 820 907 E ActivityManager: 11% 175/mmcqd/0: 0% user + 11% kernel
10-16 00:50:10 820 907 E ActivityManager: 5.1% 12165/app_process: 1.6% user + 3.5% kernel / faults: 9703 minor 540 major
10-16 00:50:10 820 907 E ActivityManager: 3.3% 29533/com.android.systemui: 2.6% user + 0.7% kernel / faults: 8402 minor 343 major
......
10-16 00:50:10 820 907 E ActivityManager: +0% 12832/cat: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: +0% 13211/zygote64: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: 87% TOTAL: 3% user + 18% kernel + 64% iowait + 0.5% softirq

发生ANR的时间 00:50:10 ,可以从这个时间点之前的日志中，还原ANR出现时系统的运行状态
发生ANR的进程 com.android.system.ui
发生ANR的原因 Reason关键字表明了ANR的原因是处理TIME_TICK广播消息超时
CPU负载 Load关键字表明了最近1分钟、5分钟、15分钟内的CPU负载分别是30.4、22.3、19.94.CPU最近1分钟的负载最具参考价值，因为ANR的超时限制基本都是1分钟以内， 这可以近似的理解为CPU最近1分钟平均有30.4个任务要处理，这个负载值是比较高的
CPU使用统计时间段 CPU usage from XX to XX ago关键字表明了这是在ANR发生之前一段时间内的CPU统计,类似的还有CPU usage from XX to XX after关键字，表明是ANR发生之后一段时间内的CPU统计
各进程的CPU使用率
以com.android.systemui进程的CPU使用率为例，它包含以下信息：
总的CPU使用率: 3.3%，其中systemui进程在用户态的CPU使用率是2.6%，在内核态的使用率是0.7%
缺页次数fault：8402 minor表示高速缓存中的缺页次数，343 major表示内存的缺页次数。minor可以理解为进程在做内存访问，major可以理解为进程在做IO操作。 当前minor和major值都是比较高的，从侧面反映了发生ANR之前，systemui进程有有较多的内存访问操作，引发的IO次数也会较多
CPU使用汇总 TOTAL关键字表明了CPU使用的汇总，87%是总的CPU使用率，其中有一项iowait表明CPU在等待IO的时间，占到64%，说明发生ANR以前，有大量的IO操作。app_process、 system_server, com.android.systemui这几个进程的major值都比较大，说明这些进程的IO操作较为频繁，从而拉升了整个iowait的时间

traces.txt 如下
----- pid 29533 at 2015-10-16 00:48:29 -----
Cmd line: com.android.systemui
DALVIK THREADS (54):
"main" prio=5 tid=1 Blocked
| group="main" sCount=1 dsCount=0 obj=0x75bd5818 self=0x7f8549a000
| sysTid=29533 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0x7f894bbe58
| state=S schedstat=( 289080040422 93461978317 904874 ) utm=20599 stm=8309 core=0 HZ=100
| stack=0x7fdffda000-0x7fdffdc000 stackSize=8MB
| held mutexes=
at com.mediatek.anrappmanager.MessageLogger.println(SourceFile:77)

Android系统中，有硬件WatchDog用于定时检测关键硬件是否正常工作，类似地，在framework层有一个软件WatchDog用于定期检测关键系统服务是否发生死锁事件。
watchdog 每过30s 检测一次， 如果要监控的线程30s 后没有响应，系统会mp出此进程堆栈，如果超过60s 没有相应，会触发watchdog，并重启系统
10:57:23.718 579 1308 W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.am.ActivityManagerService on foreground thread (android.fg), Blocked in handler on main thread (main), Blocked in handler on ActivityManager (ActivityManager)
10:57:23.725 579 1308 W Watchdog: android.fg annotated stack trace:
10:57:23.726 579 1308 W Watchdog: at com.android.server.am.ActivityManagerService.monitor(ActivityManagerService.java:26271)
10:57:23.727 579 1308 W Watchdog: - waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService)
10:57:23.727 579 1308 W Watchdog: at com.android.server.Watchdog DeliveryTracker.alarmTimedOut(AlarmManagerService.java:4151)
10:57:23.733 579 1308 W Watchdog: - waiting to lock <0x00aaee38> (a java.lang.Object)
......
10:57:23.736 579 1308 W Watchdog: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:838)
10:57:23.739 579 1308 W Watchdog: ActivityManager annotated stack trace:
10:57:23.740 579 1308 W Watchdog: at com.android.server.am.ActivityStack$ActivityStackHandler.handleMessage(ActivityStack.java:405)
10:57:23.740 579 1308 W Watchdog: - waiting to lock <0x0bb47e39> (a com.android.server.am.ActivityManagerService)
10:57:23.740 579 1308 W Watchdog: at android.os.Handler.dispatchMessage(Handler.java:106)
10:57:23.741 579 1308 W Watchdog: *** GOODBYE!
分析：
提示 ActivityManagerService的android.fg,main,ActivityManager 线程Block了,但logcat里只能看到
android.fg等待0x0bb47e39 锁,main 等待0x00aaee38锁,ActivityManager等待0x0bb47e39锁,无法进一步分析,需要看traces.txt
Cmd line: system_server
......
"main" prio=5 tid=1 Blocked

当出现应用闪退，可以从两个方面查看：
1、是否应用崩溃：
可以通过logcat –s AndroidRuntime DEBUG过滤日志，查看应用奔溃的具体堆栈信息。
其中AndroidRuntime的TAG打印java层信息，DEBUG的TAG打印native层的信息。
2、是否被lowmemorykiller杀掉：
可以通过 logcat –s lowmemorykiller 过滤日志，注意adj 0是代表前台进程。例如：
03-08 04:16:58.084 310 310 I lowmemorykiller: Killing'com.google.android.tvlauncher' (2520), uid 10007, adj 0
发生这种情况，需要mpsys meminfo 查看当前内存状态，是否有进程内存泄漏，导致系统内存不够，出现前台进程被杀，造成闪退。

测试过程中，经常遇到屏幕闪烁的现象，需要排除是OSD层闪烁，还是video层闪烁。
1、先通过android原生方法：screencap截图, screenrecord 录制视频，这里都是截取的OSD层，查看是否有闪屏现象。
2、OSD没有问题，就需要从更底层的显示模块分析，一般需要芯片厂家提供debug手段，不同芯片厂家方案不一样。
3, 有时候输出不稳定，hdmi/mipi信号干扰，输出频率异常等也会导致闪屏，这种情况需要硬件协助分析。
如果OSD层也闪烁，则需从系统和应用层面分析。如曾遇到在开机向导界面，有个应用不断被唤起，导致走开机向导时出现连续闪灰屏的现象。

黑屏分UI黑屏，视频播放黑屏但UI正常等，2种场景

1、screencap截屏，排查OSD层图形是否正常，
2、如果OSD图形正常，需要排查显示输出模块是否异常。
3、电视机里面屏显是单独控制，如果屏参配置错误会导致整改黑屏。
OSD异常，需要排查顶层activity是否黑屏，window是否有异常等.

1，排查视频图层或者window是否创建成功。
2，排查解码是否有异常，不同的应用youtube,netflix,iptv解码方式不一样，需要具体问题具体分析。

如下，ActivityManager因为空对象引用而挂掉，导致system_server重启
*** [FATAL EXCEPTION IN SYSTEM PROCESS: ActivityHanager [
^ava.lang.NullPointerException: Attempt to invoke virtual method 'void co®.android.internal.os.KernelSingleUidTimeReader.iBarkDataAsStale(boolean)' on a null object reference
at com.android.internal.os.BatteryStatsIiaplSConstants.(BatteryStatslnpl.java:13355)
at com.android.internal.os.BatteryStatsInplSConstants.upddteConstants(BatteryStatsImpl.java:13330)
at com.android.internal-o-batteryStatslMpl$Constants-onChange(BatteryStatsInpl-java:13316)
at android.database.Contentobserver.onChange(ContentObserver.java:145)
解决方法：修复空指针

DEBUG : pid: 296, tid: 1721, name: Binder：296_4 >>> /system/bin/surfaceflinger <<<
DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr ------
DEBUG : Abort message: 'status.cpp:149] Failed HIDL return status not checked: Status(EXTRANSACTIONFAILED):
DEBUG : r0 00000000 rl 000006b9
DEBUG ： C4 00000128 r5 000006b9
r2 00000006 r3 a5c5d620
r6 a235d60c r7 0000010c
DEAD_OB3ECT：
DEBUG : r8 00000019 r9 0000015d
DEBUG : ip a6ablbec sp a235d5f8
rlO a568f090 rll a620dce9
Ir a5be901d pc a5be0da2
/system/lib/libc.so (abort+62)
/system/lib/libbase.so (android::base::DefaultAborter(char const )+6)
backtrace:
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libsurfaceflinger.so
/system/lib/libbase.so (android::base::LogMessage::~LogMessage()+502)
/system/lib/libhidlbase.so (android::hardware::details::return_status::~return_status()+184)
(android::Hwc2::impl::Composer::getActiveConfig(unsigned long long, unsigned int )+56)
(HWC2::Display::getActiveConfig(std::_1::shared_ptr<HWC2：:Display::Config const>*) const+38)
(android::HWComposer::getActiveConfig(int) const+64)
(android::SurfaceFlinger::resyncToHardwareVsync(bool)+64)
可以根据backtrace来进行定位异常崩溃的地方。Android P上， backtrace使用Java上下文来显示，省去使用addr2line来转换的一个过程，方便调试分析问题。但是实际场景中，
有些native进程崩溃只有pc地址，而无函数信息，或者需要定位到具体的某个文件某个函数，则可借助堆栈分析工具addr2line。
addr2line：根据堆栈定位具体函数和文件
addr2line -e libsurfaceflinger.so -f 00071a09
addr2line -e libsurfaceflinger.so -f 00071a09
_
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp:1229
需注意两点：
1、需用带debug信息的LINK目录里面的so库，机顶盒上的so库是无法定位的：
out/target/proct/xx/obj/SHARED_LIBRARIES/libsurfaceflinger_intermediates/LINKED/libsurfaceflinger.so
或者：out/target/proct/xx/symbols/system/lib/libsurfaceflinger.so
2、定位的文件，必现和机器上出现问题的版本一致，否则定位不准确
debuggerd：打印当前进程实时堆栈：debuggerd –b pid

主要可以分为以下3类
1)Data abort
Unable to handle kernel NULL pointer dereference at virtual address...
Unable to handle kernel paging request at virtual address...
Unhandled fault...at...
Unhandled prefetch abort...at...
2)BUG/BUG_ON
Oops - BUG...
例如：
Out of memory and no killable processes...
rbus timeout...
...
PS:WARN_ON只mp stacks，kernel还是正常
3)bad mode
Oops - bad mode...
日志打印:
〃错误类型原因
[214.962667] 08:14:19.315 (2)-0488 Unable to handle kernel paging request at virtual address 6b6b6cl7
[214.973889] 08:14:19.326 (2)-0488 addr：6b6b6c17 pgd = d0824000
[214.980132] [6b6b6c17J •pgd=O000eO0e
〃Oopsttl误码序号
[214.983865] 08:14:19.336 (2)-0488 Internal error： Oops： 805 [#1] PREEMPT SMP ARM
[214.9914S3] Moles linked in: 8192eu ufsd(PO) jnl(O) fusion(O)
〃发生也错误的CPU序号
(215.001878] 08:14:19.354 (2)-0488 CPU： 2 PID: 488 Comm: system_server Tainted: P 4.4.3+ #113
(2)-0488 Hardware name: rtd284x
[215.011865] 08:14:19.364
〃当前PC指针 98:14:19.377 (2)-0488 PC is at mutex_unlo<k+0xc/0x38
(21S.024846] 08:14:19.383 (2)-0488 LR is at storage_pm_event+0xb4/0xe8
(21S.031026]
//Registers 08:14:19.390 (2)-0488 ：[<ceb78ffc>] Ir : [<C0542034>] psr: 200f0013
I 215.037644] sp : ccf79e38 ip : eceoeeee fp : 9b34648c
I 215.037644]
08:14:19.404 (2)-0488 rlO： 00000080 r9 ：Cl8b3864 r8 : oeeeeeoe
215.051370]
215.058692] 08:14:19.411 (2)-0488 P7 ： C1293a98 P6 ：C1293940 r5 : C1293940 r4 ：C1293a80
21S.067345]
[ 215.076014] 08:14:19.420 (2)-0488 r3 : 00000033 r2 ：00000000 ri : 000^000 re ：6b6b6c07
[ 215.085307]
08:14:19.428 (2)-0488 Flags: nzCv IRQs on FIQs on Mode SVC 32 ISA ARM Segment user
08:14:19.438 (2)-0488 Control: 10c5383d Table： 1082406a DAC： 00000055
//Process.不 ,定是该process的错误，只是发生错误时,刚好在运行该process
[215.093168]
//Stacks 08:14:19.446 (2)-0488 Process syste«i_server (pid: 488, stack limit = 0xccf78218)

(21S.101827] 08:14:19.454 (2)-0488 Stack: 0xccf79e38 (Oxccf79d7。 to 0xccf7a08Q) - par(0xcf796d4)

---[ end trace 45d55384id6a0974 ]--- Kernel panic not syncing: Fatal exception
[217.359794] 08:14:21.712 (0)-0488
解决方案: kernel异常一般找芯片原厂协助分析。

系统卡顿时，一般先分三步走：
1、查看当前系统的CPU，IO等参数，输入top、iotop命令： （如：iotop -s io -m 9）
如果有异常飙高的进程，kill掉后会发现系统恢复正常。
之前项目上遇到过某些U盘IO性能比较差，媒体中心又在后台扫描媒体问题，导致系统各种卡顿，io wait时间比较长。
2、系统进程卡住，触发Watchdog：ps –A |grep system_server,一般而言，system_server正常的进程号是200多，如果发现进程号变成几千，则可能出现重启，结合tombstone和 /data/anr下的trace文件分析重启原因
3、当前应用出现卡顿，造成ANR。输入logcat | grep ANR，如果有ANR打印，再去/data/anr下面查看相应进程的traces文件
有时在应用里面操作卡顿，按键响应延迟，但是却没有生成ANR，此时如果退出该应用（如果无法退出，在抓取足够信息的情况下，可以串口直接kill掉卡顿的应用），则一切正常，可能是应用自身实现问题，或者调用了其它接口导致（例如曾遇到应用调用了中间件、mediaplayer某些接口导致操作严重卡顿，按键响应延迟），这种情况则需应用和相应接口的实现者去排查。

系统完全卡死，一般分三种情况
1，串口无响应，大概率kernel panic，
2，串口日志狂输出，把系统堵塞， 优化日志输出，关注关闭后压测。
3，Input系统完全堵塞，导致任何输入都无响应。