预测用户在将来的会话中对该功能的需求。如果您不需要应用立即下载并安装按需模块,可以将安装操作延迟到应用在后台运行时再执行,并且 Google Play 会为您处理下载和安装操作。例如,假设您要在烹饪应用中推出新的季节性食谱,这些食谱在用户的当前会话中优先级并不高。您可以请求 Play 在该应用于后台运行时下载并安装这些食谱。这对于当时不需要但将来很可能需要的较大功能(大于 10MB)特别有用。
在安装应用之前预测用户对某项功能的需求。您可能希望添加对按条件分发的支持,以便在安装时根据用户所在国家/地区、设备硬件功能和 API 级别包含您的功能。例如,您可能希望将使用猪肉的食谱包含在按条件分发的模块中,并在大多数人忌吃猪肉的地区从应用安装中省略该模块。
[[["易于理解","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"]],["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# UX best practices for on demand delivery\n\nThe functionality that works well as an on demand module are those that aren't\nneeded by the majority of your users at install time. The following are a\nfew examples for app features that would appropriate on demand modules:\n\n- Editing and uploading a video in an app where the majority of users only watch videos\n- Adding a recipe in an app, where most users only browse and follow others' recipes\n- Help and support functionality when most users don't seek help, or don't seek it within the app\n- Large libraries for less used functionality such as providing detailed bug capture and reporting\n- Specific payment or checkout capabilities\n- Very high-resolution media experiences or VR/AR features\n\nIn the typical case where these modules are relatively small (less than 10MB),\nand there aren't any network or other failures, users can download and use an\non demand module very quickly. That is, the experience is typically no different\nthan if the module had been present at app install.\n\nThis page describes best practices that help you do the following:\n\n- Ensure your users are aware and feel in control of relatively larger module downloads which don't load instantly, or module install errors.\n- Further optimize the module delivery experience, especially in situations where you can anticipate that a user will need a particular module.\n\nAfter you've read through this guide, see these best practices in action by\ntrying the\n[Play Core API sample app](https://github.com/android/app-bundle-samples/tree/main/DynamicFeatures).\n\nKeep the user informed\n----------------------\n\nYou should inform the user when a feature is not immediately available. If a\nuser decides to download the feature from Google Play, display the progress of\nthe download.\n\nYou can [monitor the request state](/guide/playcore/feature-delivery/on-demand#monitor_requests)\nto display the download progress and install state. However, the type of UI you\nwant to display might depend on the size of the download:\n\n- For smaller modules (\\~10 MB or less) that can be installed very quickly, consider indicators such as spinners or a brief \"downloading content\" message.\n- For larger modules that can take a few seconds or longer to download and install, consider showing a download and install progress bar, such as the one shown in figure 1.\n\n\n**Figure 1.** Displaying a message and progress bar\nwhen downloading and installing an on demand feature\n\n\u003cbr /\u003e\n\nCommunicate installation delays and failures gracefully\n-------------------------------------------------------\n\nIf a download fails or progresses slower than expected, clearly and\ntransparently communicate to the user what's going on and what, if anything,\nthey can do, as shown in figures 2 and 3. For example, if you\n[monitor the state of the download request](/guide/playcore/feature-delivery/on-demand#monitor_requests),\nand your app receives a `API_NOT_AVAILABLE` error, notify the user that their\ndevice doesn't support on demand downloads. \n\n\n**Figure 2.** Let the user know why a feature cannot be installed at\nthis time \n\n\n**Figure 3.** Explain to the user why a feature might be taking longer\nthan expected to download\n\nShow value before permission is requested for large downloads\n-------------------------------------------------------------\n\nIf an on demand module is large (\\\u003e 150MB), Google Play requires that the user\nfirst consent before downloading it.\n\nBefore you request the module, explain the value of the module to your users.\nHelp them understand why you're making this request of them, as you would when\nrequesting app permissions. Communicating openly with users increases the\nlikelihood that they will accept the download.\n\nFor example, imagine you're building an e-commerce app and one of the\nfeatures allows users to place furniture directly within their apartment using\nAugmented Reality (AR). You might include a message such as, \"Would you like to\nsee your new sofa in your living room? Install the augmented reality viewer\nnow.\"\n\nPerform download and install in the background\n----------------------------------------------\n\nModule download and installation should always occur in the background. That is,\nwhile a user is waiting for a feature to become available, you should allow them\nto continue using other parts of your app. And, when the feature is available,\nyou should provide a notification that allows the user to switch to using that\nfeature at their discretion.\n\nAs shown in figure 5, the user continues to use the app and receives a\nnotification when the installation of an on demand feature is complete.\n\n\n**Figure 5.** Rather than changing the user's context suddenly when a module\ninstallation is complete, notify the user that the requested feature is ready\nfor them.\n\n\u003cbr /\u003e\n\nWhen the module is ready to use, notify the user and give them the choice\nwhether to launch the feature. This pattern provides the user with context and\ncontrol over their experience.\n\nIn some cases, you *could* launch the feature as soon as it's ready. However,\nbecause it might interrupt the user's experience, carefully consider whether\nthis behavior is expected and appropriate.\n\nFree up device storage when a module is no longer needed\n--------------------------------------------------------\n\nA useful capability of all feature modules is the ability to uninstall\nthem, individually. If a feature module is no longer being used, you can reduce\nthe size of your app on a user's device by requesting Google Play to\n[uninstall that module](/guide/playcore/dynamic-delivery#uninstall_modules).\n\nFor example, your app may have a robust onboarding flow, perhaps containing rich\nmedia. After a user has completed the onboarding flow, or after they've been\nactive users for a certain amount of time, you can use the Play Feature Delivery API\nto request Google Play uninstall only that component of your app.\n\nKeep in mind, you can also later uninstall modules that you include at initial\napp install. For example, a module that trains new users on how to use your app\nis valuable when users first use your app. However, to reduce app size, you can\nthen uninstall it after they've completed the training.\n\nAdvanced tips\n-------------\n\nTypically, you need to handle situations where the user explicitly signals\nintent to use the functionality of your on demand feature modules.\n\nHowever, you might want to predict when a user is likely to engage with a\nfeature *before* they signal to you that they want to use it. Using an app that\nallows you to download and create cooking recipes as an example, the following\nguidelines describe how to optimize the module delivery experience by\nanticipating user needs.\n\n**Anticipate a user's need for a feature in the current session**. Consider if\nusers only need to create an account for the recipe app when they want to create\nand share their own recipes with the community. You can use the account creation\nas a signal that the user is likely to want to add their own recipe start\ndownloading the feature module before the user even taps on 'add recipe'. You\ncan apply this approach to other user journeys in the app to make the feature\ndownload process more seamless.\n\n**Anticipate a user's need for the feature in an upcoming session**. If you do\nnot need your app to immediately download and install an on demand module, you\ncan defer installation for when the app is in the background, and Google Play\nwill handle the download and install for you. For example, imagine that you want\nto release new seasonal recipes for the cooking app, which aren't a high\npriority for the user's current session. You can request for Play to download\nand install these recipes when the app is in the background. This is especially\nuseful for larger features (\\\u003e10MB) which aren't needed right away but will\nlikely be needed in the future.\n| **Note:** Requests for deferred installs are best-effort and you cannot track their progress. Before trying to access a module you had marked for deferred installation, [check that the module has been installed](/guide/playcore/feature-delivery/on-demand#manage_installed_modules). If it hasn't, you can always install it on-demand at that time.\n\n**Anticipate a user's need for a feature ahead of app installation** . You might\nwant to\n[add support for conditional delivery](/studio/projects/dynamic-delivery/conditional-delivery)\nto include your feature at install time based on user country, device hardware\ncapability, and API level. For example, you might want to include recipes that\nuse pork in conditional modules and omit that module from app install in regions\nthat predominantly avoid pork dishes."]]