android分包原理

⑴ 求問大神現在做android的hotfix用哪個框架比較好

一.基礎知識1.阿里的熱更新框架已經開源了。但已經很久沒有更新過新版本了。當前的版本只支持到了Android4.4。由於5.0起新的ART虛擬機、更嚴格的SELinux策略以及對64位的支持之類的事，使得Xposed都在開發上做了很多調整。我不知道Dexposed現在是否支持，但至少阿里沒有開源。2.在本地動態執行遠端下發的代碼是極度危險的行為。利用此方法執行非法代碼等或用於繞過GooglePlay等市場的審查是違反相關協議的，也是對用戶極度不負責任的行為。3.在一些訪問非常密集的地方使用熱更新可能會對效率產生相對比較大的影響，應該避免使用.4.我們可以對Java的ScriptEngine進行一些封裝成為一個HotPatch類使得它更適合做熱更新的工作。5.首先,檢查熱更新補丁的管道一定要建立在https上，因為下發代碼是極其危險的，如果被劫持，後果是無法想像的。其次,請求時最好自動帶上Android版本、手機型號、地區、版本號等信息，以方便更精確地下發，千萬不能下發錯。6.Java在運行時載入對應的類是通過ClassLoader來實現的，ClassLoader本身是一個抽象來，Android中使用PathClassLoader類作為Android的默認的類載入器7.我們的如果想做hotpatch，一定要保證我們的hotpacthdex文件出現在dexElements列表的前面。二.常用的熱更新技術框架:基於 空間的HotFix→→要使用到androiddex分包方案→拆分dex的項目的話，可以參考一下谷歌的multidex方案實現.大眾點評的NuWa←項目補丁自動化做的很完整alibaba/AndFix阿里巴巴的DexPoseddalvik_patch實現multidex使用React-Native實現app熱部署的一次實踐alibaba/AndFix三、常用的熱更新技術框架比較AdvantagedisadavantageNuWa1，可以新增類和欄位，2，兼容到6.0系統1，基本原理是classloader,類載入器2，不能修改資源文件，如圖片布局等（可通過動態布局實現）AndFix1，支持Android2.3到6.0版本2，支持arm與x86系統架構3，支持dalvik和ART的runtime4，不需要重啟App即可應用補丁1，不能新增類和欄位，2，不能修改資源文件,3，不能修改manifest文件4，不能新增成員變數5，不能使用加固後的apk製作pacth文件四、github地址網路的同學的實現HotFix點評的同學的實現Nuwa阿里的同學的實現AndFix另：AndFix對static的支持不太好，下面是試驗的Demo:添加了一個靜態的欄位addString：通過AndFix來製作patch會直接報錯：

⑵ android studio怎麼分包

這里只做Android Studio分包配置簡單的介紹。
第一步：
在Gradle build文件中做如下配置：
android {
compileSdkVersion 21
buildToolsVersion "21.1.0"

defaultConfig {
...
minSdkVersion 14
targetSdkVersion 21
...

// Enabling multidex support.
multiDexEnabled true
}
...
}

dependencies {
compile 'com.android.support:multidex:1.0.0'
}

添加兩句代碼：
（1）multiDexEnable true
（2）compile 'com.android.support:multidex:1.0.0'
第二步：
在AndroidManifest.xml文件中做如下配置：
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.android.multidex.myapplication">
<application
...
android:name="android.support.multidex.MultiDexApplication">
...
</application>
</manifest>123456789123456789

如果你要定義自己的Application，或者已經有了自定義Application，那麼不需要在application節點中用android.support.multidex.MultiDexApplication，而是用自己的Application類的全名即可，而且自定義的Application也不需要繼承MultiDexApplicatoin。
第三步：
如果有自定義的Application，那麼在自定義的Application類中，重寫attachBaseContext()，並且在其中調用super.attachBaseContext()，然後調用MultiDex.install(this) ，然後在該方法上加上@Override註解，既然是重寫方法，最好加上這個註解，不過Android Studio會自動加上。
有兩點可以注意：
attachBaseContext()是在ContextWrapper類中的。而MultiDexApplication繼承Application，就是如第二步一樣重寫了attachBaseContext()方法。
不需要另外在libs中添加android-support-multidex.jar，否則會報異常。

⑶ 如何將android源碼生成eclipse可用的jar包

eclipse和Myeclispe的導出功能 都是可以支持在同一個項目內 分包打成jar的 由於程序本身是有依賴關系的 所以分包的jar也是要相互支持才行。至於想復用可以做一些公共的功能包打成jar，反復使用也是可以做到的。

⑷ 【騰訊Bugly干貨分享】Android Patch 方案與持續交付

騰訊Bugly開發者社區分享了一篇文章，探討了Android應用的版本更新問題，尤其是在面對多樣的系統版本和市場審核差異時，Android應用升級速度較慢，影響了迭代效率和用戶體驗。文章提出，借鑒Chrome瀏覽器的patch升級方案，通過在用戶無感知下提供補丁更新，來加速bug處理和版本迭代。

近年來，Android熱補丁框架如AndFix、Dexposed和nuwa等興起，但各有局限。作者團隊經過評估，發現AndFix與現網版本匹配但存在代碼修改限制和維護難度問題，nuwa僅支持Java代碼更新，無法滿足全部需求。因此，他們決定自研patch方案，將應用視為載入器，僅負責啟動和資源定位，新功能或修復通過下發補丁文件實現。

該方案設計巧妙，通過代理Application的創建過程和生命周期管理，支持所有代碼和資源的更新。盡管存在反射Application的復雜性，但通過精心設計，成功解決了載入問題。同時，通過將dex文件分包，解決了類引用變更引發的兼容性問題。然而，Multidex方案在某些特定設備上表現不佳，團隊最終轉向HackClassLoader，解決了多線程載入問題。

文章最後強調，團隊的patch方案旨在提供無縫的開發流程，開發者只需正常打包，patch包生成和應用不會影響正向開發。通過與微信讀書的試行，這種持續交付方式有望加速版本迭代，減少線上問題，並收集用戶反饋，進一步優化產品。

⑸ Android ble （藍牙低功耗） 中的坑和技巧

new ScanFilter.Builder().setServiceUuid(ParcelUuid.fromString("00007777-0000-1000-8000-00805f9b34fb");

此時可以根據manfacturerData來匹配自己設定的外圍設備

在BluetoothGattCallback中的關於此問題有三步回調
1、 public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState)

2、 public void onServicesDiscovered(BluetoothGatt gatt, int status)
mBluetoothGatt.discoverServices()執行後得到的callback，如果狀態為GATT_SUCCESS，則可以獲取ble旁支發起廣播的service和descriptor，把廣播設為enable

3、 public void onDescriptorWrite(BluetoothGatt gatt, BluetoothGattDescriptor descriptor, int status)
只有這一步status == BluetoothGatt.GATT_SUCCESS，才可以真正的傳輸數據，如果在第一步或者第二步就開始傳輸數據，會在某些特定的case下導致未知的bug或者空指針錯誤

所以，在中心設備跟外圍開始連接後，你可以設定一個超時時間，在超時時間過後，依然沒能回調onDescriptorWrite並獲得BluetoothGatt.GATT_SUCCESS，則此次過程失敗，你可以根據實際情況進行重連或者提示錯誤

如果要傳輸大於20位元組的數據怎麼辦？

1、 系統mtu可以支持修改到512位元組，完成大數據量的傳輸。但是由於涉及到中心和旁支都需要修改，會造成很大的局限性和底層修改量，而且會觸發比如某些設備第一次修改不生效，另一個設備一次連接中只能修改一次等bug，非常不可取，十分不建議。

2、分包傳輸，自己設計協議分包傳輸是最可取的方案，需要注意的是在分包後，每一個包之間寫入數據需要設置間隔，比如100ms。

在做好5和6的基礎上，依然會在一些設備上出現，由於系統原因，ble剛開始的發送第一個數據出現丟包，請對此做出特殊處理。

⑹ Android-Ble藍牙開發Demo示例–掃描,連接,發送和接收數據,分包解包(附源碼)

萬物互聯的物聯網時代的已經來臨，ble藍牙開發在其中扮演著舉重若輕的角色。最近剛好閑一點，抽時間梳理下這塊的知識點。

涉及ble藍牙通訊的客戶端(開啟、掃描、連接、發送和接收數據、分包解包)和服務端(初始化廣播數據、開始廣播、配置Services、Server回調操作)整個環節以及一些常見的問題即踩過的一些坑。

比如
1、在Android不同版本或不同手機的適配問題，掃描不到藍牙設備
2、如何避免ble藍牙連接出現133錯誤？
3、單次寫的數據大小有20位元組限制，如何發送長數據

藍牙有傳統(經典)藍牙和低功耗藍牙BLE(Bluetooth Low Energy)之分，兩者的開發的API不一樣，本文主講Ble藍牙開發，傳統藍牙不展開，有需要的可以自行了解。

相對傳統藍牙，BLE低功耗藍牙，主要特點是快速搜索，快速連接，超低功耗保持連接和數據傳輸。

客戶端

服務端

Android4.3(API Level 18)開始引入BLE的核心功能並提供了相應的 API。應用程序通過這些 API 掃描藍牙設備、查詢 services、讀寫設備的 characteristics（屬性特徵）等操作。

BLE藍牙協議是GATT協議, BLE相關類不多, 全都位於android.bluetooth包和android.bluetooth.le包的幾個類:
android.bluetooth.
.BluetoothGattService 包含多個Characteristic(屬性特徵值), 含有唯一的UUID作為標識
.BluetoothGattCharacteristic 包含單個值和多個Descriptor, 含有唯一的UUID作為標識
.BluetoothGattDescriptor 對Characteristic進行描述, 含有唯一的UUID作為標識

.BluetoothGatt 客戶端相關
.BluetoothGattCallback 客戶端連接回調
.BluetoothGattServer 服務端相關
.BluetoothGattServerCallback 服務端連接回調

android.bluetooth.le.
.AdvertiseCallback 服務端的廣播回調
.AdvertiseData 服務端的廣播數據
.AdvertiseSettings 服務端的廣播設置
.BluetoothLeAdvertiser 服務端的廣播

.BluetoothLeScanner 客戶端掃描相關(Android5.0新增)
.ScanCallback 客戶端掃描回調
.ScanFilter 客戶端掃描過濾
.ScanRecord 客戶端掃描結果的廣播數據
.ScanResult 客戶端掃描結果
.ScanSettings 客戶端掃描設置

BLE設備分為兩種設備: 客戶端(也叫主機/中心設備/Central), 服務端(也叫從機/外圍設備/peripheral)
客戶端的核心類是 BluetoothGatt
服務端的核心類是 BluetoothGattServer 和 BluetoothLeAdvertiser
BLE數據的核心類是 BluetoothGattCharacteristic 和 BluetoothGattDescriptor

下面詳細講解下客戶端和服務端的開發步驟流程

安卓手機涉及藍牙許可權問題，藍牙開發需要在AndroidManifest.xml文件中添加許可權聲明：

在搜索設備之前需要詢問打開手機藍牙：

注意: BLE設備地址是動態變化(每隔一段時間都會變化),而經典藍牙設備是出廠就固定不變了！

通過掃描BLE設備，根據設備名稱區分出目標設備targetDevice，下一步實現與目標設備的連接，在連接設備之前要停止搜索藍牙；停止搜索一般需要一定的時間來完成，最好調用停止搜索函數之後加以100ms的延時，保證系統能夠完全停止搜索藍牙設備。停止搜索之後啟動連接過程；

BLE藍牙的連接方法相對簡單只需調用connectGatt方法；

參數說明

與設備建立連接之後與設備通信，整個通信過程都是在BluetoothGattCallback的非同步回調函數中完成；

BluetoothGattCallback中主要回調函數如下：

上述幾個回調函數是BLE開發中不可缺少的；

當調用targetdDevice.connectGatt(context, false, gattCallback)後系統會主動發起與BLE藍牙設備的連接，若成功連接到設備將回調onConnectionStateChange方法，其處理過程如下：

判斷newState == BluetoothGatt.STATE_CONNECTED表明此時已經成功連接到設備；

mBluetoothGatt.discoverServices();

掃描BLE設備服務是安卓系統中關於BLE藍牙開發的重要一步，一般在設備連接成功後調用，掃描到設備服務後回調onServicesDiscovered()函數，函數原型如下：

BLE藍牙開發主要有負責通信的BluetoothGattService完成的。當且稱為通信服務。通信服務通過硬體工程師提供的UUID獲取。獲取方式如下：

具體操作方式如下：

開啟監聽，即建立與設備的通信的首發數據通道，BLE開發中只有當客戶端成功開啟監聽後才能與服務端收發數據。開啟監聽的方式如下：

BLE單次寫的數據量大小是有限制的， 通常是20位元組 ，可以嘗試通過requestMTU增大，但不保證能成功。分包寫是一種解決方案，需要定義分包協議，假設每個包大小20位元組，分兩種包，數據包和非數據包。對於數據包，頭兩個位元組表示包的序號，剩下的都填充數據。對於非數據包，主要是發送一些控制信息。
監聽成功後通過向 writeCharacteristic寫入數據實現與服務端的通信。寫入方式如下：

其中：value一般為Hex格式指令，其內容由設備通信的藍牙通信協議規定；

若寫入指令成功則回調BluetoothGattCallback中的onCharacteristicWrite()方法，說明將數據已經發送給下位機；

若發送的數據符合通信協議，則服務端會向客戶端回復相應的數據。發送的數據通過回調onCharacteristicChanged()方法獲取，其處理方式如下：

通過向服務端發送指令獲取服務端的回復數據，即可完成與設備的通信過程；

當與設備完成通信之後之後一定要斷開與設備的連接。調用以下方法斷開與設備的連接：

源碼上傳在CSDN上了，有需要的可以借鑒。

=====> Android藍牙Ble通訊Demo示例源碼–掃描,連接,發送和接收數據,分包解包

BLE單次寫的數據量大小是有限制的，通常是20位元組，可以嘗試通過requestMTU增大，但不保證能成功。分包寫是一種解決方案，需要定義分包協議，假設每個包大小20位元組，分兩種包，數據包和非數據包。對於數據包，頭兩個位元組表示包的序號，剩下的都填充數據。對於非數據包，主要是發送一些控制信息。
總體流程如下：
1、定義通訊協議，如下(這里只是個舉例，可以根據項目需求擴展)

2、封裝通用發送數據介面(拆包)
該介面根據會發送數據內容按最大位元組數拆分(一般20位元組)放入隊列，拆分完後，依次從隊列里取出發送

3、封裝通用接收數據介面(組包)
該介面根據從接收的數據按協議里的定義解析數據長度判讀是否完整包，不是的話把每條消息累加起來

4、解析完整的數據包，進行業務邏輯處理

5、協議還可以引入加密解密，需要注意的選演算法參數的時候，加密後的長度最好跟原數據長度一致，這樣不會影響拆包組包

一般都是Android版本適配以及不同ROM機型（小米/紅米、華為/榮耀等）（EMUI、MIUI、ColorOS等）的許可權問題

藍牙開發中有很多問題，要靜下心分析問題，肯定可以解決的，一起加油；