Unity3d the problem of dynamic batch processing

This period of time to do Unity3d optimization, the main start is to reduce draw call.
1, the code is mainly a number of pieces of the same material to merge into a large mesh.
2, reduce unnecessary full-screen post-processing. The rendering path of the camera is changed from deferred to forward. The reason for this modification is that we only use one light in our scene, the deferred rendering does not have much of an advantage, and the dynamic merging of the engine works well if we use forward rendering.
With the above two sections, draw call is much reduced and the game runs smoothly on the target platform. But there is a very obvious problem: there will be noticeable cracks flashing on the edges of the two objects, such as the connection of one leg to another.
The first thought was that the accuracy of depth buffer caused the depth fighting. So adjust the camera near clip, but also will appear, just adjust the near clip also has restrictions, otherwise it will affect the game, in the adjustment near clip and the anti-aliasing anti aliasing settings adjustment of the 8* cracks of the flash will not be so obvious, but also exist. Want to use W buffer instead of depth buffer to try, but it is not clear how unity to deal with, (at that time, if there is no way to program the connection of the grid itself to merge, so there will be no cracks) so first stop doing the other. It was not obvious, at least, to think of how the rift phenomenon had not been noticed before. So think it will be rendering path, different caused it.
Build two programs, using a different rendering path. It is true that the use of deferred rendering will not have the phenomenon of cracks, and forward rendering will have, it is really confusing the mind ah, two different ways of rendering how can this happen? Still do not believe is due to different rendering methods, continue to find the reason, found two cracks flash mesh, is used the same material, think will be the reason for dynamic batch processing?
Removing the dynamic batching crack flicker in the play setting when using forward rendering will not occur, and the final determination is the problem caused by the dynamic batch processing provided by the engine. So why not use deferred rendering, because the engine is limited to dynamic batching with deferred rendering, (you add two draw call for each cube added on the 4.x version of Unity, and the forward rendering will help you dynamically batch, Does not add draw call to each cube.
It's easier to know where the problem is, but why its dynamic batching can cause cracks to blink, and the question remains to be researched, but how unity is implemented inside is not known. Hope to understand this aspect of people can guide twos!

Unity3d the problem of dynamic batch processing