【Android开发网上的一些重要知识点[经验分享]。。】

熊猫儿

为什么选择Android平台来研发手机
引言

这是笔者作为一个一线手机开发者对《为什么选择Android平台来研发手机》问题的思考。
一．开源

开源的手机开发平台，基于Linux操作系统。
二．开放

Android是一个开放式的移动电话开发平台，Android是一个对第三方软件完全开放的平台，开发者在为其开发程序时拥有更大的自由度；
三．免费

服务免费
四．Java语言开发

Java语言开发的优势，众所周知。
五．标准化

Android是一个标准化的移动电话开发平台；
六．开发便捷与高效

1.强大的开发环境Eclipse，利于方便调试与开发；
2.自带的模拟器，可在Windows平台开发调试；
3.Android平台是操作系统、中间件、用户界面和应用软件组成，架构清晰，层次分明；
七．产业链完整


Google与30多家技术和无线应用的领军企业合作开发，包括运营商、设备制造商、开发商和其他第三方公司，如中国移动、摩托罗拉、高通、宏达和T-Mobile。
手机平台的生态系统健壮和完整。
八．互联网与无线通信的融合的趋势

无线通信与互联网融合的趋势，不容置疑。
而Google正是世界级的互联网领军企业，引领互联网世界发生深刻变革。
九．Google强大搜索功能可无缝移植于手机平台


十．Google的品牌号召力和市场影响力

Google的粉丝众多，一呼百应。
十一．Google世界级的技术实力

科学技术是第一生产力。
十二．Google资金雄厚

Android开发平台的研发和推出，不会因为资金不足而断裂。

熊猫儿

Ubuntu下不能识别android设备的解决方案
分类： 开发工具 2012-12-31 18:25 191人阅读 评论(0) 收藏 举报
PS： 最近调试程序，由于某种原因，换了一台android设备，

可当我试图编译安装apk时，系统却不识别这台设备。

在网上苦游半天后终于总结出了一个相对简洁又高效的方法，现在在此分享与大家！



〇、输入命令：lsusb ；列出以USB方式连接到电脑的设备信息。

Bus 008 Device 003: ID 12d1:103a Huawei Technologies Co., Ltd.
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
... ...

一、切换到 root权限

sudo -s

二、打开文件

vim /etc/udev/rules.d/51-android.rules

三、在文件中添加一行信息(注意红色字体：与你的设备ID对应)：

SUBSYSTEM==”usb”, SYSFS{“Google Inc. ”}==”12d1″, MODE=”103a″

四、保存并退出，并退到普通用户模式，运行以下命令：

sudo chmod a+rx /etc/udev/rules.d/51-android.rules
sudo /etc/init.d/udev restart

五、在你的SDK的platform-tools 目录下运行：

sudo ./adb kill-server
sudo ./adb devices

OK,大功告成！！！现在就可以连上你的android设备了。怎么样，简单吧？

熊猫儿

android intent 用bundle传递数据
分类： android开发之路(技术篇) 2012-12-14 10:21 51人阅读 评论(0) 收藏 举报
存放数据：

                String s = "value";
                Intent intent = new Intent();
                Bundle bundle = new Bundle();
                bundle.putString("key", s);
                intent.putExtras(bundle);


获取数据：

         Intent intent = getIntent();
        Bundle bundle = new Bundle();
        bundle = intent.getExtras();
        String s = bundle.getString("key");

熊猫儿

android基础概念总结
分类： android开发之路(技术篇) 2012-12-11 20:24 66人阅读 评论(0) 收藏 举报
一、 android四大基本布局：

LinearLayout, FrameLayout, RelativeLayout 和 TableLayout

二、 android四大基本部件：

Activty, Service, Broadcast Receiver 和 Content Provider.

三、 Activity 生命周期七阶段：

onCreate() --> onStart() -->  --> onResume() -->onPause() --> onRestart() -->onStop() --> onDestroy().

四、 Activity 生命周期执行流程(下边情形顺序执行)

情形一：初始启动

过程：onCreate() --> onStart() --> onResume();

情形二：回到Home

过程：onPause() --> onStop();

情形三：重新回到Activity界面

过程：onRestart() --> onStart() --> onResume();

情形四：灭屏

过程：onPause() --> onStop();
情形五：亮屏

过程：onRestart() --> onStart() --> onResume();

情形六：退出

过程：onPause() --> onStop() --> onDestroy();
注：在onPause()后却没有onDestroy()的情况下，会执行onSaveInstanceState()方法，以保存实例的状态信息。

未完，待续。。。

熊猫儿

熊猫儿

android 四大组件 原理详解(通俗易懂)
分类： android开发之路(技术篇) 2012-12-11 15:39 78人阅读 评论(0) 收藏 举报
PS：本文来自百度知道某位大神，吾观止受益匪浅，特此转至本博客，分享之。。。


Android有四大组件：Activity、Service、Broadcast Receiver、Content Provider。

Activity

做一个完整的Android程序，不想用到Activity，真的是比较困难的一件事情，除非是想做绿叶想疯了。因为Activity是Android程序与用户交互的窗口，在我看来，从这个层面的视角来看，Android的Activity特像网站的页面。

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 Provider

Content 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包含的逻辑更复杂更完整，可以抉择大部分时候使用某接口的场景，从而确定最贴切的接口是同步还是异步，简化了上层调用的逻辑。

熊猫儿

android intent 之见解
分类： android开发之路(技术篇) 2012-12-11 11:40 57人阅读 评论(0) 收藏 举报
一、 Intent 基本概念：



                         首先， Intent是用于负责应用之间通讯、消息传递的一种机制。

                         其次，Intent负责对应用中一个操作的动作、所涉及到的数据、附加数据进行描述。android就负责根据Intent的描述通过解析找到与之对应的组件，并完成相应的调用。

                         最后， Intent也可以应用于程序内部的Activity/svervice之间的交互，起到了一个粘合剂的作用，专门提供组件直接相互调用的信息，实现调用者于被调用者之间的解耦。

一句话总结基本概念：一个Intent就是对一个所要执行动作的一种抽象描述。
二、 Intent 六大基本属性：

1. Action
也就是Intent 要执行的动作，eg：ACTION_EDIT

也可以自定义动作。
2.Type

            显示指定Intent的数据类型
3. Data
             执行动作所要操作的数据
4. Category

             Intent要执行的附加信息。
如 LAUNCHER_CATEGORY 表示Intent 的接受者应该在Launcher中作为顶级应用出现
5. Component

指定Intent的的目标组件的类名称，通常根据其他属性的设置来寻找。

如果有指定，则不再查找。

6. Extras

附加信息。是其它所有附加信息的集合。使用extras可以为组件提供扩展信息。

比如，如果要执行“发送电子邮件”这个动作，可以将电子邮件的标题、正文等保存在extras里，传给电子邮件发送组件。

熊猫儿

三、 两种基本用法：

1.显示Intent (Explicit Intent)
在定义Intent时，就已经指定了接收者。
2.隐式Intent (Implicit Intent)
Intent的发送者在构造Intent对象时，并不知道也不关心接收者是谁，有利于降低发送者和接收者之间的耦合。

这时需要通过android解析得到接收者。解析机制如下：


Intent解析机制主要是通过查找已注册在AndroidManifest.xml 中的所有IntentFilter及其中定义的Intent，最终找到匹配的Intent。

在这个解析过程中，Android是通过Intent的action、type、category这三个属性来进行判断的，判断方法如下：

如果Intent指明了action，则目标组件的IntentFilter的action列表中就必须包含有这个action，否则不能匹配；
如果Intent没有提供type，系统将从data中得到数据类型。和action一样，目标组件的数据类型列表中必须包含Intent的数据类型，否则不能匹配。
如果Intent中的数据不是content: 类型的URI，而且Intent也没有明确指定它的type，将根据Intent中数据的scheme （比如 http: 或者mailto:） 进行匹配。
如果Intent指定了一个或多个category，这些类别必须全部出现在组建的类别列表中。(比如Intent中包含了两个类别：LAUNCHER_CATEGORY 和 ALTERNATIVE_CATEGORY，解析得到的目标组件必须至少包含这两个类别)