深入理解Android组件间通信机制对面向对象特性的影响详解

组件的特点
对于android的四大组件activity, service, contentprovider和service，不能有setter和getter，也不能给组件添加接口。原因是组件都是给系统框架调用的，开发者只能实现其规定的回调接口，组件的创建与销毁都是由系统框架控制的，开发者不能强行干预，更没有办法获取组件的对象。比如activity，service，broadcastreceiver，你没有办法去创建一个activity，service或broadcastreceiver，然后像使用其他类那样的调用其上的接口与其通信，用setters和getters改变属性等等。这也决定了，组件之间通信只能用系统支持的intent。而intent只能传递基本数据类型和uri等一些常见的数据类型。intent只支持传递内置类型和一些限制类型，这就导致了组件之间的数据传递必须都是基本类型，所以枚举类型无法使用。
多态无法实现
比如你有一个service用于在后台执行ui中发来的请求，这些请求有些是做数据请求，有些是做数据分析，等等。这里可以用多态，定义一个统一的transaction类，然后再为每种特定的transaction类型，transaction中统一接口process()用于实际的处理，理想的情况是，service接收一个transaction对象，然后调用其process()，没有必要知道具体的类型，ui创建具体的一个类型对象然后交由service来处理。但是这在android当中是无法实现的，因为intent通信机制所限，因为它不能直接传递transaction对象。所以，service必须要知道具体的类型。原生应用mms中就有如此的现象，在transaction包中transactionservice是处理服务，ui发送到service的只是区别不同transaction的id（一个整数），service查看不同的id创建不同的transaction对象，然后调用process()对其处理。
建议：自己实现一个类似service的服务类，在其内用handler，thread和looper让其长时间运行。这样就没有组件间通信的限制，你可以像正常使用java对象那样来使用这个服务类，向其传递自定义的处理请求:

public class transactionserver extends handlerthread {
public transactionserver() {
start();
}
public void onlooperprepared() {
mhandler = new handler(getlooper(), new handler.callback() {
 @override
  public void handlemessage(message msg) {
transaction request = (transaction) msg.obj;
 request.process();
   }
 }
}

   public void execute(transaction request) {
   if (mhandler == null) {
return;
}
   message msg = message.obtain();
   msg.obj = request;
   mhandler.sendmessage(msg);
   }
}

在activity中就可以创建此server的对象，然后使用它：

transactionserver server = new transactionserver();
transaction updaterequest = new updatetransaction();
server.execute(updaterequest);

另外，用aidl与service通信，虽可以获取service的对象引用，可以直接调用service的方法，但这个也有限制，对于aidl的接口，所有的参数和返回类型都必须是基本数据
据类型，不能有对象。原因也好理解，因为aidl也是要通过ipc的，即便service与activity在同一个进程内，所以本质上它与intent通信机制无区别。
封装性被破坏
组件间的通信机制决定了android的封装性，先来看一些实例：

intent i = new intent(intent.action_view);
i.setdataandtype(uri, "text/html");
startactivity(i);

这在android当中是再常见不过的了。
intent和intentfilter的使用让封装性受到大大的破坏，因为你必须把字串，参数等直接写入到intent或intentfilter当中。例如：

intent i = new intent("android.contacts.action.multiplecontactslists");
i.setextra("request_type", 3);
<intent-filter>
 <action android:name="android.contacts.action.multiplecontactslists" />
</intent-filter>

当然，可以再好一点，就是：
intent i = new intent(contacts.action_get_contacts);
但是在androidmanifest中的intentfilter还是要写字串常量（literal strings），这样就有一个问题，就是即使你写错了，编译器不会提醒你，直到你运行的时候才会发现程序不正常工作，你调试啊，调试，最终发现是字串写错了。或者，activity的name写错了，编译器同样不会提醒你，但你运行时却因找不到类而报出runtimeexception。
建议：尽可能在所有作用域内定义常量，以让组件间接口保持一致性，特别是对于字串常量，一定要在二个组件都可见的作用域内定义常量，否则将会有维护的麻烦。
例子：intent.putextra("request_type", 3); --> intent.putextra(targetactivity.request_type, targetactivity.no_background);否则，特别是当目标组件不在同一个包内，或距离很远时，如果另一方改了，编译时不会有错，但程序不会正常工作，从而引发难以发觉的bug。
无法在组件间传递自定义的数据结构
如前面所述，因为无法获取组件的对象的引用，所以你无法向其设置数据，当然，可以用静态方法，但是不优雅且难以维护（对于service倒是可以通过aidl方式获取service对象的引用，然后调用其方法来添加数据）。又因为intent只能携带基本的数据类型，所以对于自定义的数据结构想要在组件间传递就特别的麻烦。当然你可以以让数据结构实现parcleable接口，但是用起来也相当的麻烦。
建议：
1. 尽可能的避免使用自定义数据结构，特别是除了setters和getters以外不具有其他行为的数据结构
对于结构化的数据，为其定义contentprovider，把数据写入sqlite数据库，这样数据库表中的每行数据都相当于是一个数据对象，每一列都是其属性。因为android的组件与sqlite数据库的粘性很大，每个组件都可以很方便的从数据库中获取数据，再通过cursor等工具来操作数据。最最重要的是这很方便在组件间传递数据，因数contentprovider的访问都是通过uri来实现的，而uri又可以与intent无缝接合，uri可以方便的放入和从intent中取出，每个组件又都可以直接访问contentprovider用uri读取数据，从而就可以实现组件间的无缝数据传递。
2. 尽可能的不要在组件之间传递数据
不要用太多的activity，service也能免则免，activity＋线程可能解决大部分问题，当然了，线程也不是那么好用的，特别是在android里面。
3. 避免在组件之间传递自定义数据结构
如前所述，组件之间最好直接传递基本数据和intent支持的数据类型。对于自定义的数据结构，要么不定义数据结构，要么不要在组件间传递，否则会很麻烦，虽然可能以实现parcelable接口，但是效率和操作的方便性上都会大打折扣。
关于枚举和整数集
先前一篇<android开发笔记之:用enum(枚举类型)取代整数集的应用详解>曾说要尽量使用枚举(enum)代替整数集(ints)，而且很多编程书籍(effective java)也建议用枚举代替整数集，这其中的好处就是降低出错率，把运行时的检查可以放到编译时，因为整数的范围较大，你可传递任意的整数，直到运行时才会检测或产生问题，但是枚举会在编译时检查类型，如果不是合法的枚举，编译器会报怨。
但是我们可以看到，在android中的情况却很差，android中大量的使用了整数集，系统定义了大量的整数集，很多参数也都是整数，虽然正确的方法都是向这些api传递其所定义的整数常量，但是你如果传个integer.max_value或integer.min_value，起码在编译时不会出问题。
既然这不是一个好的编程规范，为什么android中还要大量的使用整数集呢？原因就在于组件间通信，组件之间要传递参数，但是intent又只能放入基本数据类型，也就是说如果使用枚举，那么将无法用intent传递给其他的组件，因为枚举转为整数很容易，但反过来整数转成枚举就不是那么容易了。
所以，如果你的常量不需要在组件间来回的传递，那么最好定义成为枚举，否则，只能用整数集了。
关于组件一般的设计原则
1. 不要用组件实现某些接口，比如点击接口，等等
因为组件是一个开销非常巨大的对象，组件的继承层次也非常的深，用组件实现接口，传递给调用者，就相当于用一个火车去运送一个小老鼠一样，给了别人一个相当大的对象，但是仅有一个或二个方法是别人需要的。特别是对于activity，不要去实现一些公共的接口比如view.onclicklistener，除了前面的原因以外，另外一个就是你的onclick必须用条件来区分点击的是哪个ui元素，这很难维护，还有一个原因就是activity的对象不是很稳定，因为系统的某些事件如转屏，语言切换等等会把activity杀死并重新创建一个实例，所以有可能会引发问题，虽然看起来activity还在，但是并不同一个实例，如果某些东西与具体实例相关，就会引发问题，要么程序不正常工作，要么有runtimeexception。还有可能引发内存泄漏，因为送给使用者的接口对象都是activity的实例引用，一旦某个引用超过activity的生命周期，就会造成内存泄漏。
推荐的做法是用匿名内部类来实现接口，如果其他地方需要对此接口对象的操作，可以声明一个成员变量或者一个内部类，这样也方便activity来控制，以保证所有东西都生存在activity的生存周期之内。
2. 少用service
组件service并没有传说中的好用，而且它还会让你的程序退出页面后仍然在后台跑，占系统资源不说，还会被骂（看看这些文章吧），因为service的生命周期是由系统来控制，我们无法干预，即使你确切的知道某些时候你已经完全不用它了。用activity和线程就可以完成绝大多数操作，而且你还能做到让所有线程都在activity的控制之内，让它们都活在activity的生命周期之内。另外的原因就是，因为线程都属于自建的类，或者普通的java类，可以应用面向对象，因为没有了组件通信的限制。
3. 利用contentprovider来做复杂数据结构的通信工具
contentprovider和sqlitedatabase存储的就是结构化数据，相当于一个数据结构，它的引用就是它的uri，任何组件通过uri就可获得此数据结构。它有如下优点：
1. 可以方便的在组件间传递
因为数据实际是在数据库中，你在组件间仅传递其地址uri即可，任何组件或任何持有context的类都可以方便的获取它，无论从实用性还是从效率上讲，这比用intent传，或者实际传送数据结构对象来得快。
2. contentprovider组件有自己的进程和线程，不会有线程同步问题
外部都是通过contentresolver来访问contentprovider，因此contentprovider对外界来讲是一样的，访问方式相同，自然就不会有线程同步之类的问题。
3. contentprovider可以进行封装，从而使数据操作更加方便
因为contentprovier提供统一的接口，你可以利用数据自身的特点，在实现这些接口时进行一些封装，比如添加默认值等等。
4. contentprovider可以用作队列或堆栈
因为每一行都是一个结构化数据，每一行的数据插入的顺序又是按先后顺序，所以这完全可以当做一个队列，或一个堆栈。

可以参考原生mms中信息的发送流程，信息从用户点击发送就写入数据库，然后一路把其uri在各个组件间中传递，每个组件更新信息的状态，直到最后发送。还有downloadprovider，android中默认的下载，应用程序通过downloadmanager提交一个request，但实际做下载的是downloadservice，而downloadserver是在packages/provider/downloadprovider中，是一个完全独立的进程。downloadmanager仅是把一个request写入downloadprovider中，这个request包含下载一个东西的相关信息如url等。downloadservice仅是监听downloadprovider的变化，一旦有新数据插入，就创建线程读出此request，然后开始下载。下载的同时，也是把数据直接更新到downloadprovider中，这样ui就可以显示进度等信息。这一过程涉及二个进程，至少三个组件：提交request的用户进程和downloadprovider进程，downloadmanager（是一个公共api），downloadservice（单独进程，私有的package）和downloadlist(在downloadprovider包内部，用于显示下载进度的ui），这些组件之间没有直接的通信，它们都是围绕着contentprovider。同时这里的contentprovider也被用做下载请求的队列，downloadmanager可以不断的向其中加入请求，downloadservice会监听其变化从其中取出数据然后做下载。
别说android开发很简单
虽然android上手很容易，但是要想写出优质的代码并不简单，分裂现象，碎片化，系统架构等等都给很多事情加大了难度。可以看一下原生应用中的主要的activity代码量都在5000行以上，它们的界面比较复杂，是主要核心业务逻辑所在，这些activity控制的东西比较多，所以很臃肿。当然这里的主要原因，还是未能进行良好的设计和重构。比如ics中的browser就做的好一些，它的browseractivity只有几百行的代码，但以前的代码却是6000多行，现在它把各种业务逻辑分别拆开，activity只负责接收frameworks层的回调，所有的业务逻辑控制交由controller来完成，而controller只负责tab的管理，菜单等的管理。具体的菜单和布局分辨率相关的东西又交由phoneui来处理。下载的处理由downloadhandler来处理，等等。原来这些所有的事情都放在了browseractivity中的，可以想像原来它里面的逻辑会是多么的乱，维护起来会是多么的痛苦。当然，现在的设计也还有待提高，因为类之间的耦合依然很大，比如controller中持有phoneui对象，但是phoneui对象又持有controller，等等现象。很多时候会出现相互调用的情况，这是相当难以维护的，也破坏了相当多的设计原则。

总之，凡是程序，如果要想写的好，都需要投稿额外的精力，平台虽然有优劣但更重要的是对代码投入的精力。但现在可悲的是，android平台赢利不理想，加之碎片化和浮躁的心理，使得很多应用都在一二个月内做出来，所以整个android生态系统中的应用质量都不高，更为严重的是反编译和克隆，很多人都是把应用抓下来，反编译然后改了改就是一个新的应用，越是如此不关注质量，用户就越不买帐，开发者无法赢利，就越难投入精力做好应用，如此进入了一个恶性循环。