Bene, la giustificazione più immediata per questa decisione di progettazione può essere trovata in metodo javadocs :
you can cast the return value from this method to Spannable or Editable...
I cast menzionati sopra sono possibili solo perché implementabile e modificabile CharSequence ; String non lo consentirebbe.
Per una comprensione più profonda della motivazione del design, dai un'occhiata a classe javadocs :
TextView is a complete text editor...
Sopra significa che l'oggetto TextView è progettato per supportare frequenti modifiche del suo contenuto.
Se getText restituisce String immutabile, ciò significherebbe un'alta probabilità di creare più oggetti mentre si lavora con TextView. Questo a sua volta andrebbe contro l'approccio generale preferito in Android e delineato in Evita la creazione di oggetti non necessari linee guida:
Object creation is never free. A generational garbage collector with per-thread allocation pools for temporary objects can make allocation cheaper, but allocating memory is always more expensive than not allocating memory.
As you allocate more objects in your app, you will force a periodic garbage collection, creating little "hiccups" in the user experience. The concurrent garbage collector introduced in Android 2.3 helps, but unnecessary work should always be avoided.
Thus, you should avoid creating object instances you don't need to...
Per completezza, vale la pena notare che il ragionamento nella guida sopra implica implicitamente applicazioni mobili specifiche.
In particolare, è possibile immaginare piattaforme desktop o server che dispongono di una garbage collection più sofisticata, che consente agli sviluppatori di progettare oggetti immutabili a propria discrezione, senza preoccuparsi troppo delle implicazioni in termini di prestazioni.
Nelle piattaforme mobili, i progettisti API devono tenere conto dei limiti delle risorse dei dispositivi mobili (memoria, processore, consumo energetico, ecc.) che possono bloccare l'implementazione di approcci teoricamente migliori .