Android's use of the get/set method will reduce performance, because the memory is limited. As the application complexity increases, later applications tend to be modularized and plug-in to minimize the capacity of the main program. Generally, the following methods are used to do so. optimization:
Use so to encapsulate common modules and implement code sharing by loading libraries
Using the jar form is the same as so, but it is easy to be decompiled
Simplified code writing can be achieved using reflection mechanisms and annotations
Plugin that uses sharedUserId to implement shared processes
Reflection is mentioned here. If the attributes are private, we need to reflect their get methods and copy the attributes of the original object to the new object. Compared with direct reflection to get the public attributes, the execution efficiency is obviously reduced a lot.
In addition, we read Google's source code, all entity class attributes are defined as public.
Furthermore, Android has little dependence on other frameworks and does not follow the JavaBean specification, which is not as disastrous as JavaEE development. It must be mentioned that the JavaBean specification is in line with the concept of OO encapsulation, and there are also advantages, such as hook methods, computed properties, extension of design patterns, easy program modification and maintenance, architecture decoupling, especially backward compatibility, and web-side development, must be followed.
Of course, for early Android development, it made sense to focus on performance and ignore the dangers of not complying with the JavaBeans specification. With the complexity of the ecosystem and business, backward compatibility has to be considered. At this time, should Android pick up those redundant get/set methods?
Don't worry, it's 2014. Object-oriented languages such as C# and Scala, which are newer than Java, provide language features to implement these common requirements, so there is no need for such cumbersome conventions as Java Beans. Not to mention that C# is not used for Android development, and backward compatibility can only be achieved at the source code level. Microsoft still does not recommend the use of public fields. If Scala's var or val is changed to final def, neither source code level backward compatibility nor binary level backward compatibility will be broken.
This way of defining properties has been adopted by many new object-oriented languages, such as Dart and Kotlin. Coincidentally, Google has made Kotlin the official language for Android development, and Dart as the programming language of the Flutter development framework is even more self-evident.
It's too far here. In short, if I want to write get/set in the entity class, either use the ObservableField of DataBinding, or quickly transform to Kotlin or even Flutter. Of course, Java also needs deeper research, not just staying on the syntactic sugar of the new language and ignoring the essential things.