Pantalla negra inicio App (Cosa fea)
 

Hola amigos del foro.

¡Esto parece una carrera de obstáculos!
Debo ser el más raro del foro por quejarme de tantas cosas. O a lo mejor soy demasiado exigente.

He observado con pena que a medida que una aplicación Android (construída con Delphi) va siendo más pesada (no sé lo pesada que puede ser con 50 MB, cuando los servicios de Google Play tienen 112 MB por ejemplo) Pues éso que tarda mucho en arrancar y, LO PEOR DE TODO, es que te deja la pantalla negra y por más que he buscado en foros y en internet, no encuentro una solución aceptable, hay alguna que otra chapuza, pero nada serio ni definitivo.

Curiosamente, si pones un ShowMessage() al inicio del evento OnCreate este se emite dentro de la pantalla negra, lo aceptas, desaparece, y la pantalla sigue negra hasta que arranca la aplicación. He intentado poner algún objeto como un TAnIndicator o algo semejante y no aparece, el mensaje sí.

Me vais a decir que soy muy pesado, pero Embarcadero debería haber resuelto estas cosas después de 10 ediciones de RadStudio.

Bien, si alguien ha descubierto como resolverlo, le agradecería lo compartiera conmigo y con el resto del foro, pues creo que somos muchos los que pensamos lo mismo.

He visto alguna cosa de kuruno, otras en chino para RadStudio 5, pero nada definitivo.

Gracias y perdonar que sea tan quisquilloso.

Saludos a todos.

En teoria te crea automaticamente un Splash Screen con el logo de Firemonkey

No das informacion suficiente

Tenes muchos form? Se crean todos automaticamente? Que hay en esos forms? Hay componenes de acceso a datos? Cargas muchas imagenes?

Basicamente es como decir, el auto anda lento, como lo soluciono?

Gracias Agustín por interesarte.

El Splash inicial del logo es muy facil de cambiar y se hace en Projects/Options/Application.

Pero este no es el problema. El verdadero problema viene después... (2/3 segundos despues) cuando desaparece el splash inicial. De ahí a que se muestra la pantalla queda en negro y no se sabe qué está haciendo. (El usuario, claro. Nosotros sabemos que está cargando el programa y haciendo lo que le hayamos ordenado en OnCreate y OnShow y generando los componentes... etc, etc.)
Esta pantalla en negro da muy mala impresión.

En concreto mi App (que es un tablero de sudoku) tiene que generar unos cuantos TStringGrid y el primer tablero de forma aleatoria y validarlo y repetir hasta encontrar un tablero válido.

En mi teléfono móvil tarda unos 11s. en el de mi hijo que es más moderno unos 6s. pero en la tableta Samsung Galaxy 3 nos vamos a 15 ó 20 segundos. (¡Un mundo...!)

Está todo en un solo Form, no genero automáticamente en tiempo de ejecución nada más que el tablero, todo lo demás está generado en tiempo de diseño, no tiene acceso a datos... no sé qué más decirte.

Entiendo que pueda tardar unos segundos en generar el tablero y en poner todo a punto, estos segundos han ido aumentando a medida que ha crecido el tamaño de la App.

Lo entiendo... Además los procesadores de los teléfonos y tabletas (sobre todo los más antiguos) son relativamente lentos, los comparamos con los de los PCs. El mismo programa lo tengo ya hecho para PC y abre en un parpadeo.

Todo esto lo entiendo...

He conseguido "dividir" (que no reducir) el tiempo de espera, usando una nueva Form como de presentación.

Comprendo que el tiempo de espera no se pueda reducir, es lo que hay y punto.

Lo que pretendo es evitar ésa pantalla negra. Sustituirla por algo que indique que el programa se está cargando o algo así. Como dije ya lo he intentado con un TAniIndicator y no lo he conseguido. Lo más que he conseguido es un ShowMessage en OnCreate. Ese se muestra sin esperar a la carga del programa.

Lo que os pido es algún truco que haya conseguido alguien, porque el problema, tal como yo lo veo, no debe ser solamente mío. He intentado con la solución de kurono pero tampoco resulta efectiva.

Repito, esto debería estar resuelto en Embarcadero, pero tampoco en el docwiki he encontrado nada que lo resuelva.

No os canso más. Si alquien conoce una solución al problema más elegante que el ShowMessage, agradeceré la comparta en el foro. Porque, o mucho me equivoco, o este problema es general.

Gracias por soportarme.

Saludos.

Yo creo que no van por ahí los tiros.
Si visualizas un form vacío qué te tarda. ¿Algo aceptable?
A mi en las aplicaciones que he hecho sí, por lo tanto entiendo que no es algo que tenga que solventar Embarcadero.

Si el trabajo que estás haciendo para generar el tablero tarda 10 o 15 segundos, Embarcadero ya te da soluciones para hacer eso, pero no sólo en aplicaciones móviles, sino también en aplicaciones de escritorio y la solución en ambos casos es la misma.
Debes utilizar Threads.

Si en el Create o en el Show de un form realizas una tarea que tarda 15 segundos (en una aplicación windows igual) tendrás la pantalla 15 segundos bloqueada.
Eso no es aceptable, por lo tanto debes aplicar una solución con la herramientas que te da Delphi (que ya lo tiene resuelto).

Lo lógico sería visualizar un formulario con un elemento de espera, y en un Thread aparte, realizar la tarea que te está bloqueando. Una vez finalizada esa tarea, cierras el primer form y visualizas el segundo con el tablero.

O quizá cambiar el código que genera los tableros sudoku. De que orden es ese algoritmo? Buscaste en Internet cual es la mejor estrategia para crear una tabla de Sudoku?

Haré caso a Neftalí y estudiaré los Threads que no los he utilizado nunca. Como sabéis no soy profesional de ésto, sólo un aficionado y por lo que estoy viendo bastante TORPE.

Tan inútil que una vez intenté subir unos vídeos al foro y no se llegaron a ver. Si supiera hacerlo, grabaría el tiempo que tarda el programa en arrancar en windows, con las mismas instrucciones, arranca casi instantáneo.

Es mi primer programa para FMX y lleva las mismas instrucciones adaptadas a FMX que el que tenía hecho en Win. No esperaba que tardara tanto en arrancar.

Lo dicho, voy estudiar y ya os contaré.

Saludos.

El thread no es una solucion magica. Tu algoritmo es ineficiente, o estas haciendo algo que no nos estas diciendo que es muy ineficiente

Si ahora colocas el thread y mueves todo el proceso ahi adentro, supongamos que funciona. Ok, la app arranca, sale el logo de firemonkey y luego vas a ver la "pantalla inicial". El problema de tu programa es que hasta que no terminas de generar todos los tableros, no se puede usar para nada. En definitiva vas a tener mas problemas, porque vas a tener que bloquear la pantalla inicial y desbloquearla hasta que se termine de calcular todo

Ademas, de que la programacion con hilos no es algo para nada sencillo, sobre todo en casos como este en el que tienes que sincronizarte con el hilo principal para actualizar componentes visuales

Lo que debes aprender a hacer es depurar y estudiar tu codigo. Descubre que es lo que tarda. Vuelvo a preguntarte: Como generas los tableros? Es un algoritmo tuyo? O buscaste informacion? Quiza haya alguna propiedad o "algo" que se puede aprovechar para que se genere el tablero de forma muuuy rapida

Tambien podrias publicar tu codigo para que lo veamos

Gracias de nuevo. Agustín.
Tienes razón, llevo toda la tarde leyendo sobre los Threads y todavía no he aprendido a implementarlos, a parte de que he leído que son bastante delicados, es decir: que si te equivocas... ¡paf!.

Te pongo el procedimiento de generar tablero. Te comento que tengo declarado un TStringGrid de 3x3 para cada cuadro del tablero que presenta 9 números provisionales o los oculta, según...

Código Delphi [-]
procedure GenerarTablero(var Tablero: TTablero; Dificultad: Integer; Personal:Boolean);
var
  i,j,k,l, Tope, Tope2: integer;
begin
EsDinamico := False;
TableroYaResuelto := False;
// Eliminamosm las listas de Deshacer
Princi.UndoList.Clear;
Princi.RedoList.Clear;

    SeVenTodosProvis := False;
    SeVenParteProvis := False;
    PrimeraVezDosClick := True; //Para generar los Tableros Provis la primera vez
                                // Lo hace al pintar el tablero por primera vez
Princi.Timer1.Enabled := False; // Arrancamos con el contador de 2 clicks parado
Princi.Button13.Enabled := False; // Inhabilitamos Undo
Princi.Button16.Enabled := False; // Inhabilitamos Redo
//Eliminamos todos los cuadros provisionales, si hay
Princi.EliminaProvis;

  for i:=0 to 8 do
    for j:=0 to 8 do
    begin
    TableroProvis[i,j]:=0;  // Ponemos a ceros el tablero de Provisionales
    TableroAyudado[i,j]:=0;  // Ponemos a ceros el tablero de ayuda
    ProvisVisibles[i,j]:=0;
    ProvisPuestos[i,j]:=0;
    ProvisRecuperables[i,j]:=0;
    end;

// Actualizamos el estado de los botones y del tablero
    Princi.grdTablero.Enabled := True;
    Princi.Button1.Enabled := True;
    Princi.Button2.Enabled := True;
    Princi.Button3.Enabled := True;
    Princi.Button4.Enabled := True;
    Princi.Button5.Enabled := True;
    Princi.Button6.Enabled := True;
    Princi.Button7.Enabled := True;
    Princi.Button8.Enabled := True;
    Princi.Button9.Enabled := True;
    Princi.Button10.Enabled := True;
    Princi.Button11.Enabled := True;
    Princi.Button12.Enabled := True;

    Princi.Button13.Enabled := False;
             Princi.Image1.Enabled :=False;
    Princi.Button14.Enabled := True;
             Princi.Image2.Enabled := True;
    Princi.Button15.Enabled := True;
             Princi.Image3.Enabled :=True;
    Princi.Button16.Enabled := False;
             Princi.Image4.Enabled :=False;

// Actualizamos la etiqueta con el nivel
if not Personal
then begin Case Dificultad of
           0: Princi.Label3.Text := 'Nivel SENCILLO';
           15: Princi.Label3.Text := 'Nivel NORMAL';
           25: Princi.Label3.Text := 'Nivel DIFÍCIL';
           30: Princi.Label3.Text := 'Nivel MUY DIFÍCIL';
           end; //Case
     end else Princi.Label3.Text := 'Nivel PERSONALIZADO';

// Comenzamos a generar el nuevo tablero
  FillChar(Tablero,Sizeof(Tablero),0);
  Randomize;
  i:= 0;
  while i < NUM_COLUMNAS do
  begin
    j:= Random(9)+1; // No recuerdo por qué +1 pero en VCL lo tengo así ¿?  hace años (a lo mejor esto sobra)
    if Valido(Tablero, i, 0, j) then
    begin
      Tablero[i,0]:= j;
      inc(i)
    end;
  end;  // EXIT;  //Pruebas
  Resolver(Tablero);
  TableroResuelto := Tablero;


  k:= 0;
  if Personal then begin
                   if Dificultad > 30
                   then Tope:=30
                   else Tope:=Dificultad;
                   end
              else Tope:=30;

// Quitamos 30 obvios
  while k < Tope do
  begin
    i:= Random(NUM_COLUMNAS);
    j:= Random(NUM_FILAS);
    if Tablero[i,j] <> 0 then
    begin
      l:= Tablero[i,j];
      Tablero[i,j]:= 0;
      if Obvio(Tablero,i,j)>0 then
        inc(k)
      else
        Tablero[i,j]:= l;
    end;
  end;

  k:= 0;
if not Personal then tope2:=Dificultad
                else tope2:=Dificultad - Tope;

  // Quitamos algunos que no son obvios SEGUN NIVEL 0, 15, 25, 30, PERSONAL
  while k < Tope2 do
  begin
    i:= Random(NUM_COLUMNAS);
    j:= Random(NUM_FILAS);
    if Tablero[i,j] <> 0 then
    begin
      l:= Tablero[i,j];
      Tablero[i,j]:= 0;
      if Obvio(Tablero,i,j)=0 then
        inc(k)
      else
        Tablero[i,j]:= l;
    end;
  end;

EventoFlechaActivo := False;
end;

Las funciones, como verás casi me sirven las mismas con algunos retoques y unas pocas nuevas.

Al final con el tema de los Threads voy a tener que usar una pantalla de inicio, como la que ya tengo, con la que he conseguido dividir el tiempo de espera entre 2. Y te recuerdo que en los móviles nuevos, 5/7 segundos no es mucho. Con evitar que la pantalla quedara en negro... quizá sería suficiente. Quizá pueda optimizar el flujo recolocando algunos procesos...

Un saludo.

-Bueno.
Ahora recuerdo por qué tengo puesto:

Código Delphi [-]
 j:= Random(9)+1; // No recuerdo por qué +1 pero en VCL lo tengo así ¿?  hace años (a lo mejor esto sobra)

Es porque el número recibido de Random está entre 0 y 9-1.
Saludos.

No se que haran algunas de las funciones a las que invocas dentro de ese codigo (Obvio y Valido por ej)

La otra solucion es que "tu" crees tu form splash

Hay un articulo que dice como hacerlo en FMX: revisalo

Hola Agustín.
Gracias por tu interés.
En Madrid son mas de las 12 de la noche y estoy cansado. Mañana reviso el enlace.
Las funciones de comprobación son muy simples.
Te pongo un par de ellas de las más complicadas:

Código Delphi [-]
 function Fila(Tablero: TTablero; y,n: Integer): boolean;
var
  x: Integer;
begin
  Result:= TRUE;
  x:= 0;
  while (x < NUM_COLUMNAS) and Result do
  begin
    if Tablero[x,y] = n then
      Result:= FALSE;
    inc(x);
  end;
end;

function Valido(Tablero: TTablero; x,y,n: Integer): boolean;
begin
  Result:= Fila(Tablero,y,n) and Columna(Tablero,x,n)
    and Cuadrante(Tablero,x,y,n);
end;

function Obvio(Tablero: TTablero; x,y: Integer): Integer;
var
 i,j,n: Integer;
begin
 j:= 0; n:= 0;
 for i:=1 to 9 do
   if Valido(Tablero,x,y,i) then
   begin
     n:= i;
     inc(j);
   end;
 if j=1 then
   Result:= n
 else
   Result:= 0;
end;

He estado haciendo mediciones de tiempo en distintos dispositivos:
En la Tablet Samsung Galaxy Tab3 tarda 31/32 seg.
En teléfono Samsung Galaxy S III mini 12 seg.
En teléfono Samsung Galaxy A3 7 seg.

Está claro que depende del procesador implicado.

Creo que me va a servir el enlace que me has dejado. Estoy convencido de que sólo necesito no dejar la pantalla en negro, para que el usuario no quede sorprendido y desinformado.

Buenas noches para mi y buenas tardes para ti.

Saludos.

Es que ese algoritmo, a simple vista solamente, ya se ve que tiene un orden de tiempo de ejecucion mucho mas elevado de lo que te parece

Debe haber alguna magica propiedad matematica que permita generar estos tableros de una forma mucho mas rapida

Hay bucles en los que invocas a funciones que invocan a mas bucles... y esto se repite con varias veces de anidamiento

Hola Agustín.
Seguro que tienes razón y existe alguna manera más eficiente de generar el tablero.
Pero seguramente no sea lo que más retrasa. Te explico.

He hecho comprobaciones de tiempo con la Tableta, que es el dispositivo más lento, para ver las diferencias.

Como te dije, he hecho una prueba implementando una pantalla de bienvenida en un form con un botón que es el que llama al form donde está implementado todo el programa con Forrm2.Show. En el procedimiento OnShow hace toda la generación del programa incluido el generador del tablero. Los resultados son los siguientes:

En cargar todo el programa y la pantalla de bienvenida tarda 18/19 seg.
Al pulsar el botón llama al procedimiento OnShow y tarda 11/12 seg.

Evidentemente, la mayor parte del tiempo de espera se la lleva la carga del programa.
Te recuerdo que el programa, sin pantalla de bienvenida, en Windows tarda en cargar y presentar el primer tablero UN SEGUNDO ESCASO.

Voy a estudiar el enlace que me dejaste y te cuento.

Saludos.

Cuantos y que componentes tenés en el form?

Hola a todos.

Agradeciendo el desinteresado interés que habéis puesto ambos en ayudarme.

Para los que defienden lo "indefendible" (Neftalí) Para los que creen que tengo cosas raras y pesadas en mi código (Agustín)

Para el que quiera escucharlo.

He hecho más pruebas.

Código Delphi [-]
unit Principal;

interface

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.Objects,
  FMX.Controls.Presentation, FMX.StdCtrls, FMX.Layouts;

type
  TPrin = class(TForm)
    ScaledLayout1: TScaledLayout;
    Label1: TLabel;
    Label2: TLabel;
    Label3: TLabel;
    Label4: TLabel;
    Button1: TButton;
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Prin: TPrin;

implementation

{$R *.fmx}

end.

Aquí tenéis un código muuuuuuiiiiii peeeeesaaaadoooo.

Ninguna TLabel tiene más de 4 palabras.

¿A que no sabéis lo que tarda en aparecer la pantalla en mi tableta Samsung GalaXY Tab 3?

Bien. Probarlo vosotros y la solución mañana.

Saludos.

Por cierto. Agustín.
El link que me me dejaste, he estado trabajando toda la tarde con él y tres cosas:
1.- El código bajado no compila. No encuentra el directorio c:\res (Es el error que da).
2.- Generando un proyecto nuevo y copiando el código. Intenta poner en marcha la unidad Principal2.pas (que es el programa de Sudoku) y el sistema Android de la misma tableta lo aborta antes de verse la pantalla del Sudoku.
3.- Este método es muy similar al que yo estoy utilizando con la unidad que he colgado más arriba ampliado en un único procedure llamado Button1Click() y que lleva el código siguiente:

Código Delphi [-]
procedure TPrin.Button1Click(Sender: TObject);
begin
Prin.Visible:=False;

Princi.Show; // El nombre de la unidad Principal2.pas (que lleva todo el programa de sudoku)

end;

Este es el esquema del programa de la unidad Principal2.pas que lleva todo el programa de Sudoku

Código Delphi [-]
unit Principal2;

interface

uses
.....................

  TPrinci = class(TForm)
...........

var
  Princi: TPrinci;
...........

Y con esto si que arranca el programa Sudoku, pero tarda en salir la pantalla de TPrin, (que es la pantalla de bienvenida) (os lo digo porque ya es mañana) 18 segundos con el código que os he puesto.
Y después de pulsar el Button1, tarda otros 12 segundos en arrancar el programa de TPrinci (o sea el programa verdadero de Sudoku).

Estuve mirando seriamente lo de los hilos, como dijo Neftalí, pero no encontré cómo implementarlos y sospecho que el programa lanzador tardará otros 18 segundos (en negro) en arrancar, con la fea e innecesaria imagen que transmite esa pantalla que todos sabemos que es de relleno y de espera.

Saludos. Buenas noches.

Los thread no van a ser la solucion, al menos no de manera simple. En lo unico que te puede ayudar un thread es si implementas el codigo en paralelo, y como dije, es algo muy complicado a menos que entiendas que son los deadlocks, como compartir recursos entre varios hilos, y como permitir a esos hilos que escriban en el mismo recurso

Yo he hecho aplicaciones Android simples y tambien "complejas" por ejemplo que se conectan a servidores remotos, guardan informacion en forma local, y muestran tablas de bases de datos y no he tenido grandes problemas

No me respondiste la pregunta

Si realmente creas un form con 4 label no te puede tardar ni 12 ni 18 segundos nunca

Hola de nuevo, Agustín.
Es cierto, no te he respondido a tu pregunta por que realmente son muchos controles. Tampoco tú has hecho la prueba con el código que he copiado más ¡arriba. Solo este código tarda 18 seg. en arrancar la tableta de referencia.

Sin ninguna instrucción y sin más código que el que he copiado antes. Solo para mostrar la pantalla, un contenedor TScaledLayout, 4 etiquetas de menos de 4 palabras y un boton sin siquiera el procedure Button1Clic() ¡¡¡Tarda 18 seg.!!! en el dispositivo indicado.

Me gustaría que alguien hiciera la prueba. Quizá mi dispositivo no funciona correctamente... Aunque tengo que decir que todos los programas que tiene arrancan casi instantáneamente incluidos los AJUSTES, que tiene una lista bastante grande con una imagen cada item.

Ah se me olvidaba comentarte que, en mi tableta, el programita en cuestión (El de las 4 etiquetas y un botón vacío) ocupa 53,46 MB y el de Sudoku completo 54,98 MB. Por favor que alguien me lo explique...

SALUDOS.

No he hecho la prueba porque no tengo Delphi para Android para jugar en mi casa. Ademas no tengo una tablet como la que comentas, yo solamente puedo hablar de los dispositivos con los que probe

Te puedo decir que experimentos si he hecho, varias programitas "versatiles" con varios form, frames, objetos, listas, base de datos, invocaciones rest.. y no ha habido problemas

Entre los dispositivos que usamos, no hay ningun "tope" de gama. De hecho una es una tablet "generica", aunque si es cierto que cuenta con 4 procesadores y 1 gb de ram; tampoco es tan mala. Corre en un Android 4.4

El otro dispositivo de diferencia es un telefono Motorola Moto G 2013. Este tambien es un quad-core y cuenta con 1gb de ram, es muy similar en rendimiento a la tablet. Este corre en Android Lollipop 5.1

Lo del tamaño si que lo entiendo y eso no tiene solucion. Me explico, firemonkey es una plataforma "nativa" pero para funcionar tiene que tener incluido cierto runtime. Si la memoria no me falla, la unidad de codigo se llama FMX.StartUp o similar, si quitaras esa unidad el tamaño del ejecutable baja drasticamente pero obviamente no funciona. Es por eso que programas que en apariencia son muy grandes ocupan casi lo mismo a uno vacio: porque se copia todo el runtime que da soporte a FMX.

Lo que si es realmente una pega es que dicho runtime tengamos que desplegarlo siempre y en cada aplicacion, y no una vez por dispositivo

Bueno, gracias.
Al menos me quedo más tranquilo con lo del tamaño de la App.
Voy a revisar toda la estructura del programa a ver si se puede optimizar.
Según el programa SysCheck las características de la tableta son muy similares, 4 nucleos 1,6GHz, android 4.4.2.

Saludos.