-
一个网页通用的测试用例（借鉴他人的保存，加注释）
green_star 发布于 2014-09-30 10:15:14
-
如何更好的招聘软件测试人员？
zzzmmmkkk 发布于 2013-05-18 17:02:54
-
发现的bug不能重现怎么办？
zzzmmmkkk 发布于 2013-05-30 20:57:08
微博上抛出一个讨论话题：下午一test lead问到，有些测试的bug会在A版本里出现，然后记录它；但开发人员在当前B版本试图重现时发现不能重现，故reject它。那么测试就郁闷了，待到下一轮回归测试可能是C版D版本，如果再出现自然reopen，但如果不复现是否真的应该关掉它吗？各位对这种sometimes bug怎么处理的啊？这个问题可能每个测试人员都会遇到，我说说我个人观点，供大家讨论。
1. 在A版本发现的bug应该在A版本进行重现我们知道，有很多原因会导致A版本的bug可能不能在B版本重现：1）开发人员自己偷偷解了bug，以免受到KPI考核；2）环境差异，可能B版本的代码在A版本的环境也会出问题，但是在开发环境可能就不能复现；3）代码变更，也许是其他的代码引起的bug，B版本时其他开发已经修改，此类可以归纳为相关联功能引起的bug；4）AB两版本进行复现的前置条件及步骤已不同。既然有这么多可能性，那我们就应该排除影响，让问题简单化，保持环境和代码一致的情况下进行复现。A版本的bug如果在B版本不能复现，时间和条件允许的话，那就回退代码到A版本，有个前提不用回退，那就是已准确定位问题了，并且确定在B版本已经解决它了。
2. 项目时间允许的情况下，开发人员应大力协作复现bug对于”疑难杂症“，开发人员应大力配合测试人员进行复现：1）如果对于不好调试的代码就打印更多log；2）可以通过连接测试环境数据库并回滚代码到A版本，根据获悉的已有情况添加断点调试代码；3）做更细致的code review等等方式。在自己负责的那部分代码确定完没有问题，这时候就需要考虑到接口，是否在接口数据处理上的问题，就需要其他开发人员配合。而测试人员需要尽最大努力来还原当时的场景：环境，数据，前置条件及测试步骤等。
3. 测试人员要再次确认用例设计的覆盖度及周密性有几种情况会导致不可复现：1）环境；2）代码；3）数据。而数据又可以归纳到代码容错性处理上，环境其实是可以很好还原的，那出现不容易复现的bug就大多数是归于代码和数据上了，对于测试而言，用例设计的覆盖不够，不够严谨就会导致bug不在我们的掌握中。这个时候，我们有两种情况：一是原本用例就没有好好设计过，未经评审过，大家测试时就很随意，勿容置疑，赶紧把用例好好琢磨琢磨，再叫上项目相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，各种情况大家都讨论过，保证在需求上大家的一致性，保证软件覆盖度能满足本次项目需求的要求，做到需求100%覆盖，开发人员若再提出更多建议，那也可以弥补一些黑盒测试时可能遗漏的情况；二是该项目已经经过严格的需求评审及用例评审了。当然，即便如此也不能避免漏测以及对特殊情况的考虑。当然，要这么做的前提是这个bug很严重，影响了版本的发布，有必要召集大家协力解决掉它。
4. 绞尽脑汁，它仍然不能复现时，保持关注我相信，通过以上步骤的努力，仍然不能复现的bug一定是优先级不高的，那就再评估重要度，若通过项目组决定不影响版本发布，就密切关注此bug，在发布后验证时也重点关注下。而且该bug不能关闭，依次往以后版本中顺延，并且每轮测试时都要尝试再次复现。那何时可以关闭呢？也许3，5个版本发布后，没有出问题就可以决定关闭它了。
5. 思考测试流程及测试规范，及时更正走过的弯路，制定提交bug的规范，便于开发及我们自己复现有一次，就会有第二次，我们应该及时响应，即便不能亡羊补牢，也要防患未然。 提交bug的规范，这个可能每个公司情况不一样，有些公司木有限制，提交的bug也是千人千面，这对于开发人员理解bug和复现bug无疑增加了难度。而规范了bug提交，若记录了此bug的前置条件，使用的数据及操作步骤，可能会大有益处。当然，此处不是说每个bug都这么详细。===========================
添加微信“zzzmmmkkk”,可以通过：
1. 请在微信“添加好友”->“搜索公众账号”里查找“zzzmmmkkk”
2. 或者点击本文右上角按钮后选择“关注公众账号”
zzzmmmkkk,本名赵敏科,6年测试经验,2年项目及团队管理经验,从事过多年功能测试,性能测试及自动化测试,乐于分享。
不定期发布有关测试技术文章,测试经验分享,测试思考和问题探讨。
===========================
-
应聘时的给力回答(仅供参考)
xinxinxingxing 发布于 2011-09-02 14:58:53
-
测试文档
hemiao 发布于 2011-09-08 09:44:49
-
深入浅出正则表达式（一）
yujie6832 发布于 2009-12-03 13:14:04
-
转：Android上的Webkit的测试
xiaoxie59 发布于 2010-11-29 16:06:38
-
Android介绍
paulinetina 发布于 2010-08-10 10:35:35
转自：http://yahaitt.javaeye.com/blog/453018
Android平台是一组面向移动设备的软件包，它包含了一个操作系统、中间件和关键应用程序。开发人员可以使用Android SDK(软件开发工具包)为这个平台创造应用程序。应用程序使用Java语言编写并在Dalvik之内运行。Dalvik是一款量身定制的虚拟机，它专为嵌入式应用设计，运行在Linux内核上层。
如果你想了解如何为Android平台开发应用程序，你就来对地方了！为了帮助大家了解Android平台进而开发移动应用程序，这里 提供了各种丰富的文档。
Android SDK 的预览版已经可以下载 了。其中包括了附含源代码的样例工程、开发工具、仿真器，当然了，还有你构建工程所必需的类库。
Android是什么？
机器人？
Android是一组面向移动设备的软件包，包含了一个操作系统，中间件和关键应用程序。Android SDK 的预览版提供了必需的开发工具和应用程序接口，基于这些，我们就可以使用Java编程语言在Android平台上开发应用程序了。
有点Linux风格吧
特性
- 应用程序框架 支持组件的复用和更换
- Dalvik 虚拟机 专门为移动设备进行过优化
- 集成的浏览器 基于开源的 WebKit 引擎
- 优化的图形机制 自定义的2D图形库，基于OpenGL ES 1.0规范的3D图形实现（本项为硬件加速器可选）
- SQLite 轻量级的数据库，支持结构化数据的存储
- 媒体支持 面向常见的音频、视频以及静态图形档案格式 (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
- GSM 技术 GSM：global system for mobile communications (依赖硬件支持)
- Bluetooth, EDGE, 3G, and WiFi (依赖硬件支持)
- Camera, GPS, compass, and accelerometer (依赖硬件支持)
- Rich development environment 丰富的开发环境，包含一套硬件仿真器，一些用于程序调试、内存和性能剖析的工具，以及支持Eclipse集成开发环境的插件（ADT ）。
Android架构
下方图表显示了Android操作系统的主要组件。要知道关于各个部分更多的细节，下文还有描述，请继续看。
Applications (应用)
Android将预装一组核心应用程序，包括email客户端、短信服务、日历日程、地图服务、浏览器、联系人和其他应用程序。所有应用程序都是Java编程语言编写的。
Application Frameworks (应用框架)
上文所提的核心应用程序就是依赖框架层次API开发的，程序员们当然也可以充分使用这些API。应用架构设计的初衷是：简化组件复用机制；任何应用都能发布自己的功能，这些功能又可以被任何其他应用使用（当然要受来自框架的强制安全规范的约束）。和复用机制相同，框架允许组件的更换。
所有应用都是一组服务和系统，一般包含：
- 一套丰富且可扩展的视图 组件，含有lists, grids, text boxes, buttons, 甚至嵌入的网络浏览器
- Content Providers （内容提供器） 使一个应用可以访问另外一个应用的数据（如联系人），或者使一个应用内部可以共享自身数据
- Resource Manager （资源管理器），提供对非编码资源——例如本地化字符串、图形和布局文件——的访问通道
- Notification Manager （通告管理器），使应用在状态栏显示自定义的警报通知。
- Activity Manager （行动管理器）负责管理应用的生命周期，提供通用导航回退支持
要知道更多细节，了解应用内幕，请参考教程 《Android应用编写》
Libraries (库)
Android包含一套C/C++库，Android系统的各式组件都在使用。这些功能通过Android应用框架暴露给开发人员。下面列举一些核心库：
- System C library - 衍生于BSD的标准C系统库（libc）实现(注：BSD：Berkeley Software Distribution，伯克利软件套件,是Unix的衍生系统，1970年代由伯克利加州大学开创)，尤其支持嵌入式的基于Linux的设备。
- Media Libraries - 媒体库基于PacketVideo's OpenCORE；媒体库支持很多流行音频和视频格式、静态图形文件（包括MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG ）的播放和录制
- Surface Manager - 管理范围：对子系统显示功能的访问，跨应用的无缝组合2D和2D图形层
- LibWebCore - 是流行的浏览器引擎，可以支持Android浏览器和嵌入应用的WEB视图组件
- SGL - 底层的2D图形引擎
- 3D libraries - 基于OpenGL ES 1.0 API的实现； 该类库使用硬件3D加速器（如果硬件支持的话）或者内置的、高度优化的3D软件加速机制。
- FreeType - 支持位图和矢量字体
- SQLite - 能干、轻量级的关系型数据库引擎，面向所有应用
Android Runtime (Android运行时)
Android的核心类库提供Java类库所提供的绝大部分功能。
每个Android应用都运行在自己的进程上，享有Dalvik虚拟机为它分配的专有实例。为了支持多个虚拟机在同一个设备上高效运行，Dalvik被改写过。
Dalvik虚拟机执行的是Dalvik格式的可执行文件（.dex）——该格式经过优化，以降低内存耗用到最低。Java编译器将Java源文件转为class文件，class文件又被内置的dx工具转化为dex格式文件，这种文件在Dalvik虚拟机上注册并运行。
在一些底层功能——比如线程和低内存管理方面，Dalvik虚拟机是依赖Linux内核的。
Linux Kernel (Linux内核)
Android依赖Linux 2.6版，提供核心系统服务：安全、内存管理、进程管理、网络组、驱动模型。内核部分还相当于一个介于硬件层和系统中其他软件组之间的一个抽象层次。
-
Android自动化测试工具
hansen.liu 发布于 2010-06-21 13:22:51
-
Android自动化测试
hansen.liu 发布于 2010-06-18 15:45:20
-
学习资料的一些网站收藏
张晓南 发布于 2011-02-17 11:38:18
-
Verification and Validation
lhd85 发布于 2011-02-27 12:21:01
-
转载：深入Android【八】 —— Activity间数据传输
51_51testing 发布于 2010-10-05 15:32:11
转载自：http://www.cnblogs.com/duguguiyu/archive/2010/05/29/1747244.htmlActivity间数据传输
当对Android有一些了解后，不难发现，Android程序UI框架接近于Web页面的概念。每一个用于呈现页面的组件，Activity，都是彼此独立的，它们通过系统核心来调度整合，彼此之间的通过Intent机制来串联。
每一种架构都会有其利弊，Android当然也不能超然脱俗。由于Activity之间的松耦合关系，使得其复用能力特别的出色，Mash-Up方式可以有效的提高开发效率。但另一方面，由于Activity过于的独立，它们之间的数据共享，成为一个麻烦的事情。基于消息的传输
最标准的Activity之间的数据传输，就是通过Intent的Extra对象。比如，你在A这个Activity上拿到一坨用户输入的文本信息，兴高采烈的想把它放到B这个Activity上展示并发送，一个很可行的方式，是通过Intent的putExtra接口，把用户输入的那些字符信息，按照key/value的形式放进Intent，传输到B这个Activity上。
如上图示，从A到B的传输，看上去是一个直连，但其实，Intent都是要经由系统核心层去分析调度的，这个操作，跨越了进程边界，自然而然，其中的数据，就是需要序列化和反序列化的，而不可以仅通过一个指针就倒腾过去了。基于这样类消息的传输模式，好处不多说，直接谈问题：- 首先，对于大数据，就是一场杯具，不可能一坨上M的数据，也来来回回的传来传去，慢死了谁来负责；
- 再则，Activity之间，维系的是一种线性关系，当我想把一份数据，从队尾一级级传到队头的话，自己历经磨难不提，会把中间所有的Activity都搭上，他们明明自己可能不需要这份数据，也得拿着搁着，为他人做嫁衣裳，不惆怅都不行；
- 此外，基于消息的传输，会把同一份数据生成若干个副本，有时候，这样很好，没有副作用，大家自己玩自己的不需要看别人脸色，但还有些时候，你就上杆子需要把这些数据都修改一下，同步起来那就太惨烈了；
- 最后，写序列化代码实在是太无聊了，稍微复杂点的代码，就要自己写个序列化接口，整个吃力不讨好的活计。
基于外部存储的传输
既然兽兽手手相传太幸苦，自然而然的想法就是找个地方，A把数据搁在那里，把地址信息告诉B，B需要的话，按图索骥，自取就好。这个搁东西的地方，可以考虑选择外部存储。在Android中，预设了一些快捷便利类和模块，更好的支持不同类别数据的存取。如果，需要存储的是一些小数据量的配置信息，可以选择Preference，它等同于传统意义上的设置文件。Preference提供了一些基于key/value的存取接口，可以放置一些简单的基本数据或者派生了Parcelable接口的对象。一个很好的应用场景是Cookie的存放。你在登录界面获得了一份Cookie，你可以把它扔进Preference，谁想要谁去拿，再也不要来来回回的折腾了。Preference适合于小数据、设置信息，如果大数据，你可以考虑使用数据库。在Android中，使用的是Sqlite，相关的类，堆放在android.database名字空间下，自查，无需赘述。在Android里，数据库是私有的，如果想分享给第三方组件使用，就需要用ContentProvider来封装了。比如你用系统的录音机组件即时搞一段音频信息，它不是返回可能大到恐怖的录音数据，而是会返回给你一个Uri，它标明了这份数据在ContentProvider的地址信息，拿着这个Uri，领取数据就好。当然当然，如果你足够淡定，也可以用赤果果的File来存储。如果这个文件存在手机私有目录下，那就内部使用，放在SD卡上，那就可以所有应用，一切分享。基于这样外部存储的数据传输，优缺点显而易见，它解决了困扰Intent的传输路径复杂，不利于传输大批量数据的问题，但同时，它有留下了效率隐患，复杂了编程模型。因为面对外部存储，开发者必须要考虑效率问题，很多时候，多线程就会被提上议程，这样，想不麻烦，都不行鸟。基于Service的传输
既然存在外部太慢，那么还是在内存级别解决问题好了，这时候，你可能就需要请出Android四大组件之一的Service了。Service设计的本意，就是提供一些后台的服务，数据存取，也可以归于其职责的一部分。Service是提供了直连机制，调用的Activity，可以通过bindService方法，与目标Service建立一条数据通路，拿到IBinder。这样，通过Android提供的IPC模型，就可以进行远程方法的调用和数据的传输了。
如上，通过这种模式，可以解决一定问题，但是对于Service来说，实在是太大才小用了，Service的专长，不是在数据，还是在逻辑。对于传数据而言，Service还是重量了一点，不但是有连接耗精力，传输经由IPC，写起来也够费劲。而且作为组件，Service随时可能死掉，你还是要费劲心机的处理数据的持久化，得不偿失。利用Application传输
好吧，如果你需要在不同页面之间共有某个内存对象，很合适的一种方式是把它们扔到Application里面。Application是Context的一个子类，它会在整个应用任何一个组件起来之前，先起来嘘嘘。它的生命周期会贯穿整个应用所有组件的生命旅途，因此，放在其中的对象，不会被处理掉。在Activity中，可以通过getApplication接口，随时获得Application对象的引用，用于实现一些全局对象的存储，和处理，真是最合适不过的地方了。当然，好东西也不要使用过度，可以想象，由于Application存活周期长，其上引用的对象一直缺少被释放的机会，如果你把它当成垃圾场，什么东西都往里扔，污染环境，混乱逻辑不提，单就是滥用内存资源这一项，就够罪孽深重一把了。因此，如果数据不是真的需要全局使用，不要搁在其中，如果数据太大，不要全部load出来，合理使用数据库等外存储设备，还是必须要的。结语
还有一些特殊情况，可以考虑用一些特殊的方式。比如子Activity之间，可以通过调用getParent获得父Activity的引用，来访问期间的对象，云云。小众情况，姑且不提。
以上这些概念，我相信所有的coder都了如指掌，如何处理这样的数据，都心如明镜。我只是给它们套上了一件Android的外衣，让初入Android的coder们，能迅速找到心仪的兵器，劈山砍石，攻城拔寨。 -
转载：深入Android【七】 —— 资源文件
51_51testing 发布于 2010-10-05 15:30:20
转载自：http://www.cnblogs.com/duguguiyu/archive/2010/05/02/1726069.html资源文件
作为一枚coder，做界面，很多时候都是一场梦魇。很多时候，我们会感觉对于底层逻辑实现的很有把握性，哪怕需求一直在变，也可以通过不断的重构一直跟进，一切尽在掌握。但遭遇界面，往往就不再如此，它的好坏总是和审美、体验之类的词汇扯在一起，在凤姐芙蓉出没的年头，谈审美成为一件恐怖的事情。你可能会被要求不停的改代码，就为了移动一个像素，调整一枚按钮，琐碎而无聊。
为了改变这样的状况，挽救coder们于水生活热之中，很多开发平台，都采用了类似于资源文件的解决方案。此类方案的基本思想是，将界面的实现与底层逻辑的实现完全剥离开来，用资源文件这样的东西来描述界面。资源文件的描述语言，往往是结构化很强，比如Html，Xml（及其变形体）之类的。于开发语言相比，此类语言逻辑性较弱但结构更好可读性更强更容易理解，并对自动化工具非常友好，可以于界面的拖拽配置结合的更加完美。这样的剥离，可以是的底层逻辑和上层界面独立变化，甚至不同的人员开发（这一点在web开发上表现的应该很明显...），两者之间的耦合性非常的小，coder们的负担，陡然减少（好吧，一个很挫的资源架构也会额外增加开发人员的负担，Symbian同学，请不要对号入座...）。结构和格式
Android的资源文件，是由目录结构，Xml格式的文件，和纯数据文件构成。从格式上来看，无疑，学习门槛非常低。Xml作为coder们的瑞士军刀，哪怕使不习惯，弄得清楚并会用至少是没有问题。从配套的工具来看，Android的ADT，提供了一套可视化的配置工具，说不上特别好用，但至少是差强人意能凑合着用，比不上iPhone的，调戏Symbian还是没有问题的［强档广告首播：有道词典 for iPhone新版火热上线，增加了超强单词本功能，特有的触电式颤抖单词切换功能，让你欲罢不能，持有相关设备的童鞋不要犹豫，一拥而上吧...］。
Android的资源文件，覆盖面超级广，只要是和界面相关的，都可以用资源文件表示，比如：UI的样式，菜单，配置文件，各种描述性字符串，图片，音频视频文件，动画，颜色，尺寸，风格和样式，等等等。所有的资源文件（不考虑asset，它和讨论暂无关联...），都放在res目录下，不同类别的资源，需要放置在不同的特定名称的子文件夹中，或者是写在特定文件名的文件中（或者ms不是必须的，但，不用在这里特立独行，寻章办事也挺好...）。比如，所有作为UI背景之类的图片，都需要扔在drawable这类的文件夹中，所有字符串相关的，都会放到values目录下形如strings.xml这样的文件中（如下图所示，是一个资源文件目录结构的截图...）。每个xml文件，都有一定的约定。比如一个字符串，会放在<string></string>这样的xml element中（如下图所示...），你可以通过eclipse的ADT插件提供的可是界面去填而不关注具体规范，也可以直接人肉打造，前者对于新手来说更为直观，后者对于老鸟而言更为迅捷。可配置性
程序逻辑总是不变应万变的，但界面往往是需要能够72变。首先一种变化因素，就是状态。想象一下，我们往往会有这样类似的需求，一个按钮，我们需要没有按下去的时候是一种背景，按的过程中刷的变成另一副模样，当它可用的时候需要鲜鲜亮的一个样子，不可用的时候最好是灰不溜秋没人愿点的怂样，诸如此类。传统编程模型下（Symbian，哥叫你出来当模特...），我们总是需要不厌其烦的用代码控制这样的事情。监听不同的事件，见缝插针的切换背景，并祈祷上天，千万别让哥调整，否则哥和你没完。
在Android中，做这个事情，变得简单许多，通过预设的一些Xml属性，能够轻松的搞定。如上图所示，是Radio Button的背景。通过搭配不同的属性，就可以自动转换背景。比如第一个<item>，说的是当Radio Button被选中，并且具有焦点的时候，显示btn_radio_on这幅图片，而最后一个<item>，说的是前述条件都不满足，并且处于选中状态，那么显示btn_radio_on这幅图片。另外一个更易变的因素，就是手机硬件／软件环境了，毕竟，不是家家都是苹果，一个平台搭一款手机，手机款形多样化，几乎是避免不了的问题。没有人希望自己做的软件在大屏幕手机上闪亮光鲜，换个小屏幕就惨不忍睹，竖屏看像那么回事横屏看就挤做一团。还有就是语言环境了，做为一个有国际眼光的coder，作面向世界的NB软件是咱的梦想，但我们不能因为自己的梦想逼迫大家都去学中文，做一款软件可以根据手机的语言环境选择最合适展示的语言，很多时候，是一个需要具备的功能点。
在Android中，实现这些，都是举手之劳。方法就是将和环境相关的资源，放入特定名称的文件夹中。比如，表示简体中文字符信息的资源，可以放到values-zh-rCN中去，当系统语言环境为简体中文时，就会呈现出中文的字符信息。在Android中，很多相关配置项，都可以按照这样的方式参与到资源自适应的活动中来，包括屏幕大小，屏幕朝向，屏幕分辨率，语言环境，触屏类型，SDK版本等等。系统会给所有配置项一个优先级（或者说权重，次序之类的），当用户提供了多份资源的时候，系统会根据优先级从高到底淘汰备选资源，如果淘汰仅剩了一个，那就是最符合当前系统软硬件语言环境的资源项，如果一个不剩，择启用默认项（最是形如values这样没有任何尾巴目录中的资源...）。因此，默认的资源是非常重要的，它必须是其他所有可选资源项的超集，否则在资源选择失败的情况下，应用会凄凉的崩溃。R类
在使用资源后，界面逻辑与底层逻辑的耦合被降低了，但这不意味着，两者没有关联了。比如，需要为某个按钮增加一个点击事件，就需要定位到所需的那个按钮；再比如，你需要使用某个字符串资源，通知用户某件事情，就需要能定位到资源中放置的该字串。最显而易见的一种方式，就是通过字符串比较，用名字信息在资源的xml描述文件中定位到所需的内容，加载并使用。这种方式，解决了查找的问题，但反复的字符串比较，势必带来严重的效率隐患。因此，在Android中，类似于Symbian的方法，引入了一个R类。它的基本思想是，通过增加一个额外的编译器，为所有的资源项，都赋予一个32位的整形数来表示，同一个资源像的不同配置，都使用同一个id。这个整形数，就相当于这个资源项的门牌号码，能够帮助定位到对应的资源项。所有的这些整形数，都以常量的方式，整合到一个Java类中，这个类就是R类。这样，在程序中，就可以通过使用这个R类，来查找所需的资源，这就将字符串比较，简化成了一个整形数的比较，大大的节约了开销。
不得不说，这整套逻辑和Symbian中的资源文件预编译一致。但两者很不同的点在于Symbian中的整形数，代表的是一个二进制流的偏移量，资源中的内容在编译时决定了。而Android中的整形数，是一个有逻辑意义的数值，它表达了这个资源所处的资源包，类别，和脚标，它的具体内容在运行时才确定，这使得它的灵活性大大增强，付出的则是一定的效率代价。实现
按照惯例，还是要说实现的，以一个查找流程为示例。当在Activity中需要使用字符串的，会调用它的getString方法，传入R.stirng.xxx的一个整形数，换取一个符合当前机器环境配置的字符串。getString，追根溯源，来到AssetManager类中。Asset类，其实是一个空壳，它仅仅是提供了一些便利的接口，而将请求，通过JNI的接口，传入到了底层C++实现的类库中。在底层的实现，主要是在C++实现的，AssetManager，ResourceTypes等等之中。其中：- JNI文件在：framework/base/core/jni
- 头文件在：framework/base/include/utils
- CPP文件在：framework/base/libs/utils
具体实现，和前述的算法逻辑是一致的。每一个资源的id，32位，高8位表示资源包，低16位用于描述脚标，中间8位，用来说明类别。所有资源中的文件，都被预处理了，放入到了一系列的队列和表中，通过id，可以查到具体的位置。然后根据缓存的环境设置对象，跑一次淘汰算法，获得匹配的资源对象的对应文件和偏移量。然后将值读取出来，通过JNI接口，拷贝回去。以上这些描述，并不能帮助了解真实的实现细节，主要是为了促使大家对读取资源的效率有一个比较直观的认知。整个资源读取的流程比较长，但是实现在C++中，可以预想，效率比Java高一些，开发人员，应该能够根据自己的需求，决定是否将内容写入资源文件中（还是写在代码中...），是不是需要自己稍微缓存一下，诸如此类。 -
转载：深入Android 【六】 —— 界面构造
51_51testing 发布于 2010-10-05 15:25:34
转载自：UI界面，对于每个应用而言，是它与用户进行交互的门脸。好的门脸，不只是是要亮丽可人，最好还能秀色可餐过目不忘，甚至还应该有涵养有气质，彬彬有理温柔耐心。界面构造
对于开发者来说，锻造这样的面容，不但需要高超的技艺，也需要有称手的工具和对得起党的料子。俗话说，朽木不可雕也，芙蓉不是一日炼成的，不是什么平台都能叫特能书。有套好用的UI框架，对于开发者而言，真有如沙漠中的甘露，而要是撞见了杯具的UI套件，整个界面开发就有如梦魇了。Android的UI框架，最核心的，是资源和Layout体系，然后，通过完善的控件库，简明的接口设计，进一步帮助开发者，能够最快的搭建自己需要界面（听到这里，Symbian同学开始钻土...）。UI控件
做UI，有时候就像搭积木，在Android中，这个最原子的积木块，就是View。所有其他的UI元素，都是派生于此类的子孙类们。
又从SDK中偷来张图，用来描述Android的UI控件结构，在每一个window下，这都是一个标准而完整的树结构。View有一个子类ViewGroup，它相当于一个容器类或者是复合控件，所有派生与ViewGroup的子类在这颗UI树中都可以承担着父节点的职责，而另一些绕过ViewGroup从View直通下来的，就只能蜷局在叶节点的范畴内了。
之所有说这是一个很标准的控件树，是因为父控件对子控件有绝对的掌控权，每个子控件的占地面积和位置，都是基于父控件来分配的，它能够接受和处理的事件，也是父控件派发下去的。这样的结构，被很多平台和框架广泛的认可，和传统的win开发和杯具的Symbian相比，虽然因为事件传播途径变长了，很多操作的效率变低了，但整个结构更有层次性，每个控件只需要多其父控件负责指挥子控件就好，职责明确，逻辑简单，利于开发和设计。谈及任何平台的控件，都有一些不可避免的主题，比如，每个控件如何标识，如何设定大小和位置，如何接受和处理事件，如何绘制，诸如此类。标识
在Android中，你可以为每个控件选择设定一个id，这个id的全局的唯一性不需要保证，但在某个局部的范围内具有可识别性，这样就可以通过这个id找到这个控件（如果不需要查找，就别设置了...）。但是，在父控件中逐级的find比较，找到id匹配的控件，然后再做转型，是一个比较重量的操作，于是Android又为控件憋出另一个属性，tag。它接受任意object类型的数据，你可以把和这个控件对象相关的内容堆在里面。比如，在list中，我们常常将和每个list item相关的所有控件元素封装成一个object，扔到tag中，就不需要每次都去比较id进行寻找，更加高效快捷。尺寸
在Android中，控件最重要的大小属性，就是width/height，开发者可以明确的指明控件的大小，可以设定成为fill_parent和wrap_content，这样的概念性的大小。丈量并设定控件的位置，是通过两步来进行的。第一步是measure。它传入此控件的width/height信息，控件会根据自己的参数，计算出真实需要的width/height，然后调用setMeasuredDimension方法，缓存成成员变量，留作后用。在计算出大小之后，会进行另一个步骤，layout。在这个过程中，父控件会计算其上各个子控件的位置，从而完成整个大小和位置的确定流程。整个measure和layout的流程，都是自上到下，从树顶往叶子来推进的。当开发人员需要自定义控件的时候，可能需要关注这些内容，通过重载onMeasure和onLayout方法，可以定义自己控件的丈量方式。事件
在Android中，所有的按键，触屏等事件，都是从顶至下进行分发的。每个ViewGroup的对象，会维系一个focused变量，它表示在这个父控件中具备focus的控件，当有按键时间发生的时候，会找到这个focused子控件，并传递给它。同理，触屏事件的分发也是类似，只不过和focus无关，父控件会遍历所有子控件，看看谁处于触碰位置，从而传递给谁。另外还有一些事件，逻辑上并不是从顶至下发起的。比如，当你修改某个子控件的内容，使得该子控件的大小和内容都发生了变化，就需要进行控件的重排和重绘，这些操作不仅是子控件自己的事情，需要整个控件树上的所有控件都需要配合。在Android中，处理这类事情的实现策略是子控件维系一个ViewParent对象，该对象象征着整个控件树的管理者，子控件产生影响整个控件树的事件时，会通知到ViewParent，ViewParent会将其转换成一个自顶向下的事件，分发下去。Android的事件处理逻辑，采用的是观察者模式。Android的控件提供了一些列的add/set Listener的接口，使得外部观察者，有机会处理控件事件。比如，你需要在某个button被点击时做一些事情，你就需要派生一个View.OnClickListener对象作为观察者，调用该控件的setOnClickListener接口注册进去，当button被点击，就可以获得处理点击事件的机会了。当然，有的时候，你需要处理的逻辑更为复杂，光是站在外面围观叫好不能解决问题，可能就需要派生某个控件，去重载onXXXX之类的事件处理函数，进行更完整的控制。焦点
对于一个非触屏的机器，焦点的维系是一个极其重要的事情，而在有触屏的年代，焦点的地位虽有所下降，但依然还是需要妥善保护的。Android中，是以控件树为单位，来管理焦点的。每个控件，可以设置上下左右四向的focus转移对象。当在一个控件上发生焦点转移事件，Android会如前述，自顶向下根据设定好的焦点转移逻辑，跳转到正确的控件上。和Symbian相比，真是，真是。。。Layout
Layout是一类特殊的ViewGroup控件，它们本身没有任何可显示内容，形如透明的玻璃盒子，存活的唯一理由，就是其中的内部结构，能够更好的摆放它的子控件们。比如线性的Layout，LinearLayout。放入这个Layout的子控件，会按水平或垂直方向，排排坐，一个挨着一个按顺序排列下去。TableLayout，可以将子控件按照表格的形式，一枚枚放置好。而RelativeLayout则更灵活，可以设定各个控件之间的对齐和排列关系，适合定制复杂的界面。有了Layout的存在，控件和控件之间不再割裂的存在，而是更有机的结合在了一起，设定起来也更为方便。比Symbian那样人肉维系各个控件的关系，轻松自在多了。更多
这些问题的完整答案，参见SDK中View的页面：/reference/android/view/View.html。实现
有了这些对Android的UI控件的认知，可以看更整体性的实现细节，那就是Activity的UI实现。
如上图所示，假设你做了个如同虚线框中结构的一个界面，通过Activity的setContentView方法，塞进了Activity中，就会形成图示的一个逻辑关系。每一个Activity，都包含一个Window对象，它表示的是一个顶级的一整屏幕上面的界面逻辑。在Android源码中，其实现是MidWindow，它包含了一个FrameLayout对象，呈现出来就是那种带着一个title的界面样子。自定义的一堆控件，会插进Window的界面部分，在Activity中，所有事件的处理逻辑，是Window先享用，没消费掉在交由这堆控件吃剩的。在整个控件树的最顶端，是一个逻辑的树顶，ViewParent，在源码中的实现是ViewRoot。它是整个控件树和WindowManager之间的事件信息的翻译者。WindowManager是Android中一个重要的服务。它将用户的操作，翻译成为指令，发送给呈现在界面上的各个Window。Activity，会将顶级的控件注册到WindowManager中，当用户真是触碰屏幕或键盘的时候，WindowManager就会通知到，而当控件有一些请求产生，也会经由ViewParent送回到WindowManager中。从而完成整个通信流程。 -
转载：深入Android 【三】 —— 组件入门
51_51testing 发布于 2010-10-05 14:21:47
横看成岭侧成峰，远近高低各不同。 -- 《题西林壁》组件（Component），在谈及所谓架构和重用的时候，是一个重要的事情。很多时候都会说基于组件的软件架构，指的是期望把程序做乐高似的，有一堆接口标准封装完整的组件放在哪里，想用的时候取上几个一搭配，整个程序就构建完成了。在开篇的时候就在说，Android是一个为组件化而搭建的平台，它引入所谓Mash-Up的概念，这使得你在应用的最上层，想做的不组件化都是很困难的一件事情（底层逻辑，好吧，管不了...）。具体说来，Android有四大组件四喜丸子：Activity、Service、Broadcast Receiver、Content Provider。Activity做一个完整的Android程序，不想用到Activity，真的是比较困难的一件事情，除非是想做绿叶想疯了。因为Activity是Android程序与用户交互的窗口，在我看来，从这个层面的视角来看，Android的Activity特像网站的页面。首先，一个网站，如果一张页面都没有，那...，真是一颗奇葩。而一张页面往往都有个独立的主题和功能点，比如登录页面，注册页面，管理页面，如是。在每个页面里面，会放一些链接，已实现功能点的串联，有的链接点了，刷，跑到同一站点的另一个页面去了；有的链接点了，啾，可能跳到其他网站的页面去；还有的链接点了，恩...，这次没跑，但当前页面的样子可能有所变化了。这些模式，和Activity给人的感觉很像，只不过实现策略不同罢了，毕竟Android这套架构的核心思想，本身就来自源于Web的Mash-Up概念，视为页面的客户端化，也未尝不可。Activity，在四大组件中，无疑是最复杂的，这年头，一样东西和界面挂上了勾，都简化不了，想一想，独立做一个应用有多少时间沦落在了界面上，就能琢磨清楚了。从视觉效果来看，一个Activity占据当前的窗口，响应所有窗口事件，具备有控件，菜单等界面元素。从内部逻辑来看，Activity需要为了保持各个界面状态，需要做很多持久化的事情，还需要妥善管理生命周期，和一些转跳逻辑。对于开发者而言，就需要派生一个Activity的子类，然后埋头苦干上述事情。对于Activity的更多细节，先可以参见：reference/android/app/Activity.html。后续，会献上更为详尽的剖析。Service服务，从最直白的视角来看，就是剥离了界面的Activity，它们在很多Android的概念方面比较接近，都是封装有一个完整的功能逻辑实现，只不过Service不抛头露脸，只是默默无声的做坚实的后盾。但其实，换个角度来看，Android中的服务，和我们通常说的Windows服务，Web的后台服务又有一些相近，它们通常都是后台长时间运行，接受上层指令，完成相关事务的模块。用运行模式来看，Activity是跳，从一个跳到一个，呃...，这有点像模态对话框（或者还像web页面好了...），给一个输入（抑或没有...），然后不管不顾的让它运行，离开时返回输出（同抑或没有...）。而Service不是，它是等，等着上层连接上它，然后产生一段持久而缠绵的通信，这就像一个用了Ajax页面，看着没啥变化，偷偷摸摸的和Service不知眉来眼去多少回了。但和一般的Service还是有所不同，Android的Service和所有四大组件一样，其进程模型都是可以配置的，调用方和发布方都可以有权利来选择是把这个组件运行在同一个进程下，还是不同的进程下。这句话，可以拿把指甲刀刻进脑海中去，它凸显了Android的运行特征。如果一个Service，是有期望运行在于调用方不同进程的时候，就需要利用Android提供的RPC机制，为其部署一套进程间通信的策略。Android的RPC实现，如上图所示（好吧，也是从SDK中拿来主义的...），无甚稀奇，基于代理模式的一个实现，在调用端和服务端都去生成一个代理类，做一些序列化和反序列化的事情，使得调用端和服务器端都可以像调用一个本地接口一样使用RPC接口。Android中用来做数据序列化的类是Parcel，参见：/reference/android/os/Parcel.html，封装了序列化的细节，向外提供了足够对象化的访问接口，Android号称实现非常高效。还有就是AIDL (Android Interface Definition Language) ，一种接口定义的语言，服务的RPC接口，可以用AIDL来描述，这样，ADT就可以帮助你自动生成一整套的代理模式需要用到的类，都是想起来很乏力写起来很苦力的那种。更多内容，可以再看看：guide/developing/tools/aidl.html，如果有兴致，可以找些其他PRC实现的资料lou几眼。关于Service的实现，还强推参看API Demos这个Sample里面的RemoteService实现。它完整的展示了实现一个Service需要做的事情：那就是定义好需要接受的Intent，提供同步或异步的接口，在上层绑定了它后，通过这些接口（很多时候都是RPC的...）进行通信。在RPC接口中使用的数据、回调接口对象，如果不是标准的系统实现（系统可序列化的），则需要自定义aidl，所有一切，在这个Sample里都有表达，强荐。Service从实现角度看，最特别的就是这些RPC的实现了，其他内容，都会接近于Activity的一些实现，也许不再会详述了。Broadcast Receiver在实际应用中，我们常需要等，等待系统抑或其他应用发出一道指令，为自己的应用擦亮明灯指明方向。而这种等待，在很多的平台上，都会需要付出不小的代价。比如，在Symbian中，你要等待一个来电消息，显示归属地之类的，必须让自己的应用忍辱负重偷偷摸摸的开机启动，消隐图标隐藏任务项，潜伏在后台，监控着相关事件，等待转瞬即逝的出手机会。这是一件很发指的事情，不但白白耗费了系统资源，还留了个流氓软件的骂名，这真是卖力不讨好的正面典型。在Android中，充分考虑了广泛的这类需求，于是就有了Broadcast Receiver这样的一个组件。每个Broadcast Receiver都可以接收一种或若干种Intent作为触发事件（有不知道Intent的么，后面会知道了...），当发生这样事件的时候，系统会负责唤醒或传递消息到该Broadcast Receiver，任其处置。在此之前和这以后，Broadcast Receiver是否在运行都变得不重要了，及其绿色环保。这个实现机制，显然是基于一种注册方式的，Broadcast Receiver将其特征描述并注册在系统中，根据注册时机，可以分为两类，被我冠名为冷热插拔。所谓冷插拔，就是Broadcast Receiver的相关信息写在配置文件中（求配置文件详情？稍安，后续奉上...），系统会负责在相关事件发生的时候及时通知到该Broadcast Receiver，这种模式适合于这样的场景。某事件方式 -> 通知Broadcast -> 启动相关处理应用。比如，监听来电、邮件、短信之类的，都隶属于这种模式。而热插拔，顾名思义，插拔这样的事情，都是由应用自己来处理的，通常是在OnResume事件中通过registerReceiver进行注册，在OnPause等事件中反注册，通过这种方式使其能够在运行期间保持对相关事件的关注。比如，一款优秀的词典软件（比如，有道词典...），可能会有在运行期间关注网络状况变化的需求，使其可以在有廉价网络的时候优先使用网络查询词汇，在其他情况下，首先通过本地词库来查词，从而兼顾腰包和体验，一举两得一石二鸟一箭双雕（注，真实在有道词典中有这样的能力，但不是通过Broadcast Receiver实现的，仅以为例...）。而这样的监听，只需要在其工作状态下保持就好，不运行的时候，管你是天大的网路变化，与我何干。其模式可以归结为：启动应用 -> 监听事件 -> 发生时进行处理。除了接受消息的一方有多种模式，发送者也有很重要的选择权。通常，发送这有两类，一个就是系统本身，我们称之为系统Broadcast消息，在reference/android/content/Intent.html的Standard Broadcast Actions，可以求到相关消息的详情。除了系统，自定义的应用可以放出Broadcast消息，通过的接口可以是Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者发出的称为Normal broadcast，所有关注该消息的Receiver，都有机会获得并进行处理；后者放出的称作Ordered broadcasts，顾名思义，接受者需要按资排辈，排在后面的只能吃前面吃剩下的，前面的心情不好私吞了，后面的只能喝西北风了。当Broadcast Receiver接收到相关的消息，它们通常做一些简单的处理，然后转化称为一条Notification，一次振铃，一次震动，抑或是启动一个Activity进行进一步的交互和处理。所以，虽然Broadcast整个逻辑不复杂，却是足够有用和好用，它统一了Android的事件广播模型，让很多平台都相形见绌了。更多Broadcast Receiver相关内容，参见：/reference/android/content/BroadcastReceiver.html。Content ProviderContent Provider，听着就和数据相关，没错，这就是Android提供的第三方应用数据的访问方案。在Android中，对数据的保护是很严密的，除了放在SD卡中的数据，一个应用所持有的数据库、文件、等等内容，都是不允许其他直接访问的，但有时候，沟通是必要的，不仅对第三方很重要，对应用自己也很重要。比如，一个联系人管理的应用。如果不允许第三方的应用对其联系人数据库进行增删该查，整个应用就失去了可扩展力，必将被其他应用抛弃，然后另立门户，自个玩自个的去了。Andorid当然不会真的把每个应用都做成一座孤岛，它为所有应用都准备了一扇窗，这就是Content Provider。应用想对外提供的数据，可以通过派生ContentProvider类，封装成一枚Content Provider，每个Content Provider都用一个uri作为独立的标识，形如：content://com.xxxxx。所有东西看着像REST的样子，但实际上，它比REST更为灵活。和REST类似，uri也可以有两种类型，一种是带id的，另一种是列表的，但实现者不需要按照这个模式来做，给你id的uri你也可以返回列表类型的数据，只要调用者明白，就无妨，不用苛求所谓的REST。另外，Content Provider不和REST一样只有uri可用，还可以接受Projection，Selection，OrderBy等参数，这样，就可以像数据库那样进行投影，选择和排序。查询到的结果，以Cursor（参见：reference/android/database/Cursor.html ）的形式进行返回，调用者可以移动Cursor来访问各列的数据。Content Provider屏蔽了内部数据的存储细节，向外提供了上述统一的接口模型，这样的抽象层次，大大简化了上层应用的书写，也对数据的整合提供了更方便的途径。Content Provider内部，常用数据库来实现，Android提供了强大的Sqlite支持，但很多时候，你也可以封装文件或其他混合的数据。在Android中，ContentResolver是用来发起Content Provider的定位和访问的。不过它仅提供了同步访问的Content Provider的接口。但通常，Content Provider需要访问的可能是数据库等大数据源，效率上不足够快，会导致调用线程的拥塞。因此Android提供了一个AsyncQueryHandler（参见：reference/android/content/AsyncQueryHandler.html），帮助进行异步访问Content Provider。在各大组件中，Service和Content Provider都是那种需要持续访问的。Service如果是一个耗时的场景，往往会提供异步访问的接口，而Content Provider不论效率如何，都提供的是约定的同步访问接口。我想这遵循的就是场景导向设计的原则，因为Content Provider仅是提供数据访问的，它不能确信具体的使用场景如何，会怎样使用它的数据；而相比之下，Service包含的逻辑更复杂更完整，可以抉择大部分时候使用某接口的场景，从而确定最贴切的接口是同步还是异步，简化了上层调用的逻辑。配置四大组件说完了，四大组件幕后的英雄也该出场了，那就是每个应用都会有一份的配置文件，名称是AndroidManifest.xml，在工程的根目录下。在这个配置文件中，不仅会描述一些应用相关的信息，很重要的，会包含一个应用中所有组件的信息。如果你派生Activity或者Service实现了一个相关的类，这只是把它组件化的第一步，你需要把这个类的相关信息写到配置文件中，它才会作为一个组件被应用到，否则只能默默无闻的黯淡度过余生。
摆了一幅图出来，这次不是偷来的，是敝帚自珍原创，所以没有意外的画的很丑，但基本还是可以体现出一些意思。在In Others的部分，这里是一般平台应用之间通信和交互的模型，每个应用都有很强烈的应用边界（往往表现为进程边界...），App 1的还是App 2的，分得很是清楚。每个应用内部，都有自己的逻辑去切分功能组件，这样的切分通常没有什么标准，率性而为。应用间的交互逻辑也比较零散，App 1与App 2交互，往往需要明确知道对方应用的具体信息，比如进程ID，进程名称之类的，这样使得应用和应用之间的联系，变得很生硬。而上层应用和系统应用的通信，往往有很多特定的模式，这种模式，很可能是无法直接应用在普通应用之间的，换而言之，系统应用是有一定特殊性的。重点，在图的下半部，描述的是Android的应用情形。在Android中，应用的边界，在组件这个层面，是极度模糊，什么进程、什么应用，都可以不必感知到。举个例子，App 1，实现了A和B两个组件，App 2，实现了C这个组件。A和C，都想使用B这个组件，那么它们的使用方式是完全一致的，都需要通过系统核心的组件识别和通信机制，找到和使用组件B。A，虽说和B是一个娘胎里蹦出来的，很不好意思，没有任何特殊的后面和捷径，还是要跑规矩的途径才能用到，一片和谐社会的景象油然而生。在Android中，所有组件的识别和消息传递逻辑都必须依赖底层核心来进行（通信可以没有底层核心的参与，比如一旦Service找到了，就可以和它产生持久的通信...），没有底层核心的牵线搭桥，任何两个组件都无法产生联系。比如一个Activity，跳到另一个Activity，必须要向底层核心发起一个Intent，有底层解析并认可后，会找到另一个Activity，把相关消息和数据传给它。一个Activity想使用Content Provider中的数据，必须通过底层核心解析相关的uri，定位到这个Content Provider，把参数传递给它，然后返回Activity需要的Cursor。这样的设计，保证了底层核心对所有组件的绝对掌控权和认知权，使得搭积木似的开发变成可能。为了，使得核心系统能够完整的掌握每个组件的信息，这就需要配置文件了。配置文件，就是将组件插到底层核心上的这个插头。只有通过这个插头插在底层核心的插座上（不要乱想，非十八禁...），组件才能够发光发热，闪耀光芒。组件的配置信息在我看来主要包含两个方面，一部分是描述如何认知。比如，Activity、Service、Broadcast Receiver都会有名字信息，和希望能够把握的Intent信息（姑且看成消息好了...），Content Provider会有一个描述其身份的uri。当其他组件通过这样的名字或者Intent，就可以找到它。另一部分是运行相关的信息。这个组件，期望怎么来运行，放在单独的进程，还是和调用者一个进程，还是找相关的其他组件挤在同一个进程里面，这些内容，都可以在配置的时候来决定（调用者在这个约束范围内，有进一步的选择权...）。更多配置项，请参见：guide/topics/manifest/manifest-intro.html。通过前续内容，也许可以帮助大家对Android组件有个初略的了解。但这些了解都还停留在静态层面，程序是个动态的概念，关于各个组件具体是怎么联系在一起的，如何手拉手运行起来完成一项功能的，这便是后话了。 -
转载：深入Android 【二】 —— 架构和学习
51_51testing 发布于 2010-10-05 14:16:45
转载自: http://www.cnblogs.com/duguguiyu/archive/2010/01/23/1654559.html千呼万唤始出来，犹抱琵琶半遮。 -- 《琵琶行》虽贵为富二代，但Android要是没任何可圈点的地方，开不过70迈，在玲琅满目的手机平台竞争中，充其量也就做几个俯卧撑打一桶酱油，然后被落的远远的。说到底，出来混，靠的还是技术。架构从SDK文档中，偷来一幅Android平台的架构图，如上。在整个架构最底层红彤彤的部分，是Linux Kernel在移动平台的一个移植，它隐藏了硬件、网络等相关的细节，为上层提供了一个相对纯洁的统一接口。除非要做的是Android到不同设备的移植工作，否则对于大部分普通开发者而言，基本上是远观而不必亵玩的。Google一直强调，Android的底层实现异常NB，可移植性超强，暂没有功夫研读，实属遗憾。靠上一层，是一些核心的和扩展的类库，它们都是原生的C++实现。在这一层，你可以看到很多熟悉的面孔，一如SQLite、WebKit、OpenGL，开源的力量与贡献由此可见。如果，该层类库需要被上层函数调用，就必须要通过JNI的导出相应的接口函数，否则就只能在层次内部自个把玩。也是在这一层次上，还有为上层Java程序服务的运行时。Dalvik虚拟机，是Android的Java虚拟机，之所以不采用J2ME的虚拟机，一方面是因为J2ME的设计是为了低端机器而优化，而Dalvik则是为了高端一些的机器进行优化，提供更好的性能。另一方面，从商业角度来看，必须绕开J2ME虚拟机，Android才能彻底解放，想怎么开源就怎么开源，不再需要考虑License的问题。再往上，终于有Java出没了。首先是框架层，这里包含所有开发所用的SDK类库，另外还有一些未公开接口的类库和实现，它们是整个Android平台核心机制的体现。而在最上面，就是应用层了，系统的一些应用和第三方开发的所有应用都是位于这个层次上，也许要纠结两者的差别，就是系统应用会用一些隐藏的类，而第三方的应用，总是基于SDK提供的东西来搞。一般来说，Android开发，就是在SDK的基础上，吭哧吭哧用Java写应用。但自从有了NDK，一切有了写小变化。NDK的出现意味着，最上面应用层的内容，可以穿越Java部署的框架层，直接和底层暴露出来的，或者自行开发的C++库直接对话，当然在这些库中需要包含JNI的接口。人说，这就不是Android也可以用C++开发应用么，但其实，这样的说法不够确切，纯C++应用，是无法被接受的。因为在Android中，大量的核心机制部署在框架层，它们都是用Java实现的，比如控件库，Activity的调度之类的。因此，没了界面，没了调度，还是只用C++做类库比较合适，否则一切都乱了套了。特征基于这样的架构，Android有很多的设计显得很有意思。纵览整个SDK和核心机制的设计，工整漂亮，是Android给人的第一感觉。为了说明这一点，找一个反面教材是很有必要的，Symbian同学毫无悬念的担当这个伟岸的角色。写Symbian程序，感觉就像是在玩一个猜谜游戏。哪怕你是一个Symbian老手，当需要用到Symbian中某块陌生功能的时候，你可能依然束手无策。你往往需要猜并反复找寻，在这里我需要使用哪一种奇巧淫技呢，是该臆想某些事件，还是应该用一个神秘的UID寻找某个特定应用，诸如此类。而做Android应用的时候，就像是做高考模拟试题，题看上去不一样，解答模式摸清楚，就一通百通，一了百了。监听某个系统事件，查一下SDK就好；访问某个应用的数据，看看它有没有提供Content Provider就可以。所有的一切，都是按套路出牌，只要你了解了套路，再陌生的牌也可以看得懂，出的顺。人说武林高手，都应该是无招胜有招，而一个好的应用框架，也应该做到举重若轻，可触类旁通。而Android框架最文采飞扬的一点，就是引入了Mash-Up的思想。所谓Mash-Up，就是把写应用搞成搭积木，要出效果的时候，东家一块西家一块现场拼起来就好。这里面关键有两点，一个是模块化，另一个就是动态性。所谓模块化，就是一个应用的功能要明确的被封成一个个边界清晰的功能点，每一个功能点都像是一个黑盒，由预先定义的规则描述出其交互方式；而动态性，就是这些独立的模块能够在运行的时候，按照需求描述，连接在一起，共同完成某项更大的功能。在这两点上，Android都做得非常出色。站在可Mash-Up构造应用这一点去看其他的一些Android中的核心功能设计，就显得很有章可循了。比如为什么要把文件私有化，为什么要让进程被托管，等等（当然也可以站在别的角度看出不同的效果，视角不同，视野自然不同...）。在UI机制方面，Android也有很不错的表现。它采取xml格式的资源文件，描述所有界面相关的内容。资源文件不是什么新东西了，xml格式也是老调重弹，但可贵的是Android做的更为的丰富和彻底，基本把界面相关的逻辑，全部从代码中剥离到了资源文件中，和Symbian那四不像的资源文件相比，真是强大了不知多少倍了。Android学习入门不积跬步，无以至千里。 -- 《劝学》说，万事开头难。想开始Android的开发，最重要的应该是先把马步扎稳，套路摸清楚，后面的事情就顺当多了。打开怀抱，拥抱Android，也许可以先做下面这些事。开发环境辣手摧花成性的GFW，无情的把Android开发者官网关在了墙外。不过没关系，猛击这里，同样可以殊途同归（Shit，一直在用代理，刚试了下，发现竟然也被盾了，如果不行，那就只能翻墙了...）。如果旅途顺利，你可以在路径sdk/index.html下找到安装说明，成功配置好Android的开发环境（【注】：在以后，如果要给开发者页面上的链接，都会给一个像sdk/index.html这样的相对路径，你可以在前面加上官网地址，或者本地SDK的doc地址拼凑成完整的路径，在一个盾牌横行的朝代，只能用这样委屈求全的方法保证能更好的使用...）。在2.0之前，每一次版本更新，你都要自己去下个全新的SDK，然后按照说明，小心翼翼的一步步修改eclipse的设置，甚是麻烦。在2.0后，这个模式有所改善，你会先下到一个类似于下载器的插件，通过它可以来管理和升级SDK，不仅简化了整个升级模式，还使得你可以更好的在各个不同的SDK版本间游走，利国利民。Eclipse + ADT（Android Development Tool），是正牌的Android开发环境。你可以在Windows，Linux，Mac下做开发，甚为自由。比之Symbian的开发环境，ADT显得尤为强大，它对SDK提供的一堆优秀的命令行工具进行了UI上的封装，提供了图形界面（命令行控当然同样幸福，具体参见：guide/developing/tools/index.html）。通过ADT，你可以用运行和管理模拟器，使用调试器进行调试，过滤和查看Log，浏览模拟器上的文件信息，模拟拨号、短信等手机才有的事件，等等。文档我知道，有很多人在学习一个新平台开发的时候，都习惯去买一些《xxx 21天精通》之类的书籍。但其实，最好的入门学习资料，就是SDK文档。因为只有做平台的自己，才能最了解平台中的各个玄机，各方面的轻重缓急，从而能够更好的对症下药药到病除。在Android的SDK中，guide/index.html是由浅入深的教学文档，reference/packages.html是标准的API文档。对于教学文档，我的意见是，一字不拉的通读一遍甚至多遍，至少做到能对Android摸着头脑，并且碰到问题的时候，能够快速想起在哪里可以找到，回来深刻阅读。而API文档方面，Android做的算是还不错了。基本上每个类，每个接口，都有标准而详尽的说明，在一些尤为重要的类中，还具有大量的学习性的内容，不和Symbian似的，有太多的太监类，只有光秃秃的一个函数，一行文档说明都没有。整个文档结构是按照Java包来组织的，本身Java包命名的结构性和可读性很强，找起来也颇为方便。很多人对SDK文档有抵触情绪，我想，有两方面的原因。一则是SDK文档普遍缺少文学性，麻木不仁的八股文，难以下咽。Android在这方面做得算是乏善可陈，虽然算不上文采华丽，但还是挺适合阅读的。另一则，就会是语言方面的原因了。SDK文档多为英语，偶尔像MSDN这样有中文的，也停留在机器翻译的水平上，阅读起来颇为难受。特地在网上搜了下，找到一些翻译SDK的中文文档，比如这里。虽然是基于1.5 r1版本SDK所著，稍显过时，但翻译的还是有小用心的，作为辅助，也不失为一份好资料，特代表广大看官向这些为人民福利着想的同志致敬。Tutorials光说不练假把式，除了读，在入门阶段，写也是一项不能少的运动。同样是在SDK中，Android提供了一组Tutorials和一些列的Samples，详见：resources/index.html。Tutorials很简单，Hello World只是在教你如何在eclipse中，在ADT的帮助下，创建一个Android项目。相比之下，Hello Views复杂了些，它集中展示了几种标准的Android Layout 样式是如何构建的，很多时候，你都是在这些样式下扩展所需的UI。Hello Localization，是教你如何使用资源的，做完这个，就可以了解Android的资源有多杀～。最后收官的是一个更为完整的Notepad Tutorial，它展示了很多Android的核心机制，比如基于Intent的Activity整合，Activity的生命周期等。迈过这个Tutorial，欢迎你，进入Android的大门。当然，做完Tutorials，对于Android而言，只是管中窥豹略见一斑。在SDK中，还提供了一系列的Samples。可以根据自己的需求，挑选合适的Sample编译运行和学习。但其中，有一个是不论你做什么，都需要必看必读必熟悉的，就是API Demos。在这个Sample中，集中展示了Android重点功能的API使用，把这个Sample用熟悉，需要做什么的时候过去找一下就可以很快的入手了。源码到这里，很多看官一定很不屑，前面所谓的学习入门介绍，只不过是围着SDK打转。其实，事实也是如此，SDK中包含的内容是真的非常重要，我只是期望通过一些简短的介绍，激起一些初学者的重视，如是而已。当然，SDK每一个平台都有，没什么稀罕的。但Android有另一个非常稀罕而值钱的看家法宝，就是源代码。从Android Source的主站上：http://source.android.com/，你可以获得整个平台的源码以及相关介绍。非常苦口婆心的期望大家都去down一份源码放在机器上，哪怕你不需要进行修改编译，放在机器上当百科全书也是远胜于任何一本Android教学书籍的。本系列文章后续很多内容，都是从源码中学习到的一些浅薄见识。对于大部分开发者都有学习价值的源码，主要在源码的frameworks和packages目录下。前者包含的是平台核心的一些实现，比如你需要自定义一个控件，也许你就可以翻到一个系统控件的实现中去，看看它是怎么来做的。后者包含一些系统的应用实现，比如你想做个播放器，也许你可以先去参考参考系统自带的是具体怎么做的。这样的实现，即便不算是最华美，至少也是最标准，其价值不容小视。另外，你也可以把它当个代码库来使，不会使用某个类，grep一把，也许就能获得一份最漂亮的Sample。当然，如果你有时候对某些系统机制表示费解，抑或有一些bug不知道源头在哪，都可以跟着源码顺藤摸瓜的搞清楚。这样的好东西，可不是每个平台都能够享用的。其他论坛，其实对于开发和学习都是很重要的资源。毕竟，所有的资料都是死的，只有人是活得，能够最大限度的因地制宜解决问题。只不过，标准的官方论坛，放在Google Group上，已经惆怅的被盾了。中文论坛方面，没有特别优秀和活跃的，这一方面是由于Android的发展现状还不算很磅礴，另一方面是由于Android的开发相对于Symbian而言，奇技淫巧少了很多，没有那么多好问的。也许你可以去去csdn这样的传统论坛，或者eoe这样专门的论坛。有的时候，还是多少能获得一些帮助的。书籍方面，真没有什么推荐，豆瓣上搜索一下，你可以看到，目前的书籍，基本上还是集中在SDK使用层面上，很少有解析的很透彻，做的很深入的。而SDK的使用，看SDK的文档就足够了，如果实在对e文不感冒，买一两本评价不太差的中文书籍，放着翻翻也还是挺好。更进一步，也许可以读读一些经验性的文档，去Google Code上搜索一些代码回来看看。比如，SDK文档中，有个经验性文档的集合：resources/articles/index.html，就可以翻看一下。最后，更多的一切还需要自己在工程和思考中，慢慢总结。相信，好的代码，会垂青一个勤于动手和思考的人。 -
转载：使用Junit对Android应用进行单元测试（二）
51_51testing 发布于 2010-10-29 09:18:01
转载自：http://tech.it168.com/a2010/1027/1118/000001118903_all.shtml
步骤12 SimpleCalc计算器中的加法测试用例
我们首先针对SimpleCalc中的加法进行测试用例的编写。这个测试用例中，会输入两个数(24和74)，并测试是否其结果等于98。为了模拟在输入数字后点按钮的效果，我们使用了sendkeys方法，这个方法的优点在于可以在输入后自动将焦点切换到下一个控件上。最后，我们使用assertTrue的断言去判断实际结果是否就是等于98，代码如下：
private static final String NUMBER_24 = "2 4 ENTER ";
private static final String NUMBER_74 = "7 4 ENTER ";
private static final String ADD_RESULT = "98";
public void testAddValues() {
sendKeys(NUMBER_24);
// now on value2 entry
sendKeys(NUMBER_74);
// now on Add button
sendKeys("ENTER");
// get result
String mathResult = result.getText().toString();
assertTrue("Add result should be 98", mathResult.equals(ADD_RESULT));
}
步骤13 改进测试用例
由于每次测试时，其实都是使用同一个activity的，因此在每次测试时不需要清除旧的值，我们可以在一个sendKeys()方法中，发送一系列的输入命令，如下所示：
sendKeys(NUMBER_24 + NUMBER_74 + "ENTER");
我们测试一个小数的情况如下，看结果是否等于79.5
public void testAddDecimalValues() {
sendKeys(NUMBER_5_DOT_5 + NUMBER_74 + "ENTER");
String mathResult = result.getText().toString();
assertTrue("Add result should be " + ADD_DECIMAL_RESULT + " but was "
+ mathResult, mathResult.equals(ADD_DECIMAL_RESULT));
}
同样，我们去编写乘法的单元测试用例，这里我们继续使用sendKeys()方法，由于乘法的按钮就在加法的按钮右边，所以我们在用sendkey模拟输入了两个数后，发送“DRAD_RIGHT”的消息，就可以了。
public void testMultiplyValues() {
sendKeys(NUMBER_24+NUMBER_74+ " DPAD_RIGHT ENTER");
String mathResult = result.getText().toString();
assertTrue("Multiply result should be " + MULTIPLY_RESULT + " but was "
+ mathResult, mathResult.equals(MULTIPLY_RESULT));
}
步骤14 在模拟器中运行单元测试
运行单元测试的方法很简单，鼠标右键项目，在弹出的菜单中选择“Debug ASàAndroid JUnit Test”即可，运行结果如下两图所示：
▲
▲其中红色的表示测试没办法通过，绿色的条状表示测试已经通过。
步骤15 Android中对屏幕显示的单元测试
在Android 的单元测试中，还可以针对界面的显示位置等进行单元测试。比如我们在Eclipse时开发采用的界面模拟器是在800*480的模式下的，但如果在其他尺寸规格的移动设备上是否能正常运行呢?这就需要对界面设置部分进行单元测试了。
我们另外创建一个单元测试用例，用前文所讲的方法新建立一个名为LayoutTests的单元测试用例，如下图：
▲并编写如下代码：
package com.mamlambo.article.simplecalc.test;
import android.test.ActivityInstrumentationTestCase2;
import android.view.View;
import android.widget.Button;
import com.mamlambo.article.simplecalc.MainActivity;
import com.mamlambo.article.simplecalc.R;
public class LayoutTests extends ActivityInstrumentationTestCase2 {
private Button addValues;
private Button multiplyValues;
private View mainLayout;
public LayoutTests() {
super("com.mamlambo.article.simplecalc", MainActivity.class);
}
protected void setUp() throws Exception {
super.setUp();
MainActivity mainActivity = getActivity();
addValues = (Button) mainActivity.findViewById(R.id.addValues);
multiplyValues = (Button) mainActivity
.findViewById(R.id.multiplyValues);
mainLayout = (View) mainActivity.findViewById(R.id.mainLayout);
}
}这里，分别获得了加法按钮和乘法按钮的实例。接下来，增加一个testAddButtonOnScreen
的方法，以测试按钮的位置是否正确。在这个方法中，首先你要决定屏幕的大小。有很多方
法去检测屏幕的大小，比如用getWidth()和getHeight()方法，当然在考虑尺寸时，还必须考
虑象标题栏，状态栏等所占用的位置大小。下面是其代码：
public void testAddButtonOnScreen() {
int fullWidth = mainLayout.getWidth();
int fullHeight = mainLayout.getHeight();
int[] mainLayoutLocation = new int[2];
mainLayout.getLocationOnScreen(mainLayoutLocation);
int[] viewLocation = new int[2];
addValues.getLocationOnScreen(viewLocation);
Rect outRect = new Rect();
addValues.getDrawingRect(outRect);
assertTrue("Add button off the right of the screen", fullWidth
+ mainLayoutLocation[0] > outRect.width() + viewLocation[0]);
assertTrue("Add button off the bottom of the screen", fullHeight
+ mainLayoutLocation[1] > outRect.height() + viewLocation[1]);
}在各类尺寸的模拟器上运行，可以得到如下结果所示的测试结果：
480x800, portrait 模式 (通过)
800x480, landscape mode (失败)
320x480, portrait mode (失败)
480x320, landscape (失败)
480x854, portrait mode (通过)
854x480, landscape mode (失败)?
大家可以思考下为什么有的测试用例成功有的失败。
总结
本文讲解了如何使用junit配合Android的应用进行单元测试及详细步骤，以及如何在
Junit测试Android时的小技巧。可以看到，在设计完应用后应该编写单元测试用例，测试用
例越多和越详细，则对程序的正确性提高越有好处。
-
转载：使用Junit对Android应用进行单元测试（一）
51_51testing 发布于 2010-10-29 09:10:21
转载自http://tech.it168.com/a2010/1027/1118/000001118903_all.shtml
在本文中，你将会学习到如何在Eclipse中创建Android JUnit的单元测试工程以及在不同的条件下创建及运行自动测试用例。
准备工作
本文假设读者已经有一定的Android基础知识，并且已经安装了Eclipse和Android SDK等开发工具。本文将指导读者如何将Android Junit框架应用到Android应用中去。本文还特别重点展示了如何测试Android中的Activity和如何识别程序中的错误。
本文的示例代码可以在http://code.google.com/p/simple-calc-unit-testing/中下载
步骤1 被测试的应用SimpleCalc概况
在本文中，将以一个写好了的应用SimpleCalc简单计算器为例子进行讲解。这个简单计算器有两个功能，允许用户输入两个数并将它们相加或相乘，最后显示结果，如下图所示：
▲步骤2 SimpleCalc的的界面设计
由于应用比较简单,只占一屏,所以我们在/res/layout/main.xml中设计如下代码所示:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical" android:layout_width="fill_parent"
android:layout_height="fill_parent">
<TextView android:layout_width="fill_parent"
android:layout_height="wrap_content" android:text="@string/hello"
android:gravity="center_horizontal" android:textSize="48px"
android:padding="12px" />
<EditText android:layout_height="wrap_content" android:id="@+id/value1"
android:hint="@string/hint1" android:inputType="numberDecimal"
android:layout_width="fill_parent" android:textSize="48px"></EditText>
<EditText android:layout_height="wrap_content" android:id="@+id/value2"
android:hint="@string/hint2" android:inputType="numberDecimal"
android:layout_width="fill_parent" android:textSize="48px"></EditText>
<FrameLayout android:id="@+id/FrameLayout01"
android:layout_width="wrap_content" android:layout_height="wrap_content"
android:padding="12px" android:background="#ff0000">
<LinearLayout android:id="@+id/LinearLayout02"
android:layout_width="wrap_content" android:layout_height="wrap_content"
android:orientation="horizontal" android:background="#000000"
android:padding="4px">
<TextView android:layout_width="wrap_content"
android:layout_height="wrap_content" android:text="@string/resultLabel"
android:textSize="48px" android:id="@+id/resultLabel"></TextView>
<TextView android:layout_width="wrap_content"
android:layout_height="wrap_content" android:id="@+id/result"
android:textSize="48px" android:textStyle="bold"
android:layout_marginLeft="16px"></TextView>
</LinearLayout>
</FrameLayout>
<LinearLayout android:id="@+id/LinearLayout03"
android:layout_height="wrap_content" android:layout_width="fill_parent">
<Button android:layout_height="wrap_content" android:id="@+id/addValues"
android:text="@string/add" android:textSize="32px"
android:layout_width="wrap_content"></Button>
<Button android:layout_height="wrap_content" android:id="@+id/multiplyValues"
android:text="@string/multiply" android:textSize="32px"
android:layout_width="wrap_content"></Button>
</LinearLayout>
</LinearLayout>简单解析一下这个界面设计，我们使用了LinearLayout，以使得控件能在垂直方向竖向排列。界面中包括了显示标题“Unit Testing Sample”的textview,两个输入数字的edittext控件，一个FrameLayout控件中包含了一个水平的LinearLayout，在这个LinearLayout包含了一个显示结果的textview以及其提示文字“Result”,注意的是FrameLayout的背景颜色设置为红色，而LinearLayou设置成了黑色背景。
步骤3 SimpleCale Activity
本程序中只有一个Actity:MainActity.java,代码如下：
package com.mamlambo.article.simplecalc;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;
public class MainActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
final String LOG_TAG = "MainScreen";
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
final EditText value1 = (EditText) findViewById(R.id.value1);
final EditText value2 = (EditText) findViewById(R.id.value2);
final TextView result = (TextView) findViewById(R.id.result);
Button addButton = (Button) findViewById(R.id.addValues);
addButton.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
try {
int val1 = Integer.parseInt(value1.getText().toString());
int val2 = Integer.parseInt(value2.getText().toString());
Integer answer = val1 + val2;
result.setText(answer.toString());
} catch (Exception e) {
Log.e(LOG_TAG, "Failed to add numbers", e);
}
}
});
Button multiplyButton = (Button) findViewById(R.id.multiplyValues);
multiplyButton.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
try {
int val1 = Integer.parseInt(value1.getText().toString());
int val2 = Integer.parseInt(value2.getText().toString());
Integer answer = val1 * val2;
result.setText(answer.toString());
} catch (Exception e) {
Log.e(LOG_TAG, "Failed to multiply numbers", e);
}
}
});
}
}上面的代码十分简单，分别在两个按钮的onclick事件中，对用户输入的数进行了相加和相乘，看上去代码似乎没问题，但接下来，我们将通过Junit去发现其中的bug。
步骤4 创建Android 单元测试工程
可以有两种方法去增加单元测试工程：一种是在创建新的Android工程时，在创建向导时同时创建单元测试工程，另外是针对已有的项目工程添加一个单元测试工程。本文由于已经有了一个项目工程，所以用如下步骤增加单元测试工程：
▲在Eclipse中，选择存在的工程SimpleCalc,鼠标右键后在弹出的菜单中选择Android Tools-àNew Test Project,如下图所示：
步骤5 设置测试工程
接下来需要对单元测试的工程进行设置，我们采用如下的设置方法：
l 测试工程名称：我们采用SimpleCalcTest
l 工程的位置：这个可以随便设置
l 选择被测试的工程：这里我们选择已经存在的SimpleCalc
l 构建的目标版本：这里我们选择Android 2.1
l 测试用例的包名：设置为com.mamlambo.article.simplecalc.test,
l 设置界面如下图所示。
▲步骤6 SimpleCalcTest单元测试项目的结构
我们审视下SimpleCalcTest的项目结构如下图所示，可以看到这跟普通的Android工程没什么两样：
▲步骤7 创建单元测试用例
下面创建第一个单元测试用例，鼠标右键点击simplecalc.test的包，在弹出的菜单中选择NewàJUnit Test Case,如下图所示：
▲步骤8 设置单元测试用例
接下来对单元测试进行如下设置
l 设置选择使用Junit 3
l 源代码目录：这里要设置为SimpleCalcTest工程的代码目录
l Package:这里设置为com.mamlambo.article.simplecalc.test,
l 测试用例名称：设置为MathValidation
l 测试的父类：这里选择“android.test.ActivityInstrumentationTestCase2."，这个是用来测试activity的Android的测试用例
l 将多选框中的setup,constructor两个都勾选上
如下图所示
▲步骤9 查看MatthValidation测试用例
在上图中，点”Finish”按钮后，MathVlidatiton.java测试用例就创建了。在单元测试中包括如下几个部分：construction, setUp(), 针对方法的测试用例, tearDown(), 和destruction。在setup()方法中，主要是实现一些在测试工作前的资源及环境设置等的初始化设置;而针对方法的测试用例中，需要用户自己编写，一般是以“test+方法名”;而tearDown()在每个测试方法之后运行，用来撤消其初始化的测试环境。
代码如下：
package com.mamlambo.article.simplecalc.test;
import android.test.ActivityInstrumentationTestCase2;
public class MathValidation extends
ActivityInstrumentationTestCase2<MainActivity> {
public MathValidation(String name) {
super(name);
}
protected void setUp() throws Exception {
super.setUp();
}
}步骤10 修改MathValidation的构造函数
在测试用例的构造函数中，写入如下代码，以将我们正在使用的测试父类与测试环境设置进行绑定。
public MathValidation() {
super("com.mamlambo.article.simplecalc", MainActivity.class);
}
步骤11 编写setUp方法
现在可以收集数据去验证SimpleCalc的计算方法了。在setUp方法中，首先应该通过getActivity()方法获得当前的Activity,如下所示：
MainActivity mainActivity = getActivity();
接着，需要获得名为R.id.result的textview控件的实例，这个控件实际上保存计算器应用的运算结果的，代码如下所示：
package com.mamlambo.article.simplecalc.test;
import android.test.ActivityInstrumentationTestCase2;
import android.widget.TextView;
import com.mamlambo.article.simplecalc.MainActivity;
import com.mamlambo.article.simplecalc.R;
public class MathValidation extends ActivityInstrumentationTestCase2<MainActivity> {
private TextView result;
public MathValidation() {
super ("com.mamlambo.article.simplecalc", MainActivity.class);
}
@Override
protected void setUp() throws Exception {
super.setUp();
MainActivity mainActivity = getActivity();
result = (TextView) mainActivity.findViewById(R.id.result);
}
} -
Android Virtual Devices 更改创建目录.
liyun100 发布于 2010-04-08 19:01:11
标题搜索
我的存档
数据统计
- 访问量: 11102
- 日志数: 27
- 建立时间: 2008-07-15
- 更新时间: 2015-03-18
