写给 Android 开发者的系统基础知识科普

与我以往的风格不同，本文为科普类文章，因而不会涉及到过分高深难懂的常识。但这些内容或许 Android 应用层开发者甚至部分 framework 层开发者都不了解，因而依旧高能预警。

别的广东这两天好冷啊，我们留意保暖~

虚拟机与运行时

目标的概念

假定 getObjectAddress(Object) 是一个获取目标内存地址的办法。

第一题：

考虑如下代码：

public static void main(String[] args) {
    Object o = new Object();
    long address1 = getObjectAddress(o);
    // .......
    long address2 = getObjectAddress(o);
}

main 办法中，创立了一个 Object 目标，随后两次调用 getObjectAddress 获取该目标的地址。两次获取到的目标地址是否有或许不同？换句话说，目标的地址是否有或许变更？

答：有或许。JVM 中存在 GC 即“废物收回”机制，会收回不再运用的目标以腾出内存空间。GC 或许会移动目标。

第二题：

考虑如下代码：

private static long allocate() {
    Object o = new Object();
    return getObjectAddress(o);
}
public static void main(String[] args) {
    long address1 = allocate();
    // ......
    long address2 = allocate();
}

allocate() 创立了一个 Object 目标，然后获取它的目标地址。
main 办法中调用两次 allocate()，这两个目标的内存地址是否有或许相同？

答：有或许。在 allocate() 办法中创立的目标在该办法回来后便失掉一切引证成为“不再需要的目标”，假如两次办法调用之间，第一次办法调用中发生的暂时目标被上文中说到的 GC 机制收回，对应的内存空间就变得“闲暇”，能够被其他目标占用。

第三题：

哎呀，既然上面说同一个目标的内存地址或许不相同，两个不同目标也有或许有相同的内存地址，而java 里的 == 又是判断目标的内存地址，那么

Object o = new Object();
if (o != o)

还有

Object o1 = new Object();
Object o2 = new Object();
if (o1 == o2)

这儿的两个 if 不是都有或许建立？

答：不或许。== 操作符比较确实实是目标地址没错，可是这儿其实还隐含了两个条件：

1. 这个操作符比较的是 “那一刻” 两个目标的地址。
2. 比较的两个目标都位于同一个进程内。

上述说到的两种情况都不满足“同一时间”这一条件，因而这两条 if 永远不会建立。

类与办法

第四题：

假定 Framework 是 Android Framework 里的一个类，App 是某个 Android App 的一个类：

public class Framework {
    public static int api() {
        return 0;
    }
}
public class App {
    public static void main(String[] args) {
        Framework.api();
    }
}

编译 App，然后将 Framework 内 api 办法的回来值类型从 int 改为 long，编译 Framework 但不重新编译 App，App 是否能够正常调用 Framework 的 api 办法？

答：不能。Java 类内存储的被调用办法的信息里包括回来值类型，假如回来值类型不对在运行时就找不到对应办法。将办法改为成员变量然后修改该变量的类型也同理。

第五题：

考虑如下代码：

class Parent {
    public void call() {
        privateMethod();
    }
    private void privateMethod() {
        System.out.println("Parent method called");
    }
}
class Child extends Parent {
    private void privateMethod() {
        System.out.println("Child method called");
    }
}
new Child().call();

Child 里的 privateMethod 是否重写了 Parent 里的？call 中调用的 privateMethod() 会调用到 Parent 里的仍是 Child 里的？

答：不构成办法重写，仍是会调用到 Parent 里的 privateMethod。private 办法是 direct 办法，direct 办法无法被重写。

操作系统根底

多进程与虚拟内存

假定有进程 A 和进程 B。

第六题：

进程 A 里的目标 a 和进程 B 里的目标 b 具有相同的内存地址，它们是同一个目标吗？

答：当然不是，上面才说过“目标相等”这个概念在同一个进程里才有意义，不认真听课思考是会被打屁屁的~

第七题：

进程 A 内有一个目标 a 并将这个目标的内存地址传递给了 B，B 是否能够直接访问（读取、写入等操作）这个目标？

答：不能，大概率会触发段过错，小概率会修改到自己内存空间里某个冤种目标的数据，无论如何都不会影响到进程 A。作为在用户空间运行的进程，它们拿到的所谓内存地址全部都是虚拟地址，进程访问这些地址的时分会先经过一个转换进程转化为物理地址再操作。假如转换犯错（人家根本不认识你给的这个地址，或许对应内存的权限不让你执行对应操作），就会触发段过错。

第八题：

仍是我们心爱的进程 A 和 B，可是这次 B 是 A 的子进程，即 A 调用 fork 发生了 B 这个新的进程：

void a() {
    int* p = malloc(sizeof(int));
    *p = 1;
    if (fork() > 0) {
        // 进程 A 也即父进程
        // 巴拉巴拉巴拉一堆操作
    } else {
        // 进程 B 也即子进程
        *p = 2;
    }
}

（fork 是 Posix 内创立进程的 API，调用完成后假如仍然在父进程则回来子进程的 pid 永远大于 0，在子进程则回来 0）

（仍是了解不了就把 A 想象为 Zygote 进程，B 想象为恣意 App 进程）

这一段代码分配了一段内存，调用 fork 发生了一个子进程，然后在子进程里将预先分配好的那段内存里的值更改为 2。
问：进程 B 做出的更改是否对进程 A 可见？

答：不行见，进程 A 看见的那一段内存的值依然是 1。Linux 内核有一个叫做“写时仿制”（Copy On Write）的技能，在进程 B 尝试写入这一段内存的时分会偷偷把实在的内存给仿制一份，最后写入的是这份拷贝里的值，而进程 A 看见的仍是原来的值。

跨进程大数据传递

已知进程 A 和进程 B，进程 A 暴露出一个 AIDL 接口，现在进程 B 要从 A 获取 10M 的数据（远远超出 binder 数据大小约束），且制止传递文件途径，只允许调用这个 AIDL 接口一次，请问如何完成？

答：能够传递文件描述符（File Descriptor）。别以为这个玩意只能表明文件！举个比如，作为应用层开发者我们能够运用同享内存的办法，这样编写 AIDL 完成类把数据传递出去：

@Override public SharedMemory getData() throws RemoteException {
    int size = 10 * 1024 * 1024;
    try {
        SharedMemory sharedMemory = SharedMemory.create("shared memory", size);
        ByteBuffer buffer = sharedMemory.mapReadWrite();
        for (int i = 0;i < 10;i++) {
            // 模拟发生一堆数据
            buffer.put(i * 1024 * 1024, (byte) 114);
            buffer.put(i * 1024 * 1024 + 1, (byte) 51);
            buffer.put(i * 1024 * 1024 + 2, (byte) 4);
            buffer.put(i * 1024 * 1024 + 3, (byte) 191);
            buffer.put(i * 1024 * 1024 + 4, (byte) 98);
            buffer.put(i * 1024 * 1024 + 5, (byte) 108);
            buffer.put(i * 1024 * 1024 + 6, (byte) 93);
        }
        SharedMemory.unmap(buffer);
        sharedMemory.setProtect(OsConstants.PROT_READ);
        return sharedMemory;
    } catch (ErrnoException e) {
        throw new RemoteException("remote create shared memory failed: " + e.getMessage());
    }
}

然后在进程 B 里这样拿：

IRemoteService service = IRemoteService.Stub.asInterface(binder);
try {
    SharedMemory sharedMemory = service.getData();
    ByteBuffer buffer = sharedMemory.mapReadOnly();
    // 模拟处理数据
    int[] temp = new int[10];
    for (int i = 0;i < 10;i++) {
        for (int j = 0;j < 10;j++) {
            temp[j] = buffer.get(i * 1024 * 1024 + j);
        }
        Log.e(TAG, "Large buffer[" + i + "]=" + Arrays.toString(temp));
    }
    SharedMemory.unmap(buffer);
    sharedMemory.close();
} catch (Exception e) {
    throw new RuntimeException(e);
}

这儿运用的 SharedMemory 从 Android 8.1 开端可用，在 8.1 之前的系统里也有一个叫做 MemoryFile 的 API 能够用。
打开 SharedMemory 里的源码，你会发现其实它内部便是创立了一块 ashmem （匿名同享内存），然后将对应的文件描述符传递给 binder。内核会负责将一个可用的文件描述符传递给目标进程。
你能够将它了解为能够跨进程传递的 File Stream（只要能经过权限查看），合理利用这个小玩意有奇效哦 ：）