整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
uto.js是這樣一個開源項目：
它讓你不需要 ROOT 權限，就可以實現類似按鍵精靈的自動操作，可以實現自動點擊、滑動、輸入文字、打開應用等。Auto.js 的大部分用戶用它來點贊、簽到、刷游戲
想想吧，基于Auto.js可以開發很多自動簽到等等插件
特性
本軟件與按鍵精靈等軟件不同，主要區別是：
開源地址：https://github.com/hyb1996/Auto.js
ebpack 是一種用于 JavaScript 和 TypeScript 項目的模塊打包工具。它可以將多個文件和依賴項轉換為單個或多個輸出文件，以提高應用程序的性能和可維護性。
Webpack 的特點
Webpack 的應用
Webpack 用于各種項目，包括：
Webpack 的優勢
Webpack 的未來
Webpack 繼續在 JavaScript 開發中保持其流行度。隨著其功能豐富、易于使用和廣泛的社區支持，我們預計 Webpack 將繼續成為 JavaScript 項目中的主力打包工具。
結論
Webpack 是一種強大的 JavaScript 打包工具，為開發人員提供了出色的功能，以打包和管理 JavaScript 項目。其模塊化、代碼分割和緩存功能使它成為各種項目中流行的選項。
本文作者：羋峮，豌豆莢資深工程師，負責豌豆莢測試工具平臺體系建設。《iOS測試指南》作者，對于移動平臺測試有獨到見解。
責任編輯：唐小引（tangxy@csdn.net）
本文為《程序員》原創文章，未經允許不得轉載，更多精彩文章請訂閱2016年《程序員》
Android市場的渠道分散已不是什么新鮮事，但如何高效打包仍是令許多開發者頭疼的問題。本篇文章著重介紹了目前最新的三種打包方案，并且從安全方面對這三種方案進行點評，相信會給開發者帶來新的助力。
一般需求的打包，一條行命令就出來了。復雜一些的話，也就是一個簡單的開源工具，或是一段小配置代碼就搞定了。既然如此，為什么我還要來寫Android打包相關內容？主要有以下兩個方面的原因：
所以，當Android開發團隊有一定規模時，需要一種優雅并且高效安全的打包方式來銜接從代碼到應用程序包的這個過程。
大概在3-4年前，國內的移動開發者都會使用友盟來做Crash收集和一些用戶的行為數據收集。所以，友盟定義渠道的方式基本定義了數據收集工具的渠道定義方式。友盟默認的渠道直接從AndroidManifest文件中的meta－data里面讀取。如以下代碼所示：
'' <meta-data ''="" android:name="UMENG_APPKEY" android:value="4ee5c714ee5c714ee5c71">
'' </meta-data>
'' <meta-data ''="" android:name="UMENG_CHANNEL" android:value="wandoujia">
'' </meta-data>在示例中，UMENG_APPKEY是賬戶的唯一標示，UMENG_CHANNEL的內容為wandoujia，即表示這時渠道是wandoujia。這里再多說一句渠道的概念，一般的渠道可能會表示具體是哪個應用市場。比如上傳豌豆莢和上傳360手機助手的渠道標示不一樣，當然，如果有一些線下推廣的話，也需要區分渠道。隨著數據統計越來越細，渠道也會更加的層出不窮。現在一個日活在百萬的應用，Android的渠道在幾千個是非常正常的現象。
在AndroidManifest定義渠道的年代，多渠道打包無非以下兩種方案：
現在看來，這兩種方式效率都不高。方案一基本上毫無效率可言，只能支持20個以內的渠道規模。方案二效率高一些，如果再引入多線程驅動來進行打包，支持200以內的渠道打包毫無壓力。但是隨著Android的版本升級，代碼混淆和加固工具的引入，這種方案已經不能正常運行了。所以，需要一種兼容性好并且高效的多渠道打包方式。
Android項目本身是開源的，大家都可以去研究任何實現，基于這個特性，一種叫做“Android黑科技”的學科迅速誕生。以下介紹的多渠道打包方式都應該屬于其范疇。
添加comments多渠道打包
首先解釋什么是comments（注釋或評論）的打包方式？
Android應用使用的APK文件就是一個帶簽名信息的zip文件，根據zip文件格式規范（請參見：https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT），每個文件的最后都必須有一個叫Central Directory Record（https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html）的部分，這個CDR的最后部分叫“End of Central Directory Record”，這一部分包含一些元數據，它的末尾是zip文件的注釋。注釋包含Comment Length和File Comment兩個字段。前者表示注釋的長度，后者是注釋的內容，正確修改這一部分不會對zip文件造成破壞，利用這個字段，我們可以添加一些自定義數據。
簡單來說就是：我們利用的是zip文件“可以添加comment（摘要）”的數據結構特點，在文件的末尾寫入任意數據，而不用重新解壓zip文件（apk文件就是zip文件格式）；所以該工具不需要對APK文件解壓縮和重新簽名即可完成多渠道自動打包，可謂是高效、速度快，無兼容問題。
這種高效的方式是奇虎360的一位工程師公布的，他已經把相關工具的代碼開放在GitHub上面了，地址為https://github.com/seven456/MultiChannelPackageTool。工具本身為命令行形式，一條命令即可生成一個多渠道包，并且非常高效。作者本人公布的性能數據是：5M的APK，1秒種能打300個。
就是因為速度非常快，現在一些廠商用這種方案來做安裝包的動態生成。在用戶下載之前渠道是沒有添加進去的，用戶選擇下載以后通過渠道來源判斷渠道標示，并且寫入。過程瞬間完成，用戶下載時毫無感知。
當然，利用工具把渠道寫入應用程序包內，還應該提供一種在APK內部讀取渠道的方式。讀取時方法也非常簡單，首先通過反射方法找到APK在手機中的位置，然后通過讀zip comment的方式獲取渠道內容。讀取comment和找APK位置的代碼都能在這個急速添加渠道的工具中找到，在這里不再詳細介紹。需要注意的是，在Android中使用Java反射的性能非常差，需要做一些優化處理。
如果你覺得這種方式的安全比較差，也可以自己重新實現一個小工具，并且對comment的內容加密。當然，加密使用的密鑰需要在APK代碼中體現，這種加密方案也只是提高了一點破譯的門檻而已。
美團的Android多渠道打包
美團點評技術團隊（原美團技術團隊）有一個公開的博客，每篇文章都在領域內有一定的影響。其中有一篇就是討論“如何高效地進行Android多渠道打包？”，可參見：http://tech.meituan.com/mt-apk-packaging.html。
文章中首先提到了ApkTool的多渠道打包方式，然后講到美團的業務發展已經有900多個渠道，ApkTool的方式已經不能支持這種規模的多渠道打包。所以，美團點評技術團隊開始探索一種更加高效的多渠道打包方式。
美團的做法是把一個Android應用包當作zip文件包進行解壓，然后發現在簽名生成的目錄下添加一個空文件不需要重新簽名。利用這個機制，該文件的文件名就是渠道名。這種方式不需要重新簽名等步驟，非常高效。
下面我們來詳細講解一下這個過程。首先把一個已經簽名好的Android應用程序包解壓縮，簽名文件的目錄為：META-INF，如圖1所示。
圖1 美團Android多渠道打包壓縮文件目錄
圖中有兩個框選的部分，分別為：assets目錄和META－INF目錄。assets等下文介紹豌豆莢高效打包方式的時候再說。我們這里先來看看META－INF目錄。在META－INF目錄下的三個文件，就是一個Android應用程序包被正確簽名之后的生成文件，當這個程序包中的文件被修改以后，驗證信息就需要重新生成，否則驗證的簽名信息就不正確。這套簽名機制也是從Java的jar包方式繼承過來的。
美團多渠道打包方式，正是利用簽名的驗證方式，巧妙地放入了一個空文件，利用文件名來表示渠道方式的完成。如果放入了一個非空的文件，這時簽名驗證的機制就會被破壞。美團的具體做法是通過一段簡單的Python腳本來完成。代碼如下：
'' import zipfile
'' zipped=zipfile.ZipFile(your_apk, 'a', zipfile.ZIP_DEFLATED)
'' empty_channel_file="META-INF/mtchannel_{channel}".format(channel=your_channel)
'' zipped.write(your_empty_file, empty_channel_file)通過運行Python腳本，Android應用程序包中便會多出一個文件，如圖2所示。
圖2 通過運行Python腳本，Android應用程序包中多出來的一個文件
渠道添加成功后，可以參照美團點評技術團隊的博客，在Android程序中添加讀取渠道的代碼，即可擁有高效的多渠道打包方式。
當然，這個技術實現本身可以有更加優雅和高效的方式——添加渠道。原理不變，添加方式可以進行改變。添加文件可以使用AAPT這個工具。AAPT本身是Android平臺自帶的一個命令行工具，可以實現從Android程序包中刪除和添加任意文件。當然，如果添加文件破壞了簽名驗證信息，則是另外一回事了。關于AAPT的使用和其在多渠道簽名打包時的用法，會在下文進行講解。
如果現在想把美團的渠道刪除，使用AAPT輸入一條簡單的命令行即可（能刪除就能添加，添加部分還是在豌豆莢多渠道打包方案中介紹吧）：
'' aapt remove meituan.apk META-INF/mtchannel_meituan豌豆莢Android多渠道打包
豌豆莢的多渠道打包方案和美團的所用的方式一樣，都是添加一個文件，文件本身會帶入渠道消息。但不同點在于它添加的是一個不為空的文件。之前已經提到過了，如果添加一個非空文件，就會破壞簽名校驗，需要重新簽名。
從這個方案可以看出，豌豆莢多渠道打包和美團多渠道打包正好是利用了一個特性的兩個方面。當然，如果需要重新簽名，效率會差一些。在失去效率的同時，擁有了更加安全的渠道管理。下面具體講解，豌豆莢多渠道打包管理方案。
首先，如果把渠道文件還放在META－INF目錄下的話，重新簽名時渠道文件會被刪掉。所以，渠道文件需要重新找一個合理的地方存放。之前的文章也提到過，還有一個assets目錄。assets目錄和META－INF目錄一樣，可以隨便放入小文件。如果是空文件不需要重新簽名
加入渠道時主要有以下步驟。
'' aapt add wandoujia.apk asserts/channel.txt圖3 豌豆莢打包方案處理一個包需要大約4秒
說完了豌豆莢多渠道打包的實現部分以后，需要來談一下效率。之前的兩種多渠道打包方案效率都很高，處理一個包都能在1秒之內完成。但豌豆莢的多渠道打包方案由于必須重新簽名，會慢一些（但也沒有慢多少）。在屏蔽了一些關鍵信息之后，從圖3中可以看到，一次處理大概需要4秒的時間。現在一臺一般配置的計算機，開8個線程處理，速度完全可以接受。
三種打包方案都是高效的實現，當然也有各自的側重點。以下，從安全的角度來分析。
對于Android應用包的安全問題來說，主要需要考慮渠道被惡意篡改的可能性和成本。如果一個渠道商，通過網絡劫持和篡改渠道的組合方式來獲取暴利，對于程序開發者來說可能會存在著巨大的經濟損失。
在介紹篡改渠道之前，還是先簡單介紹AAPT這個工具的一般使用方法。AAPT是在AndroidSDK內的一個命令行工具，具體位置在AndroidSDK目錄下的build-tools/19.0.0或者其他版本下，AAPT并不存在于每個發行版本中，所以一般使用的AAPT是19.0.0或19.0.1版本。
使用AAPT主要有以下4種場景：
'' INPUT apt dump badging weixin.apk
'' OUTPUT package: name='com.tencent.mm' versionCode='740' versionName='6.3.13.49_r4080b63'
'' uses-permission:'com.tencent.mm.plugin.permission.READ'
'' uses-permission:'com.tencent.mm.plugin.permission.WRITE'
'' uses-permission:'com.tencent.mm.permission.MM_MESSAGE'
'' uses-permission:'com.huawei.authentication.HW_ACCESS_AUTH_SERVICE'
'' sdkVersion:'15'
'' targetSdkVersion:'23'
'' uses-feature-not-required:'android.hardware.camera'
'' uses-feature-not-required:'android.hardware.camera.autofocus'
'' uses-feature-not-required:'android.hardware.bluetooth'
'' uses-feature-not-required:'android.hardware.location'
'' uses-feature-not-required:'android.hardware.location.gps'
'' uses-feature-not-required:'android.hardware.location.network'
'' uses-feature-not-required:'android.hardware.microphone'
'' uses-feature-not-required:'android.hardware.telephony'
'' uses-feature-not-required:'android.hardware.touchscreen'
'' uses-feature-not-required:'android.hardware.wifi'
'' uses-permission:'android.permission.ACCESS_NETWORK_STATE'
'' uses-permission:'android.permission.ACCESS_COARSE_LOCATION'
'' uses-permission:'android.permission.ACCESS_FINE_LOCATION'
'' uses-permission:'android.permission.CAMERA'
'' .....從以上代碼可以看到這個微信的版本信息，并且知道了微信的包名是：com.tencent.mm，還能看到微信這個應用使用到了哪些權限等信息（更多的信息還是交給讀者自己仔細研究吧）。
使用AAPT查看Android開發包的目錄結構如下：
'' INPUT aapt list weixin.apk
'' OUTPUT META-INF/MANIFEST.MF
'' META-INF/COM_TENC.SF
'' META-INF/COM_TENC.RSA
'' assets/jsapi/wxjs.js
'' assets/avatar/default_nor_avatar.png
'' assets/avatar/default_meishiapp.png
'' assets/avatar/default_hd_avatar.png
'' assets/ipcall_country_code.txt
'' assets/merged_features.xml
'' assets/address
'' .....又看到了META－INF目錄和assets目錄。一般在Android的應用中assets都會放一些靜態的資源。
'' INPUT aapt add wandoujia.apk assets/channel.txt'' INPUT aapt remove wandoujia.apk assets/channel.txt在掌握了以上簡單的四個命令行后，修改美團的渠道就已經非常簡單了。先通過list命令找到渠道文件，然后直接刪除文件，最后再加入自己的惡意渠道。但豌豆莢的渠道也可以通過相同的方式來進行篡改，但篡改之后需要重新簽名。在沒有官方的簽名文件時，是沒有辦法完全偽造一個相同的簽名的。
添加comments多渠道打包方式中雖然渠道信息不是明文顯示，但也存在著被篡改的可能性。如果自己進行一些簡單的加密可以杜絕大多數的惡意篡改，但由于不需要重新簽名，這種方法還是存在著被篡改的機率的。
具體選擇哪一種多渠道打包方式，還是由業務決定的。豌豆莢作為一個應用商店，需要有自己的渠道，渠道的安全性會很不好。如果是一個普通的App，一般都是在一些應用商店上發布新版本，應用商店本身會給開發者提供相對安全的環境。所以這也就是美團方案依然能夠使用的關鍵。
本文重點介紹了3種高效的多渠道打包方式。這三種方式都不會產生二次編譯，二次編譯會對一個版本的程序產生多個版本的符號表，在后期的問題追查中會有很多障礙。利用結束語簡單說說符號表的重要性吧。
當程序正確打包發布以后，可以通過各種免費、收費或自己開發的工具來收集Crash等堆棧信息，查看錯誤并進行改正。你可能會得到一段這樣的異常堆棧：
'' ava.lang.RuntimeException: There is no view set with ViewPackage found in the log tree.
'' at o.λ.?(:64)
'' at o.λ.ˊ(:25)
'' at o.к$ˋ.run(:233)
'' at android.os.Handler.handleCallback(Handler.java:733)
'' at android.os.Handler.dispatchMessage(Handler.java:95)
'' at android.os.Looper.loop(Looper.java:136)
'' at android.os.HandlerThread.run(HandlerThread.java:61)然后如果沒有一個符號表幫忙，你會陷入深深的沉思：這到底是什么問題？我的代碼在哪里？如果有了正確的符號表，一條命令行就可以就可以把相關的異常堆棧信息翻譯正確。符號表和編譯過程有著緊密的耦合，所以在選擇打包工具時，都應該選擇不產生二次編譯的工具。在以上提到的三款工具中，添加多渠道都是基于已有APK進行添加的，并不是基于源碼來添加渠道。所以都完全滿足條件。
考慮到文章的篇幅，有一些內容沒有展開說，開發者如果遇到這方面的問題，歡迎與我交流。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
