This article will conduct a comprehensive analysis and comparison of the current React Native and Flutter from seven aspects, including environment construction, implementation principles, programming development, plug-in development, compilation and operation, stable performance, and future development , and hope to give you a more valuable reference. .
Preface
After several years of ups and downs on the mobile platform, now React Native and Flutter are the only ones who can still enjoy themselves under the spotlight of the stage . As the "rich" that has been deposited for several years and the popular "upstart" in 19 years, they The "tit for tat" between them has also become a concern for developers.
Someone once asked me in the past: "He writes both Java and Object-C. He can develop on both Android and IOS platforms. Why should he learn to cross-platform?"
And my answer is: the market advantage of cross-platform does not lie in performance or learning costs, and even platform adaptation will be more time-consuming, but it ultimately allows code logic (especially business logic) to be seamlessly reused on various platforms , It reduces the maintenance cost of repeated code and ensures the unity between platforms. If certain performance can be guaranteed at this time, it will be more perfect.
ByteDance has asked this question on three sides, and I have sorted it out here. I hope it can help everyone. Welcome to check and fill in the gaps.
Separate data processing and view loading
We know that pulling data from the remote must be asynchronous. After we pull the data, we may hurriedly throw the data to the VH for processing. In fact, we should also place the data processing logic in asynchronous processing. After the Adapter notify the change, ViewHolder can do data and view binding logic simply and without pressure, such as:
mTextView.setText(Html.fromHtml(data).toString())
The Html.fromHtml(data) method here may be more time-consuming. If there are multiple TextViews, it will be more time-consuming, which will cause frame drops and freezes. If you put this step together with the network asynchronous thread From the perspective of users, the network refresh time is a little longer at most.
Data optimization
Pull remote data by page, cache the pulled remote data, improve the speed of secondary loading; for newly added or deleted data, use DiffUtil to refresh the data locally instead of blindly refreshing the data globally.
Layout optimization
Reduce transition drawing
To reduce the layout level, you can consider using a custom View to reduce the level, or set the layout more reasonably to reduce the level. It is not recommended to use ConstraintLayout in RecyclerView. Many developers have already reported that using it is worse. Related links are: Is ConstraintLayout that slow?, constraintlayout 1.1.1 not work well in listview.
Reduce xml file inflate time
The xml file here includes not only the xml of the layout, but also the xml of the drawable. The xml file inflate out the ItemView through time-consuming IO operations, especially when the probability of Item reuse is very low, as the Type increases, this The loss caused by inflate is quite large. At this time, we can use code to generate the layout, that is, the new View() method, as long as we figure out the API corresponding to the attribute of each node in the xml.
Reduce the creation of View objects
A slightly complex Item will contain a large number of Views, and the creation of a large number of Views will also consume a lot of time, so the ItemView should be simplified as much as possible; when designing the ItemType, try to design a custom View for the parts that can be shared by multiple ViewTypes to reduce the View The construction and nesting.
other
Others do not mean that they are not important, but I can't classify them. Some operations may greatly optimize your RecyclerView.
- Upgrade RecycleView version to 25.1.0 and above to use Prefetch function, please refer to RecyclerView data prefetching.
- If the Item height is fixed, you can use RecyclerView.setHasFixedSize(true); to avoid requestLayout wasting resources;
- Set RecyclerView.addOnScrollListener(listener); to stop loading during the sliding process.
- If animation is not required, you can pass ((SimpleItemAnimator) rv.getItemAnimator()).setSupportsChangeAnimations(false); to turn off the default animation to improve efficiency.
- Use String.toUpperCase for TextView instead of android:textAllCaps="true".
- Use StaticLayout or DynamicLayout custom View for TextView instead of it.
- Recycle resources by overriding RecyclerView.onViewRecycled(holder).
- Use RecycleView.setItemViewCacheSize(size); to increase the cache of RecyclerView and use space for time to improve the smoothness of scrolling.
- If the Adapter of multiple RecycledViews is the same, for example, the same Adapter exists in the nested RecyclerView, you can share a RecycledViewPool by setting RecyclerView.setRecycledViewPool(pool);.
- Set up a listener for the ItemView. Don't call addXxListener for each Item. You should share an XxListener and perform different operations based on the ID to optimize the resource consumption caused by frequent object creation.
- Use getExtraLayoutSpace to increase the extra space reserved by RecyclerView (outside the display range, there should be extra cache space), as shown below:
new LinearLayoutManager(this) {
@Override protected int getExtraLayoutSpace(RecyclerView.State state) {
return size;
}
};
At last
Because there are too many questions and the workload of sorting out answers is too large, it is limited to providing knowledge points. Many detailed questions and reference answers have been compiled into PDF files. Small partners who need it can privately mail me [Interview] for free or click GitHub to get it for free !
… (Img-lIECrrsu-1611134649500)]
[External link image is being transferred...(img-2wSNiqBA-1611134649506)]
