androidlibart

『壹』 xposed框架會不會讓手機變卡

xposed 會不會影響性能這個問題的答案是顯而易見的：會。而且這個問題還需要分兩種情況討論。android 5.0+ 和 Android 4.4-。我們先從 Android 4.4 及其以下版本的 xposed 框架說起。xposed 歸根究底就是一個提供對 Android 運行虛擬機 hook 的一個工具。可以使得用戶無需修改軟體本身而做到對軟體進行修改（通過在運行時進行修改）。其本身提供了一套抽象的 API 來幫助開發者開發 xposed 上面的插件。在運行時，通過在類載入過程中對類進行重寫的方法實現修改。就這一點上來說，無疑是存在性能上的損耗的。但也如這個問題下其他答主所說，由於 xposed 的一些插件的本身的目的就是優化其他更占資源的應用再加上 xposed 插件開發者本身開發經驗較為豐富，也比較良心，所以對性能的影響是有限的，相反，其優化性能的功能帶來的效果通常是顯著的。我比較想單獨談論一下 Android 5.0+ 的 xposed 框架，這是目前其他答主還沒有提到的地方。顯然的 Android 5.0+ 帶來的問題有很多，比如更加嚴格的 SELinux 的限制以及對 64 位的支持等等對於 xposed 框架的實現難度提了更高的要求。當然最麻煩的東西還是 ART 虛擬機。所以在 Android 5.0+ 上的 xposed 框架有著很大的實現上的區別。首先，xposed 框架會將系統的 ART 虛擬機的庫文件（libart.so 以及相關的文件）完全替換掉。但這一點，便沒有 Dalvik 上實現得那麼「干凈」，並且這個替換掉的庫會禁用掉了一些 ART 的代碼優化的特性。這也會使得整個 hook 過程變得更可靠，更穩定。

『貳』 libdvm.so和libart.so哪個好

libdvm.so是android4.4一下davlik虛擬機的庫，libart.so是4.4以上art虛擬機的，從4.4以上開始虛擬機變為art，並沒有哪個好，只是一個本地庫，如果非要說哪個好，那肯定第二個了

『叄』 如何生成android out/target/proct//obj/lintermediates/export

make:進入目錄'/home/jinsheng/android4.4_src'
make: *** 沒 有規則可以創建「out/target/proct/generic/obj/EXECUTABLES /dex2oatd_intermediates/import_includes」需要的目標「out/target/proct/generic /obj/SHARED_LIBRARIES/libartd-compiler_intermediates/export_includes」。 停 止。
make:離開目錄「/home/jinsheng/android4.4_src」

可能是工程沒有make過，單獨編譯某個模塊導致的。先把工程整個make一下。

[root@localhost android4.4_source_code]# m -j5 //Makes from the top of the tree.

『肆』 Android編譯時候無法啟動jack伺服器

要知道為什麼Android界面無法正常啟動，可以在串口命令行上先執行"stop"命令，再執行"start"命令，然後
1. 如果可以通過USB連接ADB的話，用adb logcat把Android的啟動信息列印出來；
2. 如果ADB無法連接，在串口命令行上用logcat命令

『伍』 如何打開/切換安卓4.4的ART模式

1、打開手機的設置，進入「開發者選項」，找不到「開發者選項」的進入「關於手機」連續點擊版本號幾次就行了；

2、進入「開發者選項」後下拉，找到「選擇運行環境」，可以看到目前使用的是Dalvik模式，點擊彈出兩個選項，我們點擊「使用ART」，這時彈出警告提示重啟，本人此系統未完全漢化警告顯示為英文，若漢化過的會顯示「要重新啟動以將運行模式從libdvm.so改為libart.so嗎」或者相似的提示，我們點擊確定，手機將關機重啟；

3、重啟過程系統會對所有應用程序進行優化，時間由已裝應用數量決定，待優化完畢開機，手機就正式進入ART模式運行了。

『陸』 Xposed Framework對於Android 5.0的支持是什麼原理

初步看了下，只支持ARMv7所以Nexus6可以用Nexus9就不要想了。。。。。。
作者說他干擾了ART的編譯過程，禁用了一些優化以達到目的，所以可能會降低性能，不過並不是太明顯。
簡單的說他patch了ART的源碼，自己基於AOSP的源碼修改並重新編譯了一個支持hook的libart.so然後通過XposedBridge.jar對外提供和以前一樣的API。
這樣看來使用新Xposed並不是像Dalvik時代那麼無痛，性能可能減少，有些ART安全特性為了hook方便也關掉了。
作者說這只是alpha版，他自己在Nexus5上用沒啥問題但是沒有仔細測試過。
4.4的支持可行，但是他要先搞好5.X的支持。

『柒』 請教大牛怎麼分析ANR文件

對於Android ANR而言，ANR發生時mp的trace.log 非常關鍵，ANR應用的各個線程trace代表ANR發生那一瞬間各個線程的運行狀態，類似一個快照；如果你的應用因為主線程阻塞而發生ANR，通過主線程trace就可以很容易定位到阻塞點；

如果要有效通過trace分析ANR，首先第一點需要通過main.log確認是主線程阻塞或發生死循環導致的ANR，才能確認主線程的trace有參考價值，因為trace僅是某一瞬間的動作，如果主線程5秒阻塞，那這5秒內主線程的狀態都是一樣的，所以可以通過trace確認阻塞點；

以一下堆棧為例：
"main"位置欄位代表線程名，Android各個應用主線程都叫做"main"，關鍵以sysTid=9816反映的這個數字區分是哪一個應用的主線程；
sysTid=表示系統中的線程號；
tid=表示本進程中線程排號；
Native位置欄位表示線程狀態，線程的狀態通常有Blocked，Waiting，Native，Runnable,SuSpend等等。通常Blocked,Waiting兩個狀態表示明顯阻塞，而Native，SuSpend可能是阻塞，需要具體問題具體分析，Runnable表示線程正常運行，沒有阻塞；

以下堆棧，反映ThreadedRenderer.nFence沒有響應ThreadedRenderer.fence調用，然後ThreadedRenderer.fence又沒有響應ViewRootImpl.performDraw，所以真正阻塞點應該是ThreadedRenderer.nFence這個位置的執行的方法；ANR問題涵蓋的內容非常多，需要多積累經驗，才能比較舒暢的分析這類問題；
"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 obj=0x74637280 self=0xa9985400
| sysTid=9816 nice=0 cgrp=default sched=0/0 handle=0xac61b534
| state=S schedstat=( 0 0 0 ) utm=150 stm=135 core=2 HZ=100
| stack=0xbe7fd000-0xbe7ff000 stackSize=8MB
| held mutexes=
native: #00 pc 000173e4 /system/lib/libc.so (syscall+28)
native: #01 pc 000b6a3d /system/lib/libart.so (__6ThreadE+92)
native: #02 pc 003f101b /system/lib/libart.so (_ZN3artL12GoToRunnableEPNS_6ThreadE+230)
native: #03 pc 003f0f0b /system/lib/libart.so (_ZN3art12JniMethodEndEjPNS_6ThreadE+8)
native: #04 pc 00e7a58f /data/dalvik-cache/arm/system@[email protected] (java_android_view_ThreadedRenderer_nFence__J+90)
at android.view.ThreadedRenderer.nFence(Native method)
at android.view.ThreadedRenderer.fence(ThreadedRenderer.java:859)
at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2651)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2228)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1248)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6330)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:871)
at android.view.Choreographer.doCallbacks(Choreographer.java:683)
at android.view.Choreographer.doFrame(Choreographer.java:619)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:857)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6141)
at java.lang.reflect.Method.invoke!(Native method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

『捌』 小米4的ART模式怎麼打開

首先要到手機設置中，找到關於手機--版本，不停點擊根據提示就可以開啟【開發者選項】了.在開發者選項中找到【運行環境】，這裡面就有兩種運行模式一種是默認的Dalvink，另一種就是ART模式。這是只有選擇ART就行。選中ART模式後，手機會給出類似於安全聲明之類的提示，然後就會提示重啟，按提示操作後。重啟的時候就會出現手機在自動升級的通知，這個根據你手機中有的軟體需要的時間3-5分鍾不等。ART模式雖然使得程序運行流暢多了，但是，也佔用了更多的系統內存，同時在安裝程序的時候時間也相對增多了（ART好像就是在這時候進行預編譯的），這樣開機也會慢了一些。相對而言，這還是在可接受的范圍內。

【第一】在了解到ART的詳細後，小編嘗試刷了安卓的4.4.2，並且成功切換到了ART模式，就其優點而言，自我感覺並沒有多麼特別的感覺。但在左右切換界面的時候，流暢感是挺好的。而開啟應用，也是挺速度的。
2
【第二】就其缺點BUG來說，偶爾會出現返回鍵失靈，還有輸入法自動回復到默認輸入法，目前就這兩個問題，這兩點都是很讓人捉急的BUG。
3
【總結】個人推薦手機發燒友大膽切換嘗鮮，這個被眾多人看好的ART模式究竟如何，只有自己體驗過才知道，當然，要有手機報銷後重新救機的決心。而對於其他朋友，不建議隨便切換到ART，因為這東西BUG還是挺麻煩的，希望你切換到ART如果失敗了，體驗差了不用罵小編。

ART模式雖然有很好的優勢，但是官方現在並不保持其穩定性。所以請慎重選擇切換，可能造成手機死機無法開機之類的問題。
覺得我的經驗對你有幫助點贊一個吧謝謝。