让我举一个具体的例子，说明在Java中ABI和API是如何不同的。

ABI不兼容的更改是如果我将方法a# m()从将字符串作为参数更改为String…论点。这不是ABI兼容的，因为您必须重新编译调用它的代码，但它是API兼容的，因为您可以通过重新编译来解析它，而无需在调用方中更改任何代码。

这里有一个例子。我的Java库有类A

    // Version 1.0.0
    public class A {
        public void m(String string) {
            System.out.println(string);
        }
    }

我有一个类使用这个库

    public class Main {
        public static void main(String[] args) {
            (new A()).m("string");
        }
    }

现在，库作者编译了他们的类A，我编译了我的类Main，一切都运行得很好。想象一个新版本的a出现了

    // Version 2.0.0
    public class A {
        public void m(String... string) {
            System.out.println(string[0]);
        }
    }

如果我只是使用新编译的类A，并将其与之前编译的类Main一起删除，那么在试图调用该方法时就会得到异常

Exception in thread "main" java.lang.NoSuchMethodError: A.m(Ljava/lang/String;)V
        at Main.main(Main.java:5)

如果我重新编译Main，这是固定的，所有工作再次。

API是人类使用的。我们编写源代码。当我们编写程序并想要使用一些库函数时，我们编写如下代码:

long howManyDecibels = 123L;
int ok = livenMyHills(howManyDecibels);

and we needed to know that there is a method livenMyHills(), which takes a long integer parameter. So as a Programming Interface it's all expressed in source code. The compiler turns this into executable instructions which conform to the implementation of this language on this particular operating system. And in this case result in some low level operations on an Audio unit. So particular bits and bytes are squirted at some hardware. So at runtime there's lots of Binary level action going on which we don't usually see.

在二进制级别，必须对在二进制级别传递的字节有一个精确的定义，例如4字节整数中的字节顺序，或者复杂数据结构的布局——是否有填充字节来对齐一些值。这个定义就是ABI。

API:应用程序接口

这是您从应用程序/库中公开的公共类型/变量/函数集。

在C/ c++中，这是在应用程序附带的头文件中公开的内容。

ABI:应用程序二进制接口

这就是编译器构建应用程序的方式。 它定义了一些东西(但不限于):

参数如何传递给函数(寄存器/堆栈)。 谁从堆栈中清除参数(调用方/被调用方)。 返回值的位置。 异常如何传播。

我先回答你们的具体问题。

1.什么是源级别?它是否与源代码有关?

Yes, the term source level refers to the level of source code. The term level refers to the semantic level of the computation requirements as they get translated from the application domain level to the source code level and from the source code level to the machine code level (binary codes). The application domain level refers what end-users of the software want and specify as their computation requirements. The source code level refers to what programmers make of the application level requirements and then specify as a program in a certain language.

程序如何在源级进行通信?或者库的源代码包含在主程序中?

语言API专门指一种语言需要(指定)(即接口)用该语言编写可重用模块的所有东西。可重用程序符合这些接口(API)要求，以便在相同语言的其他程序中重用。每次重用都需要符合相同的API需求。所以，“沟通”这个词指的是重用。

Yes, source code (of a reusable module; in the case of C/C++, .h files ) getting included (copied at pre-processing stage) is the common way of reusing in C/C++ and is thus part of C++ API. Even when you just write a simple function foo() in the global space of a C++ program and then call the function as foo(); any number of times is reuse as per the C++language API. Java classes in Java packages are reusable modules in Java. The Java beans specification is also a Java API enabling reusable programs (beans) to be reused by other modules ( could be another bean) with the help of runtimes/containers (conforming to that specification).

关于语言API和ABI之间的区别，以及面向服务的API与语言API的区别，我在SO方面的回答应该会有所帮助。

(应用二进制接口)结合操作系统的特定硬件平台的规范。它超越了API(应用程序程序接口)，后者定义了从应用程序到操作系统的调用。ABI为特定的CPU系列定义API和机器语言。API不能确保运行时兼容性，但ABI可以，因为它定义了机器语言或运行时格式。

礼貌

Linux共享库最小可运行API vs ABI示例

这个答案是从我的另一个答案中提取出来的:什么是应用程序二进制接口(ABI)?但我觉得它也直接回答了这个问题，而且这些问题不是重复的。

在共享库的上下文中，“拥有稳定的ABI”最重要的含义是，在库更改后不需要重新编译程序。

正如我们将在下面的示例中看到的，即使API没有改变，也可以修改ABI，从而破坏程序。

c

#include <assert.h>
#include <stdlib.h>

#include "mylib.h"

int main(void) {
    mylib_mystruct *myobject = mylib_init(1);
    assert(myobject->old_field == 1);
    free(myobject);
    return EXIT_SUCCESS;
}

mylib.c

#include <stdlib.h>

#include "mylib.h"

mylib_mystruct* mylib_init(int old_field) {
    mylib_mystruct *myobject;
    myobject = malloc(sizeof(mylib_mystruct));
    myobject->old_field = old_field;
    return myobject;
}

mylib.h

#ifndef MYLIB_H
#define MYLIB_H

typedef struct {
    int old_field;
} mylib_mystruct;

mylib_mystruct* mylib_init(int old_field);

#endif

编译和运行良好:

cc='gcc -pedantic-errors -std=c89 -Wall -Wextra'
$cc -fPIC -c -o mylib.o mylib.c
$cc -L . -shared -o libmylib.so mylib.o
$cc -L . -o main.out main.c -lmylib
LD_LIBRARY_PATH=. ./main.out

现在，假设对于标准库的v2，我们希望向mylib_mystruct添加一个名为new_field的新字段。

如果我们在old_field之前添加字段，如下所示:

typedef struct {
    int new_field;
    int old_field;
} mylib_mystruct;

重建了图书馆，但不是主要的。Out，则断言失败!

这是因为这一行:

myobject->old_field == 1

已生成程序集，该程序集试图访问结构体的第一个int，该结构体现在是new_field，而不是预期的old_field。

因此，这个更改破坏了ABI。

但是，如果我们在old_field之后添加new_field:

typedef struct {
    int old_field;
    int new_field;
} mylib_mystruct;

那么旧生成的程序集仍然访问结构的第一个int，程序仍然可以工作，因为我们保持了ABI的稳定。

下面是这个例子在GitHub上的一个全自动版本。

保持此ABI稳定的另一种方法是将mylib_mystruct视为不透明结构，仅通过方法帮助程序访问其字段。这样可以更容易地保持ABI的稳定，但是由于我们要进行更多的函数调用，因此会产生性能开销。

API 与 ABI

在前面的例子中，有趣的是，在old_field之前添加new_field只破坏了ABI，而没有破坏API。

这意味着，如果我们根据标准库重新编译main.c程序，无论如何它都会工作。

然而，如果我们改变了例如函数签名，我们也会破坏API:

mylib_mystruct* mylib_init(int old_field, int new_field);

因为在这种情况下，main.c将完全停止编译。

语义API vs编程API

我们还可以将API更改分为第三种类型:语义更改。

语义API通常是API应该做什么的自然语言描述，通常包含在API文档中。

因此，可以在不破坏程序构建本身的情况下破坏语义API。

例如，如果我们修改了

myobject->old_field = old_field;

to:

myobject->old_field = old_field + 1;

那么这既不会破坏编程API，也不会破坏ABI，但是main.c语义API会破坏。

有两种方法可以通过编程方式检查合约API:

测试一些极端情况。这很简单，但你可能总是错过一个。 正式的验证。更难做到，但产生了正确性的数学证明，本质上是将文档和测试统一为“人”/机器可验证的方式!当然，前提是你的正式描述中没有bug;-)

在Ubuntu 18.10, GCC 8.2.0中测试。