第九章 競品技術分析

splash廣告邏輯，首次加載的圖檔為應用放在res檔案夾下面幾個檔案夾裡面的圖檔，同時會去調用接口擷取下一次打開的時候要顯示的圖檔url，并緩存圖檔；下次進入該界面顯示圖檔并繼續通路接下來一次的圖檔，為了保證打開速度，這個網絡請求務必異步處理。

引導圖，不要超過4頁。動畫可原生實作，可gif,可視訊來實作。

進入首頁之前進行地理位置的定位，保證進入首頁顯示的資料為目前城市的資訊。

app首頁設計，盡可能多的将所有産品展示在首頁，會有廣告，搜尋欄，滾動條。

　　上面為使用者可見的資料，一些不可見資料：

umeng打點，統計激活數。

注冊推送。

根據推送協定進行頁面跳轉。

初始化崩潰收集機制，比如崩潰資訊上傳等。

為了加快splash的加載速度建議用戶端這邊盡可能避免耗時間的任務操作

将html5資料打包進zip包裡面去，每次從本地zip解壓檔案裡面加載html5資料；新增或者修改html5資訊怎麼辦，進行版本控制，如果版本一緻，加載本地解壓資料，如果不是加載新的zip包的解壓資料；其中公共的，不變化的html5資料壓縮為公用的zip壓縮包并下發，那麼每次下載下傳的時候隻下載下傳新增和修改的那部分html5檔案的壓縮包。在上個頁面設定不可顯示的webview加載html5資料，在下個webview加載的時候直接從本地緩存檔案裡面去加載。

app安裝包一定要小，或者實作增量更新，減少對使用者流量的不必要耗費。 

圖檔，音頻，視訊檔案應該在前期提供的時候就盡可能處理的體積足夠小。

       我的觀點：

　　對于分享，推送，定位，地圖等第三方服務內建的時候，能用微信官方，新浪官方自己去實作就盡可能自己去實作，因為團隊裡面有人為了實作分享內建umeng分享功能，導緻應用大小增加4M知道，其中包括很多無用的代碼和資源檔案，請慎重。

同背景圖檔，png加載速度大于jpg,手機會對png進行硬體加速。

網絡圖檔采用jpg圖檔比較合适。

廣告圖，引導圖采用jpg比較合适。

splash圖檔現在在300-500k之間。

引導圖可以将背景圖檔和前景圖檔分開，實作背景圖檔或者前景圖檔的可重用性。

背景圖限制在1M以内，并沒必要png格式，jpg格式就行了。

表情包的方案同上面html5頁面打開速度的論述，都是通過zip來進行增量更新。

eclipse時代用undector可以實作無用代碼的檢測，android studio暫時沒發現，無用資源檔案可以通過link來實作無用資源檔案，無用style等檢測，但是還是需要手動進行删除。

通過使用proguard來配置混淆代碼檔案來清理無用的代碼，減少apk的大小。

網絡請求優化：針對2G,3G,4G,wifi環境伺服器端配置不同的伺服器，分别接入移動，聯通，電信的專線，并在用戶端進行配置，app登入擷取周遊通路2G,3G,4G,wifi的針對性域名并判斷出最佳的通路素的的域名，并在一段時間内通路該域名。為了避免搶占同一伺服器的資源，可以在伺服器端設定針對的優先級。

抛棄使用http+json，轉而使用tcp+protobuf。

 我個人項目裡面是寫個路由類，所有的跳轉邏輯都寫在這個路由類裡面，作為所有activity界面跳轉中間控制層。

作者利用反射也提供了一個不錯的思路：

activity的常量類：

demo:

個人認為各有優缺點，還是看自己的偏好吧。

頁面打點：放在跳轉邏輯代碼前面;

事件打點：打點邏輯寫在基類控件裡面，比如寫onclick等觸發事件的基類，并在這些基類裡面寫事件打點的邏輯。

 我一般是上傳到360，百度等加強平台驚醒加強打包，然後利用平台的多管道打包工具進行批量多管道打包，書裡面講的是python程式來實作，你可以去github找找，這類代碼很多。

主要還是處理65536的問題，2種方案：

插件化：獨立子產品做成單獨的apk,使用dexClassLoader來進行加載。

dex分包:主要利用multidex來實作class.dex的拆分。

android代碼的子產品化拆分：

将常用的工具類代碼，封裝代碼，第三方代碼單獨封裝為基礎類庫。

指定資源檔案命名規範，并以子產品名稱作為字首來進行命名。

子產品間傳遞的資料以json或者單獨拉出來公用的bean作為一個庫引用。

一般情況下版本名稱為3位：比如6.0.0

第一位為大版本更新，第二位用于小版本疊代，第三位作為緊急發版。