Activity间数据传输

基于消息的传输

• 首先，对于大数据，就是一场杯具，不可能一坨上M的数据，也来来回回的传来传去，慢死了谁来负责；
• 再则，Activity之间，维系的是一种线性关系，当我想把一份数据，从队尾一级级传到队头的话，自己历经磨难不提，会把中间所有的Activity都搭上，他们明明自己可能不需要这份数据，也得拿着搁着，为他人做嫁衣裳，不惆怅都不行；
• 此外，基于消息的传输，会把同一份数据生成若干个副本，有时候，这样很好，没有副作用，大家自己玩自己的不需要看别人脸色，但还有些时候，你就上杆子需要把这些数据都修改一下，同步起来那就太惨烈了；
• 最后，写序列化代码实在是太无聊了，稍微复杂点的代码，就要自己写个序列化接口，整个吃力不讨好的活计。

基于外部存储的传输

基于这样外部存储的数据传输，优缺点显而易见，它解决了困扰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们，能迅速找到心仪的兵器，劈山砍石，攻城拔寨。