① 2016年，移動開發領域有哪些最佳實踐值得參考
參考下面
從開發角度看，移動相關的架構、開發也有很多獨特之處。在即將於4月21~23日舉行的QCon北京2016上，就准備了很多移動開發方面的最佳實踐，來自騰訊、阿里巴巴、網路、京東、華為、美團、網易、和滴滴出行等公司的專家將分享他們的一手經驗。
本次QCon，有「移動開發挑戰」和「移動測試技術」兩個移動相關的專題，其他專題也有與移動相關的產品設計、大數據和架構方面的演講。
移動開發挑戰
移動開發挑戰專題，出品人是美團網高級技術專家、美團客戶端平台團隊負責人陳曉亮。先來看看這個專題會有哪些精彩內容。
隨著3G、4G網路的普及，Wi-Fi熱點的增多，移動網路上的音視頻需求越來越多。移動互聯網的很多領域對音視頻通話有強需求，例如社交、情侶、在線教
育、移動醫療、O2O
等。讓App能通話，是一件既炫酷又實用的事情。不過移動互聯網的音視頻通話存在方方面面的挑戰，比如中國東北網通用戶，和中國南方電信用戶通話，網
絡不好怎麼辦；通話卡頓，如何診斷問題出在哪裡；如何評估某次通話的傳輸質量好不好；機場、學校、公司這些場所，有防火牆封埠怎麼辦。種種問題，聲網首
席音視頻架構師孫雨潤將在演講《移動互聯網的音視頻傳輸挑戰》中一一解答。
手機App在音視頻方面的應用產品，近兩年呈井噴狀態。觀眾在流暢地觀看著視頻畫面的同時，背後其實包含了大量的技術難題。網易杭州研究院多媒體技術專家
郭再榮也將談談《移動端音視頻應用優化之道》。本次分享將從手機攝像頭數據採集開始，把視頻編碼、數據傳輸、視頻解碼、畫面顯示整條鏈路中的技術難點和優
化方法進行詳細講解。另外，還會對音視頻開發者最關心的一些問題如直播延時、畫面清晰度、手機端資源消耗等展開討論。
很多團隊要同時維護多個項目，還要快速迭代，穩定性、容錯能力都非常重要。網路的鳳巢App團隊就是這樣，在同一時間要開發和維護數個項目。網路移動開發
平台針對android和iOS兩個平台，通過對基礎功能抽取並單獨封裝SDK完成非業務剝離，剝離後的通用功能整體為一個SDK，每個獨立功能又單獨封
裝為SDK，即SDK插件化；這樣SDK不但具備可插拔功能，而且在開發者角度上具備自動獲取更新功能。網路移動端架構師李禕嵩將分享《網路移動開發平台
最佳實踐》。
隨著移動互聯網蓬勃發展，App規模越來越大，對App發布迭代速度和質量有更高的要求，技術開發同學面臨著更大的挑戰。怎樣讓App發布更快更靈活，以
及上線後更快地修復各種Crash和緊急Bug，讓用戶免去下載安裝的操作，在最短的時間內升級用戶手中的App，是Android開發人員面臨的一個重
要的技術課題。騰訊社交平台部Android平台組組長俞尚將分享《Android超級補丁包技術》。QQ空間團隊在去年實現class替換熱補丁包技術
的基礎上，更進一步在業內首創超級補丁包技術，實現了App上Dex和資源替換覆蓋，在開發人員和用戶都完全透明無感知的情況下，可把任意App直接升級
到最新版本。補丁技術已經在空間、微信和QQ等騰訊公司重量級產品上得到推廣和應用，在此希望和業內其他團隊在技術上做些分享和交流。
前端技術和移動端開發結合越來越緊密。Weex是阿里巴巴提出的移動應用的全新技術解決方案，能夠將傳統Native的性能和HTML5的靈活和開發體驗
巧妙結合，同時在大規模工程實踐和在微觀問題上的無侵入性運用方面具備非常大的優勢。淘寶無線前端架構負責人趙錦江（勾股）和阿里技術專家徐凱（鬼道）將
分享《Weex——靈活的移動端高性能動態化方案》，希望從前端開發體驗和理念上，以及從Native端的渲染能力上，完整的呈現。
② Android無線開發的幾種常用技術（阿里巴巴資深
完整的開發一個android移動App需要經過從分解需求、架構設計到開發調試、測試、上線發布等多個階段，在發布後還會有產品功能上的迭代演進，此外還會面對性能、安全、無線網路質量等多方面的問題。
移動App的產品形態各不相同，有的是內容類，有的是工具類，有的是社交類，所以它們的業務邏輯所偏重的核心技術有些差別，但它們都會用到一些常用的技術方案。今天我們就先來簡單介紹一下這些常用技術，以後會專門分專題來詳細介紹這些技術的原理和使用場景。
1. Multidex
在Dalvik虛擬機所使用的dex文件格式中，用原生類型short來索引文件中的方法數，也就是最多隻能有4個位元組65536個method，在打包apk的過程中會把工程所需要的全部class文件都合並壓縮到一個dex文件中，也就是說自己開發的代碼加上外部引用的庫的方法總數不能超過65535。
隨著業務邏輯的不斷增長，很容易就會超過這個限制，在編譯期間就會遇到這樣一個錯誤：
還好google官方給出了一個解決方案Multidex，它會把dex文件拆成兩個或多個，第二個dex文件叫classes2.dex，在Application實例化後會從apk中解壓出classes2.dex並將其拷貝到應用的目錄下，通過反射將其注入到當前的ClassLoader中。但是這個方案非但不能解決一切問題也不能直接拿來用，而要加入自己的一些改造，來解決NoClassDefFoundError、INSTALL_FAILED_DEXOPT等問題，以保證自己的dex被順利的載入流暢的執行。
2. Plugin
Multidex雖然可以解決方法數的限制，但隨著業務邏輯越來越多，apk的大小也變得越來越多，而且有一些功能並非全部用戶都想用的，所以會把一些功能模塊獨立出來做成插件，讓用戶可以按需下載更新，這樣既減小了包大小，又改善了用戶體驗。
插件類似於windows的dll文件，放在某個特定目錄，應用程序主框架會用LoadLibrary載入各dll文件，按插件介面去訪問插件。Android的插件技術也是這樣，利用一個進程可以運行多個apk的機制，用ClassLoader將宿主apk之外的類載入進來，插件的context可以通過createPackageContext方法創建。因為插件中的activity，service等組件如果沒有在AndroidManifest.xml中聲明將不能運行，所以需要預先在AndroidManifest.xml中聲明一個代理類（ProxyActivity），將這個ProxyActivity傳給插件，讓插件的activity也有訪問資源的能力。
3. Hot Patch
有時一些嚴重的crash bug或漏洞需要緊急修復，但有些用戶不會或不願意立即升級，而且頻繁升級，沒有特別的功能更新只是修復bug的升級，對活躍用戶是一種傷害。熱補丁就可以解決這樣的窘境，它是一種可以線上修復的技術方案，有動態改變方法的能力，一般大型的移動應用都會使用熱補丁來處理緊急事件。
Hot Patch可以通過hook來修改java的method，注入自己的代碼，實現非侵入式的runtime修改，或者採用正向編程，通過工具生成patch文件，通過jni bridge指向補丁文件中的方法。還有就是利用ClassLoader，在dex中查找class時，如果找到類則返回，找不到就從下一個dex文件中繼續查找，由此可以想到，在把問題修復後，可以單獨生成一個dex，通過反射插入到dexElements數組的最前面，這樣就能讓dalvik載入補丁里的類了。
4. Push通道
Push是移動App常用的一種無線技術，基礎是基於TCP的心跳機制，和客戶端維持一個長連接。用處是向客戶端推送消息，或者代替客戶端定時去從伺服器pull的策略，改為客戶端接收到push消息後再去pull。
如果每個應用都自己實現push通道的話，cpu就會不定時地經常被喚醒，耗電量達到難以容忍的程度，而且自己搭建push平台的成本也很大，實時性和效率也存在問題，一般都直接使用一些服務商提供的push方案，這些push平台一般都經過了優化設計，在跨平台和網路穿透性、長連接心跳包、多客戶端App鏈路復用、服務和連接保活等技術上做了優化。比如Agoo最初是淘寶無線事業部開發的push服務，在逐漸完善和支撐淘系其他app後，通過服務端容量、通訊協議優化、業務和開放能力的拓展改進後，與友盟等合作，開始向第三方提供推送服務。
5. 應用加固
一款熱門的移動app或游戲發布後會受到很多的關注，經常會遇到二次打包的盜版行為，破解者要麼修改游戲的資源文件、道具、分值甚至直接把訪問的站點指向自己架設的伺服器，損害了開發者的利益；要麼偷偷植入自己的惡意代碼，表面上看起來跟正版的app完全一樣，在後台卻盜取用戶隱私，植入木馬；要麼通過反向工程學習原app的核心技術，打破技術上的競爭壁壘。
為了防止被破解只通過混淆是遠遠不夠的，即使是在native層混淆也還是會被人熟練的反編譯，所以需要一套對apk的保護方案來反調試、防逆向和防篡改。一般的加固方法都是對原apk先進行加密，然後和殼合並生成新的apk。殼是用來解密apk的dex文件。當應用啟動時，殼先解密原apk，准備好自己定義的ClassLoader，然後獲取源程序中的Application名稱，通過反射找到正確的Application對象，運行它的onCreate方法，這樣原apk才能被真正運行。其他一些反調試的方法有針對反編譯工具，在源程序中加入一些無效的指令或無效的指針，引發反編譯工具的崩潰，還有就是加花指令，利用一些跳轉，堆棧操作等指令，讓破解者無法清楚地理解反匯編後的內容。
6. 其他
除了上述幾點外，在服務端還會涉及灰度策略、鏈路流量優化、動態更新配置、防DNS劫持等技術，在客戶端會涉及用戶埋點上報、在線監控、進程保活、H5和native混合開發、注入框架等。
③ 有誰使用過阿里巴巴的AndFix框架，android熱修復
AndFix是一個Android App的在線熱補丁框架。使用此框架，咱們能夠在不重復發版的情況下，在線修改App中的Bug。AndFix就是 「Android Hot-Fix」的縮寫。
就目前來說，AndFix支持Android 2.3到6.0版本，並且支持arm 與 X86系統架構的設備。完美支持Dalvik與ART的Runtime。
AndFix 的補丁文件是以 .apatch 結尾的文件。
AndFix是阿里巴巴開源項目。
AndFix
在Android Studio使用
在Eclipse使用
代碼混淆ProGuard
AndFix介紹
Android上如何使用
patch文件的生成
Android上如何使用
1.在自定義Application中初始化，為了更早的修復應用中的bug。
package com.euler.andfix;
import android.app.Application;
import com.alipay.euler.andfix.patch.PatchManager;
/**
* MainApplication 2015-11-12 下午2:07:11
*
* @author 喬曉松 [email protected]
*/
public class MainApplication extends Application {
public PatchManager mPatchManager;
@Override
public void onCreate() {
super.onCreate();
// 初始化patch管理類
mPatchManager = new PatchManager(this);
// 初始化patch版本
mPatchManager.init("1.0");
// 載入已經添加到PatchManager中的patch
mPatchManager.loadPatch();
}
}
2.如果有新的補丁需要修復，下載完成後，進行以下操作
//添加patch，只需指定patch的路徑即可，補丁會立即生效
mPatchManager.addPatch(path);12
3.當apk版本升級，需要把之前patch文件的刪除，需要以下操作
//刪除所有已載入的patch文件
mPatchManager.removeAllPatch();12
patch文件的生成
使用工具：apkpatch-1.0.3
原理：根據兩個apk包，生成一個差異文件，就是所謂的補丁文件即patch文件。
命令 : apkpatch.bat -f new.apk -t old.apk -o output1 -k debug.keystore -p android -a androiddebugkey -e android
-f <new.apk> ：新版本
-t <old.apk> : 舊版本
-o <output> ： 輸出目錄
-k <keystore>： 打包所用的keystore
-p <password>： keystore的密碼
-a <alias>： keystore 用戶別名
-e <alias password>： keystore 用戶別名密碼123456789
執行完命令，就會在輸出目錄中輸出.apatch文件:
new-.apatch：就是patch文件。
.apatch文件根目錄內容：
META_INF文件下內容：
PATCH.MF文件內容：註：Patch-Classes就是改動過的class.
客戶端請求伺服器介面(api)，伺服器根據用戶傳遞的數據分析是否有需要修復的bug。
如果有bug需要修復，就下載伺服器指定的.apatch文件的鏈接，下載完後及時載入並修復，使用addpatch(path)方法，補丁會立即生效。
④ Android開發Tinker熱更新的問題
通過閱讀官方的技術文檔，始終沒有發現有對這個情況的相關配置項，所以只能從別處下手，最後發現，通過在 app mole 的 「build.gradle」 文件中，注釋掉依賴插件腳本，最終解決掉這個問題：
說兩句：
目前運行調試一切正常，不過要始終留意後續是否會出現問題；重要的一點是，當要打包新版本時，一定要解開這個注釋。
2、can』t the get signConfig for this build
問題：
執行 buildTinkerPatchRelease 打 Release 版本補丁包時報以下錯誤：
Error:Execution failed for task ':app:tinkerPatchRelease'.
> can't the get signConfig for this build
1
2
解決：
android {
...
// 簽名配置【buildTypes中調用了signingConfigs，則signingConfigs{}要置於buildTypes{}前面】
signingConfigs {
release {
try {
storeFile file("MyProject.jks")
storePassword "111111"
keyAlias "zhangzeqiao"
keyPassword "111111"
} catch (ex) {
throw new InvalidUserDataException(ex.toString())
}
}
}
buildTypes {
release {
...
signingConfig signingConfigs.release
}
debug {
...
signingConfig signingConfigs.release
}
}
...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
其中要特別注意，signingConfigs{} 方法體要置於 buildTypes{} 方法體前面，不然會報以下錯誤：
⑤ google android有沒有熱補丁修復app
目前沒有,網上的方法其實本質也是更新
⑥ android熱更新框架哪個好
一.基礎知識
1.阿里的熱更新框架已經開源 了。但已經很久沒有更新過新版本了。當前的版本只支持到了 Android 4.4。由於 5.0 起新的 ART 虛擬機、更嚴格的 SELinux 策略以及對 64 位的支持之類的事，使得 Xposed 都在開發上做了很多調整。我不知道 Dexposed 現在是否支持，但至少阿里沒有開源。
2.在本地動態執行遠端下發的代碼是極度危險的行為。利用此方法執行非法代碼等或用於繞過 Google Play 等市場的審查是違反相關協議的，也是對用戶極度不負責任的行為。
3.在一些訪問非常密集的地方使用熱更新可能會對效率產生相對比較大的影響，應該避免使用.
4.我們可以對 Java 的 ScriptEngine 進行一些封裝成為一個 HotPatch 類使得它更適合做熱更新的工作。
5.首先,檢查熱更新補丁的管道一定要建立在 https 上，因為下發代碼是極其危險的，如果被劫持，後果是無法想像的。其次,請求時最好自動帶上 Android 版本、手機型號、地區、版本號等信息，以方便更精確地下發，千萬不能下發錯。
6.Java在運行時載入對應的類是通過ClassLoader來實現的，ClassLoader本身是一個抽象來，Android中使用PathClassLoader類作為Android的默認的類載入器
7.我們的如果想做hotpatch，一定要保證我們的hotpacth dex文件出現在dexElements列表的前面。
二.常用的熱更新技術框架:
基於QQ空間的HotFix →→ 要使用到android dex分包方案→拆分dex的項目的話，可以參考一下谷歌的multidex方案實現.
大眾點評的NuWa←項目補丁自動化做的很完整
alibaba/AndFix
阿里巴巴的DexPosed
dalvik_patch實現multidex
使用React-Native實現app熱部署的一次實踐
alibaba/AndFix
三、常用的熱更新技術框架比較
Advantage
disadavantage
NuWa
1，可以新增類和欄位，
2，兼容到6.0系統
1，基本原理是classloader,類載入器
2，不能修改資源文件，如圖片布局等（可通過動態布局實現）
AndFix
1， 支持Android2.3到6.0版本
2， 支持arm與x86系統架構
3， 支持dalvik和ART的runtime
4， 不需要重啟App即可應用補丁
1，不能新增類和欄位，
2，不能修改資源文件,
3，不能修改manifest文件
4，不能新增成員變數
5，不能使用加固後的apk製作pacth文件
四、github地址
網路的同學的實現 HotFix
點評的同學的實現 Nuwa
阿里的同學的實現 AndFix
另：AndFix對static的支持不太好，下面是試驗的Demo:
添加了一個靜態的欄位addString：
通過AndFix來製作patch會直接報錯：
⑦ Android Studio創建項目後，修改代碼後，需要保存嗎
不需要，androidstudio編寫代碼，都是自動保存的，不需要手動保存。不過建議把代碼放到伺服器保存一份，比如GitHub，這樣一個可以算是備份，二來你在其他地方也可以拉代碼編寫
⑧ Android插件化和熱修復的區別和聯系
針對Android平台，Dexposed支持函數級別的在線熱更新，例如對已經發布在應用市場上的宿主APK，當我們從crash統計平台上發現某個函數調用有bug，導致經常性crash，這時，可以在本地開發一個補丁APK，並發布到伺服器中，宿主APK下載這個補丁APK並集成後，就可以很容易修復這個crash。
Dexposed是基於久負盛名的開源Xposed框架實現的一個Android平台上功能強大的無侵入式運行時AOP框架。
Dexposed的AOP實現是完全非侵入式的，沒有使用任何註解處理器，編織器或者位元組碼重寫器。集成Dexposed框架很簡單，只需要在應用初始化階段載入一個很小的JNI庫就可以，這個載入操作已經封裝在DexposedBridge函數庫裡面的canDexposed函數中，源碼如下所示：
/**
* Check device if can run dexposed, and load libs auto.
*/
public synchronized static boolean canDexposed(Context context) {
if (!DeviceCheck.isDeviceSupport(context)) {
return false;
}
//load xposed lib for hook.
return loadDexposedLib(context);
}
private static boolean loadDexposedLib(Context context) {
// load xposed lib for hook.
try {
if (android.os.Build.VERSION.SDK_INT > 19){
System.loadLibrary("dexposed_l");
} else if (android.os.Build.VERSION.SDK_INT == 10
|| android.os.Build.VERSION.SDK_INT == 9 ||
android.os.Build.VERSION.SDK_INT > 14){
System.loadLibrary("dexposed");
}
return true;
} catch (Throwable e) {
return false;
}
}
Dexposed實現的hooking，不僅可以hook應用中的自定義函數，也可以hook應用中調用的Android框架的函數。Android開發者將從這一點得到很多好處，因為我們嚴重依賴於Android SDK的版本碎片化。
⑨ andfix原理
AndFix，全稱是Android hot-fix，是一個Android熱補丁框架。
原理是：apkpatch將兩個apk做一次對比，然後找出不同的部分。可以看到生成的apatch了文件，後綴改成zip再解壓開，裡面有一個dex文件。通過jadx查看一下源碼，裡面就是被修復的代碼所在的類文件,這些更改過的類都加上了一個_CF的後綴，並且變動的方法都被加上了一個叫@MethodReplace的annotation，通過clazz和method指定了需要替換的方法。然後客戶端sdk得到補丁文件後就會根據annotation來尋找需要替換的方法。最後由JNI層完成方法的替換。
如果本地保存了多個補丁，那麼AndFix會按照補丁生成的時間順序載入補丁。具體是根據.apatch文件中的PATCH.MF的欄位Created-Time。
局限性：不支持YunOS
無法添加新類和新的欄位
需要使用加固前的apk製作補丁，但是補丁文件很容易被反編譯，也就是修改過的類源碼容易泄露。
使用加固平台可能會使熱補丁功能失效。
andfix與Nuwa對比，
Nuwa是另一個熱補丁框架。
⑩ 微信開源的 android 熱補丁框架 tinker 什麼來頭
他是參考國外的框架而來，如下內容：
Tinker v1.0－性能極致追求之路
為了穩定性與兼容性，微信選擇了Java流派。當前最大難點在於如何突破Qzone方案的性能問題，這時通過研究Instant Run的冷插拔與buck的exopackage給了我們靈感。它們的思想都是全量替換新的Dex。
簡單來說，我們通過完全使用了新的Dex，那樣既不出現Art地址錯亂的問題，在Dalvik也無須插樁。當然考慮到補丁包的體積，我們不能直接將新的Dex放在裡面。但我們可以將新舊兩個Dex的差異放到補丁包中，這里我們可以調研的方法有以下幾個：
BsDiff；它格式無關，但對Dex效果不是特別好，而且非常不穩定。當前微信對於so與部分資源，依然使用bsdiff演算法；
DexMerge；它主要問題在於合成時內存佔用過大，一個12M的dex，峰值內存可能達到70多M；
DexDiff；通過深入Dex格式，實現一套diff差異小，內存佔用少以及支持增刪改的演算法。