itbird的专栏

LiveData使用观察者设计模式，视图作为观察者，数据作为被观察者，视图对于进行数据的观察，当数据发生变化时，可以主动通知视图，这本身是一个很简单类似OnClickListener的简单原理，但是难点在于，如何解决LiveData中由于需要实现通知，拥有了视图的引用，从而导致可能存在的内存泄露问题。

LiveData 从实践到原理，源码阅读

首先是LiveData数据结构定义，经过猜想，我们知道这块两个东西最重要，一个是数据容器的设定，一个是内部存储数据结构，我们这里通过泛型就可以实现/*** 自定义LiveData实现/*** 内部存储的数据结构*/ T data;/*** 构造函数} /*** set方法} /*** 直接在当前线程调用//todo 子线程执行的逻辑 } public T getValue() {} /*** 检测是否为主线程if(!} } }

五一假期，第二节课，Jetpack组件LiveData从实践、源码阅读、原理解读几方面，我们一起来学习、探索、总结一下。

ViewModel使用以及源码分析ViewModel 、 onSaveInstanceState、持久化数据的使用场景总结ViewModel 与 onSaveInstanceState的异同对比

onSaveInstanceState与onRetainNonConfigurationInstance 的对比分析SaveStateHandle使用DemoSaveStateHandle源码原理分析

ViewModel的实现机制是，在内存中存储了相关的ViewModel的数据，借助 activity的相关周期方法onRetainNonConfigurationInstance 与 getLastNonConfigurationInstance的自动调用，实现了 ViewModel数据的存储和恢复。

五一期间，我们来一起学习总结一下Jetpack的ViewModel组件，从使用、源码、经验来总结分析。老办法，在研究一个框架之前，先提出一些自己可以想到的问题，带着问题，有目标的去阅读源码，收货相信更多、更明确一些。ViewModel 是做什么的？ViewModel 如何使用？ViewModel 生命周期是怎么样的？ViewModel 数据是如何保存的？是通过文件吗？类似于SP的做法？

在源码探索的过程中，大家是否发现了这样一个类。/**/**} }有小伙伴，是否看着很有趣又亲切呢？有趣在于这里即对一个对象的行为进行了接口抽象定义，同时也对这个对象的创建工厂，进行了工厂定义亲切在于，不管是去年我们在设计模式精讲系列课程里，还是在okhttp的源码探索，以及rxjava的源码探索中，发现这些第三方框架，几乎都使用了这样的封装方式，即：先将行为抽象，使外界面向接口编程，其次再将对象创建也抽象，使用工厂模式，进行对象创建。

Room是对SQLite数据库的抽象，它提供了很多便利的API和注解等，简化了使用者使用数据库的方式。同时，Room提供了 LiveData、Rxjava的结合使用的组件，更加方便了开发使用。使用Room减少了很多sql模板代码的编写，整体使用上简单、明了了很多，尤其是结合Rxjava，可以直接实现主子线程的切换、流式业务代码操作的编写。

本文，我们通过一个简单的sqlite应用实例，引入了Room，知道了Room使用的便捷和好处。然后用Room的方式，重新实现了应用实例中的场景，在这个过程中，我们结合自己已有的知识体系，从使用代码入手，对Room的实现原理，进行了猜想和简单的验证。Room是否是这样做的？下一章节，我们一边阅读源码，一边去看一下。

上面的调用，从worker的提交，到job的具体执行，绕了一圈，我们画个图梳理一下。SerialExecutor的知识应用，当我们想要控制一个任务队列中的任务，串行执行时，可以使用这样的实现方案，但是，我们需要知道，这样有一个坏处就是，达不到并发的目的了。Provider可以用于初始化init函数的调用，当我们在设计一些框架时，为了简化使用者的调用步骤，可以使用Provider的方案。

本文，我们对于WorkManager的初始化、任务入队的源码进行了深入的解读，学到了WorkManager的初始化，和MMKV、VirtualAPK、LeakCanary这些第三方框架源码一样，都使用了Provider初始化的设计方案，发现这真是一个好处，就是使用了manifest注册时，PackageParse会解析其中的四大组件，然后在AMS中进行信息初始化，那么此时Provider就会进行初始化，所以使用了这个特性。

本文，我们对Jetpack的调度任务组件WorkManager ，由使用入手，对其源码进行深入学习、总结一下。

按照标准观察者模式设计思想，首先要定义通知接口看到这里，lifecycle源码，基本都已讲完。我们来总结一下1）lifecycle大体是，通过观察者设计模式，实现activity、fragment等生命周期的具体感知、通知的2）lifecycle实现方案上，对于API>=29采用的最新的API ActivityLifecycleCallbacks 来感知所有的生命周期。

本文，我们首先一个简单的实际代码例子入手，开始说明lifecycle被引入的背景，进而我们使用lifecycle实现了简单的需求，篇幅所限，lifecycle的自我实现以及源码探索，我们下篇文章继续探索。

V4、V7、androidX，是Google的兼容包的一个进化史，androidX是最终的（目前的），最优整合兼容包Jetpack是一系列组件组成的一个套件，是用于帮助开发者遵循最佳做法、减少样板代码、减少适配代码、减少重复代码，从而让android开发者快速、高效率编码的一个工具盒，对于工具盒中的每项功能，你都可以单独拿起来使用（也就是在gradle中，可以单独引用每个组件）。jetpack历史

1）JobIntentService在android8.0以上，是通过JSS+JSC实现的后台任务执行管理，任务会交由AsyncTask后台执行；在android8.0以上，是通过PowerManager来获取了wakeup锁，实现了后台任务的执行管理，任务同样也会交由AsyncTask后台执行；2）JobIntentService的任务后台执行，是放置于线程池的，所以是多线程并发执行；

本文，我们主要对IntentService的替代API接口JobScheduler，从简单的使用入手，然后逐步对内部的实现源码细节进行分析。JobSchedulerService是一个关键的系统服务，在android系统启动时，作为核心服务已经启动。我们通过JobScheduler提交的JobInfo，在JobSchedulerService中，会转换为JobStatus，然后交由各个状态监控器StateController去监控。

本文，从Job任务的创建，到如何与JSC（JobServiceCotext）关联，到具体任务的绑定、执行进行了源码探索，相信大家到现在为止，对于JobScheduler的庐山真面目，脑海中已经有了些许自己的轮廓。但是，我们也知道，目前为止，仅仅是任务的创建、任务的执行原理我们了解、学习到了，但是任务何时执行的？约束条件如何监控job的？这些还未讲到。别着急，下一节，我们一起继续探索源码，解析其中的奥秘。

Android源码面试宝典之JobScheduler从使用到原理分析（二）【JSS的启动】我们从使用代码入手，通过阅读JobScheduler源码，来开始对于其原理，进行深入解读。

我们先看一下google官方，对于这个API框架有哪些接口和类？可以看到主要有JobInfo、JobScheduler，其中 JobInfo有内部类Builder，那么看这个设计，应该是可以通过建造者模式，去外部构建一个 JobInfo实体对象，然后我们看到JobScheduler有schedule方法，那么应该就是把这个JobInfo交由JobScheduler去执行即可。

MMAP原理MMKV原理mmkv源码

去年，我们写过一篇文章，对于android原生提供的key-value存储API SharePreference，进行了，进行了深入的探索、总结。但是之前的文章，我们仅仅指出了问题，没有给大家提供解决方案，也就是说，SharePreference既然不建议使用，那么我应该使用啥？mmkv原理mmkv使用

Retrofit+Rxjava大家知道如何使用吗？添加CallAdapterFactory支持

Retrofit实践系列课程到现在，大家是否发现还有两个关键问题，或者准确一点，应该描述为两个功能并未实现一个是Gson数据的解析，我们是直接在返回里面使用了Gson解析的，并未使用到最初框架设计的时候，加入的ConvertFactoryRetrofitCall中数据的解析，其实包含两方面，一方面是gson的转换，一方面是code的处理，这部分，明显不应该写死在这里，因为服务端可能返回xml数据、gson数据，另外code的不同，你封装一个框架是给其他人去用的，code怎么能写死在解析里面呢？

小编目前从事的系统定制类工作，有客户提出了，需要后台“静默安装”他们的app，也就是悄无声息的安装，而且特别强调，不可以跳出任何安装引导页面，他们的app下载完成之后，后台调用公开的android install代码，系统就后台完成安装，安装完成之后，重新打开应用就可以。估计大家即使一直从事的是单纯的app开发，那么也稍微接触过此类需求，比如前两年特别火的，微信抢红包插件。好了，背景先交代到这里，我们由浅入深的，去了解一下静默安装的方案有哪些，都应该如何去实现？

APK签名打包原理，消息摘要，加密

本文差不多讲完了，我们整体是对照的这个图，同时配合自己的原始目标（几个问题），来一步一步的探索打包的具体过程的。大家不妨阅读末尾，对照的这个图，脑海中回顾一下，通过本文学到的知识点。binder机制的原理aidl、aapt分别的作用R.java和resource.arsc文件的关系AssetManager与 Resources关系打包的过程。

本节到这里就基本结束了，我们回顾一下。解决retrofit 多baseUrl的动态解决方案就是RetrofitManager作为单例类，使用map保存baseurl-retrofit的一一对应保存为了解决需要记忆baseurl-retrofit一一对应关系的问题，我们引入自定义注解BaseUrl，给需要的接口类，直接添加这个注解。

篇幅所限，本文我们先就其中四个问题进行了解决，过程中，也对之前实现的诸多代码进行了优化。Create接口，使用泛型，面向所有请求接口注解的处理封装到ServiceMerthod方法中Call对象的封装和转换返回数据不规范的解决方案。

由上一节，我们基于retrofit使用代码入手，搭建了整体的框架，但是为了简化，一步一步来，我们首先使用自己搭建的retrofit实现基本的请求和返回，那么我们暂时忽略convertfactory和callback的转换，本节我们先直接使用okhttp的call，直接返回okhttp的response，实现基本的retrofit核心功能代码，具体功能点有接口动态代理创建对象注解的处理，拼接url和请求参数基于okhttp实现基本的请求本章，我们一起来基于上节搭建的Retrofit框架，实现核

我们运行一下，不出所料，肯定会崩溃的。因为在上面的代码编写中，我们只是搭建框架，并未填充任何实现，有几件重要的事情，都没有去做retrofit的builder模式创建中，okhttp并未使用convertFactroy接口并未填充实现retrofit.create方法我们只是创建一个空壳，并未去真正实现注解并未处理，因为我们最简单的，要处理注解，从而生成请求的完整url返回的数据封装处理，也就是从okhttp的call，到自己封装的call对象的转换，并未做处理。

工欲善其事必先利其器，我们开始具体的retrofit源码探索与实践之前，需要找一个免费的测试api接口，因为我们知道，不管使用okhttp，还是retrofit，你都需要一个api测试服务器。

从使用入手，到每个关键步骤的源码实现原理猜测、结合实际retrofit源码验证，大家是否已经基本了解的retrofit的整体框架和源码。接下来几节课，我们开始自我实现一个retrofit框架，还是那句老话，这里小编明确，去使用自己已知的知识，结合我们之前讲过的设计模式相关知识，实现并不是关键，毕竟已有的框架、已有的知识总结一大堆，我们并非是要花费时间重复造轮子，但是借助这个自我实践过程，去进行自我的知识沉淀、累加，进而吃透相应框架，这才是最关键的。

在android 6.0中也同时添加了权限组的概念，若用户同意组内的某一个权限，那么系统默认app可以使用组内的所有权限，无需再次申请。我们一般申请权限，是怎么做的呢？先建一个权限判断处理的类在相应的activity中（Note：为什么我这里没有包含fragment呢？大家先想一下，后续我们揭晓），做如下权限申请这个使用上有两处不方便有了这个前提，我们看一下RxPermissions使用的代码是否特别简单呢？是否解决了上面我们所说的两个问题呢？第二个问题肯定是解决了，第一个问题，是否已经解决了呢？我

总体来说， Rxjava的常见操作符分为创建操作符、转换操作符、过滤操作符、合并操作符、 条件操作符、功能操作符.我们常见的创建型操作符有 create、 just 、fromArray、interval、range 、timer。1.2 源码我们看一下create函数源码看到包装为了ObservableCreate对象，继续看一下source是上游的observable，也就是我们刚开始调用函数的crreate中创建的对象所以这里绕回到开头，也就是走到订阅流的 ObservableOnSubsc

实现线程切换功能之前，通过一个实例，我们先看一下rxjava线程切换功能的使用代码。**需求：**我们自己在实现一个图片下载然后展示到imageview上的需求的时候，不可避免的，肯定会将下载图片的网络操作，放到线程里面执行，然后有了执行结果之后，通过handler切换回主线程，进行UI渲染展示。/*** 普通的下载图片，显示到imageview的方法} });} /*** 下载图片功能函数** @returntry {= null) {try {

目前为止，我们实现了Rxjava的框架搭建、mao操作符的实现，在这个过程中，大家发现了是否对之前Rxjava原理一章的知识有了更加深入的感悟呢？篇幅所限，本文没有带着大家一起去画流程图，建议大家在实现前 or 实现后，去画一下，相信收获肯定更多。

上一章节，我们从简单的Rxjava使用入手，深入学习探索了Rxjava原理，也知道了Rxjava最重要的几个功能，，接下来我们就一步一步的结合源码+实践，来实现这些核心功能。本节，我们一起来实现Rxjava的响应式编程的功能，其实就是借助观察者模式实现一对一的通知功能。老办法，在实现一个功能之前，那么我们先去基于自己已有的知识体系，去分解、猜想功能实现的原理，然后再一步一步的去实现它，过程中，对比Rxjava源码，可以进行一一比对，看自己想的，和框架本身有何异同。