Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow operations in UI thread #264

Closed
00conan00 opened this issue Mar 28, 2014 · 2 comments
Closed

Slow operations in UI thread #264

00conan00 opened this issue Mar 28, 2014 · 2 comments

Comments

@00conan00
Copy link

Dear developers,

I am analyzing AFWall+ using a static code checker. I found some potential slow operations in AFWall+'s UI thread.

Android documentation says this:
http://developer.android.com/training/articles/perf-anr.html

"Any method that runs in the UI thread should do as little work as possible on that thread. In particular, activities should do as little as possible in key life-cycle methods such as onCreate(). Potentially long running operations such as network or database operations should be done in a worker thread (e.g., via AsyncTask)."

I found the following event handlers transitively performing heavy operations:

dev.ukanth.ufirewall.LogActivity.onCreate() which calls File IO operations.

The call hierarchy is shown below:
dev.ukanth.ufirewall.Api.parseLog(Landroid/content/Context;Ljava/lang/String;)Ljava/lang/String;
dev.ukanth.ufirewall.LogActivity.parseAndSet(Landroid/content/Context;Ljava/lang/String;)V
dev.ukanth.ufirewall.LogActivity.populateData(Landroid/content/Context;)V
dev.ukanth.ufirewall.DataDumpActivity.onCreate(Landroid/os/Bundle;)V
dev.ukanth.ufirewall.LogActivity.onCreate(Landroid/os/Bundle;)V

Do you think these operations affect AFWall+'s performance? If yes, perhaps moving these actions to a separate thread can help make AFWall+ super smooth in user interaction. Looking forward to your reply and hope I can help improve AFWall+.

@cernekee
Copy link
Contributor

Hmm, is this a bot?

aarddict/android#94
tuxmobil/CampFahrplan#31
guardianproject/ChatSecureAndroid#434
StoryMaker/storymaker#39

Based on what I see in parseLog():

  • The call to getApps() "probably" uses the cached copy, but if it has to query PackageManager and read the preferences, it could block. This could be a slow operation on devices with hundreds/thousands of apps.
  • The use of BufferedReader to parse a string line-by-line may generate false positives for a static checker looking for file-related calls.

Is there anything else inside this function to worry about?

IIRC there are still some random SU calls that might run from the UI thread (although the worst ones are gone).

@00conan00
Copy link
Author

Thanks for your prompt feedback.
I am a undergraduate student doing research for android apps.
The static checker I implemented seems to need more polish.

I will double check for the issues you mentioned above.
Again, thanks for your explanation and comments. :)

@ukanth ukanth closed this as completed Apr 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants