androidmvpretrofit

‘壹’ android开发一般都使用什么框架

Android开发框架介绍
编辑文档
学分 +2
开发框架方面包含基本的应用功能开发、数据存储、网络访问这三大块：
一、应用方面
一般而言一个标准的Android程序由如下4部分组成即Activity、Broadcast Intent Receiver、Service、Content Provider： 1. Activity是最频繁、最基本的模块，在Android中，一个Activity就是手机上一屏，相当于一个网页一样，所不同的是，每个Activity运行结束了，有个返回值，类似一个函数一样。Android系统会自动记录从首页到其他页面的所有跳转记录并且自动将以前的Activity压入系统堆栈，用户可以通过编程的方式删除历史堆栈中的Activity Instance。
Activity类中主要是跟界面资源文件关联起来（res/layout目录下的xml资源，也可以不含任何界面资源），内部包含控件的显示设计、界面交互设计、事件的响应设计以及数据处理设计、导航设计等application设计的方方面面。 2. Broadcast Intent Receiver
Intent提供了各种不同Activity进行跳转的机制，譬如如果从A activity跳转到B activity，使用Intent来实现如下： Intent in = new Intent(A.this, B.class); startActivity(in);
BroadcastReceiver提供了各种不同的Android应用程序进行进行进程间通讯的机制，譬如当电话呼叫来临时，可以通过BroadcastReceiver发布广播消息。对于用户而言，BroadcastReceiver是不透明的，用户无法看到这个事件，BroadcastReceiver通过NotificationManager来通知用户这些事件发生了，它既可以在资源AndroidManifest.xml中注册，也可以在代码中通过Context.registerReceiver()进行注册，只要是注册了，当事件来临的时候，即时程序没有启动，系统也在需要的时候会自动启动此应用程序；另外各应用程序很方便地通过Context.sendBroadcast()将自己的事情广播给其他应用程序；
3. Service,跟Windows当中的Service完全是一个概念，用户可以通过startService(Intent service)启动一个Service，也可通过Context.bindService来绑定一个Service.
4. Content Provider，由于Android应用程序内部的数据都是私有的，Content Provider提供了应用程序之间数据交换的机制，一个程序可以通过实现一个ContentProvider的抽象接口将自己的数据暴露出去，并且隐蔽了具体的数据存储实现，标准的ContentProvider提供了基本的CRUD（Create,Read,Update,Delete)的接口，并且实现了权限机制，保护了数据交互的安全性； 一个标准的Android应用程序的工程文件包含如下几大部分： -> java源代码部分(包含Activity)，都在src目录当中；
-> R.java文件，这个文件是Eclipse自动生成与维护的，开发者不需要修改，提供了Android对的资源全局索引； -> Android Library，这个是应用运行的Android库；
-> assets目录，这个目录里面主要用与放置多媒体等一些文件；
-> res目录，放置的是资源文件,跟VC中的资源目录基本类似，其中的drawable包含的是图片文件，layout里面包含的是布局文件，values目录里面主要包含的是字符串(strings.xml)、颜色（colors.xml)以及数组（arrays.xml)资源；
-> AndroidManifest.xml，这个文件异常重要，是整个应用的配置文件，在这个文件中，需要声明所有用到的Activity、Service、Receiver等。

‘贰’ 如何构建Android MVVM 应用框架

我们先来看看什么是MVVM，然后再一步一步来设计整个MVVM框架。
MVC、MVP、MVVM
首先，我们先大致了解下Android开发中常见的模式。
MVC
View：XML布局文件。
Model：实体模型（数据的获取、存储、数据状态变化）。
Controllor：对应于Activity，处理数据、业务和UI。
从上面这个结构来看，Android本身的设计还是符合MVC架构的，但是Android中纯粹作为View的XML视图功能太弱，我们大量处理View的逻辑只能写在Activity中，这样Activity就充当了View和Controller两个角色，直接导致Activity中的代码大爆炸。相信大多数Android开发者都遇到过一个Acitivty数以千行的代码情况吧！所以，更贴切的说法是，这个MVC结构最终其实只是一个Model-View（Activity:View&Controller）的结构。
MVP
View:对应于Activity和XML，负责View的绘制以及与用户的交互。
Model:依然是实体模型。
Presenter:负责完成View与Model间的交互和业务逻辑。
前面我们说，Activity充当了View和Controller两个角色，MVP就能很好地解决这个问题，其核心理念是通过一个抽象的View接口（不是真正的View层）将Presenter与真正的View层进行解耦。Persenter持有该View接口，对该接口进行操作，而不是直接操作View层。这样就可以把视图操作和业务逻辑解耦，从而让Activity成为真正的View层。
但MVP也存在一些弊端：
Presenter（以下简称P）层与View（以下简称V）层是通过接口进行交互的，接口粒度不好控制。粒度太小，就会存在大量接口的情况，使代码太过碎版化；粒度太大，解耦效果不好。同时对于UI的输入和数据的变化，需要手动调用V层或者P层相关的接口，相对来说缺乏自动性、监听性。如果数据的变化能自动响应到UI、UI的输入能自动更新到数据，那该多好！
MVP是以UI为驱动的模型，更新UI都需要保证能获取到控件的引用，同时更新UI的时候要考虑当前是否是UI线程，也要考虑Activity的生命周期（是否已经销毁等）。
MVP是以UI和事件为驱动的传统模型，数据都是被动地通过UI控件做展示，但是由于数据的时变性，我们更希望数据能转被动为主动，希望数据能更有活性，由数据来驱动UI。
V层与P层还是有一定的耦合度。一旦V层某个UI元素更改，那么对应的接口就必须得改，数据如何映射到UI上、事件监听接口这些都需要转变，牵一发而动全身。如果这一层也能解耦就更好了。
复杂的业务同时也可能会导致P层太大，代码臃肿的问题依然不能解决。
MVVM
View:对应于Activity和XML，负责View的绘制以及与用户交互。
Model:实体模型。
ViewModel:负责完成View与Model间的交互，负责业务逻辑。
MVVM的目标和思想与MVP类似，利用数据绑定(Data Binding)、依赖属性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一个更加灵活高效的架构。
数据驱动
在常规的开发模式中，数据变化需要更新UI的时候，需要先获取UI控件的引用，然后再更新UI。获取用户的输入和操作也需要通过UI控件的引用。在MVVM中，这些都是通过数据驱动来自动完成的，数据变化后会自动更新UI，UI的改变也能自动反馈到数据层，数据成为主导因素。这样MVVM层在业务逻辑处理中只要关心数据，不需要直接和UI打交道，在业务处理过程中简单方便很多。
低耦合度
MVVM模式中，数据是独立于UI的。
数据和业务逻辑处于一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要和UI或者控件打交道。UI想怎么处理数据都由UI自己决定，ViewModel不涉及任何和UI相关的事，也不持有UI控件的引用。即便是控件改变了（比如：TextView换成EditText），ViewModel也几乎不需要更改任何代码。它非常完美的解耦了View层和ViewModel，解决了上面我们所说的MVP的痛点。
更新UI
在MVVM中，数据发生变化后，我们在工作线程直接修改（在数据是线程安全的情况下）ViewModel的数据即可，不用再考虑要切到主线程更新UI了，这些事情相关框架都帮我们做了。
团队协作
MVVM的分工是非常明显的，由于View和ViewModel之间是松散耦合的：一个是处理业务和数据、一个是专门的UI处理。所以，完全由两个人分工来做，一个做UI（XML和Activity）一个写ViewModel，效率更高。
可复用性
一个ViewModel可以复用到多个View中。同样的一份数据，可以提供给不同的UI去做展示。对于版本迭代中频繁的UI改动，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二选择。
单元测试
有些同学一看到单元测试，可能脑袋都大。是啊，写成一团浆糊的代码怎么可能做单元测试？如果你们以代码太烂无法写单元测试而逃避，那可真是不好的消息了。这时候，你需要MVVM来拯救。
我们前面说过了，ViewModel层做的事是数据处理和业务逻辑，View层中关注的是UI，两者完全没有依赖。不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。在MVVM中数据是直接绑定到UI控件上的（部分数据是可以直接反映出UI上的内容），那么我们就可以直接通过修改绑定的数据源来间接做一些Android UI上的测试。
通过上面的简述以及模式的对比，我们可以发现MVVM的优势还是非常明显的。虽然目前Android开发中可能真正在使用MVVM的很少，但是值得我们去做一些探讨和调研。
如何构建MVVM应用框架
如何分工
构建MVVM框架首先要具体了解各个模块的分工。接下来我们来讲解View、ViewModel、Model它们各自的职责所在。
View
View层做的就是和UI相关的工作，我们只在XML、Activity和Fragment写View层的代码，View层不做和业务相关的事，也就是我们在Activity不写业务逻辑和业务数据相关的代码，更新UI通过数据绑定实现，尽量在ViewModel里面做（更新绑定的数据源即可），Activity要做的事就是初始化一些控件（如控件的颜色，添加RecyclerView的分割线），View层可以提供更新UI的接口（但是我们更倾向所有的UI元素都是通过数据来驱动更改UI），View层可以处理事件（但是我们更希望UI事件通过Command来绑定）。 简单地说：View层不做任何业务逻辑、不涉及操作数据、不处理数据，UI和数据严格的分开。
ViewModel
ViewModel层做的事情刚好和View层相反，ViewModel只做和业务逻辑和业务数据相关的事，不做任何和UI相关的事情，ViewModel 层不会持有任何控件的引用，更不会在ViewModel中通过UI控件的引用去做更新UI的事情。ViewModel就是专注于业务的逻辑处理，做的事情也都只是对数据的操作（这些数据绑定在相应的控件上会自动去更改UI）。同时DataBinding框架已经支持双向绑定，让我们可以通过双向绑定获取View层反馈给ViewModel层的数据，并对这些数据上进行操作。关于对UI控件事件的处理，我们也希望能把这些事件处理绑定到控件上，并把这些事件的处理统一化，为此我们通过BindingAdapter对一些常用的事件做了封装，把一个个事件封装成一个个Command，对于每个事件我们用一个ReplyCommand 去处理就行了，ReplyCommand 会把你可能需要的数据带给你，这使得我们在Vie，具体见 MVVM Light Toolkit 使用指南的 Command 部分 。再强调一遍：ViewModel 不做和UI相关的事。
Model
Model层最大的特点是被赋予了数据获取的职责，与我们平常Model层只定义实体对象的行为截然不同。实例中，数据的获取、存储、数据状态变化都是Model层的任务。Model包括实体模型（Bean）、Retrofit的Service ，获取网络数据接口，本地存储（增删改查）接口，数据变化监听等。Model提供数据获取接口供ViewModel调用，经数据转换和操作并最终映射绑定到View层某个UI元素的属性上。
如何协作
关于协作，我们先来看下面的一张图：

上图反应了MVVM框架中各个模块的联系和数据流的走向，我们从每个模块一一拆分来看。那么我们重点就是下面的三个协作。
ViewModel与View的协作 。
ViewModel与Model的协作 。
ViewModel与ViewModel的协作 。
ViewModel与View的协作

图2中ViewModel和View是通过绑定的方式连接在一起的，绑定分成两种：一种是数据绑定，一种是命令绑定。数据的绑定DataBinding已经提供好了，简单地定义一些ObservableField就能把数据和控件绑定在一起了（如TextView的text属性），但是DataBinding框架提供的不够全面，比如说如何让一个URL绑定到一个ImageView，让这个ImageView能自动去加载url指定的图片，如何把数据源和布局模板绑定到一个ListView，让ListView可以不需要去写Adapter和ViewHolder相关的东西？这些就需要我们做一些工作和简单的封装。MVVM Light Toolkit 已经帮我们做了一部分的工作,关于事件绑定也是一样，MVVM Light Toolkit 做了简单的封装，对于每个事件我们用一个ReplyCommand去处理就行了，ReplyCommand 会把可能需要的数据带给你，这样我们处理事件的时候也只关心处理数据就行了.
由 图 1 中ViewModel的模块中我们可以看出ViewModel类下面一般包含下面5个部分：
Context （上下文）
Model (数据源 Java Bean)
Data Field （数据绑定）
Command （命令绑定）
Child ViewModel （子ViewModel）
我们先来看下示例代码，然后再一一讲解5个部分是干嘛用的：
//context
private Activity context;
//model（数据源 Java Bean）
private NewsService.News news;
private TopNewsService.News topNews;
//数据绑定，绑定到UI的字段（data field）
public final ObservableField<String> imageUrl = new ObservableField<>();
public final ObservableField<String> html = new ObservableField<>();
public final ObservableField<String> title = new ObservableField<>();
// 一个变量包含了所有关于View Style 相关的字段
public final ViewStyle viewStyle = new ViewStyle();
//命令绑定（command）
public final ReplyCommand onRefreshCommand = new ReplyCommand<>(() -> {

})
public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {

});

//Child ViewModel
public final ObservableList<NewItemViewModel> itemViewModel = new ObservableArrayList<>();

/** * ViewStyle 关于控件的一些属性和业务数据无关的Style 可以做一个包裹，这样代码比较美观，
ViewModel 页面也不会有太多太杂的字段。 **/
public static class ViewStyle {
public final ObservableBoolean isRefreshing = new ObservableBoolean(true);
public final ObservableBoolean progressRefreshing = new ObservableBoolean(true);
}

Context
Context是干嘛用的呢，为什么每个ViewModel都最好需要持了一个Context的引用呢？ViewModel不处理和UI相关的事也不操作控件，更不更新UI，那为什么要有Context呢？原因
Model是什么呢？其实就是数据源，可以简单理解是我们用JSON转过来的Bean。ViewModel要把数据映射到UI中可能需要大量对Model的数据拷贝和操作，拿Model的字段去生成对应的ObservableField然后绑定到UI（我们不会直接拿Model的数据去做绑定展示），这里是有必要在一个ViewModel保留原始的Model引用，这对于我们是非常有用的，因为可能用户的某些操作和输入需要我们去改变数据源，可能我们需要把一个Bean在列表页点击后传给详情页，可能我们需要把这个Model当做表单提交到服务器。这些都需要我们的ViewModel持有相应的Model（数据源）。
Data Field（数据绑定）
Data Field就是需要绑定到控件上的ObservableField字段，这是ViewModel的必需品，这个没有什么好说。但是这边有一个建议：
这些字段是可以稍微做一下分类和包裹的。比如说可能一些字段是绑定到控件的一些Style属性上（如长度、颜色、大小），对于这类针对View Style的的字段可以声明一个ViewStyle类包裹起来，这样整个代码逻辑会更清晰一些，不然ViewModel里面可能字段泛滥，不易管理和阅读性较差。而对于其他一些字段，比如说title、imageUrl、name这些属于数据源类型的字段，这些字段也叫数据字段，是和业务数据和逻辑息息相关的，这些字段可以放在一块。
Command（命令绑定）
Command（命令绑定）简言之就是对事件的处理（下拉刷新、加载更多、点击、滑动等事件处理）。我们之前处理事件是拿到UI控件的引用，然后设置Listener，这些Listener其实就是Command。但是考虑到在一个ViewModel写各种Listener并不美观，可能实现一个Listener就需要实现多个方法，但是我们可能只想要其中一个有用的方法实现就好了。更重要一点是实现一个Listener可能需要写一些UI逻辑才能最终获取我们想要的。简单举个例子，比如你想要监听ListView滑到最底部然后触发加载更多的事件，这时候就要在ViewModel里面写一个OnScrollListener，然后在里面的onScroll方法中做计算，计算什么时候ListView滑动底部了。其实ViewModel的工作并不想去处理这些事件，它专注做的应该是业务逻辑和数据处理，如果有一个东西不需要你自己去计算是否滑到底部，而是在滑动底部自动触发一个Command，同时把当前列表的总共的item数量返回给你，方便你通过 page=itemCount/LIMIT+1去计算出应该请求服务器哪一页的数据那该多好啊。MVVM Light Toolkit 帮你实现了这一点：
public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {
int page=itemCount/LIMIT+1;
loadData(page.LIMIT)
});

接着在XML布局文件中通过bind:onLoadMoreCommand绑定上去就行了。
<android.support.v7.widget.RecyclerView
android:layout_width="match_parent"
android:layout_height="match_parent"
bind:onLoadMoreCommand="@{viewModel.loadMoreCommand}"/>
x

当然Command并不是必须的，你完全可以依照自己的习惯和喜好在ViewModel写Listener，不过使用Command可以使ViewModel更简洁易读。你也可以自己定义更多的、其他功能的Command，那么ViewModel的事件处理都是托管ReplyCommand 来处理，这样的代码看起来会比较美观和清晰。Command只是对UI事件的一层隔离UI层的封装，在事件触发时把ViewModel层可能需要的数据传给ViewModel层，对事件的处理做了统一化，是否使用的话，还是看你个人喜好了。
Child ViewModel（子ViewModel）
子ViewModel的概念就是在ViewModel里面嵌套其他的ViewModel，这种场景还是很常见的。比如说你一个Activity里面有两个Fragment，ViewModel是以业务划分的，两个Fragment做的业务不一样，自然是由两个ViewModel来处理，这时候Activity对应的ViewModel里面可能包含了两个Fragment各自的ViewModel，这就是嵌套的子ViewModel。还有另外一种就是对于AdapterView，如ListView RecyclerView、ViewPager等。
//Child ViewModelpublic final
ObservableList<ItemViewModel> itemViewModel = new ObservableArrayList<>();

它们的每个Item其实就对应于一个ViewModel，然后在当前的ViewModel通过ObservableList 持有引用（如上述代码），这也是很常见的嵌套的子ViewModel。我们其实还建议，如果一个页面业务非常复杂，不要把所有逻辑都写在一个ViewModel，可以把页面做业务划分，把不同的业务放到不同的ViewModel，然后整合到一个总的ViewModel，这样做起来可以使我们的代码业务清晰、简短意赅，也方便后人的维护。
总的来说，ViewModel和View之前仅仅只有绑定的关系，View层需要的属性和事件处理都是在XML里面绑定好了，ViewModel层不会去操作UI，只是根据业务要求处理数据，这些数据自动映射到View层控件的属性上。关于ViewModel类中包含哪些模块和字段，这个需要开发者自己去衡量，我们建议ViewModel不要引入太多的成员变量，成员变量最好只有上面的提到的5种（context、model……），能不引入其他类型的变量就尽量不要引进来，太多的成员变量对于整个代码结构破坏很大，后面维护的人要时刻关心成员变量什么时候被初始化、什么时候被清掉、什么时候被赋值或者改变，一个细节不小心可能就出现潜在的Bug。太多不清晰定义的成员变量又没有注释的代码是很难维护的。
另外，我们会把UI控件的属性和事件都通过XML（如bind：text=@{...}）绑定。如果一个业务逻辑要弹一个Dialog，但是你又不想在ViewModel里面做弹窗的事（ViewModel不希望做UI相关的事）或者说改变ActionBar上面的图标的颜色，改变ActionBar按钮是否可点击，这些都不是写在XML里面（都是用Java代码初始化的），如何对这些控件的属性做绑定呢？我们先来看下代码：
public class MainViewModel implements ViewModel {
....
//true的时候弹出Dialog，false的时候关掉dialog
public final ObservableBoolean isShowDialog = new ObservableBoolean();
....
.....
}
// 在View层做一个对isShowDialog改变的监听
public class MainActivity extends RxBasePmsActivity {

private MainViewModel mainViewModel;

@Override
protected void onCreate(Bundle savedInstanceState) {
.....
mainViewModel.isShowDialog.addOnPropertyChangedCallback(new android.databinding.Observable.OnPropertyChangedCallback() {
@Override
public void onPropertyChanged(android.databinding.Observable sender, int propertyId) {
if (mainViewModel.isShowDialog.get()) {
dialog.show();
} else {
dialog.dismiss();
}
}
});
}
...
}

简单地说你可以对任意的ObservableField做监听，然后根据数据的变化做相应UI的改变，业务层ViewModel只要根据业务处理数据就行，以数据来驱动UI。

‘叁’ Android大厂面试经验分享（OPPO，字节，华为，阿里）

我是从小公司跳出来的，最终入职OPPO，说实话这段时间的经历让我深深地感受到，我们为跳槽做的一些临时抱佛脚的提升跟那些大佬的沉淀比起来太渺小了。我们都知道找资料学习、刷面试题，但也许只能应付这一次的面试，后面还是会技术发愁，那些短时间背下来的东西迟早会忘掉， 大家还是做好长期提升自己的准备，好好沉淀的东西最后才是属于自己的。

说说当时的面试过程，我是内推获得的面试机会，很感谢当时帮我内推的兄弟，总共三轮面试，两轮技术，一轮HR面，当天面试结束。

我10：10分到的公司，10：30开始面试，第一轮面试将近一个小时，聊的点我基本上都答得上来，自我感觉良好。然后面试官让我等一下，他去叫他们老大来给我二面，我等了有二十几分钟吧，二面有一个多小时，这次问的比较深，有些地方答的有些嗑吧，总体来说我自己是满意的。HR面约到下午了，整个流程下来每轮面试官都让人感觉很不错，我自己做的准备也让我面试感觉下来很爽。

我把面试遇到过的以及自己学习用到过相关内容都整理到一起了，方便自己进行复盘和后续的查漏补缺：

一、 Java基础

1.1 静态内部类和非静态内部类的比较

1.2 多态的理解与应用

1.3 java方法的多态性理解

1.4 java中接口和继承的区别

1.5 线程池的好处，详解，单例（绝对好记）

1.6 线程池的优点及其原理

1.7 线程池的优点（重点）

1.8 为什么不推荐通过Executors直接创建线程池

1.9 不怕难之BlockingQueue及其实现

1.10 深入理解ReentrantLock与Condition

1.11 Java多线程：线程间通信之Lock

1.12 Synchronized 关键字原理

1.13 ReentrantLock原理

1.14 HashMap中的Hash冲突解决和扩容机制

1.14 Java并发

1.15 Java虚拟机

1.16 JVM常见面试题

1.17 JVM内存结构

1.18 类加载机制/双亲委托

二、 Android基础

2.1 Activity知识点(必问)

2.2 Fragment知识点

2.3 Service知识点

2.4 Intent知识点

2.5 数据存储

三、UI控件篇

3.1 屏幕适配

3.2 主要控件优化

3.3 事件分发与嵌套滚动

3.4 动态化页面构建方案

四、网络通信篇

4.1 网络协议

五、架构设计篇

5.1 MVP架构设计

5.2 组件化架构

六、性能优化篇

6.1 启动优化

6.2 内存优化

6.3 绘制优化

6.4 安装包优化

七、源码流程篇

7.1 开源库源码分析

7.2 Glide源码分析

7.3 day 20 面试题：Glide面试题

7.4 聊一聊关于Glide在面试中的那些事

7.5 面试官：简历上如果写Glide，请注意以下几点…

7.6 Glide OOM问题解决方法汇总

7.7 LeakCanary源码分析

7.8 OkHttp源码分析

7.9 okhttp连接池复用机制

7.10 okhttp 流程和优化的实现

7.11 一篇让你受用的okhttp分析

7.12 OkHttp面试之–OkHttp的整个异步请求流程

7.13 OkHttp面试之–HttpEngine中的sendRequest方法详解

7.14 OkHttp解析大总结

7.15 Okhttp任务队列工作原理

7.16 Android高频面试专题 - 架构篇（二）okhttp面试必知必会

7.17 Android 网络优化，使用 HTTPDNS 优化 DNS，从原理到 OkHttp 集成

7.18 Retrofit源码分析

7.19 RxJava源码分析

7.20 RxJava原理与源码分析

7.21 RxJava如何进行线程切换的？

7.22 Rxjava内存泄漏防止方案——RxLifecycle，AutoDispose，RxLife框架

7.23 Tinker源码分析

7.24 ARouter源码分析

7.25 Android框架层源码解析

7.26 算法设计

八、新技术篇

8.1 实战问题篇

九、面试篇

9.1 开源文档

9.2 面试文献

以上就是我的学习和面试积累，有自己面试经历过的，也有整理的一些大厂面试题，篇幅有限，具体内容就不展示了，我已经整理成文档了。

还是开头说的，仅靠面试期间临时抱佛脚和刷题对自身发展不是长久之计，做好长期提升的规划，好好沉淀每一次的学习和面试经历，把这些最终都转化成属于自己的东西才是实质上对自己最有用的。

‘肆’ Android活动命名是怎样的规则

一．标识符命名方法
1 .小驼峰命名法，除首单词外，其余所有单词的第一个字母大写。如：allPrice，getAllNames
2.大驼峰命名法，所有单词的第一个字母大写。如：GuideActivity，StudentInfoBean
3.下划线命名法:单词与单词间用下划线做间隔。如：activity_main,select_backGround_color
二．命名规范
（一）包（packages）的命名规范:
采用反域名命名规则，全部使用小写字母。一级包名为com，二级包名lwz（为个人或公司名称，可以简写），三级包名guidecity（根据应用进行命名），四级包名ui或utils等（模块名或层级名），根据实际情况也是可以用五级包名，六级包名。
这里的四级包名是要重点理解和分类的，例如：com.lwz.应用.utils ，此包中包含：公共工具方法类
1.utils
此包中包含：公共工具方法类，比如：SPHelperUtil、TimeUitl、FileUtil等
2.adapter
此包中包含：一些适配器的类，比如：ArticleAdapter、FansAdapter，HistorAdaper等
3.base
此包中包含：一些共同类的基类，比如：BaseActivity（所有的Activity类都继承这个类）、BaseFragment（所有的Fragment都继承这个类），ListItemAdapter（封装了Base Adapter的基类）等
4.bean
此包中包含：一些属性对象类，比如：StudentBean、LonginBean、ArticleBean等
5.config
此包中包含：最顶级的配置类，比如：MyApp（继承了Application）
6.httpservice
此包中包含：Http数据的请求接口类，好像Retrofit网络框架请求网络数据才要使用。如：ILogin接口，IAddTopic接口，IUpdate等
7.interface
此包中包含：某个页面或对象的所用操作接口类，这个接口主要是定义这个对象的所有方法。如：IUser接口，IArticle接口，ITopic接口等
8.model
这是MVC或MVP框架设计中的M。此包中包含：某个页面或对象的所用操作类，这个类继承了上面定义的interface接口，重写并实现厘米那的方法。如：UserModel，ArticleMode类，TopicMode类等
9.ui
这个ui表示的页面的意思，也是MVC或MVP中的V，很多人把这个包名写成activity，其实是不准确的，因为ui包含了activity和fragment，所以ui是四级包名，而activity和fragment是ui包下的五级包名。
activity此包中包含：Activity对象类。如：MainActivity类，HomeActivity类，FansListActivity类等。如果是使用了MVP框架模式，activity包名下还可以有六级包名，比如：loginMVP（包含ILoginView接口类，LoginPresenter类）、seleteTopicMVP
fragment此包中包含：Fragment对象类。但是Fragment一般都是多个存在的，所以fragment包下一般还有六级包名，表示里面是哪个页面的Fragment对象。
10.weight
此包中包含：自定义View或自定义对话框等视图类。如：CursroDialog类，SpringScrollView类，ScrollListView类等
11.db
此包中包含：数据库操作类
12.service
此包中包含：Service服务类
13.broadcast
此包中包含：Broadcast广播接收者类
14.provider
此包中包含：Provider内容提供者类（用得很少）
包名规划我感觉对程序后期阅读或修改有很大的帮助，特别是很大的程序，文件太多，不规划的话自己都不知道这个类是干什么的！
当然如果程序中没有这一类的文件，这个包名是可以不写，但是一些基本的包名，基本每个程序都是需要的比如：ui、utils、adapter、weight、bean等
（二）类（classes）的命名规范：
一般用名词，采用大驼峰命名法，尽量避免缩写，除非该缩写是众所周知的，比如HTML,URL，如果类名称中包含单词缩写，则单词缩写的每个字母均应大写。
以下是部分示例说明：
1.activity 类，如欢迎页面类WelcomeActivity.
2.adapter类,如商品详情适配器ProctDetailAdapter
3.util公共方法类，如：线程池管理类：ThreadPoolManager，日志工具类：LogUtil
4.db数据库类，以DBHelper后缀标识。如城市数据库：CityDBHelper
5.Service类，以Service为后缀标识
6.BroadcastReceive，以Broadcast为后缀标识
7.ContentProvider，以Provider为后缀标识
（三）接口（interface）：
命名规则与类一样采用大驼峰命名法，多以able或ible结尾或以I开头，如Runnable、Accessible、IUser。
（四）方法（methods）的命名规则：
一般使用动词或动名词，采用小驼峰命名法 例如:onCreate(),run()
>1.initXXX()初始化相关方法,使用init为前缀标识
2.isXXX()、checkXXX() 方法返回值为boolean型的请使用is或check为前缀标识
3.getXXX()返回某个值的方法，使用get为前缀标识
4.processXXX() 对数据进行处理的方法，尽量使用process为前缀标识
5.displayXXX() 弹出提示框和提示信息，使用display为前缀标识
6.saveXXX() 与保存数据相关的，使用sav为e前缀标识
7.resetXXX() 对数据重组的，使用reset前缀标识
8.clearXXX()removeXXX() 清除数据相关的，使用clear或remove为前缀标识
9.drawXXX() 绘制数据或效果相关的，使用draw前缀标识

（五）变量（variables）采用小驼峰命名法。类中控件名称一般与xml布局id保持一致
（六）常量（constants）全部大写,采用下划线命名法.例如：MIN_WIDTH
（七）XML文件（布局文件）：全部小写，采用下划线命名法，
例如：main_activity.xml， item_activity.xml、homeposter_item_poster.xml
（八）资源文件（图片）： 全部小写，采用下划线命名法，加前缀区分

命名
说明

btn_login_normal 按钮图片使用btn_功能_说明
bg_head 背景图片使用bg_功能_说明
def_search_cell 默认图片使用def_功能_说明
icon_more_help 图标图片使用icon_功能_说明
seg_list_line 具有分隔特征的图片使用seg_功能_说明
sel_ok 选择图标使用sel_功能_说明
（九）动画文件（anim包）：全部小写，采用下划线命名法，加前缀区分。
动画命名例子：

规范写法
备注

click_head_left 点击背景切换动画使用click前缀标识
bg_shape_rectangle 背景自定义图形使用bg前缀标识
show_shopcar_add 小动画效果使用show前缀标识
（十）资源ID（resources id）：大小写规范与方法名一致，采用小驼峰命名法。
命名规范为“资源控件的缩写名”+“变量名”。例如TextView的id=“tv_userName”。注意：页面控件名称应该和控件id名一般是一致，例如：TextView tv_userName=(TextView)findViewById(R.id.tv_userName);
三．图解包名规范示例
本文主要是想对程序包名的命名规划，这里展示我之前开发的程序的包名图片，供大家参考：
（一）总显示

上面example这个包名一般是不用的！
（二）ui包下
fragment展示

activity 展示：

（三）utils和weight包下

（四）res文件夹下的部分文件展示：

drawable包下：

layout包下：

上面就是一个完成程序的主要文件展示，这个程序大概有三百多个文件（包括java文件和资源文件），这里就不一一展示了！
大家可以想象一下，如果这个程序包名和文件名都没有很好规划，那么你要找你想要的几个文件是一个多么麻烦的事情！
一般地，我在创建每个java程序文件都会在上面做几句话的注解，说明一下这个文件的作用，有些布局文件也是有简单说明。这样更加有利于后期的程序代码迭代或版本更新！
命名规范是必须的吗？有些是！有些不是。比如包名、类的定义，系统没有硬性规定，但是资源文件res文件夹下的命名，系统要求资源文件名必须小写，否则，你的程序一直运行不了，你都不知道为啥。
最后说一句：程序开发中命名规范是一个很好的开发习惯！