浅谈Android开发中项目的文件结构及规范化部署建议

一、几句话

• 使用gradle及其推荐的项目框架
• 把密码等敏感数据放入gradle.properties
• 不要自己写http客户端，使用volley或okhttp库
• 使用jackson库来解析json数据
• 避免guava并出于dalvik 65k methods limit不要使用过多的库
• 使用fragment来绘制ui界面
• activity主要用来管理fragment
• 布局文件xml也是代码，好好组织它们
• 在布局文件里，使用styles以避免重复的属性
• 使用多个style文件而不是一个巨大的style文件
• 保持你的 color.xml 短小而dry，定义色盘
• 同样保持 dimens.xml dry，定义通用常量
• 不要创建一个太深层次的布局
• 避免webview的客户端处理，而且要注意内存泄露
• 使用robolectric来进行单元测试，robotium来进行连接（ui）测试
• 仿真器用genymotion
• 一定要用proguard 或 dexguard

二、详细
android sdk
把你的android sdk放置在你的主目录里或其他与应用无关的地方。一些ides在安装的时候会把sdk关联上，并把sdk放在ide的同一个目录下。当你需要升级（重装）ide或者更换ide时你就会发现糟糕之处啦。另外，如果你的ide在一个user账户下而不是在root下运行的话，就不要把sdk放在系统级目录下，否则在使用时需要 sudo 权限，

build system
默认的选择是 gradle。ant限制比较多而且太大。使用gradle，你可以很轻易的做到：
-编译不同的flavours 或应用的 variants
-创建简单的 类-脚本 任务
-管理和下载依赖
-自定义keystores
-等等
android的gradle插件同样被google指定为新的标准编译系统，而且google不断为其升级。

项目结构
有两种流行的选择：旧的ant & eclipse adt项目结构；新的gradle & android studio项目结构。你应该选择后者。如果你的项目使用旧的结构，那么换掉吧。
旧结构

old-structure 
├─ assets
├─ libs
├─ res
├─ src
│ └─ com/futurice/project
├─ androidmanifest.xml
├─ build.gradle
├─ project.properties
└─ proguard-rules.pro

新结构

new-structure
├─ library-foobar
├─ app
│ ├─ libs
│ ├─ src
│ │ ├─ androidtest
│ │ │ └─ java
│ │ │ └─ com/futurice/project
│ │ └─ main
│ │ ├─ java
│ │ │ └─ com/futurice/project
│ │ ├─ res
│ │ └─ androidmanifest.xml
│ ├─ build.gradle
│ └─ proguard-rules.pro
├─ build.gradle
└─ settings.gradle

新结构主要的不同在于拆分了'源代码集' (main,androidtest)，这是来自gradle的理念。
使用*别"app"有利于将你的app和其他你的应用所引用的库项目（如：library-foobar）做区分。然后settings.gradle保持应用对这些库的索引，而app/build.gradle可以指向这些库。

gradle配置
通用架构请遵循google's guide on gradle for android；
小任务（脚本），你可以使用gradle来制作小任务而不是shell、python或perl等，具体参考gradle's documentation；
密码。在你应用的build.gradle中你需要为发布编译定义 signingconfigs。具体如下：
不要像下面这样写，这样会出现在你的版本控制系统里：

signingconfigs { 
  release {  
   storefile file("myapp.keystore")  
   storepassword"password123"
   keyalias"thekey"
   keypassword"password789"
  }
}

相反，你应该创建一个不会被添加到版本控制系统里的gradle.properties文件

keystore_password=password123
key_password=password789

这个文件会被gradle自动导入，所以你可以在build.gradle这样使用：

signingconfigs { 
  release {
  try{
    storefile file("myapp.keystore")  
    storepasswordkeystore_password  
    keyalias"thekey"
    keypasswordkey_password
 } catch(ex) {
  thrownewinvaliduserdataexception("you should define keystore_password and key_password in gradle.properties.")  
  }
 }}

（如果使用maven可参考）

库
jackson是一个java库，它可以实现对象和json数据的相互转换。gson 也是一个类似的不错选择。不过我们觉得jsckson更好因为它支持多种方式来处理json：流式，内存树模型和传动的json-pojo数据绑定。但是，记住，jackson比gson更加庞大，所以你要酌情考虑，如果你想避免 65k methods limit那最好用gson。其他选择：json-smart 和 boon json
网络、缓存和图片。使用volley 或者retrofit。volley也可以用来加载和缓存图片。如果你选择retrofit，你可以用picasso 来加载和缓存图片。然后使用 okhttp 来执行有效的http请求。这三种：retrofit、picasso和okhttp都来源于同一样公司，所以它们互相补充。okhttp 能用来与 volley 相连接。
rxjava是一个响应式编程库，换句话说，处理异步事件。（具体可参考）
retrolambda 是一个java库，它帮助你的android或者其他早于jdk8平台上使用lambda表达式。（具体可参考）
最后，记住dex方法限制，不要使用太多库。（android应用，当被打包成dex文件时，有一个最大限制：65535个引用方法[1][2][3]。如果你超过了限制就会发生严重错误。因此，不要使用刚过多库，使用 工具来决定使用哪些类从而保持在限制内，尤其要避免使用guava库，因为它包含超过13k方法）
activities和fragments
fragments应该是你在android部署ui界面的默认选项。fragments可以在你的应用里重用。我们推荐使用fragements而不是 activities 来绘制界面基于以下几点：

• 解决是多视图布局。fragments被引入进来的主要原因是把手机应用程序拓展到平台电脑上，这样的话你在平板上可以同时显示a和b视图，而在手机上可只显示a或b。如果你的程序最开始就是使用fragment来实现，那么你的程序可以更容易适用于多种设备。
• 屏到屏的通信。android的api并不提供一个合适的方式来实现activity之间传递复杂数据（如java对象）。但是，使用fragment，你可以利用activity来成为其子fragment之间通信的通道。即使这比activity-到-activity通信要好不少，我仍然建议你采取event bus架构，例如使用otto 或者 greenrobot eventbus来作为一个更简洁的方案。如果你不想采取附加的库，那么rxjava也可以被用来实现一个eventbus。
• fragment不仅仅可以用来布局ui。你可以添加一个 没有ui界面的fragment 作为activity的后台服务者。甚至你可以创建一个fragment来实现fragment切换逻辑，而不是让activity去处理fragment切换逻辑。
• fragment里甚至可以管理actionbar。你可以选择一个没有ui界面的fragment来专门管理actionbar，或者你可以选择每个当前可视的fragment自己来处理父activity的actionbar。参考这里。
• 然后，我们也不建议过度使用嵌套fragments，那可能导致matryoshka 漏洞。
• 从架构的角度来考虑，你的应用应该有一个*activity，它会包含大部分业务相关的fragments。你也可以创建一些其他的支持性activities，只要它们与主activity的通信保持简单--形似与 intent.setdata()或intent.setaction()。

java包结构

在android应用程序里的java结构接近mvc结构（model-view-controller）。在android里，fragment和activity实际上都是控制器类。而从另一角度来看，他们又是用户交互的一部分，也就是说属于视图view类。
因此，我们很难严格区分fragment（或activity）是控制器还是视图。所以从java包角度来看，我们最好把fragment放在它们自己的fragments包里，然后activity放在*的包里面（遵循上文提出的建议）。当然，如果你想有2个或以上的activity，那你就创建一个activitys包。
这样的话，整个结构看起来就是一个典型的mvc结构。一个models包包含pojos，用来转化api接口获取的json数据，一个views包包含views，notifications，action bar views，widgets等。adapters是一个中间层，位于数据和视图之间。但是，它们通常需要通过getview()来输出view视图，所以你可以把adapters放在views包的子包位置。
一些应用程序级别、仅属于android系统的控制器类，应该放在managers包里。各种各样的数据处理类，例如dateutils可以放在utils包里。与后台服务器交互的类应该放在network包里。
总之，从与服务器交互到与用户交互的整体架构可设计如下：

com.futurice.project
├─ network
├─ models
├─ managers
├─ utils
├─ fragments
├─ views
  ├─ adapters
  ├─ actionbar
  ├─ widgets
  ├─ notifications

资源文件
命名
遵循加前缀的惯例，类似type_foo_bar.xml，如：fragment_contact_details.xml，view_primary_button.xml，activity_main.xml。

组织布局文件
如果你不知道如何规范化一个布局xml文件，可参考下面惯例：

• 每行一个属性，缩进4个空格；
• android:id永远放在第一个；
• android:layout_** 属性要放在顶部；
• style属性放在尾部；
• 结束标志位 />要独占一行，有助于对属性排序或添加；
• 不要写hard code，如 android:text，对于android studio来说可考虑使用designtime attributes方法。

<?xml version="1.0" encoding="utf-8"?>
<linearlayout
 xmlns:android="http://schemas.android.com/apk/res/android"
 xmlns:tools="http://schemas.android.com/tools"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 android:orientation="vertical"
>

  <textview
   android:id="@+id/name"
   android:layout_width="match_parent"
   android:layout_height="wrap_content"
   android:layout_alignparentright="true"
   android:text="@string/name"
   style="@style/fancytext"
  />

  <include layout="@layout/reusable_part" />

</linearlayout>