1，第一种思路

此题很容易认为是 16bit/80纳秒，从而算出200MB/s。

 

2，第二种思路

但另外一个思考方法算出的数据截然不同。

80纳秒一个刷新周期，那么一秒会刷新多少次呢？

1秒/80纳秒 /次= 1/(80* 10＾-9) 次。

每次可以传送16bit，即为2Byte

所以1秒的传送量= 2 B/次 * 1/(80*10＾-9)次 = 200 / 8  MB = 25 MB。

 

我认为第二种思路是没问题的。那么上面的第一种思路，16bit/80纳秒究竟有什么问题呢？

不用在意剩余内存的大小，其实很多人都是把使用其他系统的习惯带过来来了。

        Android采取了一种有别于Linux的进程管理策略，有别于Linux的在进程活动停止后就结束该进程,Android把这些进程都保留在内存中，直到系统需要更多内存为止。这些保留在内存中的进程通常情况下不会影响整体系统的运行速度并且当用户再次激活这些进程时，提升了进程的启动速度。
那Android什么时候结束进程？结束哪个进程呢？之前普遍的认识是Android是依据一个名为LRU（last recently used 最近使用过的程序）列表，将程序进行排序，并结束最早的进程。

其实安卓的内存管理机制是这样的，如下：
1.系统会对进程的重要性进行评估，并将重要性以“oom_adj”这个数值表示出来，
赋予各个进程；（系统会根据“oom_adj”来判断需要结束哪些进程，一般来说，“oom_adj”的值越大，该进程被系统选中终止的可能就越高）

2.前台程序的“oom_adj”值为0，这意味着它不会被系统终止，
一旦它不可访问后，会获得个更高的“oom_adj”，我们推测“oom_adj”的值是根据软件在LRU列表中的位置所决定的；

3.Android不同于Linux，有一套自己独特的进程管理模块，这个模块有更强的可定制性，
可根据“oom_adj”值的范围来决定进程管理策略，比如可以设定“当内存小于X时，结束“oom_adj”大于Y的进程”。这给了进程管理脚本的编写以更多的选择。

Android将进程分为六大类：
1.前台进程（foreground）：目前正在屏幕上显示的进程和一些系统进程。
举例来说，Dialer Storage，Google Search等系统进程就是前台进程；
再举例来说，当你运行一个程序，如浏览器，当浏览器界面在前台显示时，浏览器属于前台进程（foreground）
但一旦你按home回到主界面，浏览器就变成了后台程序（background）。我们最不希望终止的进程就是前台进程。

2.可见进程（visible）：可见进程是一些不再前台，但用户依然可见的进程，
举个例来说：widget、输入法等，都属于visible。
这部分进程虽然不在前台，但与我们的使用也密切相关，
我们也不希望它们被终止（你肯定不希望时钟、天气，新闻等widget被终止，那它们将无法同步，你也不希望输入法被终止，否则你每次输入时都需要重新启动输入法）

3.次要服务（secondary server）：目前正在运行的一些服务（主要服务，如拨号等，是不可能被进程管理终止的，故这里只谈次要服务），

举例来说：谷歌企业套件，Gmail内部存储，联系人内部存储等。
这部分服务虽然属于次要服务，但很一些系统功能依然息息相关，我们时常需要用到它们，所以也太希望他们被终止

4.后台进程（hidden）：虽然作者用了hidden这个词，但实际即是后台进程（background）
就是我们通常意义上理解的启动后被切换到后台的进程，如浏览器，阅读器等。
当程序显示在屏幕上时，他所运行的进程即为前台进程（foreground），
一旦我们按home返回主界面（注意是按home，不是按back），程序就驻留在后台，成为后台进程（background）。
后台进程的管理策略有多种：有较为积极的方式，一旦程序到达后台立即终止，这种方式会提高程序的运行速度，但无法加速程序的再次启动；
也有较消极的方式，尽可能多的保留后台程序，虽然可能会影响到单个程序的运行速度，但在再次启动已启动的程序时，速度会有所提升。
这里就需要用户根据自己的使用习惯找到一个平衡点

5.内容供应节点（content provider）：没有程序实体，进提供内容供别的程序去用的，比如日历供应节点，邮件供应节点等。在终止进程时，这类程序应该有较高的优先权

6.空进程（empty）：没有任何东西在内运行的进程，有些程序，比如BTE，在程序退出后，
依然会在进程中驻留一个空进程，这个进程里没有任何数据在运行，作用往往是提高该程序下次的启动速度或者记录程序的一些历史信息。这部分进程无疑是应该最先终止的。
      简单来说，就是选择退出程序时，并不是完全退出程序，该程序仍然会在后台驻留一个进程，以便下次更快的打开。
      那什么时候完全关闭该程序呢？这取决于该程序的类型（就是上面讲的那几个类型）。
      系统会给每个类型的程序一个内存值阈（阀门），也就是说当运行内存低于某个值时，系统会自动按照打开的先后顺序来关闭该类型的程序。
       例如，当运存小于24MB时，系统才会自动关闭空进程这一类型的程序,释放出更多的内存来供新程序使用，已保证新开程序的正常运行。

       综上所述，我们不难看出，很多时候我们没必要过多的去关注系统的空闲内存（RAM）是多少，也没必要特意的去杀掉后台程序，因为系统会自动分配内存，以保证新程序的运行.以前也经常纠结刷了V4后运行内存突然就少了很多，自从明白这个问题，不用去纠结啦~
       当然，特殊情况除外，比如你马上就要开一个非常大的游戏，需要更多的内存，这个时候就可以手动杀掉一些后台程序，以保证游戏的流畅。还有就是在后台也偷流量又时常要用不能删的程序，一定要关
  这是借用其他论坛的好帖子。

由内存1的讲解我们知道，内存仅仅是一个存放指令和数据的地方，要完成计算功能需要将其读取到CPU内部。

然而CPU内部又包含很多个小零件，它是一个复杂的计算机部件。



上图中的运算单元相当于CPU的大脑功能，负责各种运算工作，而且每种运算工作都有对应的电路支持，速度很快。

寄存器（Register）是CPU内部一个非常小非常快速的存储部件，但是它的容量是有限的。我们经常说到的多少位的CPU其实指的就是寄存器的位数，对于32位的CPU，每个寄存器一般能存储32位（4个字节，一个字节是8位）的数据，对于64位的CPU每个寄存器一般能存储64位（8个字节）的数据。为了实现程序中复杂的功能，现在的CPU都内置了几十个甚至上百个寄存器，（嵌入式的功能单一，寄存器数量较少）。

寄存器在程序的执行过程中至关重要，不可或缺，它们可以用来完成数学运算、控制循环次数、控制程序的执行流程、标记CPU运行状态等，CPU就是用它来记录程序的运行状态，然后根据他的值再决定下一步的操作。例如，EIP（Extern Instruction Pointer ）寄存器的值是下一条指令的地址，CPU执行完当前指令后，会根据 EIP 的值找到下一条指令，改变 EIP 的值，就会改变程序的执行流程；CR3 寄存器保存着当前进程页目录的物理地址，切换进程就会改变 CR3 的值。

缓存：在CPU的内部设置一个缓存，是为了将使用频繁的数据暂时读取到缓存，当需要同一地址上的数据时，就不用再去访问内存，直接从缓存读取（对于不经常使用的数据依然从内存上读取，对于那些数据保留在缓存上，哪些数据不保留都有复杂的算法控制）。因为虽然内存的读取速度很快，但是同CPU比起来还是很慢，不在一个数量级上，这样每次从内存读取数据会严重拖慢CPU的运行速度，每次读取会造成CPU等待无事可做。

所以我们购买电脑时也会关注缓存的容量，一级缓存是32KB,二级缓存是256KB，三级缓存是8MB。缓存容量越大，CPU越厉害。

要想让CPU工作起来，是需要指令集的，我们编写的C代码最终也是会编译成一条条的CPU指令集

Apache有三中工作模式,分别是perfork、worker、event。

prefork模式（默认模式）要求稳定的时候使用

profork模式是进程、预派生的工作模式，用进程处理请求，所以比较容易消耗内存，但是稳定性好，某个进程出现问题不会影响到其他请求。预派发的方式，服务器启动时预先创建子进程，当有用户请求时，将直接使用已经创建好的子进程进行处理，可以减少创建子进程的时间，增加响应速度，预先创建多少个子进程由prefork的参数进行设置。
worker模式 访问量多的时候使用

worker模式使用多个子进程，每个子进程有多个线程、由于使用的是线程去处理请求，消耗内存小，适合高流量的请求，但是如果某个进程出现问题，那么这个进程下的线程都会出现问题，即稳定性不是很好。
event模式

event模式为了解决keep-alive保持长连接出现的一种工作模式，使用keep-alive长连接的时候，某个线程会一直被占用，即使中间没有请求，需要等到超时才会被释放，所以这个时候就出现了event的工作模式。在event工作模式中，会有一些专门的线程用来管理这些keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务器的线程，执行完毕后，又允许它释放。这增强了在高并发场景下的请求处理。另外，event模式是不支持用在https上的。

prefork与worker模式比较

prefork模式使用多个子进程，每个子进程只有一个线程，每个进程在某个确定的时间只能维持一个连接；

worker模式使用多个子进程，每个子进程有多个线程，每个线程在某个确定的时间只能维持一个连接，适用于高流量的HTTP服务器上；

总的来说，prefork方式速度要稍高于worker，但是prefork所需要的CPU和Memory资源也稍高于worker。