The grinding road of the app (top)

Objective:

As the saying goes ax, a good product from a good idea to the user's hands, is the need for a team to spare no effort to work together continuously polished out; Similarly, a good app in addition to normal code writing, but also need to go through other aspects of continuous polishing to formally interact, and finally reach the user's hands. This article mainly describes an application in addition to the development of what needs to be done in order to pass the interaction, in this, I hope that the need for a friend a little revelation!
This article is divided into three blog posts to describe the content, the main content includes: unit testing, performance analysis, signature, confusion, apk slimming, anti-compilation, packaging and reinforcement, the following mainly describes the previous three: unit testing, performance analysis and signature.

One, Unit test

Unit testing is the writing of test code to detect specific, unambiguous, granular functions. Unit testing is not only used to ensure the correctness of the current code, but more importantly to ensure that the code is repaired, improved, or reconstructed. It is essential for the code-farmers who want to build excellent products, though most of the companies have difficulties in achieving them.
In general, unit testing tasks mainly include the following aspects:
1. Interface function test
It is mainly used to ensure the correctness of the interface function.
2. Data structure Testing
It is mainly used to ensure the correctness of the data structure in the interface, such as whether the variables have initial values or not.
3. Boundary Condition Test
Boundary condition determination is the most commonly used in unit testing, and it is also the most common bug in development, and the types of boundary conditions are mainly the following situations:
-Variables are objects: such as whether the object is null, etc.;
-Variables are numeric: numeric bounds: Minimum, maximum, infinity, infinity, overflow boundary: Minimum-1, maximum +1, near boundary: Minimum value + 1, maximum value-1;
-The variable is a string: whether the string is empty, and the length of the string is determined by the numeric variable;
-The variable is a set: whether the set is empty, the size of the set is determined by the numerical variables;
4. Independent implementation of PATH testing
The main guarantee of code coverage, such as statement coverage: to ensure that each statement is executed to, branch coverage: to ensure that each branch is executed to, conditional override: To ensure that each condition is overwritten to true and false case, path overrides: Ensure that each path is executed to;
5. Exception Handling pathway test
The main guarantee is that all exceptions are tested.

JUnit is a Java unit Testing framework that has been relied upon by default in Android Studio. At present the mainstream has JUnit3 and JUNIT4. In JUnit3, the test case needs to inherit the TestCase class. In JUNIT4, the test case does not inherit the TestCase class, only annotations such as @test are needed. Here's an example to better demonstrate the unit testing process:
A calculation tool class is established under application to facilitate the writing of unit tests:

 PackageCom.vise.note.util;/** * Calculation related Tools class * Created by XYY on 16/6/25. * * Public  class calculatorutil {     Public Double Plus(DoubleADoubleb) {returnA + b; } Public Double minus(DoubleADoubleb) {returnA-B; } Public Double Multiply(DoubleADoubleb) {returnA * b; } Public Double Divide(DoubleADoublebthrowsException {if(b = =0){Throw NewException ("The divisor cannot be zero!" "); }returnA/b; }}

Android Studio provides a quick way to create test classes by right-clicking the Calculatortest class declaration in the editor, selecting go to > Test, then clicking "Create a new test ...", which will pop up two options, One is androidtest, a test directory, because the test does not need to use the emulator, can be run on the local computer Java Virtual machine, so here to select the test directory, The Calculatorutiltest.java file is then generated in the same package as the test and application, with the following content (the method internal implementation is manually added):

 PackageCom.vise.note.util;ImportOrg.junit.After;ImportOrg.junit.Before;ImportOrg.junit.Test;Import Staticorg.junit.assert.*;/** * Created by XYY on 16/6/25. * * Public  class calculatorutiltest {    PrivateCalculatorutil Calculatorutil;@Before     Public void setUp()throwsException {calculatorutil =NewCalculatorutil (); }@After     Public void TearDown()throwsException {calculatorutil =NULL; }@Test     Public void Testplus()throwsException {assertequals (6D, Calculatorutil.plus (1D5D),0); }@Test     Public void Testminus()throwsException {assertequals (-4D, Calculatorutil.minus (1D5D),0); }@Test     Public void testmultiply()throwsException {assertequals (5D, Calculatorutil.multiply (1D5D),0); }@Test     Public void Testdivide()throwsException {assertequals (0.2D, Calculatorutil.divide (1D5D),0); }}

Finally, you can directly select Calculatorutiltest to run directly. Here, the unit test is over, here is the performance analysis, this is also very important oh! ^_^

Second, performance analysis 1, Memory Monitor

After you run the project in Android Studio, click Monitor in Android Monitor to see the memory usage and CPU performance as shown:

The following can also view the GPU and network related situation, where the network is the frequent use of power consumption is the key to the application, about 70% of the battery is reported data, check location information, the timely retrieval of background advertising information used, how to balance the use is also very important.

2. Heap Snapshot

Based on the memory monitor described above, find the third icon in memory "Dump Java Heap", each click will generate a. hprof file, click on a. hprof file, see the Analyzer Tasks on the right, see two options, One is ' Detect leaeked activites ', the other is ' Find Duplicate Strings ', click on the Green Play button in the upper right corner, will automatically analyze the heap dump to locate the leaked activity and duplicate string, The following analysis Results appears:


As you can see from the two images above, the first option indicates that there are three types of information that can be viewed: The app Heap/image Heap/zygote Heap, which represents the heap memory information for the app stack, the image heap memory information, and the heap memory information for the Zygote process. There is also an option to choose from two views of the class List view and Package Tree view.

Each attribute in the English comparison table

name	meaning
Total Count	The number of objects in this class in memory
Heap Count	The number of objects in this class in heap memory
Sizeof	Physical size
Depth	Depth
Shallow size	The object itself occupies memory size
Retained Size	The amount of memory saved after releasing the object
Dominating Size	The size of the memory that governs

3, Leakcanary

• How to use
  Add references in Build.gradle, different compilations use different references:

{   debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3‘   releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3‘}

In the application:

publicclass ExampleApplication extends Application {  @OverridepublicvoidonCreate() {    super.onCreate();    LeakCanary.install(this);  }}

After the application is run, Leakcanary will automatically analyze the current state of memory, if a leak is detected will be sent to the notification bar, click on the notification bar to jump to the specific leak analysis page.

• Working mechanism
  1, Refwatcher.watch () create a keyedweakreference to the object to be monitored.
  2. Then the background thread checks if the reference is cleared, and if not, the GC is called.
  3. If the reference is not cleared, dump the heap memory into a. hprof file in the file system corresponding to the APP.
  4. Heapanalyzerservice in another process has a heapanalyzer using haha to parse the file.
  5, thanks to the only reference key, Heapanalyzer find keyedweakreference, locate the memory leak.
  6. Heapanalyzer calculates the shortest strong reference path to the GC roots and determines whether it is a leak. If so, establish a chain of references that leads to leaks.
  7. The reference chain is passed to the Displayleakservice in the APP process and is displayed as a notification.
  For more information on the use of leakcanary, please refer to: leakcanary Chinese instructions for use

Note: These are all performance analysis methods for the Android Studio IDE.

Third, signature

Signing the premise of the signature file, the way to generate the signature file is similar, the IDE basically has this feature, here in Android Studio for the column to tell the process of generating a signature file. Select the toolbar build->generate signed APK, open and select the corresponding module, click Next:

Click Create New to enter the following screen:

信息注释Key store path:签名文件路径Password:签名库密码Confirm:确认签名库密码Alias:别名Password:该别名下签名密码Confirm:确认该别名下签名密码Validity:and Last Name:你的全名Organizational Unit:组织单位Organization:oror Province:川或省Country Code:国家代码

Follow the instructions to fill in the corresponding information, click OK to generate a signature file.
Another way is to use the command to create, into the Java Bin directory, such as my Java directory is:/library/java/home/bin, through the Keytool tool to create the KeyStore library, enter the following command:

-genkeypair-alias- xyy.-keyalg-validity100-keystore xyy.keystore

命令说明如下：-genkeypair：指定生成数字证实-alias：指定生成数字证书的别名-keyalg：指定生成数字证书的算法  这里如RSA算法-validity：指定生成数字证书的有效期-keystore ：指定生成数字证书的存储路径（这里默认在keytool目录下）

Then follow the prompts step by step to enter the corresponding information, and finally generated a signature file named Xyy.keystore.
After you have signed the file, place the signature file in the corresponding project directory module that needs to be signed, and then add the following signature information to the module corresponding to the build file (the signature information corresponds to the key information you set for the input):

android{...Signingconfigs {debug {storefile file ("Xyy.keystore") Storepassword"XYY"Keyalias"Note"Keypassword"XYY"} release {StoreFile file ("Xyy.keystore") Storepassword"XYY"Keyalias"Note"Keypassword"XYY"}} buildtypes {debug {minifyenabled false zipalignenabled true Shrinkreso            Urces false Signingconfig Signingconfigs.debug} release {//is confusing (note: If the obfuscation file is not configured with false)            Minifyenabled false//Whether Zip Align is supported zipalignenabled true//whether to clean up useless resources Shrinkresources true Proguardfiles getdefaultproguardfile (' Proguard-android.txt '),' Proguard-rules.pro 'Use signature configuration Signingconfig Signingconfigs.release}}...}

This configuration after each build project generated by the file will use the signature information under Debug, Gradle configuration details can refer to my other blog Android Studio Common Gradle operation.

Personal website: http://www.xiaoyaoyou1212.com Welcome to The spit Groove onlookers!

The grinding path of the app (top)