注：非5.0特定的开发问题，可以在这个帖子里查：Android开发问题汇总。

1、官方提供的例子android-support-v7-appcompat编译时提示android:actionModeShareDrawable属性不存在

官方例子里这个工程的target是19，需要改为21才能正确编译，否则提示

error: Error: No resource found that matches the given name: attr 'android:actionModeShareDrawable'.

。具体方法是修改project.properties文件，将target=19改为target=21，然后clean此工程或重启eclipse即可。参考链接

若仍然无法编译，可能是appcompat的版本不是最新，请通过sdk manager将support包全部升级到最新版（见下图，图片来自这里。国内用户如果无法升级，可修改hosts文件将dl-ssl.google.com静态解析到可访问的ip地址，ip地址可参考这个帖子，在超级ping里获取到）。

2、parseSDKContent failed问题

升级sdk到5.0以后，原来的Eclipse经常弹出parseSDKContent错误对话框，甚至有时会提示AndroidManifest file missing。

解决方法是删除.android目录（参考链接，在windows里这个目录是C:\Documents and Settings\YOUR_USER_NAME\.android或C:\Users\YOUR_USER_NAME\.android），不过这样会同时删除掉debug.keystore文件。也有人说不需要删除整个.android目录，更新DDMS就可以了（是指更新ADT？），但我没有试过。

3、谷歌开源的Material Design图标

可以从GitHub上下载，链接在此。另外，materialdesignicons.com和androidicons.com这两个网站也提供了一些不错的material design图标下载。

其他开源图标库：阿里巴巴提供的iconfont.cn，图标社区NounProject

在线LowPoly生成器：Trianglify

4、PreferenceActivity不显示actionbar

参考这个帖子，目前support包不支持PreferenceActivity（没有PreferenceActionbarActivity这样的类），所以解决方法要么是改用PreferenceFragment，要么使用第三方的补丁包（Fragment的方案），另一个补丁包（Activity的方案，但有缺陷——getPreferencesXmlId()只接受一个preference.xml文件）。

5、Dialog Theme的actionbar背景颜色显示不全

如下图所示，当使用Theme.AppCompat.Light.Dialog时发现actionbar背景色只显示出一半。根据这个帖子的讨论，可能是AppCompat的目前版本还没有做好。

6、使用appcompat里RecyclerView和CardView时的问题

GitHub上的这个开源项目可以帮助解决一些问题，例如添加divider、点击事件等等，但还远远不够。

CardView的多状态背景色问题，暂时没有解决，参考链接；

下拉刷新：可使用android原生的SwipeRefreshLayout解决；

上拉翻页：方案1)仍使用SwipeRefreshLayout； 方案2)自己监听事件实现Endless效果；

HeaderView：RecyclerView没有像ListView那样提供addHeaderView()方法，要实现类似效果，有两种方法：1)将第一个item作为header，使用android-parallax-recyclerview这个库； 2)让第一个item完全透明，下层显示一个同高的view作为header，使用ASOV这个库。

7、实现Material Design（简称MD）的方方面面

MD是一系列UI特性的组合，阿里巴巴团队的这个帖子介绍得清晰易懂，但要在我们的应用里逐一实现这些特性就不那么容易了，特别是要兼容Android 4.x甚至2.x的时候。Google官方AppCompat v21在这方面只提供了有限的支持，例如ActionBar和侧滑菜单，而像FAB（Fixed Action Button）等等则没有包含在内。

其实在GitHub上已经有不少第三方的实现，值得一提的是，这个名为MaterialDesignCenter的项目把大量相关项目汇总在了一起供开发者参考，值得一看。以下列出我认为值得使用的第三方实现：

FAB: FloatingActionButton

对话框: material-dialogs

各类UI控件: MaterialDesignLibrary

另外几个汇集了android上各类交互效果的项目Interactive-animation、awesome-android-ui、android-open-project（300+项目，不仅限于MD），同样值得参考。

8、使用SlidingTabLayout替代Actionbar的tab导航

v7包的Actionbar对象里，与navigation有关的方法（例如setNavigationMode）都不建议使用了，应使用googleio2014提供的SlidingTabLayout实现类似功能。

参考链接1，参考链接2

9、Android 5.1将AlarmManager的setInterval()最小值限制为1分钟

这个比较坑，毕竟有一些应用依赖AlarmManager机制进行更新，当设备升级到android 5.1后就会出现问题。由于开发文档里并没有提到，所以具体情况见googlecode上的讨论。讨论链接需翻墙，google主要回复如下：

“If you are trying to run more often than every 5 seconds, alarms are the wrong way to go about it. Waking up the device that often is extremely bad for battery life. If you have live UI that needs to be updated continually, use a wakelock and then schedule your activity on a handler. This is actually *more* battery efficient than setting an alarm every second.”

替代方法是在Service里使用ScheduledExecutorService实现定时任务，与AlarmManager的区别见 参考链接

10、使用Android Support Design开发包实现Material Design

Google在2015 I/O大会推出了Android Support Design开发包，方便开发者实现多种常用的MD效果。以下几个有用链接：

INTRODUCTION TO COORDINATOR LAYOUT ON ANDROID

(译)掌握 Coordinator Layout 

高逼格UI-ASD(Android Support Design)

NestedScrollView

CoordinatorLayout与滚动的处理

Android Design Support Library使用详解

（搬家前链接：https://www.cnblogs.com/bjzhanghao/p/4194164.html）

工欲善其事，必先利其器。

和iOS开发相比，Android的开发环境的版本比较多，随之而来的问题也多。显然，我们不应该浪费宝贵的时间在解决开发环境带来的问题上，为此本文总结了常见的开发环境问题和解决方法，供大家查询和随时补充。

Debug certificate expired

Android SDK生成的用于调试的证书文件debug.keystore有效期是365天，当使用超过一年后控制台就会报这个错误。

Error generating final archive: Debug Certificate expired on 10/09/18 16:30

解决方法是手工删除debug.keystore文件，Windows系统下位于"C:\Documents and Settings\username\.android"目录，Linux和Mac系统下位于"~/.android/"目录。下次启动应用时，Eclipse会自动新建一个debug.keystore文件。最好"Project->Clean"一下项目以便触发编译器重新编译。

Failed to install apk on device: timeout

导致这个问题的确切原因不清楚，可能是由于不正确关闭adb连接。

Failed to install helloworld.apk on device 'emulator-5554': timeout

解决方法1：更换电脑usb口（不使用前置usb口）或重装手机驱动，将手机关机后再开机。

解决方法2：在Eclipse里选择Window->Preferences->Android->DDMS->ADB connection time out，将缺省的5000ms改为更大的值，例如20000ms。

解决方法3：在命令行窗口里依次输入如下命令：

adb kill-server
adb start\-server

invalid command-line parameter

这是由于Eclipse开发环境无法找到所需的可执行文件造成的。

\[2011-07-10 07:10:22 - demo\] Android Launch! \[2011-07-10 07:10:24 - demo\] adb is running normally.
\[2011-07-10 07:10:24 - demo\] Performing com.demo.DemoActivity activity launch
\[2011-07-10 07:10:25 - demo\] Automatic Target Mode: launching new emulator with compatible AVD 'xxx' \[2011-07-10 07:10:25 - demo\] Launching a new emulator with Virtual Device 'xxx' \[2011-07-10 07:11:06 - Emulator\] invalid command-line parameter: Files\\Android\\android-sdk\\tools/emulator-arm.exe.

解决方法是在Eclipse里选择"Window->Preferences->Android"选项，检查"SDK Location"的路径是否包含了空格，如果是"c:\Program Files\android"这种，改为"c:\Progra~1\android"，这样命令行就可以正常调用到了。

小提示：在命令行窗口里输入"dir /x"命令就可以列出8.3格式的文件名，看下面的结果：

2012-09-25  23:52    <DIR>          WATCHD~1 WatchData 2012-09-01  11:01    <DIR> Winamp 2012-07-24  22:22    <DIR>          WINDOW~4 Windows Live 2012-07-24  22:21    <DIR>          WI3957~1     Windows Live SkyDrive

INSTALL_FAILED_INSUFFICIENT_STORAGE

安装应用程序时遇到存储容量不足时会报这个错误：

Installation error: INSTALL\_FAILED\_INSUFFICIENT\_STORAGE
Please check logcat output for more details.
Launch canceled!

如果是在模拟器上运行应用，可以扩大AVD的内存容量。

如果是在真机上运行，可以在AndroidManifest.xml里修改安装偏好，让应用直接安装到SD卡上解决。

<manifest xmlns:android\="http://schemas.android.com/apk/res/android" package\="com.example" **android:installLocation\="preferExternal"** \> ... </manifest\>

Unable to open sync connection

虽然很多人遇到这个问题，但问题的根源并不确切，可能有多种原因造成adb报这个错误：

\[2010-10-12 09:36:48 - myapp\] Android Launch! \[2010-10-12 09:36:48 - myapp\] adb is running normally. \[2010-10-12 09:36:48 - myapp\] Performing com.mycompany.myapp.MyActivity activity launch \[2010-10-12 09:36:48 - myapp\] Automatic Target Mode: using device 'xxx' \[2010-10-12 09:36:48 - myapp\] Uploading myapp.apk onto device 'xxx' \[2010-10-12 09:36:48 - myapp\] Failed to upload myapp.apk on device 'xxx' \[2010-10-12 09:36:48 - myapp\] java.io.IOException: Unable to open sync connection! \[2010-10-12 09:36:48 - myapp\] Launch canceled!

解决方法1：拔掉手机连接线再重新连上；

解决方法2：在手机上关闭Debug选项再重新打开，这个选项在手机的"设置->应用程序->开发->USB调试"里。

Too many open files

这个问题与系统可同时打开文件数量设置有关，但一般不需要修改相关设置，用上一个问题（Unable to open sync connection）的方法即可解决。

第三方Jar包，NoClassDefFoundError

升级ADT版本以后容易出现这个问题：本来一切正常的Android项目，升级以后所有的第三方Jar包里的类都提示NoClassDefFoundError了。

原因可能出现在不同版本ADT使用的编译ant脚本的区别，可能的解决方法有两个：

方法1：在Eclipse里右键点击你的Android工程，选择"Properties->Java Build Path->Order and Export"，在这里把所有第三方Jar包前面的复选框都勾上。

方法2：检查你的第三方Jar包文件是否放在工程目录下的"libs"目录，如果不是，改过来。

Failed to allocate memory: 8

一般是AVD的设置有问题，很可能是RAM值设得太高，降低些试试。早期adt版本里有个bug，就是RAM值里必须包含"MB"，例如是"512MB"而不是"512"，否则提示上述错误信息。

也有人提到过分辨率是原因之一，但我没有实际遇到过，如果只改小RAM没有解决问题，试着把分辨率也调低看看。

参考资料

“Debug certificate expired” error in Eclipse Android plugins

Android error: Failed to install *.apk on device *: timeout

The Android emulator is not starting, showing “invalid command-line parameter”

Solution: Android INSTALL_FAILED_INSUFFICIENT_STORAGE error

Android adb “Unable to open sync connection!”

com.android.ddmlib.SyncException: Too many open files

NoClassDefFoundError - Eclipse and Android

Android emulator failed to allocate memory 8

（博客迁移前链接：https://www.cnblogs.com/bjzhanghao/archive/2012/11/11/2765341.html）

刚从桌面应用开发转做手机开发的同学常常被这个问题困扰——用户按下Home键后，应用不是“完全退出”而是“运行在后台”，它仍然占用着系统资源，这么多后台运行的应用必然导致系统变慢，是不是应该在我的应用里给用户提供一个“退出菜单”或“退出按钮”呢？

我在Android开发文档里暂时没有找到关于这个问题的解释，但经过在网上调查很多资料以后，我认为答案是比较明显的：不应提供“退出应用”功能。

虽然文档里没有明确说明，但假如这是常用功能，应该有简便的方法实现，而实际上要靠代码“退出”一个应用并非易事。以下总结了能够模拟退出效果的两个方案：

方案1：打开系统主屏来模拟应用退出的效果，这和用户按Home键没有什么区别。

Intent intent = new Intent(Intent.ACTION\_MAIN);
intent.addCategory(Intent.CATEGORY\_HOME);
intent.setFlags(Intent.FLAG\_ACTIVITY\_NEW\_TASK);
startActivity(intent);

方案2：直接杀掉当前应用进程。这个方法太暴力了，我找到一段iOS开发文档，上面强烈不建议使用杀进程的方式来退出应用，原因也适用于Android系统：这样退出的效果容易让用户以为应用崩溃了。

int pid=android.os.Process.myPid();
android.os.Process.killProcess(pid);

此外，有人建议调用System.exit(0)退出应用，实际测试发现这个方法常常只能关闭当前Activity，或是根本不起作用。

由此可以看出，Android系统的设计里本来就没有“退出应用”的机制，当用户按下Home键或在应用首页里按下Back键后，应用被置于后台，而何时要彻底杀掉应用进程则由系统决定。Android和iOS都已抛弃了“退出应用”这个概念，对手机用户来讲，他只需要知道“启动应用”——概念越少越简单。

参考资料：

Quitting an application - is that frowned upon?
android - exit application code
How to close/exit an application in android?
Proper way to exit iPhone application?
How do I programmatically quit my iOS application?

Android开发文档上专门有一小节解释这个问题。简单来说，Activity是负责与用户交互的最主要机制，任何“设置”（Configuration）的改变都可能对Activity的界面造成影响，这时系统会销毁并重建Activity以便反映新的Configuration。

“屏幕方向”（orientation）是一个Configuration，通过查看Configuration类的javadoc可以看到其他Configuration还有哪些：如fontScale、keyboardHidden和locale等等。

当屏幕旋转时，这个Configuration就发生了改变，因此当前显示的Activity需要被重建，Activity对象会被终止，它的onPause()、onStop()和onDestroy()方法依次触发，然后一个新的Activity对象被创建，onCreate()方法被触发。假设屏幕旋转前，用户正在手机上填写一个注册表单，如果处理不当，用户会发现旋转后的表单变成空白的了，严重影响使用体验。

要解决这个问题有三种方法：

方法1：禁止旋转屏幕

毫无疑问，这是最懒的办法了，相当于回避了本文提出的问题，方法如下看看就好：

<activity android:name=".MyActivity"
          android:screenOrientation="portrait"
          android:label="@string/app_name">

方法2：旋转后恢复现场

既然Activity会被销毁，那么我们就可以使用前文介绍过的“持久化/恢复现场”方法来解决。即在onPause()里将用户当前已经输入的内容保存到数据库或Preference，在onCreate()方法里读取并填充到表单中，这也是官方推荐的方法。

需要补充一点，如果Activity重建需要耗费大量资源或需要访问网络导致时间很长，可以实现onRetainNonConfigurationInstance()方法将所需数据先保存到一个对象里，像下面这样：

@Override
public Object onRetainNonConfigurationInstance() {
    final MyDataObject data = collectMyLoadedData();
    return data;
}

重建时，在onCreate()方法里通过getLastNonConfigurationInstance()方法获得之前保存的数据，如下所示：

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    final MyDataObject data = (MyDataObject) getLastNonConfigurationInstance();
    if (data == null) {//表示不是由于Configuration改变触发的onCreate()
        data = loadMyData();
    }
    ...
}

方法3：手工处理旋转

一般情况下Configuration的改变会导致Activity被销毁重建，但也有办法让指定的Configuration改变时不重建Activity，方法是在AndroidManifest.xml里通过android:configChanges属性指定需要忽略的Configuration名字，例如下面这样：

<activity android:name=".MyActivity"
          android:configChanges="orientation|keyboardHidden"
          android:label="@string/app_name">

这样设置以后，当屏幕旋转时Activity对象不会被销毁——作为替代，Activity的onConfigurationChanged()方法被触发，在这里开发者可以获取到当前的屏幕方向以便做必要的更新。既然这种情况下的Activity不会被销毁，旋转后Activity里正显示的信息（例如文本框中的文字）也就不会丢失了。

假如你的应用里，横屏和竖屏使用同一个layout资源文件，onConfigurationChanged()里甚至可以什么都不做。但如果横屏与竖屏使用不同的layout资源文件，例如横屏用res/layout-land/main.xml，竖屏用res/layout-port/main.xml，则必须在onConfigurationChanged()里重新调用setContentView()方法以便新的layout能够生效，这时虽然Activity对象没有销毁，但界面上的各种控件都被销毁重建了，你需要写额外的代码来恢复界面信息。

@Override
public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);

    // Checks the orientation of the screen
    if (newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) {
        Toast.makeText(this, "横屏模式", Toast.LENGTH_SHORT).show();
    } else if (newConfig.orientation == Configuration.ORIENTATION_PORTRAIT){
        Toast.makeText(this, "竖屏模式", Toast.LENGTH_SHORT).show();
    }
}

官方的Android开发文档不建议使用这种方式处理Configuration改变：

Note: Using this attribute should be avoided and used only as a last-resort. Please read Handling Runtime Changes for more information about how to properly handle a restart due to a configuration change.

最佳实践

考虑到旋转屏幕并不是使Activity被销毁重建的唯一因素，仍然推荐前文介绍过的方法：在onPause()里持久化Activity状态，在onCreate()里恢复现场，可以做到一举多得；虽然Google不推荐设置android:configChanges属性的方式，但如果你的Activity横向纵向共用同一个layout文件，方法3无疑是最省事的。

参考资料：

Configuration Changes
Handling Runtime Changes
Activity restart on rotation Android
How to handle screen orientation change when progress dialog and background thread active?

(搬家前链接：https://www.cnblogs.com/bjzhanghao/archive/2012/11/09/2761897.html)

我们要了解Android手机开发与桌面开发有一个主要不同之处：通常在一部Android手机里同时运行着多个应用(app)，每个app对应一个系统进程，当系统需要更多的资源（如内存）而空闲资源不足时，Android系统就会选择杀掉一些“低优先级”的进程以便释放所需资源。

Android系统是如何确定进程优先级的高低的呢？

• 如果一个app正在与用户交互，那么它所在的进程具有最高优先级；
• 其次，如果一个app是可见的，例如被一个对话框部分遮挡，它所在进程具有第二高的优先级；
• 再次，如果app当前是不可见的，也就是被切换到了后台，则它所在进程具有第三高的优先级；这里要补充一点，如果这个后台app启动了一个service，则它比一般的后台app优先级高一些。
• 最后，如果一个进程里没有包含任何app，这个进程的优先级是最低的。

当系统资源严重不足时，任何一个进程都有可能被杀掉，而当用户想回到一个已经不存在于内存中的Activity时，系统只得新建一个这样的Activity对象并调用它的onCreate()方法进行恢复。所以有时出现这种状况：一个app大部分时间运行很好，偶尔在切换Activity时出现空指针异常导致强制关闭，这多半是在onCreate()方法里使用了已经被重置为空的对象（例如intent里的变量）造成的。即使不出现异常，也会造成表单数据丢失等严重影响使用体验的问题。

要解决这类问题，切不可抱“现在手机内存大，进程一般不会被杀掉”这种侥幸心理，而应该以“应用随时都会被杀掉”的态度来谨慎处理，下面介绍Google建议的方式。

解决方法

由于Activity随时可能需要重建，所以我们要做的事情就是在适当的位置将Activity所需数据进行持久化（从ram复制到rom或sd卡），并在onCreate()方法里利用这些数据恢复现场。

Activity有两类数据需要进行持久化处理：“文档类型数据”和“内部状态类型数据”，前者例如用户正在编辑的表单，后者如用户偏好。

一、为了持久化文档类型的数据，Google建议使用”即时生效”（edit in place）的编辑策略，具体的方式如下：

• 用户新建文档时，在SQLite数据库（根据需要也可以使用preference）里也立即新建一条记录。（与此相对的方式是：为用户提供一个“保存”按钮，只有当用户按下按钮时才将文档保存到数据库。）
• 当用户离开当前Activity时，onPause()方法会被触发，在这个方法里将当前正在编辑的文档持久化到数据库。这样一来，如果用户是从这个Activity切换到另一个相关Activity，仍然可以看到刚刚保存的内容。

这种方式可以最大限度避免数据丢失，只要onPause()方法被触发执行，即使Activity所在进程被系统kill掉也不会造成数据丢失。唯一要注意的是，界面上最好能提供一个“取消”按钮或菜单，以便让用户可以选择不保存对文档的更改。

二、为了持久化内部状态类型的数据，可以在onPause()里使用Activity#getPreferences(int)方法，这个方法返回SharedPreferences类型的对象，利用它可以记录用户对这个Activity的偏好信息。例如一个日历应用，用户可以选择显示为周视图或月视图，这样的信息作为内部状态记录到SharedPreferences对象以后，下次再打开这个Activity时就可以按用户上次的选择来显示日历了。

以下代码来自官方文档，演示了如何持久化并恢复一个Activity的当前显示模式：

 public class CalendarActivity extends Activity {
     ...

     static final int DAY_VIEW_MODE = 0;
     static final int WEEK_VIEW_MODE = 1;

     private SharedPreferences mPrefs;
     private int mCurViewMode;

     protected void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
         //取回之前持久化的日历显示模式
         SharedPreferences mPrefs = getSharedPreferences();
         mCurViewMode = mPrefs.getInt("view_mode", DAY_VIEW_MODE);
     }

     protected void onPause() {
         super.onPause();

         //持久化日历显示模式 
         SharedPreferences.Editor ed = mPrefs.edit();
         ed.putInt("view_mode", mCurViewMode);
         ed.commit();
     }
 }

是有点麻烦，但为了能让app稳定运行也值了。

有些同学要问了，为什么是在onPause()里持久化而不是在onSaveInstanceState()里？官方文档有下面一段话简要解释了原因，即前者比后者更可靠，因为onSaveInstanceState()不属于Activity生命周期的一部分。——既然如此，我想不出onSaveInstanceState()还有什么其他用途了，大家干脆忘了它吧，还有onRestoreInstanceState()。

Note that it is important to save persistent data in onPause() instead of onSaveInstanceState(Bundle) because the latter is not part of the lifecycle callbacks, so will not be called in every situation as described in its documentation.

注1：关于上面这段话，网上存有一些争议，我个人还是比较倾向在onPause()里做持久化——既可靠又好记，唯一的缺点是调用次数稍多。

注2：从Android 3.0（HoneyComb）版本开始，Activity进程在被系统杀掉之前，将保证onStop()方法先执行完成，因此如果我们开发的应用只运行在3.0以上，可以把持久化工作放在onStop()里以减少持久化的次数。

最佳实践

不要抱侥幸心理，你的Activity随时可能被销毁。

解决方法：在onPause()里持久化Activity数据，在onCreate()里恢复现场。

参考资料：

ActivitySaving Activity state in Android

（搬家前链接：https://www.cnblogs.com/bjzhanghao/archive/2012/11/08/2759948.html ）

Android官方文档里对Activity的生命周期有比较详尽的描述，但由于资源回收机制带来不确定性，我们的程序运行结果常常与预期的不符，而调试这类问题又十分消耗时间和精力。解决的根本办法还是要理解透Activity的生命周期及相关内容，这篇帖子着重介绍Activity生命周期本身，之后会用一两篇帖子来介绍如何处理异常的状态变化。

下图是官方文档里的Activity生命周期图，其中彩色标出的四个框是Activity的四种状态，当Activity的状态改变时会触发一个或多个onXXX()方法。

onCreate()

当Acitivity第一次被创建时触发，一般在这里要做的事情包括创建视图（setContentView()）、向视图填充必要的数据等等。

onRestart()

这个我比较少用到，按文档上的介绍，如果Activity之前被stop过，那么下一次onStart()方法之前会先触发这个方法。

onStart()

只要Activity从不可见变成可见，就会触发到这个方法，但被AlertDialog遮挡/显示的情况不算在内。

onResume()

当Activity来到最上层的时候，也就是开始与用户直接交互时，触发这个方法。例如本来Activity被一个AlertDialog遮挡，当这个AlertDialog消失时，onResume()方法就被触发。

onPause()

和onResume()的触发条件刚好相反，如果Activity本来在最上层，当它要让出最上层的位置时会触发这个方法。onPause()和onResume()是被触发最频繁的两个方法，所以在这里不应该执行过于消耗资源的方法。

onStop()

当有其他Activity覆盖了当前Activity时，不论另一个Activity是新开始的还是从下层移至最上层的，当前Activity的onStop()方法都会被触发。

onDestroy()

Activity生命周期的终点。有两种情况会导致它被触发：1)执行了Activity#finish()方法；2)Android系统由于资源不足等原因决定杀掉Activity所在进程。通过isFinishing()方法可以判断出是哪种情况。在这个方法里，我们一般要做的事情是释放Activity占有的资源，例如后台正在进行的下载线程等等。

最后，举个实际例子来说明，假设你有一个“首页Activity”和一个“编辑页Activity”。

• 当用户点击首页里的“开始编辑”按钮时，首页的onPause()->onStart()onStop()依次触发，编辑页的onCreate()->onStart()->onResume()依次触发；（感谢James.H.Fu指出的错误）
• 当用户在编辑页按下“返回”按钮时，编辑页的onPause()->onStop()依次触发，之后首页的onStart() -> onResume()依次触发；
• 这时用户在首页按下“返回”按钮，首页的onPause()->onStop()->onDestroy()依次触发。

参考资料：

Activity Lifecycle
Simplest Android Activity Lifecycle
Activity lifecycle explained in details

搬家前链接：https://www.cnblogs.com/bjzhanghao/archive/2012/11/07/2758276.html