Written before project start-some experiences

The new project is about to begin. I am solely responsible for the Android platform. This is the first time that I have full control over the development of a software. I feel a little uneasy, afraid that I am not able to do well, but there is no way to do it, I had to clench my teeth to catch up. I think back to my previous project experiences and have some insights.

1. During the interface layout, you must consider switching between the landscape and the landscape, and try not to adapt to many machines later.

2. you must be rigorous in controlling the lifecycle of an activity. Consider When to query the activity, when to remove the listener, and when to switch the activity's three lifecycles. Save the interface information and restore the interface information, all must be inCodeWe recommend that you do your best before writing the code, so you cannot follow the bug.

3. code is often sorted out, and attributes and methods that are not used in the class must be deleted. Do not think about future use. 99% of the cases are that they will never be used in the future. This can avoid confusion in future code sorting.

4. the workbench encoding and engineering encoding use UTF-8 in a unified manner, and synchronize the workbench on the home computer with it to avoid garbled code.

5. there is no way to keep a good job record because the company is small and there is no development document. You should write your work record as much as possible. For example, the general implementation idea of a function and the difficulties encountered, the solution will not be too difficult in the future.

6. Define the method name and attribute name must not be a waste of time. You can get a good name and save a lot of time in the future.

7. when XML is used for page layout, try to reuse elements. At the same time, the XML name is very important. Any layout file of an activity must be followed by a suffix of _ activity, the layout of itemview in the list must be suffixed with _ item, so it must be unified. Otherwise, it will be messy in the future.

8. Resource files such as drawable and styles that cannot be used in the res directory should be deleted in time. It will be very troublesome to delete them later. Who knows if this drawable is used.

9. Pay more attention to threads and threads. If the thread is not opened, the thread should be opened less, and handler should be used instead. When starting a thread, you must consider how to close it.

10. unit testing is required.

Now I have thought of so much, and I will try again later.