浅谈Android源代码改进问题

　　下面介绍下有关Android源代码的内容和编程技巧，但是首先要让大家了解下什么是Android操作系统，所谓的Android系统：基于Linux平台的开源手机操作系统  。

　　实际上，TestCase这个类用于在Android源代码担当所有独特的TestCase的基类的作用，它是一个Abstract Class  。Android单元测试类继承关系图如下所示：

　　之所以有那么多XXXTestCase主要是为了简化工作  。例如当你想对一个访问数据库的功能进行测试时，首先需要自己启动并初始化数据库  。在这里是类似的，如果你想测试一个Activity，首先要启动它  。而ActivityTestCase就会自动帮你做完这些事情  。

　　而 ActivityUnitTestCase会更注重测试的独立性，它会让测试与Android源代码的联系降到最低  。其余的类可以查看相关的Javadoc 来按需挑选  。要编写测试，就是找到合适的XXXTestCase作为基类来继承  。

　　并且编写自己的测试方法  。很明显的，最简单的编写测试的方法就是继承Android源代码写一个自己的TestCase  。然后为自己的一组TestCase写一个Activity界面  。由界面控制 TestCase的启动，运行和结果报告  。

　　但是，你很快会发现，为何要给测试写一个界面呢?这太诡异了  。这时就需要一种技术，它可以利用命令行(Shell)来启动一组测试，并且通过命令行的形式给出结果  。这就是所谓的Instrumentation  。

　　除了上次我们简单介绍的内容外可以看到Motodev studio for Android在创建新文件时，多出了不少选项，比如Android Activity、Broadcast Receiver、Service、Content Provider，几乎Android源代码的主要框架都包含在内了  。

　　不过仅仅是基础代码的生成，从另一个侧面可以看到这点Google毕竟是从Web起家的，对于开发人员来说微软这方面作为软件帝国想的就十分周到  。Motodev只是做了小幅的补充  。经过简单的试用可以看到对于标准的Android源代码来说  。

　　试用Motodev还合适，不过考虑到目前moto的经济状况，长久考虑还是推荐使用Eclipse+ADT的方式稳当，总体而言和Google官方的开发工具相比没有太大的改进，至少工作在Java VM上的产物稳定性仍然是一个问题  。