同理，启动相关 Fragment 在其内部输入 newInstance 即可，如下所示：
public static MainFragment newInstance(User user) {
Bundle args = new Bundle();
args.putParcelable(ARGUMENT_USER, user);
MainFragment fragment = new MainFragment();
fragment.setArguments(args);
return fragment;
}
注意：这些函数需要放在
onCreate()之前的类的顶部；如果我们使用了这种方式，那么extras和arguments的键应该是private的，因为它们不再需要暴露给其他类来使用。
4.7 行长限制
代码中每一行文本的长度都应该不超过 100 个字符。虽然关于此规则存在很多争论，但最终决定仍是以 100 个字符为上限，如果行长超过了 100（AS 窗口右侧的竖线就是设置的行宽末尾 ），我们通常有两种方法来缩减行长。
- 提取一个局部变量或方法（最好）。
- 使用换行符将一行换成多行。
不过存在以下例外情况：
- 如果备注行包含长度超过 100 个字符的示例命令或文字网址，那么为了便于剪切和粘贴，该行可以超过 100 个字符。
- 导入语句行可以超出此限制，因为用户很少会看到它们（这也简化了工具编写流程）。
4.7.1 换行策略
这没有一个准确的解决方案来决定如何换行，通常不同的解决方案都是有效的，但是有一些规则可以应用于常见的情况。
4.7.1.1 操作符的换行
除赋值操作符之外，我们把换行符放在操作符之前，例如：
int longName = anotherVeryLongVariable + anEvenLongerOne - thisRidiculousLongOne
- theFinalOne;
赋值操作符的换行我们放在其后，例如：
int longName =
anotherVeryLongVariable + anEvenLongerOne - thisRidiculousLongOne + theFinalOne;
4.7.1.2 函数链的换行
当同一行中调用多个函数时（比如使用构建器时），对每个函数的调用应该在新的一行中，我们把换行符插入在 . 之前。
例如：
Picasso.with(context).load(“https://blankj.com/images/avatar.jpg”).into(ivAvatar);
我们应该使用如下规则：
Picasso.with(context)
.load(“https://blankj.com/images/avatar.jpg”)
.into(ivAvatar);
4.7.1.3 多参数的换行
当一个方法有很多参数或者参数很长的时候，我们应该在每个 , 后面进行换行。
比如：
loadPicture(context, “https://blankj.com/images/avatar.jpg”, ivAvatar, “Avatar of the user”, clickListener);
我们应该使用如下规则：
loadPicture(context,
“https://blankj.com/images/avatar.jpg”,
ivAvatar,
“Avatar of the user”,
clickListener);
4.7.1.4 RxJava 链式的换行
RxJava 的每个操作符都需要换新行，并且把换行符插入在 . 之前。
例如：
public Observable syncLocations() {
return mDatabaseHelper.getAllLocations()
.concatMap(new Func1<Location, Observable<? extends Location>>() {
@Override
public Observable<? extends Location> call(Location location) {
return mRetrofitService.getLocation(location.id);
}
})
.retry(new Func2<Integer, Throwable, Boolean>() {
@Override
public Boolean call(Integer numRetries, Throwable throwable) {
return throwable instanceof RetrofitError;
}
});
}
5 资源文件规范
资源文件命名为全部小写，采用下划线命名法。
如果是组件化开发，我们可以在组件和公共模块间创建一个 ui 模块来专门存放资源文件，然后让每个组件都依赖 ui 模块。这样做的好处是如果老项目要实现组件化的话，只需把资源文件都放入 ui 模块即可，如果想对资源文件进行分包，可以参考我这篇文章：Android Studio 下对资源进行分包；还避免了多个模块间资源不能复用的问题。
如果是三方库开发，其使用到的资源文件及相关的 name 都应该使用库名作为前缀，这样做可以避免三方库资源和实际应用资源重名的冲突。
5.1 动画资源文件（anim/ 和 animator/）
安卓主要包含属性动画和视图动画，其视图动画包括补间动画和逐帧动画。属性动画文件需要放在 res/animator/ 目录下，视图动画文件需放在 res/anim/ 目录下。
命名规则：{模块名_}逻辑名称。
说明：{} 中的内容为可选，逻辑名称 可由多个单词加下划线组成。
例如：refresh_progress.xml、market_cart_add.xml、market_cart_remove.xml。
如果是普通的补间动画或者属性动画，可采用：动画类型_方向 的命名方式。
例如：
| 名称 | 说明 |
|---|---|
fade_in | 淡入 |
fade_out | 淡出 |
push_down_in | 从下方推入 |
push_down_out | 从下方推出 |
push_left | 推向左方 |
slide_in_from_top | 从头部滑动进入 |
zoom_enter | 变形进入 |
slide_in | 滑动进入 |
shrink_to_middle | 中间缩小 |
5.2 颜色资源文件（color/）
专门存放颜色相关的资源文件。
命名规则：类型{_模块名}_逻辑名称。
说明：{} 中的内容为可选。
例如：sel_btn_font.xml。
颜色资源也可以放于 res/drawable/ 目录，引用时则用 @drawable 来引用，但不推荐这么做，最好还是把两者分开。
5.3 图片资源文件（drawable/ 和 mipmap/）
res/drawable/ 目录下放的是位图文件（.png、.9.png、.jpg、.gif）或编译为可绘制对象资源子类型的 XML 文件，而 res/mipmap/ 目录下放的是不同密度的启动图标，所以 res/mipmap/ 只用于存放启动图标，其余图片资源文件都应该放到 res/drawable/ 目录下。
命名规则：类型{_模块名}_逻辑名称、类型{_模块名}_颜色。
说明：{} 中的内容为可选；类型 可以是可绘制对象资源类型，也可以是控件类型（具体见附录UI 控件缩写表）；最后可加后缀 _small 表示小图，_big 表示大图。
例如：
| 名称 | 说明 |
|---|---|
btn_main_about.png | 主页关于按键 类型_模块名_逻辑名称 |
btn_back.png | 返回按键 类型_逻辑名称 |
divider_maket_white.png | 商城白色分割线 类型_模块名_颜色 |
ic_edit.png | 编辑图标 类型_逻辑名称 |
bg_main.png | 主页背景 类型_逻辑名称 |
btn_red.png | 红色按键 类型_颜色 |
btn_red_big.png | 红色大按键 类型_颜色 |
ic_head_small.png | 小头像图标 类型_逻辑名称 |
bg_input.png | 输入框背景 类型_逻辑名称 |
divider_white.png | 白色分割线 类型_颜色 |
bg_main_head.png | 主页头部背景 类型_模块名_逻辑名称 |
def_search_cell.png | 搜索页面默认单元图片 类型_模块名_逻辑名称 |
ic_more_help.png | 更多帮助图标 类型_逻辑名称 |
divider_list_line.png | 列表分割线 类型_逻辑名称 |
sel_search_ok.xml | 搜索界面确认选择器 类型_模块名_逻辑名称 |
shape_music_ring.xml | 音乐界面环形形状 类型_模块名_逻辑名称 |
如果有多种形态，如按钮选择器：sel_btn_xx.xml，采用如下命名：
| 名称 | 说明 |
|---|---|
sel_btn_xx | 作用在 btn_xx 上的 selector |
btn_xx_normal | 默认状态效果 |
btn_xx_pressed | state_pressed 点击效果 |
btn_xx_focused | state_focused 聚焦效果 |
btn_xx_disabled | state_enabled 不可用效果 |
btn_xx_checked | state_checked 选中效果 |
btn_xx_selected | state_selected 选中效果 |
btn_xx_hovered | state_hovered 悬停效果 |
btn_xx_checkable | state_checkable 可选效果 |
btn_xx_activated | state_activated 激活效果 |
btn_xx_window_focused | state_window_focused 窗口聚焦效果 |
注意：使用 Android Studio 的插件 SelectorChapek 可以快速生成 selector，前提是命名要规范。
5.4 布局资源文件（layout/）
命名规则：类型_模块名、类型{_模块名}_逻辑名称。
说明：{} 中的内容为可选。
例如：
| 名称 | 说明 |
|---|---|
activity_main.xml | 主窗体 类型_模块名 |
activity_main_head.xml | 主窗体头部 类型_模块名_逻辑名称 |
fragment_music.xml | 音乐片段 类型_模块名 |
fragment_music_player.xml | 音乐片段的播放器 类型_模块名_逻辑名称 |
dialog_loading.xml | 加载对话框 类型_逻辑名称 |
ppw_info.xml | 信息弹窗（PopupWindow） 类型_逻辑名称 |
item_main_song.xml | 主页歌曲列表项 类型_模块名_逻辑名称 |
5.5 菜单资源文件（menu/）
菜单相关的资源文件应放在该目录下。
命名规则：{模块名_}逻辑名称
说明：{} 中的内容为可选。
例如：main_drawer.xml、navigation.xml。
5.6 values 资源文件（values/）
values/ 资源文件下的文件都以 s 结尾，如 attrs.xml、colors.xml、dimens.xml，起作用的不是文件名称，而是 <resources> 标签下的各种标签，比如 <style> 决定样式，<color> 决定颜色，所以，可以把一个大的 xml 文件分割成多个小的文件，比如可以有多个 style 文件，如 styles.xml、styles_home.xml、styles_item_details.xml、styles_forms.xml。
5.6.1 colors.xml
<color> 的 name 命名使用下划线命名法，在你的 colors.xml 文件中应该只是映射颜色的名称一个 ARGB 值，而没有其它的。不要使用它为不同的按钮来定义 ARGB 值。
例如，不要像下面这样做：
#FFFFFF #2A91BD #5F5F5F #939393 #FFFFFF #FF9D2F ... #323232使用这种格式，会非常容易重复定义 ARGB 值，而且如果应用要改变基色的话会非常困难。同时，这些定义是跟一些环境关联起来的，如 button 或者 comment，应该放到一个按钮风格中，而不是在 colors.xml 文件中。
相反，应该这样做：
#FFFFFF
#DBDBDB
#939393
#5F5F5F
#323232
#27D34D
#2A91BD
#FF9D2F
#FF432F
向应用设计者那里要这个调色板，名称不需要跟 "green"、"blue" 等等相同。"brand_primary"、"brand_secondary"、"brand_negative" 这样的名字也是完全可以接受的。像这样规范的颜色很容易修改或重构，会使应用一共使用了多少种不同的颜色变得非常清晰。通常一个具有审美价值的 UI 来说，减少使用颜色的种类是非常重要的。
注意：如果某些颜色和主题有关，那就单独写一个
colors_theme.xml。
5.6.2 dimens.xml
像对待 colors.xml 一样对待 dimens.xml 文件，与定义颜色调色板一样，你同时也应该定义一个空隙间隔和字体大小的“调色板”。 一个好的例子，如下所示：
22sp
18sp
15sp
12sp
40dp
24dp
14dp
10dp
4dp
60dp
40dp
32dp
布局时在写 margins 和 paddings 时，你应该使用 spacing_xx 尺寸格式来布局，而不是像对待 string 字符串一样直接写值，像这样规范的尺寸很容易修改或重构，会使应用所有用到的尺寸一目了然。 这样写会非常有感觉，会使组织和改变风格或布局非常容易。
5.6.3 strings.xml
<string> 的 name 命名使用下划线命名法，采用以下规则：{模块名_}逻辑名称，这样方便同一个界面的所有 string 都放到一起，方便查找。
| 名称 | 说明 |
|---|---|
main_menu_about | 主菜单按键文字 |
friend_title | 好友模块标题栏 |
friend_dialog_del | 好友删除提示 |
login_check_email | 登录验证 |
dialog_title | 弹出框标题 |
button_ok | 确认键 |
loading | 加载文字 |
5.6.4 styles.xml
<style> 的 name 命名使用大驼峰命名法，几乎每个项目都需要适当的使用 styles.xml 文件，因为对于一个视图来说，有一个重复的外观是很常见的，将所有的外观细节属性（colors、padding、font）放在 styles.xml 文件中。 在应用中对于大多数文本内容，最起码你应该有一个通用的 styles.xml 文件，例如：
应用到 TextView 中：
或许你需要为按钮控件做同样的事情，不要停止在那里，将一组相关的和重复 android:xxxx 的属性放到一个通用的 <style> 中。
5.7 id 命名
命名规则：view 缩写{_模块名}_逻辑名，例如： btn_main_search、btn_back。
如果在项目中有用黄油刀的话，使用 AS 的插件：ButterKnife Zelezny，可以非常方便帮助你生成注解；没用黄油刀的话可以使用 Android Code Generator 插件。
6 版本统一规范
Android 开发存在着众多版本的不同，比如 compileSdkVersion、minSdkVersion、targetSdkVersion 以及项目中依赖第三方库的版本，不同的 module 及不同的开发人员都有不同的版本，所以需要一个统一版本规范的文件。
具体可以参考我写的这篇博文：Android 开发之版本统一规范。
如果是开发多个系统级别的应用，当多个应用同时用到相同的 so 库时，一定要确保 so 库的版本一致，否则可能会引发应用崩溃。
7 第三方库规范
别再闭门造车了，用用最新最火的技术吧，安利一波：Android 流行框架查速表，顺便带上自己的干货：Android 开发人员不得不收集的代码。
希望 Team 能用时下较新的技术，对开源库的选取，一般都需要选择比较稳定的版本，作者在维护的项目，要考虑作者对 issue 的解决，以及开发者的知名度等各方面。选取之后，一定的封装是必要的。
个人推荐 Team 可使用如下优秀轮子：
- Retrofit
- RxAndroid
- OkHttp
- Glide/Fresco
- Gson/Fastjson
- EventBus/AndroidEventBus
- GreenDao
- Dagger2（选用）
- Tinker（选用）
8 注释规范
为了减少他人阅读你代码的痛苦值，请在关键地方做好注释。
8.1 类注释
每个类完成后应该有作者姓名和联系方式的注释，对自己的代码负责。
/**
-
author : Blankj -
e-mail : xxx@xx -
time : 2017/03/07 -
desc : xxxx 描述 -
version: 1.0
*/
public class WelcomeActivity {
…
}
具体可以在 AS 中自己配制，进入 Settings -> Editor -> File and Code Templates -> Includes -> File Header，输入
/**
-
author : ${USER} -
e-mail : xxx@xx -
time : ${YEAR}/${MONTH}/${DAY} -
desc : -
version: 1.0
*/
这样便可在每次新建类的时候自动加上该头注释。
8.2 方法注释
每一个成员方法（包括自定义成员方法、覆盖方法、属性方法）的方法头都必须做方法头注释，在方法前一行输入 /** + 回车 或者设置 Fix doc comment（Settings -> Keymap -> Fix doc comment）快捷键，AS 便会帮你生成模板，我们只需要补全参数即可，如下所示。
/**
- bitmap 转 byteArr
- @param bitmap bitmap 对象
- @param format 格式
- @return 字节数组
*/
public static byte[] bitmap2Bytes(Bitmap bitmap, CompressFormat format) {
if (bitmap == null) return null;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
bitmap.compress(format, 100, baos);
return baos.toByteArray();
}
8.3 块注释
块注释与其周围的代码在同一缩进级别。它们可以是 /* ... */ 风格，也可以是 // ... 风格（// 后最好带一个空格）。对于多行的 /* ... */ 注释，后续行必须从 * 开始， 并且与前一行的 * 对齐。以下示例注释都是 OK 的。
/*
- This is
- okay.
*/
// And so
// is this.
/* Or you can
- even do this. */
注释不要封闭在由星号或其它字符绘制的框架里。
Tip：在写多行注释时，如果你希望在必要时能重新换行（即注释像段落风格一样），那么使用
/* ... */。
8.4 其他一些注释
AS 已帮你集成了一些注释模板，我们只需要直接使用即可，在代码中输入 todo、fixme 等这些注释模板，回车后便会出现如下注释。
// TODO: 17/3/14 需要实现，但目前还未实现的功能的说明
// FIXME: 17/3/14 需要修正，甚至代码是错误的，不能工作，需要修复的说明
9 测试规范
业务开发完成之后，开发人员做单元测试，单元测试完成之后，保证单元测试全部通过，同时单元测试代码覆盖率达到一定程度（这个需要开发和测试约定，理论上越高越好），开发提测。
9.1 单元测试
测试类的名称应该是所测试类的名称加 Test，我们创建 DatabaseHelper 的测试类，其名应该叫 DatabaseHelperTest。
测试函数被 @Test 所注解，函数名通常以被测试的方法为前缀，然后跟随是前提条件和预期的结果。
- 模板：
void methodName 前提条件和预期结果() - 例子：
void signInWithEmptyEmailFails()
注意：如果函数足够清晰，那么前提条件和预期的结果是可以省略的。
有时一个类可能包含大量的方法，同时需要对每个方法进行几次测试。在这种情况下，建议将测试类分成多个类。例如，如果 DataManager 包含很多方法，我们可能要把它分成 DataManagerSignInTest、DataManagerLoadUsersTest 等等。
9.2 Espresso 测试
每个 Espresso 测试通常是针对 Activity，所以其测试名就是其被测的 Activity 的名称加 Test，比如 SignInActivityTest。
10 其他的一些规范
-
合理布局，有效运用
<merge>、<ViewStub>、<include>标签； -
Activity和Fragment里面有许多重复的操作以及操作步骤，所以我们都需要提供一个BaseActivity和BaseFragment，让所有的Activity和Fragment都继承这个基类。 -
方法基本上都按照调用的先后顺序在各自区块中排列；
-
相关功能作为小区块放在一起（或者封装掉）；
-
当一个类有多个构造函数，或是多个同名函数，这些函数应该按顺序出现在一起，中间不要放进其它函数；
-
数据提供统一的入口。无论是在 MVP、MVC 还是 MVVM 中，提供一个统一的数据入口，都可以让代码变得更加易于维护。比如可使用一个
DataManager，把http、preference、eventpost、database都放在DataManager里面进行操作，我们只需要与DataManager打交道； -
多用组合，少用继承；
-
提取方法，去除重复代码。对于必要的工具类抽取也很重要，这在以后的项目中是可以重用的。
-
可引入
Dagger2减少模块之间的耦合性。Dagger2是一个依赖注入框架，使用代码自动生成创建依赖关系需要的代码。减少很多模板化的代码，更易于测试，降低耦合，创建可复用可互换的模块； -
项目引入
RxAndroid响应式编程，可以极大的减少逻辑代码； -
通过引入事件总线，如：
EventBus、AndroidEventBus、RxBus，它允许我们在DataLayer中发送事件，以便ViewLayer中的多个组件都能够订阅到这些事件，减少回调； -
尽可能使用局部变量；
-
及时关闭流；
-
尽量减少对变量的重复计算；
如下面的操作：
for (int i = 0; i < list.size(); i++) {
…
}
建议替换为：
for (int i = 0, len = list.size(); i < len; i++) {
…
}
- 尽量采用懒加载的策略，即在需要的时候才创建；
例如：
String str = “aaa”;
if (i == 1) {
list.add(str);
}
建议替换为：
if (i == 1) {
String str = “aaa”;
list.add(str);
}
-
不要在循环中使用
try…catch…，应该把其放在最外层； -
使用带缓冲的输入输出流进行 IO 操作；
-
尽量使用
HashMap、ArrayList、StringBuilder，除非线程安全需要，否则不推荐使用HashTable、Vector、StringBuffer，后三者由于使用同步机制而导致了性能开销； -
尽量在合适的场合使用单例；
使用单例可以减轻加载的负担、缩短加载的时间、提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：
-
控制资源的使用，通过线程同步来控制资源的并发访问。
-
控制实例的产生，以达到节约资源的目的。
-
控制数据的共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。
-
把一个基本数据类型转为字符串，
基本数据类型.toString()是最快的方式，String.valueOf(数据)次之，数据 + ""最慢； -
使用 AS 自带的 Lint 来优化代码结构（什么，你不会？右键 module、目录或者文件，选择 Analyze -> Inspect Code）；
-
最后不要忘了内存泄漏的检测；
最后啰嗦几句：
- 好的命名规则能够提高代码质量，使得新人加入项目的时候降低理解代码的难度；
- 规矩终究是死的，适合团队的才是最好的；
- 命名规范需要团队一起齐心协力来维护执行，在团队生活里，谁都不可能独善其身；
- 一开始可能会有些不习惯，持之以恒，总会成功的。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
学习福利
【Android 详细知识点思维脑图（技能树）】
其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。
虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。
这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。
由于篇幅有限，这里以图片的形式给大家展示一小部分。
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
中…(img-Vgo02tSW-1711624061614)]
学习福利
【Android 详细知识点思维脑图（技能树）】
[外链图片转存中…(img-Z0bJxy1S-1711624061615)]
其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。
虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。
这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。
由于篇幅有限，这里以图片的形式给大家展示一小部分。
[外链图片转存中…(img-qrCG3Mpr-1711624061615)]
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
