写在前面的话：在一个公司安逸了两年，突然要准备找新的工作，心里面慌的一P，感觉啥都还给Android了，好在还认识几个字，只能慢慢的去整理输出了，倒逼自己慢慢的养成写记录和总结的习惯，这由何尝不是一件好事？初来乍到，难免出现各种错误，请各位看官指教！但且看来！

  下面就说说Android中的基础中的基础，任哪位Android人多会知道的知识，作为大师兄在简书的开篇之作吧！

---

Android核心知识-1

1.底层原理

 Android 操作系统是一个多用户 Linux 操作系统，每个应用都是一个用户。

· 操作系统一般会给每个应用分配一个唯一的Linux 用户 ID，这个 ID 对应用是不可见的。但有些情况下两个应用可以共享同一个 Linux 用户 ID，此时他们可以访问彼此的文件，甚至还可以运行在同一个 Linux 进程中，共享同一个虚拟机。但两个应用的签名必须是一样的。【这应该也是Android的应用之间能够通讯的最底层的原因了】

·每个进程都有自己的虚拟机，一般每个应用都运行在自己的Linux 进程中。

---

2.应用组件

·  应用没有唯一的入口，没有main()函数，因为应用是由多个组件拼凑在一起的，每个组件都是系统或者用户进入应用的入口，组件之间既可以是相互独立的，也可以是相互依赖的。系统和其它应用在被允许的情况下可以启动/激活一个应用的任意一个组件。

咳咳，大师兄要装B了，且看大师兄粗糙的解读吧！【大师兄解读:为什么各个组件之间可以通讯，底层原理是一个很重要的原因，还有就是Android应用的各个机体之间的组成了，它没有谁启动谁的主次关系，也没有谁非要依赖谁的关系，它们是独立的，因此可以独立存在，当需要完成一些特殊的功能，比如可以利用Service来完成后台的一些耗时操作。这些从另外一个侧面说明了，在android的生态中，原本就是支持组件化的，这是android存在的意义吧。组件之间各自协作，每一个组件存在的意义不一样，对于一个完整的APP来说，它们的联合组成了APP的整体。】

·  说到组件，就不得不说这几种组件了，:Activity，Service，BroadcastReceiver和ContentProvider。且往下看!

Activity

(1)Activity表示一个新的用户界面，只能由系统进行创建和销毁，应用只能监听到一些生命周期回调，这些回调通常也被叫作生命周期方法.

【大师兄解读:如果这么说，Activity只能由系统来创建，那我们平时在开发中相当于是自定义Activity了？这类似于我们自定义的View都要继承系统提供的原生View？我们“创建的Activity”，只是通过覆写一些方法来调用不同的生命周期方法，Activity的创建和销毁，都是在各自的生命周期方法中，而不能由开发者来自定义一个不依赖生命周期的方法，来完成Activity的创建和销毁？而且在开发过程中，为了减轻Activity的负担，我们可以将Activity相关的生命周期方法，通过抽象提取，重新组合，方法管理Activity的销毁和创建过程，但从本质上说，还是无法改变Activity由系统来创建和销毁的“宿命”了!】

(2)Activity的名字一旦确定好就不要再更改了，否则可能会引发一系列问题.

【大师兄解读:这个真没听说过，这里的Activity的名字不能再更改，应该不是在开发的过程中吧？否则作为Androider，还不痛苦死，要修改名字，还得推到了重来！做着做着就有凉凉的感觉！】

Service

Service表示一个后台服务，Service可以是独立的，可以在应用退出后继续运行【这个在消息推送中是个很明显的例证了，除非用户手动杀死了Service】。也可以绑定到其他进程或Activity，表示其他进程想使用这个Service，像输入法、动态壁纸、屏保等系统功能都是以Service的形式存在的，在需要运行的时候进行绑定。

大部分情况下，更建议使用JobScheduler，因为JobScheduler和Doze API 配合下一般会比简单使用 Service更省电。

【大师兄解读我等菜鸡，还是第一次听说这个叫JobScheduler的东东，好在有网络的度娘，链接就是某位大佬关于JobScheduler的介绍，真是不看不知道自己的孤陋寡闻了。https://www.jianshu.com/p/aa957774a965，原来JobScheduler是为了提供应用的效率，唉，找不到好的辞藻来形容了，感觉是首次写情书一样，无法恰如其分的表达自己对女神的矮了。比如设备在空闲状态, 并且使用wifi时, 自动下载新的Apk，这个时候，利用JobScheduler就是比较科学的玩法了，什么定义一个广播，在广播里启动Service，都没有它高大上。】

BroadcastReceiver

BroadcastReceiver是一个事件传递的组件，通过它应用可以响应系统范围的广播通知。系统的包管理器会在安装应用时将应用中的静态广播接收器注册好，所以即使应用没在运行，系统也能把事件传递到该组件。

通过BroadcastReceiver可以实现进程间通信。【大师兄解说:至今听到进程间通讯几个字，都觉得好可怕，还没这么玩过!又暴露了我菜鸡的本质!】

ContentProvider

ContentProvider是在多个应用间共享数据的组件，如果应用的一些数据想要被其它应用使用，必须通过ContentPrivider进行管理，不过应用的私有数据也可以通过ContentProvider进行管理，主要还是因为ContentProvider提供了共享数据的抽象，使用者不需要知道数据究竟是以文件形式还是数据库等其他形式存储的，只需要通过ContentProvider提供的统一的API进行数据的增删改查即可。同时ContentProvider还提供了安全环境，可以根据需要方便地控制数据的访问权限，不需要手动控制文件权限或数据库权限.

【大师兄解读:来来，感觉到了充分发挥小学语文考试中就有的必考题了--提炼中心句。从这一段中，对于ContentProvider的好处大致是这样的：第一，它是为了应用间通讯而存在的，共享数据，不就是通讯的一种方式吗？哈哈，被自己的“强词夺理”给折服了!第二，它不用考虑共享的数据类型，因为它有统一的API，你说爽不爽，什么都想到了，更重要的是，通过ContentProvider来失效共享数据，还很安全，不怕被一些残忍的黑科技来“偷”数据了（什么偷，根本就是抢，好不？这是违法的！！！），还有一个点，任凭系统是什么版本，都不用担心权限的问题，权限都被“系统”配置好了！】

为了安全，也为了方便，一般需要通过ContentResolver操作ContentProvider。

通过ContentProvider可以实现进程间通信。

以上总结的初始蓝本，来自某金，感谢大佬的默默付出，大佬的链接如下：

https://juejin.im/post/5c46db4ae51d4503834d8227！

初来乍到，多多指教!