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.