android实现原理,安卓框架原理

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

android消息推送原理是怎么样的

主要介绍其中的五种实现方式：短轮询、Comet、Flash XMLSocket、Server-sent、WebSocket

1、短轮询

指在特定的的时间间隔（如每10秒），由浏览器对服务器发出HTTP request，然后由服务器返回最新的数据给客户端的浏览器。浏览器做处理后进行显示。无论后端此时是否有新的消息产生，都会进行响应

2、Comet

包括了长轮询和长连接，长轮询是客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求；长连接是在页面中的iframe发送请求到服务端，服务端hold住请求并不断将需要返回前端的数据封装成调用javascript函数的形式响应到前端，前端不断收到响应并处理

3、Flash XMLSocket

在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的socket接口与服务器端的socket进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示

4、Server-sent

服务器推指的是HTML5规范中提供的服务端事件EventSource，浏览器在实现了该规范的前提下创建一个EventSource连接后，便可收到服务端的发送的消息，实现一个单向通信。客户端进行监听，并对响应的信息处理显示

5、WebSocket

WebSocket是HTML5下一种新的协议，是基于TCP的应用层协议，只需要一次连接，便可以实现全双工通信，客户端和服务端可以相互主动发送消息。客户端进行监听，并对响应的消息处理显示

针对自己系统的应用场景选择合适的推送方案才是合理的，因此最后简单说一下实现个性化推送的两种方式。第一种很简单，直接使用第三方实现的推送，无需复杂的开发运维，直接可以使用。第二种就是自己封装，可以选择如今较为火热的WebSocket来实现系统的推送。

关于第三方推送平台，极光推送，操作简单，稳定性高，送达率快

相关问答

Q1: Android主流视频播放及缓存实现原理调研

本文针对视频播放及缓存方案进行调研，对于Android端常用的视频播放器的缓存策略介绍及实现原理。

实现简单，逻辑易懂。

在播放器与视频源服务器之间加了一层代理服务器，截取视频播放器发送的请求，根据截取的请求，向网络服务器请求数据，然后写到本地。本地代理服务器从文件中读取数据并发送给播放器进行播放。

在第二次播放时，如果文件中有空洞，无论片段再小，也会保存到片段中，最后当配置数组为{0, length}的时候，length为视频长度大小，也会存到片段中。

Qzone的日均视频播放量破十亿，其中Android端的总播放量占比超过70%。所以Qzone的实现方案对我们来说很有借鉴意义。

优化主要从如下几个方面入手：

这里主要解决的问题是，之前单个的顺序存储方式无法对于播放空洞（非顺序播放场景，例如拖动、续播等）进行缓存，降低了缓存率和命中率。

H265是新一代视频编码标准，相比原有使用H264编码的视频，具有更高的压缩比，在画质近似的前提下，H265编码的视频文件体积只有H264的一半甚至更少，因此，播放H265编码的视频能极大减少带宽消耗。

具体编码相关内容，请看直播技术点之编解码基础（一）

Q2: 安卓手机的工作原理是什么

android基于Linux内核，很多系统也都基于Linux内核。但是android的特别之处除了开发上的特点以外，还有一个就是程序在运行时的行为和以往我接触到的程序运行机制有很大不同。在传统PC机或者其他一些手机上，用户对应用程序有绝对的掌控权，在应用程序的系统菜单上选择“退出”或者“关闭”之类的选项会直接杀死进程，而在android系统中不是这样的。在android中，应用程序的生命周期并不是由应用程序自身直接控制的，而是由系统，当系统需要释放内存来运行新进程或者保证某些后台进程和前端进程顺利执行的时候才会释放相应应用程序的资源，这个释放过程有一个重要性的层次。

android中进程的层次如下（重要性由高到低）：

1、前端进程。顾名思义，前端进程就是目前显示在屏幕上和用户交互的进程，在系统中前端进程数量很少，而这种进程是对用户体验的影响最大，只有系统的内存稀少到不足以维持和用户的基本交互时才会销毁前端进程。因此这种进程重要性是最高的。

2、可见进程。可见进程也拥有一个可视化的界面，只是目前不是最上层界面（最上层界面在前端进程里面），可见进程一般调用了OnPause()，可见进程比前端进程重要性低，但是在交互方面影响还是很大，因为用户可能随时切换过去，所以系统不会轻易销毁它。

3、服务进程。一个服务进程就是一个Service，它调用了startService，就是UNIX中说的守护进程，对用户不可见，但是保证了一些重要的事件被监听或者维持着某些状态，比如网络数据传输、后台音乐播放，这类进程在内存不足且为了保证前端交互的顺利进行的时候被销毁。

4、后台进程。这里叫后台进程可能会和一般意义上的后台进程混淆，要说明的是，android里的后台进程是调用了OnStop()的，可以理解成用户暂时没有和这个进程交互的愿望，所以这里后台进程有点“待销毁”的意思。

5、空进程。这是一种系统缓存机制，其实就是个进程的外壳，当有新进程创建的时候，这个空进程可以加快进程创建速度，当系统内存不足的时候，首先销毁空进程。

android中进程重要性层次

Q3: Android Binder机制，共享内存实现原理

Binder机制，共享内存实现原理

Android匿名共享内存是基于Linux共享内存的，都是在tmpfs文件系统上新建文件，并将其映射到不同的进程空间，从而达到共享内存的目的，只是，Android在Linux的基础上进行了改造，并借助Binder+fd文件描述符实现了共享内存的传递。

Q4: 什么是android运行原理

在了解android运行原理，我们必须先知道Java虚拟机的原理和内存分配机制。Java编译过的代码是一些class文件，通过Java VM的类解析器分析、效验后执行。执行代码的时候，首先解析Class，查找该类的方法、常量，这些对于常规情况下都编译成二进制的代码保存在jar文件中，java用的是反射原理，虽然编译的时间变短了，但是运行时候的效率就会变低了

如果看到这里你认为android 应用也运行在java VM中那就错了，手机的RAM相对于PC还小了很多，Java这样的内存大户语言在手机硬件设备有限的手机来说，必须要注意内存问题，这样才能提高程序的性能

所以 Google优化Java VM虚拟机，所以的Dalvik Java VM产生了

具体介绍一下Java VN 和 Dalvik虚拟机的区别

Q5: Android N 四大组件的工作原理

本文侧重讲解android N 系统中四大组件的工作原理，不同系统原理略有差别。通过分析四大组件的工作流程加深对Android Framework的理解，也为插件化开发打下基础。

Activity

展示一个界面并和用户交互，它扮演的是一个前台界面的角色。

Service

计算型组件，用于后台执行一系列计算任务，工作在主线程，耗时操作需要另起线程，分为启动状态和绑定状态。

BroadcastReceiver

消息型组件，主要用于不同组件或者不同应用之间的消息传递，它工作在系统内部，不适合执行耗时操作，操作超过5s，会出现ANR。

ContentProvider

数据共享型组件，用于向其他组件或者应用共享数据，主要执行CURD操作。

我们启动一个activity有两种方法，

第一种（Activity直接启动方式）：

Intent intent = new Intent(this, MainActivity.class);

startActivity(intent);

第二种（Context启动方式）

Intent intent = new Intent(this, MainActivity.class);

getApplicationContext().startActivity(intent);

不同的启动方式Activity的工作流程有点差别。

两种启动都会调用到Instrumentation类中的execStartActivity的方法，系统最终是通过ActivityThread中的performLaunchActivity完成Activity的创建和启动。

performLaunchActivity方法主要完成以下工作：

1、通过ActivityClientRecord对象获取启动activity的组件信息

2、通过mInstrumentation对象的newActivity方法调用classloader完成activity的创建

3、通过r.packageInfo(LoadedApk 对象)的makeApplication方法尝试创建Application对象

4、创建ContextImpl对象并调用Activity的attach方法完成一些数据的初始化

5、调用Activity的onCreate方法

在Activity启动的过程中，App进程会频繁地与AMS进程进行通信：

App进程会委托AMS进程完成Activity生命周期的管理以及任务栈的管理；这个通信过程AMS是Server端，App进程通过持有AMS的client代理IActivityManager完成通信过程；

AMS进程完成生命周期管理以及任务栈管理后，会把控制权交给App进程，让App进程完成Activity类对象的创建，以及生命周期回调；这个通信过程也是通过Binder完成的，App所在server端的Binder对象存在于ActivityThread的内部类ApplicationThread；AMS所在client通过持有IApplicationThread的代理对象完成对于App进程的通信。

Service有两种启动方式，startService()和bindService()，两种状态可以并存:

startService流程

bindService流程

BroadcastReceiver的工作过程主要包括广播的注册、发送和接收:

动态注册过程：

发送过程

静态注册是由PackageManagerService（PMS）在应用安装的时候完成整个注册过程的，除广播以外，其他三大组件也都是在应用安装时由PMS解析并注册的。

每个进程的入口都是ActivityThead.main()，App的启动流程如下：

从源码中可以看出：

应用启动的入口为ActivityThread的main方法，main方法会创建ActivityThread实例并创建主线程消息队列。

attach方法中远程调用AMS的attachApplication方法，并提供ApplicationThread用于和AMS的通信。

attachApplication方法会通过bindApplication方法和H来调回ActivityThread的handleBindApplication，这个方法会先创建Application，再加载ContentProvider，然后才会回调Application的onCreate方法。