jd源碼
首先要下載兩個工具：dex2jar和JD-GUI
前者dex2jar是將apk中的classes.dex轉化成Jar文件，而JD-GUI是一個反編譯工具，可以直接查看Jar包的源代碼。以下是下載地址：
dex2jar：
JD-GUI：
具體步驟：
首先將apk文件，將後綴改為zip，解壓，得到其中的classes.dex，它就是java文件編譯再通過dx工具打包而成的；
解壓下載的dex2jar，將classes.dex復制到dex2jar.bat所在目錄。在命令行下定位到dex2jar.bat所在目錄(在DOS命令下CD 目錄)
運行
dex2jar.bat classes.dex
生成
classes.dex.dex2jar.jar
生成jar文件的截圖如下：
運行JD-GUI（jd-gui.exe），打開上面生成的jar包，即可看到源代碼了
❷ 如何防止JD-GUI，JD-Eclipse 查看自己代碼
apk如何防止反編，就用反編譯工具來舉例，例如dex2jar和JD-GUI。dex2jar是將APK中的classes.dex轉化成Jar文件，而JD-GUI是一個反編譯工具，可以直接查看Jar包的源代碼。
具體步驟：首先將APK文件後綴改為zip，解壓，得到其中的classes.dex，它就是java文件編譯再通過dx工具碰模打包而成的；解壓下載的
dex2jar，將classes.dex復制到dex2jar.bat所在目錄。在命令行下定位到dex2jar.bat所在目錄(在DOS命令下CD
目錄)。運行dex2jar.bat classes.dex生成classes.dex.dex2jar.jar
運行JD-GUI（jd-gui.exe），打開上面生成的jar包，即可看到源代碼了。笑春緩
apk如何防止反編，現在大多開發者已經意識到了App加密保護的重要性，愛加密正是順應行業的發展，對APK進行加密保護，防止反編譯，保護開發者的創意不再被剽竊的第三方森遲加密服務平台。
加密原理：通過對源碼進行加殼保護，然後生成類似虛像的DEX殼文件，即使反編譯也無法看到APK包的源碼，達到防止反編譯的目的。
❸ 京東hotkey源碼解析
京東hotkey是一個經過京東大促驗證的hotkey防禦中間件，大概原理是通過上報key訪問數到統計伺服器集群，統計伺服器集群將hotkey通知到客戶端，讓hotkey能緩存到本地內存中，做到毫秒級的Scale-Out。處理方式有點像美團cat實時收集數據進行統計，只不過美團cat沒有反向通知邏輯而已。非常貼亂豎近工作實踐，值得一看。
首先看一下緩存入口Cache的get方法，JdHotKeyStore.getValue是獲取hotkey的方法，並且會進行訪問嘩薯大次數的統計上報，如果獲取到hotkey不為空，則直接返回，否則從redis獲取並調用JdHotKeyStore.smartSet判斷是否有hotkey，有則設置值，最後返回。
JdHotKeyStore.getValue會先調用inRule校驗此key是否有對應規則，如果沒有對應規則則不處理，然後調用getValueSimple從本地內存中獲取hotkey的存儲對象ValueModel，如果沒有獲取到，則調用HotKeyPusher.push開始計數；如果獲取到，會調用isNearExpire判斷是否快過期了，如果是也計數，然後取出ValueModel里的value是否有設置對應值，有才返回。最後調用KeyHandlerFactory.getCounter().collect進行對應規則的計數。下面來一步步分析此流程。
inRule會去KeyRule緩存中獲取對應的規則，經過層層調用會到KeyRuleHolder的findByKey方法，然後繼續調用其findRule方法選擇對應的KeyRule，如果沒有KeyRule就直接返回了，否則會拿到它的ration(hotkey緩存時間)，拿到對應ration的本地緩存。實際上這里為了方法的通用性，用了get來代替contain的判斷。
findRule的邏輯比較特別，作者已經留下了注釋，優先全匹配->prefix匹配-> * 通配，這樣做是為了更精確選擇對應的規則。比如配置了sku_的前綴規則，但是茅台sku的流量突升，需要針對茅台sku的本地緩存再長一點時間讓系統平穩渡過高峰期，那就配置一個sku_moutai_sku_id的全匹配規則，這樣不會干擾到其他sku的緩存規則。
那麼KEY_RULES的規則是怎麼來的呢？這就要說到etcd了，其實可以把etcd當做zookeeper，也有對配置crud，然後通知客戶端的功能。這里是做了定時拉取+監聽變化的雙重保證，這里跟攜程apollo的處理非常像：不要把雞蛋放在一個籃子，兜底功能真的很重要。每5秒定時從etcd拉取規則，開啟監聽器有變化就去etcd拉取規則。fetchRuleFromEtcd從ectd的rule_path獲取rules，然後轉化成ruleList繼續調用notifyRuleChange進行本地處理。
notifyRuleChange會往EventBus發送KeyRuleInfoChangeEvent的通知，進而進入KeyRuleHolder的putRules方法，這里可以看到維護了KEY_RULES和RULE_CACHE_MAP。
回到原有流程，getValueSimple方法的鏈路比較長，主要是通過key的規則，獲取到對應的ration，然後從對應ration的本地緩存中獲取ValueModel。
接下來是HotKeyPusher.push，如果是remove則在etcd創建一個節點然後再刪除，達到集群刪除的效果。如果是探測並且key在規則內，則調用KeyHandlerFactory.getCollector().collect進行統計。
KeyHandlerFactory.getCollector().collect方法交替使用兩個map，對count進行累加，這樣清理map的時候就不需要停頓了，交替使用是避免停頓的有效方手納式。
接回上文，還有一個 KeyHandlerFactory.getCounter().collect收集的是規則的訪問次數，也是取到對應的規則，然後對規則的訪問總數、熱次數進行累加。
兩個指標的收集已經分析完畢，那怎麼發送到worker呢？來到PushSchelerStarter，這里會啟動對兩個指標的定時線程池，分別會定時調用NettyKeyPusher的send和sendCount方法。
NettyKeyPusher的send和sendCount方法都是為統計數據選擇對應的worker然後進行請求，chooseChannel就是根據key哈希到其中一個worker上，然後發送請求即可。
最後當worker統計到hotkey時，client需要接收worker推送過來的hotkey進行存儲，可以看到NettyClientHandler會向EventBus發送ReceiveNewKeyEvent事件，ReceiveNewKeyListener收到此事件後將調用receiveNewKeyListener.newKey，將hotkey放到本地緩存，client端的處理流程就結束了。
由上文可知，client與worker的交互只有推送統計數據到worker，worker接收處理，最後推送hotkey到client。因此worker端只需要分析兩個部分：統計數據匯總、推送hotkey。
首先看到HotKey的處理邏輯是在HotKeyFilter中，首先會對totalReceiveKeyCount進行累加，然後調用publishMsg，如果統計信息超時1秒或者在白名單中就不處理，否則繼續調用keyProcer.push。
keyProcer.push將未過時的統計信息丟進queue中。
worker端會開啟指定數量的KeyConsumer，不斷消費queue中的統計數據。根據統計數據的類型調用KeyListener的removeKey和newKey。
KeyListener的removeKey和newKey方法對Cache中的滑動窗口SlidingWindow進行刪除或者累加，刪除或者達到一定訪問數就會推送到根據appname選出所有client進行推送。
京東的hotkey處理是通過計數來動態判斷是否為hotkey，然後緩存再本地內存中，做到毫秒級的scale out。那還有沒有其他解決方案？下面是我的觀點：
1.如果面對一些緩存key很少的場景，比如活動頁信息（同時進行的活動頁不可能超過1000），完全就可以直接將緩存放在本地內存中，到了刷新時間就從redis拉取最新緩存即可，不需要動態計算hotkey。也就是常見的多級緩存。
2.同樣是動態判斷hotkey，但會將hotkey遷移到專門的、更多節點、更高性能的hotkey redis集群中，集群中每個節點都有同一個hotkey緩存，這樣就可以做到請求的分散，避免流量都流向同一個redis節點，判斷是hotkey就去hotkey集群中取，不需要存在本地內存中了，維護起來會比較簡單。
❹ 手機怎麼將位元組碼反編譯為源碼
1、JD-GUI：一款免費的Java反編譯工具，可以將.class文件反編譯為Java源代碼文件，能在手機上使用。
2、jadx：一款開源的AndroidAPK反編譯工具，可以將APK包中的.dex文件反編譯成Java源代碼文件，能在手機上使用。
❺ JD_GUI查看反編譯後的源碼為什麼會變成位元組碼
反編譯後都是匯編指令，很難看的，沒有相當的功底和耐心，一般都會望而卻步