Android Activity间数据传输

在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随时可能死掉，你还是要费劲心机的处理数据的持久化，得不偿失。