از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
Binder سیستمی برای ارتباطات بین فرآیندی است که به دو فرآیند در یک دستگاه مجهز به اندروید اجازه می دهد با هم ارتباط برقرار کنند. Binder وسیله ای برای اجرای فراخوانی تابع در فرآیند دیگری فراهم می کند که برای تماس گیرنده کاملاً شفاف است.
در اصطلاح بایندر، فرآیند فراخوانی مشتری در نظر گرفته می شود و نقطه پایانی آن را پراکسی بایندر یا پروکسی می نامند. برعکس، فرآیندی که فراخوانی می شود سرور است و نقطه پایانی آن گره یا گرهبایندر نامیده می شود.
هر گره می تواند رابط کاربری خود را آشکار و پیاده سازی کند. و با استفاده از یک پروکسی، کلاینت می‌تواند روش‌هایی را بر روی یک رابط گره اجرا کند که گویی فراخوانی یک فراخوانی تابع محلی است. مثال زیر یک متد در حال فراخوانی را نشان می دهد:
int result = someNodeInterface.foo(a, b); // someNodeInterface is a proxy object
فرض کنید کلاینت فراخوانی foo() در فرآیند A و سرور پیاده سازی کننده foo() در فرآیند B اجرا می شود. شکل 1 نحوه اجرای این فراخوانی را نشان می دهد:
شکل 1. اجرای فراخوانی Binder.
برای اجرای یک متد در یک فرآیند دیگر، همانطور که در شکل 1 نشان داده شده است، موارد زیر رخ می دهد:
کد مشتری در فرآیند A کد پروکسی را در فرآیند A فرا می‌خواند. کد پراکسی در فرآیند A تراکنشی حاوی موارد زیر ایجاد می‌کند:
شناسه گره
یک شناسه برای متد foo() در گره
یک بافر حاوی یک کپی از آرگومان های a و b
تراکنش به درایور هسته بایندر ارسال می شود.
درایور هسته binder تعیین می کند که فرآیند B میزبان گره باشد.
هسته کل تراکنش را در فضای آدرس فرآیند B کپی می کند.
هسته یک رشته را در فرآیند B برای مدیریت تراکنش پیدا می کند و تراکنش را به آن ارسال می کند.
Thread تراکنش را باز می کند، گره را پیدا می کند و تراکنش را به شی گره می فرستد.
شی گره شناسه تابع را از تراکنش دریافت می کند، a و b از بافر تراکنش باز می کند و a و b در متغیرهای محلی ذخیره می کند.
شی گره foo(a, b) روی کد سرور در فرآیند B فراخوانی می کند.
نتیجه تماس در یک تراکنش پاسخ بازگردانده می شود که به درایور هسته ارسال می شود و سپس به پروکسی فراخوان در فرآیند A باز می گردد.
پروکسی نتیجه را به تماس گیرنده در فرآیند A برمی گرداند.
موارد استفاده از کلاسور
Binder را می توان در سناریوهای مختلفی استفاده کرد که در آن ارتباط بین نرم افزار در فرآیندهای مختلف باید رخ دهد. به عنوان مثال:
یک برنامه دوربین از کلاسور برای برقراری ارتباط با سرور دوربین در فرآیند دیگری استفاده می کند. سپس سرور دوربین از Binder برای برقراری ارتباط با دوربین HAL در فرآیند دیگری استفاده می کند.
یک برنامه از Binder برای برقراری ارتباط با سرور سیستم در فرآیند دیگری استفاده می کند. سرور سیستم از Binder برای صحبت با HAL ها در فرآیندهای دیگر استفاده می کند.
یک برنامه در یک فرآیند از Binder برای برقراری ارتباط با یک برنامه دیگر در فرآیند دیگر استفاده می کند.
دیمون سیستم که مسئول نصب، به‌روزرسانی و حذف برنامه‌ها ( installd ) است، از بایندر برای برقراری ارتباط با شبح زمان اجرا اندروید («artd») برای کامپایل برنامه‌ها استفاده می‌کند.
AIDL و بایندر
از زبان طراحی رابط اندروید (AIDL) برای تعریف رابط های برنامه نویسی که از binder برای IPC استفاده می کنند، استفاده کنید. برای اطلاعات بیشتر، به نمای کلی AIDL مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین به‌روزرسانی 2025-08-05 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین به‌روزرسانی 2025-08-05 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Binder overview\n\n*Binder* is a system for interprocess\ncommunication that lets two processes on an Android-powered device\ncommunicate. Binder provides a means to execute function calls in another\nprocess that is completely transparent to the caller.\n\nIn binder terms, the calling process is considered the *client* and its\nendpoint is called the *binder proxy* or *proxy* . Conversely,\nthe process being called is the *server* and its endpoint is called the\n*binder node* or *node*.\n\nEach node can expose and implement its own interface. And, using a proxy, the\nclient can execute methods on a node interface as though invocation was a\nlocal function call. The following example shows a method being invoked: \n\n int result = someNodeInterface.foo(a, b); // someNodeInterface is a proxy object\n\nAssume that the client calling `foo()` is running in process A and the server\nimplementing `foo()` is running in process B. Figure 1 shows how this call is\nexecuted:\n\n**Figure 1.** Binder call execution.\n\nTo execute a method in another process, as shown in figure 1,\nthe following occurs:\n\n1. The client code in process A invokes the proxy code in process A. The proxy code in process A creates a transaction containing the following items:\n - An identifier for the node\n - An identifier for the `foo()` method on the node\n - A buffer containing a copy of the arguments `a` and `b`\n2. The transaction is submitted to the binder kernel driver.\n3. The binder kernel driver determines that process B hosts the node.\n4. The kernel copies the entire transaction into process B's address space.\n5. The kernel finds a thread in process B to handle the transaction and passes the transaction to it.\n6. The thread unpacks the transaction, finds the node, and sends the transaction to the node object.\n7. The node object obtains the function identifier from the transaction, unpacks `a` and `b` from the transaction buffer, and stores `a` and `b` in local variables.\n8. The node object calls `foo(a, b)` on the server code in process B.\n9. The result of the call is returned in a reply transaction, which is passed to the kernel driver and then back to the calling proxy in process A.\n10. The proxy returns that result to the caller in process A.\n\nBinder use cases\n----------------\n\nBinder can be used in a variety of scenarios where communication between\nsoftware in different processes must occur. For example:\n\n- A camera app uses binder to communicate with the camera server in\n another process. The camera server then uses binder to communicate with the\n camera HAL in another process.\n\n- An app uses binder to communicate with a system server in another process. The\n system server uses binder to talk to HALs in other processes.\n\n- An app in one process uses binder to communicate with a different app in\n another process.\n\n- The system daemon responsible for installing, updating, and removing\n apps (`installd`) uses binder to communicate with the Android\n runtime daemon ('artd') to compile apps.\n\nAIDL and binder\n---------------\n\nUse the Android Interface Design Language (AIDL) to define programming\ninterfaces that use binder for IPC. For further information, see the\n[AIDL overview](/docs/core/architecture/aidl).\n| **Note:** HIDL is deprecated; only AIDL is recommended for new implementations."]]
