标签: vm

Android手机很卡似乎是个千古谜案 　　有没有感觉你用的Android手机很卡？貌似手机配置都已经挺不错的了，四核、八核、≥2GB RAM这样的配置居然还会发生动画掉帧、点击某个按钮或图标出现停顿一会儿之类的情况？高通、MTK、英伟达之类的芯片制造商不是整天宣称什么制程、架构 如何先进，什么一秒钟多少万多少亿次浮点运算，怎么还整天被iPhone用户嘲笑很卡很不爽？ 关于Android系统存在卡顿和不流畅的问题，似乎是个千古谜案——即便到现在也还有很多Android用户坚持说他们新买的旗舰已如丝般柔滑， 却真正在流畅的细微处比iOS差了一截。不过从古到今，试图解释Android卡顿的观点就有千百种，据说即便是采访Android内部开发工程师，他们 也说这是个说不清道不明的问题。这次我们就从相关Android卡顿的几个主流说法谈起，尝试从相对浅显的角度来理解这一问题。 都是Dalvik VM虚拟机惹的祸？ 　　按照普通人对虚拟机的理解，就是平常一直在用Windows操作系统，想装个Mac OS玩玩又没钱买苹果电脑咋办？——装个虚拟机。从这个角度来理解，不管是出于玩机还是开发、或考虑兼容性的问题，用过虚拟机的同学就知道，这东西的效率 和原生安装方式不在一个层面，不管是从驱动、资源利用等各角度来看都是如此。 Android的系统框架上，在最底层的Linux内核之上就跑了个虚拟机，在Android 4.4之前，这个虚拟机叫Dalvik VM。绝大部分Android应用就运转在Dalvik VM虚拟机之上——很多人，甚至是程序员认为，Android系统之所以不流畅和卡顿，罪魁祸首就是此虚拟机，想想我们平常应用层面虚拟机的运行效率就知 道了，再牛逼的硬件也抵不住软件这么坑啊。 　　早年的Android系统能有如此奇葩的框架和执行思路并不是因为Andy Rubin真的很二。Android选择这条路的原因是看中互联网上浩瀚的Java资源——Java应用可以运行在Android这种Linux内核的系 统上正是拜虚拟机所赐，对于一个当时的新生系统而言，想要尽早构建起应用生态，这是个捷径——也是Android现在拥有这么多应用资源的关键所在(虽然 苹果就没这么做)。 　　不过另有一个帮派的程序员表示，这个层面的虚拟机和我们平常自己在电脑上装的虚拟机根本不是一回事，它的执行效率并没有人们想象的不堪，实际使用中和直接调用底层基础函数也没差多少。 (NDK的也可是让Android应用不用跑在虚拟机上) 【 分页导航 】 • 第1页： Android手机很卡似乎是个千古谜案 • 第2页： 从谷歌的行动看,情况好像没这么简单 • 第3页： 第三方应用质量很悲剧 • 第4页： 内存还不够用？装越多APP手机越卡 • 第5页： Android如此卡的根源是它的碎片化? 从谷歌的行动看,情况好像没这么简单 我们从谷歌后来的行动看到，情况好像没有这么简单。早在Android 2.3时期，谷歌就意识到Dalvik并非长久之计，就为Android引入了NDK——这是个真正的开发包，使用C/C++语言也可以为Android 开发应用，以这种方式开发的应用不会跑在虚拟机上。彼时的程序员认为，这是Android从应用层真正开始具备与iOS相抗衡实力的开始，但这种梦想很快 就被打破，一方面是让开发者放弃Java全面转向C/C++并不现实，而且后两者开发难度甚高，涉及内存操作甚至与设备驱动程序对话，对于Android 这种机器种类繁多的系统而言，开发者采用NDK很不现实(类似《极品飞车》这种大型3D游戏运行代码理应采用C++，所以这类游戏针对Android手机 的不同处理器甚至还有不同的版本)。 　　所以在Android 4.4时期，谷歌为之引入了一种新的ART虚拟机，用以替代Dalvik。ART的特点是相比Dalvik更为高效：Dalvik虚拟机在每次运行应用时 会将之编译为二进制机器代码，ART的改进之一就在于在应用安装的时候就将二进制代码编译完成(所以每个应用安装所占空间会更大)，这叫预编译模式，而不 是等到每次运行应用才编译。 理论上听来，ART似乎的确较Dalvik效率更高些，谷歌自己说ART对比Dalvik速度平均提升幅度达到80%，不过各位已经在用 Android 4.4甚至5.0的小伙伴有这种体会吗？或许今后随着Android生态以及系统自身的完善，ART可以表现出更大的优势，起码现在我们没怎么看出来它对 系统流畅性体验改善有多大贡献。 　　另外，在系统框架层面，除了探讨虚拟机可能是拖垮Android流畅性的元凶之一这种说法，还有人也会谈到Linux这类宏内核在驱动方面的先天不足，这些或许都是阻碍Android有丝般流畅的要素，但是否还有其他原因呢？ 硬件加速弱爆了 　　显示系统图形界面的时候，如果画图的工作都交给CPU完成，这效率是可想而知的，犹如你让一位精通数学的同学画图，多少他倒是能画，只是能不能画好 很成问题。如果GPU，也就是专门的画图工作者能够协助这个过程，情况自是大不相同。虽说系统流畅性是个相当大的话题，但硬件加速是否做得好就成为其中的 重要因素。 完善如上所述的这个过程，几乎是贯穿Android 2.x早期，到最新的Android 5.1，甚至此后很长一段时间内，谷歌需要努力的方向。针对系统图片、网页等2D图形绘制，Android所用的是谷歌早在2005年就收购的 Skia(那时Android都还没出生，Chrome也采用Skia作为2D图形引擎)。 　　Skia原始版本的图形光栅处理完全基于CPU和软件运算，也就是说早期Android的2D图形绘制对GPU的利用率存在严重不足，相较iOS和Windows Phone这种在硬件加速领域有着很久积累的系统完全不是一个水平。 【 分页导航 】 • 第1页： Android手机很卡似乎是个千古谜案 • 第2页： 从谷歌的行动看,情况好像没这么简单 • 第3页： 第三方应用质量很悲剧 • 第4页： 内存还不够用？装越多APP手机越卡 • 第5页： Android如此卡的根源是它的碎片化? 在Android的系统设置-调试选项中，有个“强制进行GPU渲染”选项，开启这个选项以后会发现某些应用的运行的确更流畅了，但有些则出现了更 糟糕的使用体验。在Android 2.3时代，国外科技博客DorothyBrowse特别强制开启这种Skia GPU加速，尝试进行Webkit渲染(Chrome的渲染引擎)测试，结果发现相较CPU自己画图，所谓的GPU加速居然出现了反效果，可知当时的 Skia GPU加速在Android平台有多么不成熟。 　　在Android 3.0之前，这套系统都没有真正行之有效的图形加速方案(即便从初版开始，Android就在努力融合硬件加速)，Android 3.0才实现窗口相对完整的硬件加速绘制。实际上，即便是到Android 4.1，谷歌大肆宣传的黄油计划，过渡动画帧率达到60fps，通过预判和缓冲来提升效率，其GPU加速支持也并不完整。谷歌自己的官方文档中就提到，并 不是所有2D图像操作的API都已经支持硬件加速。 　不过总的说来，Android的GPU加速是朝着逐步完善的方向发展的，最新版相较过去已经有了很大程度的提升，从系统级应用和各类操作这些年来流 畅度的明确提升就能感觉得到，即便这种提升在iOS和Windows Phone面前还是显得有些无力。可是来到第三方应用，这个问题又变得非常复杂。 第三方应用质量很悲剧 　　在宣称如“丝般顺滑”、甚至“赶超iOS”的Android 4.1问世以后，不说和iOS比实际如何，其系统级应用倒真的流畅了很多，可是第三方应用死性未改，该怎么卡还是怎么卡。这就是个相当复杂的问题了。 　　其一，在Android一步步向前的步伐中，API Level越高，GPU硬件加速也的确愈加完善，比如Android 5.1所用API Level 22。所谓的API Level，标识的是Android平台框架的API版本。这个API可以理解为Android所跑虚拟机针对应用开发而支持的功能，随着版本号的变化， 这些“功能”在发生着升级或转变。对Android的系统应用而言，采用最新的API是理所当然的，流畅性也保持在最佳状态。 但对第三方应用来说，采用最新的API，就意味着对旧版本系统的抛弃。比如微信应用更新，如果很任性地用上API Level 22，那么最新版的微信将只支持Android 5.1，人类可以忍受吗？所以微信迄今为止还在采用API Level 9，微博则为API Level 14。这种API的迭代，也是苹果为何高度追求系统一致性的重要原因。想想Android系统的碎片化问题，第三方应用要变得更高效，好像是个根本无法完 成的任务。 　　这还只是第三方应用开发的一环。其二，Android应用开发者的“随性”让Android应用的效率更加悲惨。比如说谷歌在应用开发的指导原则中提到，如果应用不够流畅，应该看看是否存在“过度渲染(OverDraw)”的问题，就是布局重叠、重复绘制。 要检查这个问题，有兴趣的同学可以一起来做这个实验。在Android系统设置的开发者选项中，选择“显示GPU过度绘制”，此时整个界面变得花花 绿绿一片。这些色块所表达的是，无色透明状态为最佳，蓝色表示很好，绿色为不错，浅红色表示较差，深红色为过度绘制问题严重。类似Instagram等应 用的情况似乎挺好，而某博和Facebook过度渲染的问题就很严重。这只是Android应用开发中的一个例子，如此这般罔顾开发原则的状况那是数也数 不清的。在Android相对开放的应用世界中，这种情况是不会有警察去抓的，显然iOS全程把关App Store就不会这么悲剧。 　　其三，在天朝这样一个奇特的国度，开放的系统无疑为许多应用开发商提供了大好机会。很多应用当安装到你手机中，其行为习惯可能是你完全不知道了，而且可能实情会更令你震惊，这就是下面一个话题了。 【 分页导航 】 • 第1页： Android手机很卡似乎是个千古谜案 • 第2页： 从谷歌的行动看,情况好像没这么简单 • 第3页： 第三方应用质量很悲剧 • 第4页： 内存还不够用？装越多APP手机越卡 • 第5页： Android如此卡的根源是它的碎片化? 内存居然还不够用？装越多APP手机越卡 　　相关Android装越多应用，手机越卡的解释非常多样，甚至包括对于固态存储原理的解释。或许这些都是原因所在，不过更关键的原因是这样 的：Android系统中有个叫做Receiver(接收器？)的东西，负责传递系统接收到的变化，就像是神经系统。比如说按下Power键锁屏，长按关 机，或者长按相机按键启动相机应用，或者插入耳机，都是在Receiver接收到以后通知相应apk，后由程序给出响应。 应用本身就可以跟系统注册任何形式的Receiver，其较大的用处之一是通知系统启动某个程序。比如YouTube的Receiver在开机时、 系统语言切换后、系统账户改变后这三种情况下自动启动YouTube应用本身——这是个比较常见的Receiver。而国内的诸多“异士”是如何写 Receiver的呢？ 　　某些著名视频站APP在下面这些情况下都会启动，包含开机时、网络状况改变时(2G、3G与WiFi间切换)、安装其它App时、卸载其它APP 时、用户唤醒机器时.。。对于用户而言，无论你怎么杀进程清内存，只要这些操作被触发，Receiver就会启动相应程序，话说连个WiFi、下个新应用 都要启动该应用，哪有透明度可言，真是独有社会主义特色。 此类国产APP相当多见，常见Receiver动作还有：耳机拔出或插入时、文件下载完成后、WiFi扫描SSID完成后，都启动程序，是不是感觉 灰常神奇？它们的宗旨就是永远不会被你杀死，什么一键杀进程，分分钟给你活过来，除非彻底卸载它们，或禁用相应Reciever。在这种情况 下，Android系统对于内存容量的要求自然是非一般的。 　　所谓的内存回收机制此刻都已不值一提，何以iPhone 1GB内存流畅运行至今，而Android现如今已是3GB时代；这也是很多Android优化文章告诉用户，如果某应用一周不用就卸载的核心所在，环境使然。你听说过iOS优化让用户卸应用的吗？ 碎片化问题让Android千疮百孔 【 分页导航 】 • 第1页： Android手机很卡似乎是个千古谜案 • 第2页： 从谷歌的行动看,情况好像没这么简单 • 第3页： 第三方应用质量很悲剧 • 第4页： 内存还不够用？装越多APP手机越卡 • 第5页： Android如此卡的根源是它的碎片化? Android如此卡的根源或许是它的碎片化 可以说，除了Android本身的顽疾之外，导致上述绝大部分问题的根源就是Android的碎片化，无论是Android自身开放的态度让各种高 配、低配的手机都在使用，还是手机制造商对Android进行的二次开发。要将硬件加速做好、规范第三方应用质量，在Android开放的理念下是几近不 可能完成的任务，且谷歌自己都难以收拾局面。 Android的开放和碎片化带来的问题还远不止上面这些，一个典型的例子是iOS和Windows Phone都具备了特别出色的信息推送机制，比如说QQ、微信接收消息，在iOS和Windows Phone中，应用本身不需要常驻后台，通过每台手机和推送服务器保持唯一连接，就能收到推送通知，无论对性能和功耗的节省都具备了极大的意义。 　　Android系统当然也具备了消息推送的可行性，但由于碎片化问题，以及国内因为某种原因不得不去掉谷歌服务的现状，令Android不同应用采 用五花八门的推送机制。许多Android应用获取消息的方式是轮询(而非推送)，即应用主动地与服务器连接并查询是否有新消息，可想而知它对系统和网络 资源的消耗。 关乎Android系统本身，则除了文首提到的虚拟机机制，还有许多相当微妙的问题形成它与iOS之间的流畅性差异，比如Android对多任务的 支持更类似于桌面系统，本身就只有靠堆砌硬件才能满足这种多任务的需求，当然iOS的多任务也已经不像很多人理解的那样，是多年前的“假后台”了，它针对 第三方应用开放的多任务API正越来越多。 　　总之，Android的卡顿和不流畅是个极其复杂、庞大的问题，上面所提的这些也只是挖掘了其中的一部分。就Android系统的发展轨迹来看，从 初代问世至今，其发展史都可以看做是谷歌在系统流畅性问题上所做的一次次努力，流畅性改善甚至是Android前行的一条线索，所以谷歌也才毫不吝啬地一 次次地宣传，我们的系统更流畅了，不管相较竞争对手有多大差距和多少不可控性，现在的Android也已经比过去流畅了很多，虽然未来还有很长的路要走。 【 分页导航 】 • 第1页： Android手机很卡似乎是个千古谜案 • 第2页： 从谷歌的行动看,情况好像没这么简单 • 第3页： 第三方应用质量很悲剧 • 第4页： 内存还不够用？装越多APP手机越卡 • 第5页： Android如此卡的根源是它的碎片化?

At the recent ESC DESIGN West, in the context of conversations about microcontroller usage and architecture evolution, several embedded system developers I met were thrilled about a new open source Java virtual machine (VM) implementation called KESO (which is OSEK backwards, the OS environment within which it was originally designed to function ). This enthusiasm for a JVM surprised me because the conventional wisdom among embedded developers is that Java and its VMs have no place in small footprint, highly deterministic, and real time apps in automotive, industrial, and machine control designs. While Java was developed to make code development cleaner and more bug free, this comes at the cost of unpredictable timing due to the garbage collection algorithms it uses to deal with extraneous code and to the memory space its VMs require. Java virtual machines, even the just-in-time and ahead-of-time compiled versions, are still too big and too slow for use on most microcontrollers. Not so with the KESO virtual machine. In general, it avoids many of the problems with traditional JVMs through the use of a design that is carefully architected ( by researchers at the Embedded Systems Institute in the the School of Engineering, Friedrich-Alexander University, Erlangen-Nuremberg, Germany ) with the limited resources and response times of microcontroller applications in mind—not just for 32bit MCUs, but on 8- and 16bit microcontrollers such as the Atmel AVRs and Microchip's 8bit PICs as well. Unlike traditional JVMs, KESO is designed to operate in tandem with an RTOS, leaving to the RTOS many functions traditional JVMs might take on. For example, it does not implement thread scheduling and thread synchronisation, but uses an existing RTOS to do these tasks. As with most Java implementations, it makes selective use of garbage collection, but when it does, it uses a bare-bone, primitive form that assumes operation in a priority-based scheduling environment, another function it lets devolve to the RTOS. Also, rather than depend on the traditional Java VM compiler to generate executable Java code, KESO is provided with a companion compiler called " jino " that generates native C code in an ahead-of-time fashion, making possible a very slim run time environment and fast execution times. Rather than just any C code, KESO generates ISO-C90 code, which has a number of advantages. First, because it makes use of a standard C compiler available for most embedded microcontrollers, there is no need for a compiler backend for each target microcontroller. Second, the C source code is easier to read than native code, making it easier to debug. Third, it allows the use of existing C language tools for static analysis and testing. Fourth, the jino compiler is designed to work in cooperation with standard C compilers, concentrating on high-level optimisations. Low-level optimisations are left to the traditional C compilers. Because KESO is initially targeted for automotive applications, it is designed as a multi-JVM, in which the basic structural building block is the "protection domain." This allows different applications to coexist on a microcontroller in their own memory space, with communications between them limited to a set of well-defined and safe communications channels, again mediated by an RTOS. As I mentioned earlier, KESO incorporates a minimalist and flexible form of garbage collection and assumes operation in a purely static memory environment, typical of many auto applications which use an AUTOSAR operating system. It's multi-JVM structure requires logical separation of executable code into different memory domain heap areas rather than allocating from a common heap. Not only does such static partitioning allow the VM to give the various allocated heap spaces guarantees on performance and response time but also provides protection on a per domain basis. To operate effectively in such a multi-JVM environment, KESO uses a relatively simple heap strategy which often does not require the use of garbage collection at all. The advantage of this is that memory objects can be deployed with short, constant, and easily predictable time constraints. In addition, if a developer feels the need to use garbage collection, KESO makes use of two precise tracing non-moving mark-and-sweep garbage collection techniques: through-put optimised GC and an incremental GC that is at least latency aware. Various implementations of KESO on MCUs run the gamut from high end 32bit MCUs such as the ARM Cortex-M and Infineon's Tricore to Atmel's 8bit AVR MCUs and equivalent Microchip PICs. In the 8bit domain, a typical memory configuration is about 8 kilobytes of flash and about 500 to 600B or so of internal SRAM. The current compiler backend for KESO requires an OSEK/VDK or an AUTOSAR-compatible OS, the most common platforms used in automotive designs. In that environment, KESO takes advantage of the fact that OSEK/VDX is at its core little more than a scheduler based on static priorities. As a result, it supports determinism and takes advantage of code generators sent out with the OS that allow a developer to generate a KESO/RTOS variant tailored to the specific hardware platform and application at hand. Despite its initial OSEK/AUTOSAR implementations, though, KESO makes few assumptions about the underlying scheduling model, other than requiring priority-based scheduling. This implies that it can be used in combination with any RTOS if the developer is willing to do the work to adapt it. If not, there is a whole range of OSEK/VDX compatible configurations, including emulations for most commodity and open source RTOSes. Similar to several other Java platforms optimised for embedded systems, KESO doesn't offer support for the full spectrum of features provided by the Java 2 Standard platform (J2SE), for obvious performance and memory space considerations. Despite that, it seems to incorporate a range of features that MCU developers should find useful. Its native interface (KNI) is lightweight and flexible enough to interact with any number of native APIs. Safe abstractions have been built atop the KNI for accessing OS services such as memory-mapped hardware registers. As a multi-domain JVM, it incorporates a high level remote procedure call (RPC) mechanism that allows communications between protection domains and allows tasks to perform in those different protection contexts without losing their original priority scheduling. What I am describing here is tantalizing more for the details that are left out than for what I have been able to describe based on what developers have told me. That is one of the most exciting – and most frustrating – things about directly talking to developers at conferences such as ESC. I am currently scouring the web and querying my developer contacts for further details and hope to have more to report later. How KESO can be used in embedded applications is a topic worth further exploration, and I would like to hear from you about your experiences with it. Just as valuable is the input from developers who have looked at KESO and did not find it attractive. A final note: The fact that KESO was developed for use on microcontrollers and seems able to meet fairly strict deterministic response time constraints even on 8bit MCUs convinces me that despite the constant refrains from high-end MCU vendors that 32 bit MCUs will soon displace 8bitters, this under-appreciated segment of the embedded systems market is still one of the most creatively active areas of development.  

自 2006 年以来，Lauterbach 支持 Java 程序的调试，适用于 Java 虚拟机 J2ME CLDC、J2ME CDC 和 Kaffe。由于虚拟机越来越受到欢迎，因此虚拟机供应商的数目正在快速增涨。目前，并非所有虚拟机都是开源的，为了让虚拟机供应商及其用户能够根据其虚拟机特性，灵活的调整调试功能，Lauterbach 从 2010 年中开始致力于开发一种新的解决方案。以 Android Dalvik 虚拟机在 ARM 核的实现，做为停止模式下开发虚拟机应用程序接口的范例. 两个“调试世界” 对于系统开发者，Android 是一个开源软件栈，包括以下组件（见图 3）： • Linux 内核及其硬件驱动程序。 • Android Runtime 与 Dalvik 虚拟机以及一系列程序库：经典 Java 内核库，Android 特殊库、C/C++ 程序库。 • Java 应用程序及其支持的应用构架。 Android 软件可采用各种语言编写： • Linux 内核、一些程序库与 Dalvik 虚拟机代码可采用C、C++ 或 Assembler 编写。 • 虚拟机应用程序及其支持的应用构架可采用 Java 语言编写。  每个代码块都在单独的“调试世界”内测试。   调试 C/C++ 程序和汇编程序代码 通过使用 JTAG 接口，采用 C/C++ 和汇编器编写的Android 程序可以在目标硬件上以停止模式调试。在停止模式调试时，TRACE32 调试器可直接与 Android 硬 件平台的处理器通讯（见图 4）。停止调试模式的特点是：当处理器被停止以进行调试时，整个 Android 系统亦停止运行。 停止模式调试具有以下主要优势： • 只需一个有效的 JTAG 接口即可实现调试器与处理器之间的通讯。 • 无需在目标上加载调试服务程序，因此非常适合于测试已发布软件。 • 它允许实时测试，因此能够有效调试仅在实时情况下才出现的问题。 目前，停止模式调试暂不支持在 Dalvik VM 等虚拟机上调试 VM 应用程序，因此要实现所有软件层上均能够透明调试仍然需要一段时间。   劳特巴赫工程师精心为您准备在线视频讲座，欢迎观看！ http://v.youku.com/v_show/id_XMzExNzcwMTI4.html   您可以登录“劳特巴赫(Lauterbach)中国公司”官方微博 http://weibo.com/lauterbach 官方博客 http://blog.sina.com.cn/lauterbachchina 官方网站 http://www.lauterbach.com/frames.html?country=cn%3fhome_c.html 留言与专家进行互动，为您做免费咨询解答。  

自 2006 年以来，Lauterbach 支持 Java 程序的调试，适用于 Java 虚拟机 J2ME CLDC、J2ME CDC 和 Kaffe。由于虚拟机越来越受到欢迎，因此虚拟机供应商的数目正在快速增涨。目前，并非所有虚拟机都是开源的，为了让虚拟机供应商及其用户能够根据其虚拟机特性，灵活的调整调试功能，Lauterbach 从 2010 年中开始致力于开发一种新的解决方案。以 Android Dalvik 虚拟机在 ARM 核的实现，做为停止模式下开发虚拟机应用程序接口的范例. 两个“调试世界” 对于系统开发者，Android 是一个开源软件栈，包括以下组件（见图 3）： • Linux 内核及其硬件驱动程序。 • Android Runtime 与 Dalvik 虚拟机以及一系列程序库：经典 Java 内核库，Android 特殊库、C/C++ 程序库。 • Java 应用程序及其支持的应用构架。 Android 软件可采用各种语言编写： • Linux 内核、一些程序库与 Dalvik 虚拟机代码可采用C、C++ 或 Assembler 编写。 • 虚拟机应用程序及其支持的应用构架可采用 Java 语言编写。  每个代码块都在单独的“调试世界”内测试。   调试 C/C++ 程序和汇编程序代码 通过使用 JTAG 接口，采用 C/C++ 和汇编器编写的Android 程序可以在目标硬件上以停止模式调试。在停止模式调试时，TRACE32 调试器可直接与 Android 硬 件平台的处理器通讯（见图 4）。停止调试模式的特点是：当处理器被停止以进行调试时，整个 Android 系统亦停止运行。 停止模式调试具有以下主要优势： • 只需一个有效的 JTAG 接口即可实现调试器与处理器之间的通讯。 • 无需在目标上加载调试服务程序，因此非常适合于测试已发布软件。 • 它允许实时测试，因此能够有效调试仅在实时情况下才出现的问题。 目前，停止模式调试暂不支持在 Dalvik VM 等虚拟机上调试 VM 应用程序，因此要实现所有软件层上均能够透明调试仍然需要一段时间。   劳特巴赫工程师精心为您准备在线视频讲座，欢迎观看！ http://v.youku.com/v_show/id_XMzExNzcwMTI4.html   您可以登录“劳特巴赫(Lauterbach)中国公司”官方微博 http://weibo.com/lauterbach 官方博客 http://blog.sina.com.cn/lauterbachchina 官方网站 http://www.lauterbach.com/frames.html?country=cn%3fhome_c.html 留言与专家进行互动，为您做免费咨询解答。