如何解决单应用中多表盘（多服务）的Complications配置冲突？

Hey there, let's tackle this frustrating issue where your second watch face's complication changes are showing up on the first one, while the second face ends up empty. Your hunch about shared storage for user selections is totally on point—here are concrete steps to fix this:

• Unique Complication IDs Across Watch Faces
  Double-check that every complication slot in your two watch face services has a unique identifier. It’s easy to accidentally reuse constants like PRIMARY_COMPLICATION_SLOT_ID across both services. Instead, namespace them per watch face: use WATCH_FACE_1_PRIMARY_SLOT and WATCH_FACE_2_PRIMARY_SLOT to ensure the system (and your code) can tell them apart.

• Isolate User Selection Storage
  If you’re using SharedPreferences, DataStore, or any local storage to save users’ chosen complications, make sure each watch face uses a distinct key prefix. For example, instead of a generic selected_complication_for_slot_1, use watch_face_1_selected_complication_slot_1 and watch_face_2_selected_complication_slot_1. This prevents the two watch faces from overwriting each other’s saved data.

• Separate Complication Data Source Registration
  In each WatchFaceService implementation’s onCreateComplicationDataSources method, ensure you’re only registering the slots specific to that watch face. Don’t copy-paste the same registration logic between the two services—each should handle its own set of complications independently.

• Verify Complication Slot Configuration
  Make sure the complication slot definitions (like supported types, positions, and default data) are scoped to each watch face service. Avoid using shared configuration objects that might carry over settings from one face to the other.

• Clean Up Cache and Retest
  Old cached data can cause unexpected behavior. Go to your watch’s app settings, clear the data for your watch face app, then set up both watch faces again from scratch. This will eliminate any leftover conflicting data that might be causing the mix-up.

If you’re using Jetpack Wear’s Watch Face libraries, also confirm that each ComplicationManager instance is tied to its respective watch face service—don’t share a single manager between the two.

内容的提问来源于stack exchange，提问作者Mal Ham