AI 在 React Native 中無法做到的 5 件事

1. Compute and Power Constraints

Mobile CPUs/GPUs are orders of magnitude slower than datacenter hardware. Running complex models continuously can overheat devices and deplete batteries. For example, on-device object detection may take tens of milliseconds per frame, far slower than server GPUs. One case study found that enabling GPU delegation reduced inference from ~28 ms to ~11 ms per image, illustrating how hardware accelerators help but only partially bridge the gap. In practice, heavy inference slows the UI and degrades UX. Developers must mitigate this by using quantized (INT8) or pruned models, leveraging mobile NN accelerators (NNAPI on Android, Metal on iOS), and limiting workload (e.g. reducing camera frame rate or downscaling images). Offloading to edge/ cloud (e.g. sending data to a server) avoids local load but adds network latency. In sum, AI features that demand high throughput or low latency (e.g. real-time video analysis) are often beyond pure on-device execution.

2. Model Size and Architecture

State-of-the-art AI (LLMs, deep vision nets) contains hundreds of megabytes or more. Mobile storage is limited and models can’t be compressed by standard obfuscation. Large models inflate app size and may not fit in RAM. In one comparison, TensorFlow Lite’s library was ~20 MB smaller than PyTorch Mobile’s (minimized) binary, underscoring how framework choice affects footprint. Very large models simply won’t load on most devices. This means some AI tasks (e.g. on-device GPT-3) are infeasible. Mitigations include using compact models (MobileNet, DistilBERT) or on-device-specialized frameworks (LiteRT/TFLite, Core ML) that optimize size and performance. Techniques like pruning and quantization shrink models. Developers may also download models on demand or load from storage if necessary. Nonetheless, any feature requiring a “heavy” model forces trade-offs (e.g. degrade to simpler heuristic, or rely on cloud inference).

3. Connectivity and Latency

Complex AI often needs backend support. For large models or up-to-date data (e.g. user personalization), cloud APIs are used. But sending images or audio adds round-trip delays and requires bandwidth. One developer notes that even fast cloud inference suffers “massive overhead” serializing data, transmitting it, and encrypting it. Without a network (offline mode), these AI features fail outright. Conversely, on-device inference avoids connectivity needs and protects privacy, but then accuracy/complexity may suffer. A practical strategy is hybrid (“edge vs cloud”): run lightweight models locally and escalate harder tasks to the cloud if connected. Caching previous results, using quantized models for offline fallback, or pre-downloading data (e.g. language packs) can help. For non-real-time tasks, background syncing to the cloud when on Wi-Fi is another pattern. In short, AI features must gracefully degrade when offline or slow, for UX continuity.

4. Integration and Platform Constraints

React Native does not natively run AI models in JavaScript at production speeds. Developers must integrate ML frameworks via native modules or JSI. As one example showed, implementing a TFLite image classifier in React Native required ~50 lines of Android (Kotlin) and iOS (Swift) code to preprocess frames and invoke the interpreter each time. This bridging adds development complexity and can be a maintenance burden. Cross-platform differences compound it: Android typically uses LiteRT/TFLite or PyTorch Mobile, while iOS favors Core ML or Metal-based inference. Code must handle both paths. Moreover, traditional RN bridge calls are asynchronous and could add latency; the new Hermes/JSI architecture (as used in react-native-vision-camera) helps by running code as native “worklets” to cut overhead. Still, any bug in the native side can crash the app. Developers mitigate integration pain by relying on well-maintained libraries (e.g. react-native-tflite, react-native-vision-camera frame processors) and using architecture patterns that isolate ML logic. Employing Hermes or TurboModules also improves performance. But in general, RN’s JavaScript core cannot perform heavy AI by itself – native collaboration is required.

5. Privacy and Security

AI features often process sensitive data (camera, microphone, personal info). Offloading to the cloud risks leaking user data unless encrypted – and even then, trust is a concern. On-device ML “avoids sending user-private data through the network”, which is great for privacy (e.g. facial analysis can stay local). However, embedding models on the device introduces intellectual property risk: attackers could extract or reverse-engineer your model. Studies warn that on-device ML models are targets for extraction attacks, exposing both the model and possibly training data. Developers should weigh these: for highly sensitive data (health, finance) on-device inference is safer for users, whereas for proprietary models cloud execution can better protect model IP. Mitigations include on-device encryption of model files, obfuscating code, or using secure enclaves/TrustZones. In either case, clear user consent and compliance (GDPR, etc.) are essential.

Custom Native Modules & Bridging (TurboModules)

React Native’s native modules require manual specification and binding code. For example, creating a TurboModule involves writing a typed specification in TypeScript or Flow, running RN’s Codegen, and implementing native code on each platform. AI can generate a basic template, but it cannot reliably configure the native build environment or resolve platform-specific details. Official docs emphasize that a TurboModule is defined by “your specification, the native code you write, and the Codegen interfaces generated from your specification”.

// specs/NativeLocalStorage.ts (TypeScript spec for a TurboModule)
import type {TurboModule} from 'react-native';
import {TurboModuleRegistry} from 'react-native';

export interface Spec extends TurboModule {
  setItem(value: string, key: string): void;
  getItem(key: string): string | null;
  removeItem(key: string): void;
  clear(): void;
}
export default TurboModuleRegistry.getEnforcing<Spec>('NativeLocalStorage');

Beyond codegen, many subtleties arise. For instance, Apple’s Swift language cannot call C++ (JSI) APIs directly, so bridging requires an Objective-C++ “glue” layer. React Native’s documentation specifically notes that iOS Swift modules need an adapter pattern with minimal Objective-C++ code to interoperate with RN’s C++ core. A human developer must correctly set up bridging headers, adjust symbol linkage, and handle issues (nil pointers, load-order quirks) that an AI model won’t foresee. In practice, you might define an Objective-C++ wrapper that calls Swift code, as in the React Native guide (e.g. creating a NativeLocalStorage.mm that instantiates a Swift class). AI can’t test this on-device or catch linkage errors, so solving such integration bugs falls to developers.

Migration Tip: When migrating to the new architecture, enable TurboModules and Fabric carefully. For Android, set newArchEnabled=true in gradle.properties; for iOS, add ENV['RCT_NEW_ARCH_ENABLED'] = '1' to the Podfile. Then rebuild and watch for crashes or missing modules (issues often show up in Xcode or Logcat).

Performance Profiling and Optimization

React Native apps require manual performance tuning. The official docs state that RN “cannot determine the best optimization approach for you” in all cases – some problems need custom fixes. For example, large lists in a FlatList must be configured with props like windowSize, initialNumToRender, and updateCellsBatchingPeriod to balance rendering and memory. The performance guide lists defaults (e.g. windowSize = 21) and notes that increasing it can reduce blank areas but raise memory use. Adjusting these requires testing on target devices; AI cannot predict the optimal settings for your data. Likewise, stripping out debug code (e.g. console.log) is often necessary. The docs even recommend using a Babel plugin to remove logs before production builds.

Moreover, RN runs two frame loops: the JS thread and the native UI thread. The docs explain that animations performed on the native thread (e.g. using @react-navigation/native-stack) are smoother and not blocked by JS work. An AI model might suggest a JS-based animation, but a human developer can recognize when to switch to a native-driven animator or optimize JavaScript batching. As React Native notes, “native stack navigators… provide better performance… because the transition animations are executed on the native main UI thread”. Achieving 60 FPS often means profiling with device tools (Android Studio Profiler, Xcode Instruments), something only a human can operate. Even RN’s in-app Perf Monitor is just a guide – developers are advised to use native profilers for accurate metrics.

Practical Example: To tune a heavy list, try increasing maxToRenderPerBatch and updateCellsBatchingPeriod:

<FlatList
  data={items}
  windowSize={21}
  initialNumToRender={10}
  maxToRenderPerBatch={15}
  updateCellsBatchingPeriod={30}
  // ...
/>

Then test on device to ensure scrolling remains smooth.

Mitigation: Profile on real hardware and iteratively tune. Use the React Profiler (in DevTools) to identify JS bottlenecks and native tools (CPU/GPU traces) for UI lags. Automating this reasoning is beyond current AI, so human analysis is key.

Native Debugging & Tooling

Debugging React Native issues often requires human-driven, platform-specific tools. You can’t simply ask an AI to attach Xcode breakpoints or parse adb logcat output in real time. Official docs explain that for native code, one typically “launches the app from Android Studio or Xcode and takes advantage of native debugging features (setting breakpoints, etc.)”. Likewise, checking platform logs uses CLI commands (npx react-native log-android or log-ios) or IDE consoles. For example, native modules should log via Android’s Log.d or iOS’s NSLog, which developers then view in Logcat or Xcode. These live-run tasks – attaching to a process, stepping through C++ code, observing thread contention – cannot be done by a static AI model.

Moreover, diagnosing memory leaks or concurrency bugs requires monitoring. RN’s Dev Menu can show a simple perf overlay, but as docs caution, it’s only a guide and “native tooling under Android Studio and Xcode” is recommended for accurate analysis. Tools like Flipper or the Chrome debugger help inspect the JS side, but many timing issues or crashes stem from native threads or JSI. AI code suggestions won’t capture the actual runtime state.

Debugging Tip: If your app freezes, attach the native debugger. In Android Studio use Run → Attach debugger, and in Xcode use Debug → Attach to Process. Then set breakpoints in Java/Kotlin or Objective-C++ code. This hands-on step-by-step inspection is something only a developer can perform. Rely on LogBox and console logs for JS errors, but remember that true native crashes (e.g. EXC_BAD_ACCESS) need native debugging, not just console output.

// Example: remove console logs for production
// Babel config in .babelrc or babel.config.js
{
  "env": {
    "production": {
      "plugins": ["transform-remove-console"]
    }
  }
}

(Configuring the build is another manual task; RN docs recommend removing logs for release builds to avoid JS thread bottlenecks.)

New Architecture Migration & UI Quirks

With React Native’s new architecture (Fabric and TurboModules), developers must adopt new patterns that AI can’t auto-insert. As the RN team notes, the new architecture allows synchronous layout measurement and concurrent rendering features. For example, instead of using the asynchronous onLayout callback (which may cause visual jumps), developers can use useLayoutEffect to synchronously measure views in Fabric, eliminating intermediate states. AI tools won’t automatically refactor your code to this model or understand the subtle timing benefits.

Similarly, enabling features like React 18 automatic batching requires opting into the new renderer. The documentation highlights that useLayoutEffect in the new architecture performs measurements “in a single commit, avoiding the visual ‘jump’” seen in the legacy flow. Knowing when to use these new patterns versus old callbacks is something a seasoned developer decides during optimization.

Finally, the new architecture’s strict typing and codegen add hurdles. For instance, Swift-based AppDelegates cannot directly work with JSI C++ code, as noted earlier. Setting the newArchEnabled flag requires touching multiple files (Gradle and Podfile edits) and understanding build nuances. If something goes wrong (e.g. a missing TurboModule causes startup to fail), a human must trace through native codegen logs.

Migration Example: Suppose you enabled Fabric (newArchEnabled=true). You may find certain libraries need manual updates to their codegen specs. Check RN’s “What can I expect from enabling the New Architecture?” guide for version-specific notes. Always test on both iOS and Android after toggling the flag. Issues like symbols not found (RCTCxxBridge errors) often require adjusting Podfile or rebuilding native modules.

Platform Quirks and Build Configuration

Each platform and OS version can introduce unique issues that AI can’t anticipate. For example, iOS’s new privacy permission dialogs or Android’s scoped storage changes often require platform-specific code or manifest edits. React Native’s native modules sometimes behave differently on device vs simulator. Only by testing on real hardware can a developer catch these quirks. The official docs do not enumerate every nuance (e.g. Bluetooth permissions, background task constraints), so developers rely on forums and GitHub issues for fixes.

Another example is build configuration: adjusting the Android AndroidManifest.xml, editing the iOS Info.plist, setting up push notification certificates, or configuring Google services JSON. These steps are manual and tightly coupled to the native environment. An AI model cannot set up your Xcode signing, Gradle keystores, or handle merge conflicts in android/app/build.gradle.

Developer Tip: Use the React Native Upgrade Helper to compare changes when bumping versions. For AndroidX or library incompatibilities, consult GitHub threads. AI-generated suggestions might miss these details. Document and script your platform-specific changes (e.g., CocoaPods post-install hooks or Gradle plugin settings) to avoid errors.