android的一些常识

Android的虚拟机Dalvik 介绍
随着上周Google的Android SDK的发布，关于它的API以及在移动电话领域所带来的预期影响这些方面的讨论不胜枚举。不过，其中的一个话题在Java社区是一石激起千层浪，这就是Android平台的基础——Dalvik虚拟机。

　　Dalvik和标准Java虚拟机（JVM）之间的首要差别之一，就是Dalvik基于寄存器，而JVM基于栈。一直以来都有人在猜测，选择基于寄存器的方式是因为它对提前优化（ahead-of-time optimization）提供了更好的支持，而这对类似于移动电话这样的受限环境是颇有裨益的。另一份针对基于寄存器虚拟机和基于栈虚拟机更深入的比较分析指出，基于寄存器的虚拟机对于更大的程序来说，在它们编译的时候，花费的时间更短。

　　Dalvik和Java之间的另外一大区别就是运行环境——Dalvik经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个 Dalvik应用作为一个独立的Linux进程执行。Neil Bartlett指出，给每一个应用赋予独立的进程可以允许动态安装、激活和去激活，但是他对Dalvik为什么要选择这种方式而没有使用OSGi在单一进程中实现表示疑问——Radoslav Gerganov回复说，独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。Carl Rosenberger也指出OSGi也可以被移植到Android平台，而Jilles van Gurp对Google为何选择重新实现若干组件，如跨进程通信，表示疑问。

　　此外，Java也已经不再是人们在Dalvik上开发所选择的唯一语言了——已经有人在Dalvik上运行Scala取得了成功，并且Hecl也已经被成功移植了。另外更有人对运行Groovy做了一次尝试，不过目前为止还不怎么成功。Mono项目的创始人Miguel de Icaza也对在Dalvik源码公开之后将Mono整合到Dalvik上表示了兴趣，而且也已经有人猜测如何用多种方式来实现整合了，包括与随Android SDK提供的Java到Dalvik重编译器类似的CIL（Common Intermediate Language，通用中间语言）到Dalvik重编译器。

　　Dalvik的诞生也导致人们开始忧虑Java平台的第一次大规模的分道扬镳或许已经是进行时了——有人已经把Davlik和微软的JVM以及Sun 对微软的诉讼联系起来，等着看Google身上是否也会发生类似事情；另外一些人则指出，Google并没有宣称Dalvik是一个Java实现，而微软却是这样做的。Sun也对可能带来的阵营分裂表达了忧虑情绪，并提出和Google合作来保证Dalvik和JVM之间的兼容性——Google对此的解释是，Dalvik是对解决目前Java ME平台上分裂的一次尝试，也是为了提供一个拥有较少限制许可证的平台。甚至还有人怀疑这是否是Sun和Google两大阵营对Java之未来的一次大规模较量。Ian Skerret认为，Dalvik的诞生是对Sun尝试控制和保护来自Java ME收入来源的一次反应，以及对建立OpenJDK统辖理事会迟迟未果的回答。这也导致Dalibor Topic怀疑Google是否要重履Sun走过的路：

　　当然，一个很有意思的问题是，为什么没人有勇气拿Google关于OpenJDK的问题反过来问Google呢？

　　虽然Android号称开源，但它仍是专有产品。Android做过兼容性保证，是在秘密会议室中签署和保管的。Android不具备任何治理模型，也没有证据指出将来会出现治理模型。Android没有规范，并且它的许可证禁止任何替代实现的开发，因为这并非Google在SDK许可证中授权许可的使用权。Android完全在Google的掌控之下，一旦有竞争性应用在财政上损害了Google的利益，Google是保有一刀抹杀这些应用的权利的。从设计伊始，Android就收到限制，只能在Google的财务利益允许的条件内开放。专有的Java也不是什么好货色，旧瓶装新酒而已。

　　这就好像我们在见证JCP的重生一样，人们排着队把开源社区的“街头信誉”在一个单一的、专有的实现的基础上借给另外一个封闭的厂商垄断集团。只不过这次的大头改姓Google，而不是Sun了。
Stefano Mazzocchi发布了一篇分析报告，深切入里地探讨了围绕Java ME和Dalvik的许可证问题，他得出结论说，Dalvik的市场定位良好，足以给移动电话市场带来冲击。尽管Google一直都很小心避免引起诉讼的几个关键点，但Mazzocchi相信Sun还是会起草知识产权案的状告书（IBM也有可能）。他还指出，由于在JCP之外操作，Google可以非常快地对Android进行更改，而且可以避开Sun对任何JCP更动的否决权——这样他们也可以为诸如USB和蓝牙这样的组件加入接口，而这些组件在基础Java ME实现中是不可用的。最后，通过在Apache许可证下授权许可Dalvik的源码，移动电话运营商更有可能采用Dalvik，因为运营商可以在不花费许可费用的情况下使用和修改它。




Android内存管理机制之一：lowmemory killer
准备写这个专题之前，心里是有点忐忑的。首先Android内存管理机制相当复杂，想要讲清楚比较困难；其次对于绝大多数用户来说，只关心内存够不够用，至于内存如何管理的这种技术细节，不是用户需要去考虑的，写这样一个专题有没有意义？毕竟我们是用手机，不是来研究手机的。最后的顾虑是这个专题会不会太技术化了，绝大部分用户不会看或者说缺乏相应的背景。但是有一种激励促使着我去写这样一个专题，一直以来，MIUI团队在与用户互动的过程中也同时在向用户学习，你们的一些建议或者点子总会给我们启示，这个专题中我相信你们同样能给以启示。虽然说内存管理是一个很技术的话题，但我们仍可以从用户的角度去看这些问题，内存管理是如何影响我们使用手机，作为用户，我们能做些什么。我会尽力使这样一个专题不那么技术化，但是仍旧免不了会有一些技术术语以及实现相关的讨论，如果有兴趣，我们就一起看看吧。

我们首先从用户发的一个帖子开始：“传说中的神器，让你的ms时刻保持空余内存”，在这个帖子中提到了"alter minfree"选项，在这一篇中我们就讲讲这个是什么，它是如何工作的。

（1）Android是一个多任务系统，也就是说可以同时运行多个程序，这个大家应该很熟悉。一般来说，启动运行一个程序是有一定的时间开销的，因此为了加快运行速度，当你退出一个程序时，Android并不会立即杀掉它，这样下次再运行该程序时，可以很快的启动。随着系统中保留的程序越来越多，内存肯定会出现不足，这个时候Android系统开始挥舞屠刀杀程序。这里就有一个很明显的问题，杀谁？

（2）Android系统中杀程序的这个刽子手被称作"LowMemory Killer"，它是在Linux内核中实现的。这里它实现了一个机制，由程序的重要性来决定杀谁。通俗来说，谁不干活，先杀谁。Android将程序的重要性分成以下几类，按照重要性依次降低的顺序：

名称 oom_adj 解释
FOREGROUD_APP 0 前台程序，可以理解为你正在使用的程序
VISIBLE_APP 1 用户可见的程序
SECONDARY_SERVER 2 后台服务，比如说QQ会在后台运行服务
HOME_APP 4 HOME，就是主界面
HIDDEN_APP 7 被隐藏的程序
CONTENT_PROVIDER 14 内容提供者，
EMPTY_APP
15
空程序，既不提供服务，也不提供内容

其中每个程序都会有一个oom_adj值，这个值越小，程序越重要，被杀的可能性越低。

（3）除了上述程序重要性分类之外，Android系统还维护着另外一张表，这张表是一个对应关系，以N1为例：
oom_adj 内存警戒值( 以4K为单位）
0 1536
1 2048
2 4096
7 5120
14 5632
15 6144
这个表是定义了一个对应关系，每一个警戒值对应了一个重要性值，当系统的可用内存低于某个警戒值时，就杀掉所有大于该警戒值对应的重要性值的程序。比如说，当可用内存小于6144 * 4K = 24MB时，开始杀所有的EMPTY_APP，当可用内存小于5632 * 4K = 22MB时，开始杀所有
的CONTENT_PROVIDER和EMPTY_APP。


(4) alter minfree改的是什么呢，上面这张对应表是由两个文件组成的：
/sys/module/lowmemorykiller/parameters/adj和/sys/module/lowmemorykiller/parameters/minfree。

alter minfreee就是修改/sys/module/lowmemorykiller/parameters/minfree这个文件的，举例来说，如果把最后一项改为32 * 1024，那么当可用内存小于128MB是，就开始杀所有的EMPTY_APP。

这个专题的第一贴就到此结束，我们大致的讲了一下在内核里是如何处理low memory的，当然，实际上内核中的内存管理非常复杂，也不可能在这样的一个帖子中去展开，下一篇我们跳出内核层，去应用层看看。




android 内存使用
众所周知，在写 android 程序的时候，很容易出现 OOM ，而出现的时机大多数是由 Bitmap decode 引发的：
ERROR/AndroidRuntime(16350): java.lang.OutOfMemoryError: bitmap size exceeds VM budget
      我们知道，android程序内存一般限制在16M，当然也有24M的，而android程序内存被分为2部分：native和dalvik，dalvik就是我们平常说的java堆，我们创建的对象是在这里面分配的，而bitmap是直接在native上分配的，对于内存的限制是 native+dalvik 不能超过最大限制。
      用以下命令可以查看程序的内存使用情况：
adb shell dumpsys meminfo $package_name or $pid   //使用程序的包名或者进程id
      用android自带的launcher程序为例：
run: adb shell dumpsys meminfo com.android.launcher
<br>results:
Applications Memory Usage (kB):
Uptime: 113017 Realtime: 113017

** MEMINFO in pid 129 [com.android.launcher] **
                    native   dalvik    other    total
            size:     4572     3527      N/A     8099
       allocated:     4113     2684      N/A     6797
            free:      406      843      N/A     1249
           (Pss):     1775     3572     3953     9300
  (shared dirty):     1448     4020     4792    10260
    (priv dirty):     1652     1308      708     3668
 
Objects
           Views:        0        ViewRoots:        0
     AppContexts:        0       Activities:        0
          Assets:        5    AssetManagers:        5
   Local Binders:       14    Proxy Binders:       21
Death Recipients:        0
OpenSSL Sockets:        0
 
SQL
            heap:       64       memoryUsed:       64
pageCacheOverflo:        4  largestMemAlloc:       50
 
DATABASES
  Pagesize   Dbsize  Lookaside  Dbname
      1024        4         48  launcher.db
       具体每一项代表什么，参考：http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android#2299813，我们比较关心的是这2行：
             native   dalvik    other    total
     size:     4572     3527      N/A     8099
allocated:     4113     2684      N/A     6797
       其中size是需要的内存，而allocated是分配了的内存，对应的2列分别是native和dalvik，当总数也就是total这一列超过单个程序内存的最大限制时，OOM就很有可能会出现了。
       多数时候，发生OOM 都是在做一些跟图片相关的操作，以下提出一些建议尽量可以减少这种情况的发生：
1.decode bitmap 的时候，尽量配置下Options，例如：inSameSize
2.Bitmap使用完以后，调用 bitmap.recycle()来释放内存
3.如果应用是基于图片的应用，尽量采用LazyLoad和DymanicRecycle
4.decode bitmap 的时候，将decode代码 try catch 出来，catch oom error，避免程序crash，可以在catch里面做一些释放内存操作




说说mvc模式的原理，它在android中的运用
​MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。
Android中界面部分也采用了当前比较流行的MVC框架，在Android中M就是应用程序中二进制的数据，V就是用户的界面。Android的界面直接采用XML文件保存的，界面开发变的很方便。在Android中C也是很简单的，一个Activity可以有多个界面，只需要将视图的ID传递到setContentView()，就指定了以哪个视图模型显示数据。
在Android SDK中的数据绑定，也都是采用了与MVC框架类似的方法来显示数据。在控制层上将数据按照视图模型的要求（也就是Android SDK中的Adapter）封装就可以直接在视图模型上显示了，从而实现了数据绑定。比如显示Cursor中所有数据的ListActivity，其视图层就是一个ListView，将数据封装为ListAdapter，并传递给ListView，数据就在ListView中现实



简单描述下Android 数字签名
在Android系统中，所有安装到系统的应用程序都必有一个数字证书，此数字证书用于标识应用程序的作者和在应用程序之间建立信任关系
Android系统要求每一个安装进系统的应用程序都是经过数字证书签名的，数字证书的私钥则保存在程序开发者的手中。Android将数字证书用来标识应用程序的作者和在应用程序之间建立信任关系，不是用来决定最终用户可以安装哪些应用程序。这个数字证书并不需要权威的数字证书签名机构认证，它只是用来让应用程序包自我认证的。
同一个开发者的多个程序尽可能使用同一个数字证书，这可以带来以下好处。
(1)有利于程序升级，当新版程序和旧版程序的数字证书相同时，Android系统才会认为这两个程序是同一个程序的不同版本。如果新版程序和旧版程序的数字证书不相同，则Android系统认为他们是不同的程序，并产生冲突，会要求新程序更改包名。
(2)有利于程序的模块化设计和开发。Android系统允许拥有同一个数字签名的程序运行在一个进程中，Android程序会将他们视为同一个程序。所以开发者可以将自己的程序分模块开发，而用户只需要在需要的时候下载适当的模块。
在签名时，需要考虑数字证书的有效期：
(1)数字证书的有效期要包含程序的预计生命周期，一旦数字证书失效，持有改数字证书的程序将不能正常升级。
(2)如果多个程序使用同一个数字证书，则该数字证书的有效期要包含所有程序的预计生命周期。
(3)Android Market强制要求所有应用程序数字证书的有效期要持续到2033年10月22日以后。
Android数字证书包含以下几个要点：
(1)所有的应用程序都必须有数字证书，Android系统不会安装一个没有数字证书的应用程序
(2)Android程序包使用的数字证书可以是自签名的，不需要一个权威的数字证书机构签名认证
(3)如果要正式发布一个Android，必须使用一个合适的私钥生成的数字证书来给程序签名，而不能使用adt插件或者ant工具生成的调试证书来发布。
(4)数字证书都是有有效期的，Android只是在应用程序安装的时候才会检查证书的有效期。如果程序已经安装在系统中，即使证书过期也不会影响程序的正常功能。



什么是嵌入式实时操作系统, Android操作系统属于实时操作系统吗
实时操作系统是指当外界事件或数据产生时，能够接受并以足够快的速度予以处理，其处理的结果又能在规定的时间之内来控制生产过程或对处理系统作出快速响应，并控制所有实时任务协调一致运行的嵌入式操作系统。主要用于工业控制、军事设备、航空航天等领域对系统的响应时间有苛刻的要求，这就需要使用实时系统。又可分为软实时和硬实时两种，而android是基于linux内核的，因此属于软实时。


dvm的进程和Linux的进程, 应用程序的进程是否为同一个概念
Dvm是dalivk虚拟机,每个android程序都运行在自己的进程里面,每个android程序系统都会给他分配一个单独的uid, 每个dvm都是linux里面的一个进程.所以说这两个进程是一个进程.


Android程序与Java程序的区别？
Android程序用android sdk开发,java程序用javasdk开发.
Android SDK引用了大部分的Java SDK，少数部分被AndroidSDK抛弃，比如说界面部分，java.awt package除了java.awt.font被引用外，其他都被抛弃，在Android平台开发中不能使用。将Java 游戏或者j2me程序移植到Android平台的过程中，Android  SDK与Java SDK的区别是很需要注意的地方