android序列化,android序列化区别

Android两种序列化的区别和作用

对于Serializable，类只需要实现Serializable接口，并提供一个序列化版本id(serialVersionUID)即可。而Parcelable则需要实现writeToParcel、describeContents函数以及静态的CREATOR变量，实际上就是将如何打包和解包的工作自己来定义，而序列化的这些操作完全由底层实现。

10多年的昌都网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整昌都建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。成都创新互联公司从事“昌都网站设计”,“昌都网站推广”以来，每个客户项目都认真落实执行。

Android Gson 使用详解

Json 是一种文本形式的数据交换格式，比 xml 更为轻量。Json 的解析和生成的方式很多，在 Android 平台上最常用的类库有 Gson 和 FastJson 两种，这里要介绍的是 Gson

Gson 的 GitHub 主页点击这里： Gson

在进行序列化与反序列操作前，需要先实例化一个 com .google.gson.Gson 对象，获取 Gson 对象的方法有两种

利用 Gson 可以很方便地生成 Json 字符串，通过使用 addProperty 的四个重载方法

addProperty 方法底层调用的是 add(String property, JsonElement value) 方法，即将基本数据类型转化为了 JsonElement 对象，JsonElement 是一个抽象类，而 JsonObject 继承了 JsonElement ，因此我们可以通过 JsonObject 自己来构建一个 JsonElement

Json数组 与 字符串数组

Json数组 与 List

Gson 也提供了 toJson() 和 fromJson() 两个方法用于转化 Model 与 Json，前者实现了序列化，后者实现了反序列化

首先，声明一个 User 类

序列化的方法很简单，调用 gson 对象的 toJson 方法，传入要序列化的对象

反序化的方式也类似

继续使用上一节声明的 User 类，根据 User 类声明的各个属性名，移动端的开发者希望接口返回的数据格式即是如下这样的

如果没有和服务器端沟通好或者是 API 改版了，接口返回的数据格式可能是这样的

如果继续使用上一节介绍的方法，那无疑会解析出错

例如

name 属性值解析不到，所以为 null

此时为了兼顾多种格式的数据，就需要使用 SerializedName 注解

根据 SerializedName 的声明来看，SerializedName 包含两个属性值，一个是字符串，一个是字符串数组，而字符串数组含有默认值

SerializedName 的作用是为了在序列化或反序列化时，指导 Gson 如果将原有的属性名和其它特殊情况下的属性名联系起来

例如，修改 User 类，为 name 声明 SerializedName 注解，注解值为 userName

在序列时，Json 格式就会相应改变

在反序列化时也一样，能够解析到正确的属性值

还有个问题没解决，为了应对多种属性名不一致的情况，难道我们要声明多个 User 类吗？这显然是不现实的，所以还需要为 User 类设置多个备选属性名，这就需要用到 SerializedName 注解的另一个属性值 alternate 了。

以下几种情况都能够被正确的反序列化

有时候并不是所有的字段都需要进行系列化和反序列化，因此需要对某些字段进行排除，有四种方法可以来实现这种需求。

Expose 注解包含两个属性值，且均声明了默认值。Expose 的含义即为“暴露”，即用于对外暴露字段，serialize 用于指定是否进行序列化，deserialize 用于指定是否进行反序列化。如果字段不声明 Expose 注解，则意味着不进行序列化和反序列化操作，相当于两个属性值均为 false 。此外，Expose 注解需要和 GsonBuilder 构建的 Gson 对象一起使用才能生效。

Expose 注解的注解值声明情况有四种

现在来看个例子，修改 User 类

按照如上的注解值，只有声明了 Expose 注解且 serialize 值为 true 的字段才能被序列化，只有声明了 Expose 注解且 deserialize 值为 true 的字段才能被反序列化

Gson 提供了 @Since 和 @Until 两个注解基于版本对字段进行过滤，@Since 和 @Until 都包含一个 Double 属性值，用于设置版本号。Since 的意思是“自……开始”，Until 的意思是“到……为止”，一样要和 GsonBuilder 配合使用。

当版本( GsonBuilder 设置的版本) 大于或等于 Since 属性值或小于 Until 属性值时字段会进行序列化和反序列化操作，而没有声明注解的字段都会加入序列化和反序列操作

现在来看个例子，修改 User 类

访问修饰符由 java.lang.reflect.Modifier 提供 int 类型的定义，而 GsonBuilder 对象的 excludeFieldsWithModifiers 方法接收一个 int 类型可变参数，指定不进行序列化和反序列化操作的访问修饰符字段

看个例子

GsonBuilder 类包含 setExclusionStrategies(ExclusionStrategy... strategies) 方法用于传入不定长参数的策略方法，用于直接排除指定字段名或者指定字段类型

看个例子

字段名为 "intField" 和字段类型为 double 的字段都会被排除掉

setExclusionStrategies 方法在序列化和反序列化时都会生效，如果只是想指定其中一种情况下的排除策略或分别指定排除策略，可以改为使用以下两个方法

对于 Gson 而言，在序列化时如果某个属性值为 null 的话，那么在序列化时该字段不会参与进来，如果想要显示输出该字段的话，可以通过 GsonBuilder 进行配置

默认的序列化后的 Josn 字符串并不太直观，可以选择格式化输出

Gson 也可以对时间值进行格式化

TypeAdapter 是一个泛型抽象类，用于接管某种类型的序列化和反序列化过程，包含两个抽象方法，分别用于自定义序列化和反序列化过程

下面看个简单的例子

定义 TypeAdapter 的子类 UserTypeAdapter 来接管 User 类的序列化和反序列化过程

这里设定当 User 类序列化时 Json 中的Key值都是大写字母开头，反序列化时支持“name”和“Name”两种不同的 Json 风格

可以看到 User 类按照预定义的策略来完成序列化和反序列化了

TypeAdapter 将序列化和反序列操作都接管了过来，其实 Gson 还提供了只接管序列化过程的接口，即 JsonSerializer

看个例子

相对应的，JsonDeserializer 接口提供了反序列化的接口

这里有个比较麻烦的地方，那就是在使用 TypeAdapter 、JsonSerializer 和 JsonDeserializer 时，总需要调用 registerTypeAdapter 方法进行注册，那有没有更简单的注册方法呢？

有的，Gosn 还提供了另一个注解 @JsonAdapter 用于进行简单的声明

类似于这样，声明了 User 类的序列化或反序列化操作由 UserTypeAdapter 完成，注解的优先级高于 registerTypeAdapter 方法

TypeAdapterFactory 是用于创建 TypeAdapter 的工厂类，通过参数 TypeToken 来查找确定对应的 TypeAdapter，如果没有就返回 null 并由 Gson 默认的处理方法来进行序列化和反序列化操作，否则就由用户预定义的 TypeAdapter 来进行处理

这一篇文章好像写得太长了一点？Gson 的知识点介绍到这里也差不多了，以后如果还发现新内容的话我会继续补充，现在就先这样啦

android 序列化传递对象是同一个对象吗

putSerializable,是通过对象的序列化和反序列化来实现Activity之间对象的传递的,所以这种方法得到的就是两个完全不一样的对象(Activity2中的对象obj就相当于new了一个新对象,然后将Activity1中的对象obj的值都赋给了它,所以可以说它们的内容是一样的,但是对象不一样.). 注:通过上述方法传递的对象obj一定要实现Serializable接口才可以哦!一般在Activity之间是不做对象的传递的吧,序列化和反序列化本身就没有一定的弊端吧(个人感觉),呵呵...而且对象都要实现Serializable接口.如果一定要传对象的话可以在做一些静态的类或对象!希望对你有帮助 ^_^!

Android IPC机制

IPC是指两个进程之间进行数据交互的过程，即：跨进程通信。

进程是一个执行单，在移动设备上指一个程序或者一个应用。一个进程可以有多个线程，也可以只有一个线程，即主线程。在Android里边，主线程也叫作UI线程，要是在主线程执行大量耗时任务，就会造成界面无法响应，ANR问题，解决这类问题，把耗时操作放在子线程就好。

在Android中，最有特色的进程间通信就是Binder，Binder轻松的实现了进程间的通信。

给四大组件 Activity、Service、Receiver、ContentProvider 在AndroidMenifeist中指定 android:process 属性，可以指定其运行的进程。

: 开头的线程是当前应用的私有进程，其它应用不可以和它跑在同一个进程中，而不以 : 开头的属于全局进程，其他应用通过ShareUID方式可以和它跑在一个进程中。

Android为了每一个应用（进程）都分配了独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间。

多进程会造成如下几个反面方面的问题：

为了解决这些问题，系统提供了跨进程通信方法，虽然不能直接共享内存，但是可以实现数据共享。Intent来传递数据，共享文件，基于Binder的Messenger，ContentProvider，AIDL和Socket。

当我们需要通过Intent和Binder传输数据，或者我们需要把对象持久化到存储设备上，再或者通过网络传输给其它客户端时，Serializable和Parcelable接口可以完成对象的序列化过程。

Serialzable是java提供的序列化接口，是一个空接口，为对象同序列化和反序列化操作。

想让一个类对象实现序列化，只需要这个类实现Serialzable接口，并声明一个serialVersionUID即可，serialVersionUID可以声明成1L或者IDE根据当前类接口自动生成它的hash值。

没有serialVersionUID不影响序列化，但是可能会影响反序列化。序列化时，系统当前类的serialVersionUID写入序列化文件中，当反序列化时，回去检测文件中的serialVersionUID，看它是否和当前类的serialVersionUID一致，如果不一致，无法完成反序列化。

Seriallizable用起来简单但是开销大，序列化和反序列过程需要大量的I/O操作，而Parcelable是Android序列化方式，更适合Android平台，效率更高。Parcelable主要用于内存序列化上，而Seriallizable更适用于序列化到本地存储设备，或者将对象序列化后通过网络传输到别的客户端。

Activity、Service、Receiver都支持在 Intent中传递Bundle数据，Bundle实现了Pareclable接口,所以它可以方便地在不同进程间传输。

Android基于Linux，使得其并发读写文件可以没有限制的进行，两个进程可以通过读写一个文件来交换数据。共享数据对文件格式没有要求，双反约定就行。使用文件共享很有可能出问题。

SharedPreferences是个特例，虽然也是属于文件的一种，但是由于系统对它的读写有一定的缓存策略，即在内存中会有一份SharedPreferences文件的缓存，因此在多进程模式下，系统对他的读写变得不可靠，高并发的时候，很大可能会丢失数据。

Messenger可以在不同的进程中传递Message对象，在Message中存入我们需要传递的数据，就可以实现数据的跨进程传递。它是一种轻量级的IPC方案，底层实现是AIDL。

Messenger对AIDL做了封装，使得我们可以更便捷的实现跨进程通信，它一次只处理一个请求，在服务端不用考虑线程同步问题，在服务端不存在并发执行的情形。实现一个Messenger有如下几个步骤：

在服务端创建一个Service，同时创建一个Handler，并通过它来创建一个Messenger对象，然后再Service的onBind中返回这个Messenger对象底层Binder即可。

绑定服务端Service，绑定成功后用服务端返回的IBinder对象创建一个Messenger。通过这个对象就可以向服务端发消息了。如果需要服务端回应客户端，就需要和服务端一样，创建一个Handler，并通过它来创建一个Messenger对象，然后把这个Messenger对象通过Message的replyTo参数传给服务端，服务端可以通过这个replyTo参数回应客户端。

首先要创建一个Service用来监听客户端的连接请求，然后创建一个AIDL文件，将暴露给客户端的接口在这个AIDL文件中声明，最后在Service中实现AIDL接口即可。

绑定服务端的Service，将服务端返回的Binder对象转成AIDL接口所属的类型，接着就可可以范文AIDL里边的方法了。

在AIDL文件中，并不是所有的额数据类型都是可以使用的。

以上6种数据就是AIDL所支持的所有类型，其中自定义的Parecelable对象和AIDL对象必须显示的import，不管是否和当前的AIDL文件位于同一个包。

AIDL文件中用到了自定义的Parcelable对象，必须新建一个同名的AIDL文件，在其中声明它为parcelable类型。

AIDL中除了基础数据类型，其它类型参数都需要标上方向：in、out、inout，in是输入型参数，out是输出型参数，inout是输入输出型参数。

上面是远程服务端示例，AIDL方法在服务端的Binder线程池中执行，因此各个客户端同时连接的时候，会存在多个线程同时访问的情形，所以要在AIDL中处理线程同步，这个CopyOnWriteArrayList支持并发的读写。

AIDL所支持的是一个抽象的List，只是一个接口，因此虽然服务端返回的是CopyOnWriteArrayList，当时Binder会按照List规范去范文数据并最终形成一个ArrayList传递给客户端。

ServiceConnection 的回调方法在UI线程中运行，服务端的方法有可能很久才能执行完毕，需要考虑ANR的问题。

服务的方法本省就运行再Binder线程池中，本身可以执行大量耗时操作，不要去服务端方法中开县城去进行异步任务。

客户端

服务端

RemoteCallbackList是系统提供专门用于删除跨进程listener的，它的内部有一个Map结构，用来保存所有的AIDL回调，这个Map的key就是Binder类型，value是CallBack类型。

客户端解注册的时候，我们只需要遍历服务端所有的listener，找出那个和接注册listener具有相同的Binder对象的服务端listener并把它删除即可。

RemoteCallbackList的beginBroadcast和finishBroadcast必须配对使用。

ContentProvider是Android专门提供不同应用间进行数据共享的方式。底层实现一样是Binder。

系统预置了许多ContentProvider，比如通讯录，日程信息表，只需要通过ContentResolver的query、update、insert、delete方法即可。

怎么序列化android.graphics.Path

继承 android.graphics.Path 类，重写 moveTo, lineTo 等方法，记录下 path 绘制的每一点的左边数据；反序列化的时候调用 “drawThisPath” 重绘 path。

相关代码：

public class CustomPath extends Path implements Serializable {

private static final long serialVersionUID = -5974912367682897467L;

private ArrayListPathAction actions = new ArrayListCustomPath.PathAction();

private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException{

in.defaultReadObject();

drawThisPath();

}

@Override

public void moveTo(float x, float y) {

actions.add(new ActionMove(x, y));

super.moveTo(x, y);

}