Deprecated API Migration
Deprecated API Migration Process
- Identify deprecated APIs: Check for deprecation warnings during compilation and confirm the replacement APIs.
- Evaluate the migration impact: Analyze the differences in API parameters, return values, and semantic differences.
- Write migration code: Replace the deprecated API calls and adapt to the new API parameters.
- Test and verification: Ensure that the functions are correct and the performance meets expectations after the migration.
Migration Example: aclrtQueryEvent -> aclrtQueryEventStatus
// Deprecated API (old code).
aclrtEventStatus status;
aclrtQueryEvent(event, &status);
if (status == ACL_EVENT_STATUS_COMPLETE) {
// ...
}
// Replacement API (new code).
aclrtEventRecordedStatus status;
aclrtQueryEventStatus(event, &status);
if (status == ACL_EVENT_RECORDED_STATUS_COMPLETE) {
// ...
}
Recommended
- Regularly checking compilation warnings: Handle deprecated API warnings promptly to avoid accumulation.
- Preferentially using new APIs: New APIs usually have better semantics, performance, or functionality.
- Recording version information: Record the Runtime version when the application starts, thus facilitating fault locating.
- Preferring feature detection over versions: Use the feature query API instead of hardcoded version numbers to query capabilities.
- Encapsulating version adaptation logic: Centralize compatibility logic at the adaptation layer to facilitate maintenance.
Not recommended
- Ignoring deprecation warnings: Deprecated APIs may be removed in future versions, leading to compilation failures.
- Hard-coding version checks: Version checking lacks flexibility. Use feature detection instead.
- Mixing old and new APIs: Use either the new or old APIs consistently within the same functional module to avoid confusion.
- Assuming that API semantics remain unchanged: During migration, carefully read the new API documentation to ensure semantic consistency.
Parent topic: Compatibility Handling