Android开发经验总结，很受用。

转自：http://www.eoeandroid.com/thread-148049-1-1.html 

 

1、有一个方法，有一段类似于下面这样：  Java代码 new Thread(){        public void run(){            // 做了一些数据库操作            db.close();        }    }.start();   复制代码 结果运行过程中，发现有时候会报数据库已经锁定的异常。最后才定位到上面这段代码。原因是在上面的run()方法中打开了数据库，这个时候会自动锁定Database，如果在关闭数据库之前，另外一个线程B也进行数据库操作，就会报这个异常。如果数据库已经关闭之后，另外一个线程B请求数据库操作，就没有问题。  所以在新线程中进行数据库操作，或者是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

<!--EndFragment-->