[转]Android开发最佳实践

——欢迎转载，请注明出处 http://blog.csdn.net/asce1885 ，未经本人赞成请勿用于商业用途，谢谢——

原文连接：https://github.com/futurice/android-best-practices

本文是Futurice公司的Android开发人员总结的最佳实践，遵循这些准则能够避免重复制造轮子。若是你对iOS或者Windows Phone开发感兴趣，那么也请看看iOS最佳实践和Windows客户端开发最佳实践。

概要

使用Gradle和推荐的工程结构

把密码和敏感数据存放在gradle.properties文件中

不要本身实现HTTP客户端，要使用Volley或者OkHttp库

使用Jackson库来解析JSON数据

避免使用Guava，使用少许的函数库从而避免超出65k方法数限制

使用Fragments来表示UI界面

Activities只用来管理Fragments

布局XML文件是代码，要组织好它们

使用样式文件来避免布局XML文件中属性的重复定义

使用多个样式文件避免单一大样式文件的使用

保持colors.xml文件简短和不重复，只定义颜色值

保持dimens.xml文件不重复，并只定义通用的常量

避免ViewGroups层次结构太深

避免在客户端侧处理WebViews，谨防内存泄漏

使用Robolectric做为单元测试的工具，Robotium做为UI测试的工具

使用Genymotion做为你的模拟器

老是使用ProGuard或者DexGuard

Android SDK

把你的Android SDK目录放在电脑的主目录或者其余跟IDE安装目录独立的磁盘位置，某些IDE在安装时就包含了Android SDK，并且可能把它放在跟IDE相同的目录下。当你须要升级（或从新安装）IDE，或者更换IDE时，这种作法是很差的。一样要避免把Android SDK放在另一个系统层级的目录中，这样当你的IDE在user模式下运行而不是root模式时，将须要sudo权限。

构建系统

 

你的默认选择应该是Gradle。相比之下，Ant限制更大并且使用起来更繁琐。使用Gradle能够很简单的实现：

1）将你的app编译成不一样的版本；

2）实现简单的相似脚本的任务；

3）管理和下载第三方依赖项；

4）自定义密钥库；

5）其余

Google也在积极的开发Android的Gradle插件，以此做为新的标准编译系统。

 

工程结构

 

目前有两个流行的选择：之前的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引入的概念。例如，你能够在源码目录src中添加paid和free两个子目录，分别用来存放付费版和免费版app的源码。

顶层的app目录有助于把你的app和工程中会引用到的其余库工程（例如library-foobar）区分开。settings.gradle文件中记录了这些库工程的引用，这样app/build.gradle就可以引用到了。

Gradle配置

 

通常结构：参见 Google的安卓Gradle指南。

小任务：在Gradle中，咱们使用tasks而不是脚本（shell，Python，Perl等使用脚本），详细的内容可参见 Gradle文档。

密码：发布release版本时，你须要在app目录下面的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")
            storePassword KEYSTORE_PASSWORD
            keyAlias "thekey"
            keyPassword KEY_PASSWORD
        }
        catch (ex) {
            throw new InvalidUserDataException("You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.")
        }
    }
}

优先选择Maven依赖而不是导入jar文件。若是你在工程中显式地包含jar文件，它们会是特定的不可变的版本，例如2.1.1。下载jar包并手动更新是很麻烦的，而这个问题Maven正好帮咱们解决了，在Android Gradle构建中也建议这么作。你能够指定某个版本范围的jar包，例如2.1.＋，这样Maven会帮咱们自动更新和这个版本模式匹配的后续升级。例子以下：

dependencies {
    compile 'com.netflix.rxjava:rxjava-core:0.19.+'
    compile 'com.netflix.rxjava:rxjava-android:0.19.+'
    compile 'com.fasterxml.jackson.core:jackson-databind:2.4.+'
    compile 'com.fasterxml.jackson.core:jackson-core:2.4.+'
    compile 'com.fasterxml.jackson.core:jackson-annotations:2.4.+'
    compile 'com.squareup.okhttp:okhttp:2.0.+'
    compile 'com.squareup.okhttp:okhttp-urlconnection:2.0.+'
}

IDE和文本编辑器

使用任何保持良好工程结构的代码编辑器。代码编辑器是我的喜爱的选择，你须要作的是保证你所用的编辑器可以和工程结构以及构建系统良好集成。

 

当下最受推崇的IDE是Android Studio，由于它是Google开发的，和Gradle耦合最好，默认使用最新的工程结构，已经处于稳定阶段，是为Android开发量身定作的IDE。

固然你也可使用Eclipse ADT，但你须要配置它才能使用Gradle，由于它默认使用的是旧的工程结构和使用Ant进行构建。你甚至可使用相似Vim，Sublime Text，Emacs等文本编辑器，这种状况下你须要在命令行中使用Gradle和adb。若是你的Eclipse集成Gradle不可用，你的选择是要么使用命令行编译或者把项目迁移到Android Studio中。Android Studio是最好的选择，由于ADT插件已经被标记为过期了，也就是不会再做后续维护和更新了。

不管你使用哪一种方式，需保证的是按照官方的推荐使用新的工程结构和Gradle来构建你的应用，并避免把你特定于编辑器的配置文件加入到版本控制系统中。例如要避免把Ant的build.xml文件添加到版本控制系统中。特别是若是你在Ant中更改了编译配置，不要忘了同步更新build.gradle文件。最后一点，要对其余开发人员友好，不要迫使他们修改他们所用编辑器的偏好设置。

函数库

Jackson是一个把Java对象转换为JSON字符串或者把JSON字符串转换成Java对象的Java函数库。Gson也是解决这类问题很流行的选择之一，但咱们发现Jackson更加高性能，由于它支持多种可选的处理JSON的方式：流，内存树模型和传统的JSON-POJO数据绑定。尽管如此，Jackson是比Gson更大的函数库，因此须要根据你项目的具体状况，你可能会选择GSON来避免65k方法数限制。其余的选择还有：Json-smart和Boon JSON。

网络，缓存和图像。向后端服务器发起网络请求有不少通过实战检验的解决方案，你应该使用这些解决方案而不是本身实现一个。使用Volley或者Retrofit吧！除了网络请求，Volley还提供了帮助类用于加载和缓存图像。若是你选择Retrofit，那么能够考虑使用Picasso做为加载和缓存图像的函数库，并结合OkHttp实现高效的HTTP请求。Retrofit，Picasso和OkHttp这三款函数库都是同一家公司开发的，因此它们可以很好的互补。Volley也能使用OkHttp来实现网络链接。

RxJava是一个响应式编程的函数库，也就是能够处理异步事件。这是一个强大和有前途的编程范式，但因为它是如此的不一样，所以会显得很差理解。在使用这个函数库搭建你的应用的框架时，咱们建议你要保持谨慎的态度。咱们有几个项目已经使用RxJava来实现，若是你须要帮助能够联系如下这些人：Timo Tuominen, Olli Salonen, Andre Medeiros, Mark Voit, Antti Lammi, Vera Izrailit, Juha Ristolainen。咱们已经写了一些博客文章来进行介绍

1）http://blog.futurice.com/tech-pick-of-the-week-rx-for-net-and-rxjava-for-android；

2）http://blog.futurice.com/top-7-tips-for-rxjava-on-android；

3）https://gist.github.com/staltz/868e7e9bc2a7b8c1f754；

4）http://blog.futurice.com/android-development-has-its-own-swift）。

若是你以前没有使用RxJava的经验，那么开始时能够仅在网络请求API的响应处使用。若是有经验了，能够将RxJava应用在简单UI事件的处理，例如点击事件或者搜索框中的输入事件。若是你对本身的RxJava技能很自信并且想把RxJava应用到整个项目架构中，那么在代码难以理解的部分要编写Javadocs。要记住对RxJava不熟悉的程序员可能在维护工程的初期会很痛苦。尽你所能帮助他们理解你的代码和RxJava。

Retrolambda是兼容在Android中和JDK8以前的Java版本中使用Lambda表达式语法的一个Java函数库。它帮助你的代码保持紧凑和可读，特别是当你使用函数式编程风格时，例如使用RxJava。要使用这个库，须要安装JDK8，在Android Studio工程结构对话框中设置SDK的位置，并设置JAVA8_HOME和JAVA7_HOME环境变量，而后在工程的build.gradle中设置以下：

 

dependencies {
    classpath 'me.tatarka:gradle-retrolambda:2.4.+'
}

接着在各个模块的build.gradle中增长配置以下：

 

 

apply plugin: 'retrolambda'

android {
    compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
}

retrolambda {
    jdk System.getenv("JAVA8_HOME")
    oldJdk System.getenv("JAVA7_HOME")
    javaVersion JavaVersion.VERSION_1_7
}

 

Android Studio提供了支持Java8 lambdas的代码辅助功能。若是你刚接触lambdas，能够参见下面的建议来开始：

1）任何只有一个函数的接口（Interface）是“lambda友好”的，能够被折叠为更紧凑的语法格式；

2）若是对参数或诸如此类的用法还存有怀疑的话，能够编写一个普通的匿名内部类而后让Android Studio帮你把它折叠成lambda表达式的形式。

要注意dex文件方法数限制的问题，避免使用太多的第三方函数库。当Android应用打包成一个dex文件时，存在最多65536个引用方法数的限制问题。当超出这个限制时，你将在编译阶段看到fatal error。所以，应该使用尽量少的第三方函数库，并使用dex-method-counts工具来决定使用哪些函数库的组合以免不超过该限制。特别要避免使用Guava函数库，由于它包含的方法数超过13k。

 

Activities and Fragments

 

在Android中实现UI界面默认应该选择Fragments。Fragments是可复用用户界面，可以在你的应用中很好的组合。咱们建议使用Fragments代替Activities来表示用户界面，下面是几点缘由：

1）多窗口布局的解决方案。最初引入Fragment的缘由是为了把手机应用适配到平板电脑屏幕上，这样你能够在平板电脑屏幕上具备A和B两个窗口，而到了手机屏幕上A或者B窗口独占整个手机屏幕。若是你的应用在最开始的时候是基于Fragments实现的，那么之后要适配到其余不一样类型的屏幕上面会容易得多。

2）不一样界面之间的通讯。Android API没有提供在Activity之间传递复杂数据（例如某些Java对象）的正确方法。对于Fragments而已，你可使用Activity的实例做为它的子Fragments之间通讯的通道。虽然这种方法比Activities之间的通讯更好，但你可能愿意考虑Event Bus框架，例如使用 Otto或者 green robot EventBus做为更简洁的方法。若是你想避免添加多一个函数库的话，RxJava也能够用于实现Event Bus。

3）Fragments足够通用，它不必定须要UI界面。你可使用 没有UI界面的Fragment来完成Activity的后台工做。你能够进一步拓展这个功能， 建立一个专门的后台Fragment来管理Activity的子Fragments之间的切换逻辑，这样就不用在Activity中实现这些逻辑了。

4）在Fragments里面也能够管理ActionBar。你能够选择建立一个没有UI界面的Fragment专门来管理ActionBar，或者选择让每一个Fragments在宿主Activity的ActionBar中添加它们本身的action items。更多请参考 http://www.grokkingandroid.com/adding-action-items-from-within-fragments/。

咱们建议不要大量的使用嵌套Fragments，这会致使 matryoshka bugs。只有在必要的时候（例如在Fragment屏幕中内嵌水平滑动的ViewPager）或者确实是明智的决定时才使用嵌套Fragments。

从软件架构的层面看，你的app应该具备一个包含大部分业务相关fragments的顶级activity。固然你也能够有其余辅助activities，这些activities与主activity的具备简单的数据通讯，例如经过Intent.setData()或者Intent.setAction()等等。

Java包结构

Android应用的Java包结构大体相似MVC模式。在Android中Fragment和Activity其实是controller类，另外一方面，它们显然也是用户界面的一部分，所以也是View类。

所以，很难严格界定Fragments（或者Activities）是controllers类仍是views类。最好把Fragments类单独放在fragments包里面。若是你遵循前面段落的建议的话（只有一个主Activity），Activities能够放在顶层的包里面。若是你计划会存在多个activities，那么就将Activity放在单独的activities包里面。

另外一方面，整个包结构看起来很像经典的MVC框架，models包目录存放网络请求API响应通过JSON解析器填充后获得的POJOs对象。views包目录存放自定义的views，notifications，action bar views，widgets等等。Adapters处于灰色地带，介于data和views之间，然而，它们通常须要经过getView()函数导出视图，因此你能够在views包中增长adapters子包。

 

有的controller类是应用范围的并和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。

组织布局XMLs。若是你对如何格式化布局XML文件不大清楚的话，那么下面的惯例或许能够帮你：

1）每行一个属性，缩进四个空格

2）android:id始终做为第一个属性

3）android:layout_****属性放在头部

4）style属性放在尾部

5）结束标签/>放在单独一行，便于新增属性或者从新排列属性

6）考虑使用Android Studio中的 Designtime attributes，而不使用android:text硬编码。

<?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>

通常来讲android:layout_****属性应该定义在XML布局文件中，而其余的android:****属性应该放在样式xml文件中。这条法则也有例外，但通常状况是这样的

。这种作法是为了在布局文件中只保留布局属性（位置，留白，大小）和内容属性，而其余外观细节（颜色，填充，字体）放到样式文件中。

例外的有：

1）android:id必须放在layout文件中

2）在LinearLayout中的android:orientation通常放在layout文件中更有意思

3）android:text必须放在layout文件中，由于它定义了内容

4）有时建立通用的style文件并定义android:layout_width和android:layout_height属性更有意思，但默认状况下这两个属性应该放在layout文件中。

 

使用styles。几乎全部工程都须要正确的使用styles，由于它是让view具备相同外观的常见的方法。你的应用的文本内容应该至少具备一个公用的样式，例如：

 

<style name="ContentText">
    <item name="android:textSize">@dimen/font_normal</item>
    <item name="android:textColor">@color/basic_black</item>
</style>

用在TextView上面以下：

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/price"
    style="@style/ContentText"
    />

你可能须要对buttons作相似的工做，但别就此停住。继续把相关的和重复的android:****属性分组到公用的style文件中。

把一个大的style文件细分红多个文件。你没有必要维护单独一个styles.xml文件，Android SDK能很好的支持其余文件。styles文件的名字并不必定要是styles.xml，起做用的是xml文件里面的<style>标签。所以，你的样式文件命名能够是styles.xml，styles_home.xml，styles_item_details.xml，styles_forms.xml等。和资源目录名不一样（编译系统须要根据资源目录名找到资源），res/values里面的文件名能够随意命名。

colors.xml是调色板。在你的colors.xml文件中除了定义颜色名字到RGBA颜色值的映射外，不该该定义其余的东西。不用使用它来定义不一样类型按钮的RGBA颜色值。

不要这样作：

 

<resources>
    <color name="button_foreground">#FFFFFF</color>
    <color name="button_background">#2A91BD</color>
    <color name="comment_background_inactive">#5F5F5F</color>
    <color name="comment_background_active">#939393</color>
    <color name="comment_foreground">#FFFFFF</color>
    <color name="comment_foreground_important">#FF9D2F</color>
    ...
    <color name="comment_shadow">#323232</color>

 

这样的使用很容易重复定义相同的RGBA值，这致使若是须要更改一个基本色值时会很麻烦。并且上面的这些定义是和上下文相关的，例如“button”，“comment”，这些应该放到button样式文件中，而不是colors.xml文件中。

应该这样作：

<resources>

    <!-- grayscale -->
    <color name="white"     >#FFFFFF</color>
    <color name="gray_light">#DBDBDB</color>
    <color name="gray"      >#939393</color>
    <color name="gray_dark" >#5F5F5F</color>
    <color name="black"     >#323232</color>

    <!-- basic colors -->
    <color name="green">#27D34D</color>
    <color name="blue">#2A91BD</color>
    <color name="orange">#FF9D2F</color>
    <color name="red">#FF432F</color>

</resources>

向应用的设计师要以上这些色值定义。命名不须要为颜色名字，如“green”，“blue”等，例如“brand_primary”，“brand_secondary”，“brand_negative”这样的命名也是彻底能够接受的。这样来格式化颜色值使得之后若是要修改或者重构颜色时很容易，同时应用中使用了多少种颜色也是一目了然的。对于一个美观的UI，减小使用的颜色种类是很重要的。

 

dimens.xml文件跟colors.xml文件具备相同的用法。你应该定义一个典型的间距和字体大小的模版，目的基本上和colors.xml文件同样，好的dimens.xml文件例子以下：

 

<resources>

    <!-- font sizes -->
    <dimen name="font_larger">22sp</dimen>
    <dimen name="font_large">18sp</dimen>
    <dimen name="font_normal">15sp</dimen>
    <dimen name="font_small">12sp</dimen>

    <!-- typical spacing between two views -->
    <dimen name="spacing_huge">40dp</dimen>
    <dimen name="spacing_large">24dp</dimen>
    <dimen name="spacing_normal">14dp</dimen>
    <dimen name="spacing_small">10dp</dimen>
    <dimen name="spacing_tiny">4dp</dimen>

    <!-- typical sizes of views -->
    <dimen name="button_height_tall">60dp</dimen>
    <dimen name="button_height_normal">40dp</dimen>
    <dimen name="button_height_short">32dp</dimen>

</resources>

布局文件的边距和填充应该使用spacing_****尺寸定义，而不是使用硬编码（相似字符串硬编码）。这样会带来统一的外观，同时使得组织和修改样式和布局更简单。

 

避免过深的views层级。有时你可能会被诱导在LinearLayout中再增长一层LinearLayout，例如为了完成一组views的排列。这种状况相似以下：

 

<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    >

    <RelativeLayout
        ...
        >

        <LinearLayout
            ...
            >

            <LinearLayout
                ...
                >

                <LinearLayout
                    ...
                    >
                </LinearLayout>

            </LinearLayout>

        </LinearLayout>

    </RelativeLayout>

</LinearLayout>

即便你没有很明显的在Layout文件中看到这种状况，但可能最终发生在Java代码中将某个view inflate到另外的view中。

 

这可能会引发一些问题，你可能会遇到性能问题，由于处理器须要处理很复杂的UI树层级。另外一个更严重的问题是可能会引发StackOverflowError。

所以，尽可能使你的view具备扁平的层级：学习怎样使用RelativeLayout，怎样优化布局和使用<merge>标签。

当心WebView相关的问题。当你须要展现一个web页面时，例如新闻文章，要避免在客户端侧对HTML进行简化处理，相反，应该向服务器端请求通过简化后的HTML。当WebView持有所在Activity Context引用而不是Application Context引用时，也可能致使内存泄漏。要避免在简单文本或者按钮使用WebView，应该使用TextView和Button。

测试框架

Android SDK的测试框架还很简单，尤为是UI测试相关的。Android Gradle目前实现了一个叫作connectedAndroidTest的测试任务，它可以使用JUnit的Android扩展来运行你建立的JUnit测试用例。这意味着你须要链接设备或者模拟器来运行测试用例，遵循官方帮助指南来进行测试1）http://developer.android.com/tools/testing/testing_android.html；

2）http://developer.android.com/tools/testing/activity_test.html）。

使用Robolectric来进行单元测试，而不是UI测试。这是一个为了提升开发速度，专一于提供“独立于设备”的测试框架，尤为适用于models和view models的单元测试。可是Robolectric对于UI测试的支持是不许确和不完善的。使用Robolectric进行动画，对话框等相关的UI元素测试时会遇到问题，你将看不到屏幕相应的UI元素被测试实时操纵，你将相似于在黑暗中行走。

Robotium简化了UI测试。你不须要Robotium来执行UI测试用例，但它提供了不少帮助工具用来获取和分析views，控制屏幕等，这一点对你可能颇有帮助。测试用例很简单，以下所示：

 

solo.sendKey(Solo.MENU);
solo.clickOnText("More"); // searches for the first occurence of "More" and clicks on it
solo.clickOnText("Preferences");
solo.clickOnText("Edit File Extensions");
Assert.assertTrue(solo.searchText("rtf"));

模拟器

 

若是你的工做是开发android app，那么买一个Genymotion模拟器的licence吧。Genymotion模拟器比AVD模拟器具备更快的帧率，并且具备演示app，模拟网络链接质量，GPS位置等工具。它也是用于链接测试的理想工具。使用Genymotion模拟器，你能够模拟不少不一样类型的设备，因此购买一个Genymotion模拟器licence比买多个真实设备更划算。

要注意的是：Genymotion模拟器没有移植全部的Google服务，例如Google Play Stoe和Google Maps。你可能须要测试三星特有的API，这时须要购买一台真实的三星设备。

Proguard配置

在Android工程中ProGuard被用于压缩和混淆打包后的代码。ProGuard的使用能够在工程配置文件中设置。通常状况下当构建一个release版本的apk时，你须要配置Gradle使用ProGuard。

 

buildTypes {
    debug {
        minifyEnabled false
    }
    release {
        signingConfig signingConfigs.release
        minifyEnabled true
        proguardFiles 'proguard-rules.pro'
    }
}

为了决定哪些代码须要保留，哪些代码须要丢弃或者混淆，你须要在你的代码中指定一个或者多个入口点。这些入口点典型的就是具备main函数，applets，midlets，activities等的类。Android框架使用的默认配置文件是SDK_HOME/tools/proguard/proguard-android.txt。自定义的工程特有的proguard规则文件定义为my-project/app/proguard-rules.pro，将会拼接到默认配置中。

Proguard相关的一个常见问题是在应用启动时出现crash，错误类型是ClassNotFoundException或者NoSuchFieldException等，即便编译是成功的，缘由不过以下两种：

1）ProGuard把须要用到的类，枚举，方法，变量或者注解等给移除了；

2）ProGuard把相应的类，枚举或者变量名给混淆（重命名）了，但调用者仍是使用它原来的名字，例如Java反射的状况。

检查app/build/outputs/proguard/release/usage.txt文件看出问题的对象是否被移除了；检查app/build/outputs/proguard/release/mapping.txt文件看出问题的对象是否被混淆了。为了防止ProGuard把须要的类或者类成员移除了，须要在ProGuard配置文件中增长keep选项：

 

-keep class com.futurice.project.MyClass { *; }

为了防止ProGuard把须要的类或者类变量混淆了，要增长keepnames选项：

-keepnames class com.futurice.project.MyClass { *; }

一些例子能够从ProGuard配置模版上面找到，更多例子参见ProGuard官方例子。

在你的项目早期，执行一个release构建来检查ProGuard规则是否正确的保持了不须要移除或者混淆的东西。当你增长新的函数库，也要执行新的Release构建并在设备上测试生成的apk来确保没有问题。不要等到你的app要发布1.0版本了才想到要执行一个release构建，这时你可能会获得及其不愉快的惊喜，并花一段时间来修复这些问题。

贴士：保存每一个你发布给最终用户的apk包对应的mapping.txt文件。保存mapping.txt的缘由在于当你的用户上传混淆过的crash日志时，你能够很容易的进行调试。

DexGuard：若是你须要能对你发布的代码进行优化，尤为是混淆的核心工具的话，能够考虑DexGuard，这是由ProGuard同一团队发布的商业软件。它还能够很容易的对分割Dex文件以解决65k函数个数限制问题。

 

 

 

——欢迎转载，请注明出处 http://blog.csdn.net/asce1885 ，未经本人赞成请勿用于商业用途，谢谢——