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系統完全堵塞，導致任何輸入都無響應。