记录一些坑来警示自己
| 检查项 | 可能存在的问题 | 解决方案 |
|---|---|---|
| TextView（及其子类） setText 方法设置一个 int 类型的数据 | 会默认查询R文件中定义的资源 | 先将int型数据转换成String |
| 上线前使用正式签名 | ||
| 在Activity中少创建Handler | ||
| 使用Bitmap要释放 | ||
| super.onCreate(saveInstanceState) 在所有业务之前 | ||
| 创建四大组件要在清单文件中声明，广播动态注册除外 | ||
| 为Activity声明系统配置变更事件 | 系统配置变更事件是指转屏，区域语言发生变化，屏幕尺寸发生变化等等，如果Activity没有声明处理这些事件，发生事件时，系统会把Activity杀掉然后重启，并尝试恢复状态，Activity有机会通过onSaveInstanceState()保存一些基本数据到Bundle中，然后此Bundle会在Activity的onCreate()中传递过去。虽然这貌似正常，但是这会引发问题，因为很多其他的东西比如Dialog等是要依赖于具体Activity实例的。所以这种系统默认行为通常都不是我们想要的。 | android:configChanges="fontScale/orientation/keyboardHidden/locale/navigation/screenSize/uiMode" |
| 尽量使用Android的API | Context.openFileOutput(String); // no File file = new File(String)原因就是API里面会考虑到Android平台本身的特性；再如，少用Thread，而多使用AsyncTask等 | |
| 要考虑到Activity和进程被杀掉的情况 | 如了通常情况退出Activity外，还有Activity因其他原因被杀的情况，比如系统内存过低，系统配置变更，有异常等等，要考虑和测试这种情况，特别是Activity处理重要的数据时，做好的数据的保存。 | |
| 不要用四大组件去实现接口 | 一是组件的对象都比较大，实现接口比较浪费，而且让代码更不易读和理解； 另外更重要的是导致多方引用，可能会引发内存泄露。 | |
| 用getApplication()来取Context当参数 | 对于需要使用Context对象作为参数的函数，要使用getApplication()获取Context对象当参数，而不要使用this，除非你需要特定的组件实例！getApplication()返回的Context是属于Application的，它会在整个应用的生命周期内存在，远大于某个组件的生命周期，所以即使某个引用长期持有Context对象也不会引发内存泄露。 | |
| 主线程只做UI控制和Frameworks回调相关的事 | ||
| 附属线程只做费时的后台操作 | 交互只通过Handler。这样就可以避免大量的线程问题 | |
| Frameworks的回调不要做太多事情仅做必要的初始化 | 其他不是很重要的事情可以放到其他线程中去做，或者用Handler Schedule到稍后再做。 | |
| cursor 关闭 | ||
| Activity onCreate 中调用了popupWindow | popupWindow是挂载在某一组件上，activity还没有完全显示可能异常 | |
| Application 缓存数据 | 后台是杀掉程序，Application数据丢失 | |
| 操作磁盘时检测磁盘挂载，空间不足 | ||
| 网络操作考虑无网络，网络超时 |
