Android EditText alternative

Question

Currently, Android's EditText is extremely slow when dealing with a huge amount of lines of text (10000+). It appears like this slowdown is partially due to the fact that EditText supports spans, and primarily due to the fact that EditText is calculating the width of each line, which is very expensive. Are there any faster alternatives to EditText, or a way to optimize it to make it usable?

EDIT: Method traces are as follows:

android.text.StaticLayout.generate: 99.1% CPU time inclusive, 8.8% exclusive (1 call)
    android.text.Layout.getParagraphSpans: 28% inclusive, 1.1% exclusive (4686 calls)
    android.text.MeasuredText.setPara: 20.6% inclusive, 1.6% exclusive (2343 calls)
    android.text.MeasuredText.addStyleRun: 18.6% inclusive, 1.1& exclusive (2343 calls)
    android.text.SpannableStringBuilder.getSpans: 15% inclusive (of parent calls), 56.7% inclusive (of all calls, 47.3% of which are from android.text.Layout.getParagraphSpans, 26% are from android.text.MeasuredText.setPara, 26% are from android.text.StaticLayout.generate)

This is a problem I am exploring as well. My post gives a few solutions (although none are adequate) I proposed and tested: http://stackoverflow.com/questions/29801232/edittext-performance-understanding-gpu-process-time-on-profile-gpu-rendering — PPartisan, Apr 23 '15 at 15:01
Maybe you could set `singleLine="true"` so it doesn't have to render line widths? It also won't render anything past the margin until you scroll, at least it *shouldn't*. — Aaron Gillion, Apr 23 '15 at 15:14
@AaronGillion that does improve performance (albeit still not to a usable level), however it doesn't allowing for multi-line editing, which is something I need. — Zambezi, Apr 23 '15 at 15:43
Try android:hardwareAccelerated="false". It is out of EditText capability may be. — Shailesh, Apr 23 '15 at 16:00
android:hardwareAccelerated="false" is helping a lot - performance is still not where it should be but it went from completely unusable to very sluggish (but functional). — Zambezi, Apr 23 '15 at 17:04
Does anyone have any idea why it is that setting hardwareAccelerated to false gives such a drastic improvement? — Zambezi, Apr 23 '15 at 19:22
FWIW, I updated my post with a sample app for people to test themselves, and a couple of video demonstrations. Current consensus appears to be that the issue is related to certain GPUs. [My Post](http://stackoverflow.com/questions/29801232/edittext-performance-understanding-gpu-process-time-on-profile-gpu-rendering?noredirect=1#comment48024347_29801232) and [Sample App/Code](https://github.com/PPartisan/ASyncEditText) — PPartisan, Apr 29 '15 at 19:01
Did you find any sollution for optimizing Edittext besides hardwareAccererate? I am struggling with the same problem right now. — Prokky, Mar 16 '16 at 07:45
EditText wasn't designed for this use case. It was designed for entering a few lines of text. You'll need to create a custom view for this. That really shouldn't surprise you, do you think that a word processor uses the built in text tool in Windows? If you have an extreme usecase, you need to do more work yourself. — Gabe Sechan, Mar 16 '16 at 08:01
@GabeSechanwell well, notepad manages somehow. Granted, that did severely limit the supported filesize for quite some time ... — SamB, Aug 02 '22 at 19:07

Ilya Gazman · Answer 1 · 2016-03-23T06:55:06.117

6

The best thing you can do is using RecyclerView with EditText as its item, so you get a new EditText for each of your lines.

New line will be the only thing you will have to implement.

edited Mar 23 '16 at 06:55

answered Apr 23 '15 at 15:37

Ilya Gazman

31,250
24
137
216

Was this tested by anyone? How well did it do with performance and user interaction compared with EditText? It is hard to implement? – Nicolas Dec 25 '16 at 03:12
1

What ever you do, it will be hard to implement... But the performance rocks! – Ilya Gazman Dec 25 '16 at 03:41
Do you know any newer alternative not suggested here? I saw apps like QuickEdit who have a editor with incredible performance even past 30k lines and they are clearly not using a recyclerview – Nicolas Dec 25 '16 at 03:44
I used a similar approach to scroll the entire [bible](https://www.amazon.com/Gazman-My-Bible/dp/B00E7OHKI0) – Ilya Gazman Dec 25 '16 at 03:50
Isn't that a textview, or is your bible editable? But do you have an idea on how these apps do it? – Nicolas Dec 25 '16 at 22:00

score 2 · Answer 2 · answered Apr 23 '15 at 14:57

2

Although this article only talks about optimizing static TextViews where the text doesn't change, it might get you on the right track for making a more performant EditText.

answered Apr 23 '15 at 14:57

Andrew Orobator

7,978
3
36
36

score 0 · Answer 3 · answered Apr 23 '15 at 15:32

0

Avoid using EditText inside a RelativeLayout, use LinearLayout instead.

answered Apr 23 '15 at 15:32

Shailesh

490
5
11

Unfortunately, it doesn't like this helps at all. In this vein - I've tried setting fixed widths and heights, and still no noticeable difference appears. – Zambezi Apr 23 '15 at 15:37
Can you check DDMS if it has a lot of redraws and recalculations occurrence – Shailesh Apr 23 '15 at 15:43
Also can you confirm the running OS version for the testing – Shailesh Apr 23 '15 at 15:45
I'm running Android 5.0, and it doesn't seem to matter which hardware (tried on multiple). I will update my OP with method tracing in a bit. – Zambezi Apr 23 '15 at 15:46
1

Before recommending to delete please consider http://meta.stackoverflow.com/questions/265552/when-to-flag-an-answer-as-not-an-answer – Petter Friberg Mar 19 '16 at 13:28
This is also a good answer. On many devices using LinearLayout + fixed width does speed up EditText, esp. if the text is superlong. I've just tested on Samsung Tab S (Android 6). – Eugene Kartoyev Oct 08 '18 at 20:01

score 0 · Answer 4 · edited May 23 '17 at 12:33

The alternative would be to use a TextView (how else would you show the text) and make it act as a EditText. Here's how:

You'll set an OnClickListener on your TextView, to show the keyboard:

textView.setOnClickListener(new View.OnClickListener() {
    public void onClick(View v) {
        getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_ALWAYS_VISIBLE);
        isEnteringText = true; //global
    }
});

And override onKeyDown and process keyboard presses to the TextView:

@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
    if(isEnteringText) {
        textView.append(event.getDisplayLabel());
        return true;
    }
    return super.onKeyDown(keyCode, event);
}

Obviously this will need a lot of work, such as hiding the keyboard afterward, processing backspace & enter, and clipboard. I kinda formed my answer around this post, you can try the other methods mentioned in there if you're having problems retrieving the keyboard keys. According to them, the above code will work as long as the language is English.

EditText is _"a thin veneer over TextView"_. The real problem is with the TextView even though the question is about EditText. — Nicolas, Jan 27 '17 at 22:03

Android EditText alternative

4 Answers4

Linked