קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
Binder היא מערכת שמאפשרת תקשורת בין תהליכים (IPC) שפועלים במכשירי Android אפשר להשתמש בה כדי לשלוח בקשה להפעלת פונקציה מתהליך אחר שתהיה שקופה לגמרי לפונקציית הקריאה החוזרת (caller).
הגדרות ב-Binder: התהליך ששולח את הקריאה הוא הלקוח ונקודת הקצה שלו נקראת Binder proxy או Proxy. התהליך שאליו נשלחת הקריאה הוא השרת ונקודת הקצה שלו נקראת צומת Binder או צומת.
כל צומת יכול לחשוף ולהטמיע ממשק משלו, ואז הלקוח יכול להשתמש ב-Proxy כדי להריץ מתודות על הממשק של הצומת כאילו זו שליחה מקומית של בקשה להפעלת פונקציה. דוגמה להפעלה של מתודה:
int result = someNodeInterface.foo(a, b); // someNodeInterface is a proxy object
נניח שהלקוח ששולח קריאה ל-foo() פועל בתהליך א', והשרת שמטמיע את foo() פועל בתהליך ב'. באיור 1 רואים איך הקריאה נשלחת:
איור 1. שליחת קריאה ב-Binder
זה מה שקורה כשמריצים מתודה בתהליך אחר, כמו שמוצג באיור 1:
קוד הלקוח בתהליך א' מפעיל את קוד ה-Proxy בתהליך א'. קוד ה-Proxy בתהליך א' יוצר טרנזקציה עם הפריטים הבאים:
מזהה של הצומת
מזהה של מתודת foo() בצומת
מאגר נתונים זמני שיש בו עותק של הארגומנטים a ו-b
הטרנזקציה נשלחת לדרייבר של ליבת Binder.
הדרייבר קובע שהצומת יתארח בתהליך ב'.
הליבה מעתיקה את כל העסקה למרחב הכתובות של תהליך ב'.
הליבה מאתרת בתהליך ב' Thread שבו אפשר לטפל בטרנזקציה ומעבירה את הטרנזקציה לשם.
ה-Thread מפרק את הטרנזקציה, מוצא את הצומת ושולח את הטרנזקציה לאובייקט הצומת.
אובייקט הצומת שולף את מזהה הפונקציה מהטרנזקציה, מפרק את a ואת b ממאגר הנתונים הזמני של הטרנזקציה ושומר את a ואת b במשתנים מקומיים.
אובייקט הצומת שולח קריאה ל-foo(a, b) בקוד השרת בתהליך ב'.
התוצאה של הקריאה מוחזרת בטרנזקציית תגובה, שמועברת לדרייבר של הליבה ואז בחזרה ל-Proxy ששלח את הקריאה מתהליך א'.
ה-Proxy מחזיר את התוצאה הזו לפונקציית הקריאה החוזרת (caller) בתהליך א'.
תרחישי שימוש ב-Binder
אפשר להשתמש ב-Binder במגוון תרחישים שבהם נדרשת תקשורת בין תוכנות בתהליכים שונים. לדוגמה:
אפליקציית מצלמה משתמשת ב-Binder כדי לתקשר עם שרת המצלמה בתהליך אחר, ואז שרת המצלמה משתמש ב-Binder כדי לתקשר עם
רכיב HAL של המצלמה בתהליך אחר.
אפליקציה משתמשת ב-Binder כדי לתקשר עם שרת מערכת בתהליך אחר, ואז שרת המערכת משתמש ב-Binder כדי לתקשר עם רכיב HAL בתהליכים אחרים.
אפליקציה בתהליך אחד משתמשת ב-Binder כדי לתקשר עם אפליקציה אחרת בתהליך אחר.
הדימון (daemon) של המערכת שאחראי על התקנה, עדכון והסרה של אפליקציות (installd) משתמש ב-Binder כדי לתקשר עם הדימון (daemon) של סביבת זמן הריצה ב-Android (artd) כדי לקמפל אפליקציות.
AIDL ו-binder
אתם יכולים להשתמש בשפה לעיצוב ממשקים ב-Android (AIDL) כדי להגדיר אילו ממשקי תכנות ישתמשו ב-Binder לצורכי IPC. מידע נוסף מפורט בסקירה הכללית בנושא AIDL.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-09-03 (שעון UTC).
[[["התוכן קל להבנה","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-09-03 (שעון UTC)."],[],[],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."]]
