阿里巴巴Android開發手冊V1.0.0隨手筆記

該筆記主要記錄本人在讀《阿里巴巴Adroid開發手冊》的過程，自我感受有疑惑或者值得記錄的地方。故並不是對全部內容都有涉略。有興趣的朋友能夠看成一個參考內容來看看。主要按該手冊的章節進行閱讀，記錄。後續有新的感悟還會補充。

2、Android資源文件命名與使用

【自我感悟】1. Java按必定的規律來命名控件。作到多module時資源不會衝突以及模塊命名定義清晰。

3、Android 基本組件

1【強制】Activity 間的數據通訊，對於數據量比較大的，避免使用 Intent + Parcelable 的方式，能夠考慮 EventBus 等替代方案，以避免形成 TransactionTooLargeException。

其餘還能夠搞個靜態內部類或者單例來保存數據，在一個activity存，另外一個取。這些方法本質上都是開闢一塊公共區域來存取數據。

（猜想前一個Activity的onStop中用EventBus發送數據，另外一個目標Activity的onCreate中對EventBus進行註冊）

2.【強制】避免在 BroadcastReceiver#onReceive()中執行耗時操做，若是有耗時工做， 應該建立 IntentService 完成，而不該該在 BroadcastReceiver 內建立子線程去作。

【緣由】由於BroadcastReceiver生命週期很短，一旦結束，其所在進程就屬於空進程(沒有任何活動組件的進程)，極易在系統內存不足時優先被殺死，而正在工做的子線程也會被殺死。因此，推薦開啓一個service，將耗時操做交給service，這樣能夠提升宿主進程優先級，保證耗時操做執行完成。

3.【推薦】當前 Activity 的 onPause 方法執行結束後纔會執行下一個 Activity 的 onCreate 方法，因此在 onPause 方法中不適合作耗時較長的工做，這會影響到頁面之間的跳 轉效率。

4.對於只用於應用內的廣播，優先使用 LocalBroadcastManager 來進行註冊 和發送，LocalBroadcastManager 安全性更好，同時擁有更高的運行效率。

【緣由】LocalBroadcastManager只在app內進行廣播，不會在各app之間進行傳播。可防止本身的廣播信息被別有用心的人監聽。（跨Activity數據傳遞本質上是找了一個公共區域用來存放數據）

4、UI 與佈局

1. 【強制】佈局中不得不使用 ViewGroup 多重嵌套時，不要使用 LinearLayout 嵌套，改用 RelativeLayout，能夠有效下降嵌套數。

【緣由】同一個佈局在不少狀況下RelativeLayout下的佈局所需的層次會小於LinearLayout所需的佈局可減小過分繪製。可是在佈局相同的狀況下用LinearLayout更加好。由於RelativeLayout會進行上下和左右兩次measure

2.【推薦】在 Activity 中顯示對話框或彈出浮層時，儘可能使用 DialogFragment，而非 Dialog/AlertDialog，這樣便於隨 Activity 生命週期管理對話框/彈出浮層的生命週期。

3.【推薦】文本大小使用單位 dp，view 大小使用單位 dp。對於 Textview，若是在文 字大小肯定的狀況下推薦使用 wrap_content 佈局避免出現文字顯示不全的適配問 題。

【緣由】sp會隨着用戶在設置中設置系統大小不一樣而變化。字體變化後有可能致使app適配的問題。同時國內的rom碎片化也有可能致使各類顯示問題。而dp會一直保持現有大小。可是這個的弊端是用戶調整系統的字體大小後，你自身app的大小不能進行變化。有點違背系統的感受。我的感受用哪一個根據本身須要吧。目前我仍是用的sp

4.【推薦】不能在 Activity 沒有徹底顯示時顯示 PopupWindow 和 Dialog。

【緣由】PopupWindow不像對話框那樣從屏幕的固定位置彈出，而是依賴於錨點控件對象的位置，所謂錨點控件對象，就是界面組件中的某個控件，PopupWindow的展現和功能都是以它爲核心，做爲錨點控件的擴展交互界面，以加強該控件對象的功能。彈出窗口與描點控件有着緊密的聯繫，在構造並展現彈出窗口前，須要保證錨點控件所在的控件樹已經與窗口管理服務創建鏈接，由於在彈出窗口的展現過程當中，須要經過該窗口對象來獲取相關信息。在界面組件的構造過程當中，窗口鏈接的創建是個異步過程，也就是說，當Activity.onCreate()等函數被調用時，界面與窗口管理服務的雙向通訊鏈接還沒有創建，若是在此時構造彈出窗口則會拋出異常。所以，若是指望在界面組件展示之處便構造彈出窗口，能夠將彈出窗口對象構造也轉換成一個異步過程。即view.post(new running()).

5.【強制】不能使用 ScrollView 包裹 ListView/GridView/ExpandableListVIew;由於這 樣會把 ListView 的全部 Item 都加載到內存中，要消耗巨大的內存和 cpu 去繪製圖 面。

說明:ScrollView 中嵌套 List 或 RecyclerView 的作法官方明確禁止。除了開發過程當中遇到的各類視覺和交互問題，這種作法對性能也有較大損耗。ListView 等 UI 組件自身有垂直滾動功能，也沒有必要在嵌套一層 ScrollView。目前爲了較好的 UI 體驗，更貼近 Material Design 的設計，推薦使用 NestedScrollView

PS：本人測試NestedScrollView中添加ListView也會所有添加。相似於要使用這種需求。能夠用阿里的Vlayout佈局。或者ListView添加HeadView等。

5、進程、線程與消息通訊

1.【強制】不要經過 Intent 在 Android 基礎組件之間傳遞大數據(binder transaction 緩存爲 1MB)，可能致使 OOM。

2.【強制】新建線程時，必須經過線程池提供(AsyncTask 或者 ThreadPoolExecutor 或者其餘形式自定義的線程池)，不容許在應用中自行顯式建立線程。

【緣由】本人在開發app中發現若是多人一塊兒開發而且都我的建立線程則會致使app內線程亂飛。嚴重的如華爲的某些機制在線程數達到500時會致使crash。建議根據業務定義幾個全局統一的線程庫。

3.【強制】線程池不容許使用 Executors 去建立，而是經過 ThreadPoolExecutor 的方 式，這樣的處理方式讓寫的同窗更加明確線程池的運行規則，規避資源耗盡的風險。

4.【強制】不要在非 UI 線程中初始化 ViewStub，不然會返回 null。

6、文件與數據庫

1. 【強制】任什麼時候候不要硬編碼文件路徑，請使用 Android 文件系統 API 訪問。

android.os.Environment#getExternalStorageDirectory() android.os.Environment#getExternalStoragePublicDirectory() android.content.Context#getFilesDir() android.content.Context#getCacheDir

2.【推薦】SharedPreference 提交數據時，儘可能使用 Editor#apply()，而非 Editor#commit()。通常來說，僅當須要肯定提交結果，並據此有後續操做時，才使 用 Editor#commit()。

說明:SharedPreference 相關修改使用 apply 方法進行提交會先寫入內存，而後異步寫入 磁盤，commit 方法是直接寫入磁盤。若是頻繁操做的話 apply 的性能會優於 commit，apply 會將最後修改內容寫入磁盤。可是若是但願馬上獲取存儲操做的結果，並據此作相應的其餘操做，應當使用 commit.

7、Bitmap、Drawable 與動畫

這節講到的內容基本上都有所瞭解。因此不作記錄了。主要就是要注意不要OOM。

8、安全

1.不要把敏感信息打印到 log 中.

【方法】在產品的線上版本中關閉調試接口，不要輸出敏感信息。方法參考 https://mp.weixin.qq.com/s/DE4gr8cTRQp2jQq3c6wGHQ 黑科技:用Proguard的-assumenosideeffects清除log

這節的內容瞭解的基本都瞭解。有些內容真的基本沒怎麼涉略過。後續要好好研究一下。