Android開發中的效能最佳化（摘錄：陳彧堃演講實錄）

　　大家好！我是陳彧堃，其實HTML5我之前也做過一些相關的研究，包括現在我們也在做一些調研。我個人一年前在G3上利用HTML5開發一些東西的時候，我發現原生的對HTML不支援，開始踏踏實實做Android原生代碼開發。目前來說在將來一到兩年內HTML5的東西會慢慢侵蝕原生程式，我講的是現在進行時，現在來說Android開發還是占絕對主導地位。所以今天來看一下Android研發的最佳化。

　　我想做一個小調研，有多少人知道友盟？謝謝！感覺不是很多。簡單介紹一下我們是一個面向中國移動開發人員的服務平台，我們最核心、推出最久的功能是一個統計平台，提供SDK，支援全平台，服務了八千以上的移動廠商，包括了超過一萬五千個行動裝置 App。同時我們還會定期發一些報告，這些報告我們希望對產業鏈中不同的、向開發人員、應用商、產業鏈其他部分夥伴都有一些參考作用。

不同的應用，出的各種各樣的問題，最終歸根到底都是由於體驗問題。找到了使用者體驗問題，就看一下開發痛點，最後提出一些最佳化策略。最後我們提一下代碼複用問題。

　　首先搞清楚關注的東西。大家對這個圖應該很熟悉吧？這是Android的體系架構圖。藍色的上面部分是平時關注最多，基本上都是Java代碼，Android是基於MID開發的，在這個上面提供一些庫，這些庫是純C++的，如果要調的話是向上面提供API，同時Android提供了虛擬層，這比較類似於，但是是不同的介面，因為有這個虛擬層，做Android開發的時候不需要考慮太多記憶體方面的東西，正是由於這個原因導致很多JAV程式員轉做Android的時候，他們會認為不需要考慮效能最佳化的問題。其實這是非常錯誤的認識。

　　在Android上開發都和傳統的Web開發、Java開發不太一樣，所以我們做開發的時候需要更多考慮跟Android手機有關係的設計和最佳化。從使用者體驗出發講三點，第一是使用者要求快速，因為手機上主要訪問資料，所以資料的獲得，有幾個途徑，第一是記憶體，五毫秒去一個資料。我也有一個記憶體檔案、一個資料庫，還有傳統IO。這個需要上百毫秒的時間，IO需要這邊去桌上拿，時間也不是很長。如果你的程式很慢，使用者會馬上看到一個系統提示框，說這個沒有響應，是不是應該關掉，如果使用者關掉之後應該卸載，卸載完之後還不夠，還給你幾個差評，給你一個一星，別人看到這個以後可能再也不會下載這個程式。你可能需要找很多水軍把一星的評論刷掉。這是很不好的體驗。

　　第一點是需要快，第二點需要友好。我們一定要保證使用者操作流暢、自然。Android上面還有一個問題是UI問題，Android機型特別多，但是Android提供很多系統級最佳化策略，協助我們避免這些問題。不要涉及一些太複雜的提示去擋著使用者。因為Android特別開放，現在智能手機都比較開放，像剛才講的2.0，也有一個使用者通知，如果這個太濫，也會讓使用者反感。不要完全照搬iOS設計，Android有很多自己的特點，有菜單鍵、返回鍵，管理都是和iOS不太一樣的地方。

　　Android上有一個返回鍵，很多iOS設計師過來的時候會把iOS菜單鍵，把那個設計直接帶過來用，直接無視Android的按鈕，打破了使用者預期，他會覺得無所適從，所有系統原生程式充分利用了返回鍵。所以我們要尊重使用者期望，滿足他的心理期許。

　　關係到使用者體驗的第三點是一定要省電，一個手機如果需要每天都充電，算不算一個行動裝置？我覺得不算。首先要避免一些複雜演算法，我有朋友曾經在Android手機上實現過哈析表，是Google這種大公司做Email，還是一個分級的，這個Email先做哈析然後再哈析，他做完以後得意。但是使用者發現，當他開啟應用的時候，系統會發現耗電量太大了，沒過幾天他就自己更新了，省了很多電，效能沒有受太大的影響。手機上真的不要涉及太複雜的演算法。

　　因為多進程、多限程，並且Android沒有退出的設計，所以可以設計一個永遠在後台跑的，推出一些資訊、提供一些時間。我建議考慮一下即時和非即時兩種不同需求。如果即時建議使用Google的功能。如果是非即時的需求，建議一定要延長推崇時間，比如隔幾個小時、一天撲一次。而且時間可以設定得靈活一些。五比如說設了一個更新的鍵，可以放一個欄位，這個欄位代表更新周期，每次更新的時候先把欄位做好。可以應付一些一會兒很緊，在你需要平台更新的時候更新，不需要的時候把時間限制設長一些。

還有網路請求不要太長，平均每個使用者使用時間長度一分鐘，現在在Android手機上一次GPS請求(中國移動基本上2G比較普遍)一次10秒以上比較普遍，一次串連20秒，三次串連使用者就關閉了。所以不要頻繁請求。可以結合一些壓縮方式來減少網路次數。

（我認為如果要想做好Android開發，一定要能夠訪問國外的論壇和高手切磋。因為國外的論壇，上面有最先進、最前沿的Android技術）

　　第二點適配問題，分幾個問題，硬體、解析度還有OS。Android手機有各個價格位的。我們有一個夥伴Camera360，他們說在做拍照的時候，需要對不同網路攝影機做了大量最佳化，有的是200萬像素、有的上千萬像素，對圖片處理完全不一樣。這是比較痛苦的事。

　　然後看一下解析度，這是二季度的總結，沒有一個手機解析度佔主導地位，最多的是800×480，也只佔30%不到的比例。剩下的不同解析度千奇百怪，現在在中國Android量很大，不可能忽略一個很怪的解析度，魅族的980×640，但是佔6%的比例，所以沒有辦法忽略。

　　這是最近的關於Android分裂的圖，據統計在18個Android裝置中，7個不用最新版Android，12個使用最新版短於一周，10個落後最新版兩代，15個沒有運行Android 3.0。

還有記憶體管理，Android裡記憶體管理是非常難的問題，對於每個記憶體限制24M，而老式手機上限制16，這種概念大家看好像比較大，但是實際上應用本身會超過十兆，分的記憶體空間已經非常少，如果你做一些圖片應用，拍幾張照，直接讀出來是長跟寬，一張照片一般都是1兆以上。所以經常會出現out of Memory問題。我們怎麼解決這個問題呢？從幾個方面解決，首先從視圖方面最佳化。我們善於運用Android提供的工具，Google提供了分析視圖結構，提供一些建議。FrameLayout不要濫用。不要超過13層嵌套，不要超過80個view。還有一個工具是TraceView，函數單獨化時間是多少，這個函數包含所有的子函數的時間是多少。其實Google提供非常非常豐富的開發協助工具輔助，還有很多沒有講到，比如一個隨即測試介面的程式。

　　怎麼減少View以及View的嵌套層次呢？左邊是一個圖，右面是上下兩行文字。有兩種寫法，一種是把文字包起來，另外一種是寫兩行文字，設一個相互關係。看上去沒有太大的差別，但是看一下樹，如果用嵌套，子模組結構變化這樣，如果不用嵌套，相對位置關係就變化成這樣。如果只有這條沒有任何問題，但如果模組被大量應用在列表裡，會導致主線會經常變得很慢，如果滑動的時候會變得很卡。這些是一些小細節。

　　還有一個問題是圖片當中，Android提供一個技術，可以把圖局部放大，如果直接展開，因為每個像素均勻展開，那麼邊角會變得模糊。怎麼樣從左邊無縫展開到右邊？簡單介紹一下這個原理，一張圖通過這個工具，把圖定義成兩個地區，第一是左邊和上邊的投影，投影到中間會決定你的內容，下面和右邊，投影出來的內容會決定你的PNG。小圖放大的問題是被均等放大，放大之後變得特別猛，畫兩條黑線，制定上面和左邊，決定了展開的地區。邊緣不展開了。就這個意思。就能產生上面的效果。

　　還有更複雜的，左邊這張小圖怎麼變成右邊的圖？可以指定不同的複合地區。編輯圖片壓縮會帶來很大的優勢，如果處理得好，可以省很多apk大小，下載apk的時候下載率會大幅度提高。做過一個不太精準的統計，下載率50%左右，一半情況會失敗，失敗情況是因為包太大。圖片壓縮是很重要的技術。

　　另外從解析度上適配，剛才說了系統會提供一些手段幫你做適配。提供幾種不同的檔案夾，ldpi、mdpi、hdpi，代表三種不同精度，系統會自己分析精度做定位。另外要盡量多使用dp，跟當前裝置有關係的一個像處理。Pixel有問題，他們往往想直接用，用PS，Android裡不一樣，Pixel裡有什麼問題？有一句話叫supports 想問開發人員你的程式適不適配於小螢幕、大螢幕、中螢幕，如果選擇否，系統認為你沒有經過特殊的配置，這時候會出什麼問題？比如800×480的裝置，通過大解析度，會轉化為533×320，因為使用了API。他認為你畫的點，其實想畫在15ph、15px這個點，因為他想幫你做適配。這個時候讀API會讀錯，所以盡量不要用pihel，不要用絕對布局。

　　記憶體方面的最佳化，其中一個很大的最佳化是圖片最佳化，大家知道Bi圖直接讀大小是X×Y，我們要自己壓縮，設一下壓縮率就可以了。做應用的很多很多問題，跨寫、包括M，其實很簡單，可以寫很多東西。

　　還有就是要瞭解編譯器的最佳化原則。某種程度上是反OO的問題，不要太多用getter和setter，包括訪問速度都有一系列的問題。

　　另外說一下關於C++開發，鐵峰也講了，C++的確某些情境下會提升效能，這個領域是遊戲。如果普遍應用想用C++就需要謹慎，除非有特別好的C++高手，包括C的代碼也不可以做最佳化，那時候很多東西，做出來還不如全部用加法寫速度快。

　　另外下載的時候一定要有buffer。我們的經驗是，因為我們做SDO，做了很多資料壓縮方面的探索，結合兩種技術會導致網路發送資料包大小變成原代碼的30%左右，這是非常省流量和減少失敗率的方法。別人看代碼的時候會出現一些小問題。其實我認為更大的好處還是在於降低了APK大小，可以提升APK下載成功率。

最後再說一下當我們寫很多代碼之後怎麼樣複用代碼。最傳統的做法和JAVA沒什麼區別，優點是穩定，但是缺點是無法整合資源檔。

　　Android提供了一個新的複用，叫Android Library。第一步是先建立Library工程，別人可以直接用這個工程，不用管資源什麼東西。也有一個問題，它的習慣問題。現在開發人員不太習慣這種機制，並且會有資源衝突。所以大家要根據自己開發習慣和項目實際情況去考慮這個問題。

　　最後就是講一下用戶端的技術，最後比拼的還是服務。所以掌握伺服器開發很重要。個人推薦大家掌握一個容易上手的。其實最終大家拼的還是一個互聯的一種服務，而不是用戶端做得如何漂亮。

　　另外用戶端可能進行一些比較複雜的計算的時候，要深思熟慮一下，你的計算是不是一定要做，是不是資料經常需要更新，如果是的話需要把這個東西放在伺服器端啊，伺服器端跟用戶端涉及一套協議。但如果發展起來之後，這個問題可能不存在，但是目前來說，要根據自己的業務來決定選擇什麼樣的BS2、CS2。

　　綜合來看，第一點要跟tracrace和monkey結合測試，然後寫代碼，最後做好代碼複用，精通一門伺服器開發構架，儘快變成伺服器端構架應用。最後以運用的心態經營應用。為什麼呢？說到運營的話，必須要瞭解，我們有提供瞭解使用者的一種機制，我們是一個非常專註瞭解協助開發人員瞭解應用的各種使用方式，包括收集你的crash報表，告訴程式員最容易犯的錯誤是什麼，我們也提供一種雙向反饋系統。我們提供一個介面，使用者可以通過介面提交反饋，他覺得你有什麼不好給你建議，在我們網站上可以看到這個建議，看到建議之後可以給他回複，使用者第二次啟動應用會看到這條回複，建立了使用者和開發人員之間雙向的渠道。從而提供一些應用聯盟做推廣，交叉推廣的工具。

　　如果大家有興趣可以訪問我們的網站和微博，謝謝大家！