2014-08-27 15 views
7

Sto riscontrando un problema con Navigation Drawer, è troppo lento, la soluzione che sto cercando è chiudere prima il cassetto e poi mostrare l'attività, ma non funziona, certamente io Mi manca qualcosa.Navigation Drawer lag su Android

private class DrawerItemClickListener implements ListView.OnItemClickListener { 
     @Override 
     public void onItemClick(AdapterView<?> parent, View view, int posicao, long id) { 
      setLastPosition(posicao); 
      setFragmentList(lastPosition); 
      layoutDrawer.closeDrawer(linearDrawer); 
     } 
    } 

    private OnClickListener userOnClick = new OnClickListener() { 
     @Override 
     public void onClick(View v) { 
      layoutDrawer.closeDrawer(linearDrawer); 
     } 
    }; 

    private void setFragmentList(int posicao) { 

     FragmentManager fragmentManager = getSupportFragmentManager(); 
     Fragment fragment = new FragmentViagens(); 

     switch (posicao) { 

      case 0: 
       fragmentManager.beginTransaction().replace(R.id.content_frame, fragment).commit(); 
       break; 
      case 1: 
       fragmentManager.beginTransaction().replace(R.id.content_frame, new FragmentPedidos()).commit(); 
       break; 
      case 2: 
       fragmentManager.beginTransaction().replace(R.id.content_frame, new FragmentClientes()).commit(); 
       break; 

     } 

     navigationAdapter.setChecked(posicao, true); 
     setTitleFragments(lastPosition); 
     navigationAdapter.resetarCheck(); 
     layoutDrawer.closeDrawer(linearDrawer); 

    } 

risposta

24

si può fare in questo modo per evitare cassetto lag, modificare la onItemClick:

layoutDrawer.closeDrawer(linearDrawer); 
setLastPosition(posicao); 
new Handler().postDelayed(new Runnable() { 
     @Override 
     public void run() { 
      setFragmentList(lastPosition); 
     } 
    }, 200); 

Edit: modo preferito dovrebbe essere l'impostazione DrawerListener su DrawerLayout e impostare il tuo frammento in onDrawerClosed in questo modo:

Fragment mFragmentToSet = null; 

@Override 
public boolean onNavigationItemSelected(@NonNull MenuItem item) { 
    // Handle navigation view item clicks here. 
    switch (item.getItemId()) { 
     case R.id.nav_home: 
      mFragmentToSet = HomeFragment.newInstance(); 
      break; 
    } 

    mDrawerLayout.closeDrawer(GravityCompat.START); 
    return true; 
} 

mDrawerLayout.addDrawerListener(new DrawerLayout.DrawerListener() { 
     @Override public void onDrawerSlide(View drawerView, float slideOffset) {} 
     @Override public void onDrawerOpened(View drawerView) {} 
     @Override public void onDrawerStateChanged(int newState) {} 

     @Override 
     public void onDrawerClosed(View drawerView) { 
      //Set your new fragment here 
      if (mFragmentToSet != null) { 
      getSupportFragmentManager() 
        .beginTransaction() 
        .replace(FRAGMENT_CONTAINER_ID, mFragmentToSet) 
        .commit(); 
      mFragmentToSet = null; 
      } 
     } 
    }); 
+0

Grazie per il vostro aiuto, ora è più veloce, ma sta ancora ottenendo un certo ritardo, non dovrebbe accadere. Come posso chiudere il cassetto e mostrare l'attività? Puoi aiutarmi su questo? – AND4011002849

+0

Sì, si potrebbe provare a modificare il ritardo da 200 a 250 o 300. – Yuraj

+0

http://developer.android.com/training/basics/firstapp/starting-activity.html – Yuraj

18

Invece di fare un'operazione in onClick, perché non farlo in onDrawerClosed da DrawerLayout.DrawerListener?

+0

Mi dispiace non ho capito Sono molto nuovo per lo sviluppo Android – AND4011002849

+0

Si può fare in questo modo, ma preferisco la soluzione semplice - postDelay. – Yuraj

+0

Penso che questa sia la soluzione giusta. L'utilizzo del ritardo dipende dalle prestazioni del dispositivo. – uDevel

0

Vedere this per una combinazione apparentemente corretta di entrambe le risposte di cui sopra.

0

Prova questo. Al cassetto verrà detto di chiudere usando la trasmissione. Questo per garantire che l'attività o il frammento in fase di caricamento sia eseguito prima, prima di chiudere il cassetto.

All'interno MainActivity

private BroadcastReceiver xBroadcastReceiver = new BroadcastReceiver() { 
    @Override 
    public void onReceive(Context context, Intent intent) { 
     if (Drawer.isDrawerOpen(GravityCompat.START)){ 
      Drawer.closeDrawers(); 
     } 
    } 
}; 

@Override 
protected void onStart() { 
    super.onStart(); 
    IntentFilter filter = new IntentFilter(); 
    filter.addAction("my.drawer.listener"); 
    this.registerReceiver(xBroadcastReceiver, filter); 
} 

@Override 
public void onDestroy() { 
    super.onDestroy(); 
    this.unregisterReceiver(xBroadcastReceiver); 
} 

All'interno attività o frammento

@Override 
public void onStart() { 
    super.onStart(); 
    Intent intent = new Intent(); 
    intent.setAction("my.drawer.listener"); 
    getActivity().sendBroadcast(intent); 
} 

si potrebbe cambiarlo in precedenza processo dal onCreate o onAttach, ma dipenderà dalla vostra applicazione.

5

Penso di aver trovato la soluzione migliore per questo!

in primo luogo fare la transazione frammento in questo modo:

new Handler().post(new Runnable() { 
       @Override 
       public void run() { 
        getSupportFragmentManager() 
          .beginTransaction() 
          .setCustomAnimations(android.R.anim.fade_in, android.R.anim.fade_out) 
          .replace(R.id.container, finalMenuFragment) 
          .commit(); 
       } 
      }); 

So che sembra inutile inviare un Runnable ma questo hack evitare il ritardo sul click animazione sul cassetto soprattutto quando si utilizzano android:background="?attr/selectableItemBackground" per un elemento cliccabile .

E poi si chiude il cassetto ALLA FINE DEL funzione onResume() del frammento (in questo esempio è "finalMenuFragment"), in questo modo:

new Handler().post(new Runnable() { 
     public void run() { 

      mDrawerLayout.closeDrawer(mFragmentContainerView); 
     } 
    }); 

Ancora una volta So che sembra stupido per pubblicare un Eseguibile ma rende scorrevole l'animazione.

In questo modo, il cassetto si chiuderà il più velocemente possibile se si desidera animazioni fluide e se il frammento non ha molte viste in esso, si chiuderà più velocemente e senza ritardo.

Vorrei un feedback su questo se qualcuno ha testato questa soluzione, spero che aiuti!

+2

questo ha fatto i trucchi per me. Grazie. – RameshJaga

+1

FYI: Gestore # postDelayed (Runnable, 0) è l'equivalente di # post gestore (eseguibile) –

0

Penso che l'utilizzo dei ritardi per le transazioni dei frammenti sia la soluzione più instabile.

Quello che li sta eseguendo suDrawerClosed offre un leggero ritardo tra la chiusura e la visualizzazione dei frammenti.

Preferisco eseguire la transazione subito dopo il clic di navigazione, chiudere il cassetto dopo con postDelayed 200ms (in controllo eseguibile nel caso in cui non sia nullo). Il frammento si apre appena prima che il cassetto inizi a chiudersi.

Non solo il ritardo dal rubinetto fino alla chiusura del cassetto è più breve di quello dopo il cassetto chiuso e il frammento successivo che appare, è meglio UX mentre l'utente rimuove il dito dallo schermo - il ritardo è meno evidente.

2

Ho appena risolto questo problema in un solo One-Line

andare al vostro Menifest file di nel cassetto di attività appena messo HardwareAccelerated vero per evitare il ritardo di apertura cassetto

<activity 
     android:name=".activity.YourDrawerActivity" 
     android:configChanges="keyboardHidden|orientation" 
     android:screenOrientation="portrait" 
     android:hardwareAccelerated="true" //important 
     android:theme="@style/AppTheme.NoActionBar" 
     android:windowSoftInputMode="stateHidden" /> 
0

Se ritarda puoi richiedere l'accelerazione hardware. se manifestiamo aggiungere questo alla vostra attività

android:hardwareAccelerated="true" 

se il metodo OnCreate aggiungere questo codice

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, 
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED); 

ora avete l'accelerazione hardware nella vostra attività. fonte: https://developer.android.com/guide/topics/graphics/hardware-accel.html

Problemi correlati