If the value of the field_total_fruits is always the sum of the other fields, then there is not really a point in storing it. Instead, you can compute the value when you want to display it, or when you want to do other things with it.
You now have a number of options, depending what you want to do with the result.
I personally do not like solutions like "computed field", from what I remember from last time I used it.
Actual fields + hook_entity_presave() (EDIT)
Yes, you can store the sum in a dedicated field added to the entity. This means having redundant data in the database, but it also means having the data available to functionality that only works with fields. It can make your life easier.
To do so, you can use hook_entity_presave() to calculate the sum and store it in the new field.
Notice that you probably need to load the field collection items, because the field items of
$node->field_fruit_collection will only contain the field collection item ids.
You should pay attention to the array indices
[$langcode][$delta] of field items. On a specific site it can be sufficient to always hardcode `[LANGUAGE_NONE], but this limits the reusability of the module a lot. And you'd still need to check if the keys are set to prevent PHP notices.
I think it is ok to hardcode some assumptions into your module. You are already hardcoding the field names, so you can also hardcode which of the fields are single-value. So in
$delta is always
0. Or use
reset() to pick the first item. This makes your module unsuitable for publishing on drupal.org, but good enough for your site.
But for the language key you should be more careful. Normally I would say loop over the languages, then store results per language in the field_total_fruit. Maybe use some kind of fallback logic to use LANGUAGE_NONE if no language present.
What complicates things here, is that both the field collection and the field_apples and field_watermelons can have values per language. E.g. you could have
Things like this can go unnoticed for a while, and then you get strange bug reports that make you scratch your head.
Since all of this is numbers, I'd say configure these fields so that only LANGUAGE_NONE is used.
I would say do NOT use field_get_items() here. Or if you do, be careful what you are doing. The entity will be saved in all languages, and field_get_items() filters the result to the current language only. So you could have inconsistent behavior depending on the current user language.
You could use hook_entity_property_info() to register a property with a value callback. In this value callback you would use field_get_items() on both fields and calculate the sum.
Entity properties can be used in a number of places, but they do not naturally show up in field ui for entity view modes, or as views fields.
You would need to do more research to find a way to make them show up in views or elsewhere. Although the hook has some interesting fields like 'entity views field' which might help.
I think it would be worth it to do some more research in this direction, possibly even open a new question. Entity properties are quite a powerful concept, and really there has to be a way to make them show up where you need them.
DS custom field
You could declare a Display suite custom field where you calculate the value. This will only be available in DisplaySuite-enabled view modes, though.
Custom Views field handler
You could write you own views field handler. But these are only available in Views, not elsewhere.
I personally have created some of those, but never really enjoyed working with the API.
Custom "entity display plugin"
There is a collection of modules that I have created myself, that would make this specific task quite easy. The downside is that this is an entire new world to dive into, not something you want to do for just one little task. I am presenting this option here for completeness.
You start with EntDisP. It has a bunch of dependencies, which are listed on the module page. The basic getting-started is explained on the module page.
You would then create a custom module, e.g. "fruitsum" with a custom entity display plugin.
I could elaborate on this further, but this would give it unjust priority over the other options.
The advantage is that these plugins are easy to write and maintain once you get the hang of it, and they can be used in a lot of places.
The disadvantage is that, as said, this is a completely new world to dive into.
I personally would suggest to follow the "entity property" route, with some research of your own. If you find a way to make those things show up, you have a new tool at your disposal for future tasks.
I am even considering to create a new entdisp plugin for the purpose of displaying properties.
Maybe other answers can elaborate more on this direction. Or if you find out, you could write the answer yourself!