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模式虽然有很好的优势，但是官方现在并不保持其稳定性。所以请慎重选择切换，可能造成手机死机无法开机之类的问题。
觉得我的经验对你有帮助点赞一个吧谢谢。