android共享库
Ⅰ android shared library已停用
android中的所有应用程序都无法禁用。
每一个模块名称必须惟一，且不含任何空格。构建系统在生成最终共享库文件时，会将正确的前缀和后缀自动添加到您分配给LOCAL_MODULE的名称。例如，上述示例会致使生成一个名为libhello-jni.so的库。
若是模块名称的开头已经是lib，则构建系统不会附加额外的前缀lib；而是按原样采用模块名称，并添加.so扩展名。所以，好比原来名为libfoo.c的源文件仍会生成名为libfoo.so的共享对象文件。此行为是为了支持Android平台源文件从Android.mk文件生成的库，全部这些库的名称都以lib开头。
Ⅱ 安装安卓软件时提醒说没有该应用所需的共享库是怎么回事
共享库不存在或失效，是因为你所升级的软件与你手机的系统不兼容，必须装回以前那个版本，比如说你的软件升级到1.1版本出现了共享库不存在或失效，无法安装，你只要装回1.0版本的那个软件就可以了。
Ⅲ android中java静态库和java共享库有什么区别
程序编制一般需经编辑、编译、链接、加载和运行几个步骤。在我们的应用中，有一些公共代码是需要反复使用，就把这些代码编译为“库”文件；在链接步骤中，连接器将从库文件取得所需的代码，复制到生成的可执行文件中。这种库称为静态库，其特点是可执行文件中包含了库代码的一份完整拷贝；缺点就是被多次使用就会有多份冗余拷贝。
为了克服这个缺点可以采用动态链接库。这个时候链接器仅仅是在可执行文件中打上标志，说明需要使用哪些动态连接库；当运行程序时，加载器根据这些标志把所需的动态链接库加载到内存。
另外在当前的编程环境中，一般都提供方法让程序在运行的时候把某个特定的动态连接库加载并运行，也可以将其卸载（例如Win32的LoadLibrary()&FreeLibrary()和Posix的dlopen()&dlclose()）。这个功能被广泛地用于在程序运行时刻更新某些功能模块或者是程序外观。
与普通程序不同的是，Java程序（class文件）并不是本地的可执行程序。当运行Java程序时，首先运行JVM（Java虚拟机），然后再把Java class加载到JVM里头运行，负责加载Java class的这部分就叫做Class Loader。通常class文件仅在需要使用时才加载。 这本身就是一种动态链接。
Java作为一种天生的动态链接语言，无法支持静态链接。但C语言的静态库除了静态链接的概念外，还隐含了一层意思，即库中的代码会打包到可执行文件中。JAVA中的JAR某种程度上类似一个可执行文件或库，借用C语言中静态库和动态库的概念，这里把最终会合并到生成的JAR文件中的JAR包叫静态库，反之仅仅在编译中使用，并不打包到生成的JAR包中，运行时需系统自行提供的JAR包叫动态库。
C的静态链接只把需要的代码复制过来，而Java用类似Fat Jar的方法，把所有的依赖库打包到最后的库中，眉毛胡子一把抓。这个问题可以用ProGuard解决，用它自己的话说是 It detects and removes unused classes, fields, methods, and attributes。
Eclipse中对JAR包的使用方式有两种，library和user libraries，其中library在工程中通过add jars...或add external jars...添加，出现在Referenced Libraries中，而user libraries需要在工作空间中管理，再在工程中通过add library...添加。这两种使用方式本身并没有静态库和动态库的区别，需要在打包或部署时再行指定。但user libraries的方式明显更方便管理多个工程共同使用的多个库，而系统库往往都有这种特性。
android的apk比JAR更类似可执行程序，而且因为标准库隐藏了很多功能，我们常常需要使用自己构建的系统库来编译。但android的ADT工具并没有提供是否将library或user libraries打包的选项。根据我的经验，ADT默认将library打包到apk中，而user libraries则仅用于编译，运行时再请求系统加载相关类。哪位同学有更明确的信息，还望指教，我短期内恐怕不会有时间去研究这个问题。
因此，可以这么说，在android中，library用来添加静态库，而user libraries用来管理动态库。千万不能弄错了，如果把静态库错误地加入动态库，运行时会出现找不到对应的class的错误，但因为Java语言的动态链接机制，只有运行到库中代码时才会出错；反之，如果把动态库做成了静态库，问题就更隐蔽了，可能只是dex文件特别大，而没有其它问题，也可能因加载了错误版本的系统代码，出现一些稀奇古怪的问题。慎之，慎之...
附：向eclispe中添加user Libraries的步骤：
1。点击eclipse的window菜单，选择“Preference”
2。在preferences窗口中选择java->User Libraries,然后点击窗口右边的New...按钮，在弹出的子窗口中输入user library的名称，此时在user libraries窗口中会出现新加的library名称。
3。向该user library中添加jar包。选中my_lib，然后点击Add JARS...按钮，选择你要添加的jar后，点击“打开”按钮，则my_lib库中就会出现你刚添加的jar文件信息。
4。最后点击窗口下的“OK”按钮，完成user library的添加和其jar的添加。
Ⅳ 安卓平台属于动态库操作吗
属于
静态库全称静态链接库，动态库全称动态链接库，看到全称就知道什么意思了吧？也就是说在链接的时候才会用到的库，只有C/C++、OC语言才会有链接过程，Java没有。在Android中说到静态库和动态库，一般说的都是C/C++代码，我们知道在android中是通过jni技术访问到C代码的，我们会把C/C++打包成so文件，这个就是动态库（共享库）。如果我们想要使用的C库是.a形式的静态库时，我们要把.a包装成so库，具体网上有方法。个人感觉在java语言中讨论静态库和动态库就是个伪概念，java是的编译结果是字节码文件，不是二进制文件，而且没有链接的过程，jvm在解释执行java代码的时候调用C++代码只能是动态的。在C++和object C开发中，用编译链接的过程，静态库在链接过程中，会和自己写的源代码打到一块，多个程序多个静态库。动态库不会打到一块，如果有共享情况的话，系统只会加载一次。OC的代码处理过程是很复杂的，有预处理、编译、链接过程，预处理就是处理宏什么的，编译这个过程就很复杂了，有编译前端和编译后端，编译称机器码（中间还会有汇编的过程），链接就是链接动态库或者静态库。Android（java）代码处理过程就很简单啦，毕竟是运行在虚拟机上的。没有所谓的预处理，直接编译，这里的编译也就是把java代码转化成字节码，这个编译和OC中的编译可不是一个概念，只不过也这么叫而已。后续Aandroid还会用dex工具把.class打包成.dex，不同的VM模式（5.0以后都是ART）会对.dex进行不同的优化，具体看Android 编译到运行APK过程总结。需要提一下的是，ART采用AOT和JIT技术，在安装或者运行的时候，会把字节码转化成机器码，这个机器码也会受VM控制的，具体看Android之Dalvik 、ARTC/C++、Object C属于编译型语言，这是毋庸置疑的，因为它们都会在生成安装包之前编译成机器码。
Ⅳ Android 怎么自定义共享库
LOCAL_PATH := $(call my-dir)//标准mk语句，指编译路径，所有mk文件第一句都是这个 /**这个模块表示引用了一个本地的静态库 include $(CLEAR_VARS) //清除各种变量，因为这些变量是静态全局的，如果清除，下次编译时又会用到这些变量造成出错 LOCAL_MODULE := libopencore-amrnb //本地静态库模块的名字，这个名字在下面编译jni时需要引用 LOCAL_SRC_FILES := lib/libopencore-amrnb/smfwuxiao/article/details/6591927 NDK r5 开始支持预编译共享库。预编译共享库就是从其他地方获得源码编译出的共享库，而不是Android系统自带的。方法如下： 1、声明共享库模块 把共享库声明为一个独立模块。假如 libfoo.so 与 Android.mk 位于同一目录。则 Android.mk 应该这样写： LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := foo-prebuilt # 模块名 LOCAL_SRC_FILES := libfoo.so # 模块的文件路径（相对于 LOCAL_PATH） include $(PREBUILT_SHARED_LIBRARY) # 注意这里不是 BUILD_SHARED_LIBRARY 这个共享库将被拷贝到 $PROJECT/obj/local 和 $PROJECT/libs/<abi> （strip过的） 2、在其他模块中引用这个共享库 在 Android.mk 中，将这个共享库的模块名加入 LOCAL_STATIC_LIBRARIES （静态库）或 LOCAL_SHARED_LIBRARIES （动态库） 例如, 使用 libfoo.so 的方法: include $(CLEAR_VARS) LOCAL_MODULE := foo-user LOCAL_SRC_FILES := foo-user.c LOCAL_SHARED_LIBRARY := foo-prebuilt include $(BUILD_SHARED_LIBRARY) 3、为共享库导出头文件 这个共享库一般有相应的头文件，比如 libfoo.so 就有 foo.h。 一个简单方法（在Android.mk中写）： include $(CLEAR_VARS) LOCAL_MODULE := foo-prebuilt LOCAL_SRC_FILES := libfoo.so LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include include $(PREBUILT_SHARED_LIBRARY) 这样，使用该共享库的模块就会在它的 LOCAL_C_INCLUDES 变量加入该头文件搜索路径。 4、调试共享库 建议你的共享库保留调试信息。 $PROJECT/libs/<abi> 目录下的共享库都是 strip 之后的（没有调试信息）。有调试信息的版本可被ndk-gdb使用。 5、共享库 ABI 你的共享库与目标系统ABI的兼容性很重要。 请检查 TARGET_ARCH_ABI，有以下值： armeabi => ARMv5TE 以上 armeabi-v7a => ARMv7 以上 x86 => x86 建议： armeabi ABI 可以运行在所有 ARM CPU 上。
Ⅵ android 怎么自定义共享库
在源码根目录下有个 vendor (供应商) 目录，专门用于存放各个供应商的会有代码。其中有一个个 sample 目录，这是 Google 用于示范如何编写自定义共享库的示例，它展示了自定义共享库、JNI 调用、对库的使用方法及皮肤定制等功能。下面我们通过对该示例进行分析，让大家熟悉这个轻量级的框架。
1、首先看一下 sample 目录的结构：
sample
├── Android.mk
├── apps
│ ├── Android.mk
│ ├── client
│ └── upgrade
├── frameworks
│ ├── Android.mk
│ └── PlatformLibrary
├── MODULE_LICENSE_APACHE2
├── procts
│ ├── AndroidProcts.mk
│ └── sample_addon.mk
├── README.txt
├── sdk_addon
│ ├── hardware.ini
│ └── manifest.ini
└── skins
└── WVGAMedDpi
Android.mk： 该文件用于编写构建规则，默认继承 Android 的 make 框架。
frameworks： 该目录在这里的意义等同于 Android 源码中的 frameworks 。
PlatformLibrary： 该目录就自定义共享库。
apps： 该目录用于编写依赖该库的应用程序。经过测试也可以用来编写不依赖该库的程序，这有个好处，让开发商可以把自己特有的应用集成到框架中。
client 与 upgrade： 这是两个依赖该库的应用程序示例。
procts： 该目录中的文件对包含该库与 Android 框架集成的信息，如模块名称等。
AndroidProcts.mk： 指明该模块的 make 配置文件的在哪里。
sample_addon.mk ：模块的配置信息。
sdk_addon： 该目录对该库的硬件需求进行定义。
hardware.ini： 定义模块对硬件的需求。
manifest.ini： 模块的说明文件。名称、供应商等。
skins： 该目录用于存放自定义皮肤。
WVGAMedDpi： 已经定义好的一套皮肤。
2.如何封装 Java 共享库？
PlatformLibrary 为我们展示了封装 Java 共享库的方法。其目录结构如下： frameworks/PlatformLibrary
├── Android.mk
├── com.example.android.platform_library.xml
├── java
│ └── com
│ └── example
│ └── android
│ └── platform_library
│ └── PlatformLibrary.java
└── README.txt
Android.mk： 该文件说明如何构建该模块。
com.example.android.platform_library.xml： 该文件是模块注册时需要的文件。该文件需要被放置到 /system/etc/permissions 目录下。
Java /*： Java 源码所在目录。具体步骤：
a、编写 Java 库，并将源码放到 java 目录下。这一步和编写普通 Java 程序没有差别。
b、编写 Android.mk，内容如下：
# 获得当前目录，清空环境变量
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS) # 源码所在目录，all-subdir-java-files 表示所有了目录中的 Java 文件。
LOCAL_SRC_FILES := \
$(call all-subdir-java-files) # 该模块是可选的。
LOCAL_MODULE_TAGS := optional # Java 模块名称
LOCAL_MODULE:= com.example.android.platform_library # 编译为 Java 库。最近以 jar 的形式而不是 apk 的形式存在。
include $(BUILD_JAVA_LIBRARY) # 构建该库的 API 文档
include $(CLEAR_VARS)
LOCAL_SRC_FILES := $(call all-subdir-java-files) $(call all-subdir-html-files)
LOCAL_MODULE:= platform_library
# 文档对应的库
LOCAL_DROIDDOC_OPTIONS := com.example.android.platform_library
# 库的类型
LOCAL_MODULE_CLASS := JAVA_LIBRARIES
LOCAL_DROIDDOC_USE_STANDARD_DOCLET := true # 编译为 Java API。
include $(BUILD_DROIDDOC)
c、编写 com.example.android.platform_library.xml，内容如下：
< xml version="1.0" encoding="utf-8" >
<permissions>
<!-- 库的名称及对应的 Jar 文件位置 -->
<library name="com.example.android.platform_library"
file="/system/framework/com.example.android.platform_library.jar"/>
</permissions> 现在基本的库我们已经编写完成，现在需要对框架中的其它文件进行配置。
d、编写 sample/frameworks/Android.mk, 内容如下：
# 包含子目录中的所有 make 文件 include $(call all-subdir-makefiles) 该文件与 sample/Android.mk 文件相同。
e、编写 sample/sdk_addon/manifest.ini，内容如下： # 该模块的名称、供应商及描述
name=Sample Add-On
vendor=Android Open Source Project
description=sample add-on # 构建该模块的 Android 平台代号
api=3 # 模块的版本号。必须为整数。
revision=1 # 该模块中包括的共享库列表
libraries=com.example.android.platform_library # 对每个库的详细定义，格式如下:
# <library.name>=<name>.jar;<desc> # <library.name>: 通过前面 libraies 定义的库的名称。
# <name>.jar: 包含库 API 的 jar 文件。该文件放在 libs/add-on 下面。
com.example.android.platform_library=platform_library.jar;Sample optional plaform library 该文件还可包括该模块的其它定义，如皮肤等，为了保持该文档清晰易懂的初衷，这里不做介绍，需要了解可以给我邮件。
f、编写 sample/procts/sample_addom.mk，内容如下：
# 要植入系统镜像的应用及可选类库。可以包括 Java 库和本地库。这里我们只有 Java 库。
PRODUCT_PACKAGES := \ com.example.android.platform_library # 把 xml 文件复制到系统镜像中相应的位置去。
PRODUCT_COPY_FILES := \ vendor/
sample/frameworks/PlatformLibrary/com.example.android.platform_library.xml:system/etc/permissions/
com.example.android.platform_library.xml # 这个扩展的名称
PRODUCT_SDK_ADDON_NAME := platform_library # 把模块的 manifest 和硬件配置文件复制到系统镜像中相应的位置。 PRODUCT_SDK_ADDON_COPY_FILES := \
vendor/sample/sdk_addon/manifest.ini:manifest.ini \
vendor/sample/sdk_addon/hardware.ini:hardware.in # 把库的 Jar 包复制到相应的位置。 PRODUCT_SDK_ADDON_COPY_MODULES := \
com.example.android.platform_library:libs/platform_library.jar # 文档的名称。必须与。
# LOCAL_MODULE:= platform_library
PRODUCT_SDK_ADDON_DOC_MODULE := platform_library # 这个扩展继承系统扩展。 $(call inherit-proct, $(SRC_TARGET_DIR)/proct/sdk.mk) # 这个扩展的真实名字。这个名字会用于编译。
# 用 'make PRODUCT-<PRODUCT_NAME>-sdk_addon' 的形式来编译此扩展。
PRODUCT_NAME := sample_addon
g、编写 sample/procts/AndroidProcts.mk，内容如下：
PRODUCT_MAKEFILES := \
$(LOCAL_DIR)/sample_addon.mk h、最后运行make -j8 PRODUCT-sample_addon-sdk_addon，编译扩展。
至此，我们就完成了 Java 库的封装。
3、接下来我们再来看如何通过 JNI 的方式对 C 代码进行封装。
a、在 sample/frameworks/PlatformLibrary 目录下添加一个文件夹，用于放置 JNI 本地代码，目录结构如下：
frameworks/PlatformLibrary/jni
├── Android.mk
└── PlatformLibrary.cpp
b、把 frameworks/PlatformLibrary/java/com/example/android/platform_library/PlatformLibrary.java
文件改写为 JIN 调用接口，代码如下 ： package com.example.android.platform_library; import android.util.Config;
import android.util.Log; public final class PlatformLibrary {
static { / Load the library. If it's already loaded, this does nothing. System.loadLibrary("platform_library_jni");
private int mJniInt = -1; public PlatformLibrary() {} / Test native methods. public int getInt(boolean bad) {
// this alters mJniInt //
int result = getJniInt(bad); // reverse a string, for no very good reason //
String reverse = reverseString("Android!"); Log.i("PlatformLibrary", "getInt: " + result + ", '" + reverse + "'"); return mJniInt; //
/ Simple method, called from native code. private static void yodel(String msg) {
Log.d("PlatformLibrary", "yodel: " + msg); //
/ Trivial native method call. If "bad" is true, this will throw an
/ exception. native private int getJniInt(boolean bad); / Native method that returns a new string that is the reverse of
/ the original. This also calls yodel(). native private static String reverseString(String str);
}
c、在 frameworks/PlatformLibrary/jni/PlatformLibrary.cpp 中编写 PlatformLibrary.java 中规定本地调用的具体实现。
d、编写 frameworks/PlatformLibrary/jni/Android.mk，内容如下：
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS) LOCAL_MODULE_TAGS := optional # JNI 模块的名称
LOCAL_MODULE:= libplatform_library_jni # 依赖的源代码文件
LOCAL_SRC_FILES:= \
PlatformLibrary.cpp # 编译时需要的库
LOCAL_SHARED_LIBRARIES := \
libandroid_runtime \
libnativehelper \
libcutils \
libutils # 没有静态库
LOCAL_STATIC_LIBRARIES := # 包含必须的 JNI 头文件
LOCAL_C_INCLUDES += \
$(JNI_H_INCLUDE) # 编译器选项
LOCAL_CFLAGS += # 对该模块不进行预编译。使用预编译可以提高模块的性能。
LOCAL_PRELINK_MODULE := false # 把它编译成动态共享库
include $(BUILD_SHARED_LIBRARY) 该文件主要定义了本地库的名字、依赖、编译选项及编译方式。
e、修改 frameworks/PlatformLibrary/Android.mk，在末尾添加如下两行：
include $(CLEAR_VARS) # 调用子目录中的 make 文件。
include $(call all-makefiles-under,$(LOCAL_PATH))
f、修改 sdk_addon/sample_addon.mk，在PRODUCT_PACKAGES 中添加该 JNI 本地库。
PRODUCT_PACKAGES := \
com.example.android.platform_library \
libplatform_library_jni
g、编译即可。至此，添加 JNI 库完毕。
4、添加接下来我们再看看如何添加原生应用程序
添加原生应用程序就很简单了，只需要把按照 Android 应用开发的基本方法，写好一个应用，该应用可以依赖这个扩展，也可以不依赖。如 sample 中的 client 应用，目录结构如下： apps/client/
├── AndroidManifest.xml
├── Android.mk
└── src
└── com
└── example
└── android
└── platform_library
└── client
└── Client.java
a、在应用根目录中添加一个 Android.mk 文件，内容如下：
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS) LOCAL_MODULE_TAGS := user # 目标名称
LOCAL_PACKAGE_NAME := PlatformLibraryClient # 只编译这个apk包中的java文件
LOCAL_SRC_FILES := $(call all-java-files-under, src) # 使用当前版本的 SDK
LOCAL_SDK_VERSION := current # 依赖使用刚才编写的扩展
LOCAL_JAVA_LIBRARIES := com.example.android.platform_library include $(BUILD_PACKAGE)
b、在 AndroidManifest.xml 中添加一句：
<uses-library android:name="com.example.android.platform_library" />
c、修改 sdk_addon/sample_addon.mk，在PRODUCT_PACKAGES 中添加该 JNI 本地库。
PRODUCT_PACKAGES := \
com.example.android.platform_library \
libplatform_library_jni \
PlatformLibraryClient
d、编译即可。至此，添加 JNI 库完毕。
5、其他功能如添加皮肤等，这里就不一一示范了，请参考<sdk-src>/vendor/sample。
Ⅶ android系统中查看内存信息
看下大致内存使用早团轿情况 （free+buffers+cached）
proc/meminfo 机器的内存使用信息
/proc/pid/maps pid为进程号，显示当前进程所占用的虚拟地址。
/proc/pid/statm 进程所占用的内存
df 查看 存储空间使用情况
ps -t |grep system_server （或 surfaceflinger， service manager， media server，zygote） ( 倒数第二个是不是 s) 异常情况有如’D’， ‘T’， ‘Z’ ， ‘R’等
mpsys meminfo com.android.mms 打印一个app的mem信息
从以上打印可以看出，一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS
VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）是单个进程全部可访问的地址空间
RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）是单个进程实际占用的内存大小，对于单个共享库， 尽管无论多少个进程使用，实际该共享库只会被装入内存一次。
PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
USS 是或态针对某个进程开始有可疑内存泄露的情况，进行检测陆肆的最佳数字。怀疑某个程序有内存泄露可以查看这个值是否一直有增加
使用mpsys meminfo查看内存信息
脚本：
adb shell ps -t> tsq/ps.txt
adb shell top -t -m 5 -n 2 > tsq/top.txt
adb shell service list > tsq/serviceList.txt
adb shell cat /proc/meminfo >tsq/meminfo
adb shell cat /proc/buddyinfo >tsq/buddyinfo
adb shell procrank > tsq/procrank.txt
adb shell cat proc/sched_debug >tsq/sched_debug.txt
adb shell cat proc/interrupts >tsq/interrupts.txt
adb shell mpstate > tsq/mpstate.txt
adb shell bugreport > tsq/bugreport.txt
@echo "finish."
pause
可以按以下步骤进行：
Android应用的数据库一般都是私有的，其他应用无法访问，那么怎么在手机已root的前提下，在自己的应用中读取指定应用中的数据信息呢，现提供一种思路。
以uc浏览器历史浏览记录为例：
一：对手机进行root。
某些厂家的Android设备是支持在系统设置中一键root的，如魅族手机。更通用的情况下一般是用第三方软件进行root，如KingRoot。
二：在手机上安装RootExplorer。
RootExplorer是在Android上使用很方便的文件浏览器，借用它，我们可以找到uc浏览器的历史记录数据库所在为data/data/com.UCMobile/databases/history/history。
三：将数据库文件复制到sd卡指定目录。
四：从sd卡数据库文件中读取数据。
五：将数据加载到Recyclerview中展示。
至此，我们已经实现了在自己应用中读取其他应用数据库数据的一个完整过程，诚然这种方式存在许多局限性，但不失为解决方案的一种。
Ⅸ Android中静态库和共享库的区别
简单来讲：
静态库是在连接阶段直接拷贝到代码中使用的，而共享库是由加载器加载到内存，在运行时使用的。
编译出来的静态库（这里指jar包）里每个java文件对应的class文件都单独存在，可以直接导入Eclipse等IDE使用
而编译出来的共享库（jar包），内部是Android字节码Dex格式的文件，一般无法导入Eclipse等IDE使用。Android.mk中由BUILD_JAVA_LIBRARY指定生成共享BUILD_STATIC_JAVA_LIBRARY指定生成静态库。
Ⅹ Android图形系统系统篇之HWC
HWC （hwcomposer）是Android中进行窗口（ Layer ）合成和显示的HAL层模块，其实现是特定于设备的，而且通常由显示设备制造商 (OEM)完成，为 SurfaceFlinger 服务提供硬件支持。
SurfaceFlinger 可以使用 OpenGL ES 合成 Layer ，这需要占用并消耗GPU资源。大多数GPU都没有针对图层合成进行优化，当 SurfaceFlinger 通过GPU合成图层时，应用程序无法使用GPU进行自己的渲染。而 HWC 通过硬件设备进行图层合成，可以减轻GPU的合成压力。
显示设备的能力千差万别，很难直接用API表示硬件设备支持合成的 Layer 数量， Layer 是否可以进行旋转和混合模式操作，以及对图层定位和硬件合成的限制等。因此HWC描述上述信息的流程是这样的：
虽然每个显示设备的能力不同，但是官方要求每个 HWC 硬件模块都应该支持以下能力：
但是并非所有情况下 HWC 都比GPU更高效，例如：当屏幕上没有任何变化时，尤其是叠加层有透明像素并且需要进行图层透明像素混合时。在这种情况下， HWC 可以要求部分或者全部叠加层都进行GPU合成，然后 HWC 持有合成的结果Buffer，如果 SurfaceFlinger 要求合成相同的叠加图层列表， HWC 可以直接显示之前合成的结果Buffer，这有助于提高待机设备的电池寿命。
HWC 也提供了 VSync 事件，用于管理渲染和图层合成时机，后续文章会进行介绍。
Android7.0提供了HWC和HWC2两个版本，默认使用HWC，但是手机厂商也可以选择HWC2，如下所示：
SurfaceFlinger 通过 HWComposer 使用 HWC 硬件能力， HWComposer 构造函数通过 loadHwcMole 方法加载HWC模块，并封装成 HWC2::Device 结构，如下所示：
上述通过 hw_get_mole 方法（hardware\libhardware\hardware.c）加载 hwcomposer 模块，此模块由硬件厂商提供实现，例如：hardware\libhardware\moles\hwcomposer\hwcomposer.cpp是 hwcomposer 模块基于HWC1的default实现，对应的共享库是 hwcomposer.default.so ；hardware\qcom\display\msm8994\libhwcomposer\hwc.cpp是高通MSM8994基于HWC1的实现，对应的共享库是 hwcomposer.msm8994.so 。
如果是基于HWC2协议实现，则需要实现hwcomposer2.h中定义的 hwc2_device_t 接口，例如： class VendorComposer : public hwc2_device_t 。Android7.0的 hwcomposer 模块默认都是基于HWC1协议实现的。
每个HAL层模块实现都要定义一个 HAL_MODULE_INFO_SYM 数据结构，并且该结构的第一个字段必须是 hw_mole_t ，下面是高通MSM8994 hwcomposer 模块的定义：
frameworks\native\services\surfaceflinger\DisplayHardware\HWC2.h主要定义了以下三个结构体：
它们是对 HWC 硬件模块的进一步封装，方便进行调用。 HWC2::Device 持有一个 hwc2_device_t ，用于连接硬件设备，它包含了很多HWC2_PFN开头的函数指针变量，这些函数指针定义在 hwcomposer2.h 。
在 HWC2::Device 的构造函数中，会通过 Device::loadFunctionPointers -> loadFunctionPointer(FunctionDescriptor desc, PFN& outPFN) -> hwc2_device_t::getFunction 的调用链从硬件设备中获取具体的函数指针实现。关键模板函数如下所示：
这些函数指针主要分为三类：
通过上述函数指针可以与 hwc2_device_t 表示的硬件合成模块进行交互。三类指针分别选取了一个示例：
可以通过类图，直观感受下引用关系。
HWC2::Device 构造函数除了完成获取函数指针实现以外，还会通过 Device::registerCallbacks 向硬件设备注册三个 Display 的回调：热插拔，刷新和VSync信号，如下所示：
总结一下， HWC2::Device 构造函数向硬件设备注册三个 Display 回调：热插拔，刷新和VSync信号。当 HWC2::Device 收到这些回调时，会通过监听器向外回调到对应的HWComposer函数： HWComposer::hotplug / HWComposer::invalidate / HWComposer::vsync 。HWComposer再通过这些信息驱动对应工作，后续文章进行介绍。
上文提到 HWC2::Device 中的函数指针是hardware\libhardware\include\hardware\hwcomposer2.h中定义的，除此之外，该头文件还定义了一些重要的结构体，这里介绍两个比较重要的：
DisplayType 表示显示屏类型，上面注释已经介绍，重点看下Layer合成类型：
那么一个 Layer 的合成方式是怎么确定的那？大致流程如下所示：
本篇文章只是简单介绍了HWC模块的相关类： HWComposer 、 HWC2::Device 、 HWC2::Display 和 HWC2::Layer ，以及它们的关系。此外，还着重介绍了Layer的合成方式和合成流程。后续文章会更加全面的介绍 SurfaceFlinger 是如何通过HWC模块完成Layer合成和上屏的（虚拟屏幕是到离屏缓冲区）。