Native code with the NDK can handle heavy tasks that Java code handles slowly. Image processing and audio processing and physics simulation benefit from native speed. Poor native code can still waste that advantage. This guide explains seven optimisations that make native tasks faster without changing the feature. Each optimisation targets a common native pattern.
Start by profiling the native task before you optimise. A profiler shows which function consumes the most time. A guess about native speed often points to the wrong function. Record the task time before each change. A measured baseline proves whether an optimisation helped.
Optimise one function at a time and test after each change. Native changes can introduce crashes that are hard to trace. A single change makes a crash easy to locate. Keep a log of each change and its measured effect. A log helps code review and it helps future optimisation work.
Use Efficient Loops And Data Layout
Loops dominate many native tasks. A loop that accesses memory in a scattered pattern runs slowly. A loop that accesses memory in order runs faster because the processor can predict the next access. Arrange data so the loop reads in order. A simple layout change can beat a complex algorithm change for memory heavy tasks.
Avoid function calls inside tight loops when a direct calculation works. A call inside a loop adds overhead on every iteration. Move invariant calculations outside the loop. An invariant value does not change during the loop so computing it once is safe. A loop with fewer calls and fewer branches runs more predictably.
- Profile the native task before optimising
- Access memory in order inside loops
- Move invariant work outside tight loops
- Avoid calls inside hot loops when possible
- Test one change at a time
Reduce Allocations In Native Code
Native allocations cost time and they can fragment memory. A function that allocates on every call adds pressure during repeated tasks. Reuse buffers for repeated work when the buffer size is predictable. Clear the buffer before reuse rather than allocating a new one. A reused buffer keeps a steady memory footprint.
Check for hidden allocations in library calls. A library function may allocate a temporary buffer for each call. A wrapper that reuses a buffer can avoid that cost when the library allows it. Test buffer reuse carefully because a reused buffer must not leak data between calls. Clear sensitive data from reused buffers after use.
Allocation work also relates to the profiler material on debugging memory leaks with Profiler. A native allocation pattern that grows over time can look like a leak in a heap dump. Compare native memory use across repeated tasks to separate a leak from a temporary spike. A stable native footprint after repeated tasks is a good sign.
Use Threads For Parallel Tasks
Parallel tasks benefit from multiple threads on multi-core devices. Split a large image task into independent tiles. Process each tile on a separate thread. Combine results after all threads finish. A tiled task can run several times faster on a modern phone. A task with dependencies between parts needs more careful splitting.
Balance thread count with device core count. Too many threads can cause overhead from switching. Too few threads leave cores idle. Test thread counts on a mid-range device and on a flagship device. A thread count that helps both device classes is a safe default. Make the count adjustable for future devices.
Choose The Right Compiler Settings
Compiler settings affect native speed significantly. An optimisation level that favours speed can produce faster code than a debug level. Test release settings on a test device before you ship. A setting that speeds up one function may slow another function. Measure the whole task rather than a single function when you change compiler settings.
Enable processor specific optimisations only when you know the target devices. A setting for a newer processor may fail on an older device. Use separate builds per processor type when a specific optimisation matters. Test each build on its target device type. A build that crashes on an older device is worse than a slightly slower build that runs everywhere.
Avoid Unnecessary Copies
Copies waste time when a function can work on original data. Pass large buffers by reference rather than by value. Avoid copying an image for a filter that can work in place. An in-place filter needs care to avoid overwriting data that later steps need. Test in-place work with edge inputs to confirm correctness.
Check data transfers between Java and native code. Each transfer can copy data across the boundary. A large array transfer on every frame adds overhead. Share a direct buffer when the platform allows it. A shared buffer avoids a copy and it keeps Java and native views in sync.
Use Vector Instructions Carefully
Vector instructions process several values at once. They can speed up image and audio tasks dramatically. They need data alignment and careful handling of edge elements. A vector loop must handle the remaining elements that do not fill a full vector. Test vector code with sizes that are not multiples of the vector width.
Use vector code only when profiling shows a clear gain. Vector code is harder to read and harder to debug than scalar code. A small gain does not justify the added complexity. A large gain on a hot task does justify it. Document vector code clearly so future readers understand the edge handling.
Measure On Real Devices
Measure native tasks on real devices with realistic data. An emulator can hide native performance differences. A flagship device can hide problems that appear on a mid-range device. Test the task time on both device classes. A fix that helps both classes is a strong fix.
Test with realistic input sizes. A small test image may run fast while a large camera image runs slowly. Use production sized inputs for final measurements. A realistic test reveals loop and memory problems that small tests hide. Fix those problems before release.
for (int i = 0; i < count; i++) {
data[i] = data[i] * 2;
}The snippet above is an original example written for this guide. It shows generic native loop code that you can adapt to your own task. It does not copy code from any outside source.
The snippet shows a simple loop that processes data in order. Use it as a reference for memory friendly loop design. Expand the pattern only after you measure the simple case.
Profile Native Code With Real Workloads
Native profiling needs workloads that match real user tasks. A synthetic benchmark with a small data set can mislead optimisation work. A real workload with a full camera image or a full audio track shows the true hot function. Build a test harness that feeds real inputs to the native task. Record the task time for each input size. A profile from real inputs guides optimisation to the code that users actually run.
Compare native profiles across device types. A function that dominates on a flagship device may not dominate on a mid-range device. A mid-range device has slower memory and fewer cores. A profile from both device classes reveals which optimisation helps most users. A fix that helps a flagship device only is less valuable than a fix that helps both classes. Prioritise fixes by their effect on the slower device.
Profile native memory use alongside time. A fast function that allocates heavily can cause pressure that slows the whole app. A memory profile shows allocation patterns during the task. A task that allocates and frees repeatedly may benefit from a reused buffer. A task that grows memory steadily may have a native leak. Time and memory profiles together give a complete picture of native health.
Repeat profiling after each optimisation to confirm the gain. A change that looks good in theory may not help in practice. A repeat profile proves the effect and it reveals new hot functions that appear after the first fix. Optimisation is iterative and each iteration needs a fresh profile. A team that profiles after every change avoids wasted work on theories that do not help.
Share native profiles with the team in a readable form. A profile summary should name the hottest function and its share of total time. It should also name the input size and the device used. A summary without device and input context is hard to interpret. Context turns a profile into evidence that the whole team can act on.
Common Mistakes
A common mistake is optimising native code without profiling. A guess can waste time on a function that rarely runs. Profile first and optimise the hottest function. A measured target gives the largest gain.
Another mistake is adding threads to a task with hidden dependencies. Dependent parts cannot run in parallel safely. Split only independent parts across threads. Test parallel results against serial results for correctness.
Some developers also copy large buffers on every call. Copies add overhead that can erase native speed gains. Pass buffers by reference and share direct buffers where possible. A copy-free path is often the fastest path.
Finally do not use processor specific settings without testing target devices. A setting for a new processor can crash an older device. Test each build on its target device type. Compatibility matters more than a small speed gain.
Frequently Asked Questions
When should I use native code?
Use native code for heavy tasks such as image and audio processing. Use Java or Kotlin for most app logic. Native code adds complexity so use it only where profiling shows a clear need.
Do threads always speed up native tasks?
No threads help only for independent parts of a task. Dependent parts need careful design. Test parallel results for correctness and speed before you keep threading.
Can compiler settings replace code optimisation?
No compiler settings help but they cannot fix a poor algorithm or a bad memory pattern. Fix data layout and loop design first. Then tune compiler settings for extra gain.
Conclusion
Native performance improves with ordered memory access and fewer allocations and careful threading. Use compiler settings wisely and avoid unnecessary copies. Measure on real devices with realistic data. Your concrete next step is to profile your heaviest native task today and fix its hottest loop with one optimisation from this guide. Measure the result and then move to the next function. For related work you can study native inline C++ hooks and debugging memory leaks with Profiler and Kotlin performance fixes as next steps.
