紙上得來終覺淺,絕知此事要躬行
背景
我們在日常使用應用可能會遇到以下場景。
場景1:
用戶瀏覽h5頁面時看到一個頁面,下載安裝app后啟動會來到首頁而不是用戶之前瀏覽的頁面,造成使用場景的割裂。
場景2:
用戶通過二維碼把一個頁面分享出去,沒有裝貓客的用戶如果直接安裝啟動之后無法回到分享的頁面。
如果用戶在當前頁面下載了應用,安裝之后直接跳轉到剛才瀏覽的界面,不僅可以將這一部分流量引回客戶端,還可以讓用戶獲得完整的用戶體驗。下面提出一種方案來滿足這個業務需求。
原理
android使用的apk包的壓縮方式是zip,與zip有相同的文件結構,在zip的Central directory file header中包含一個File comment區域,可以存放一些數據。File comment是zip文件如果可以正確的修改這個部分,就可以在不破壞壓縮包、不用重新打包的的前提下快速的給apk文件寫入自己想要的數據。
comment是在Central directory file header末尾儲存的,可以將數據直接寫在這里,下表是header末尾的結構。
由于數據是不確定的,我們無法知道comment的長度,從表中可以看到zip定義comment的長度的位置在comment之前,所以無法從zip中直接獲取comment的長度。這里我們需要自定義comment的長度,在自定義comment內容的后面添加一個區域儲存comment的長度,結構如下圖。
這里可以將一個固定的結構寫在comment中,然后根據自定義的長度分區獲取每個部分的內容,還可以添加其它數據,如校驗碼、版本等。
實現
1.將數據寫入comment
這一部分可以在本地進行,需要定義一個長度為2的byte[]來儲存comment的長度,直接使用Java的api就可以把comment和comment的長度寫到apk的末尾,代碼如下。
public static void writeApk(File file, String comment) {
ZipFile zipFile = null;
ByteArrayOutputStream outputStream = null;
RandomAccessFile accessFile = null;
try {
zipFile = new ZipFile(file);
String zipComment = zipFile.getComment();
if (zipComment != null) {
return;
}
byte[] byteComment = comment.getBytes();
outputStream = new ByteArrayOutputStream();
outputStream.write(byteComment);
outputStream.write(short2Stream((short) byteComment.length));
byte[] data = outputStream.toByteArray();
accessFile = new RandomAccessFile(file, "rw");
accessFile.seek(file.length() - 2);
accessFile.write(short2Stream((short) data.length));
accessFile.write(data);
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if (zipFile != null) {
zipFile.close();
}
if (outputStream != null) {
outputStream.close();
}
if (accessFile != null) {
accessFile.close();
}
} catch (Exception e) {
}
}
}
2.讀取apk包中的comment數據
首先獲取apk的路徑,通過context中的getPackageCodePath()方法就可以獲取,代碼如下。
public static String getPackagePath(Context context) {
if (context != null) {
return context.getPackageCodePath();
}
return null;
}
獲取路徑之后就可以讀取comment的內容了,這里不能直接使用ZipFile中的getComment()方法直接獲取comment,因為這個方法是Java7中的方法,在android4.4之前是不支持Java7的,所以我們需要自己去讀取apk文件中的comment。首先根據之前自定義的結構,先讀取寫在最后的comment的長度,根據這個長度,才可以獲取真正comment的內容,代碼如下。
public static String readApk(File file) {
byte[] bytes = null;
try {
RandomAccessFile accessFile = new RandomAccessFile(file, "r");
long index = accessFile.length();
bytes = new byte[2];
index = index - bytes.length;
accessFile.seek(index);
accessFile.readFully(bytes);
int contentLength = stream2Short(bytes, 0);
bytes = new byte[contentLength];
index = index - bytes.length;
accessFile.seek(index);
accessFile.readFully(bytes);
return new String(bytes, "utf-8");
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
這里的stream2Short()和short2Stream()參考了MultiChannelPackageTool中的方法。
測試
在生成apk后,調用下面的代碼寫入我們想要的數據,
File file = new File("/Users/zhaolin/app-debug.apk");
writeApk(file, "test comment");
安裝這個apk之后運行,讓comment顯示在屏幕上,運行結果如下。
運行結果符合預期,安裝包也沒有被破壞,可以正常安裝。
結論
- 通過修改comment將數據傳遞給APP的方案是可行的,由于是修改apk自有的數據,并不會對apk造成破壞,修改后可以正常安裝。
- 這種方案不用重新打包apk,并且在服務端只是寫文件的操作,效率很高,可以適用于動態生成apk的場景。
- 可以通過這個方案進行h5到APP的引流,用戶操作不會產生割裂感,保證用戶體驗的統一。