Android开发一个简单实用的闹铃APP

生活中我们会常常遇到需要闹钟提醒；不管是起床还是生活中的事件提醒。

那作为Android开发如何自己开发一个闹钟功能呢，是不是觉得很酷呢？接下来我们就实战一个闹钟。

本示例采用的是RecyclerView，其适配器类与常无二，其异在于继承一个代理类，为适配之后侧滑删除而准备

建立一个内部类ViewHolder实现控件定义申明

实现onCreateViewHolder方法载入子项布局文件

绑定实体类，实现onBindViewHolder获取数据

此处有三处状态，第一种状态：第一次进入程序，默认加载固定闹钟子项；第二种状态：进入添加子项页面，然后返回其主页面，并判断其switch是否为ture，如果为ture则添加子项；第三种状态：程序被系统回收或者用户停止程序，并再次进入程序，防止加载前一时刻闹钟子项；

添加依赖 实现侧滑主要依赖于一个第三方包，然后使用RecyclerView进行子项绑定 依赖如下：

并在目录buildgradle包下添加如下库

其实现侧滑删除主要的玄机在于布局文件当中，使用RelativeLayout布局，将删除按钮固定在布局右方，并使用其他布局将其覆盖，只有滑动时，才将其显示。掩盖侧滑删除按钮与暴露侧滑删除按钮效果对比图如下

然后，在适配器类中，实现WeSwipeHelperSwipeLayoutTypeCallBack接口，实现如下三个方法，第一个方法为获取侧滑删除按钮的宽度；第二个方法为需要滑动的视图，也就是覆盖侧滑删除按钮的布局；第三个方法为当视图正在滑动时，用户触发单击事件，自动还原滑动状态

最后，在需要添加子项的视图中绑定RecyclerView即可

通过监听子项滑动删除按钮点击事件，实现子项删除

跳转新增闹钟子项Acticity需要传输实体类对象，传输对象一般需要序列化改类，其 *** 作如下

定义实体类，并实现序列化

然后通过Intent传输Bundle对象

实现时间选择主要使用系统集成的组件TimePicker，其使用方法如下 其有两种显示方式，第一种为spinner，就是下拉滑动式，第二种为clock，即显示一个时钟，通过滑动指针选择时间

在stylexml文件中申明如下样式

然后再指定Activcty申明即可

获取数据比较简单，实现对应接口即可

将获取的数据通过SharedPreferences存储起来，然后点击存储时，进行页面跳转，然后再该界面进行取出数据

存储数据

首先判断回调的switch数据是否为ture，如果为ture则保存该子项，然后再适配器类中进行数据添加

选中与默认两种状态效果图如下

创建thumb和track样式

创建一个选择器文件，有选中和默认两种状态

创新open_thumbxml文件

创建shut_thumbxml文件

同样创建一个选择器，并用于两种状态

其中AlarmManager为系统主要 *** 作类，参数为提醒模式、提醒时间(long型)、PendingIntent对象 以下有三种时间传入，第一种，直接传入一个Long型时间用于测试，第二种，通过设置系统启动至今而设置时间，第三种，通过取出设置的时间，然后获取系统当前时间，将其差传入其中。

然后再清单文件中注册服务

使用Intent实现服务启动

杀死程序

本示例总共使用到了三个单例类：SP（SharedPreferences封装）、TimeFormat（时间数据格式封装）、KillProcess（杀死所有Activity）

SharedPreferences

KillProcess

文章带这里就完成了一个简单的闹钟；Android开发还有许多更加更多的知识学习。进一步学习Android技术，我这里推荐这份笔记方便学习，我就放在私信， 发送“核心笔记”或“手册”即可获取。朋友们可以免费领取！

1、首先为了提供运行的速度，我们会对View的 onDraw方法尤其关心，因为会引起垃圾回收，从而导致卡顿，所以在安卓上做动画，请在初始化期间或动画之间分配对象。切勿在动画运行期间进行分配。

2、要降低对 onDraw方法的调用频率，一般 onDraw方法的调用是有 invalidate 引起的 ，所以要避免不必要的调动

3、还有一种超级昂贵的 *** 作便利布局，requestLayout 这个方法如果调用，会对整个界面进行遍历，为了确定每个视图需要的尺寸，而且在遍历过程中，发现了冲突的尺寸， 可能还需要多次遍历层次结构：所以对开发人员来讲 ，少一层 ViewGroup 是必须要考虑的，由于层次结构导致的性能问题，所以浅层次结构的尤其重要

4、对于复杂的界面，使用自定义的ViewGroup

RecycleView的源码注释

在早期的RecycleView的源码中是这样子的

如果 hasFixedSize=true的话， 通过上面的解释，调用 requestLayout是非常昂贵的动作，如果你的 RecycleView 有插入和删除数据，而且是经常的话，这样子是极其可怕的，

所以setHasFixedSize 为 true，是为了更改 adapter的内容不会改变 它的View的高度和宽度，那么就可以设置为 True来避免不必要的 requestLayout

如果我们有一个高度/宽度wrap_content为 as的 RecyclerView， setHasFixedSize应该为 false，因为适配器插入的每个元素都可以根据插入/删除的项目改变大小，因此，每次添加/删除时，大小都会不同项目。RecyclerViewRecyclerView

更清楚地说，如果我们使用固定的宽度/高度

我们可以用my_recycler_viewsetHasFixedSize(true)

那么如果我们不使用固定的宽度/高度

我们应该使用因为my_recycler_viewsetHasFixedSize(false)宽度或高度可以改变我们的大小。wrap_contentRecyclerView

一句话，布局文件 match ，设置 setHasFixedSize =true

DiffUtil是一个工具类，当你的RecyclerView需要更新数据时，将新旧数据集传给它，它就能快速告知adapter有哪些数据需要更新。就相当于如果改变了就对某个item刷新，没改变就没刷新，可以简称为局部刷新。

Callback用来设置数据源的比较规则，判断新老数据之间的差异。

Callback

局部刷新

Android真响应式架构系列文章：

Android真响应式开发——MvRx

Epoxy——RecyclerView的绝佳助手

Android真响应式架构——Model层设计

Android真响应式架构——数据流动性

Android真响应式架构——Epoxy的使用

Android真响应式架构——MvRx和Epoxy的结合

什么是Epoxy？ Epoxy 是Airbnb开源的一个库，主要帮助我们构建复杂的RecyclerView，使用Epoxy可以让我们在毫无感知的情况下构建出复杂的多ViewType的RecyclerView。这么形容这个库有点太平淡了，实际上Epoxy是响应式框架MvRx的重要组成部分，是实现响应式界面的关键（强行安利， MvRx 是Airbnb开源的一个另一个库，简单来说它是一套Android响应式MVVM开发框架，具体可以查看 Android真响应式架构——MvRx ）。

我因为使用MvRx而接触到这个库，由衷地觉得其异常强大，大大简化了界面的开发。但是这么个强大的库，在国内几乎没啥人知道，也没几篇与之相关的文章，因此我决定写一篇文章来介绍它的使用方式，做个布道者。

试问使用RecyclerView的关键是什么，无外乎两点：

数据是千变万化的，显示更是形形色色的。众所周知，要让RecyclerView显示多种ViewType，还是一件比较繁琐的事。Epoxy的第一个重要作用就是简化了复杂多ViewType的开发流程，使我们专注在数据与显示的绑定上就可以了，剩下的Epoxy会帮我们处理。实际上，无论RecyclerView是单ViewType还是多ViewType，在Epoxy的帮助下，两者对于开发者而言是一模一样的，就是这么的无感。

你以为这就完了，too young。以上只描述了一半，也就是数据不变动的情形，还有另一半内容，即在数据发生变化的情况下，RecyclerView如何更新。又众所周知了，手动跟踪数据的变动然后通知RecyclerView更新是很费劲的，要不然就得无脑地 notifyDataSetChanged ，这都不是我们想要的，理想情况下应该是这样的：

这不是巧了这不是，Epoxy刚好可以帮我们完成上述任务的后两步。我们要做的就是声明数据的变化。

总结 ：Epoxy的主要作用有两个，第一，简化RecyclerView多ViewType的开发（简化到毫无感知的地步）；第二，如果数据变化，帮我们找出差别，然后做出对应的更新。因此，在Epoxy的帮助下，我们使用RecyclerView的主要任务就变成了：

Epoxy有两个重要组件：

使用RecyclerView绕不开就是数据如何在View中显示的问题，这一步任何库都帮不了我们，必须自己定义。原来我们使用RecyclerView是在 onBindViewHolder 中完成的这一步，在Epoxy中，使用EpoxyModel来完成这一步。当然EpoxyModel的功能还远不止于此。上面提到，Epoxy会帮我们找出“数据”的差别，然后做出对应更新，这里说的“数据”指的就是EpoxyModel。找出“数据”差别的前提就是知晓“数据”的同与不同，也就是说，该“数据”需要有 hashCode 和 equals 方法，刚好，EpoxyModel中有这样的方法。以上是EpoxyModel的作用，关于其定义，下面会有介绍。

EpoxyModel定义了item显示的基础，EpoxyController则决定了item的显示顺序。通过EpoxyController的 buildModel 方法提交“当前状态”下的EpoxyModels，Epoxy会帮我们和上一次EpoxyModels（如果有的话）进行比较，然后更新RecyclerView。如果数据发生变化，调用EpoxyController的 requestModelBuild 方法，EpoxyController的 buildModel 方法会再次被调用，创建“当前状态”下的EpoxyModels，如此反复（注意，不能直接调用 buildModel ）。

可以看出EpoxyController本身就是为了适应/鼓励MVVM的模式。数据只能单向流动：

Epoxy帮我们实现了从数据State到EpoxyModels到RecyclerView显示的黏合，至于如何 *** 纵数据State，以及何时调用 requestModelBuild 方法则取决于我们（推荐MvRx，它完美地解决了这个问题）。

有四种方式可以创建EpoxModel：

这里只介绍第一种推荐的方式。例如，item如下所示：

假如我们已经定义好layout叫 item_lotteryxml ，那么EpoxyModel可以这么定义：

以上就定义了一个基本的EpoxyModel。虽说叫自定义view的方式，但是我们往往都是直接 extends 某个布局，因此为了避免不必要的View嵌套， item_lotteryxml 会这么定义：

使用merge标签作为根。

下面解释一下以自定义View的方式创建EpoxyModel的要点：

完成 LotteryView 这一“自定义View”之后，（构建工程后）Epoxy会帮我们生成一个名为 LotteryViewModel_ 的类，原类名加上 Model_ 后缀，然后 LotteryViewModel_ 就可以在EpoxyController中使用了。

EpoxyModel另一个重要概念是ID。每个EpoxyModel都应该有唯一确定的ID来标识它，这个ID被用来diff和保存state。作为所有Model的基类 EpoxyModel ，它包含了以下方法：

可见生成ID的方法非常多

ID是以64位的 long 值表示的，除了 modelid(id) 这种最直接的方式，其它方式会以hash的方式计算ID，存在冲突的可能性，假如有几百个Model，都使用hash的方式生成ID，那么冲突的可能性是100万亿分之一（可比你写bug的概率小太多了）。可以选择过滤掉ID相同的EpoxyModel，具体内容请查看 文档 。

EpoxyModel中的属性可以是任意的，不一定非得是primitive type，但是该属性必须提供 equals 和 hashCode 方法，否则会产生编译错误。

属性可以分组：

对于以上的Image属性，我们提供url或者drawableRes就可以了。

上面提到 @ModelProp 注解的方法只能有一个参数，有些情况下需要有多个属性共同决定View的显示，这时可以用 @AfterPropsSet 注解：

还可以为属性提供默认值，或者设定属性为可选的（即可以不设置该属性）。具体可以查看 文档 。

以你想要的顺序向EpoxyController中添加EpoxyModel，就可以确定RecyclerView中应该显示哪些items。使用EpoxyController的关键在于重写其 buildModel 方法， buildModel 方法只需要根据其调用时刻的数据状态构建EpoxyModels即可。例如：

如上所示，每当数据发生变化时，调用EpoxyController的 requestModelBuild 方法就会通知EpoxyController重新构建EpoxyModels（即 buildModel 方法被调用），完成diff之后，RecyclerView被更新。

如 requestModelBuild 的名称一样，只是请求Model的构建，并不保证构建会立即完成（除了第一次请求），新的请求会取消掉旧的请求（debounced），所以我们不用担心多余的 requestModelBuild ，任意数据的变化都应该发起 requestModelBuild ，不用考虑优化的问题。

每次的 buildModels 都是完全独立的（之前一次的EpoxyModels不会保存），每次都是从空的models列表开始的，所以每次 buildModels 都要构建完整的EpoxyModels列表。

默认情况下构建Models和diff都发生在主线程，显然这可能会引起界面的卡顿（尤其是diff *** 作），所以应该把他们都放在子线程，有个开箱即用的方式：

如果采用这种方式就要保证在 buildModels 中访问数据是线程安全的，并且不能在该方法中更新View（例如根据数据状态改变title什么的）。也可以选择构建Models仍在主线程，diff放在子线程，可以去查看 文档 。

为了保证EpoxyController的正确运行，必须保证：

Epoxy提供了一个RecyclerView的子类EpoxyRecyclerView，它使得Epoxy和RecyclerView的结合变得更加简单，推荐使用。

EpoxyRecyclerView做了如下改进：

如果item还在RecyclerView中显示，此时代表该item的EpoxyModel如果更新了，那么只会进行局部的更新，不会更新整个item。以如下界面为例：

假设生成的EpoxyModel叫 PayWayModel_ 。

整体流程如上图所示，其中diff *** 作会把ID相同的 PayWayModel_ 进行比较，例如从微信支付切换到支付宝支付，前者的check属性从true变为false，前者的check属性从false变为true，其它属性无变化，那么就只有这两个item的CheckBox会刷新，其它的都不会刷新。如果按照我们传统的方式，一般会调用 notifyItemChanged 方法，这会使这两个item重新绑定，item中所有View均会刷新，导致item轻微闪烁，相反，Epoxy的局部更新就不会有这样的问题。

以上以一个实际事例描述了Epoxy的更新流程，在这个例子中，由于 PayWayModel_ 始终只有三个，只是属性会更新，并且一般情况下这三个item会始终显示在RecyclerView中，因此Epoxy会仅仅进行局部更新。不过，diff的功能绝不仅仅是比较相同ID的Model属性的变化这么简单，EpoxyModels的增加、删除甚至是顺序调整都会被diff比较出来，然后做出对应界面更新。

Epoxy是RecylerView的绝佳助手，大大简化了RecyclerView的使用。有了Epoxy的帮助，你会发现RecyclerView的使用范围也被大大扩展了，几乎一切界面的主体部分都可以使用RecyclerView来承载。界面开发就变成了定义一个又一个的EpoxyModel，界面被拆分成一个又一个的EpoxyModel后，界面元素的复用也变得异常简单，整个界面的开发就跟搭积木一样。

如前所述，Epoxy完成了从数据State到EpoxyModels到RecyclerView显示的黏合，至于如何 *** 纵数据State以及通知更新则取决于我们，但是，这并不是一项简单的任务，这也可能是为啥Epoxy并不太流行的原因。还好MvRx帮我们完美地解决了这个问题，所以还是强烈推荐结合 MvRx 一起使用的，你会体验到不同以往的Android开发流程。

Scrap

Cache

ViewCacheExtension

RecycledViewPool

Scrap 对应ListView缓存中的ActiveView，即屏幕内的缓存数据：当列表数据发生变化时，屏幕内的数据可以直接拿来复用，无需进行数据绑定

Cache 是刚刚移除屏幕的缓存数据，默认大小是2个；当容量充满时又有新的数据加入，会根据先入先出原则，把先进入Cache的缓存数据放到下一级缓存中，然后把新的数据添加进来；Cache里面携带了ViewHolder的所有数据信息，数据可以直接拿来复用。

注意：Cache里是根据position来寻找数据，这个position是根据第一个或者最后一个可见的item的position和用户 *** 作行为（上拉、下拉）来计算的

ViewCacheExtension 是留给开发者自定义缓存的，通过重写getViewForPositionAndType方法，根据type和position拿到viewHolder，慎用

RecycledViewPool 默认大小是5个，与Cache不同的是，在Cache里移除的ViewHolder再存入RecyclerViewPool之前，ViewHolder的数据会被全部重置，相当于一个新的ViewHolder，RecyclerViewPool是根据itemType来获取数据的，如果没有重写getItemType方法，那么itemType就是默认的；因为viewHolder数据被重置了，所以RecyclerViewPool缓存的ViewHolder是全新的，从这里取出的数据是要重新走onBindViewHolder方法的

项目地址： >

刚刚开始写博客，写的不好，敬请见谅！

在适配中自定义一个接口

public interface SaveEditListener{

void SaveEdit(int position, String string);

}

在适配器中的构造方法中声明该接口：

适配中调用：

如果条目是输入框类型的话，需要自定义EditText的监听类，具体实现：

Activity中调用：

实现该接口

看截图类型1跟类型2有加载顺序要求，类型2控制在类型1加载完成后就可以了，至于是不是同个线程没什么所谓吧，类型1加载完，在同个线程内再请求接口也可以。类型1加载完，再创建一个线程去加载类型2也可以。

以上就是关于Android开发一个简单实用的闹铃APP全部的内容，包括:Android开发一个简单实用的闹铃APP、再次认识下 RecyclerView setHasFixedSize的方法、Recyclerview-Diffutils等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！