动态加载与插件化 - CSDN博客
动态加载与插件化
插件化备忘
一、& 概述
　　当一个软件项目开发结束并交互使用后，需要添加一些新的功能，我们通常希望在不修改原有的应用程序情况下，将新添加的功能植入到系统中，这就是所谓的插件化，新增加的功能模块就叫插件。插件化能大大的降低模块间的耦合性，有利于各模块的独立维护，加快项目的维护更新。这里记录了下，主流的集中语言，实现插件化的方法。
二、& Java、Net和c/c++ 动态加载方式
　　Java的动态加载主要是靠classloader实现的.顾名思义，ClassLoader就是用来Load Class的，当一个Class被加载的时候，这个Class所引用到的所有Class也会被加载，而且这种加载是递归的，也就是说，如果A引用到B，B 引用到C，那么当A被加载的时候，B也会被加载，而B被加载的时候，C也会加载。如此递归直到所有需要的Class都加载好。特别注意ClassLoader双亲委派机制：ClassLoader总是先请求其父ClassLoader查找Class在自身查找Class。具体参考：
所以可以实现ClassLoader来实现Class的动态加载，不过java已经提供了现成的ClassLoader实现类：URLClassLoader可以加载URL所指定的jar。
有一个plugin.jar里面有一个实现IPlugin接口的类com.test.TestPlugin
ClassLoader loader = new URLClassLoader(new URL[]{new URL(&file://jar路劲\plugin.jar&)});
Class&?& pluginCls = loader.loadClass(&com.test.TestPlugin&);
IPlugin plugin = (IPlugin)pluginCls. newInstance();
plugin.load();
PS：这只是范例代码还有很多注意点，比如jar中不能包含IPlugin接口，确保URLClassLoader的parent中包含IPlugin。如何导出jar，就不叙述了。上诉就是java的动态加载，在这基础上添加插件管理，版本控制（如在zip文件结构中打入插件信息，在android那块会具体说明）。
　　Net的代码是以exe与dll的组织形式发布的，而我们常用的插件加载形式为exe和dll。果开发进程级别的插件可以考虑以exe的形式组织插件（java也一样），你可以以创建，终止进程的方式，随意加载，卸载所需插件。不过这种方式要多考虑多进程通信方面的问题，这里不讨论这种形式，主要关注进程内dll形式的插件实现使用的方法。先看下net的一些基本概念，如应用程序域，程序集。
应用程序域：
　　应用程序域是一种边界，它由围绕同一应用程序范围内创建的对象建立（即，从应用程序开始，沿着对象激活的序列的任何位置）。应用程序域有助于将在一个应用程序中创建的对象与在其他应用程序中创建的对象隔离，以使运行时行为可以预知。在一个单独的进程中可以存在多个应用程序域。在net中加载到应用程序域中的dll是不能卸载，我们可以每次创建一个新的应用程序域加载dll，完成逻辑后卸载这个应用程序域。
应用程序集：
　　一个.NET应用程序可以由多个程序集拼装而成的。程序集，简单来说，就是一个以（CLR）为宿主的、版本化的、自描述的二进制文件。尽管显示中.NET程序集和以往Win32二进制文件（包括遗留的COM服务对象）的（*.exe或*.dll）完全相同，但是两者的内部构成几乎完全不同。程序集可以促进代码重用、确定类型边界、可版本化的单元、自描述的、可配置的。
Net主要靠Assembly实现dll的动态加载， Assembly由多个加载dll的static方法，这边只关注加载指定路径下dll的方法LoadFile
有一个plugin.dll 里面有一个实现IPlugin接口的类Test.Plugins.TestPlugin
Assembly assembly = Assembly.LoadFile(&dll的路径\plugin.dll&);
Type type = Assembly.GetType(&Test.Plugins.TestPlugin&);
IPlugin plugin = Activator. CreateInstance(type) as IP
plugin.Load();
PS：如果单纯这样加载的dll实在默认的应用程序域，无法被卸载的，如果需要卸载dll可以新建一个应用程序域去加载，不用时卸载这个应用程序域。
3. c/c++
　　c/c++就没有标准的动态加载的实现方式了，依平台而定这边记录了下Liunx与windows。程序有两种链接方式，一种是静态链接，一种是动态链接。了解c/c++的动态加载前，先看下这两个概念。
　　所谓静态链接就是在编译链接时直接将需要的执行代码拷贝到调用处，优点就是在程序发布的时候就不需要的依赖库，也就是不再需要带着库一块发布，程序可以独立执行，但是体积可能会相对大一些。（所谓库就是一些功能代码经过编译连接后的可执行形式。）
　　所谓动态链接就是在编译的时候不直接拷贝可执行代码，而是通过记录一系列符号和参数，在程序运行或加载时将这些信息传递给操作系统，操作系统负责将需要的动态库加载到内存中，然后程序在运行到指定的代码时，去共享执行内存中已经加载的动态库可执行代码，最终达到运行时连接的目的。优点是多个程序可以共享同一段代码，而不需要在磁盘上存储多个拷贝，缺点是由于是运行时加载，可能会影响程序的前期执行性能。
　　Windows下是以dll形式的（和net的dll有一定的区别），而liunx则是以so的形式。虽然Windows和Liunx的API有一点差异，但是大体的机制还是一致。都是分加载动态链接库，查找指定符号地址，调用指定过程，完成释放动态链接库。
　　下面先来看下windows的，windows提供了多个API来实现动态加载动态链接库和调用里面的方法。
　　LoadLibrary&加载指定的动态链接库获得对应的模块句柄（还有其他高级版本）
　　GetProcAddress&按照指定的符号名称在加载的动态链接库中查找函数地址
　　FreeLibrary&释放加载的动态链接库
　　有一个动态链接库plugin.dll,里面有一个插件接口IPlugin、一个插件实现类TestPlugin和一个导出函数int CreatePlugin(IPlugin** outPlugin)
typedef int (*CreatePlugin)(IPlugin** outPlugin);
HMODULE handle = LoadLibrary(L&dll所在目录\plugin.dll&);
if (handle == nullptr)
printf_s(&load dll fail&);
return -1;
CreatePlugin create = (CreatePlugin)GetProcAddress(handle, &CreatePlugin&);
if (create == nullptr)
printf_s(&get proc address fail&);
return -1;
IPlugin* plugin =
Int res = create(&plugin);
if (res!=0 || plugin == nullptr)
printf_s(&load plugin fail&);
return -1;
plugin-&Load();
FreeLibrary(handle);
PS：一般dll都是导出函数，所以都是先导出指定函数，作为创建导出类的入口点，后续类的创建都依赖这个入口点。Dll如何实现函数如何导出这里就不说了。
说完windows我们在看下liunx，其实和加载调用过程和windows差不多的，liunx提供了：
dlopen 按指定模式加载指定路径下的动态库。
dlsym按照指定的符号名称在加载的动态链接库中查找函数地址
dlclose 关闭释放动态链接库
和windows一样的情况，有一个动态链接库plugin.so,里面有一个插件接口IPlugin、一个插件实现类TestPlugin和一个导出函数int CreatePlugin(IPlugin** outPlugin)
typedef int (*CreatePlugin)(IPlugin** outPlugin);
void* handle = dlopen(&so所在目录/plugin.so&, RTLD_LAZY);
if (handle ==NULL)
printf(&load dll fail&);
return -1;
CreatePlugin create = (CreatePlugin)dlsym(handle, &CreatePlugin&);
if (create == NULL)
printf(&get proc sym fail&);
return -1;
IPlugin* plugin = NULL;
Int res = create(&plugin);
if (res!=0 || plugin == NULL)
printf(&load plugin fail&);
return -1;
plugin-&Load();
dlclose(handle);
PS:liunx和windows动态加载动态库的流程还是很相似的，但是由于平台的差异，中间还是有许多细节需要注意的，这边只记录大体的流程，细节后续的在讨论。
三、&&&& Android与Windows Phone插件化
Android插件化
　　看完上面这些，我们再来看看，两个移动平台的情况，首先看下android，由于android的上层开发一般性基于java（那些游戏引擎暂时除外），所以动态加载和java还是基本上一样的，但是由于Dalvik与java虚拟机的差异，实质还是有一些差距，流程上大致是一致。
　　Dalvik虚拟机和java虚拟机的差异致使，无法直接加载class文件，必须将class转化为dex，Dalvik才能去加载。所以在开发插件的步骤上我们要多一步jar到dex的转化。在动态加载的api上，android提供两个加载dex的类DexClassLoader和PathClassLoader。
　　DexClassLoader顾名思义就是加载Dex的ClassLoader,它可以加载dex文件或包含dex的jar和apk（dex必须是classes.dex这样命名并在根目录下），但是实际使用时发现有些机型无法加载直接dex形式，所以使用时建议用jar或apk形式。
　　PathClassLoader看名字可能认为它就是加载指定路径下的模块，实际上PathClassLoader加载的路径已经被限定死，只能加载/data/app路径下的dex。所以一般情况下，都是使用DexClassLoader实现插件机制。
有一个plugin.jar里面有一个实现IPlugin接口的类com.test.TestPlugin
ClassLoader loader = (IPlugin) new DexClassLoader(&jar所在的目录/plugin.jar&,&dextop目录&,&so的查找目录&,父ClassLoader);
Class&?& pluginCls = loader.loadClass(&com.test.TestPlugin&);
IPlugin plugin = (IPlugin)pluginCls. newInstance();
plugin.load();
　　到这里android初步的插件化是可以实现了，可是在使用的时候，会发现这样插件化，无法支持android的res机制，每次实现插件里面的UI只能靠code实现，真心不是一般的烦。那接下我来看下，有什么办法能将res也集成到插件里面。
　　首先我们先分析下，无法使用res的原因，android项目在编译的时候会res进行一次编译，对资源进行优化，并为每一个res下的资源都生成一个对应的id。在使用的时候靠这个id在运行时android会靠这个id和资源映射表arsc找到相应资源，所这样造成我们在开发插件时，及时把res放到jar，android也无法按照id找到对应资源。这里的关键是Resource对象，在应用的那个Resource里面是找不到插件内带的那些资源的，所以如果我们能构造一个和插件里面res关联的Resource，那么利用这个Resource(其实还包括Theme)我们就能顺利访问到插件里的资源。
那如何创建插件的Resources呢，这里有两个方法：
　　1.直接构造Resources我们可以看下Resources的定义可以发现它有这么一个构造Resources(AssetManager, DisplayMetrics, Configuration)这里可以看出创建Resources所需要的三个参数，先看下后面两个参数这两个参数一个和显示分辨率相关一个是单纯的配置，自然我们可以直接使用app的Resources里的这两个参数，那么AssetManager呢，这个就与资源相关了，显然我们要创建一个与插件的资源相关联的的AssetManager,那我们在看下AssetManager的定义可以发现一个主要的方法addAssetPath(String)，看它的实现，这个String应该是对应资源所在的apk路径（即插件位置）这样我们就能构建一个自己的AssetManager了。
　　现在三个参数都全了，是不是可以构建出插件的Resources了，拿到这个Resources我们就能访问里面的大部分资源了，对了时大部分资源，不是全部，这个后续会说明的，接下来先讲下下一个方法。
　　2.通过某个方法直接加在apk获得这个apk的Context，那样我能就能拿到所有与这个Context相关的资源。这里我们可以观察activity的启动过程，可以发现当某个apk中的组件第一被加载的时候都会去查找这个组件所在的Application是否已经被创建，如果没有被创建都会，先加载apk创建Application，这里android以Package Name为标识查找Application，查看这部分源码我们会发现Application是由LoadedApk创建的，而LoadedApk是从ActivityThread的getPackageInfo开头的几个方法里，再仔细浏览的话，发现有个getPackageInfoNoCheck方法，需要获得一个applicationinfo为参数（还有别的参数，这个4以下与以上不同），于似乎我们只要拿到Apk的ApplicationInfo就能创建Application并获得Resources，实际上也很接近了。
　　但是是还有些问题要解决，如果我们直接PackageManager().getPackageArchiveInfo获得PackageInfo获得里面的ApplicationInfo，进行上述操作，会坑爹发现报了个某某路劲没有访问权限的错误，这是由于LoadedApk在makeApplication时候，需要加载apk里的dex，这时所指定的dexopt路径是应用是没有权限访问。是不是感觉到这里就坑了，只能默默的回去继续看源码，看着这茫茫的代码晕了一段时间后，会发现LoadedApk在创建加载dex前会判断mClassLoader是不是为null，如果不是就不会去加载dex，现在好了我们只要自己去加载dex，再通过反射去设置mClassLoader这一步就过了。
　　再拿到这个Application后，其实我们基本是用它的Resources，而不是直接用这个Application去创建View，由于这个Application是未安装的，如果你用这个Application创建EditText它去访问剪切板服务就GameOver了。
Windows Phone
　　过完android，再来看下Windows Phone，由于Windows Phone生态系统的性质，微软为了杜绝未经审核的应用在商店上线，防止恶意的程序对Windows Phone的破坏，动态加载这部分API是被严格限制的。
　　先来看下Windows Phone 下的net，实际上和PC上的net一样也是由Assembly的Load方法进行动态加载，不过Windows Phone公开了一个带AssemblyName参数的重载，只能加载应用安装目录和GAC下的DLL流程上和net基本没差。
　　再看下Windows Phone下的win32 API，Windows Phone的win32有公开动态加载动态库的API但是也和net一样做了限制LoadLibrary被LoadPackagedLibrary取代，只能加载安装目录下的动态库，而另外两个API与PC的一致。
　　到这里可以发现微软已经隐藏了所有可以加载外部代码的API，那就没办法加载外部的代码了吗，如果我们去查看Windows Phone的System32下的dll会发现，其实答案是否定的，还是有办法加载的，虽然说微软只公开的LoadPackagedLibrary，但是LoadLibrary还是存在的，这里我们就看看怎么去访问这个未公开的LoadLibrary。
在这之前我们先看几个和后续操作有关的结构体
//线程环境块
typedef struct _TEB
//BYTE fill[0x30]; x86
NT_TIB nt_
PVOID EnvironmentP
PVOID ActiveRpcH
PVOID ThreadLocalStorageP
PEB* currentPEB;
//进程环境块
typedef struct _PEB
BYTE fill[0x0c]; x86
BYTE Reserved1[2];
BYTE BeingD
BYTE Reserved2[1];
PVOID Reserved3[2];
PEB_LDR_DATA*
//进程加载的模块信息
typedef struct _PEB_LDR_DATA
BYTE fill[0x1c]; x86
LIST_ENTRY InLoadOrderModuleL
LIST_ENTRY InMemoryOrderModuleL
MODULE_LIST_ENTRY* initModuleL
}PEB_LDR_DATA;
//模块链表实体
typedef struct _MODULE_LIST_ENTRY
_MODULE_LIST_ENTRY* F
_MODULE_LIST_ENTRY* B
DWORD* baseA
}MODULE_LIST_ENTRY;
在这几个结构体里面就包含了我要找的LoadLibrary所在的模块句柄，既PEB的ldr这个链表里面。所以只要我们能获得PEB就能在ldr里面找的已经加载的模块，那怎么获得PEB，看TEB我们可以发现TEB里面包含PEB那又变成获得TEB，而获得TEB的API是公开的NtCurrentTeb，有了这个就好办了
HMODULE NativeInterop::getKernelModule()
TEB* teb = NtCurrentTeb();
return (HMODULE) teb-&currentPEB-&ldr-&initModuleList-&Flink-&baseA
这样就获取到LoadLibrary的所在模块的句柄了，不过这是默认这个模块加载顺序确定的情况下，所以建议在加载模块名称的判断来确定模块位置。
本文已收录于以下专栏：
相关文章推荐
如有转载，请声明出处: 时之沙: http://blog.csdn.net/t12x;   （来自时之沙的csdn博客）
概述: 
        ...
开发中经常能听到动态加载，插件化，热部署等词，动态加载到底是何方神物，它能实现什么功能，实现原理又如何？动态加载和插件化、热部署又有着什么样的联系呢？下面我们一起来学习吧。1. 基本知识1.1 动态加...
概述: 
        随着应用的不断迭代，应用的体积不断增大,项目越来越臃肿,冗余增加.项目新功能的添加，无法确定与用户匹配性，发生严重异常往往牵一发而动全身,只能紧急发布补丁版本，强制...
上一篇博客中http://blog.csdn.net/lxping51/article/details/，主要通过反射的方式来实现动态加载插件化，今天我们以接口的方式来达到目的。接口的...
前段时间，公司项目完成了插件化的开发，自己也因此学习了很多Android插件化的知识，于是想把这些内容记录下来，本次带来Android插件化的第一篇：动态加载综述Android插件化学习之路（一）之动...
Android插件化之资源动态加载
Android插件化的一个重要问题就是插件资源访问问题，先列出会面对的问题
1.如何加载插件资源
2.如何处理插件资源与宿主资源的处突：插件化资源...
引言上篇文章我们有提到过ClassLoader类加载器，通过学习了解到系统提供的类加载器有* PathClassLoader*和* DexClassLoader*两种。它们的不同之处是：
Android插件化（一）：使用改进的MultiDex动态加载assets中的apk
为了解决65535方法数超标的问题，Google推荐使用MultiDex来加载classes2.dex...
他的最新文章
讲师：吴岸城
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)下次自动登录
现在的位置:
& 综合 & 正文
android 移植ffmpeg后so库的使用
今天折腾了一天，可算是有所收获，成功的用jni调用了libffmpeg中的一个方法-----avcodec_version()，至于avcodec_version()是干什么用的我不大清楚，应该是获取版本信息吧，没有深入的去研究ffmpeg。
这里主要是想把折腾一天所获取的经验记录下来，以免时间长全忘了，也希望能给其他人一点借鉴，不至于和我一样一点头绪都没有连猜带蒙的，本文纯属个人心得，高手可以无视....
要在android上用ffmpeg首先得奖ffmpeg工程移植到android上，这里就要用到ndk把这个开源工程编译成一个后缀为so的库，这个步骤这里就不多说了 网上的资料也挺多的，我是按照:在ubantu环境下编译的，你按照教程上一步一步来应该都没有问题，顺便给下在windows下编译ffmpeg的教程：（这个要用非ie浏览器打开）。以上两篇文章给了我很大的指引，在此谢过。。。都是牛人啊~~~
编译完以后你会获得一个libffmpeg.so的文件，那么问题来了，怎么用呢。我在百度，google搜了半天也没有一个详细的教程，总是东一句西一句的，但思路是明确的，就是还得编译一个so文件，这个so里的是jni方法，可以由java层调用的，而这些jni方法里用到的函数则就是来至libffmpeg.so了。思路是有了，但是具体怎么做呢？又经过一顿摸索，n次的编译，终于编译成功了。我是拿一个标准的ndk例子来做的测试就是ndk samples文件夹里的hello-jni工程。进入该工程的jni目录，将ffmpeg的源代码拷到该目录下，做这部的原因是你要编译的so文件里需要调用ffmpeg的方法，自然要引用ffmpeg里的h文件，然后将libffmpeg.so文件拷到ndk目录下的platforms/android-5/arch-arm/usr/lib目录下(你会发现platfroms里有好几个android文件夹如
-3 -4 -5分别代表不同的版本，以防万一我每个目录都拷了，呵呵，应该是只要拷指定目录的)，因为等等系统编译的时候要用。接下来就编辑android.mk和hello-jni.c文件了 代码如下
# Copyright (C) 2009 The Android Open Source Project
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
PATH_TO_FFMPEG_SOURCE:=$(LOCAL_PATH)/ffmpeg
LOCAL_C_INCLUDES += $(PATH_TO_FFMPEG_SOURCE)
LOCAL_LDLIBS := -lffmpeg
LOCAL_MODULE
:= hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
PATH_TO_FFMPEG_SOURCE:=$(LOCAL_PATH)/ffmpeg
这行是定义一个变量，也就是ffmpeg源码的路径
LOCAL_C_INCLUDES += $(PATH_TO_FFMPEG_SOURCE)
这行是指定源代码的路径，也就是刚才拷过去的ffmpeg源码，$(LOCAL_PATH)是根目录，如果没有加这行那么引入ffmpeg库中的h文件编译就会出错说找不到该h文件。
LOCAL_LDLIBS := -lffmpeg
这行很重要，这是表示你这个so运行的时候依赖于libffmpeg.so这个库， 再举个例子：如果你要编译的so不仅要用到libffmpeg.so这个库还要用的libopencv.so这个库的话，你这个参数就应该写成
LOCAL_LDLIBS := -lffmpeg -lopencv
其他的参数都是正常的ndk编译用的了，不明白的话google一下。
* Copyright (C) 2009 The Android Open Source Project
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
#include &string.h&
#include &stdio.h&
#include &android/log.h&
#include &stdlib.h&
#include &jni.h&
#include &ffmpeg/libavcodec/avcodec.h&
/* This is a trivial JNI example where we use a native method
* to return a new VM String. See the corresponding Java source
* file located at:
apps/samples/hello-jni/project/src/com/example/HelloJni/HelloJni.java
Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
jobject thiz )
char str[25];
sprintf(str, "%d", avcodec_version());
return (*env)-&NewStringUTF(env, str);
#include &ffmpeg/libavcodec/avcodec.h&
这行是因为下面要用到avcodec_version()这个函数。
改完这两个文件以后就可以编译了~~用ndk-build命令编译完后在工程的libs/armeabi目录底下就会有一个libhello-jni.so文件了！（两行眼泪啊~终于编译成功了）
编译完成后就可以进行测试了，记得将libffmpeg.so也拷到armeabi目录底下，并在java代码中写上
System.loadLibrary("ffmpeg");
System.loadLibrary("hello-jni");
* Copyright (C) 2009 The Android Open Source Project
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
package com.example.
import android.app.A
import android.widget.TextV
import android.os.B
public class HelloJni extends Activity
/** Called when the activity is first created. */
public void onCreate(Bundle savedInstanceState)
super.onCreate(savedInstanceState);
/* Create a TextView and set its content.
* the text is retrieved by calling a native
* function.
tv = new TextView(this);
tv.setText( "1111" );
//System.out.println();
setContentView(tv);
tv.setText(String.valueOf(stringFromJNI()));
/* A native method that is implemented by the
* 'hello-jni' native library, which is packaged
* with this application.
public native String
stringFromJNI();
/* This is another native method declaration that is *not*
* implemented by 'hello-jni'. This is simply to show that
* you can declare as many native methods in your Java code
* as you want, their implementation is searched in the
* currently loaded native libraries only the first time
* you call them.
* Trying to call this function will result in a
* java.lang.UnsatisfiedLinkError exception !
public native String
unimplementedStringFromJNI();
/* this is used to load the 'hello-jni' library on application
* startup. The library has already been unpacked into
* /data/data/com.example.HelloJni/lib/libhello-jni.so at
* installation time by the package manager.
System.loadLibrary("ffmpeg");
System.loadLibrary("hello-jni");
到此就完成了，将程序装到手机可看到打印出“3426306”，google搜索“ffmpeg 3426306”得知果然是ffmpeg的东西，证明成功的调用了libffmpeg.so库里的方法了。欣慰啊~~
接下来要做的就是学习ffmpeg库里的各种函数的使用方法，以实现自己想要的功能了。
&&&&推荐文章:
【上篇】【下篇】