Today, everything can be video, short video content as a new promotion point of mobile terminal products, received more and more attention and input. In addition to basic optimization such as second broadcast, delay rate and playback success rate, Hema introduces the ability of traceless continuous broadcast in user experience to improve the continuity of video content watched by users. This article will share hema’s practice in iOS short video.

Author | God catch proofread | Tai Yi

Cross-page continuation is another feature that adds to the user experience in terms of motion in addition to second playback. Some business scenarios need to play scenes with the same video content on different pages, and the page switching of these scenarios is often continuous, which requires that short videos be played continuously. Only in this way can the experience be consistent, so that when users enter the immersive page, they can smoothly transition and continue to play without perception, so as to produce continuous and uninterrupted feelings. Let’s start with the cross-page continuation ability and smooth animation switching effect of Hema short video.…

As shown in the video above, after the video is previewed on the list page, the user is likely to continue clicking to jump to the next full-screen page and enter the immersive experience. In this process, the video window smoothly expands to full screen, the video progress is continuous, and there is no sense of pause in the video or audio. After the page returns, the video window also has the corresponding restore effect.

The target

Easy access, only need to care and add a parameter, other logical cohesion. Good adaptability, support cutting mode switch. Video and audio are seamless without any sense of pause. The playing status between pages is isolated and does not interfere with each other.

Implementation scheme

In the selection of the scheme, the following three main considerations were taken into account:

At present hema uses the third way — playerView reuse, specifically, the realization of traceless continuous seeding, at least the following steps:

  1. A user clicks to switch from page A to page B, for example, domain/ Path? ReusedPlayerView = 0xYYYYYY, add a reusedPlayerView parameter on the basis of the original service parameter, and pass the playerView to the next page.
  2. B page HMTBPlayerView instantiation: internally instantiate A reusedPlayerView or reuse A page.
  3. PlayerView size position conversion, achieve switching animation.
  4. When you return to A from page B, the implementation exits the animation and returns to playerView.

The above steps are few, but the specific implementation is relatively complex. We will focus on the solution process of four major problems to explain the specific implementation methods.

Size change animation

Normally, if you calculate the original Rect of the playerView, and the final Rect of the playerView, you can easily make the window bigger by animating the frame based on UIView. However, it was found that the setFrame method was rewritten inside the hand-tao player. As long as the frame was modified, the playerView would be directly displayed as the final state, and the animation would have no effect.

Therefore, the scale implementation of CGAffineTransform is adopted here: PlayerView frame is set to final state, first calculate well before and after the change of dimension scale thewire, set the playerView. Transform = CGAffineTransformMakeScale (thewire, thewire), Scale it down to its initial position size, and then you can animate the Transform from start to finish.

It should be noted that ratio is calculated using the actual rendered video size in the playerView, not the size of the playerView itself.

Render mode switch

The video rendering itself can be set as ScaleAspectFit or ScaleAspectFill. At present, in hema’s scene, there is A player of page A with Fill mode and A fixed square playerView, but when jumping to page B, Change to Fit Mode, so there is a problem with mode switching during the size change animation.

The above method of setFrame and transform modification can achieve the size of the playerView to be consistent with the initial size before animation. However, if there is a need for mode switch, the size after calculation may be inconsistent, for example, from a 9: The rectangle playerView becomes a 1:1 square PlayerView with mode fill. At this time, the width is the same, but the height is significantly higher. Direct animation will cause the initial state to flash.

Solution here, we use the mode switching transition maskView: first, calculate maskView respectively on the wide high scale, and then set the playerView. MaskView. The transform. The calculation method is as follows:

CGAffineTransformMakeScale(originalRect.size.width/(destRect.size.width*ratio), originalRect.size.height/(destRect.size.height*ratio))
Copy the code

In this way, maskView is used to display the 9:16 rectangle into a 1:1 visible area, and the starting position of the animation coincides. Finally, combined with the playerView.transform animation above, add another maskView.transform animation, the two work together to simulate the animation transition effect in the mode switching scene.

Proactive recovery and proactive return strategies

After the entry animation is implemented, the most important thing to consider is the playerView reuse logic, one of the more important points is when playerView is returned to page A.

At present, we adopt the idea of renting:

  1. When you have a playerView to borrow, borrow it;
  2. Reuse playerView is no longer in use, timely active return;
  3. When the lessor himself to use, found that the lessee has not returned, at this time to take the initiative to recycle.

For specific scenarios: when entering the site, reusePlayerView is judged to be available and reused; When the immersive video (B page, similar to Douyin) is flipped to the next video, the previous video will be actively returned. If the user moves back to the first video, it will be a new playerView. In addition, when users click on the page to close, actively return (if not already returned); In particular, an active recycling mechanism is added here. For example, when the user returns to page A through some unknown means, the reusePlayerView does not actively return at this time, but page A needs to play itself, so the active recycling mechanism is triggered to ensure the current page is available.

One thing to mention is that when the page returns, it also has an animation, which is similar in implementation, except that when the page returns, it might have a dealloc, and it might have a problem with the animation, so what we’re going to do is we’re going to take the playerView from page B, add it to the window, do a zoom animation, and when we’re done, Then voluntarily return to page A.

State of isolation

An important consideration when using player reuse is the isolation of player state and Settings after reuse. For example, after page A enters page B, the player continues to play without trace, but the player state is paused for Page A and must be played for page B, even though they use the same playerView.

This isolation is necessary, for example, if the business wants to direct the user to page A, where he gets credits for watching A video, then he should not continue to collect credits when he gets to page B (the business relies on playing status notifications). In addition, the playing Settings of page A and page B may be different. Page A may be mute, while page B has sound. Different Settings also need to be isolated. Here’s how we do it, as shown below (view level) :

In the picture, the outermost view is hema’s own packaged player HMTBPlayerView, and inside there is a hand-washed TBMPBPlayerView of the same size. So what we’re going to reuse is the TBMPBPlayerView layer, and we’re going to put all the business layer Settings in the HMTBPlayerView, so when the TBMPBPlayerView is removed, we’re going to set it up again according to the new HMTBPlayerView, and we’re going to associate it, The old HMTBPlayerView Settings are not affected, including player callbacks.


To sum up, we have realized a way of player reuse, realizing the logic of window switching and state isolation inside the player, which is almost insensitive to App users. This scheme can not only be used in the scene of traceless continuous play, but also in the optimization direction of global player instance reuse in App in the future.

“Video cloud technology” your most noteworthy audio and video technology public account, weekly push from Ali Cloud front-line practice technology articles, here with the audio and video field first-class engineers exchange exchange. You can join ali Cloud video cloud product technology exchange group, and the industry together to discuss audio and video technology, get more industry latest information.