Android--编程方法之外的常识

最新推荐文章于 2021-05-26 00:11:30 发布

ioter12

最新推荐文章于 2021-05-26 00:11:30 发布

阅读量390

点赞数

分类专栏： Android 文章标签： Android dalvik webkit

本文链接：https://blog.youkuaiyun.com/u014751358/article/details/47361487

版权

Android 专栏收录该内容

12 篇文章

订阅专栏

Android整体架构：

分为Application（就是我们开发的一些上层应用）、ApplicationFramework（包括ActivityManager等）、本地库（如Webkit、Sqlite）、linux内核。

其中的Library层：来自开源社区的 C/C++ 本地库为 Android 应用层提供了很多必需的服务。它们包括:

WebKit: 一个高速的Web渲染引擎，这个引擎已经被 Safari ， Chrome 和很多其他的浏览器所使用。
SQLite: 一个全功能的 SQL 数据库
Apache Harmony: 开源的 Java 实现
OpenGL: 3D 图像渲染库
OpenSSL: 安全套接字层。等等..

这些库中的大部分都是被原封不动地拿过来的，但是 Bionic 是一个例外。 Bionic 基本上是 C 标准库的重写版。使用 Bionic 的原因有如下两条:

技术方面: 专为电量有限的设备进行优化。
许可证方面: 对他人的使用和修改是许可证友好的。

Dalvik虚拟机：

Dalvik 是一个专为 Android 设计的虚拟机。传统的Java虚拟机（JVM）是为了适应各种不同环境而设计的，强调泛用性。但Dalvik的开发团队认为专注于一个方面，可以得到更好的设计。因此他们研究了长期限制移动设备性能的制约因素，比如电池的续航能力和处理器的速度。而后针对这些因素对症下药，专门设计了Dalvik。

关于编译：

1.平常的Java开发都是先编写Java代码，然后通过Java编译器编译成字节码，最后在JVM上运行。

2.但在Android中并非如此。相同的是仍需编写Java代码然后编译为字节码，但Dalvik编译器在执行前，会将Java字节码重新编译为Dalvik字节码。到最后真正执行的是Dalvik字节码。如图：

为什么不直接把Java代码编译成Dalvik字节码呢? 这是有考虑的。让我们回到2005年 Dalvik 项目刚刚开始时，当时 Java 的语法修改很频繁，但 Java 字节码基本上没有什么太大的改动。于是 Android 团队决定使用 JVM 字节码而不是 Java 源码来产生 Dalvik 代码。这样做得到的好处是，理论上你可以使用任何可以编译成 Java 字节码的语言来开发 Android 应用，比如 Python 或者 Ruby 。我说“理论上”是因为你还需要可用的 SDK 和库。不过有万能的开源社区在，未来会出现一套完善的解决方案也未可知。

另外需要注意的是 Android Java 并非来自标准的 Java 家族。 Java 一般分为:标准版(用于开发基本的桌面型应用)、J2EE(企业级应用)、J2ME(移动平台)。Android的Java类库比较接近 Java 标准版，它们的主要区别在于Java类库的GUI接口（ AWT 和 Swing ）被替换成了 Android 的专用接口。 Android在支持标准 Java 的类库之余，也提供了若干新功能。这一来你可以很快地上手Android开发。

Activity的生命周期：

因为涉及到新建Linux进程、为UI对象申请内存、解析XML文件以及最终的图像渲染，初始化Activity的成本是比较高的。既然在初始化上面花了这么大功夫，那么每次离开Activity就将其销毁就未免太浪费了。在这方面，Android引入了Activity Manager机制，用以自动管理Activity的生命周期。

Activity的创建、销毁、管理皆由Activity Manager全权负责。如果用户首次启动了某程序，Activity Manager会负责程序界面的初始化与显示；如果用户要切换界面，Activity Manager将原先的界面隐藏而不是销毁，这样可以加速下次访问；Activity Manager也负责销毁长时间未访问的Activity，为当前活跃的Activity腾出更多内存空间。引入Activity Manager机制的动机就是提升用户界面的速度，这对用户体验很重要。

Intent：（组件之间传递消息的一种机制）

Intent分为显式（explicit）和隐式（implicit）两种。显式的Intent要求发送者明确地指出接收者是谁；而隐式的Intent只要求发送者指明接收者属于哪一类别。

Service的生命周期：

service是什么？
   不是线程、
   不是进程
两个功能：
   在后台做耗时操作Context.startService()
   向其他app公开自己的功能 Context.bindService()

Service的生命周期要比Activity简单不少，要么启动，要么停止。虽说Service运行于后台，但这并不是说它默认执行于另一个独立的线程中。如果一个Service需要执行一段耗时的操作(比如网络调用)，依然需要程序员将它放在单独的线程中处理。否则，你的用户界面将响应不灵。一言以蔽之，Service默认与Activity在同一个线程中执行，而这个线程也被称作UI线程。

ContentProvider（是应用程序之间共享数据的接口）：

Android默认使每个应用程序都运行在沙盒(sandbox)里面，自己的数据与外面的程序完全隔离，要传递数据则必须依赖一些特定的接口。少量数据通过Intent传递即可，要传递大量的持久化数据就需要Content Provider了。为此，Content Provider提供了一套很好的按照CRUD原则设计的接口，以供不同程序之间共享数据。

应用：Android将这种机制应用到了方方面面。比如Contacts Provider专为不同的应用程序提供联系人数据，Settings Provider专为不同的应用程序提供系统的配置信息，Media Store为不同的应用程序提供多媒体信息(比如图片、音乐)的存储与分享，等等。

把数据的存储与用户界面分离开来，这使得系统中各个部分之间的联系更加紧密，拆换起来也更加灵活。比如用户可以安装一个新的地址薄应用(Address Book App)替换掉原先的默认的联系人应用(Contacts App)，同时仍希望使用原先的数据；或在主屏幕上面安装一个小部件，方便做些开关WiFi/蓝牙/GPS之类的系统设置。也有许多手机制造商(比如 HTC Sense)基于Content Provider机制，设计一套自己的软件集来提升用户体验。
Content Provider的接口很简单，那就是insert()、update()、delete()与query()。这与一个数据库的接口很相似，因此针对某数据库实现一个Content Provider当作代理也十分简单。话虽这么说，不过你该更喜欢使用现成的Content Provider，而不是自己造轮子。

Application Context：

Application Context即当前应用程序所在的进程以及其运行环境，它为不同的构件所共享，因此我们可以通过它实现在不同的构件中共享数据和资源。不管应用程序中首先启动的是哪个构件(Activity，Service还是其它)，都会首先初始化Application Context。从此它的生存周期也就与整个应用程序保持一致，而与Activity或者某构件无关。我们可以通过Context.getApplicationContext()或者Activity.getApplication()获得它的引用。留意Activity与Service都是Context的子类，因此也就继承了它所有的方法。

详细介绍

SharedPreferences:

名字中的"Shared"可能会让人疑惑，它是指允许在当前程序的各部分间共享，而不能与其它程序共享。这个类允许我们在程序的任何部分(比如Activity,Service,BroadcastReceiver,ContentProvider)中访问选项数据，这也正是SharedPreference这个名字的由来。

整理自：Learning Android CN Project