文件共享方法及装置与流程

本发明属于信息技术领域，尤其涉及一种文件共享方法及装置。

背景技术：

现有的不同应用程序(APP，Application)之间的文件共享，通过将文件保存在SD卡的sdcard/下的目录，或者保存至都可以访问到的路径下，以此实现文件数据的共享。

在发明人实现本方案的过程中，发现在上述文件保存的方案中至少存在以下问题：虽然按照上述方案可以实现文件数据的共享，但是带来了如文件容易被用户误删除，写入和读取文件时都需要相应的权限等问题。

技术实现要素：

本发明实施例的目的在于提供一种文件共享方法及装置，旨在解决现有文件共享方案中出现如文件容易被用户误删除，写入和读取文件时都需要相应的权限的问题。

第一方面，本发明实施例提供一种文件共享方法，包括：

将第一应用的待共享文件保存在所述第一应用的预置目录下；

建立contentprovider的继承类，并重写建立的类中的openFile方法；

为建立的类定义统一资源标识符；

第一应用将所述预置目录下的所述待共享文件读取为输入输出流；

第二应用通过所述统一资源标识符获取所述输入输出流，以获取所述待共享文件。

第二方面，本发明实施例提供一种文件共享装置，包括：

文件保存单元，用于将第一应用的待共享文件保存在所述第一应用的预置目录下；

类建立单元，用于建立contentprovider的继承类，并重写建立的类中的openFile方法；

标识定义单元，用于为建立的类定义统一资源标识符；

第一应用单元，用于将所述预置目录下的所述待共享文件读取为输入输出流；

第二应用单元，用于通过所述统一资源标识符获取所述输入输出流，以获取所述待共享文件。

在本发明实施例中，通过将第一应用的待共享文件保存至该第一应用的预置目录下，避免了写入文件时所需的权限问题，使用户无法删除该与之目录下的待共享文件，同时通过建立contentprovider的继承类，并重写建立的类中的openFile方法，以使第一应用能够读取自身预置目录下的待共享文件，并将其读取成输入输出流(IO流)，其他应用程序就可以通过URI来获取IO流，以获取该待共享文件。本实施例通过上述步骤，能够避开SD卡的读取权限，同时避免了用户因为误操作导致待共享文件被删除的问题。

附图说明

图1是本发明第一实施例提供的文件共享方法的实现流程图；

图2是本发明第二实施例提供的文件共享方法的实现流程图；

图3是本发明第三实施例提供的文件共享方法的实现流程图；

图4是本发明第四实施例提供的文件共享方法的实现流程图；

图5是本发明第五实施例提供的文件共享方法的实现流程图；

图6是本发明第六及第七实施例提供的文件共享装置的结构示意图；

图7是本发明实施例提供的文件共享方法的电子设备结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

请参见图1，图1示出了本发明提供的第一实施例，一种文件共享方法，包括：

S101，将第一应用的待共享文件保存在所述第一应用的预置目录下。

在本步骤，文件共享装置在检测到第一应用的待共享文件后，将第一应用的待共享文件保存至该第一应用的预置目录下。

具体地，目前用户使用移动终端或者电脑端安装各式应用程序(APP，Application)，每一APP在使用过程中均会按照该APP预置的保存路径保存产生的文件。以操作系统为安卓(Android)系统的移动终端为例，移动终端在安装了某APP后，该APP的在使用过程中产生的文件将按照该APP预置的保存规则保存至不同的目录中。为避免文件共享装置在保存文件时需要SD卡保存的权限问题，本实施例中，文件共享装置将每一APP待保存文件保存在该APP的预置目录下，以避免待保存文件写入时所需SD卡写入的权限问题，同时也保证用户在使用过程中无法删除该预置目录下的文件。

S102，建立contentprovider的继承类，并重写建立的类中的openFile方法。

在本步骤中，文件共享装置将建立contentprovider的继承类，在建立了contentprovider的继承类后，将重写建立的类中的openFile方法。

具体地，安卓系统(Android)提供了ContentProvider，ContentProvider为存储和获取数据提供统一的接口，可以在不同的应用程序(APP)之间共享数据。实际应用中，Android已经为常见的一些数据提供了默认的ContentProvider。Android内置的许多数据都是使用ContentProvider形式，供开发者调用的(如视频，音频，图片，通讯录等)。当应用程序(APP)继承ContentProvider类，并重写该类用于提供数据和存储数据的方法，就可以向其他应用程序(APP)共享其数据。创建一个继承自ContentProvider的类后，将重写建立的类中的insert、delete、query、update、getType、onCreate方法，在这些方法中实现对数据源的操作。本步骤中，建立contentprovider的继承类后，文件共享装置重写建立的类中的openFile方法。

虽然使用其他方法也可以对外共享数据，但数据访问方式会因数据存储的方式而不同，如：采用文件方式对外共享数据，需要进行文件操作读写数据；采用sharedpreferences共享数据，需要使用sharedpreferences API读写数据。而使用ContentProvider共享数据的好处是统一了数据访问方式。

S103，为建立的类定义统一资源标识符。

在本步骤中，文件共享装置将为建立的类定义统一资源标识符。具体地，文件共享装置使用URI来定义建立的类。URI(Uniform Resource Identifier，统一资源标识符)是一个用于标识某一互联网资源名称的字符串。该种标识允许用户对任何(包括本地和互联网)的资源通过特定的协议进行交互操作。

S104，第一应用将所述预置目录下的所述待共享文件读取为输入输出流。

在本步骤中，第一应用将保存至预置目录的待共享文件读取为输入输出流(IO流，Input Output Stream)。

S105，第二应用通过所述统一资源标识符获取所述输入输出流，以获取所述待共享文件。

在本步骤中，当其他应用程序(APP)需要获取待共享文件时，可以通过同一资源标识符(URI)来获取第一应用的输入输出流(IO流)。

在本实施例中，文件共享装置通过将第一应用的待共享文件保存至该第一应用的预置目录下，避免了写入文件时所需SD卡写入的权限问题，使用户无法删除该预置目录下的待共享文件，同时通过建立contentprovider的继承类，并重写建立的类中的openFile方法，以使第一应用能够读取自身预置目录下的待共享文件，并将其读取成输入输出流，其他应用程序就可以通过URI来获取IO流，以获取该待共享文件。本实施例通过上述步骤，能够避免SD卡的读取权限，同时避免了用户因为误操作导致待共享文件被删除的问题。

请参见图2，图2是示出了本发明提供的第二实施例一种文件共享方法，包括：

S201，将第一应用的待共享文件保存在所述第一应用的预置目录下。

文件共享装置在检测到第一应用的待共享文件后，将第一应用的待共享文件保存至该第一应用的预置目录下。

具体地，目前用户使用移动终端或者电脑端安装各式应用程序(APP，Application)，每一APP在使用过程中均会按照该APP预置的保存路径保存产生的文件。以操作系统为安卓(Android)系统的移动终端为例，移动终端在安装了某APP后，该APP的在使用过程中产生的文件将按照该APP预置的保存规则保存至不同的目录中。为避免文件共享装置在保存文件时需要SD卡保存的权限问题，本实施例中，文件共享装置将每一APP待保存文件保存在该APP的预置目录下，以避免待保存文件写入时所需SD卡写入的权限问题，同时也保证用户在使用过程中无法删除该预置目录下的文件。

S202，建立contentprovider的继承类，并重写建立的类中的openFile方法。

在本步骤中，文件共享装置将建立contentprovider的继承类，在建立了contentprovider的继承类后，将重写建立的类中的openFile方法。

具体地，安卓系统(Android)提供了ContentProvider，ContentProvider为存储和获取数据提供统一的接口，可以在不同的应用程序(APP)之间共享数据。实际应用中，Android已经为常见的一些数据提供了默认的ContentProvider。Android内置的许多数据都是使用ContentProvider形式，供开发者调用的(如视频，音频，图片，通讯录等)。当应用程序(APP)继承ContentProvider类，并重写该类用于提供数据和存储数据的方法，就可以向其他应用程序(APP)共享其数据。创建一个继承自ContentProvider的类后，将重写建立的类中的insert、delete、query、update、getType、onCreate方法，在这些方法中实现对数据源的操作。本步骤中，建立contentprovider的继承类后，文件共享装置重写建立的类中的openFile方法。

S203，通过AndroidManifest.xml文件为所述建立的类，注册统一资源标识符中的内容提供者以及内容获取路径。

在本步骤中，文件共享装置通过AndroidManifest.xml配置文件为建立的类，注册统一资源标识符(URI)中的内容提供者和内容获取路径，并定义URI给其他应用程序。

S204，第一应用将所述预置目录下的所述待共享文件读取为输入输出流。

在本步骤中，第一应用将保存至预置目录的待共享文件读取为输入输出流(IO流，Input Output Stream)。

S205，第二应用通过所述统一资源标识符获取所述输入输出流，以获取所述待共享文件。

在本步骤中，当其他应用程序(APP)需要获取待共享文件时，可以通过同一资源标识符(URI)来获取第一应用的输入输出流(IO流)。

在本实施例中，文件共享装置通过将第一应用的待共享文件保存至该第一应用的预置目录下，避免了写入文件时所需SD卡写入的权限问题，使用户无法删除该预置目录下的待共享文件，同时通过建立contentprovider的继承类，并重写建立的类中的openFile方法，还通过AndroidManifest.xml配置文件为所述建立的类，注册统一资源标识符(URI)中的内容提供者以及内容获取路径，以使第一应用能够读取自身预置目录下的待共享文件，并将其读取成输入输出流，其他应用程序就可以通过URI来获取IO流，以获取该待共享文件。本实施例通过上述步骤，能够避免SD卡的读取权限，同时避免了用户因为误操作导致待共享文件被删除的问题。

请参见图3，图3是本发明第三实施例提供的文件共享方法，包括：

S301，将第一应用的待共享文件保存在所述第一应用的预置目录下。

文件共享装置在检测到第一应用的待共享文件后，将第一应用的待共享文件保存至该第一应用的预置目录下。

具体地，目前用户使用移动终端或者电脑端安装各式应用程序(APP，Application)，每一APP在使用过程中均会按照该APP预置的保存路径保存产生的文件。以操作系统为安卓(Android)系统的移动终端为例，移动终端在安装了某APP后，该APP的在使用过程中产生的文件将按照该APP预置的保存规则保存至不同的目录中。为避免文件共享装置在保存文件时需要SD卡保存的权限问题，本实施例中，文件共享装置将每一APP待保存文件保存在该APP的预置目录下，以避免待保存文件写入时所需SD卡写入的权限问题，同时也保证用户在使用过程中无法删除该预置目录下的文件。

S302，建立contentprovider的继承类，并重写建立的类中的openFile方法。

在本步骤中，文件共享装置将建立contentprovider的继承类，在建立了contentprovider的继承类后，将重写建立的类中的openFile方法。

具体地，安卓系统(Android)提供了ContentProvider，ContentProvider为存储和获取数据提供统一的接口，可以在不同的应用程序(APP)之间共享数据。实际应用中，Android已经为常见的一些数据提供了默认的ContentProvider。Android内置的许多数据都是使用ContentProvider形式，供开发者调用的(如视频，音频，图片，通讯录等)。当应用程序(APP)继承ContentProvider类，并重写该类用于提供数据和存储数据的方法，就可以向其他应用程序(APP)共享其数据。创建一个继承自ContentProvider的类后，将重写建立的类中的insert、delete、query、update、getType、onCreate方法，在这些方法中实现对数据源的操作。本步骤中，建立contentprovider的继承类后，文件共享装置重写建立的类中的openFile方法。

S303，为建立的类定义统一资源标识符。

在本步骤中，文件共享装置将为建立的类定义统一资源标识符。具体地，文件共享装置使用URI来定义建立的类。URI(Uniform Resource Identifier，统一资源标识符)是一个用于标识某一互联网资源名称的字符串。该种标识允许用户对任何(包括本地和互联网)的资源通过特定的协议进行交互操作。

S304，第一应用将所述预置目录下的所述待共享文件读取为输入输出流。

在本步骤中，第一应用将保存至预置目录的待共享文件读取为输入输出流(IO流，Input Output Stream)。

S305，通过ContentResolver解析所述统一资源标识符，并获取所述统一资源标识符指向的所述输入输出流，以获取所述待共享文件。

在本实施例中，文件共享装置通过将第一应用的待共享文件保存至该第一应用的预置目录下，避免了写入文件时所需SD卡写入的权限问题，使用户无法删除该预置目录下的待共享文件，同时通过建立contentprovider的继承类，并重写建立的类中的openFile方法，以使第一应用能够读取自身预置目录下的待共享文件，并将其读取成输入输出流，其他应用程序通过ContentResolver解析所述统一资源标识符，并获取所述统一资源标识符指向的所述输入输出流，以获取该待共享文件。本实施例通过上述步骤，能够避免SD卡的读取权限，同时避免了用户因为误操作导致待共享文件被删除的问题。

图4示出了本发明第四实施例提供的一种文件共享方法，包括：

S401，将第一应用的待共享文件保存在所述第一应用的date目录下。

文件共享装置在检测到第一应用的待共享文件后，将第一应用的待共享文件保存至该第一应用的data目录下。

具体地，目前用户使用移动终端或者电脑端安装各式应用程序(APP，Application)，每一APP在使用过程中均会按照该APP预置的保存路径保存产生的文件。以操作系统为安卓(Android)系统的移动终端为例，移动终端在安装了某APP后，该APP的在使用过程中产生的文件将按照该APP预置的保存规则保存至不同的目录中。为避免文件共享装置在保存文件时需要SD卡保存的权限问题，本实施例中，文件共享装置将每一APP待保存文件保存在该APP的data目录下，以避免待保存文件写入时所需SD卡写入的权限问题，同时也保证用户在使用过程中无法删除该data目录下的文件。

S402，建立contentprovider的继承类，并重写建立的类中的openFile方法。

在本步骤中，文件共享装置将建立contentprovider的继承类，在建立了contentprovider的继承类后，将重写建立的类中的openFile方法。

S403，为建立的类定义统一资源标识符。

在本步骤中，文件共享装置将为建立的类定义统一资源标识符。具体地，文件共享装置使用URI来定义建立的类。URI(Uniform Resource Identifier，统一资源标识符)是一个用于标识某一互联网资源名称的字符串。该种标识允许用户对任何(包括本地和互联网)的资源通过特定的协议进行交互操作。

S404，第一应用将所述预置目录下的所述待共享文件读取为输入输出流。

在本步骤中，第一应用将保存至预置目录的待共享文件读取为输入输出流(IO流，Input Output Stream)。

S405，第二应用通过所述统一资源标识符获取所述输入输出流，以获取所述待共享文件。

在本步骤中，当其他应用程序(APP)需要获取待共享文件时，可以通过同一资源标识符(URI)来获取第一应用的输入输出流(IO流)。

在本实施例中，文件共享装置通过将第一应用的待共享文件保存至该第一应用的data目录下，避免了写入文件时所需SD卡写入的权限问题，使用户无法删除该预置目录下的待共享文件，同时通过建立contentprovider的继承类，并重写建立的类中的openFile方法，以使第一应用能够读取自身data目录下的待共享文件，并将其读取成输入输出流，其他应用程序就可以通过URI来获取IO流，以获取该待共享文件。本实施例通过上述步骤，能够避免SD卡的读取权限，同时避免了用户因为误操作导致待共享文件被删除的问题。

本发明还提供了如图5所示的第五实施例，一种文件共享方法，包括：

S501，将第一应用的待共享文件保存在所述第一应用的预置目录下。

在本步骤，文件共享装置在检测到第一应用的待共享文件后，将第一应用的待共享文件保存至该第一应用的预置目录下。

S502，建立contentprovider的继承类，并重写建立的类中的openFile方法。

在本步骤中，文件共享装置将建立contentprovider的继承类，在建立了contentprovider的继承类后，将重写建立的类中的openFile方法。

S503，为建立的类定义统一资源标识符。

在本步骤中，文件共享装置将为建立的类定义统一资源标识符。具体地，文件共享装置使用URI来定义建立的类。URI(Uniform Resource Identifier，统一资源标识符)是一个用于标识某一互联网资源名称的字符串。该种标识允许用户对任何(包括本地和互联网)的资源通过特定的协议进行交互操作。

S504，第一应用将所述预置目录下的所述待共享文件读取为输入输出流。

在本步骤中，第一应用将保存至预置目录的待共享文件读取为输入输出流(IO流，Input Output Stream)。

S505，第二应用通过所述建立的类的统一资源标识符获取所述输入输出流，并将所述输入输出流转换为文本格式，以获取所述待共享文件。

在本步骤中，第二应用通过建立的类的统一资源标识符(URI)获取待分享文件的输入输出流(IO流)，并将获取的IO流转换成文本格式，从而得到该待分享文件。

在本实施例中，文件共享装置通过将第一应用的待共享文件保存至该第一应用的预置目录下，避免了写入文件时所需SD卡写入的权限问题，使用户无法删除该预置目录下的待共享文件，同时通过建立contentprovider的继承类，并重写建立的类中的openFile方法，以使第一应用能够读取自身预置目录下的待共享文件，并将其读取成输入输出流，其他应用程序就可以通过URI来获取IO流，并对该IO流进行转换后获取该待共享文件。本实施例通过上述步骤，能够避免SD卡的读取权限，同时避免了用户因为误操作导致待共享文件被删除的问题。

在实际应用中，Android提供了ContentProvider，一个程序可以通过实现一个ContentProvider的抽象接口将自己的数据完全暴露出去，而且ContentProviders是以类似数据库中表的方式将数据暴露，也就是说ContentProvider就像一个“数据库”。其他应用程序获取ContentProvider提供的数据，与从数据库中获取数据的操作基本一样，并采用URI来表示外界需要访问的“数据库”。

在Content Provider中使用的查询字符串有别于标准的SQL查询。很多诸如select,add,delete,modify等操作都使用一种特殊的URI来进行，这种URI由3个部分组成，“content://”,代表数据的路径，和一个可选的标识数据的ID。以下是一些示例URI:

content://media/internal/images这个URI将返回设备上存储的所有图片；

content://contacts/people/这个URI将返回设备上的所有联系人信息；

content://contacts/people/45这个URI返回单个结果(联系人信息中ID为45的联系人记录)；

具体地，OpenFile为程序编写时用于打开文件的函数。

请参见图6，图6是本发明第四实施例提供的文件共享装置的结构示意图，该装置可以为终端设备或终端设备的一个模块，该文件共享装置包括：

文件保存单元101，用于将第一应用的待共享文件保存在所述第一应用的预置目录下。

文件保存单元101在检测到第一应用的待共享文件后，将第一应用的待共享文件保存至该第一应用的预置目录下。

具体地，目前用户使用移动终端或者电脑端安装各式应用程序(APP，Application)，每一APP在使用过程中均会按照该APP预置的保存路径保存产生的文件。以操作系统为安卓(Android)系统的移动终端为例，移动终端在安装了某APP后，该APP的在使用过程中产生的文件将按照该APP预置的保存规则保存至不同的目录中。为避免文件保存单元101在保存文件时需要SD卡保存的权限问题，本实施例中，文件保存单元101将每一APP待保存文件保存在该APP的预置目录下，以避免待保存文件写入时所需SD卡写入的权限问题，同时也保证用户在使用过程中无法删除该预置目录下的文件。

类建立单元102，用于建立contentprovider的继承类，并重写建立的类中的openFile方法。

类建立单元102将建立contentprovider的继承类，在建立了contentprovider的继承类后，将重写建立的类中的openFile方法。

具体地，安卓系统(Android)提供了ContentProvider，ContentProvider为存储和获取数据提供统一的接口，可以在不同的应用程序(APP)之间共享数据。实际应用中，Android已经为常见的一些数据提供了默认的ContentProvider。Android内置的许多数据都是使用ContentProvider形式，供开发者调用的(如视频，音频，图片，通讯录等)。当应用程序(APP)继承ContentProvider类，并重写该类用于提供数据和存储数据的方法，就可以向其他应用程序(APP)共享其数据。创建一个继承自ContentProvider的类后，将重写建立的类中的insert、delete、query、update、getType、onCreate方法，在这些方法中实现对数据源的操作。本步骤中，建立contentprovider的继承类后，类建立单元102重写建立的类中的openFile方法。

虽然使用其他方法也可以对外共享数据，但数据访问方式会因数据存储的方式而不同，如：采用文件方式对外共享数据，需要进行文件操作读写数据；采用sharedpreferences共享数据，需要使用sharedpreferences API读写数据。而使用ContentProvider共享数据的好处是统一了数据访问方式。

标识定义单元103，用于为建立的类定义统一资源标识符。

标识定义单元103将为建立的类定义统一资源标识符。具体地，标识定义单元103使用URI来定义建立的类。URI(Uniform Resource Identifier，统一资源标识符)是一个用于标识某一互联网资源名称的字符串。该种标识允许用户对任何(包括本地和互联网)的资源通过特定的协议进行交互操作。

第一应用单元104，用于将所述预置目录下的所述待共享文件读取为输入输出流。

第一应用单元104将保存至第一应用的预置目录的待共享文件读取为输入输出流(IO流，Input Output Stream)。

第二应用单元105，用于通过所述统一资源标识符获取所述输入输出流，以获取所述待共享文件。

当其他应用程序(APP)需要获取待共享文件时，第二应用单元105可以通过同一资源标识符(URI)来获取第一应用的输入输出流(IO流)。

在本实施例中，文件共享装置通过将第一应用的待共享文件保存至该第一应用的预置目录下，避免了写入文件时所需SD卡写入的权限问题，使用户无法删除该预置目录下的待共享文件，同时通过建立contentprovider的继承类，并重写建立的类中的openFile方法，以使第一应用能够读取自身预置目录下的待共享文件，并将其读取成输入输出流，其他应用程序就可以通过URI来获取IO流，以获取该待共享文件。本实施例通过上述步骤，能够避免SD卡的读取权限，同时避免了用户因为误操作导致待共享文件被删除的问题。

本发明提供的第七实施例如图6所示，一种文件共享装置包括：

文件保存单元101，用于将第一应用的待共享文件保存在所述第一应用的预置目录下。

类建立单元102，用于建立contentprovider的继承类，并重写建立的类中的openFile方法。

标识定义单元103，用于为建立的类定义统一资源标识符。

第一应用单元104，用于将所述预置目录下的所述待共享文件读取为输入输出流。

第二应用单元105，用于通过所述统一资源标识符获取所述输入输出流，以获取所述待共享文件。

进一步地，在第七实施例中，标识定义单元103具体用于：通过AndroidManifest.xml文件为所述建立的类，注册统一资源标识符中的内容提供者以及内容获取路径。

进一步地，在第七实施例中，第二应用单元105具体用于：通过ContentResolver解析所述统一资源标识符，并获取所述统一资源标识符指向的所述输入输出流。

进一步地，在第七实施例中，文件保存单元101具体用于：将第一应用的待共享文件保存在所述第一应用的date目录下。

进一步地，在第七实施例中，第二应用单元105具体用于：通过所述建立的类的统一资源标识符获取所述输入输出流，并将所述输入输出流转换为文本格式，以获取所述待共享文件。

图7是本申请实施例提供的文件共享方法的电子设备的硬件结构示意图，如图7所示，该设备包括：

一个或多个处理器610以及存储器620，图6中以一个处理器610为例。

执行文件共享方法的设备还可以包括：输入装置630和输出装置640。

处理器610、存储器620、输入装置630和输出装置640可以通过总线或者其他方式连接，图6中以通过总线650连接为例。

存储器620作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中的文件共享方法对应的程序指令/模块。处理器610通过运行存储在存储器620中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例的文件共享方法。

存储器620可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据文件共享装置的使用所创建的数据等。此外，存储器620可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器620可选包括相对于处理器610远程设置的存储器，这些远程存储器可以通过网络连接至文件共享装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置630可接收输入的数字或字符信息，以及产生与文件共享装置的用户设置以及功能控制有关的键信号输入。输出装置640可包括显示屏等显示设备。

所述一个或者多个模块存储在所述存储器620中，当被所述一个或者多个处理器610执行时，执行上述任意方法实施例中的文件共享方法。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

本发明实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备:这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、通讯录器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上为对本发明所提供的文件共享方法及装置的描述，对于本领域的技术人员，依据本发明实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本发明的限制。