Twenty items in a feed feels perfect. The scroll is butter. Your client is happy. Then you ship to production, the data

ಫೀಡ್‌ನಲ್ಲಿ ಇಪ್ಪತ್ತು ಐಟಂಗಳು ಇದ್ದರೆ ಅದು ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣಿಸುತ್ತದೆ. ಸ್ಕ್ರೋಲಿಂಗ್ ತುಂಬಾ ಮೃದುವಾಗಿರುತ್ತದೆ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಸಂತೋಷಪಡುತ್ತಾರೆ. ನಂತರ ನೀವು ಅದನ್ನು ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಕಳುಹಿಸಿದಾಗ, ಡೇಟಾ ಬಂದಾಗ, ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನೀವು ಎರಡು ಸಾವಿರ ಸಾಲುಗಳನ್ನು ನೋಡುತ್ತೀರಿ. UI ಅಡಚಣೆಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಮೆಮೊರಿ ಹೆಚ್ಚಾಗುತ್ತಾ ಹೋಗಿ ಅಂತಿಮವಾಗಿ OS ಅದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಹತಾಶೆಯಲ್ಲಿ, ಕೆಲವು ಡೆವಲಪರ್‌ಗಳು ಎಲ್ಲವನ್ನೂ ScrollView ಒಳಗೆ ಹಾಕಿ ಕೆಲಸ ಮುಗಿಸಿದಂತೆ ಮಾಡುತ್ತಾರೆ. ಆ ನಿರ್ಧಾರವು ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದರೆ ಪ್ರತಿಯಾಗಿ ಮೂರು ಹೊಸ ಬಗ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಲಿಸ್ಟ್‌ಗಳು ನಿಮ್ಮ React Native ಆ್ಯಪ್ ಅನ್ನು ಬಳಕೆದಾರರು ಹೇಗೆ ಗ್ರಹಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಬಾಟಲ್ನೆಕ್ (bottleneck) ಆಗಿವೆ. ಅವುಗಳನ್ನು ಸರಿಯಾಗಿ ಬಳಸಿದರೆ ಆ್ಯಪ್ ನೈಟಿವ್ ಆಗಿ ಕಾಣುತ್ತದೆ. ತಪ್ಪಾಗಿ ಬಳಸಿದರೆ ಅತ್ಯಂತ ಸುಂದರವಾದ ಸ್ಕ್ರೀನ್ ಕೂಡ ನಿಧಾನಗತಿಯ ಕೆಲಸವಾಗುತ್ತದೆ. ಇದರ ಮೂಲ ಕಾರಣವು ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಕಾಂಪೊನೆಂಟ್ ಮತ್ತು JavaScript ಹಾಗೂ UI ಥ್ರೆಡ್‌ಗಳಿಗೆ ನೀವು ನೀಡುವ ಕೆಲಸದ ನಡುವಿನ ಅಸಮತೋಲನವಾಗಿದೆ. React Native ಎರಡು ಟ್ರ್ಯಾಕ್‌ಗಳಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ನಿಮ್ಮ ಲಾಜಿಕ್ JS ಥ್ರೆಡ್‌ನಲ್ಲಿ ಇರುತ್ತದೆ ಮತ್ತು ಪೇಂಟಿಂಗ್ (painting) ನೈಟಿವ್ UI ಥ್ರೆಡ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ. ನೀವು ದೊಡ್ಡ ಲಿಸ್ಟ್ ಅನ್ನು ತಪ್ಪಾಗಿ ರೆಂಡರ್ ಮಾಡಿದಾಗ, ಎರಡೂ ಥ್ರೆಡ್‌ಗಳು ಲೇಔಟ್ ಕ್ಯಾಲ್ಕುಲೇಶನ್‌ಗಳು, ರೀ-ರೆಂಡರ್‌ಗಳು ಮತ್ತು ಮೆಮೊರಿ ಅಲೋಕೇಶನ್‌ಗಳಲ್ಲಿ ಮುಳುಗಿಹೋಗುತ್ತವೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಫ್ರೇಮ್‌ಗಳು ಬಿಟ್ಟುಹೋಗುತ್ತವೆ, ಸ್ಕ್ರೀನ್ ಬ್ಲಾಂಕ್ ಆಗುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಆ್ಯಪ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ.

ಸರಿಯಾದ ಸಾಧನವನ್ನು ಆರಿಸಿ

ಲಿಸ್ಟ್ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಒಂದು ಉದ್ದೇಶಪೂರ್ವಕ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ನಿರ್ಧಾರವಾಗಿರಬೇಕೇ ಹೊರತು ಕೇವಲ ಅಭ್ಯಾಸವಾಗಿರಬಾರದು.

ScrollView ಅತ್ಯಂತ ಸರಳವಾದ ಆಯ್ಕೆಯಾಗಿದೆ. ಇದು ನೀವು ನೀಡುವ ಪ್ರತಿಯೊಂದು ಚೈಲ್ಡ್ ಅನ್ನು ತಕ್ಷಣವೇ ಮೆಮೊರಿಯಲ್ಲಿ ಮೌಂಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇಡೀ ಗುಂಪನ್ನು ನೈಟಿವ್ ಸ್ಕ್ರೋಲ್ ಇಂಜಿನ್‌ಗೆ ನೀಡುತ್ತದೆ. ಸೆಟ್ಟಿಂಗ್ಸ್ ಸ್ಕ್ರೀನ್, ಲಾಗಿನ್ ಫಾರ್ಮ್ ಅಥವಾ ಹತ್ತು ಸೆಕ್ಷನ್‌ಗಳಿರುವ ಸ್ಟ್ಯಾಟಿಕ್ ಪ್ರಾಡಕ್ಟ್ ಡೀಟೇಲ್ ಪೇಜ್‌ನಂತಹ ಸಣ್ಣ ಮತ್ತು ಸ್ಥಿರವಾದ ವಿಷಯಗಳಿಗೆ ಇದು ಸೂಕ್ತವಾಗಿದೆ. ಇದು ಊಹಿಸಬಹುದಾದ ಮತ್ತು ಸ್ಟೈಲ್ ಮಾಡಲು ಸುಲಭವಾಗಿದೆ. ಆದರೆ ಇಲ್ಲಿ ವರ್ಚುವಲೈಸೇಶನ್ (virtualization) ಇಲ್ಲ ಎಂಬುದು ಮುಖ್ಯವಾದ ವಿಷಯ. ನೀವು ಇದಕ್ಕೆ ಎರಡು ಸಾವಿರ ಐಟಂಗಳನ್ನು ನೀಡಿದರೆ, ಅದು ಅಚ್ಚುಕಟ್ಟಾಗಿ ಎರಡು ಸಾವಿರ ನೈಟಿವ್ ವ್ಯೂಗಳನ್ನು ರಚಿಸುತ್ತದೆ. ದೊಡ್ಡ ಅಥವಾ ಡೈನಾಮಿಕ್ ಡೇಟಾ ಸೆಟ್‌ಗಳಿಗಾಗಿ ScrollView ಅನ್ನು ಬಳಸಬೇಡಿ. ಇದನ್ನು ಲೈಬ್ರರಿ ಶೆಲ್ಫ್ ಎಂದು ಭಾವಿಸಬೇಡಿ, ಬದಲಾಗಿ ಫ್ರೇಮ್ ಮಾಡಿದ ಪೋಸ್ಟರ್ ಎಂದು ಭಾವಿಸಿ.

FlatList ದೀರ್ಘವಾದ ಮತ್ತು ಏಕರೂಪದ ಫೀಡ್‌ಗಳಿಗೆ ಅತ್ಯುತ್ತಮ ಕೆಲಸಗಾರ. ಇದು ಕಂಟೆಂಟ್ ಅನ್ನು ವರ್ಚುವಲೈಸ್ ಮಾಡುತ್ತದೆ, ಅಂದರೆ ಪ್ರಸ್ತುತ ವೀಕ್ಷ್ಯದಲ್ಲಿರುವ ಅಥವಾ ವೀಕ್ಷ್ಯದ ಹತ್ತಿರವಿರುವ ಸಾಲುಗಳನ್ನು ಮಾತ್ರ ಇದು ಮೌಂಟ್ ಮಾಡುತ್ತದೆ. ಬಳಕೆದಾರರು ಸ್ಕ್ರೋಲ್ ಮಾಡುವಾಗ, FlatList ಸ್ಕ್ರೀನ್‌ನಿಂದ ಹೊರಹೋಗುವ ಸೆಲ್‌ಗಳನ್ನು ಅನ್‌ಮೌಂಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಹೊಸ ಡೇಟಾಕ್ಕಾಗಿ ಅವುಗಳನ್ನು ಮರುಬಳಕೆ (recycle) ಮಾಡುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಅರೇ (array) ಎಷ್ಟು ದೊಡ್ಡದಾಗಿದ್ದರೂ ಮೆಮೊರಿಯನ್ನು ಸ್ಥಿರವಾಗಿಡುತ್ತದೆ. ನೀವು ಸೋಶಿಯಲ್ ಟೈಮ್‌ಲೈನ್, ನೋಟಿಫಿಕೇಶನ್ ಸೆಂಟರ್ ಅಥವಾ ಒಂದೇ ರೀತಿಯ ಕಾರ್ಡ್‌ಗಳ ನಿರಂತರ ಸ್ಕ್ರೋಲಿಂಗ್ ಸಂಗ್ರಹವನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, FlatList ಸರಿಯಾದ ಆಯ್ಕೆಯಾಗಿದೆ.

SectionList ಎಂಬುದು ಒಂದು ವ್ಯವಸ್ಥಿತವಾದ FlatList ಆಗಿದೆ. ನಿಮ್ಮ ಡೇಟಾ ಗುಂಪುಗಳಾಗಿ ಬಂದಾಗ ಇದನ್ನು ಬಳಸಿ, ಉದಾಹರಣೆಗೆ ಅಕ್ಷರಮಾಲೆಯ ಪ್ರಕಾರ ಜೋಡಿಸಲಾದ ಅಡ್ರೆಸ್ ಬುಕ್, ದಿನಾಂಕದ ಪ್ರಕಾರ ವಿಂಗಡಿಸಲಾದ ವರ್ಕೌಟ್ ಲಾಗ್ ಅಥವಾ ತಿಂಗಳ ಪ್ರಕಾರ ವಿಂಗಡಿಸಲಾದ ಇನ್‌ವಾಯ್ಸ್ ಲಿಸ್ಟ್. ಇದು ಸ್ಟಿಕಿ ಸೆಕ್ಷನ್ ಹೆಡರ್‌ಗಳನ್ನು ರೆಂಡರ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಗುಂಪು ಮಾಡುವ ತರ್ಕವನ್ನು (grouping logic) ನಿಮಗಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಒಳಗಿನಿಂದ FlatList ನಂತೆಯೇ ವರ್ಚುವಲೈಸೇಶನ್ ಇಂಜಿನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಅದೇ ಮೆಮೊರಿ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ.

FlashList ಸಾಧನದಿಂದ ಪ್ರತಿಯೊಂದು ಫ್ರೇಮ್ ಅನ್ನು ಗರಿಷ್ಠವಾಗಿ ಪಡೆಯಬೇಕಾದಾಗ ಬಳಕೆಯಾಗುತ್ತದೆ. RecyclerListView ಎಕೋಸಿಸ್ಟಮ್ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಇದು, FlatList ಗಿಂತ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ವ್ಯೂಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಮಧ್ಯಮ ಶ್ರೇಣಿಯ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲೂ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಅರವತ್ತು ಫ್ರೇಮ್‌ಗಳನ್ನು (60 FPS) ಕಾಯ್ದುಕೊಳ್ಳುವ ಗುರಿಯನ್ನು ಹೊಂದಿದೆ. ನೀವು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಚಾಟ್ ಇಂಟರ್ಫೇಸ್, ವೇಗವಾಗಿ ಸ್ಕ್ರೋಲ್ ಮಾಡಬಹುದಾದ ಪ್ರಾಡಕ್ಟ್ ಕ್ಯಾಟಲಾಗ್ ಅಥವಾ ಸ್ಮೂತ್ನೆಸ್ (smoothness) ಮುಖ್ಯವಾಗಿರುವ ಸ್ಕ್ರೀನ್ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, FlashList ಅನ್ನು ಬಳಸಲು ಯೋಗ್ಯವಾಗಿದೆ. ಇದು ಪ್ರತಿಯೊಂದು ಸ್ಕ್ರೀನ್‌ಗೆ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ, ಮುಖ್ಯವಾದ ಫೀಡ್‌ಗಳ ಪರ್ಫಾರ್ಮೆನ್ಸ್‌ನಲ್ಲಿ ದೊಡ್ಡ ವ್ಯತ್ಯಾಸವನ್ನು ಕಾಣಬಹುದು.

ಸಾಮಾನ್ಯ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಕುಂಠಿತಗೊಳಿಸುವ ಅಂಶಗಳು

ಲಿಸ್ಟ್ ನಿಧಾನವಾಗಲು ಮೂರು ಸಾಮಾನ್ಯ ಕಾರಣಗಳಿವೆ.

ಏಕಕಾಲದಲ್ಲಿ ಅತಿಯಾದ React ಟ್ರೀಗಳನ್ನು ಮೌಂಟ್ ಮಾಡುವುದು ದೊಡ್ಡ ವೈಫಲ್ಯವಾಗಿದೆ. ಪ್ರತಿ ಸಾಲು ಕೂಡ ಒಂದು ಸಂಕೀರ್ಣ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀ ಆಗಿದ್ದಾಗ, ಆರಂಭಿಕ ರೆಂಡರಿಂಗ್ JS ಥ್ರೆಡ್ ಅನ್ನು ತಡೆಹಿಡಿಯಬಹುದು, ಇದರಿಂದ ಬಿಳಿ ಸ್ಕ್ರೀನ್ ಅಥವಾ ವಿಳಂಬಿತ ರಿಸಲ್ಟ್ ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು. ಬಳಕೆದಾರ ಆ್ಯಪ್ ತೆರೆದು ಕಾಯಬೇಕಾಗುತ್ತದೆ. ಆರಂಭಿಕ ಲೋಡ್ ಆದ ನಂತರವೂ, ಭಾರೀ ಸಾಲುಗಳು ಸ್ಕ್ರೋಲ್ ಆರಂಭವನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತವೆ ಏಕೆಂದರೆ ಮೊದಲ ಕೆಲವು ಫ್ರೇಮ್‌ಗಳು ಸೆಟಪ್ ಕೆಲಸದಲ್ಲಿ ವ್ಯಯವಾಗುತ್ತವೆ.

ಪ್ರತಿ ಫ್ರೇಮ್‌ನಲ್ಲಿ ಅತಿಯಾದ ಕೆಲಸವು ಸ್ಕ್ರೋಲ್ ಮಾಡುವಾಗ ಅಡಚಣೆ ಅಥವಾ ಜಿಗಿತದಂತೆ (stuttering) ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಅನಿಮೇಷನ್‌ಗಳನ್ನು ಸ್ಮೂತ್ ಆಗಿಡಲು ನಿಮಗೆ ಪ್ರತಿ ಫ್ರೇಮ್‌ಗೆ ಸುಮಾರು ಹದಿನಾರು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಬಜೆಟ್ ಇರುತ್ತದೆ. ಒಂದು ರೋ ಕಾಂಪೊನೆಂಟ್ ದುಬಾರಿ ಕ್ಯಾಲ್ಕುಲೇಶನ್‌ಗಳನ್ನು ಮಾಡಿದರೆ ಅಥವಾ ರೆಂಡರ್ ಮಾಡುವಾಗ ಡೇಟಾವನ್ನು ಪಾರ್ಸ್ ಮಾಡಿದರೆ, ನೀವು ಆ ಬಜೆಟ್ ಅನ್ನು ಮೀರುತ್ತೀರಿ. UI ಥ್ರೆಡ್ ಫ್ರೇಮ್‌ಗಳನ್ನು ಬಿಟ್ಟುಹೋಗುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಅದು ಅಡಚಣೆಯಾಗಿ ಕಾಣುತ್ತದೆ.

ಅತಿಯಾದ ಮೆಮೊರಿ ಬಳಕೆ ಒಂದು ಮೌನ ಕೊಲೆಗಾರನಿದ್ದಂತೆ. ಪ್ರತಿಯೊಂದು ನೈಟಿವ್ ವ್ಯೂ ಕೂಡ RAM ಅನ್ನು ಬಳಸುತ್ತದೆ. ದೊಡ್ಡ ಅನ್‌ಆಪ್ಟಿಮೈಸ್ಡ್ ಇಮೇಜ್‌ಗಳು, ಪ್ರತಿ ಕಾರ್ಡ್ ಮೇಲೆ ಡ್ರಾಪ್ ಶ್ಯಾಡೋಗಳು ಅಥವಾ ನೆಸ್ಟೆಡ್ ಟಚಬಲ್ಸ್‌ಗಳನ್ನು ಬಳಸಿದರೆ ಮೆಮೊರಿ ಬಳಕೆ ಹೆಚ್ಚಾಗುತ್ತದೆ. iOS ನಲ್ಲಿ ಸಿಸ್ಟಮ್ ಎಚ್ಚರಿಕೆ ನೀಡದೆ ನಿಮ್ಮ ಆ್ಯಪ್ ಅನ್ನು ನಿಲ್ಲಿಸಬಹುದು. Android ನಲ್ಲಿ ಬಳಕೆದಾರರು ಆ್ಯಪ್ ಬಳಸಲು ಅಸಾಧ್ಯವಾಗುವವರೆಗೆ ಆಗುವ ವಿಳಂಬವನ್ನು (lag) ನೋಡುತ್ತಾ ಕುಳಿತುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.

ಆಪ್ಟಿಮೈಸೇಶನ್ ಚೆಕ್‌ಲಿಸ್ಟ್

ಸಣ್ಣ ಕಾರ್ಯತಂತ್ರದ ಅಭ್ಯಾಸಗಳು ಕೇವಲ ಕೆಲಸ ಮಾಡುವ ಪಟ್ಟಿಗೂ ಮತ್ತು ಅತ್ಯಂತ ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಪಟ್ಟಿಗೂ ಇರುವ ವ್ಯತ್ಯಾಸವನ್ನು ತಿಳಿಸುತ್ತವೆ.

ಸ್ಥಿರ ಕೀಗಳನ್ನು (stable keys) ಬಳಸಿ. ನಿಮ್ಮ ಡೇಟಾ ಸೆಟ್‌ನಿಂದ ನೈಜ ಐಡೆಂಟಿಫೈಯರ್ ಅನ್ನು ಯಾವಾಗಲೂ key prop ಗೆ ಕಳುಹಿಸಿ. ಅರೇ ಇಂಡೆಕ್ಸ್ ಅನ್ನು (array index) ಎಂದಿಗೂ ಬಳಸಬೇಡಿ. ನಿಮ್ಮ ಪಟ್ಟಿಯು ಮರುಜೋಡಣೆ (reorder), ಫಿಲ್ಟರ್ ಅಥವಾ ಹೊಸ ಐಟಂಗಳನ್ನು ಸೇರಿಸುವಾಗ, ಇಂಡೆಕ್ಸ್ ಆಧಾರಿತ ಕೀಯು React ಅನ್ನು ತಪ್ಪಾದ ಡೇಟಾವನ್ನು ತಪ್ಪಾದ ಕಂಪೊನೆಂಟ್‌ನೊಂದಿಗೆ ಜೋಡಿಸಲು ಪ್ರೇರೇಪಿಸುತ್ತದೆ. ಈ ತಪ್ಪಿನಿಂದ ಅನಗತ್ಯ unmounts, state mismatches ಮತ್ತು cascading re-renders ಸಂಭವಿಸುತ್ತವೆ. ಸರಿಯಾದ ID ಬಳಸಿರುವುದರಿಂದ, ಯಾವ ರೋ (row) ಎಲ್ಲಿಗೆ ಚಲಿಸಿದೆ ಎಂಬುದನ್ನು React ನಿಖರವಾಗಿ ತಿಳಿಯುತ್ತದೆ.

ರೋಗಳನ್ನು ಮೆಮೊೈಸ್ (Memoize) ಮಾಡಿ. ನಿಮ್ಮ ರೋ ಕಂಪೊನೆಂಟ್ ಅನ್ನು React.memo ನಲ್ಲಿ ಸುತ್ತುವರಿಯಿರಿ (wrap), ಇದರಿಂದ ಅದರ props ಬದಲಾದಾಗ ಮಾತ್ರ ಅದು re-render ಆಗುತ್ತದೆ. ಈ ಸುರಕ್ಷತೆಯಿಲ್ಲದೆ, ಪೇರೆಂಟ್ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್ (parent state update) ಆದಾಗ, ಡೇಟಾ ಒಂದೇ ಆಗಿದ್ದರೂ ಸಹ ಪ್ರತಿಯೊಂದು ರೋ ಕೂಡ re-render ಆಗಬಹುದು. ದೀರ್ಘವಾದ ಪಟ್ಟಿಯಲ್ಲಿ, ಈ ವ್ಯರ್ಥ ಸೈಕಲ್‌ಗಳು ವೇಗವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತವೆ.

renderItem ಅನ್ನು ಸ್ಥಿರವಾಗಿರಿಸಿ. ಪ್ರತಿ ಪೇರೆಂಟ್ 渲染 (render) ಸಮಯದಲ್ಲಿ renderItem prop ಒಳಗೆ ಹೊಸ ಫಂಕ್ಷನ್ ಅನ್ನು ನೇರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ. renderItem={({ item }) => <Row data={item} />} ನಂತಹ ಇನ್‌ಲೈನ್ ಅರೋ ಫಂಕ್ಷನ್ (inline arrow function) ಪೇರೆಂಟ್ ಅಪ್‌ಡೇಟ್ ಆದ ಪ್ರತಿ ಬಾರಿಯೂ ಹೊಸ ರೆಫರೆನ್ಸ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. FlatList ಬದಲಾದ prop ಅನ್ನು ನೋಡಿ ಅನಗತ್ಯವಾಗಿ ರೋವನ್ನು ಮರುಬಳಕೆ (recycle) ಮಾಡುತ್ತದೆ. ರೆಂಡರ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಕಂಪೊನೆಂಟ್‌ನ ಹೊರಗೆ ವ್ಯಾಖ್ಯಾನಿಸಿ ಅಥವಾ useCallback ಬಳಸಿ ಮೆಮೊೈಸ್ ಮಾಡಿ, ಇದರಿಂದ ರೆಫರೆನ್ಸ್ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.

ಸಾಧ್ಯವಾದಾಗಲೆಲ್ಲ getItemLayout ಬಳಸಿ. ನಿಮ್ಮ ರೋಗಳಿಗೆ ನಿಗದಿತ ಅಥವಾ ಊಹಿಸಬಹುದಾದ ಎತ್ತರ (height) ಇದ್ದರೆ, ಅದನ್ನು FlatList ಗೆ ನಿಖರವಾಗಿ ತಿಳಿಸಿ. ಈ prop ಪಟ್ಟಿಯು ದುಬಾರಿ native measurement calls ಅನ್ನು ಬಿಟ್ಟುಬಿಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಮೌಂಟ್ (mount) ಆದ ನಂತರ ಪ್ರತಿ ಸೆಲ್ ಅನ್ನು ಅಳೆಯುವ ಬದಲು, ಪಟ್ಟಿಯು ಗಣಿತದ ಮೂಲಕ ಸ್ಥಾನವನ್ನು (position) ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ನೂರಾರು ಅಥವಾ ಸಾವಿರಾರು ಐಟಂಗಳನ್ನು ಹೊಂದಿರುವ ಪಟ್ಟಿಗಳಲ್ಲಿ ಇದರ ವ್ಯತ್ಯಾಸವು ಸ್ಪಷ್ಟವಾಗಿ ಕಂಡುಬರುತ್ತದೆ, ಅಲ್ಲಿ onLayout ಚಾಟರ್ (chatter) JS thread ಅನ್ನು ಕುಂಠಿತಗೊಳಿಸಬಹುದು.

ಚಿತ್ರಗಳನ್ನು (images) ತೀವ್ರವಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿ. ಅನಿರ್ದಿಷ್ಟ ಗಾತ್ರದ ಚಿತ್ರಗಳು ಪಟ್ಟಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹಾಳುಮಾಡುತ್ತವೆ. ಚಿತ್ರವು ಡಿಕೋಡ್ ಆಗುವ ಮೊದಲು native layer ಸ್ಥಳವನ್ನು ಕಾಯ್ದಿರಿಸಲು ಯಾವಾಗಲೂ ಸ್ಪಷ್ಟವಾದ width ಮತ್ತು height ಅನ್ನು ನಿಗದಿಪಡಿಸಿ. ರಿಮೋಟ್ ಚಿತ್ರಗಳಿಗಾಗಿ, memory caching, disk persistence ಮತ್ತು format optimization ಅನ್ನು ನಿರ್ವಹಿಸುವ Expo Image ಅಥವಾ ಸಮಾನವಾದ caching library ಬಳಸಿ. ಡಿಫಾಲ್ಟ್ React Native Image ಕಂಪೊನೆಂಟ್ ಪ್ರೊಟೊಟೈಪ್‌ಗಳಿಗೆ (prototypes) ಸರಿಹೊಂದುತ್ತದೆ, ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ ಫೀಡ್‌ಗಳಿಗೆ ಮೆಮೊರಿ ಮತ್ತು ಲೋಡಿಂಗ್ ಸ್ಟೇಟ್‌ಗಳ ಮೇಲೆ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣದ ಅಗತ್ಯವಿದೆ.

ಸ್ಕ್ರೋಲ್ ಕಂಟೇನರ್‌ಗಳನ್ನು ನೆಸ್ಟಿಂಗ್ (nesting) ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಿ. ವರ್ಟಿಕಲ್ FlatList ಅನ್ನು ಎಂದಿಗೂ ವರ್ಟಿಕಲ್ ScrollView ಒಳಗೆ ಇರಿಸಬೇಡಿ. ಪೇರೆಂಟ್ ScrollView ಎಲ್ಲಾ ಸ್ಕ್ರೋಲ್ ಇವೆಂಟ್‌ಗಳನ್ನು ಹಿಡಿದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಚೈಲ್ಡ್ FlatList ತನ್ನ ವ್ಯೂಪೋರ್ಟ್ (viewport) ಅನ್ನು ಅಳೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ. FlatList ಯಾವ ರೋಗಳು ಕಾಣಿಸಬೇಕು ಎಂದು ತಿಳಿಯದ ಕಾರಣ Virtualization ವಿಫಲವಾಗುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿಯೊಂದು ರೋ ಕೂಡ ಮೌಂಟ್ ಆಗುತ್ತದೆ, ಇದು virtualization ನ ಉದ್ದೇಶವನ್ನೇ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ಪಟ್ಟಿಯ ಮೇಲೆ ಹೆಡರ್ ಬೇಕಿದ್ದರೆ, FlatList ನ ListHeaderComponent prop ಬಳಸಿ. ಸಂಕೀರ್ಣವಾದ sticky behavior ಬೇಕಿದ್ದರೆ, ಸೂಕ್ತವಾದ ಹೆಡರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ SectionList ಅಥವಾ FlashList ಬಳಸಿ.

ಸುವರ್ಣ ನಿಯಮ

ವಿಷಯವು (content) ಚಿಕ್ಕದಾಗಿದ್ದರೆ ಮತ್ತು ಸೀಮಿತವಾಗಿದ್ದರೆ, ಅದನ್ನು ScrollView ಮೂಲಕ ನಿರ್ವಹಿಸಿ. ವಿಷಯವು ಬಳಕೆದಾರರ ಡೇಟಾ ಅಥವಾ ರಿಮೋಟ್ ಪೇಜಿನೇಶನ್‌ನೊಂದಿಗೆ ಬೆಳೆಯುತ್ತಿದ್ದರೆ, virtualized list ಬಳಸಿ. ಪಟ್ಟಿಯು ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರಮುಖ ಭಾಗವಾಗಿದ್ದಾಗ ಮತ್ತು ಬಳಕೆದಾರರು ನಿಮಿಷಗಟ್ಟಲೆ ಸ್ಕ್ರೋಲ್ ಮಾಡಬೇಕಾದ ಸಂದರ್ಭದಲ್ಲಿ, FlashList ಬಳಸಿ.

ಮರೆಯಲಾಗುವ ಒಂದು ಕೊನೆಯ ಸತ್ಯ ಇಲ್ಲಿದೆ. ಸರಳವಾದ ರೋಗಳು ವೇಗವಾಗಿ ಸ್ಕ್ರೋಲ್ ಆಗುತ್ತವೆ. ನಿಮ್ಮ ರೋ ಕಂಪೊನೆಂಟ್ ಎಷ್ಟು ಹಗುರವಾಗಿದೆಯೋ, ನಿಮ್ಮ ಪಟ್ಟಿ ಅಷ್ಟು ಸುಗಮವಾಗಿರುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ರೋನಿಂದ ನೆಸ್ಟೆಡ್ ನ್ಯಾವಿಗೇಷನ್‌ಗಳು (nested navigations), ಭಾರೀ ಕಂಪ್ಯೂಟೇಶನ್‌ಗಳು ಮತ್ತು ಅನಗತ್ಯ ಅನಿಮೇಷನ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ. ಮಾರ್ಕಪ್ ಅನ್ನು ಫ್ಲಾಟ್ ಆಗಿ, ಲಾಜಿಕ್ ಅನ್ನು ತೆಳುವಾಗಿ ಮತ್ತು ಚಿತ್ರಗಳ ಗಾತ್ರವನ್ನು ಸರಿಯಾಗಿರಿಸಿ. ಪಟ್ಟಿಯು ಅದು ರೆಂಡರ್ ಮಾಡುವ ವಿಷಯಗಳ ಒಟ್ಟು ತೂಕದ ಮೇಲೆ ಬದುಕುತ್ತದೆ ಅಥವಾ ಸಾಯುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ರೋವನ್ನು ಲಘುವಾಗಿ (cheap) ಮಾಡಿ, ಆಗ ಪಟ್ಟಿಯು ಅತ್ಯುತ್ತಮ ಅನುಭವವನ್ನು ನೀಡುತ್ತದೆ.