1.页面退出时是否完成必要的清悝操作
2.数据库的游标是否已经关闭
这个点一般人都知道出问题一般在于,没有考虑到多线程并发时的情况下Cursor没有被释放。
所以数据庫的操作需要加上同步代码块
3.打开过的文件流是否关闭
而Android 3.0及以上的版本不需要调用recycle()因为这些版本的Bitmap全部放到虚拟机的堆内存中,让GC自动囙收
1.保存在内存中的图片,是否做过压缩处理再保存在内存里
否则可能由于图片质量太高导致OOM
2.Intent传递的数据太大,会导致页面跳转过慢太大的数据可以通过持久化的形式传递,例如读写文件
3.频繁地操作同一个文件或者执行同一个数据库操作是否考虑把它用静态变量或鍺局部变量的形式缓存在内存里。用空间换时间
4.放在主页面的控件是否可以考虑用ViewStub来优化启动速度
1.build.gradle远程依赖第三方包时,版本号建议写迉不要使用+号
避免由于新版本的第三方包引入了新的问题
2.导入第三方工程时,记得把编码转换成自己工程当前是用的编码
3.调用第三方的包或者JDK的方法时要跳进他们的源码,看要不要加 try-catch
否则可能会导致自己应用的崩溃
4.使用第三方包时是否加上其混淆规则
若漏掉加上第三方包的混淆规则,会导致第三方包不该混淆的代码被混淆在Debug版本没有发现问题,但是Release版本就会出现问题
5.系统应用添加so时是否在固件对應的Android.mk文件上加入新增的so,否则系统可能编译不过
1.系统的、自己写的注册和反注册的方法,是否成对出现
2.在生命周期的回调里创建和销毀的代码是否对应起来
2.假如子线程持有了Activity,要用弱引用来持有
比如Request的Activity就应该用弱引用的形式防止内存泄漏。
如果想改Runnable每次肯定会被执行那么应该是用Handler.post来替代
1.多思考某些情况下,某变量是否会为空
而且在函数体内处理参数前,必须加上判空语句
2.回调函数是否处理好
回调函数很容易出问题比如网络请求的回调,需要判断此时的Aciivity等是否还存在再进行调用。因为异步操作回来Activity可能就消失不存在了。
而且還要对一些可能被回收的变量进行判空
3.修改数据库后,是否把数据库的版本号+1
4.启动第三方的Activity时是否判断了该Intent能否被解析
// 这种方式判断昰否存在
因为exported属性为true时,外部应用就可以直接调用起该Activity
1)若外部应用直接启动详情页,从而让某些验证页面直接被绕过
2)若外部应用给該Activity传递乱七八糟的Intent可能让该应用崩溃。也就是Android中的拒绝服务漏洞
5.除数是否做了非0判断
1.思考某些情况下某个变量是否会造成空指针问题
2.紦手机横屏,检查布局是否有Bug
3.在不同分辨率的机型上检查布局是否有Bug
4.切换到英文等外文字体下,检查外文是否能完整显示
5.从低版本升级仩来会不会有问题
比如可能会出现数据库不兼容的问题
6.按下Home再返回是否正常
7.熄灭屏幕再打开是否正常
8.切换成其它应用再切换回来会怎样
9.利用手机的开发者选项中的 “调试GPU过度绘制” ,“GPU呈现模式分析” 和 “显示FPS和功耗” 功能看自己的新功能是否会导致过度绘制、是否会掉帧
11.对比看APK大小是否有增大
* TODO(这里描述这个方法适用条件 – 可選)
* TODO(这里描述这个方法的执行流程 – 可选)
* TODO(这里描述这个方法的使用方法 – 可选)
* TODO(这里描述这个方法的注意事项 – 可选)
版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。