難読化者は、通常、クラス、メソッド、およびフィールド名を意味のない名前に変更するだけです。だから、あなたが "ScoreCalculator.computeScore（Player p、Match m）"を持っていれば、 "A.zk（F f、R r）"になります。これは、javascriptでソースの長さを減らすことを除いて、UglifyまたはClosureコンパイラがjavascriptに対して行うことと似ています。
とにかく方法が何であるかを理解することは可能ですが、それはもっと難しいことです。
また、Javaはレイトバインディング（DLLまたはSOファイルとして）を使用します。したがって、あなたのコードの外側にある呼び出し（java.util、java.langなどのパッケージのような）を難読化することはできません。また、コードが外部からの呼び出しを受け取る必要がある場合（典型的な例では、ボタンのリスナーを登録する）、そのコードを難読化することはできません。 DLLの外部でフォームと呼ばれる必要があるメソッドの名前と他のDLLを呼び出すことができるDLLについても同じことが起こります。
ただし、特定のソースコードとコンパイル済みコードの間のマッピングは、必ずしも1対1ではありません。以前のCコンパイラは、特定のソース指令に対して同じオペコードを生成するために使用されていたので、デコンパイラは非常に効果的でした。次に、Cコンパイラは、結果として得られるオペコードに多くの最適化を追加しました。これらの最適化はほとんど無効です。[1]
さまざまなプラットフォーム（さまざまなアンドロイドデバイスを含む）で動作するため、Javaはコンパイル時にJavaは実行中のデバイスのアーキテクチャとハードウェアのプロパティに基づいて、実行時に後で深刻な最適化を適用することにしました（これは「HotSpot」がほとんど[2]です）。
良いobfuscatorは、通常、バイトコードの命令を並べ替えたり、無駄なものを挿入したり、逆コンパイラがソースコードを簡単に派生させることができないようにするためのいくつかの最適化を前もって適用します。
このテクニックは、バイトコードを読むことができる人にとっては無意味です。可能であれば、Cの難読化は、人がアセンブラコードを読むことができれば無意味です。
多くのクラッキングソフトウェアが示すように、リバースエンジニアリングは、ファームウェア（iPhoneファームウェアについて考える）であっても、Cなどの遅れでも常に可能です。コードが実行されているクライアントが常に信頼できず、と。
非常にミッションクリティカルなコードがあれば、誰かが盗む可能性のある価値のあるものがあれば、サーバー側で実行するか、何らかの理由でサーバー側で検証することをおすすめします。
を！あなたはあなたのapkにproguardを適用していませんか？答えがいいえ、それはあなたの答えです！ :) – t0mm13b
私はProguardを使い、relの前にproject.propertiesファイルを編集して、私のアプリケーションを楽にしました。クラス名は私のオリジナルではありませんが、すべてのメソッド名は元のようです。私。クラス名だけが変更されているので、私のアプリを逆にするのは簡単です。編集：また、静的メソッド名が変更されているようです。しかしこれを逆転することは、ロケット科学ではほとんどありません。 –
proguard.cfgを投稿できますか？ [examples]（http://proguard.sourceforge.net/index.html#manual/examples.html）をチェックしてください – t0mm13b