lyMediaManagerPlugin - 0.6.1
A media manager plugin for Doctrine
You are currently browsingthe website for symfony 1
1457 plugins
3895 releases
609 developers
16615 users
Apostrophe
Applications
Development
Internationalization
JavaScript
Performance
WebServices
The plugin offers a simple web interface to upload and manage images, documents and other media files directly from the backend of your symfony application. File upload and file browsing features can be easily integrated into the TinyMCE editor.
Developers
moc.smc-aryl &&ta&& nimda
Copyright (c) 2010 Massimo GiagnoniPermission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the &Software&), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.THE SOFTWARE IS PROVIDED &AS IS&, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CO***ACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.lyMediamanagerPlugin is partially derivative work of sfAssetsLibraryPlugin (MIT license).Copyright (c) 2008 Ma Generation, Francois Zaninotto, Gabriele Santini, William Garcia
Releases for sf 1.4
MIT license
21/12/2010
MIT license
05/11/2010
MIT license
19/10/2010
MIT license
27/09/2010
MIT license
24/08/2010
MIT license
02/08/2010
MIT license
20/07/2010
MIT license
10/07/2010
MIT license
28/06/2010
Releases for sf 1.3
MIT license
21/12/2010
MIT license
05/11/2010
MIT license
19/10/2010
MIT license
27/09/2010
MIT license
24/08/2010
MIT license
02/08/2010
MIT license
20/07/2010
MIT license
10/07/2010
MIT license
28/06/2010
Join this plugin team
To join this plugin team, you must first
Changelog for release 0.6.1 - 21/12/2010
mgiagnoni: Added 'folder list' view
mgiagnoni: Made some layout changes to 'asset list' view
Other releases
Release 0.6.1 - 21/12/2010
mgiagnoni: Added 'folder list' view
mgiagnoni: Made some layout changes to 'asset list' view
Release 0.6.0 - 05/11/2010
mgiagnoni: Made root folder not editable from web interface
mgiagnoni: Added a check to prevent the creation of a regular folder with the same name of thumbnails folders
mgiagnoni: Added thumbnail creation for PDF files and graphic formats supported by ImageMagick
mgiagnoni: Added support for FCKEditor
mgiagnoni: Added link to hide/show folder menu in icons view.
mgiagnoni: Minor fixes / optimizations
Release 0.5.6 - 19/10/2010
mgiagnoni: Created more unit tests
vjousse: Added support for optional i18n behavior in schema
mgiagnoni: Added new task 'generate-thumbs'
mgiagnoni: Added a batch action to (re)generate thumbnails for selected assets
mgiagnoni: Added a download asset action
Release 0.5.5 - 27/09/2010
mgiagnoni: Made small changes to default list view
mgiagnoni: Updated README with instruction on how to customize list view layout
mgiagnoni: Improved error checking on asset/folder creating, moving, renaming, deleting operations
mgiagnoni: Moved many function from lyMediaTools class to model classes
mgiagnoni: Fixed wrong rounding to integer of asset file size value (thanks Jakub)
Release 0.5.4 - 24/08/2010
mgiagnoni: Refactored lyMediaFolder, lyMediaAsset and added some unit tests
mgiagnoni: Added a few icons for common mime-types
mgiagnoni: Fixed undefined variable error when filters are disabled in lyMediaAsset module (thanks Jeremie)
Release 0.5.3 - 02/08/2010
mgiagnoni: Fixed redirection urls for file upload and folder creation actions in file browser popup
mgiagnoni: Added a file to configure TinyMCE with an external Javascript
mgiagnoni: Updated README with instructions on how to configure the plugin to act as TinyMCE file browser.
mgiagnoni: Created helper thumbnail_image_path
mgiagnoni: Fixed wrong path of images inserted from TinyMCE file browser when front controller is not located in Document Root
mgiagnoni: Changed sfWidgetFormLyMediaTinyMCE to automatically include TinyMCE related javascript files
mgiagnoni: Auto-rename of uploaded file when another file with the same name exists in folder
mgiagnoni: Added dedicated layout for file browser popup used by TinyMCE
mgiagnoni: Added number of files / folders counters in icons view
Release 0.5.2 - 20/07/2010
mgiagnoni: Created forms to add a folder / upload file from icons view
mgiagnoni: Fix: existence of media root directory is now checked in controller
Release 0.5.1 - 10/07/2010
mgiagnoni: Made asset list (icons view) sortable by name or date
mgiagnoni: Added paging to asset list (icons view)
mgiagnoni: Refactored class lyMediaFolder
mgiagnoni: Added task synchronize
Release 0.5.0 - 28/06/2010
mgiagnoni: initial release
lyMediaManagerPlugin
The plugin offers a simple web interface to upload and manage images, documents and other media files directly from the backend of your symfony application. File upload and file browsing features can be easily integrated into the TinyMCE editor.
lyMediaManagerPlugin is inspired to sfAssetsLibraryPlugin for Propel, but some of its features have not been ported yet while others have been reimplemented in a different way.
This plugin is being developed to be included in Lyra CMS (also under development), but it's a standard plugin that can be used in any symfony project with no dependencies except sfThumbnailPlugin, needed to generate thumbnails.
This is currently a beta release, play with it, please report me any error and feel free to suggest improvements
Installation
Automatic installation
lyMediaManagerPlugin can be quickly installed with the symfony command plugin:install (you must have PEAR installed on your system).
php symfony plugin:install --stability=beta lyMediaManagerPlugin
sfThumbnailPlugin is also needed to generate thumbnails of images.
php symfony plugin:install sfThumbnailPlugin
Manual installation
Alternatively you can uncompress the .tgz package inside the plugins directory of your symfony project. If you have Subversion installed you can also install the plugin by checking out the source code from the repository: cd to the plugins directory of your symfony project and execute
svn checkout /mgiagnoni/lyMediaManagerPlugin.git lyMediaManagerPlugin
If you choose the manual installation another two steps are needed. Plugins must be enabled in your project configuration class. Example:
//%project_dir%/config/ProjectConfigurationClass.class.php
public function setup()
$this-&enablePlugins('sfDoctrinePlugin');
$this-&enablePlugins('sfThumbnailPlugin');
$this-&enablePlugins('lyMediaManagerPlugin');
Plugin assets must be published with the following symfony command
php symfony plugin:publish-assets
Configuring i18n
If you want to enable i18N behavior, add this in your app.yml:
lyMediaManager:
use_i18n: true
i18n_cultures:
en: English
fr: Fran?§ais
Building models and tables
Then we need to generate plugin model classes and corresponding database tables.
php symfony doctrine:build --all
Keep in mind that this will erase all your data and rebuild everything from scratch. Before executing the statement above you may want to backup your database and restore it thereafter.
Enabling plugin modules
lyMediaManagerPlugin contains two modules: lyMediaAsset, lyMediaFolder. Both must be enabled in settings.yml file (usually in your backend application). Example.
#%project_dir%/apps/backend/config/settings.yml
.settings:
enabled_modules: [default, lyMediaAsset, lyMediaFolder]
Initializing folder tree
lyMediaManagerPlugin provides a custom task to create the media library root directory inside the web directory of your project and the corresponding root node in the database. By default this directory will be called media: see configuration below if you prefer a different name.
php symfony media:create-root
This command should be executed by an user of the same group of the http server, if this is not possible chmod/chown the media library root directory so that is writable by the http server.
Go to default page
Assuming that you are testing the plugin on localhost and you have enabled modules in your backend application, visit
http://localhost/backend.php/ly_media_asset
to go to the module default page.
Configuration
Some configuration parameters can be set inside the app.yml file of your application. Example.
#%project_dir%/apps/backend/config/app.yml
lyMediaManager:
# root directory name (used by task media:create-root)
media_root: media
# thumbnails settings
thumbnails:
height: 32
# forces thumbnail size to fixed width/height values
shave: true
height: 84
shave: true
width: 194
height: 152
# name of folder where thumbnails will be created
thumbnail_folder: thumbs
# thumbnails will be created only for these mime-types
create_thumbnails_for: [image/jpeg,image/png,image/gif]
# only files with these extensions can be uploaded
allowed_extensions: [jpg,png,gif,txt]
# only files of these mime-types can be uploaded
mime_types: [image/jpeg,image/png,image/gif,text/plain]
# libray used for thumbnail creation: true ImageMagick, false (default) GD
use_ImageMagick: false
Note: mini, small and medium size thumbnails are used by the plugin itself and should not be removed. More thumbnails of desired sizes can be created for use in your application.
Customizing views
Media library contents can be displayed and managed in different views: list view and icons view.
The list view is a sortable list created with the standard Doctrine admin generator templates and can be customized as any other module created with the task doctrine:generate-admin. Here are some quick instructions.
First create a folder lyMediaAsset and a subfolder config inside the modules folder of the application where you have enabled the plugin module. Then add a generator.yml file inside config
%project_dir%
%app_name% (likely `backend`)
lyMediaAsset
generator.yml
You can now safely customize the list view layout in your own generator.yml file without losing your changes when you upgrade the plugin. A complete list of all parameters and settings you can use in configuration files is available in symfony . Here are a couple of simple examples.
Always remember to issue a symfony clear-cache command to see the effect of any change made to a configuration file in the production environment.
#%project_dir%/apps/%app_name%/modules/lyMediaAsset/config/generator.yml
generator:
created_at: {date_format: 'd MMM, yyyy'}
display: [_td_image,title,description,created_at]
title: Assets List
With this configuration the list layout displays the following columns: asset thumbnail, title, description, creation date. We have also set a custom page title and a date format for creation date column.
The display option contains an array of columns: a column can show not only field values (title, description, created_at in our example), but also partials (_td_image defined in %project_dir%/plugins/lyMediaManagerPlugin/modules/lyMediaAsset/templates), components (not used in our example) and any value returned by a getter method declared in model class. Let see an example.
With the default layout the first column of the list displays a thumbnail or icon. We may want to replace it with the asset path to save space: to do so it's sufficient to change our generator.yml in this way.
display: [path,title,description,created_at]
If you look at the definition of the class lyMediaAsset in plugin schema.yml you won't find a column named path : the list column will show the value returned by lyMediaAsset::getPath() method.
Synchronize
A dedicated task is available to synchronize the media library database with the contents of a directory.
php symfony media:synchronize ./web/uploads/medias --application=backend
All folders and files in './web/uploads/medias' (a relative path, but you can specify an absolute path as well) that are not present in the media library will be added and a corresponding record created in the database. Thumbnails will be automatically generated for files of mime-types indicated in plugin configuration (see parameter create_thumbnails_for).
php symfony media:synchronize ./web/uploads/medias --removeOrphanAssets --application=backend
Same as above, but in addition every file that is present in the media library without a corresponding file in './web/uploads/medias' will be removed from the media library.
php symfony media:synchronize ./web/uploads/medias --removeOrphanFolders --application=backend
This time every folder in the media library without a corresponding folder in the directory will be removed. If something it's not clear, play with the task in a development environment to see the effect of these switches.
Generate thumbnails
The generate-thumbs task will regenerate thumbnails for all assets in a given folder or the whole media library, provided thumbnails are supported by asset mime-type (see parameter create_thumbnails_for in plugin configuration).
This can be useful once we have added a new thumbnail type or changed the width or height of an existing type in plugin configuration.
php symfony media:generate-thumbs
Thumbnails are generated for all assets of the media library.
php symfony media:generate-thumbs media/photos
Thumbnails are generated for assets inside the media/photos folder and all subfolders.
php symfony media:generate-thumbs media/photos --no-recurse
Thumbnails are generated only for assets inside the media/photos folder.
Note that all folder paths passed to the task must be relative.
Working with TinyMCE editor
lyMediaManagerPlugin can work together with the TinyMCE editor to make file browsing and file uploading features accessible directly from the editor toolbar. A few configuration steps are needed.
Installing TinyMCE
Download the package from the : it will be something like tinymce_3_3_x.zip, where x is the minor version number. Uncompress it in a temporary folder on your hard disk: the resulting folder tree should be like the following
--jscripts
--tiny_mce &--Only this folder (with all subfolders and files inside) is needed.
--examples
Copy the tiny_mce folder (with all its subfolders and files) in '%project_dir%/web/js'. Verify that the following javascript files are present exactly in these paths:
%project_dir%/web/js/tiny_mce/tiny_mce.js
%project_dir%/web/js/tiny_mce/tiny_mce_popup.js
Configuring your form
To use TinyMCE with the file browser provided by lyMediaManagerPlugin you need to configure your forms following one of these alternative methods.
1) Dedicated widget
In the configure() method of your form replace sfWidgetFormTextarea with sfWidgetFormLyMediaTinyMCE. For example, assuming that the field you want to make editable with TinyMCE editor is named content
class MyForm extends BaseMyForm
public function configure()
$this-&widgetSchema['content'] = new sfWidgetFormLyMediaTinyMCE(array(
'width' =& 450,
'height' =& 300
Refer to the source of sfWidgetFormLyMediaTinyMCE for other options supported by the widget. If you have installed TinyMCE exactly as explained above, you won't need to change options default values.
2) Manual inclusion of Javascript files
If you prefer to not use the widget you can include all the needed Javascript files in your form template through standard helpers.
&?php use_stylesheets_for_form($form) ?&
&?php use_javascripts_for_form($form) ?&
&?php use_javascript('tiny_mce/tiny_mce', 'last'); ?&
&?php use_javascript('/lyMediaManagerPlugin/js/lymedia_tiny', 'last'); ?&
&?php use_javascript('/lyMediaManagerPlugin/js/lymedia_tiny_cfg', 'last'); ?&
Then in the configure() method of your form set a class attribute for all textareas you want to make editable with TinyMCE.
class MyForm extends BaseMyForm
public function configure()
$this-&widgetSchema['content']-&setAttribute('class', 'rich');
Also refer to comments inside lymedia_tiny_cfg.js file because you may need to edit something depending by the name and location of your front controller.
Using sfWidgetFormLyMediaTinyMCE is easier, while manual inclusion of Javascript files is preferable if you want to keep TinyMCE configuration in a separate javascript file e do not want to mix markup and Javascript code in document body. Whichever method you choose, if you have configured everything properly you will see lyMediaManagerPlugin file browser when you select the insert/edit image button in TinyMCE toolbar and click the browse icon in the pop-up window.
Working with FCKEditor
Installation
Refer to official
for instructions on how to install the editor. I will assume that installation folder is %project_dir%/web/js/fckeditor
Form setup
Insert the following lines at the top of the form template where you want to use the editor
&?php use_javascript('/js/fckeditor/fckeditor', 'last'); ?&
&?php use_javascript('/lyMediaManagerPlugin/js/lymedia_fck_init', 'last'); ?&
If the form is part of a module generated by the admin generator, you can insert the lines above in _form_header.php template.
The script lymedia_fck_init will create an instance of FCKeditor for each textarea with a class attribute of rich. Assuming that the field you want to make editable with FCKeditor editor is named content, insert the following code in the configure() method of your form.
class MyForm extends BaseMyForm
public function configure()
$this-&widgetSchema['content']-&setAttribute('class', 'rich');
If the form is part of a module generated by the admin generator you can set this attribute in generator.yml
content: {attributes {class: rich}}
If everything is properly configured the dialog window opened by the insert image button on editor toolbar should now contain a Browse Server button: click it to have acess to lyMediaManagerPlugin icons view and select the image to insert in content.
This plugin is inspired to (and in part derived from) .
Optional i18n support has been contributed by Vincent Jousse ().
Icons come from .
Complete this README :)
Improve user interface
Support other plugins for thumbnail generation (sfImageTransformPlugin)
Add more tests从java到C解析Binder机制
从java到C解析Binder机制
Binder机制是一种C/S结构，主要包括三部分，分别为Client、Server、ServiceManager。ServiceManager是谷歌设计的，它是一段简洁的C代码（位置在native/cmds/servicemanager/service_manager.c），主要是方便集中管理系统中的各种服务，也方便Client和Server查询系统中的服务信息。
我们首先来看一个跟ServiceManager很大关联的类，它就是IServiceManager类：
该类包括四个方法，名字就不重复了，通过这些方法可以注册服务、查询服务信息等，另外它还有一个enum枚举，enum包含与方法相对应的四个常量。查看源码我们可知enum常量的值为1，2，3，4。
&&&&&&&GET_SERVICE_TRANSACTION = IBinder::FIRST_CALL_TRANSACTION,
&&&&&&&CHECK_SERVICE_TRANSACTION,
&&&&&&&ADD_SERVICE_TRANSACTION,
&&&&&&&LIST_SERVICES_TRANSACTION,
其中IBinder::FIRST_CALL_TRANSACTION的值为1，这里的取值是很重要的，因为他们分别对应ServiceManager(service_manager.c)中的enum常量：
&&& SVC_MGR_GET_SERVICE = 1,
&&& SVC_MGR_CHECK_SERVICE,
&&& SVC_MGR_ADD_SERVICE,
&&& SVC_MGR_LIST_SERVICES,
该enum在native/cmds/servicemanager/binder.h位置，service_manager.c程序引用了binder.h。这样C/S实现IServiceManager接口后，如果C/S传递GET_SERVICE_TRANSACTION参数，ServiceManager(service_manager.c)就能对应SVC_MGR_GET_SERVICE处理了，其他类似。
之所以开头就讲IServiceManager类，是因为我觉得从宏观上对C/S和ServiceManager的关系有一个大概的印象很重要，如下图所示：
如何看到这里你在好奇使用的是什么软件画图的，我郑重的推荐一下Gliffy画图软件，而且它有chrome插件，相比viso等软件更轻、更简单。
&在上图IServiceManager和ServiceManager之间什么都没有画，那他们是如何通信的呢？其实他们是通过一种叫Binder设备进行通信的，这也是今天的主题，如果不了解设备的概念，建议查看linux的相关知识。我们将Binder设备加入可得到下图：
从上图我们知道了IServiceManager和ServiceManager可以通过Binder通信，但是还没有和C/S关联，我们加上C/S后来看看效果图，如下所示：
因为Client与binder通信在java层涉及的层次太多，我们主要分析Server与Binder的通信。
Server到BpServiceManager的过程
我们以MediaPlayerService为例，MediaPlayerService的Server端是main_mediaserver文件，android5.1.0的源码位置在/frameworks/av/media/mediaserver/main_mediaserver.cpp，代码如下：
main_mediaserver作为Server端，肯定会与mediaplayerservice关联，defaultServiceManager方法可以获得BpServiceManager对象，这样通过该对象就能与binder设备通信。MediaPlayerService::instantiate()这句很重要，是main_mediaserver和mediaplayerservice关联的桥梁，该方法的具体代码如下：
voidMediaPlayerService::instantiate() {
&&&& defaultServiceManager()-&addService(
&&&&&&&&&& String16(&media.player&),new MediaPlayerService());
我们看出instantiate方法的作用是将MediaPlayerService注册到ServiceManager中，这里又出现了defaultServiceManager方法，说明注册服务也是通过BpServiceManager来执行的。
回到main_mediaserver我们找不到defaultServiceManager方法，但是我们可以找到如下声明：
#include&binder/IServiceManager.h&
我们迫不及待想要去看看defaultServiceManager方法的具体实现了，位置在native/libs/binder/IServiceManager.cpp)，代码如下所示：
从上面代码我们只能看出gDefaultServiceManager是IServiceManager类，而不能确定它就是BpServiceManager类。我们继续跟踪，首先关注ProcessState类，它是一个记录进程状态的类。之前的图中我们在Server和BpServiceManager之间添加的就是ProcessState，不记得可以回头看一下，之所以放在这么重要的位置，那是因为Binder设备的操作都是跟进程关联的，一个进程共享一个Binder设备。我们来看看ProcessState::self()-&getContextObject(NULL)具体内容：
我们跟进getStrongProxyForHandle(0)（位置在native/libs/binder/ProcessState.cpp），内容如下：
由上面的代码我们知道getStrongProxyForHandle(0)返回的是BpBinder，所以defaultServiceManager()方法可以简化为
gDefaultServiceManager= interface_cast&IServiceManager&(new BpBinder(0))
interface_cast在IServiceManager类中没有定义，它是在父类头文件IInterface.h中定义的，它是一个模板方法，位置在native/include/binder/IInterface.h中，如下所示：
上述代码中的INTERFACE模板类为IServiceManager，这是在defaultServiceManager()方法中传入的,所以gDefaultServiceManager =IServiceManager::asInterface(new BpBinder(0))。这样我们跟踪IServiceManager的asInterface()方法，但是在IServiceManager中没有找到该方法，我们继续在父类IInterface.cpp中找，我们可以找到如下代码：
我们进一步简化gDefaultServiceManager= new BpServiceManager(new BpBinder(0))，其实BpServiceManager没有什么特别的意义，它都是通过BpBinder去通信的，它的意义是就在于保存BpBinder对象以供MediaPlayerService调用。BpServiceManager中的成员变量mRemote就是用来保存BpBinder对象的，mRemote变量定义在BpRefbase类中，继承关系如下：
阶段总结，我们可以知道defaultServiceManager()方法得到是BpServcieManager对象，并且BpServiceManager对象中的变量mRemote保存了BpBinder对象。
BpServiceManager到Binder设备的过程
回顾之前的main_mediasever.cpp类，我们知道MediaPlayerService服务是通过MediaPlayerService::instantiate()这句代码将自己注册到ServerManager，我们再回顾一下具体显示的代码：
voidMediaPlayerService::instantiate() {
&&&& defaultServiceManager()-&addService(
&&&&&&&&&& String16(&media.player&),new MediaPlayerService());
之前我们分析过defaultServiceManager方法得到的是BpServiceManager，我们就以MediaPlayerService的addService过程为例分析一下《BpServiceManager到Binder设备的过程》。
我们进入BpServiceManager的addService方法看看，位置在native/libs/binder/IServiceManager.cpp，实现代码如下：
注意data.writeStrongBinder(service)这句代码，service就是MediaPlayerService::instantiate方法中new的MediaPlayerService对象。感兴趣话可以追踪writeStrongBinder方法的实现，它的主要作用就是将MediaPlayerService对象保存在Parcel对象中并通过binder设备传递给ServerManager ，这样以后就可以通过该对象与ServiceManager和Client通信了。
remote()方法就是获得mRemote对象，调用BpBinder的transact方法就能与Binder设备通信了，我们进入transact方法看一下：
IPCThreadState是什么呢？之前我们介绍过ProcessState类，我们知道ProcessState类是记录进程的状态，IPCThreadState跟ProcessState有很大的关系，从字面意思来讲，IPCThreadState就是IPC有关线程的状态，也就是一个进程可能同时存在好多线程与外界的进程通过IPC通信，用图描述如下：
我们进入IPCThreadState（位置在native/libs/binder/IPCThreadState.cpp）的transact方法中看看：
代码中的writeTransactionData方法，主要是将数据写入Pacel缓存中，方便进行比较等操作，但是真正的传递数据是在waitForResponse方法中，代码如下：
注意talkWithDriver方法，我们再进入该方法中看看：
注意mProcess变量，由之前IPCThreadState和ProcessState关系图我们知道该mProcess变量就是指向ProcessState对象，所以mProcess-&mDriverFD指向的就是进程中唯一的Binder设备，这样就可以将数据写入Binder设备来传递数据。
ServiceManager处理Binder数据的过程
开头我们就说了ServiceManager其实是一段C程序，那我们看看service_manager.c的代码(位置在native/cmds/servicemanager/service_manager.c)：
其中bs = binder_open(128*1024)就是打开binder设备，第一感觉就是128*1024的size是不是太小了，驱动相关的朋友有知道的请不吝赐教。我们关注后面的binder_loop方法，它就是负责操作binder设备，定义在native/cmds/servicemanager/binder.c
从代码的内容可以看出该方法里面包含了一个死循环，这样一旦service_manager.c程序运行后，该程序就开始***binder设备的数据了。binder_write_read结构体是用来在binder设备传递数据的，如果需要了解更详细的信息请参考其它资料。通过ioctl方法可以获得binder设备中的数据，那有事怎么解析的呢？我们看看binder_parse方法的代码：
从代码中可以看出，binder.c会根据ptr的指针所指类型进行不同的响应，至于ptr指针的结构，也就是binder驱动层面的代码可以参考侯亮的系类文章。
ServiceManager给予反馈后，Server的处理过程
现在我们已经分析了server-&BpServiceManger-&binder-&ServiceManager的整个过程，并且我们知道在binder_parse会根据不同的请求作出响应，那server端是如何收到响应的呢？我们回过头去看一下main_mediaserver.cpp的代码：
以我们之前的分析经验可以知道操作binder设备主要跟进程的ProcessState和IPCThreadState类有关，我们跟踪IPCThreadState::self()-&joinThreadPool()看看：
注意该方法中的talkWithDriver带的参数是false，当Server端是注册服务或初始化时传递的参数是false，我们现在分析的是Server端接收数据，所以我们分析getAndExecuteCommand方法，跟踪进去看看：
这里也看到talkWithDriver，而且默认传递的参数是true，不信的话可以去IPCThreadState.h头文件看看，位置在native/include/binder/IPCThreadState.h。
有之前《BpServiceManager到Binder设备的过程》的最后一步talkWithDriver方法的分析，我们知道talkWithDriver方法会与binder设备打交道，通过ioctl方法传递数据，并将binder数据缓存到Parcel对象，那我们现在分析一下Server如何处理从Binder设备读取的数据吧。首先从缓存Parcel中读取数据:
cmd =mIn.readInt32()
此时的cmd的类型就是BR_TRANSACTION了，然后我们进入executeCommand方法看看，代码太长我们截取主要部分：
关键就是sp&BBinder&b((BBinder*)tr.cookie)这句代码，为什么ServiceManager从Binder设备中读到是BBinder类型的数据呢？还记得我们之前在main_mediaserver是如何将MediaPlayerServcie注册到ServiceManager的吗？我们来回顾一下MediaPlayerService::instantiate()方法：
voidMediaPlayerService::instantiate() {
&&&& defaultServiceManager()-&addService(
&&&&&&&&&& String16(&media.player&),new MediaPlayerService());
我们传递进去的是MediaPlayerService对象，并通过后续BpServiceManager中的writeStrongBinder将MediaPlayerService打包成Parcel传递给ServiceManager的。但是即便这样，MediaPlayerService跟BBinder又有什么关系呢？我们来看一下MediaPlayerService的继承关系：
很激动，我们发现MediaPlayerService继承BBinder，那tr.cookie就是指向MediaPlayerService对象了。有了MediaPlayerService对象后，Server(main_mediaserver.cpp)就能调用MediaPlayerService的transact方法做出响应了，transact的具体实现我们就不分析了。
虽然我们知道了MediaPlayerService通过binder_transaction_data.cookie域传递，但是我们对Server和ServcieManager之间数据的传递没有一个很直观的印象，所以我推荐侯亮的系列文章，我相信你看完之后会有一个更深的理解。我们在这里引用侯亮的图片简单说明一下：
我们简单分析一下红线表示的流程，当我们在Server端(即图片中的发起端进程)需要向ServerManager（目标端进程）注册服务时，在驱动层会创建实体树的根binder_node，将Server端的MediaPlayerService对象保存到cookie域，只有被其他进程调用时才会创建引用树的根binder_ref。当目标端进程需要用到Server端MediaPlayerService服务时，直接在驱动层访问binder_node的cookie域就能拿到MediaPlayerServcie对象了，再通过transact方法传递数据。
Android深入浅出之Binder机制: http://my.oschina.net/youranhongcha/blog/152963
红茶一杯:话Binder http://my.oschina.net/youranhongcha/blog/152963
看过本文的人也看了：
我要留言技术领域：
取消收藏确定要取消收藏吗？
删除图谱提示你保存在该图谱下的知识内容也会被删除，建议你先将内容移到其他图谱中。你确定要删除知识图谱及其内容吗？
删除节点提示无法删除该知识节点，因该节点下仍保存有相关知识内容！
删除节点提示你确定要删除该知识节点吗？