Android activity之间传值

当对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们，能迅速找到心仪的兵器，劈山砍石，攻城拔寨。