So the Renderer base class sends messages OnBecameInvisible and OnBecameVisible to the GameObject it sits on.
The CanvasRenderer class does not send any messages.
Note that CanvasRenderer is not a Renderer in the polymorphic sense. CanvasRenderer and Renderer extend from Component so they don’t share functionality from each other.
I think you could benefit from studying the UI implementation at bitbucket.
Though if I understand your problem correctly, it would be pointless to look for messages OnBecameInvisible and OnBecameVisible because the point is to defer instantiation until the object is needed and if the object doesn’t exist yet, how would it ever get a OnBecameInvisible? Perhaps you are thinking of making 600 empty game objects and if any of them become visible, create the item? How about not?
I think what you are looking for is called a virtual list view. I don’t know of any existing virtual list view for Unity, but the idea is that virtual list views are used when you have a large number of items to view and for performance reasons won’t create actual items for the view. Only create for the items that are in the view, and possible a back and forward cache.
Instead of creating 600 UI items, create only the items that could possibly be visible. Instead of loading 600 different textures (consider a scenario where you want to show all wearable hats in the game for example), only load the resources for what is visible and what probably will be visible soon (back/front cache).
Here’s a fugly image trying to depict what I mean. Say you have a rect that can at most show 4 buttons at a time. Only have 4 buttons in your scene (managed by the virtual list view). When a button goes out of view, keep the resources it needs loaded in memory (if user swipe up/down we dont want lag). Unload resources when user navigates away from them (to preserve memory) and make them 100% virtual.
Note that the only UI/GameObjects here is the scrollview + 4 buttons. The rest is just memory.
An example:
When the virtual list view wants to view Item 200, update the contents of one of the buttons to match what item 200 represents. Maybe you set the text to “silly hat” and the texture to a very, very silly hat image. When the virtual list view wants to view item 204, item 200 is no longer visible, so it updates the contents to reflect item 204, a sissy hat, and repositions the button into view. When the virtual list view wants to view Item 340, we understand that we’ll just reuse the buttons again (item 201-204 are no longer in view). Also item 200 - 204 are way far from item 340 so it would make sense to unload the assets for the image until you scroll back to items 200-204…