קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
פרויקט עם כמה מודולים של Gradle נקרא פרויקט מרובה מודולים. המדריך הזה כולל שיטות מומלצות ודפוסים מומלצים לפיתוח אפליקציות Android מרובות מודולים.
הבעיה של בסיס קוד הולך וגדל
בבסיס קוד שהולך וגדל, יכולת ההרחבה, הקריאות ואיכות הקוד הכוללת לרוב יורדות עם הזמן. הסיבה לכך היא שגודל בסיס הקוד גדל, אבל המפתחים לא נקטו אמצעים פעילים כדי לאכוף מבנה שקל לתחזק. מודולריזציה היא דרך לבנות את בסיס הקוד כך שיהיה קל יותר לתחזק אותו ולמנוע את הבעיות האלה.
מהי מודולריות?
מודולריזציה היא שיטה לארגון בסיס קוד לחלקים עצמאיים עם צימוד רופף. כל חלק הוא מודול. כל מודול הוא עצמאי ומיועד למטרה ברורה. כשמחלקים בעיה לבעיות משנה קטנות יותר וקלות יותר לפתרון, אפשר לצמצם את המורכבות של תכנון מערכת גדולה ותחזוקה שלה.
תרשים 1: גרף תלות של בסיס קוד לדוגמה עם כמה מודולים
היתרונות של מודולריזציה
יש הרבה יתרונות למודולריזציה, אבל כולם מתמקדים בשיפור התחזוקה והאיכות הכוללת של בסיס קוד. בטבלה הבאה מפורטים היתרונות העיקריים.
הטבות
סיכום
שימוש חוזר
מודולריזציה מאפשרת לשתף קוד ולבנות כמה אפליקציות על בסיס אותה תשתית. מודולים הם למעשה אבני בניין. האפליקציות צריכות להיות סכום התכונות שלהן, כשהתכונות מאורגנות כמודולים נפרדים. יכול להיות שפונקציונליות מסוימת שמספק מודול מסוים תופעל באפליקציה מסוימת, ויכול להיות שלא. לדוגמה, :feature:news יכול להיות חלק מהגרסה המלאה של האפליקציה ל-Wear, אבל לא חלק מגרסת ההדגמה.
שליטה קפדנית בהרשאות הגישה
מודולים מאפשרים לכם לשלוט בקלות במה שאתם חושפים לחלקים אחרים ב-codebase. כדי למנוע שימוש בכל מה שאינו הממשק הציבורי מחוץ למודול, אפשר לסמן את כל השאר כ-internal או כ-private.
משלוח בהתאמה אישית
Play Feature Delivery משתמשת ביכולות המתקדמות של חבילות אפליקציות, ומאפשרת לכם לספק תכונות מסוימות של האפליקציה בתנאי או לפי דרישה.
אפשר ליהנות מהיתרונות של מודולריזציה רק אם בסיס הקוד מודולרי.
אפשר להשיג את היתרונות הבאים גם בטכניקות אחרות, אבל מודולריזציה יכולה לעזור לכם ליישם אותם בצורה טובה יותר.
הטבות
סיכום
מדרגיות
בבסיס קוד עם צימוד הדוק, שינוי יחיד יכול להפעיל שרשרת של שינויים בחלקים של הקוד שנראים לא קשורים. פרויקט עם מודולריות נכונה יתבסס על העיקרון של הפרדת דאגות, ולכן יגביל את הצימוד. כך המשתתפים מקבלים יותר אוטונומיה.
בעלות
בנוסף להפעלת אוטונומיה, אפשר להשתמש במודולים גם כדי לאכוף אחריות. לכל מודול יכול להיות בעלים ייעודי שאחראי על תחזוקת הקוד, תיקון באגים, הוספת בדיקות ובדיקת שינויים.
אנקפסולציה
המשמעות של הכמסה היא שלכל חלק בקוד צריך להיות מינימום ידע על חלקים אחרים. קל יותר לקרוא ולהבין קוד מבודד.
יכולת בדיקה
המונח 'יכולת בדיקה' מתאר עד כמה קל לבחון את הקוד. בסיס קוד שאפשר לבדוק הוא כזה שאפשר לבדוק את הרכיבים שלו בקלות בבידוד.
Build time
חלק מהפונקציות של Gradle, כמו בנייה מצטברת, מטמון בנייה או בנייה מקבילה, יכולות להשתמש במודולריות כדי לשפר את ביצועי הבנייה.
טעויות נפוצות
הגרנולריות של בסיס הקוד היא המידה שבה הוא מורכב ממודולים. בבסיס קוד עם רמת פירוט גבוהה יותר יש יותר מודולים קטנים יותר. כשמעצבים בסיס קוד מודולרי, צריך להחליט על רמת הפירוט. כדי לעשות את זה, צריך לקחת בחשבון את הגודל של בסיס הקוד ואת רמת המורכבות היחסית שלו. חלוקה ליחידות קטנות מדי תגרום לעומס יתר, וחלוקה ליחידות גדולות מדי תפחית את היתרונות של המודולריזציה.
אלה כמה מהטעויות הנפוצות:
גרנולריות גבוהה מדי: כל מודול מוסיף עומס מסוים בצורה של מורכבות גבוהה יותר של הבנייה וקוד boilerplate. הגדרות מורכבות של build מקשות על שמירה על עקביות ההגדרות בין המודולים. יותר מדי קוד סטנדרטי
יוצר בסיס קוד מסורבל שקשה לתחזק. אם התקורה מבטלת את השיפורים בסקיילביליות, כדאי לשקול לאחד כמה מודולים.
גרנולריות גסה מדי: מצד שני, אם המודולים גדלים יותר מדי, יכול להיות שתקבלו עוד מונוליט ותפספסו את היתרונות של המודולריות. לדוגמה, בפרויקט קטן אפשר להציב את שכבת הנתונים בתוך מודול יחיד. אבל כשהוא גדל, יכול להיות שיהיה צורך להפריד בין מאגרי המידע ומקורות הנתונים למודולים עצמאיים.
מורכב מדי: לא תמיד כדאי להפוך את הפרויקט למודולרי. אחד הגורמים המשפיעים ביותר הוא גודל בסיס הקוד. אם אתם לא צופים שהפרויקט יגדל מעבר לסף מסוים, היתרונות של יכולת ההתאמה והזמן שנדרש לבנייה לא יחולו.
האם מודולריזציה היא השיטה הנכונה בשבילי?
אם אתם רוצים ליהנות מהיתרונות של שימוש חוזר, שליטה קפדנית בחשיפה או שימוש ב-Play Feature Delivery, מודולריזציה היא חובה בשבילכם. אם לא, אבל אתם עדיין רוצים ליהנות משיפורים במדרגיות, בבעלות, באנקפסולציה או בזמני בנייה, כדאי לשקול מודולריזציה.
טעימות
Now in Android – אפליקציה ל-Android שפועלת באופן מלא וכוללת מודולריזציה.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-08-17 (שעון 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-08-17 (שעון UTC)."],[],[],null,["# Guide to Android app modularization\n\nA project with multiple Gradle modules is known as a multi-module project. This\nguide encompasses best practices and recommended patterns for developing\nmulti-module Android apps.\n| **Note:** This page assumes a basic familiarity with the [recommended app\n| architecture](/topic/architecture).\n\nThe growing codebase problem\n----------------------------\n\nIn an ever-growing codebase, scalability, readability, and overall code quality\noften decrease through time. This comes as a result of the codebase increasing\nin size without its maintainers taking active measures to enforce a structure\nthat is easily maintainable. Modularization is a means of structuring your\ncodebase in a way that improves maintainability and helps avoid these problems.\n\nWhat is modularization?\n-----------------------\n\nModularization is a practice of organizing a codebase into loosely coupled and\nself contained parts. Each part is a module. Each module is independent and\nserves a clear purpose. By dividing a problem into smaller and easier to solve\nsubproblems, you reduce the complexity of designing and maintaining a large\nsystem.\n**Figure 1**: Dependency graph of a sample multi-module codebase\n\nBenefits of modularization\n--------------------------\n\nThe benefits of modularization are many, though they each center upon improving\nthe maintainability and overall quality of a codebase. The following table\nsummarizes the key benefits.\n\n| Benefit | Summary |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Reusability | Modularization enables opportunities for code sharing and building multiple apps from the same foundation. Modules are effectively building blocks. Apps should be a sum of their features where the features are organized as separate modules. The functionality that a certain module provides may or may not be enabled in a particular app. For example, a `:feature:news` can be a part of the full version flavor and wear app but not part of the demo version flavor. |\n| Strict visibility control | Modules enable you to easily control what you expose to other parts of your codebase. You can mark everything but your public interface as `internal` or `private` to prevent it from being used outside the module. |\n| Customizable delivery | [Play Feature Delivery](/guide/playcore/feature-delivery) uses the advanced capabilities of app bundles, allowing you to deliver certain features of your app conditionally or on demand. |\n\nThe benefits of modularization are only achievable with a modularized codebase.\nThe following benefits might be achieved with other techniques but\nmodularization can help you enforce them even more.\n\n| Benefit | Summary |\n|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Scalability | In a tightly coupled codebase a single change can trigger a cascade of alterations in seemingly unrelated parts of code. A properly modularized project will embrace the [separation of concerns](https://en.wikipedia.org/wiki/Separation_of_concerns) principle and therefore limit the coupling. This empowers the contributors through greater autonomy. |\n| Ownership | In addition to enabling autonomy, modules can also be used to enforce accountability. A module can have a dedicated owner who is responsible for maintaining the code, fixing bugs, adding tests, and reviewing changes. |\n| Encapsulation | Encapsulation means that each part of your code should have the smallest possible amount of knowledge about other parts. Isolated code is easier to read and understand. |\n| Testability | Testability characterizes how easy it is to [test](/training/testing) your code. A testable codebase is one where components can be easily tested in isolation. |\n| Build time | Some Gradle functionalities such as incremental build, build cache or parallel build, can leverage modularity to [improve build performance](/studio/build/optimize-your-build). |\n\nCommon pitfalls\n---------------\n\nThe granularity of your codebase is the extent to which it is composed of\nmodules. A more granular codebase has more, smaller modules. When designing a\nmodularized codebase, you should decide on a level of granularity. To do so,\ntake into account the size of your codebase and its relative complexity. Going\ntoo fine-grained will make the overhead a burden, and going too coarse will\nlessen the benefits of modularization.\n\nSome common pitfalls are as follows:\n\n- **Too fine-grained** : Every module brings a certain amount of overhead in the form of increased build complexity and [boilerplate code](https://en.wikipedia.org/wiki/Boilerplate_code). A complex build configuration makes it difficult to [keep configurations consistent](/topic/modularization/patterns#consistent-configuration) across modules. Too much boilerplate code results in a cumbersome codebase that is difficult to maintain. If overhead counteracts scalability improvements, you should consider consolidating some modules.\n- **Too coarse-grained**: Conversely, if your modules are growing too large you might end up with yet another monolith and miss the benefits that modularity has to offer. For example, in a small project it's ok to put the data layer inside a single module. But as it grows, it might be necessary to separate repositories and data sources into standalone modules.\n- **Too complex**: It doesn't always make sense to modularize your project. A dominating factor is the size of the codebase. If you don't expect your project to grow beyond a certain threshold, the scalability and build time gains won't apply.\n\nIs modularization the right technique for me?\n---------------------------------------------\n\nIf you need the benefits of reusability, strict visibility control or to use the\n[Play Feature Delivery](/guide/playcore/feature-delivery), then modularization is a necessity for you. If you\ndon't, but still want to benefit from improved scalability, ownership,\nencapsulation, or build times, then modularization is something worth\nconsidering.\n\nSamples\n-------\n\n- [Now in Android](https://github.com/android/nowinandroid) - fully functional Android app featuring modularization.\n- [Multi module architecture sample](https://github.com/android/architecture-samples/tree/multimodule)"]]
