简单介绍:Android四大核心组件指的是 Activity、Service、Content Provider、BroadCast Receiver,核心组件都是由 Android系统进行管理和维护的,一般都要在清单文件中进行注册或者在代码中动态注册。
活动(activity):用于表现功能; 服务(service):后台运行服务,不提供界面呈现; 内容提供者(Content Provider):支持多个应用中存储和读取数据; 广播接受者(Broadcast Receive):用于接收广播。
概念:在android中,Activity相当于一个页面,可以在 Activity中添加 Button、CheckBox 等控件,一个android程序有多个Activity组成。 // Activity 之间通过 Intent 进行通信;直接通过 Bundle 对象来传递
概念:Service(服务)是安卓中的四大组件之一,它通常用作在后台处理耗时的逻辑,与 Activity 一样,它存在自己的生命周期,也需要在 AndroidManifest.xml 配置相关信息。开发人员需要在应用程序配置文件中声明全部的 service,使用 < service>< /service> 标签。 Service 通常位于后台运行,它一般不需要与用户交互,因此 Service 组件没有图形用户界面。Service 组件需要继承Service 基类。Service 组件通常用于为其他组件提供后台服务或监控其他组件的运行状态。
定义与作用:Service(服务)是一个没有用户界面的专门在后台处理耗时任务的 Android 组件,它没有UI。它有两种启动方式,startService和bindService。其他应用组件能够启动 Service,并且当用户切换到另外的应用场景,Service将持续在后台运行。另外,一个组件能够绑定到一个service与之交互(IPC机制),例如,一个service可能会处理网络操作,播放音乐,操作文件I/O或者与内容提供者(content provider)交互,所有这些活动都是在后台进行。 Service 还有一个作用就是提升进程(每个应用都是一个进程)的优先级,进程的优先级指的是在 Android 系统中,会把正在运行的应用确定一个优先级,当内存空间不足时,系统会根据进程的优先级清理掉一部分进程占用的内存空间,以获得足够的内存空间以供新启用的应用运行。 详细的进程优先级划分如下:
介绍:Content Provider是 android 四大组件之一的内容提供器,它主要的作用就是将程序的内部的数据和外部进行共享,为数据提供外部访问接口,被访问的数据主要以数据库的形式存在,而且还可以选择共享哪一部分的数据。这样一来,对于程序当中的隐私数据可以不共享,从而更加安全。Content Provider 是 android中 一种跨程序共享数据的重要组件
四大基本组件都需要注册才能使用,每个 Activity、service、Content Provider 都需要在 AndroidManifest 文件中进行配置。AndroidManifest 文件中未进行声明的 activity、服务 以及 内容提供者 将不为系统所见,从而也就不可用。而 broadcast receiver 广播接收者的注册分静态注册(在AndroidManifest文件中进行配置)和通过代码动态创建并以调用Context.registerReceiver()的方式注册至系统。需要注意的是在AndroidManifest文件中进行配置的广播接收者会随系统的启动而一直处于活跃状态,只要接收到感兴趣的广播就会触发(即使程序未运行)。
作用:Content Provider中文意思是内容提供者,Content Provider可以将应用程序自身的数据对外(对其它应用程序)共享,使得其它应用可以对自身的数据进行增、删、改、查操作。
// 使用系统的 Content Provider: Android 系统使用了许多 Content Provider,将系统中的绝大部分常规数据进行对外共享,系统的 ContentProvider 有很多,例如:通讯录、通话记录、短信、相册、歌曲、视频、日历等等,一般这些数据都存放于一个个的数据库中。同时这些数据一般都需要和第三方的 app 进行共享数据。既然是使用系统的,那么 Content Provider的具体实现就不需要我们担心了,使用内容提供者的步骤如下: 1、获取 Content Resolver 实例 2、确定 Uri 的内容,并解析为具体的 Uri 实例 3、通过 Content Resolver 实例来调用相应的方法,传递相应的参数,但是第一个参数总是 Uri,它制定了我们要操作的数据的具体地址
// 自定义 ContentProvider: 系统的 Content Provider在与我们交互的时候,只接受了一个 Uri 的参数,然后根据我们的操作返回给我们结果。系统到底是如何根据一个 Uri 就能够提供给我们准确的结果呢?只有自己亲自实现一个看看了。 和之前提到的一样,想重新自定义自己程序中的四大组件,就必须重新实现一个类,重写这个类中的抽象方法,在清单文件中注册,最后才能够正常使用。
概述: Broadcast Receiver( 广播接收者 )顾名思义就是用来接收来自系统和应用中的广播 的 系统组件。广播是一种一对多的通信方式,即存在1个发送方,若干个接收方。在 Android 系统中,广播体现在方方面面,例如:当开机完成后系统会产生一条广播,接收到这条广播就能实现开机启动服务的功能;当网络状态改变时系统会产生一条广播,接收到这条广播就能及时地做出提示和保存数据等操作;当电池电量改变时,系统会产生一条广播,接收到这条广播就能在电量低时告知用户及时保存进度,等等。把这种数据的传递方式的机制称之为 “广播” 。Android 系统会在特定的情景下发出各种广播,例如开机、锁屏了、电量不足了、正在充电了、呼出电话了、被呼叫了…… // android广播分为两个角色:发送者和接收者
广播接收者的注册有两种方法,分别是AndroidManifest文件中进行静态注册和程序动态注册。
总结:
有序广播的接收者们的优先级用于确定接收的先后顺序,优先级越高的接收者,将更优先接收到广播,反之,则更靠后接收到广播。
在Android开发中,不管是插件化还是组件化,都是基于Android系统的类加载器ClassLoader来设计的。只不过Android平台上虚拟机运行的是Dex字节码,一种对class文件优化的产物,传统Class文件是一个Java源码文件会生成一个.class文件,而Android是把所有Class文件进行合并、优化,然后再生成一个最终的class.dex,目的是把不同class文件重复的东西只需保留一份,在早期的Android应用开发中,如果不对Android应用进行分dex处理,那么最后一个应用的apk只会有一个dex文件。
Android中常用的类加载器有两种,DexClassLoader和PathClassLoader,它们都继承于BaseDexClassLoader。区别在于调用父类构造器时,DexClassLoader多传了一个optimizedDirectory参数,这个目录必须是内部存储路径,用来缓存系统创建的Dex文件。而PathClassLoader该参数为null,只能加载内部存储目录的Dex文件。所以我们可以用DexClassLoader去加载外部的apk文件,这也是很多插件化技术的基础。
从小到上就是:linux,kernel,lib,dalvik vm,application,framework, app
帧动画:指通过指定每一帧的图片和播放时间,有序的进行播放而形成动画效果,比如想听的律动条。
视图动画(补间动画):指通过指定View的初始状态、变化时间、方式,通过一系列的算法去进行图形变换,从而形成动画效果,主要有Alpha、Scale、Translate、Rotate四种效果。注意:只是在视图层实现了动画效果,并没有真正改变View的属性,比如滑动列表,改变标题栏的透明度。
属性动画:在Android3.0的时候才支持,通过不断的改变View的属性,不断的重绘而形成动画效果。相比于视图动画,View的属性是真正改变了。比如view的旋转,放大,缩小。 通过变化属性来达到动画的效果,性能略差,支持点击等事件。android 3.0
Gif动画:原理和帧动画差不多,是canvas画出来。
// 内存溢出: out of memory:是指程序在申请内存时,没有足够的内存空间供其使用,出现out of memory;比如申请了一个integer,但给它存了long才能存下的数,那就是内存溢出。内存溢出通俗的讲就是内存不够用。 // 内存泄露: memory leak:是指程序在申请内存后,无法释放已申请的内存空间,一次内存泄露危害可以忽略,但内存泄露堆积后果很严重,无论多少内存,迟早会被占光 // 内存泄露检测工具 → LeakCanary
// Android 跨进程通信,像intent,contentProvider,广播,service都可以跨进程通信。 1、Files 文件系统(包括内存映射) 2、Sockets 3、Pipes 管道 4、共享内存 5、Intents, ContentProviders, Messenger 6、Binder
intent:这种跨进程方式并不是访问内存的形式,它需要传递一个uri,比如说打电话。 contentProvider:这种形式,是使用数据共享的形式进行数据共享。 service:远程服务,aidl 广播
// Android中为什么子线程不能更新UI? viewRootImpl对象是在Activity中的onResume方法执行完成之后,View变得可见时才创建的,之前的操作是没有进行线程检查的,所以没有报错。但是ViewRootImpl创建之后,由于进行了checkThread操作,所以就不能在子线程更改UI了 当访问 UI 时,ViewRootImpl 会调用 checkThread方法去检查当前访问 UI 的线程是否为创建 UI 的那个线程,如果不是。则会抛出异常
// 如果不做这个校验,是不是我也可以正常在子线程更新UI? 按理来说,这样是可以的
// 但是google为什么要这样去设计呢 1.如果在不同的线程去控制用一个控件,由于网络延时或者大量耗时操作,会使UI绘制错乱,出了问题也很难去排查到底是哪个线程更新时出了问题; 2.主线程负责更新,子线程负责耗时操作,能够大大提高响应效率 3.UI线程非安全线程,多线程进行并发访问有可能会导致内存溢出,降低硬件使用寿命;且非线程安全不能加Lock线程锁,否则会阻塞其他线程对View的访问,效率就会变得低下!
// ViewRootImp是在onActivityCreated方法后面创建的吗? 1、ViewRootImpl是在Activity的onResume()方法后面创建出来的,所以在onResume之前的UI更新可以在子线程操作而不报错,因为这个时候ViewRootImpl还没有创建,没有执行checkThread()方法。 2、安卓系统中,操作viwe对象没有加锁,所以如果在子线程中更新UI,会出现多线程并发的问题,导致页面展示异常。
// 为什么一定需要checkThread呢? 因为UI控件不是线程安全的
// 那为什么不加锁呢? 一是加锁会让UI访问变得复杂; 二是加锁会降低UI访问效率,会阻塞一些线程访问UI。 所以干脆使用单线程模型处理UI操作,使用时用Handler切换即可
// 为什么一开始在Activity的onCreate方法中创建一个子线程访问UI,程序还是正常能跑起来呢? 因为ViewRootImpl 的创建在 onResume 方法回调之后,而我们一开篇是在 onCreate 方法中创建了子线程并访问 UI,在那个时刻,ViewRootImpl 还没有创建,我们在因此 ViewRootImpl#checkThread 没有被调用到,也就是说,检测当前线程是否是创建的 UI 那个线程 的逻辑没有执行到,所以程序没有崩溃一样能跑起来。而之后修改了程序,让线程休眠了 3000 毫秒后,程序就崩了。很明显 3000 毫秒后 ViewRootImpl 已经创建了,可以执行 checkThread 方法检查当前线程
// Android中子线程真的不能更新UI吗? 任何线程都可以更新自己创建的UI,但是需要满足各自对应的条件
// 保证上述条件1成立,不就可以避免checkThread时候抛出异常了吗?为什么还需要开启消息循坏? 条件 1 可以避免检查异常,但是无法保证 UI 可以被绘制出来。 条件 2 可以让更新的 UI 效果呈现出来。 注:WindowManger的addView 最终会调用WindowManageGlobal的addView方法,进而触发ViewRootImpl的setView 方法,该方法内部会调用ViewRootImpl的requestLayout 方法。根据 UI 绘制原理,下一步就是 scheduleTraversals了,该方法会往消息队列中插入一条消息屏障,然后调用 Choreographer的postCallback 方法,往 looper 中插入一条异步的 MSG_DO_SCHEDULE_CALLBACK 消息。等待垂直同步信号回来之后执行
// 使用子线程更新 UI 有实际应用场景吗? Android 中的 SurfaceView 通常会通过一个子线程来进行页面的刷新。如果我们的自定义 View 需要频繁刷新,或者刷新时数据处理量比较大,那么可以考虑使用 SurfaceView 来取代 View
文件的系统权限是由linux系统规定的,只读,读写等。 运行时权限是对于某个系统上的app的访问权限,允许,拒绝,询问。这个可以防止非法的程序访问敏感的信息。
// 前台进程
// 可见进程:
// service进程: 当前开启startSerice()启动一个service服务就可以认为进程是一个服务进程。
// 后台进程 activity的onStop()被调用,但是onDestroy()没有调用的状态。该进程属于后台进程。
// 空进程: 改进程没有任何运行的数据了,且保留在内存空间,并没有被系统killed,属于空进程。该进程很容易被杀死。
// Davik 进程:
// Linux 进程:
黑色保活:不同的app进程,用广播相互唤醒(包括利用系统提供的广播进行唤醒) 白色保活:启动前台Service 灰色保活:利用系统的漏洞启动前台Service
所谓黑色保活,就是利用不同的app进程使用广播来进行相互唤醒
// 白色保活 白色保活手段非常简单,就是调用系统api启动一个前台的Service进程,这样会在系统的通知栏生成一个Notification,用来让用户知道有这样一个app在运行着
// 灰色保活 灰色保活,这种保活手段是应用范围最广泛。它是利用系统的漏洞来启动一个前台的Service进程,与普通的启动方式区别在于,它不会在系统通知栏处出现一个Notification,看起来就如同运行着一个后台Service进程一样。这样做带来的好处就是,用户无法察觉到你运行着一个前台进程(因为看不到Notification),但你的进程优先级又是高于普通后台进程的。那么如何利用系统的漏洞呢,大致的实现思路和代码如下: 思路一:API < 18,启动前台Service时直接传入new Notification(); 思路二:API >= 18,同时启动两个id相同的前台Service,然后再将后启动的Service做stop处理
它是Android提供的用来存储一些简单配置信息的一种机制,采用了XML格式将数据存储到设备中。只能在同一个包内使用,不能在不同的包之间使用。
文件存储方式是一种较常用的方法,在Android中读取/写入文件的方法,与Java中实现I/O的程序是完全一样的,提供了openFileInput()和openFileOutput()方法来读取设备上的文件。
SQLite是Android所带的一个标准的数据库,它支持SQL语句,它是一个轻量级的嵌入式数据库
主要用于应用程序之间进行数据交换,从而能够让其他的应用保存或读取此Content Provider的各种数据类型
通过网络上提供给我们的存储空间来上传(存储)和下载(获取)我们存储在网络空间中的数据信息