Android Interface Optimization skills and android interface skills

Android Interface Optimization skills and android interface skills
The optimization will talk about adapter from the following aspects: the simplest method, the slowest and least practical, and the convertView is used to retrieve views at an update frequency of about 10 frames per second, improving the efficiency by 200%, update frequency: The ViewHolder mode is used for transmission of frames per second for about 30, and the efficiency is improved by 250%. The update frequency is about 40 frames per second. Background and image: select the appropriate image size, the view background image will always fill the entire view area: * The image size is not suitable, which will cause automatic scaling * avoid real-time scaling * it is best to pre-scale to the View Size originalImage = Bitmap. createScaledBitmap (originalImage, // view the scaled image. getWidth (), // view width. getHeight (), // view height true); // returns the background and image update frequency of the bilinear filter. The pre-scale transmission frames per second is about 50, and the window background is automatically scaled around 25: * By default, The window has an opaque background * Sometimes it is not required. -The top-level view is not transparent-the top-level view overwrites the entire window fill_parent * updating the invisible background is a waste of time * deleting the window background-getWindow (). setBackgroundDrawable (null);-<item name = "android: windowBackground"> @ null </item> the background update frequency of the window. The number of frames transmitted per second with a background is about 42, there is no background update request around 50: * when the screen needs to be updated, call invalidate ()-Simple and Convenient-but the entire view will be updated, too expensive * it is best to first find the invalid region, then call. The more effective method is to update only the region to be updated-invalidate (Rect dirty);-invalidate (int left, int top, int right, int bottom); window background update frequency: the invalidate is transmitted at around 18 per second, and the last two are at around 48 views and la s: * If a window contains multiple views-long start time, long measurement time, long layout time, long drawing time * If the view tree depth is too deep-StackOverflowException the user interface is slow to respond * solution-use TextView composite drawables reduce layers-use ViewStub latency to expand views-use <merge> to merge intermediate views-use RelativeLayout to reduce layers-use custom views and use custom Layout for memory allocation: * do not create Java objects. in performance-sensitive code, avoid creating Java objects-Measurement: onMeasure ()-layout: onLayout ()-plotting: dispatchDraw (), onDraw () -event processing: dispatchTouchEvent (), onTouchEvent ()-Adapter: getView (), bindView () * GC, garbage collection: the entire program is suspended, slow (about several hundred milliseconds * managed objects * use soft references, the best choice for memory cache * use weak references to avoid Memory leakage
Conclusion: * use ViewHolder to implement getView of Adapter * select the correct image for the background * update request for invalid areas * view and layout. The simpler the better * avoid creating objects in performance-sensitive paths