处理一些warning

1.Avoid object allocations during draw/layout operations (preallocate and reuse instead)

用Android自带的lint测试，发现上面这个问题。。。。百度一番发现。。。在ondraw/onlayout中尽量不要用new 对象的操作。。。因为ondraw/onlayout会经常被调用；这样比较耗内存。。。。

2.The vertically scrolling ScrollView should not contain another vertically scrolling widget (GridView)

3.Incorrect line ending: found carriage return (\r) without corresponding newline (\n)

4.This LinearLayout should use android:layout_height="wrap_content"

回答：ScrollView children must set their layout_width or layout_height attributes to wrap_content rather than fill_parent or match_parent in the scrolling dimension，ScrollView的子View必须设置他们的宽或者高为wrap_content.

5.The following images appear in both -nodpi and in a density folder: search_play_icon.png, search_ugc_icon_filter.png, volumn_bg.9.png, volumn_front.9.png, volumn_primary.9.png

回答：以下的图片在nodpi中Bitmaps that appear in drawable-nodpi folders will not be scaled by the Android framework. If a drawable resource of the same name appears both in a -nodpi folder as well as a dpi folder such as drawable-hdpi, then the behavior is ambiguous and probably not intentional. Delete one or the other, or use different names for the icons.删除nodpi中的图片，或者定义名字和其他资源包的名字不一样。。。

6.Do not hardcode "/sdcard/"; use Environment.getExternalStorageDirectory().getPath() instead

回答：不要硬编码。。而是要用系统的Environment.getExternalStorageDirectory().getPath()

7.Replace "-" with an "en dash" character (–, –) ?

回答：在string引用文件中把-替换成–

8.This Handler class should be static or leaks might occur 

回答：In Android, Handler classes should be static or leaks might occur. Messages enqueued on the application thread's MessageQueue also retain their target Handler. If the Handler is an inner class, its outer class will be retained as well. To avoid leaking the outer class, declare the Handler as a static nested class with a WeakReference to its outer class.

9.Use new SparseArray<ArrayList<TextView>>(...) instead for better performance

回答：当定义new HashMap<Integer, ArrayList<TextView>>();这个类型时，Android建议

For maps where the keys are of type integer, it's typically more efficient to use the Android SparseArray API. This check identifies scenarios where you might want to consider using SparseArray instead of HashMap for better performance.


This is particularly useful when the value types are primitives like ints, where you can use SparseIntArray and avoid auto-boxing the values from int to Integer.


If you need to construct a HashMap because you need to call an API outside of your control which requires a Map, you can suppress this warning using for example the @SuppressLint annotation.