1.GLSurfaceView把上層的View遮蓋
在使用GLSurfaceView開發(fā)的時候，會調到到setZOrderOnTop(boolean onTop)這個方法汽煮，而這個方法大概的意思是將GLSurfaceView放置到window界面的最上層匀们，所以GLSurfaceView上面是不會顯示其他View的献汗。下面這個段是官方對這個方法的介紹。
Control whether the surface view's surface is placed on top of its window. Normally it is placed behind the window, to allow it to (for the most part) appear to composite with the views in the hierarchy. By setting this, you cause it to be placed above the window. This means that none of the contents of the window this SurfaceView is in will be visible on top of its surface.
Note that this must be set before the surface view's containing window is attached to the window manager. If you target `[Build.VERSION_CODES#R](https://developer.android.google.cn/reference/android/os/Build.VERSION_CODES#R)` the Z ordering can be changed dynamically if the backing surface is created, otherwise it would be applied at surface construction time.
Calling this overrides any previous call to [setZOrderMediaOverlay(boolean)](https://developer.android.google.cn/reference/android/view/SurfaceView#setZOrderMediaOverlay(boolean)).
在這段官方介紹的最后提到了setZOrderMediaOverlay(boolean isMediaOverlay)這個方法资厉，下面是setZOrderMediaOverlay的官方介紹厅缺，這段介紹不太好理解，根據(jù)我自身的使用和理解宴偿，這段介紹的意思是調用setZOrderMediaOverlay方法后湘捎，GLSurfaceView依然會顯示在最上面，只是會在對應的位置開一個口顯示需要置頂?shù)腣iew窄刘。
Control whether the surface view's surface is placed on top of another regular surface view in the window (but still behind the window itself). This is typically used to place overlays on top of an underlying media surface view.
Note that this must be set before the surface view's containing window is attached to the window manager.
Calling this overrides any previous call to `[setZOrderOnTop(boolean)](https://developer.android.google.cn/reference/android/view/SurfaceView#setZOrderOnTop(boolean))`.
2.使用Arrays將數(shù)組轉集合窥妇，再進行添加或移除的時候報UnsupportedOperationException錯誤
在Arrays類里面有一個自定義的ArrayList類，而這個類并沒有實現(xiàn)add和remove方法娩践，在AbstractList類中活翩，這個兩個方法直接拋出UnsupportedOperationException錯誤，所以在使用Arrays的asList方法的時候要注意得到的ArrayList集合并不是我們平時使用java.util.ArrayList類得到的集合
3.Type BuildConfig is defined multiple times
在多模塊開發(fā)的時候欺矫，如果AndroidManifest.xml文件中的package相同則會導致出現(xiàn)這個問題纱新。
4.當背景資源設置成select的時候，當view的enable設置成false的時候沒有切換到對應enable=false的資源
錯誤的順序：
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@drawable/shape_func1_radius_60" android:state_pressed="false" />
<item android:drawable="@drawable/shape_func14_radius_60" android:state_pressed="true" />
<item android:drawable="@drawable/shape_func1_radius_60" android:state_enabled="true" />
<item android:drawable="@drawable/shape_func14_radius_60" android:state_enabled="false" />
</selector>
根據(jù)你提供的selector資源穆趴，當View處于disabled狀態(tài)時脸爱，它的背景色應該顯示為@drawable/shape_func14_radius_60對應的顏色。但是未妹，你發(fā)現(xiàn)當View的android:enabled屬性設置為false時簿废，它的背景色并沒有顯示為@drawable/shape_func14_radius_60對應的顏色。
這種情況可能是由于selector資源中的item順序導致的络它。在selector資源中族檬，item的順序很重要，因為它決定了哪個item會被優(yōu)先匹配化戳。在你的selector資源中单料，第三個item和第四個item都定義了android:state_enabled屬性，但是它們的順序錯誤点楼。
正確的item順序應該是這樣的：
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@drawable/shape_func14_radius_60" android:state_pressed="true" />
<item android:drawable="@drawable/shape_func14_radius_60" android:state_enabled="false" />
<item android:drawable="@drawable/shape_func1_radius_60" android:state_enabled="true" />
<item android:drawable="@drawable/shape_func1_radius_60" />
</selector>
在上面的selector資源中扫尖，第一個item定義了View處于pressed狀態(tài)時的背景色，第二個item定義了View處于disabled狀態(tài)時的背景色掠廓，第三個item定義了View處于enabled狀態(tài)時的背景色换怖，第四個item定義了View處于默認狀態(tài)時的背景色。
當View的android:enabled屬性設置為false時蟀瞧，selector資源會優(yōu)先匹配第二個item沉颂，因此View的背景色會顯示為@drawable/shape_func14_radius_60對應的顏色条摸。
需要注意的是，在selector資源中铸屉，如果多個item的state屬性都匹配當前的狀態(tài)钉蒲，那么selector資源會優(yōu)先匹配第一個滿足條件的item。因此彻坛，在定義selector資源時子巾，應該盡可能地避免定義沖突的item。
5.Kotlin和Java混合使用出現(xiàn)空指針異常
當使用Kotlin實現(xiàn)Java的接口時候需要注意接口方法的參數(shù)是否能為空的問題
public interface ITestListener {
void onTest(String data);
}
...
ITestListener listener = ...;
listener.onTest(null);
...
Java在定義接口的時候是可以不用設置參數(shù)是否能為空小压，但是在實際調用的時候是可以傳空參數(shù)進去的。
而Kotlin在實現(xiàn)這個接口的時候椰于，參數(shù)可空是需要加上怠益？代表參數(shù)可空，如果在實現(xiàn)這個接口的時候沒有加上瘾婿？蜻牢，而調用方傳參的時候使用null，這個時候就會出現(xiàn)空指針異常偏陪。
//這個是錯誤的演示
val listener = object:ITestListener {
fun onTest(data: String) {
//data參數(shù)沒有設置成可空抢呆，那么如果調用方傳參的時候設置null，這里就會出現(xiàn)空指針異常
}
}
所以在做Kotlin和Java混合開發(fā)的時候笛谦，Kotlin在實現(xiàn)Java接口的時候盡量將Java中非基礎類型的參數(shù)設置成可空抱虐。
//這個是正確的演示
val listener = object:ITestListener {
fun onTest(data: String?) {
//data參數(shù)設置成可空，那么調用方傳來null也不會出現(xiàn)空指針異常
}
}
6.so 崩潰堆棧解析
1.需要將崩潰的堆棧信息從*******開始保存
2.執(zhí)行./ndk-stack -sym <so庫的目錄> -dump <保存崩潰信息的文件>
3.執(zhí)行用的 ndk-stack 要使用編譯 so 庫對應的 ndk 版本饥脑，路徑一般位于Android sdk 的 NDK 目錄中
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: ''
Revision: '0'
ABI: 'arm64'
Timestamp:
Process uptime: 55s
Cmdline:
pid: 25202, tid: 27734, name:
uid: 10390
tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: 'Scudo ERROR: invalid chunk state when deallocating address 0x20000746d42d350'
x0 0000000000000000 x1 0000000000006c56 x2 0000000000000006 x3 00000072860fd920
x4 64736073721f6a6d x5 64736073721f6a6d x6 64736073721f6a6d x7 7f7f7f7f7f7f7f7f
x8 00000000000000f0 x9 00000075dd68f920 x10 0000000000000001 x11 00000075dd71b4c0
x12 00000075e31ed020 x13 000000007fffffff x14 0000000002c0a9ea x15 00000496365c7647
x16 00000075dd78aa60 x17 00000075dd763dd0 x18 0000006efcfb4000 x19 0000000000006272
x20 0000000000006c56 x21 00000000ffffffff x22 0000000000000000 x23 0000000000006272
x24 00000072860fdcb0 x25 00000072860fdcb0 x26 00000072860fdff8 x27 00000075e1e4b000
x28 0000000000000000 x29 00000072860fd9a0
lr 00000075dd70b898 sp 00000072860fd900 pc 00000075dd70b8c4 pst 0000000000001000
13 total frames
backtrace:
#00 pc 00000000000a58c4 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: 35647bdbfd4abaae505972042de0d304)
#01 pc 0000000000090618 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::die()+8) (BuildId: 35647bdbfd4abaae505972042de0d304)
#02 pc 0000000000091240 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::ScopedErrorReport::~ScopedErrorReport()+32) (BuildId: 35647bdbfd4abaae505972042de0d304)
#03 pc 0000000000091764 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportInvalidChunkState(scudo::AllocatorAction, void*)+116) (BuildId: 35647bdbfd4abaae505972042de0d304)
#04 pc 000000000009351c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+332) (BuildId: 35647bdbfd4abaae505972042de0d304)
