Android_CheckList

记录一些坑来警示自己

检查项	可能存在的问题	解决方案
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数据丢失
操作磁盘时检测磁盘挂载，空间不足
网络操作考虑无网络，网络超时