android守护进程

⑴ AndroidFramework 之启动 ServiceManager

本文源码基于 Android 10 ，涉及相关源码如下。

ServiceManagaer 是 Binder 的守护进程，在 Binder 机制中起着重要的作用。本文将从源码的角度对其进行分析，整体流程如下：

时序图如下。

先来看看 ServiceManager 是如何启动的：

在 Zygote 一文中说过， init 进程启动的第二阶段会解析 init.rc 文件。

在这之后会触发 trigger init 。

结合 init.rc 看看 action init 做了什么。

当触发 trigger init 后，会启动 servicemanager 服务，其声明如下。

对应的执行文件为 /system/bin/servicemanager ，在编译前位于 frameworks/native/cmds/servicemanager 下，来看看 Android.bp 。

其对应的源码为 service_manager.c 和 binder.c ，入口函数 main() 位于 servicemanager.c 。

启动完 ServiceManager 后会打开 Binder 驱动。

在 main() 中首先调用 binder_open() 。

binder_open() 主要做了如下事情：

给结构体 binder_state 分配内存。

系统调用 open() 打开 /dev/binder ，如果打开驱动失败，则执行 fail_open 释放内存。

简单的解释一下什么是系统调用？

由于需要限制不同的程序之间的访问能力，防止程序获取别的程序的内存数据， CPU 划分出两个权限等级， 用户态 和 内核态 。

所有的用户程序都是运行在用户态，但有时需要做一些内核态的事情，而唯一可以做这些事情的就是操作系统，所以程序需要向操作系统发起请求，以程序的名字来执行这些操作。这时就需要一个从用户态切换到内核态但不能控制内核态中执行的机制，这种机制就是 系统调用 。

系统调用 ioctl() 传入 BINDER_VERSION 命令获取 Binder 驱动版本，对比版本是否一致，不一致则执行 fail_open 释放内存。

系统调用 mmap() 映射 128kb 的内存空间，即把 Binder 驱动文件的 128kb 映射到内存空间供 ServiceManager 使用，内存映射失败则执行 fail_map ，关闭 fd 并释放内存。

ServiceManager 进程 mmap 的内存大小可以通过 adb shell 命令查看。

可以看到内存映射地址为 0xf10f8000 ~ 0xf1118000 ，差为 0x20000 即十进制的 128kb 。

打开 Binder 驱动后会将 ServiceManager 设置为上下文管理者。

调用 binder_become_context_manager() 。

android 10 新增 BINDER_SET_CONTEXT_MGR_EXT 命令来设置安全的上下文管理者，如果设置失败，则使用原有的 BINDER_SET_CONTEXT_MGR 命令来设置上下文管理者，两者区别在于是否携带参数。

最后会进入循环，从 Binder 驱动读取和解析数据。

调用 binder_loop() 进入循环，不断地通过系统调用 ioctl() 从 Binder 驱动读取数据，并通过 binder_parse() 进行数据解析。

注意这里调用 binder_loop() 传入的 svcmgr_handler() ，后面会使用到。

binder_write() 会封装 struct binder_write_read ，并通过系统调用 ioctl() 将对应的命令传递给 Binder 驱动。

binder_parse() 用来解析从 Binder 驱动读取到的数据，然后根据不同的命令执行对应的操作。

因为 cmd 命令可能有多个，所以通过 while 循环每次处理一个 cmd 命令，多 cmd 的结构大致如下图所示。

这里重点看下 BR_TRANSACTION 命令。

BR_TRANSACTION 是 Binder 驱动向 Server 端发送请求数据。

binder_transaction_data 的结构如下，其表明了 transcation 传输的具体语义，语义码记录在 code 中，不同语义码携带的数据是不同的，这些数据由 data 指定。

在解析完 binder_transaction_data 的具体语义后，会调用前面传给 binder_loop() 的 svcmgr_handler() ，其实就是 switch case 语义码做不同的事情。

ServiceManager 的功能其实很简单：

至此 ServiceManager 就分析完了。

⑵ Android 日志系统分析(二)：logd

logd 守护进程是日志系统的管家，内部维持三个日志 Socket : logd、logdr、logdw 来与客户端进行通信。同时负责维护几个环形缓冲区，用于存放系统中的各种日志，缓冲区包含 main、system、events、radio、crash、kernel ；但是在 Android 5.0 之前， logd 进程并不存在，日志是保留在 /dev/log/main、/dev/log/system、/dev/log/radio、/dev/log/event 等节点中，但是这样面临的一个问题就是当 Android 系统大版本升级时， linux kernel 需要升级对应的日志驱动，因此在后续的版本中就有了 logd 进程。

在 Android 日志系统分析(一)：概述 一文中，总结了整个日志读写的主要流程，因此对于 logd 进程是如何同外界沟通进而读写日志的过程不再赘述，而着重于 logd 本身的一些知识点，这里先看一下 logd 的系统框图：

知识点：

① logd 是日志系统的核心进程，由 init 启动，是属于守护进程常驻后台
② logd 维护各个日志节点缓存队列，提供 socket 接口进行读、写、控制功能
③ logd 进程启动后，分别启动 LogReader、LogListener、CommandListener 三个线程，监听并处理来自三个 socket 的消息。在收到消息后，会通过 LogBuffer 类保存日志到对应的 RAM buffer 中
④ LogAudit 模块用于接收 Kernel selinux 信息，即可以在用户空间打印 selinux 日志信息
⑤ LogKlog 用于接收 kernel 日志信息，通过设置 property ，可以通过 logcat 命令读取内核日志
⑥ LogStatistics 是日志统计模块，默认开启统计数据较少，仅能以 pid/uid 纬度统计打印日志的数量。如果设置了 logd.statistic = true 。会打印更多纬度的统计信息，包括哪些 pid/uid/tid/TAG 日志量比较大，可用于日志裁剪相关

在 main 函数中，会打开 /dev/kmsg 来读取内核日志，通过 LogKlog 来进行存储；若是配置了 ro.logd.kernel 属性，则打开 /proc/kmsg 读取内核日志；

logd 作为 Native Service ，系统启动时会读取 init.rc 脚本去启动，它的相关属性被定义在 logd.rc 文件中：

这里主要分为两部分： 启动 logd 服务 和 启动 logd-reinit 服务 （在Android 10 上添加了 logd-auditctl 服务，目的是为了限制 selinux denia打印日志为5秒一次）；先来看一下 启动 logd 服务 的同时做了些什么：

① 创建 logd、logdr、logdw 这三个 socket 为后面的通信做准备
② logdw 定义为 dgram 类型的 socket ，类似与 UDP类型的 Socket ，这么做的原因是考虑到性能问题，在多个进程同时写日志的情况下， write 函数写入到 socket 的 buffer 中即可返回，这样不会 block 业务逻辑太长时间。如果是 TCP 类型的 Socket ，客户端需要等到 TCP 收到 ACK 响应才能返回，这样就会过多的消耗性能和资源；

启动 logd-reinit 服务：

这个服务的主要作用是重新初始化 logd 的 LogBuffer，在配置中 oneshot 表示开机只启动一次。在上面的 main.cpp 中的 main 函数内， logd 在启动后，会创建一个线程 reinit_thread_start () ，当 logd-reinit 传入参数 reinit 后，进行功能执行:

① 如果 reinit 启动后，并且 /deg/kmsg 打开成功，把 logd.daemon: renit 写入 kmsg
② 重新初始化各个 log buffer 的大小，以及其他参数的初始化，但不会重新生成 LogBuffer 对象

main.cpp##main

main.cpp#reinit_thread_start()

[ 1 ] 深入理解安卓日志系统（logcat / liblog / logd）
[ 2 ] Android10.0 日志系统分析(二)-logd、logcat架构分析及日志系统初始化

⑶ Android保活系列之——双进程守护

近期跳槽到玩加电竞，加之英雄联盟云顶之弈排位模式的推出，导致个人精力有限没有时间和心情去写相关的博客。

在Context中提供了bindService的方法

绑定服务是客户端--服务器接口中的服务器。组件和服务进行绑定后，可以发送请求、接收响应、执行进程间通信（IPC）。这里的服务器模型不同于网络C-S模型而是针对于Android应用不同的功能进行进程划分，例如提供视频播放的进程我们可以把它当做视频播放服务器，我们UI层属于客户端，客户端想要调用视频播放，需要用IPC方式通过bind服务的方式调用视频播放服务。（PS:如果大家对IPC不太熟悉可以参考我的其他文章 Android跨进程通信技术的使用及原理 ）客户端可以通过调用bindService()绑定到服务。调用时，必须提供ServiceConnection的实现，后者会监控与服务的连接及销毁。
借助bindService的机制，我们可以在主进程创建时创建一个守护进程，并监听守护进程的连接及销毁，再守护进程bindService中绑定主进程，这样即使进程因为锁屏、内存等问题杀掉后，也会被守护进程拉起，这就是Android中双进程守护的概念。当然早在PC时期，网吧的计时系统就使用了双进程守护机制，防止被恶意杀掉。
实现方式就不写了，网络上一搜一堆，这里给出一篇文章
Android 双进程守护
写的中规中矩，如果不清楚如何实现可以看一下。

谷歌官方8.0变更

当版本>8.0时，如果需要在后台启动服务需要调用startForegroundService。并且在serivce中onCreate方法必须在5秒内调用startForeground ,向通知栏发一个通知告知用户你的App正在后台运行，否则就会抛出异常

8.0通知适配

保活分两种：拉活、保活
拉活和保活是相辅相成的。在6.0版本以后的机型上，系统杀应用是按照进程组杀的，会直接导致双进程守护失效。那么因此就不使用双进程了么？
1.低版本双进程守护是依然亲测好使。
2.双进程守护可以和后面讲到的 账号同步、外部PUSH、JobScheler
相结合，可以规避开系统杀进程组的问题。使双进程守护功能可以兼容高版本。

讲的有些笼统，我寻思的发Dome、写例子，但这样解决不了根本问题，只有懂得了思路，了解了什么是双进程守护，才能在开发中随机应变。只能说Android水太深，大家需要细心细心再细心。

⑷ Android 守护进程的实现方式

在我们进行应用开发时，会遇到上级的各种需求，其中有一条 刚需： 后台保活 ，更有甚者：

我要我们的应用永远活在用户的手机后台不被杀死 —— 这都 TM 的扯淡

除了系统级别的应用能持续运行，所有三方程序都有被杀死的那一天！当然 QQ/微信/陌陌 等会好一些，因为他们已经深入设备的 心 ；
我们能做的只是通过各种手段尽量让我们的程序在后台运行的时间长一些，或者在被干掉的时候，能够重新站起来，而且这个也不是每次都有效的，也是不能在所有的设备的上都有效的；要做到后台进程保活，我们需要做到两方便：

要实现实现上边所说，通过下边几点来实现，首先我们需要了解下进程的优先级划分：

Process Importance 记录在 ActivityManager.java 类中:

了解进程优先级之后，我们还需要知道一个进程回收机制的东西；这里参考 AngelDevil 在博客园上的一篇文章:

Android 的 Low Memory Killer 基于 Linux 的 OOM 机制，在 Linux 中，内存是以页面为单位分配的，当申请页面分配时如果内存不足会通过以下流程选择bad进程来杀掉从而释放内存：

在 Low Memory Killer 中通过进程的 oom_adj 与占用内存的大小决定要杀死的进程， oom_adj 越小越不容易被杀死；
Low Memory Killer Driver 在用户空间指定了一组内存临界值及与之一一对应的一组 oom_adj 值，当系统剩余内存位于内存临界值中的一个范围内时，如果一个进程的 oom_adj 值大于或等于这个临界值对应的 oom_adj 值就会被杀掉。

下边是表示 Process State (即老版本里的 OOM_ADJ )数值对照表，数值越大，重要性越低，在新版SDK中已经在 android 层去除了小于0的进程状态

Process State （即老版本的 OOM_ADJ ）与 Process Importance 对应关系，这个方法也是在 ActivityManager.java 类中，有了这个关系，就知道可以知道我们的应用处于哪个级别，对于我们后边优化有个很好地参考

一般情况下，设备端进程被干掉有一下几种情况

由以上分析，我们可以可以总结出，如果想提高我们应用后台运行时间，就需要提高当前应用进程优先级，来减少被杀死的概率

分析了那么多，现在对Android自身后台进程管理，以及进程的回收也有了一个大致的了解，后边我们要做的就是想尽一切办法去提高应用进程优先级，降低进程被杀的概率；或者是在被杀死后能够重新启动后台守护进程

第一种方式就是利用系统漏洞，使用 startForeground() 将当前进程伪装成前台进程，将进程优先级提高到最高(这里所说的最高是服务所能达到的最高，即1);

这种方式在 7.x 之前都是很好用的，QQ、微信、IReader、Keep 等好多应用都是用的这种方式实现；因为在7.x 以后的设备上，这种伪装前台进程的方式也会显示出来通知栏提醒，这个是取消不掉的，虽然 Google 现在还没有对这种方式加以限制，不过这个已经能够被用户感知到了，这种方式估计也用不了多久了

下边看下实现方式，这边这个 VMDaemonService 就是一个守护进程服务，其中在服务的 onStartCommand() 方法中调用 startForeground() 将服务进程设置为前台进程，当运行在 API18 以下的设备是可以直接设置，API18 以上需要实现一个内部的 Service ，这个内部类实现和外部类同样的操作，然后结束自己；当这个服务启动后就会创建一个定时器去发送广播，当我们的核心服务被干掉后，就由另外的广播接收器去接收我们守护进程发出的广播，然后唤醒我们的核心服务；

当我们启动这个守护进程的时候，就可以使用以下 adb 命令查看当前程序的进程情况（需要 adb shell 进去设备），
为了等下区分进程优先级，我启动了一个普通的后台进程，两外两个一个是我们启动的守护进程，一个是当前程序的核心进程，可以看到除了后台进程外，另外两个进程都带有 isForeground=true 的属性：

然后我们可以用下边的命令查看 ProcessID

有了 ProcessID 之后，我们可以根据这个 ProcessID 获取到当前进程的优先级状态 Process State ，对应 Linux 层的 oom_adj
可以看到当前核心进程的级别为 0 ，因为这个表示当前程序运行在前台 UI 界面，守护进程级别为 1 ，因为我们利用漏洞设置成了前台进程，虽然不可见，但是他的级别也是比较高的，仅次于前台 UI 进程，然后普通后台进程级别为 4 ；当我们退到后台时，可以看到核心进程的级别变为 1 了，这就是因为我们利用 startForeground() 将进程设置成前台进程的原因，这样就降低了进程被系统回收的概率了；

可以看到这种方式确实能够提高进程优先级，但是在一些国产的设备上还是会被杀死的，比我我测试的时候小米点击清空最近运行的应用进程就别干掉了；当把应用加入到设备白名单里就不会被杀死了，微信就是这样，人家直接装上之后就已经在白名单里了，我们要做的就是在用户使用中引导他们将我们的程序设置进白名单，将守护进程和白名单结合起来，这样才能保证我们的应用持续或者

Android系统在5.x以上版本提供了一个 JobSchele 接口，系统会根据自己实现定时去调用改接口传递的进程去实现一些操作，而且这个接口在被强制停止后依然能够正常的启动；不过在一些国产设备上可能无效，比如小米；
下边是 JobServcie 的实现：

我们要做的就是在需要的时候调用 JobSchele 的 schele 来启动任务；剩下的就不需要关心了， JobSchele 会帮我们做好，下边就是我这边实现的启动任务的方法：

在实现 Service 类时，将 onStartCommand() 返回值设置为 START_STICKY ，利用系统机制在 Service 挂掉后自动拉活；不过这种方式只适合比较原生一些的系统，像小米，华为等这些定制化比较高的第三方厂商，他们都已经把这些给限制掉了；

这种方式在以下两种情况无效：

事事没有绝对，万物总有一些漏洞，就算上边的那些方式不可用了，后边肯定还会出现其他的方式；我们不能保证我们的应用不死，但我们可以提高存活率；

其实最好的方式还是把程序做好，让程序本身深入人心，别人喜欢你了，就算你被干掉了，他们也会主动的把你拉起来，然后把你加入他们的白名单，然后我们的目的就实现了不是 😁 ~

⑸ Android 使用MarsDaemon进程常驻

在特定的业务场景中，我们可能会需要app在后台做一些事情，比如上传数据之类的操作，并且希望这种操作及时在程序退出之后依然可以继续进行。因此也就理所当然的想到了使用Service进行处理。 但是 ，在特定条件（app进入后台+设备内存不足+进程占用的内存足够大）的情况下，Service会非常容易在几分钟内被系统干掉，因此提高Service的存活率至关重要。

此方法企图利用Service是生命周期去调用其本身，事实证明这种方法是无效的，在进程被杀死时，Service根本不会执行onDestroy就被直接清出内存了，因此靠自身的力量提高存活率的方式也就不可行了。

导入项目之后

之后不要忘记导入mole

此处将process1作为主要进程，process2作为守护进程。MainService中执行主要的业务逻辑，Receiver1、GuardService、Receiver2都是额外创建的，里面不要做任何事情，都是空实现就好。

由于我们的Application一般都会集成其他的Application，因此需要在attachBaseContext中初始化DaemonClient，然后调用onAttachBaseContext即可实现

使用Marsdaemon提高Service存活率的方式虽然有一定效果，但是在Android5.0之后的版本中，并不可靠，并且还有如下几个缺陷。

因此，Marsdaemon不应是大家频繁使用的功能，特殊情况下可以应急即可。

⑹ 在Android设备上怎么调试守护进程

其实网上有很多类似的文章，但是你会发现几乎都不可重现，要么是细节没讲清楚，要么是压根自己没有真正去试过。这里，我仅给出自己用gdb和gdbserver调试android native code的实际过程，希望对大家有用。

注：以调试mediaserver进程为例.

第一步：你需要下载android，以debug方式编译，并以生成的image起模拟器或者设备。

第二步：你需要从“http://developer.download.nvidia.com/tegra/files/tegra-gdb-20100430.zip”下载一个gdb，覆盖到android源码中gdb对应的位置。

第三步：adb shell到设备,并起gdbserver侦听目标进程:

adb shell

gdbserver :5039 /system/bin/mediaserver

第四步: 建立pc机和设备的消息连接:

adb forward tcp:5039 tcp:5039

第五步: 使用gdb调试目标进程:

cd android_src

prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gdb out/debug/target/proct/generic/symbols/system/bin/mediaserver

第六步: 设置符号表:

set solib-absolute-prefix /your_android_src_path/out/debug/target/proct/generic/symbols

set solib-search-path /your_android_src_path/out/debug/target/proct/generic/symbols/system/lib

第七步: 使gdb和gdb server建立连接:

target remote :5039

第八步: ok. 现在可以使用gdb的命令进行调试,譬如next\break\step\info thread等.

⑺ Android-保活

Low Memory Killer

打开的应用越多，后台缓存的进程也越多。因为系统出于体验和性能上的考虑，app在退到后台时系统并不会真正的kill掉这个进程，而是将其缓存起来。于是在系统内存不足的情况下，系统开始依据自身的一套进程回收机制来判断要kill掉哪些进程，以腾出内存来供给需要的app, 这套杀进程回收内存的机制就叫 Low Memory Killer。

进程的优先级（by:https://developer.android.google.cn/guide/components/activities/process-lifecycle?hl=zh-cn）

前台进程

用户正在使用的程序，一般系统是不会杀死前台进程的，除非用户强制停止应用或者系统内存不足等极端情况会杀死。

可见进程

用户正在使用，看得到，但是摸不着，没有覆盖到整个屏幕,只有屏幕的一部分可见进程不包含任何前台组件，一般系统也是不会杀死可见进程的，除非要在资源吃紧的情况下，要保持某个或多个前台进程存活施。

服务进程

在内存不足以维持所有前台进程和可见进程同时运行的情况下，服务进程会被杀死。

后台进程

系统可能随时终止它们，回收内存。

空进程

某个进程不包含任何活跃的组件时该进程就会被置为空进程，完全没用,杀了它只有好处没坏处,第一个干它。

内存阈值

内存阈值在不同的手机上不一样，一旦低于该值,Android便会杀死对应优先级的进程。一旦低于该值,Android便开始按逆序关闭进程。即优先级从最高的空进程开始，逆序关闭，直到内存足够。

如何判断进程的优先级？

通过 oom_adj 值，判断进程的优先级，不同手机的oom_adj 值可能不一样。

我们了解这个有什么用呢？PS：了解这个你才能想办法保证自己怎么不被杀掉。

网上的一些方案和自己认为有用的方案

1 开启一个像素Activity（伪前台进程）

在锁屏的时候在本进程开启一个Activity，为了欺骗用户，让这个Activity的大小是1像素，并且透明无切换动画，在开屏幕的时候，把这个Activity关闭掉，所以这个就需要监听系统锁屏广播。

我们的应用就始终和前台进程是一样的优先级了，为了省电，系统检测到锁屏事件后一段时间内会杀死后台进程，如果采取这种方案，就可以避免了这个问题，但是还是有被杀掉的可能。

Android5.0以下：

Process.killProcessQuiet(pid);

Android5.0以后：

Process.killProcessQuiet(app.pid);

Process.killProcessGroup(app.info.uid, app.pid);

应用退出后，ActivityManagerService不仅把主进程给杀死，另外把主进程所属的进程组一并杀死，这样一来，由于子进程和主进程在同一进程组，子进程在做的事情，也就停止了。

2 相互唤醒（广播唤醒）

相互唤醒的意思就是，假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app，那么你打开任意一个阿里系的app后，有可能就顺便把其他阿里系的app给唤醒了。这个完全有可能的。此外，开机，网络切换、拍照、拍视频时候，利用系统产生的广播也能唤醒app，不过Android N已经将这三种广播取消了。

3 JobSheler机制保活（不推荐）

JobSheler是作为进程死后复活的一种手段，native进程方式最大缺点是费电， Native 进程费电的原因是感知主进程是否存活有两种实现方式，在 Native 进程中通过死循环或定时器，判断主进程是否存活，当主进程不存活时进行拉活。其次5.0以上系统不支持。  但是JobSheler可以替代在Android5.0以上native进程方式，这种方式即使用户强制关闭，部分厂商手机（如：华为）也能被拉起来，但AndroidN失效。

4 粘性服务&与系统服务捆绑()

这个是系统自带的，onStartCommand方法必须具有一个整形的返回值，这个整形的返回值用来告诉系统在服务启动完毕后。Service的onStartCommand方法里返回 STATR_STICK，onDestory中start自启（准确的将算不上进程拉活，只能算service自启，force_stop后不能正常拉活）。

5 监听第三方app开放的静态广播（同2）

需要大量反编译app去找开放的静态广播，而且不保证长期有效，可能第三方开放广播在版本升级时改为私有广播，如果自己公司有多个app,可广播互相拉起。

6 NDK+Socket通过fork实现进程保活方案（）

实现进程守护实际是守护app的主要服务，当app主进程被系统kill时，主要服务也会杀死，守护进程将其唤醒。

实现原理图：

进程保活方案调研结果

未能实现真正意义上的进程保活。

光从保活这一点来说，绑定一个像素activity和循环一个无声的声音这种方法比较好，但是对用户来说太流氓了，不推荐。  对于有硬性需求的，可以引导用户加入白名单。至于推送，  可以尝试集成多个推送方案，小米，华为等都有推送sdk，在对应手机上可以确保收到消息，  然后像网络这种是多app公用通道的，也就是手机中有一个使用网络推送的app被允许后台启动，就能让其他app收到推送。随着Android版本的不断更新及国内厂商对ROM的不断优化，如何最大可能的对进程保活，是Android一道需要长期学习/钻研的学问，也是Android开发者不得不面对的问题。

引援:https://www.jianshu.com/p/1c353edf73ba

⑻ Android应用开发需要具备哪些知识

l 熟练运用Android下的自定义控件。x0dx0al 熟练掌握Android系统架构，对Android的各个层次的开发有一定的认识。x0dx0al 熟练掌握android下的XML,JSON,HTML的解析，熟练掌握各种数据的存储方式，能使用MVC独立开发客户端程序，熟悉安卓下的GPS定位。x0dx0al 熟悉android 的JNI 开发，通过JNI实现JAVA与C/C++程序间的调用及回调。x0dx0al 熟练掌握UI设计、常用布局、动画特效。熟悉安卓下的消息推送机制原理。x0dx0al 熟悉Android下的安全机制。如获取系统最高权限使得不能停止服务，利用守护进程保护服务不被停止，清理内存等。x0dx0al 熟悉Android下网络通信机，对Socket通信、TCP、Http有较深刻的了解和经验。x0dx0al 熟练应用Mysql，SQLServer，及安卓下的SQLite数据库操作及编码。x0dx0al 熟练掌握HTML，DIV/CSS，熟悉JavaScript/Ajax/jquery能实现静态页面的开发。x0dx0al 了解HTML5,了解PhoneGAP框架，WebSevice。x0dx0a熟练使用Eclipse/Myeclipse,CVS/SVN/GIT等开发工具, 对数据结构有深入了解，有C/C++基础x0dx0a当然你java基础也必须要好 算法什么的

⑼ Android系统内存管理

部分内容出至林学森的Android内核设计思想。
Android官网内存管理
部分出至 https://www.jianshu.com/p/94d1cd553c44

Android本质是Linux所以先从Linux说起。

Linux的内存管理为系统中所有的task提供可靠的内存分配、释放和保护机制。
核心：
虚拟内存
内存分配与释放
内存保护

将外存储器的部分空间作为内存的扩展，如从硬盘划出4GB大小。
当内存资源不足时，系统按照一定算法自动条形优先级低的数据块，并把他们存储到硬盘中。
后续如果需要用到硬盘中的这些数据块，系统将产生“缺页”指令，然后把他们交换回内存中。
这些都是由操作系统内核自动完成的，对上层应用”完全透明“。

每个进程的逻辑地址和物理地址都不是直接对应的，任何进程都没办法访问到它管辖范围外的内存空间——即刻意产生的内存越界与非法访问，操作系统也会马上阻止并强行关闭程序，从而有力的保障应用程序和操作系统的安全和稳定。

一旦发现系统的可用内存达到临界值，机会按照优先级顺序，匆匆低到高逐步杀掉进程，回收内存。
存储位置：/proc/<PID>/oom_score
优先级策略：
进程消耗的内存
进程占用的CPU时间
oom_adj（OOM权重）

Android平台运行的前提是可用内存是浪费的内存。它试图在任何时候使用所有可用的内存。例如，系统会在APP关闭后将其保存在内存中，以便用户可以快速切换回它们。出于这个原因，Android设备通常运行时只有很少的空闲内存。在重要系统进程和许多用户应用程序之间正确分配内存内对存管理是至关重要。
Android有两种主要的机制来处理低内存的情况：内核交换守护进程(kernel swap daemon)和低内存杀手(low-memory killer)。

当用户在APP之间切换时，Android会在最近使用的（LRU）缓存中保留不在前台的APP，即用户看不到的APP，或运行类似音乐播放的前台服务。如果用户稍后返回APP，系统将重用该进程，从而使APP切换更快。
如果你的APP有一个缓存进程，并且它保留了当前不需要的内存，那么即使用户不使用它，你的APP也会影响系统的整体性能。由于系统内存不足，它会从最近使用最少的进程开始杀死LRU缓存中的进程。该系统还负责处理占用最多内存的进程，并可以终止这些进程以释放RAM。
当系统开始终止LRU缓存中的进程时，它主要是自底向上工作的。系统还考虑哪些进程消耗更多的内存，从而在终止时为系统提供更多的内存增益。你在LRU列表中消耗的内存越少，你就越有可能留在列表中并能够快速恢复。

为了满足RAM的所有需求，Android尝试共享RAM来跨进程通信。它可以做到以下方式：

Android设备包含三种不同类型的内存：RAM、zRAM和storage。
注意：CPU和GPU都访问同一个RAM。

内存被拆分成页。通常每页有4KB的内存。
页面被认为是空闲的或已使用的。
空闲页是未使用的RAM。
已使用页是系统正在积极使用的RAM，分为以下类别：

干净的页面(Clean pages)包含一个文件（或文件的一部分）的一份精确副本存在存储器上。当一个干净的页面不再包含一个精确的文件副本（例如，来自应用程序操作的结果）时，它就变成了脏页。可以删除干净的页，因为它们始终可以使用存储中的数据重新生成；不能删除脏页(Dirty pages)，否则数据将丢失。

内核跟踪系统中的所有内存页。

当确定一个应用程序正在使用多少内存时，系统必须考虑shared pages。APP访问相同的服务或库将可能共享内存页。例如，Google Play Services 和一个游戏APP可能共享一个位置服务。这使得很难确定有多少内存属于这个服务相对于每个APP。

当操作系统想要知道所有进程使用了多少内存时，PSS非常有用，因为页面不会被多次计数。PSS需要很长时间来计算，因为系统需要确定哪些页面是共享的，以及被有多少进程。RSS不区分共享页面和非共享页面（使计算速度更快），更适合于跟踪内存分配的更改。

内核交换守护进程（kswapd）是Linux内核的一部分，它将使用过的内存转换为空闲内存。当设备上的空闲内存不足时，守护进程将变为活动状态。Linux内核保持低和高的可用内存阈值。当空闲内存低于低阈值时，kswapd开始回收内存。当空闲内存达到高阈值，kswapd将停止回收内存。
kswapd可以通过删除干净的页面来回收干净的页面，因为它们有存储器支持并且没有被修改。如果进程试图寻址已删除的干净页，则系统会将该页从存储器复制到RAM。此操作称为请求分页。

kswapd将缓存的私有脏页(private dirty pages)和匿名脏页(anonymous dirty pages)移动到zRAM进行压缩。这样做可以释放RAM中的可用内存（空闲页）。如果进程试图触摸zRAM中脏页，则该页将被解压缩并移回RAM。如果与压缩页关联的进程被终止，则该页将从zRAM中删除。
如果可用内存量低于某个阈值，系统将开始终止进程。

lmkd实现源码要在system/core/lmkd/lmkd.c。
lmkd会创建名为lmkd的socket，节点位于/dev/socket/lmkd，该socket用于跟上层framework交互。

小结：
LMK_TARGET： AMS.updateConfiguration() 的过程中调用 updateOomLevels() 方法, 分别向/sys/mole/lowmemorykiller/parameters目录下的minfree和adj节点写入相应信息；
LMK_PROCPRIO： AMS.applyOomAdjLocked() 的过程中调用 setOomAdj() 向/proc/<pid>/oom_score_adj写入oom_score_adj后直接返回；
LMK_PROCREMOVE： AMS.handleAppDiedLocked 或者 AMS.() 的过程,调用remove(),目前不做任何事,直接返回；

为了进一步帮助平衡系统内存并避免终止APP进程，可以Activity类中实现ComponentCallbacks2接口。提供的onTrimMemory()回调方法允许APP在前台或后台侦听与内存相关的事件，然后释放对象以响应应用程序生命周期或表明系统需要回收内存的系统事件。
onTrimMemory()回调是在Android 4.0（API级别14）中添加的。
对于早期版本，可以使用onLowMemory()，它大致相当于TRIM_MEMORY_COMPLETE事件。

一个专门的驱动。(Linux Kernel 4.12 已移除交给kswapd处理)。
很多时候，kswapd无法为系统释放足够的内存。在这种情况下，系统使用onTrimMemory()通知APP内存不足，应该减少其分配。如果这还不够，内核将开始终止进程以释放内存，它使用低内存杀手（LMK）来完成这个任务。
为了决定要终止哪个进程，LMK使用一个名为oom_adj_score的“out of memory”分数来确定运行进程的优先级，高分的进程首先被终止。
后台应用程序首先被终止，系统进程最后被终止。
下表列出了从高到低的LMK评分类别。第一排得分最高的项目将首先被杀死：

Android Runtime（ART）和Dalvik虚拟机使用分页（Paging）和内存映射（mmapping）来管理内存。应用程序通过分配新对象或触摸已映射页面来修改内存都将保留在RAM中，并且不能被调出。应用程序释放内存的唯一方式是垃圾收集器。

⑽ 解决Android Studio内存占用过大问题

笔者在Ubuntu电脑上面运行Android Studio，发现内存占用非常大，主要是Gradle守护进程在执行任务之后不释放导致，参考Gradle官方文档，可以使用命令来清理，不用每次都重启Android Studio 守护进程会在闲置3小时后自动终止.如果想在这之前停止守护进程,也可以通过操作系统运行gradle --stop命令终止后台进程.--stop选项会要求所有运行相同版本的守护进程终止.