Android-Tips（實用Android開發技巧）

標籤：

整理本人實際開發中遇到的一些問題以及解決辦法和一些開發技巧，以後會不定時更新。

tips:利用“目錄”可快速導航

1.追溯sdk中某一個類隨sdk版本升高導致的曆史變遷。（find API changes）

問題來源：SwipeRefreshLayout源碼：判斷子View是否能向上滾動（或者是否滾動到頂部）：

    /**     * @return Whether it is possible for the child view of this layout to     *         scroll up. Override this if the child view is a custom view.     */    public boolean canChildScrollUp() {        if (android.os.Build.VERSION.SDK_INT < 14) {            if (mTarget instanceof AbsListView) {                final AbsListView absListView = (AbsListView) mTarget;                return absListView.getChildCount() > 0                        && (absListView.getFirstVisiblePosition() > 0 || absListView.getChildAt(0)                                .getTop() < absListView.getPaddingTop());            } else {                return ViewCompat.canScrollVertically(mTarget, -1) || mTarget.getScrollY() > 0;            }        } else {            return ViewCompat.canScrollVertically(mTarget, -1);        }    }

進入Android開發官網，假如要查看View API的變化，輸入View,選擇android.view.View，

進入View的API參考頁面（文檔頁），

可以看到三個主要資訊：

• View是在API level 1添加的
• View的類層次
• 通過左側的API level choose button 可以查看不同API level下的View API，進行縱向的查看,同時可以將不同API level下的View API進行橫向對比。

追溯API 變化就是通過上述第三條實現的。比如我們想看看API level 13和 API level 14之間有什麼變化，將左側API level設定為13,查看方法列表：

我們會發現一些API 是灰色的，當滑鼠hover過方法名時，會顯示出一個提示，

這個提示告訴我們：View中的canScrollVertically(int direction) 方法是在API level 14以後才添加的，另外canScrollHorizontally(int direction) 也是API level 14以後才添加的方法。當我把API level 切換到14時，發現上述兩個方法的顏色變為藍色了，說明他們的確是在API level 14添加的：

總結：

使用這種方法的好處是不用下載每一個api 版本的原始碼，也可以很方便的對比他們之間的變化。開發參考除了可以對比方法的變化以外，還可以對比內部類，介面等變化，當前選中的API level 為9，結果

2.使用device monitor 中的method profiling 工具尋找app卡頓的元兇

問題來源：使用RxJava時，出現莫名的卡頓，方法嵌套過深，或類別關係過於複雜，難以定位問題。

進入sdk->tools檔案夾。雙擊運行monitor.bat 開啟device monitor：

左側Device tab下是當前的裝置名稱以及待調試應用的包名。在要測試某個操作（方法調用）之前，點擊method profiling 按鈕，彈出對話方塊：

輸入採樣間隔：

輸入採樣間隔，間隔越大，採集到某個方法調用棧的可能性就越小，可能漏掉某個調用棧，越小，採樣精度越高（或者說覆蓋率越高）但是採樣間隔太小，會導致卡頓。所以需要輸入一個合適的採樣間隔。輸入後點確認，然後在app上執行你的操作，執行完後點stop method profiling,會產生一個名為“ddms+時間戳記+.trace”的檔案，這個檔案記錄了方法的調用棧資訊，這個檔案是我們分析的重點:

視圖中上一欄，展示了在method profile過程中並存執行的所有線程或進程。下一欄的表格展示了方法的調用資訊，如方法名，所耗時間，cpu佔用等。可參考：http://blog.csdn.net/androiddevelop/article/details/8223805

表格中相關列名的說明：

點擊表格每一欄的名字可以進行排序，根據Name找到上述操作調用的方法，如fetchData:

Parents值得是fetchData的調用入口，而Children指的是fetchData方法中的子調用。
可以看出每個子調用或父調用的耗時情況，可以看出fetchData中的子調用fetchDataImpl耗時22.777ms,繼續點擊fetchDataImpl可以進入fetchDataImpl的調用棧，分析方式就同fetchData了，通過這種方式可以定位耗時操作的源頭：

總結：

使用method profiling可以分析方法的調用棧，找出app的效能瓶頸。android device monitor的功能很強大，是一個工具的合集，還可以分析Heap Dump,Allocation,Network,查看Device的檔案等。好的工具可以提升開發效率，科學使用工具可以事半功倍。另外推薦一款線上APP 冷啟動效能分析工具：Nimbledroid 可以分析APP 冷啟動的調用棧，通過他可以最佳化APP的啟動速度，並能通過學習別的app加快啟動速度的方式，提高自己app的啟動速度。

以後會不定時更新，未完待續。

Android-Tips（實用Android開發技巧）