美團反編譯

㈠ android 不混淆代碼要怎麼使用Robust

什麼是代碼混淆：
    Android SDK 自帶了混淆工具Proguard。它位於SDK根目錄\tools\proguard下面。如果開啟了混淆，Proguard默認情況下會對所有代碼，包括第三方包都進行混淆，可是有些代碼或者第三方包是不能混淆的，這就需要我們手動編寫混淆規則來保持不能被混淆的部分。

為什麼要混淆：
優化java的位元組碼
減小apk文件的大小，在混淆過程中會刪除未使用過的類和成員
代碼安全，使類、函數、變數名隨機變成無意義的代號形如：a,b,c...之類。防止app被反編譯之後能夠很容易的看懂代碼

㈡ Android | 他山之石，可以攻玉！一篇文章看懂 v1/v2/v3 簽名機制

這篇文章的內容會涉及以下前置 / 相關知識，貼心的我都幫你准備好了，請享用~

數字簽名（Digital Signature）也叫作數字指紋（Digital Fingerprint），它是消息摘要演算法和非對稱加密演算法的結合體，能夠驗證數據的完整性，並且認證數據的來源 。

數據簽名演算法的模型分為兩個主要階段：

需要注意的是，Android 目前不對應用證書進行 CA 認證，應用可以由第三方（OEM、運營商、其他應用市場）簽名，也可以自行簽名。

應用 APK 其實是一種特殊的 Zip 壓縮包，無法避免惡意破解者解壓 / 反編譯修改內容，針對這個問題有何解決方案呢？他山之石，可以攻玉 ——數字簽名演算法。應用簽名正是數字簽名演算法的應用場景之一，與其他應用場景類似，目的無非是：

Android 平台上運行的每個應用都必須有開發者的簽名。在安裝應用時，軟體包管理器會驗證 APK 是否已經過適當簽名，安裝程序會拒絕沒有獲得簽名就嘗試安裝的應用。

軟體包管理器在安裝應用前會驗證應用摘要，如果破解者修改了 apk 里的內容，那麼摘要就不再匹配，驗證失敗（驗證流程見下文方案）。

截止至 Android 11，Android 支持以下三種應用簽名方案：

為了提高兼容性，必須按照 v1、v2、v3 的先後順序採用簽名方案，低版本平台會忽略高版本的簽名方案在 APK 中添加的額外數據。

v1 簽名方案是基於 Jar 的簽名。

首先，我們先來分析其簽名產物。 v1 簽名後會增加 META-INF 文件夾 ，其中會有如下三個文件。考慮到使用不同的證書和簽名方式，得到的文件名可能不同，因此你只要留意文件的後綴即可：

v1 簽名流程如下：

MANIFEST.MF（Message Digest File，摘要文件）

*.SF（Signature File，簽名文件）

驗證流程可以分為驗證簽名和驗證完整性兩個步驟：

驗證簽名步驟：

如果上述簽名驗證結果正確，才會驗證完整性：

以上任何步驟驗證失敗，則整個 APK 驗證失敗。

為了解決這些問題，Android 7.0 中引入了 APK 簽名方案 v2。

v2 簽名方案是一種 全文件簽名方案 ，該方案能夠發現對 APK 的受保護部分進行的所有更改，相對於 v1 簽名方案驗證速度更快，完整性覆蓋范圍更廣。

在分析 v2 簽名方案之前，我們先簡單了解一下 Zip 文件格式：

首先，我們先來分析其簽名產物。v2 簽名後會在 「條目內容區」和「中央目錄區」之間插入「APK 簽名分塊（APK Signing Block）」 。

從左到右邊，我們定義為區塊 1~4。

相對與 v1 簽名方案，v2 簽名方案不再以文件為單位計算摘要了，而是以 1 MB 為單位將文件拆分為多個連續的塊（chunk），每個分區的最後一個塊可能會小於 1 MB。

v2 簽名流程如下：

驗證流程可以分為驗證簽名和驗證完整性兩個步驟：

簽名方案 v3 支持密鑰輪換，應用能夠在 APK 更新過程中更改其簽名密鑰。

【累了，後面先不寫了...】

這一節，我們介紹基於 Android 應用簽名機制的衍生應用場景。

在 v1 方案中， MANIFEST.MF 和 *.SF 這兩個文件會記錄大量的文件名和文件摘要。如果 apk 中文件數很多，而且文件名很長，那麼這兩個文件會變得很大。使用 AndResGuard 工具，可以將文件名轉換為短路徑文件名，從而減少這兩個文件的大小。

在實際生產中，往往需要生成多個渠道的 APK 包，傳統的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，這一類多渠道打包方案的缺點是耗時嚴重。隨著 Android 應用簽名方案的演進，演變出了不同的多渠道打包方案：

在 v1 方案中，我們提到了完整性校驗不覆蓋到 META-INF 文件夾的問題。有些多渠道打包方案就是利用了這個問題，在 META-INF 文件夾下添加空文件， 用空文件的名稱來作為渠道的唯一標識 ，就可以節省打包的時間，提高打渠道包的速度。

除了添加空文件的方法，還可以向 APK 添加 Zip Comment 來生成多渠道包（APK 本身就是特殊的 Zip 包）。

在 v2 簽名方案中，幾乎整個 APK 都納入保護范圍，如果向 APK 添加空文件或 Zip Comment 的話，在安裝時會報以下錯誤：

新背景下的多渠道打包方案，則是利用了 APK 簽名分塊（區塊 2）不受保護 & 欄位可擴展的特點 ，向區塊中添加多渠道信息（ID-Value），例如 美團多渠道打包方案 Walle 。

㈢ 像美團外賣這樣的APP用一種開發語言，能開發得出來嗎

像美團外賣這樣的APP用一種開發語言，能開發得出來嗎？答案是不能。

美團發展到現在可以說已經是一個【巨無霸】了，裡面集成了很多很多功能，除了核心的外賣，還有 旅遊 、 娛樂 、購物、出行，金融等等業務線，那麼這么多復雜的業務根本不可能用同一種開發語言實現。

那麼美團都用到哪些開發語言和技術了呢？下面就根據我的理解詳細說一下。

前端是把產品的核心服務交給用戶的呈現者，它的表述方式、展示形式以及交互邏輯都跟用戶息息相關，都影響著用戶使用產品的體驗，也就是說直接影響產品的用戶留存。

前端開發主要分為三大類型：Andriod、IOS和PC（H5） ,Android開發語言是Kotlin和Java，IOS開發語言是Object-c和Swift，PC（H5）開發語言就比較雜了，有JS、CSS、HTML，還有很多第三方的前端框架，比如Angular.js、vue.js、Bootstrap、JQuery等等。

關於後端的功能，這一點可以說是眾說紛紜，主要需要考慮的是如何實現功能、數據的交互流程和存取、平台的穩定性與性能等。

那麼後端都用到哪些開發語言和技術呢？

根據後端技術選型的標准，後端可選的開發語言和技術是非常多的。

比如Java體系的話，可以選用SpringMVC、Spring cloud、Hibernate，Mybatis、Mysql、Redis、Memcache、zookeeper、Kafka......；

比如python體系的話，可以選用Django、Flask、Tarnado、Web2py等，中間件都是通用的，Redis，MQ、MySQL、Kafka等都可以用在python體系中；

當然還有PHP、C、Perl等開發語言。

綜上所述，美團這個巨無霸公司，隨著業務線的擴展用到的技術肯定會越來越多，而且越來越復雜，技術快速變革的時代，適者生存的競爭性也會越來越激烈。

俗話說：羅馬不是一日建成的，任何事都不可能一蹴而就，包含技術。在以後的發展中美團也會逐步更新自己的技術和開發語言的。

至少三種語言。後端一種語言（比如Java丶Go丶Python丶PHP等），後端語言及生態比較成熟。下面重點聊前端App開發。

前台兩種語言（Android和iOS是不同的開發環境。比如Android用Java或者Kotlin，iOS採用Object C++或Swift），稱之為Native開發。

當然創業公司可以用一種前端語言寫App前端，這樣就不需要Android和蘋果分兩種語言寫，寫一次代碼可以編譯成Android和iOS的App，現在通行的方案有Vue之類的DOM渲染模式，以及ReactNative方案（RN）。性能上RN優於DOM渲染但低於用Native開發的App。所以美團這種公司，一定是Native方式寫App，但RN是初創項目不錯的選擇。

與RN競爭的還有一種新貴flutter，是google推出來的，但設計原理與RN不同，性能方面優於RN，只是目前生態不夠健全，國內有閑魚app是採用此技術。未來可能會佔一席之地。

最後，其實App開發已經是強努之末，我覺得主流應該是朝PWA和小程序方向發展。

你好，開發譬如美團這種APP，用一種語言是實現不了的，一個APP有安卓和蘋果兩個操作系統，開發能在安卓iOS端應用的APP主流的開發語言和技術是很多的，如後台有JAVA、C++、PHP、Python等多種開發語言，前端有kotlin、HTML、css、jquery、ajax、bootstrap、angular.js、react、vue.js、node.js、swift、object-c等多種語言和框架。

一個APP的開發是需要前端技術和後台技術共同配合完成，這樣的APP不論是功能還是性能都給用戶很好的體驗，單一開發語言畢竟技術支持有限，所以即使能開發出來，APP的用戶體驗也是不理想的。

一般APP有這幾種開發組合模式：1、原生安卓iOS開發，前端：JAVA、kotlin、swift、object-c後台：JAVA、PHP、C++等後台技術，這種模式開發周期長，成本高，性能好；2、混合APP開發即hybrid app，前端以網頁技術為主，穿插原生開發功能，兼具原生APP和web app的優點，如淘寶、微信等應用都是走的這個技術；3、web app，前端純網頁技術，後台為主流開發語言，這種模式開發速度快，成本低，界面體驗可能弱一些。

可見開發一款APP大多數都是多種語言配合完成，謝謝閱讀。

看完之前的評論，依然好奇為什麼一個語言不能完全勝任。

前端跨平台的方案有react native，cordova,flutter等，如果需要兼容開發小程序，h5頁面，可以採用taro來開發，一套代碼，所有平台通吃。

後端的方案有服務端運行時nodejs，大數據背景下運用而生的資料庫mobgodb，緩存解決方案redis，搜索工具elasticsearch，負載均衡ngix，基本上是需要什麼就有什麼

所以總結下來，一句話，一種語言可以實現類似美團這樣的app和小程序。為什麼美團使用的語言那麼多，一大原因估計是美團app開發的早，當時前端技術不成熟，工具沒現在這么多。

使用混合開發與C++ 進行跨平台開發，有好有壞。

C++ 進行跨平台開發

編寫一次，隨處運行。早在 2013 年，Dropbox 就採用上述策略進行移動開發，這背後的想法很簡單：用 C++ 編寫一次代碼，而不是用 Java 和 Objective-C 編寫兩次。那時，整個移動工程團隊相對還比較小，但需要支持快速增長的移動路線圖。因此，公司希望找到一種方法，使這個小團隊可以快速交付大量 Android 和 iOS 代碼。

如今，Dropbox 完全放棄了這個策略，轉而使用各個平台的原生語言（主要是 Swift 和 Kotlin ，這兩種語言在剛開始制定移動策略時還不存在）。

Hybrid App混合開發

Hybrid App主要以JS+Native兩者相互調用為主，從開發層面實現「一次開發，多處運行」的機制，成為真正適合跨平台的開發。Hybrid App兼具了Native App良好用戶體驗的優勢，也兼具了Web App使用HTML5跨平台開發低成本的優勢。

目前已經有眾多Hybrid App開發成功應用，比如美團、愛奇藝、支付寶等知名移動應用，都是採用Hybrid App開發模式。

移動應用開發的方式，目前主要有三種：

幾種模似都可以開發出應用，小應用無所謂，但是大流量應用，對圖形要求高的如 游戲 等原生開發的效果還是最好

支付寶打開很慢，就是因為採用混合開發，使用人多了不如原生開發

不行的哦。任何你看到的應用和網頁，都需要多個語言開發的，大的分比如前端和後端，用的語言都是不一樣的