- Release Notes and Announcements
- Product Introduction
- Getting Started
- Guidelines for Code Integration
- Android
- Android SDK Description
- Android API
- Android SDK Description
- Android FAQs
- Android Error Codes
- Android Privacy Compliance
- Android SDK Updates
- Get Demo and SDK
- Accessing via iOS Devices
- Accessing with Flutter
- Android
- Guide to Mini Program Development
- Mini program introduction and development environment
- Mini program code composition
- Framework
- API
- API Overview
- Fundamentals
- Routing
- Redirect
- Forwarding
- Interface
- Network
- Data Caching
- Data Analysis
- canvas
- Media
- WXML
- File
- Device
- Contact person
- Vibration
- Battery Level
- Screen
- Memory
- Device Orientation
- Accessibility
- Network
- Keyboard
- Phone number
- Accelerometer
- Compass
- Gyroscope
- SMS
- Code scanning
- Encryption
- NFC－Ndef
- NFC－NfcA
- NFC－NfcB
- NFC－NfcF
- NFC－NfcV
- WiFi
- Calendar
- Clipboard
- NFC－getNFCAdapter
- NFC－NFCAdapter
- NFC－IsoDep
- NFC－MifareClassic
- NFC－MifareUltralight
- Bluetooth - Low Energy Central Device
- Bluetooth - Low Energy Peripheral Device
- Bluetooth - Beacon
- Bluetooth - General
- Location
- Open Interfaces
- Custom APIs
- Sensitive API
- Components
- Open source component statement
- FAQs
- Agreements
- Release Notes and Announcements
- Product Introduction
- Getting Started
- Guidelines for Code Integration
- Android
- Android SDK Description
- Android API
- Android SDK Description
- Android FAQs
- Android Error Codes
- Android Privacy Compliance
- Android SDK Updates
- Get Demo and SDK
- Accessing via iOS Devices
- Accessing with Flutter
- Android
- Guide to Mini Program Development
- Mini program introduction and development environment
- Mini program code composition
- Framework
- API
- API Overview
- Fundamentals
- Routing
- Redirect
- Forwarding
- Interface
- Network
- Data Caching
- Data Analysis
- canvas
- Media
- WXML
- File
- Device
- Contact person
- Vibration
- Battery Level
- Screen
- Memory
- Device Orientation
- Accessibility
- Network
- Keyboard
- Phone number
- Accelerometer
- Compass
- Gyroscope
- SMS
- Code scanning
- Encryption
- NFC－Ndef
- NFC－NfcA
- NFC－NfcB
- NFC－NfcF
- NFC－NfcV
- WiFi
- Calendar
- Clipboard
- NFC－getNFCAdapter
- NFC－NFCAdapter
- NFC－IsoDep
- NFC－MifareClassic
- NFC－MifareUltralight
- Bluetooth - Low Energy Central Device
- Bluetooth - Low Energy Peripheral Device
- Bluetooth - Beacon
- Bluetooth - General
- Location
- Open Interfaces
- Custom APIs
- Sensitive API
- Components
- Open source component statement
- FAQs
- Agreements
Why use multi-process for Android SDK?
The Android runtime SDK uses a multi-process mechanism, where the mini-program and the host app run in separate processes. The processes do not interfere with each other and transfer data through cross-process communication. This approach offers several benefits:
Does not occupy the memory of host app The system allocates separate memory for the mini program process, preventing memory overflow issues in the host app.
Ensure safe and stable operation of the host App Any exceptions in the mini program process do not affect the host app, ensuring continuous operation even if the mini program crashes.
Data decoupling Processes are naturally isolated in memory, preventing direct data access between processes and avoiding data coupling issues.
How is multi-process implemented?
Android does not provide APIs for dynamic process creation. Instead, processes are created by binding them to Activities using the android:process attribute in AndroidManifest.xml. When an Activity is first launched, the system creates a new process and assigns the Activity to it.
To enhance user experience, different mini programs are displayed in separate positions in the recent tasks list. This is achieved by setting the android:taskAffinity attribute in AndroidManifest.xml, placing Activities of different mini-program processes in separate task stacks.
How to manage mini program processes?
The SDK can create up to 5 mini program processes simultaneously. If the number of mini program processes is below this limit, each new mini program will start in a new process. Once the limit is reached, any additional mini programs will reuse existing processes.
When opening the same mini program, the SDK first checks if it is already running. If it is, the corresponding process is reactivated.
The main process handles the creation, reuse, and activation of mini program processes, managing all these operations centrally.
How does mini program processes communicate with the main process?
Bidirectional communication between mini program processes and the host process is achieved using AIDL (Android Interface Definition Language). Both the mini program and main processes bind to the same remote service. Through the Binder mechanism, they obtain a proxy object for the service, which allows them to call AIDL interfaces for inter-process communication.
How to ensure process and thread security
Currently, all resources that need to be written during the mini program's runtime are stored in the application's sandbox directory specific to the mini program. This setup avoids writing to globally shared resources, thus eliminating inter-process competition for the same system resources. For potential process security issues, we use process-safe methods for reading and writing data during development, such as file locks for file access and ContentProvider instead of SharedPreferences for data sharing.
There are no direct thread security issues between processes. Thread security concerns arise only when different mini program processes concurrently access the main process's memory via inter-process communication or when there is concurrent read/write access within a process. The SDK addresses these thread security issues using locks, synchronized methods, and Java concurrency utilities.
Yes
No
Was this page helpful?