‘壹’ android如何做到防止反编译，保护自己的资源图片拜托了各位 谢谢
1.进行源码保护检测。检测DEX文件保护，查看DEX文件是否做了保护，避免法分子 反编译得到程序源码,从而杜绝恶意插入广告、恶意植入扣费代码等行为，保证用户体验以及APP的功能完整。 2.源码混淆保护检测。该项目主要用来弥补程序开发人员利用混淆源码做程序的漏洞，因为混淆源码作为一种常见的基础保护措施，并不严密，如果被专业人士利用，还是会造成相当程度的破坏。 3.资源文件保护检测。APP程序中的各种音频、视频、图片、文字等文件资料如果缺乏有效的保护，很容易被恶意篡改、替换和盗窃。比如程序中的音频格式或文字内容，如果被篡改，做成广告画面或违禁色情图片等，也是对开发人员和用户的权益侵害。 4. Android主配文件保护检测。该免费源码检测平台可以有效对Android主配置文件中的各个组件进行安全保护，预防其他人员在XML文件中插入代码，破坏和盗取相关信息，篡改应用程序的功能设定。 5.APK防二次打包保护检测。二次打包就是程序人员对下载的程序进行解压，删除原有的签名，自己设定一个签名工具在安装包上签名，这是一种盗用行为，侵害了原版程序设计人员的权益和利益。通过免费检测平台，可以有效查看安装包签名是否有过改动，可以有效防止二次打包的出现。 6、so文件保护，防止APP应用被第三方修改打包。 7.爱加密http://www.ijiami.cn/
‘贰’ 安卓用什么开发防修改存档
一种android应用程序防篡改的方法、系统及计算机存储介质，基于内存检测的动态防篡改的检测方案，检测到恶意代码注入时进行即时反制，自动恢复成原始的程序，更加有效和准确地进行应用程序的自我保护，同时也保障用户的安全使用。
根据本发明一方面，提供了一种android应用程序防篡改的方法，包括：
检测当前函数的第一标志是否为第一预定标志；
比较所述当前函数的内存结构与原函数的内存结构，判断所述当前函数是否被篡改；
如果所述当前函数被篡改，则将当前函数恢复为原函数。
示例性地，所述检测当前函数的第一标志是否为第一预定标志包括：在dalvik运行模式下，检测当前函数的修饰符是否为acc_native。
示例性地，所述检测当前函数的第一标志是否为第一预定标志包括：在art运行模式下，检测当前函数的access_flags是否标识为被xposedhook。
示例性地，所述比较所述当前函数的内存结构与原函数的内存结构包括：通过获取所述当前函数的xposedhookinfo，并将其转换为method结构，比较所述当前函数的method结构与所述原函数的method结构。
示例性地，所述转换为method结构包括：在dalvik运行模式下，通过获取当前函数method的insns即xposedhookinfo,将其转换为method结构。
示例性地，所述转换为method结构包括：在art运行模式下，通过获取当前函数method的entry_point_from_jni，将hookinfo->original_mathod转换为artmethod结构。
示例性地，所述判断所述当前函数是否被篡改包括：如果所述当前函数的method结构与原函数的method结构中除了修改过的值，其余的值都相同，则确定当前函数被注入代码。
示例性地，在dalvik运行模式下，修改过的值包括：method结构中的accessflags，以及nativefunc、insns、registerssize、outssize中的至少一个；其余的值包括：clazz、methodindex、name、shorty中的至少一个。
示例性地，在art运行模式下，修改过的值包括：artmethod类结构中的access_flags_，以及entry_point_from_jni_、entry_point_from_quick_compiled_code_、dex_code_item_offset_中的至少一个；其余的值包括：declaring_class_、dex_method_index_、method_index_中的至少一个。
示例性地，将当前函数恢复为原函数包括：将检测到被篡改的当前函数的内存空间替换为备份的原函数内存空间。
根据本发明另一方面，提供了一种android应用程序防篡改的系统，包括存储器、处理器及存储在所述存储器上且在所述处理器上运行轮顷的计算机程序，所述处理器执行所述计算机程序时实现上述方法的步骤。
根据本发明另一方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被计算机执行时实现上述方法的步骤。
根据本发明实施例的一种android应用程序防篡改的方法、系统和存储介质，采用非接触式的方法，基于内存检测的动态防篡改的检测方案，检测到恶意代码注入时进行即时反制，自动恢复成原始的程序，更液稿加有效和准确地进行应用程序的自我保护，同时也保障用户的安全使用。
附图说明
通过结合附图对本发明实施例进行更详细的描述，本发明的上述以及其它目的、特征和优势将变得更加明显。附图用来提供对本发明实施例的进一步理解，并且构成说明书的一部分，与本发明实施例一起用于解释本发明，并不构成对本发明的限制。在附图中，相同的参考标号通常代表相同部件或步骤。
图腊埋陆1是用于实现根据本发明实施例的一种android应用程序防篡改的方法的示意性流程图；
图2是用于实现根据本发明实施例的在dalvik运行模式下检测当前函数是否被篡改的示意性流程图；
图3是用于实现根据本发明实施例的在art运行模式下检测当前函数是否被篡改的示例的示意性流程图；
图4是用于实现根据本发明实施例的在dalvik运行模式下恢复原函数的示例的示意性流程图；
图5是用于实现根据本发明实施例的在art运行模式下恢复原函数的示例的示意性流程图。
具体实施方式
为了使得本发明的目的、技术方案和优点更为明显，下面将参照附图详细描述根据本发明的示例实施例。显然，所描述的实施例仅仅是本发明的一部分实施例，而不是本发明的全部实施例，应理解，本发明不受这里描述的示例实施例的限制。基于本发明中描述的本发明实施例，本领域技术人员在没有付出创造性劳动的情况下所得到的所有其它实施例都应落入本发明的保护范围之内。
dex文件是android应用程序的可执行文件，如前所述，例如，基于xposed的开源框架下，动态注入的恶意代码，把原有函数的method结构体进行了拷贝，保存到一个新的地址a指向的内存空间，同时修改原函数的修饰符，修改原函数的入口指向一个回调函数,回调函数内容包含被注入的代码和原函数的代码(即a所指向的程序)，保存原函数的代码是为了运行被注入的代码之后能够运行原函数的逻辑。这样原函数被调用时则会执行回调函数，原函数原有的运行逻辑或参数就被篡改了。
具体来说，例如：在dalvik运行模式下，首先通过拷贝当前函数相关信息保存到hookinfo实现原函数的备份，接着修改当前函数的method修饰符为acc_native(accessflags与0x00000100进行或运算),修改当前函数的nativefunc指向hook回调方法，以及替换当前函数的method->insns指向hookinfo，最后修正当前函数的registerssize及outssize；在art运行模式下，首先通过拷贝当前函数相关信息保存到hookinfo->original_method实现原函数的备份，接着修改当前函数的artmethod->access_flags_(与0x10000000进行或运算)，以标志此函数为被注入的函数，替换当前函数的entry_point_from_jni_指向hookinfo，修改entry_point_from_quick_compiled_code_指向hook回调函数,最后修改dex_code_item_offset_为0。
这种对android应用程序的动态注入篡改程序是无法被现有的基于静态文件检测的方法所检测的。
因此，本发明实施例提出了一种android应用程序防篡改的方法。参考图1来描述用于实现本发明实施例的一种android应用程序防篡改的方法100。
首先，在步骤s110，检测当前函数的第一标志是否为第一预定标志；
在步骤s120，比较所述当前函数的内存结构与原函数的内存结构，判断所述当前函数是否被篡改；
在步骤s130，如果所述当前函数被篡改，则将当前函数恢复为原函数。
根据本发明实施例，步骤110可以进一步地包括：第一标志包括当前函数的修饰符或access_flags访问标志；第一预定标志包括acc_native或被xposedhook。
在一个实施例中，在dalvik运行模式下，检测当前函数的修饰符是否为acc_native。
在另一个实施例中，在art运行模式下，检测当前函数的access_flags是否标识为被xposedhook。
根据本发明实施例，步骤120可以进一步地包括：所述比较所述当前函数的内存结构与原函数的内存结构包括：通过获取所述当前函数的xposedhookinfo，并将其转换为method结构，比较所述当前函数的method结构与所述原函数的method结构。
根据本发明实施例，步骤120还可以进一步地包括：所述判断所述当前函数是否被篡改包括：如果所述当前函数的method结构与原函数的method结构中除了修改过的值，其余的值都相同，则确定当前函数被注入代码。
在一个实施例中，参见图2，图2示出了用于实现根据本发明实施例的在dalvik运行模式下检测当前函数是否被篡改的示例的示意性流程图。具体来说：
在dalvik运行模式下，首先通过获取当前函数method(标识为curmethod)的insns即xposedhookinfo,将其转换为method结构(标识为originmethod)；
然后，比较所述当前函数中curmethod与originmethod的内存结构，如果除去修改过的值，其余的值都相同，就确定所述当前函数函数被xposed注入了代码。其中，修改过的值包括：method结构中的accessflags，以及nativefunc、insns、registerssize、outssize中的至少一个；其余的值包括：clazz、methodindex、name、shorty中的至少一个。
在另一个实施例中，参见图3，图3示出了用于实现根据本发明实施例的在art运行模式下检测当前函数是否被篡改的示例的示意性流程图。具体来说：
在art运行模式下，首先通过获取当前函数method(标识为curmethod)的entry_point_from_jni_即xposedhookinfo，将hookinfo->original_mathod转换为artmethod结构(标识为originmethod)。
然后，比较所述当前函数中curmethod与originmethod的内存结构，如果除去修改过的值之外，其余的值都一样，就可以判断该函数被xposed注入了代码。其中，修改过的值包括：artmethod类结构中的access_flags_，以及entry_point_from_jni_、entry_point_from_quick_compiled_code_、dex_code_item_offset_中的至少一个；其余的值包括：declaring_class_、dex_method_index_、method_index_中的至少一个。
根据本发明实施例，步骤230可以进一步地包括：将检测到被篡改的当前函数的内存空间替换为备份的原函数内存空间。
在一个实施例中，参见图4，图4示出了根据本发明实施例的在dalvik运行模式下恢复原函数的示例的示意性流程图。具体来说：在dalvik运行模式下，恢复当前函数method(标识为curmethod)为原函数originmethod的内容。
在另一个实施例中，参见图5，图5示出了实现根据本发明实施例的在art运行模式下恢复原函数的示例的示意性流程图。具体来说：在art运行模式下，恢复当前函数method(标识为curmethod)为原函数originmethod的内容。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
根据本发明实施例，还提供了一种android应用程序防篡改的系统，包括存储器、处理器及存储在所述存储器上且在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述方法的步骤。
此外，根据本发明实施例，还提供了一种计算机可读存储介质，在所述存储介质上存储了程序指令，在所述程序指令被计算机或处理器运行时用于执行本发明实施例的android应用程序防篡改方法的相应步骤。所述存储介质可以包括只读存储器，可擦除可编程只读存储器等各种存储器，或上述存储介质的任意组合。
根据本发明实施例的android应用程序防篡改方法、系统以及存储介质，基于内存检测的动态防篡改的检测方案，检测到恶意代码注入时进行即时反制，自动恢复成原始的程序，更加有效和准确地进行应用程序的自我保护，同时也保障用户的安全使用。
尽管这里已经参考附图描述了示例实施例，应理解上述示例实施例仅仅是示例性的，并且不意图将本发明的范围限制于此。本领域普通技术人员可以在其中进行各种改变和修改，而不偏离本发明的范围和精神。所有这些改变和修改意在被包括在所附权利要求所要求的本发明的范围之内。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
以上所述，仅为本发明的具体实施方式或对具体实施方式的说明，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。本发明的保护范围应以权利要求的保护范围为准。
android应用程序被恶意篡改，除了反编译修改静态代码再重打包的方式进行静态篡改，还包括动态篡改，即原始应用程序安装之后，对原有程序动态注入恶意代码，在程序运行过程中改变程序的运行路径及运行参数。现有的应用程序防篡改的方法一般是基于安装包的静态文件校验，如对应用程序的存储文件进行校验生成验证文件再打包到安装包中的方法，或通过对apk进行解压修改classes.dex执行文件重新打包的方法。这种基于静态文件校验的方法的不足之处在于无法检测程序被动态篡改的情况，例如程序被动态注入恶意代码，基于静态文件的检测方法就并无法检测出程序被篡改。这些恶意行为可能造成用户隐私被窃取、被远程操控等安全问题。
因此，现有技术中存在无法检测动态注入的恶意代码，以及应用程序安全性低的问题。
‘叁’ Android项目里如何混淆自己打的jar包或者防止被反编译
Android之防止反编译技巧：
1. 判断程序是否运行在模拟器上
boolean isRunningInEmualtor() {
boolean qemuKernel = false;
Process process = null;
DataOutputStream os = null;
try{
process = Runtime.getRuntime().exec("getprop ro.kernel.qemu");
os = new DataOutputStream(process.getOutputStream());
BufferedReader in = new BufferedReader(new InputStreamReader(process.getInputStream(),"GBK"));
os.writeBytes("exit\n");
os.flush();
process.waitFor();
// getprop ro.kernel.qemu == 1 在模拟器
// getprop ro.proct.model == "sdk" 在模拟器
// getprop ro.build.tags == "test-keys" 在模拟器
qemuKernel = (Integer.valueOf(in.readLine()) == 1);
Log.d("com.droider.checkqemu", "检测到模拟器:" + qemuKernel);
} catch (Exception e){
qemuKernel = false;
Log.d("com.droider.checkqemu", "run failed" + e.getMessage());
} finally {
try{
if (os != null) {
os.close();
}
process.destroy();
} catch (Exception e) {
}
Log.d("com.droider.checkqemu", "run finally");
}
return qemuKernel;
}
2. 检测keystore签名，再与之前得做比较
public int getSignature(String packageName) {
PackageManager pm = this.getPackageManager();
PackageInfo pi = null;
int sig = 0;
try {
pi = pm.getPackageInfo(packageName, PackageManager.GET_SIGNATURES);
Signature[] s = pi.signatures;
sig = s[0].hashCode();
} catch (Exception e1) {
sig = 0;
e1.printStackTrace();
}
return sig;
}
3. 检测包名，版本名和版本号，然后做判断：
private String getAppInfo() {
try {
String pkName = this.getPackageName();
String versionName = this.getPackageManager().getPackageInfo(
pkName, 0).versionName;
int versionCode = this.getPackageManager()
.getPackageInfo(pkName, 0).versionCode;
return pkName + " " + versionName + " " + versionCode;
} catch (Exception e) {
}
return null;
}
4. 把jpg图片写成是png格式得图片 但是最新版本的apktool已经修复了
5. 花指令，影响jd－gui 但是最新版本的jd－gui已经修复
private static final char[] wJ = "0123456789abcdef".toCharArray();
public static String imsi = "204046330839890";
public static String p = "0";
public static String keyword = "电话";
public static String tranlateKeyword = "%E7%94%B5%E8%AF%9D";
在每个类里面加入 如上字段。。。。
https://***/ 一个第三方得”爱加密“网站 1.需要使用官方的打包key工具打包后上传到"爱加密"网站进行处理,然后到网站上面下载,下载后还要用"爱加密"的打包工具再次进行打包即可。
‘肆’ Android APP的破解技术有哪些如何防止反编译
防止反编译的最好办法，
就是使用自己编写的apk打包工具，
不要用派羡“通用”的粗饥打包岩羡返工具。
‘伍’ Android APP的破解技术有哪些如何防止反编译
由于Android系统的开放性，导致Android
APK很容易被他人破解或是反编译，下面给大家介绍常用的APP破解工具和技术要求。同时根据自己以往的防破解经验，跟大家分析下如何防止反编译。
Android
APK运行环境依赖的文件/文件夹
res、DEX、主配文件Lib
只是简单的加密甚至没有任何保护措施。APKtool（一种反编译工具）可轻易将其轻松破解，再配合其他各种工具基本可以做到：源码暴露(代码混淆也几乎起不到任何安全作用)、资源文件裸奔、主配文件可任意修改、核心SO库暴露、暴力破解恶意利用等。部分大公司会对其应用APK包进行防二次打包和防APKtool破解，但其代码都是写在JAVA层，另外APKtool的可升级导致其安全保护级别也是非常低的。
‘陆’ 怎么让android studio的编译的aar防止反编译
1、 简述
在比较大的 Android 项目的开发中，我们经常会遇到工程、jar 包等等之间相互引用的方式。一般我们通过在 gradle 文件中配置依赖来解决
通用配置
Gradle 的一些基本依赖配置方式如下：
compile fileTree(dir: 'xxx', include: ['*.jar', "*.xxx"])：将某个目录下所有符合扩展名的文件作为依赖；
compile 'com.xx.xx:ProjectName:Version'：配置Maven` 库作为依赖；在 Maven 库中心 可以搜索自己想用的库进行依赖；
compile project(':AnotherMole')：配置另一个 Mole 作为本 Mole 的依赖，被依赖的 Mole 必须被导入到当前工程中；
compile files('xxx.jar')：配置某个 jar 包作为依赖。
看起来不错，基本通用的配置都已经存在了。一般对于中等小型的工程，这种开发方式完全没有问题。但是有时候 A 和 B 两个工程，想同时引用另一个公共的 Mole C，而这个 Mole 可能是一个比较复杂的 Android Mole，可能包含了一些主题、UI 、资源文件等等，这时候，如果用 Mole 依赖的方式来配置，不免有些困难，因为 A 和 B 都要导入 C，而且要随时关注 C 的更改。
好在 Android Studio 提供了 aar 库的打包方式，我们可以把 C 作为 library 进行打包，输出 aar 文件，然后在 A 和 B 中，配置 aar 库依赖，就可以解决。
2、aar 文件简介
要输出 aar 文件，必须将 Mole 配置为 library
输出 aar ： apply plugin: 'com.android.library'；
输出 apk ：apply plugin: 'com.android.application'。
将 Mole 配置为 library 后，构建输出一个 aar 文件，根据渠道和 BuildType 的不同，在相应的目录下可以找到。比如对 BuildType 为 debug 的配置，输出为：[MoleName]/build/outputs/aar/[MoleName]-debug.aar。一份 aar 文件其实就是一份 zip 包，和 jar 不同的是，它将一些资源文件、第三方库文件、so 文件等等都打包在内，而代码文件编译后压缩在在 classes.jar 中。
3、导入 aar 的方式引用
这种方式比较简单，打开 Project Structure，添加一个新 Mole，然后选择 Import *.JAR or *.AAR Package 的方式导入
导入后，在你的工程下面，会生成一个文件夹，里面是 aar 文件以及 Android Studio 的配置文件。
接着可以在 gradle 中配置依赖了，其他 Mole 可以引用这个 Mole 了，依赖方式使用 compile project 的方式即可。
缺点：被依赖的 aar 无法 F3 跟进去，无法看到资源文件内容以及目录层级等等缺陷。
4、使用配置依赖的方式引用
gradle 其实还有另一种依赖可以引用 aar：
compile(name: 'xxx', ext: 'aar')。
首先需要将 aar 文件放入引用 Mole 的 libs 目录下，和一般的 jar 文件类似。然后在 gradle 配置文件中把 libs 目录加入依赖：
repositories
flatDir {
dirs 'libs'
}
}
接着在 gradle 的依赖配置中加入 compile(name: 'xxx', ext: 'aar') 这一句，依赖即可关联完毕。构建一下工程，在 Mole 的build/intermediates/exploded-aar 目录下，可以看到有一些临时文件生成
被导入 aar 生成的临时文件
Android Studio 安装反编译插件后，可以通过 F3 跟进到 class 文件里面，如果你有被依赖 Mole 的源代码的话，还可以 Attach Source 关联源代码查看。另外，可以很方便的查看 aar 中的资源文件。
另外，这种依赖方式更新 aar 后，生成的临时文件也会随之变动，不用担心改动不同步的问题。
‘柒’ 如何防止 Android App 被反编译后接口泄露
app反编译后防止接口泄露的方法，就是使用谷歌提供的混淆工具，将不要反编译的文件保留，其他的塌咐都进行混淆，这样之后反编译看到贺友的都是一些乱码，例如abc之类的禅衫槐。
‘捌’ android app怎么防止反编译
APK在PC上面就被看作一个压缩格式文件，在手机上面它就算一个可执行格式文件。两种格式对它的读取要求也有区别，所以说利用这个区别来实现伪加密。对PC端来讲伪加密的APK没法被解包无法被反编译，但是对android系统来说它完全不会影响正常的安装运行(对4.2以前的系统)。
伪加密的原理：读取APK的字节，找到连续4位字节标记为”P K 01 02”的后第5位字节，如果是0表示不加密，如果是1就表示加密（伪加密就强行改成1 反伪加密就是把1改成0就可以了）。
2
伪加密前和伪加密后的对比图如下：
伪加密前：
3
伪加密后：
END
使用第三方平台加密
步骤如下：
登录/注册→上传APK→等待系统加密→完成后下载APK→给APK签名→完成！
2
爱加密作为移动安全行业的第三方平台，为Android APP移动应用提供专业的加固保护方案，包括DEX文件保护、资源文件保护、XML主配文件保护、防二次打包保护、so文件保护、内存保护、高级混淆等，全方位保护Android App，防止被反编译、破解等，维护广大开发者朋友的切身利益！
‘玖’ 对安卓应用加密防apk反编译现在有不少讨论，哪些有效呢
现在的Android
APK防止破解和反编译的办法，都是用混淆代码和防二次打包的加密技术。不过这两样加密技术都已无用了！！！
对Android
APK的加密保护只有对DEX、RES、SO库等主要文件进行了保护，才能有效的防止破解和反编译。现在有很多的Android开发者都在使用爱加密APK源代码安全保护，听说效果不错！！！
‘拾’ Android APP的破解技术有哪些如何防止反编译
AndroidAPP破解主要依靠利用现有的各种工具，如下：1)APKtool2)dex2jar3)jd-gui4)签名工具防止反编译，介绍一种有效对抗native层代码分析的方法——代码混淆技术。代码混淆的学术定义如下：代码混淆（codeobfuscation）是指将计算机程序的代码，转换成一种功能上等价，所谓功能上的等价是指其在变换前后功能相同或相近。其解释如下：程序P经过混淆变换为P‘，若P没有结束或错误结束，那么P’也不能结束或错误结束；而且P‘程序的结果应与程序P具有相同的输出。否则P’不是P的有效的混淆。目前对于混淆的分类，普遍是以Collberg的理论为基础，分为布局混淆（layoutobfuscation）、数据混淆（dataobfuscation）、控制混淆（controlobfuscation）和预防混淆（preventiveobfuscation）这四种类型。腾讯御安全保护方案提供了以上所述四种混淆分类的多维度的保护，布局混淆方面，御安全提供了针对native代码层中的函数名进行了混淆删除调试信息等功能；数据混淆方面，御安全提供了针对常量字符串加密及全局变量的混淆的功能；控制混淆方面，御安全针对代码流程上，提供了扁平化，插入bogus分支以及代码等价变换等功能；预防混淆方面，御安全在混淆过程中加入了针对主流反编译器的预防混淆的代码，能够有效地抵抗其分析。御安全还对应用开发者提供不同等级的保护力度及多种混淆方式的功能的选择，用户可以根据自己的需求定制不同的混淆功能保护。同时，御安全保护方案除了提供代码混淆保护方面的技术，还提供代码虚拟化技术及反逆向、反调试等其他安全保护方案，综合使用多种保护方案可以有效地提高代码安全。