《Android开发艺术探索》笔记

本笔记整理自: https://www.gitbook.com/book/tom510230/android_ka_fa_yi_shu_tan_suo/details
參考文章：
http://szysky.com/tags/#笔记 
http://blog.csdn.net/player_android/article/category/6577498

MD文件下载：https://pan.baidu.com/s/1c2OiQNe
联系我：xiadeye@icloud.com

本书是一本Android进阶类书籍，採用理论、源代码和实践相结合的方式来阐述高水准的Android应用开发要点。本书从三个方面来组织内容。

  1. 介绍Android开发人员不easy掌握的一些知识点
  2. 结合Android源码和应用层开发过程。融会贯通。介绍一些比較深入的知识点
  3. 介绍一些核心技术和Android的性能优化思想


1 Activity的生命周期和启动模式

1.1 Activity的生命周期全面分析

用户正常使用情况下的生命周期 & 因为Activity被系统回收或者设备配置改变导致Activity被销毁重建情况下的生命周期。

1.1.1 典型情况下的生命周期分析

Activity的生命周期和启动模式

  1. Activity第一次启动：onCreate->onStart->onResume。
  2. Activity切换到后台（ 用户打开新的Activity或者切换到桌面） 。onPause->onStop(假设新Activity採用了透明主题，则当前Activity不会回调onstop)。
  3. Activity从后台到前台。又一次可见，onRestart->onStart->onResume。
  4. 用户退出Activity。onPause->onStop->onDestroy。
  5. onStart開始到onStop之前。Activity可见。onResume到onPause之前。Activity能够接受用户交互。
  6. 在新Activity启动之前，栈顶的Activity须要先onPause后，新Activity才干启动。所以不能在onPause运行耗时操作。

  7. onstop中也不能够太耗时，资源回收和释放能够放在onDestroy中。

1.1.2 异常情况下的生命周期分析

1 系统配置变化导致Activity销毁重建

比如Activity处于竖屏状态，假设突然旋转屏幕，因为系统配置发生了改变，Activity就会被销
毁并又一次创建。
在异常情况下系统会在onStop之前调用onSaveInstanceState来保存状态。

Activity又一次创建后，会在onStart之后调用onRestoreInstanceState来恢复之前保存的数据。

保存数据的流程： Activity被意外终止。调用onSaveIntanceState保存数据-> Activity托付Window。Window托付它上面的顶级容器一个ViewGroup（ 可能是DecorView） 。然后顶层容器在通知全部子元素来保存数据。

这是一种托付思想，Android中类似的还有：View绘制过程、事件分发等。

系统仅仅在Activity异常终止的时候才会调用 onSaveInstanceState 和onRestoreInstanceState 方法。

其它情况不会触发。

2 资源内存不足导致低优先级的Activity被回收
三种Activity优先级:前台- 可见非前台 -后台，从高到低。
假设一个进程没有四大组件，那么将非常快被系统杀死。

因此，后台工作最好放入service中。

android:configChanges=”orientation” 在manifest中指定 configChanges 在系统配置变化后不又一次创建Activity，也不会运行 onSaveInstanceState 和onRestoreInstanceState 方法。而是调用 onConfigurationChnaged 方法。
附：系统配置变化项目

configChanges 一般经常使用三个选项：

  1. locale 系统语言变化
  2. keyborardHidden 键盘的可訪问性发生了变化。比方用户调出了键盘
  3. orientation 屏幕方向变化

1.2 Activity的启动模式

1.2.1 Activity的LaunchMode

Android使用栈来管理Activity。

  1. standard
    每次启动都会又一次创建一个实例，无论这个Activity在栈中是否已经存在。谁启动了这个Activity。那么Activity就执行在启动它的那个Activity所在的栈中。
    用Application去启动Activity时会报错，原因是非Activity的Context没有任务栈。解决的方法是为待启动Activity制定FLAG_ACTIVITY_NEW_TASH标志位，这样就会为它创建一个新的任务栈。
  2. singleTop
    假设新Activity位于任务栈的栈顶，那么此Activity不会被又一次创建。同一时候回调 onNewIntent 方法。onCreate和onStart方法不会被运行。
  3. singleTask
    这是一种单实例模式。假设不存在activity所须要的任务栈。则创建一个新任务栈和新Activity实例；假设存在所须要的任务栈，不存在实例。则新创建一个Activity实例；假设存在所须要的任务栈和实例，则不创建，调用onNewIntent方法。

    同一时候使该Activity实例之上的全部Activity出栈。
    參考：taskAffinity标识Activity所须要的任务栈

  4. singleIntance
    单实例模式。具有singleTask模式的全部特性，同一时候具有此模式的Activity仅仅能独自位于一个任务栈中。

如果两个任务栈。前台任务栈为12，后台任务栈为XY。

Y的启动模式是singleTask。如今请求Y，整个后台任务栈会被切换到前台。

如图所看到的：

设置启动模式

  1. manifest中 设置下的 android:launchMode 属性。
  2. 启动Activity的 intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); 。
  3. 两种同一时候存在时，以另外一种为准。第一种方式无法直接为Activity加入FLAG_ACTIVITY_CLEAR_TOP标识，另外一种方式无法指定singleInstance模式。
  4. 能够通过命令行 adb shell dumpsys activity 命令查看栈中的Activity信息。

1.2.2 Activity的Flags

这些FLAG能够设定启动模式、能够影响Activity的执行状态。

  • FLAG_ACTIVITY_NEW_TASK
    为Activity指定“singleTask”启动模式。
  • FLAG_ACTIVITY_SINGLE_TOP
    为Activity指定“singleTop”启动模式。

  • FLAG_ACTIVITY_CLEAR_TOP
    具有此标记位的Activity启动时，同一个任务栈中位于它上面的Activity都要出栈，一般和FLAG_ACTIVITY_NEW_TASK配合使用。

  • FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
    假设设置，新的Activity不会在近期启动的Activity的列表(就是安卓手机里显示近期打开的Activity那个系统级的UI)中保存。等同于在xml中指定android:exludeFromRecents=”true”属性。

1.3 IntentFilter的匹配规则

Activity调用方式

  1. 显示调用 明白指定被启动对象的组件信息。包含包名和类名
  2. 隐式调用 不须要明白指定组件信息。须要Intent可以匹配目标组件中的IntentFilter中所设置的过滤信息。

匹配规则

  • IntentFilter中的过滤信息有action、category、data。

  • 仅仅有一个Intent同一时候匹配action类别、category类别、data类别才干成功启动目标Activity。
  • 一个Activity能够有多个intent-filter。一个Intent仅仅要能匹配不论什么一组intent-filter就可以成功启动相应的Activity。

action
action是一个字符串,匹配是指与action的字符串全然一样,区分大写和小写。
一个intent-filter可以有多个aciton。仅仅要Intent中的action可以和不论什么一个action同样就可以成功匹配。


Intent中假设没有指定action。那么匹配失败。

category
category是一个字符串。
Intent能够没有category，可是假设你一旦有category。无论有几个，每一个都必须与intent-filter中的当中一个category同样。
系统在 startActivity 和 startActivityForResult 的时候，会默觉得Intent加上 android.intent.category.DEFAULT 这个category，所以为了我们的activity可以接收隐式调用。就必须在intent-filter中加上 android.intent.category.DEFAULT 这个category。

data
data的匹配规则与action一样，假设intent-filter中定义了data，那么Intent中必需要定义可匹配的data。
intent-filter中data的语法：

    <data android:scheme="string"
    android:host="string"
    android:port="string"
    android:path="string"
    android:pathPattern="string"
    android:pathPrefix="string"
    android:mimeType="string"/>

Intent中的data有两部分组成：mimeType和URI。mimeType是指媒体类型。比方
image/jpeg、audio/mpeg4-generic和video/等，能够表示图片、文本、视频等不同的媒
体格式。

URI的结构：

    <scheme>://<host>:<port>/[<path>|<pathPrefix>|<pathPattern>]

实际样例

    content://com.example.project:200/folder/subfolder/etc
    http://www.baidu.com:80/search/info

scheme：URI的模式，比方http、file、content等，默认值是 file 。


host：URI的主机名
port：URI的端口号
path、pathPattern和pathPrefix：这三个參数描写叙述路径信息。


path、pathPattern能够表示完整的路径信息，当中pathPattern能够包括通配符 * ，表示0个或者多个随意字符。
pathPrefix仅仅表示路径的前缀信息。

过滤规则的uri为空时。有默认值content和file，因此intent设置uri的scheme部分必须为content或file。
Intent指定data时，必须调用 setDataAndType 方法。 setData 和 setType 会清除还有一方的值。


对于service和BroadcastReceiver也是相同的匹配规则，只是对于service最好使用显式调用。

隐式调用需注意

  • 当通过隐式调用启动Activity时，没找到相应的Activity系统就会抛出 android.content.ActivityNotFoundException 异常，所以须要推断是否有Activity可以匹配我们的隐式Intent。

  • 採用 PackageManager 的 resloveActivity 方法或Intent 的 resloveActivity 方法

      public abstract List<ResolveInfo> queryIntentActivityies(Intent intent,int flags);
  public abstract ResolveInfo resloveActivity(Intent intent,int flags);

    以上的第二个參数使用 MATCH_DEFAULT_ONLY 。这个标志位的含义是只匹配那些在
    intent-filter中声明了 android.intent.category.DEFAULT 这个category的Activity。由于假设把不含这个category的Activity匹配出来了，由于不含DEFAULT这个category的Activity是无法接受隐式Intent的从而导致startActivity失败。

  • 以下的action和category用来表明这是一个入口Activity，而且会出如今系统的应用列表中，二者缺一不可。

      <action android:name="android.intent.action.MAIN" />
  <category android:name="android.intent.category.LAUNCHER" />

2 IPC机制

2.1 Android IPC 简单介绍

  • IPC即Inter-Process Communication。含义为进程间通信或者跨进程通信，是指两个进程之间进行数据交换的过程。

  • 线程是CPU调度的最小单元，是一种有限的系统资源。进程一般指一个运行单元，在PC和移动设备上是指一个程序或者应用。进程与线程是包括与被包括的关系。一个进程能够包括多个线程。最简单的情况下一个进程仅仅有一个线程，即主线程（ 比如Android的UI线程） 。
  • 不论什么操作系统都须要有对应的IPC机制。如Windows上的剪贴板、管道和邮槽。Linux上命名管道、共享内容、信号量等。Android中最有特色的进程间通信方式就是binder，另外还支持socket。

    contentProvider是Android底层实现的进程间通信。

  • 在Android中，IPC的使用场景大概有下面：
    • 有些模块因为特殊原因须要执行在单独的进程中。
    • 通过多进程来获取多份内存空间。

    • 当前应用须要向其它应用获取数据。

2.2 Android中的多进程模式

2.2.1 开启多进程模式

在Android中使用多线程仅仅有一种方法：给四大组件在Manifest中指定 android:process 属性。这个属性的值就是进程名。

这意味着不能在执行时指定一个线程所在的进程。

tips：使用 adb shell ps 或 adb shell ps|grep 包名 查看当前所存在的进程信息。

两种进程命名方式的差别

  1. “：remote”
    “：”的含义是指在当前的进程名前面附加上当前的包名，完整的进程名为“com.example.c2.remote”。这样的进程属于当前应用的私有进程，其它应用的组件不能够和它跑在同一个进程中。
  2. “com.example.c2.remote”
    这是一种完整的命名方式。这样的进程属于全局进程，其它应用能够通过ShareUID方式和它跑在同一个进程中。

2.2.2 多线程模式的执行机制

Android为每一个进程都分配了一个独立的虚拟机，不同虚拟机在内存分配上有不同的地址空间。导致不同的虚拟机訪问同一个类的对象会产生多份副本。比如不同进程的Activity对静态变量的改动。对其它进程不会造成不论什么影响。全部执行在不同进程的四大组件，仅仅要它们之间须要通过内存在共享数据，都会共享失败。四大组件之间不可能不通过中间层来共享数据。

多进程会带来下面问题：

  1. 静态成员和单例模式全然失效。

  2. 线程同步锁机制全然失效。
    这两点都是由于不同进程不在同一个内存空间下，锁的对象也不是同一个对象。
  3. SharedPreferences的可靠性下降。


    SharedPreferences底层是 通过读/写XML文件实现的，并发读/写会导致一定几率的数据丢失。

  4. Application会多次创建。


    因为系统创建新的进程的同一时候分配独立虚拟机。事实上这就是启动一个应用的过程。在多进程模式中，不同进程的组件拥有独立的虚拟机、Application以及内存空间。

多进程相当于两个不同的应用採用了SharedUID的模式

实现跨进程的方式有非常多：

  1. Intent传递数据。

  2. 共享文件和SharedPreferences。
  3. 基于Binder的Messenger和AIDL。
  4. Socket等

2.3 IPC基础概念介绍

主要介绍 Serializable 、 Parcelable 、 Binder 。Serializable和Parcelable接口能够完毕对象的序列化过程，我们通过Intent和Binder数据传输时就须要Parcelabel和Serializable。

还有的时候我们须要对象持久化到存储设备上或者通过网络传输到其它client。也须要Serializable完毕对象持久化。

2.3.1 Serializable接口

Serializable 是Java提供的一个序列化接口（ 空接口） ，为对象提供标准的序列化和反序列化操作。

仅仅须要一个类去实现 Serializable 接口并声明一个 serialVersionUID 就可以实现序列化。

private static final long serialVersionUID = 8711368828010083044L

serialVersionUID也能够不声明。假设不手动指定 serialVersionUID 的值，反序列化时假设当前类有所改变（ 比方增删了某些成员变量） ，那么系统就会又一次计算当前类的hash值并更新 serialVersionUID 。

这个时候当前类的 serialVersionUID 就和序列化数据中的serialVersionUID 不一致，导致反序列化失败。程序就出现crash。

静态成员变量属于类不属于对象。不參与序列化过程，其次 transient keyword标记的成员变量也不參与序列化过程。

通过重写writeObject和readObject方法能够改变系统默认的序列化过程。

2.3.2 Parcelable接口

Parcel内部包装了可序列化的数据。能够在Binder中自由传输。序列化过程中须要实现的功能有序列化、反序列化和内容描写叙述。

序列化功能由 writeToParcel 方法完毕,终于是通过 Parcel 的一系列writer方法来完毕。

   @Override
    public void writeToParcel(Parcel out, int flags) {
    out.writeInt(code);
    out.writeString(name);
    }

反序列化功能由 CREATOR 来完毕。其内部表明了怎样创建序列化对象和数组，通过 Parcel 的一系列read方法来完毕。

public static final Creator<Book> CREATOR = new Creator<Book>() {
@Override
public Book createFromParcel(Parcel in) {
return new Book(in);
} 
@Override
public Book[] newArray(int size) {
return new Book[size];
}
};
protected Book(Parcel in) {
code = in.readInt();
name = in.readString();
}

在Book(Parcel in)方法中，假设有一个成员变量是还有一个可序列化对象。在反序列化过程中须要传递当前线程的上下文类载入器，否则会报无法找到类的错误。

   book = in.readParcelable(Thread.currentThread().getContextClassLoader());

内容描写叙述功能由 describeContents 方法完毕，差点儿全部情况下都应该返回0，仅当当前对象中存在文件描写叙述符时返回1。

public int describeContents() {
return 0;
}

Serializable 是Java的序列化接口，使用简单但开销大，序列化和反序列化过程须要大量I/O操作。

而 Parcelable 是Android中的序列化方式。适合在Android平台使用。效率高可是使用麻烦。 Parcelable 主要在内存序列化上，Parcelable 也能够将对象序列化到存储设备中或者将对象序列化后通过网络传输，可是稍显复杂。推荐使用 Serializable 。

2.3.3 Binder

Binder是Android中的一个类，实现了 IBinder 接口。从IPC角度说。Binder是Andoird的一种跨进程通讯方式，Binder还能够理解为一种虚拟物理设备。它的设备驱动是/dev/binder。从Android Framework角度来说，Binder是 ServiceManager 连接各种Manager( ActivityManager· 、 WindowManager )和对应 ManagerService 的桥梁。从Android应用层来说。Binder是client和服务端进行通信的媒介，当bindService时，服务端返回一个包括服务端业务调用的Binder对象，通过这个Binder对象，client就能够获取server端提供的服务或者数据（ 包含普通服务和基于AIDL的服务）。

Binder通信採用C/S架构，从组件视角来说，包括Client、Server、ServiceManager以及binder驱动，当中ServiceManager用于管理系统中的各种服务。

图中的Client,Server,Service Manager之间交互都是虚线表示，是因为它们彼此之间不是直接交互的，而是都通过与Binder驱动进行交互的，从而实现IPC通信方式。

当中Binder驱动位于内核空间。Client,Server,Service Manager位于用户空间。

Binder驱动和Service Manager能够看做是Android平台的基础架构，而Client和Server是Android的应用层，开发者仅仅需自己定义实现client、Server端，借助Android的基本平台架构便能够直接进行IPC通信。
http://gityuan.com/2015/10/31/binder-prepare/

Android中Binder主要用于 Service ，包含AIDL和Messenger。普通Service的Binder不涉及进程间通信，Messenger的底层事实上是AIDL，所以以下通过AIDL分析Binder的工作机制。

由系统依据AIDL文件自己主动生成.java文件

  1. Book.java
    表示图书信息的实体类。实现了Parcelable接口。
  2. Book.aidl
    Book类在AIDL中的声明。
  3. IBookManager.aidl
    定义的管理Book实体的一个接口，包括 getBookList 和 addBook 两个方法。虽然Book类和IBookManager位于同样的包中。可是在IBookManager仍然要导入Book类。
  4. IBookManager.java
    系统为IBookManager.aidl生产的Binder类，在 gen 文件夹下。
    IBookManager继承了 IInterface 接口。全部在Binder中传输的接口都须要继IInterface接口。结构例如以下：
    • 声明了 getBookList 和 addBook 方法，还声明了两个整型id分别标识这两个方法，用于标识在 transact 过程中client请求的究竟是哪个方法。
    • 声明了一个内部类 Stub ，这个 Stub 就是一个Binder类，当client和服务端位于同一进程时，方法调用不会走跨进程的 transact 。当二者位于不同进程时，方法调用须要走 transact 过程，这个逻辑有 Stub 的内部代理类 Proxy 来完毕。

    • 这个接口的核心实现就是它的内部类 Stub 和 Stub 的内部代理类 Proxy 。

Stub和Proxy类的内部方法和定义

  1. DESCRIPTOR
    Binder的唯一标识。一般用Binder的类名表示。
  2. asInterface(android.os.IBinder obj)
    将服务端的Binder对象转换为client所需的AIDL接口类型的对象，假设C/S位于同一进
    程。此方法返回就是服务端的Stub对象本身。否则返回的就是系统封装后的Stub.proxy对
    象。

  3. asBinder
    返回当前Binder对象。

  4. onTransact
    这种方法执行在服务端的Binder线程池中，由client发起跨进程请求时。远程请求会通过
    系统底层封装后交由此方法来处理。该方法的原型是 
     java public Boolean onTransact(int code,Parcelable data,Parcelable reply,int flags)
    1. 服务端通过code确定client请求的目标方法是什么。
    2. 接着从data取出目标方法所需的參数，然后运行目标方法。
    3. 运行完成后向reply写入返回值（ 假设有返回值） 。
    4. 假设这种方法返回值为false，那么服务端的请求会失败，利用这个特性我们能够来做权限验证。
  5. Proxy#getBookList 和Proxy#addBook
    这两个方法执行在client，内部实现步骤例如以下：
    1. 首先创建该方法所须要的输入型对象Parcel对象_data，输出型Parcel对象_reply和返回值对象List。
    2. 然后把该方法的參数信息写入_data（ 假设有參数）
    3. 接着调用transact方法发起RPC（ 远程过程调用） ，同一时候当前线程挂起
    4. 然后服务端的onTransact方法会被调用知道RPC过程返回后，当前线程继续运行。并从_reply中取出RPC过程的返回结果，最后返回_reply中的数据。

AIDL文件不是必须的，之所以提供AIDL文件。是为了方便系统为我们生成IBookManager.java，但我们全然能够自己写一个。

linkToDeath和unlinkToDeath
假设服务端进程异常终止，我们到服务端的Binder连接断裂。可是。假设我们不知道Binder连接已经断裂，那么client功能会受影响。

通过linkTODeath我们能够给Binder设置一个死亡代理，当Binder死亡时。我们就会收到通知。

  1. 声明一个 DeathRecipient 对象。

    DeathRecipient 是一个接口，仅仅有一个方法 binderDied ，当Binder死亡的时候。系统就会回调 binderDied 方法，然后我们就能够又一次绑定远程服务。

     private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient(){
 @Override
 public void binderDied(){
 if(mBookManager == null){
 return;
 } 
 mBookManager.asBinder().unlinkToDeath(mDeathRecipient,0);
 mBookManager = null;
 // TODO：这里又一次绑定远程Service
 }
 }
  2. 在client绑定远程服务成功后，给binder设置死亡代理： 
     mService = IBookManager.Stub.asInterface(binder);
 binder.linkToDeath(mDeathRecipient,0);
  3. 另外，能够通过Binder的 isBinderAlive 推断Binder是否死亡。

2.4 Android中的IPC方式

主要有下面方式：

  1. Intent中附加extras
  2. 共享文件
  3. Binder
  4. ContentProvider
  5. Socket

2.4.1 使用Bundle

四大组件中的三大组件（ Activity、Service、Receiver） 都支持在Intent中传递 Bundle 数据。


Bundle实现了Parcelable接口，因此能够方便的在不同进程间传输。当我们在一个进程中启动了还有一个进程的Activity、Service、Receiver，能够再Bundle中附加我们须要传输给远程进程的消息并通过Intent发送出去。被传输的数据必须能够被序列化。

2.4.2 使用文件共享

我们能够序列化一个对象到文件系统中的同一时候从还有一个进程中恢复这个对象。

  1. 通过 ObjectOutputStream / ObjectInputStream 序列化一个对象到文件里。或者在还有一个进程从文件里反序列这个对象。

    注意：反序列化得到的对象仅仅是内容上和序列化之前的对象一样，本质是两个对象。

  2. 文件并发读写会导致读出的对象可能不是最新的，并发写的话那就更严重了 。

    所以文件共享方式适合对数据同步要求不高的进程之间进行通信，而且要妥善处理并发读写问题。

  3. SharedPreferences 底层实现採用XML文件来存储键值对。系统对它的读/写有一定的缓存策略，即在内存中会有一份 SharedPreferences 文件的缓存，因此在多进程模式下，系统对它的读/写变得不可靠，面对高并发读/写时 SharedPreferences 有非常大几率丢失数据。因此不建议在IPC中使用 SharedPreferences 。

2.4.3 使用Messenger

Messenger能够在不同进程间传递Message对象。是一种轻量级的IPC方案，底层实现是AIDL。它对AIDL进行了封装。使得我们能够更简便的进行IPC。

详细使用时。分为服务端和client：

  1. 服务端：创建一个Service来处理client请求。同一时候创建一个Handler并通过它来创建一个
    Messenger，然后再Service的onBind中返回Messenger对象底层的Binder就可以。 
     private final Messenger mMessenger = new Messenger (new xxxHandler());
  2. client：绑定服务端的Sevice。利用服务端返回的IBinder对象来创建一个Messenger，通过这个Messenger就能够向服务端发送消息了，消息类型是 Message 。假设须要服务端响应，则须要创建一个Handler并通过它来创建一个Messenger（ 和服务端一样） ，并通过 Message 的 replyTo 參数传递给服务端。

    服务端通过Message的 replyTo 參数就能够回应client了。

总而言之，就是client和服务端 拿到对方的Messenger来发送 Message 。仅仅只是client通过bindService 而服务端通过 message.replyTo 来获得对方的Messenger。

Messenger中有一个 Hanlder 以串行的方式处理队列中的消息。

不存在并发运行，因此我们不用考虑线程同步的问题。

2.4.4 使用AIDL

假设有大量的并发请求，使用Messenger就不太适合，同一时候假设须要跨进程调用服务端的方法，Messenger就无法做到了。这时我们能够使用AIDL。

流程例如以下：

  1. 服务端须要创建Service来监听client请求，然后创建一个AIDL文件。将暴露给client的接口在AIDL文件里声明。最后在Service中实现这个AIDL接口就可以。

  2. client首先绑定服务端的Service。绑定成功后。将服务端返回的Binder对象转成AIDL接口所属的类型，接着就能够调用AIDL中的方法了。

AIDL支持的数据类型：

  1. 基本数据类型、String、CharSequence
  2. List：仅仅支持ArrayList。里面的每一个元素必须被AIDL支持
  3. Map：仅仅支持HashMap。里面的每一个元素必须被AIDL支持
  4. Parcelable
  5. 全部的AIDL接口本身也能够在AIDL文件里使用

自己定义的Parcelable对象和AIDL对象，无论它们与当前的AIDL文件是否位于同一个包，都必须显式import进来。

假设AIDL文件里使用了自己定义的Parcelable对象，就必须新建一个和它同名的AIDL文件，并在当中声明它为Parcelable类型。

    package com.ryg.chapter_2.aidl;
    parcelable Book;

AIDL接口中的參数除了基本类型以外都必须表明方向in/out。

AIDL接口文件里仅仅支持方法，不支持声明静态常量。

建议把全部和AIDL相关的类和文件放在同一个包中，方便管理。

    void addBook(in Book book);
posted on 2017-08-17 09:55  ljbguanli  阅读(232)  评论(0)  编辑  收藏  举报

Powered by: 博客园 Copyright © 2024 ljbguanli
Powered by .NET 9.0 on Kubernetes