All the Log Shipping jobs run on their fixed schedule, while the number of files they process each time may be variable. The Copy jobs perform a "best effort" copy of all files that haven't been copied yet and aren't currently in use. The Restore jobs perform a "best effort" restore of all the files available that haven't been restored yet. However, that is contingent on adhering to any other rules you may have specified (ex. Setting a restore delay of 2 hours so you can possibly retrieve data off your Secondary if someone does an unintentional change/delete of data on the Primary).
Essentially, you can think of each job as taking a kind of Work Queue approach that first creates a list of work to perform before processing each item on that list. If a transaction log backup is still writing to file DBTranLogBackup.bak at the time the Copy runs, that particular file will not make it onto the list of work that can be performed and will get processed during the next run of the job.
Hope that helps.