Evenimentele sunt încărcate și rulate pe firul principal, iar dacă primul eveniment din firul principal nu este finalizat, ajungi la al doilea eveniment, la fel ca alte programe din firul principal, aștepți ca cel anterior să termine procesarea înainte de a procesa următorul sau alt program sau eveniment din firul principal.
Cele de mai sus sunt că am încapsulat eu însumi un obiect, iar în acel obiect am încapsulat eu însumi un eveniment.
Procesez date prin metoda de abonament la evenimente, cum ar fi partea de adnotare a imaginilor,
Pentru că evenimentul la care m-am abonat era un fișier citit txt, iar fișierul meu txt avea 50.000 de linii, ceea ce a făcut ca metoda evenimentului să fie declanșată de 50.000 de ori.
Apoi, când am rulat programul, am observat că interfața mea era într-o stare de animație suspendată și am știut că trebuie să fie o problemă acolo.
Inițial am crezut că manipularea controlului interfeței în metoda asta a cauzat moartea falsă.
Apoi, pas cu pas, s-a constatat că, la adăugarea datelor în set, acesta intrase deja într-o stare de animație suspendată.
de ce??? În cele din urmă, am aflat de pe internet că evenimentul este pe firul principal, iar dacă primul eveniment nu este procesat, va bloca executarea următorului,
În general înțelegeam ce ordonam, ca să fiu direct, 50.000 de evenimente au făcut ca programul să fie blocat, iar apoi am intrat într-o stare de animație suspendată.
Soluție:
Pentru unele evenimente simple, care nu vor duce la executarea unui număr mare de metode de eveniment, pot fi scrise direct în metoda evenimentului.
Pentru un număr mare de metode de eveniment numite, sper să deschizi un fir de discuție pentru a le gestiona, cum ar fi: socket sau httplistener, etc. (cantitatea de date este mică și nu o poți vedea, odată ce volumul de date este mare, haha, va muri direct)
|
Postat pe 21.09.2016 16:05:58
|
|
|
|
Postat pe 22.09.2016 09:23:17