转自:http://www.eoeandroid.com/thread-148049-1-1.html
1、有一个方法,有一段类似于下面这样: Java代码
所以在新线程中进行数据库操作,或者是TimerTask中进行数据库操作的时候,要注意考虑并发的问题,也许就会有数据库锁定的异常。 2、另外一段代码,将TimerTask的销毁操作放在了Service的onDestory()方法里,但是发现有时候会报TimerTask已经schedule的异常。开始就觉得很奇怪,不是已经在onDestory()方法里关闭了TimerTask了吗?后来想到,Service的onDestory()方法不是一定有机会执行的。在资源不足的时候,系统会强行关闭Service,在这种情况下,onDestory()方法是没有机会执行的。 所以,绝对不能依赖组件的onDestory()方法。 3、这次项目管理有一个失误的地方。就是在项目设计早期,没有关注数据库表设计。到了后期才来检查数据库的设计,结果发现有很多地方需要变更,这就造成建表语句、模型对象、DAO都要修改,开发和测试的成本都非常高。 所以以后一定要在早期就关注数据库设计,如果有迫不得已的数据库变更(这个几乎是难免的),也要趁早进行 4、有的时候,发现两个组员都是更新了最新的代码,可是一个能正常跑起来,另一个人就总是报错。这种情况,一般是因为数据库错误引起的,虽然是同样的代码,但是却不是同样的数据库。这种情况下,需要把旧的应用卸载,重新启动。这样就会触发SqliteDatabaseOpenHelper的onCreate()方法,重新建立一致的数据库 5、前期把整个应用的常量,都放在一个Constants类里,这样虽然避免了硬编码,但是其实由于Constants类里充斥了各种各种的常量,也失去了可维护的意义。所以如果常量太多的话,可以考虑根据模块或者业务,分散到不同的Constants类里 6、一般跳转到别的Activity,是调用startActivity()方法,不过如果需要在新Activity里做完某些操作以后,再通知原先的Activity的话,应该调用startActivityForResult()方法,然后实现onActivityResult()方法 7、有一次在DDMS里发现了has leaked window的异常告警。这种情况一般是在Activity里创建了Dialog,然后又没有及时关闭引起的。解决的办法很简单,在需要创建Dialog的地方,调用showDialog()方法,然后在Activity里实现onCreateDialog()方法,这样的话,Activity就会管理Dialog的生命周期,就不会发生上述的问题了 8、一般连接android底层的linux,用adb shell命令就可以了。但是如果同时开启了模拟器,又连接了真机,就不能这样了,必须用以下的命令: adb devices,这个命令可以看到有哪些设备,包括了模拟器和真机 然后用adb -s (deviceId) shell,就可以连接到目标终端上 或者还有一个办法,用adb -d shell连接到设备上,用adb -e shell连接到模拟器上 9、我自己定义了一个VO类,可是用Intent.putExtra()方法竟然放不进去,原来是这个VO没有实现Serializable接口 10、项目中业务上需要很多后台长时间运行的Service,可是后来发现Service实在太多了,所以换了一个方案。把实现业务逻辑的Service,都改成用IntentService实现。只开启一个长时间后台运行的Service,在这个Service里用多个TimerTask,定时去startService()各个IntentService。这样应用就只有一个驻留Service了 11、很多Service都去实现onStart()方法,其实这是不对的,onStart()是一个遗留方法。Android2.2以上的版本,官方推荐是实现onStartCommand()方法 12、如果没有多线程的需求的话,使用IntentService替代Service是一个不错的选择。一方面不需要编码另起线程(Service默认是跑在UI Thread里的,这点相当恐怖),另一方面,也不需要显式地调用stopSelf(),或者stopService()。IntentService的问题是,如果需要并发地处理请求,则晚来的Intent只能排队 13、TimerTask比较多的话,一个最佳实践(或者是迷信)是:用3、7、11、13、17这样的素数错开运行的时间 14、一个已经调用了.cancel()方法的TimerTask,不能被再次作为Timer.schedule()的参数,需要重新实例化一个TimerTask 15、没有特别的需求的话,个人建议可以在AndroidManifest.xml里不配置intent-filter,这样就强制代码只能用显式的Intent来跳转Activity或者开启Service,不能用隐式的Intent来调用。 这种做法虽然损失了一些面向组件的灵活性,但是定位问题会比较简单。因为比较容易查出来,某个Service被哪些组件启动了,或者某个Activity可以从哪些页面跳转过来 当然,如果Activity和Service被设计为允许其他应用使用,那必须要支持隐式的Intent调用 16、数据库字段的命名,还是有点讲究的。比如在T_PERSON表里,字段就没必要再命名成PERSON_NAME,直接叫NAME就可以了,前者比较冗余。这个虽然是小问题,但是对于追求细节完美的应用来说,还是要注意的。如果前期没有注意,到项目后期再统一优化,代价会大很多 17、原来经常用getSharedPreference()方法,来获取自定义SP文件。其实发现,用PreferenceManager.getDefault()方法就可以获得一个默认的SP文件了 18、DTO和VO,建议重载toString()方法,调试会很方便 19、Activity的findViewById()方法,和View的findViewById()是不一样的。 前者一般都在onCreate()方法里调用setContentView()方法,然后findViewById()就是从这个xml文件里找ID 后者一般调用一个inflate()方法,然后findViewById()方法是从这个xml文件里找ID |