首先，我们从源头的数据量来考虑。我们的理想是，图像非常清晰，质量高，录像出来的文件都像美国大片那样细腻。但是现实是做不到的，主要产业链的瓶颈还是在存储上跟编码的效率上。编解码目前主流的还是H.264的，支持H.265的并不多，那么我们就以H.264来讲，图像编码的质量越高需要的码率也就越高，单位时间内需要存储的编码后的视频数据量就越大。目前纯行车记录仪的产品，比如小米的、360的他们支持前视录像的，码率都达到了10Mb/s以上，1080P的，每分钟存储量达到100M以上，理论上C4及以上的SD卡就能满足了，但是SD卡的品质参差不齐，还有很多造假的，杂牌厂贴牌的，比如C4的卡刚开始使用，可能可以达到3M以上的读写速度，但是卡用一个月后，性能急剧下降，可能就不到2M了，越往后就越慢，因此基本上都是配的C10的卡，考虑性能效率下降，在3个月内还能扛得住。SD卡作为一个易耗品，本来也是要经常更换的，一般3～6个月更换一次比较好。在做同时录前视加上后视的产品上，因为存在前后两路视频数据需要存储，这对存储卡的操作就更频繁了。考虑到两个不同线程对同一张卡的操作效率的考虑，两路码率跟一路同样码率大小的产品对比，两路明显需要更多一点的写入时间。很明显的就是，我们在电脑上给U盘拷贝两个东西，我们一个一个拷的速度比两个同时拷的速度还快一点，就是不需要两个互斥同步的时间消耗，另外也是一个批量写入跟两个零散写入的差别。因此，建议在图像足够清晰的情况下，码率尽量低一点，减少视频数据的存储量，选用C10及以上的卡。
刚刚我们已经了解了视频数据源跟写入存储器的一些基本知识，那我们就再从系统的角度来看视频数据的共用。我们知道，行车记录仪的图像可以预览，也可以不预览，但是录像功能在后台都是可以工作的。从效率上考虑，目前预览跟录像使用的视频数据都是同一个buffer的，属于共享的。如果有阻塞会造成行车记录应用出现黑屏的问题，就是预览或者录像未及时释放buffer，造成底层camera驱动没有buffer接收新的视频数据，造成这种堵塞后就预览也预览不了，黑屏满满的，另外录像也不可能正常了。因此，我们需要监控这个视频数据buffer的空闲情况，比如有10个buffer，如果当有8个被占用了，那我们就需要加快消耗的速度，但是加快消耗的速度不大好控制，一般还是控制输入的速度，比如预览的图像我不送那么快了，处理不过来了就不连续送那么多，比如没两帧送一帧，如果还没有效果到更严重时，就要考虑少喂一点视频数据帧给编码器了，这是万不得已的情况了，整个功能异常总比视频数据丢掉一些帧要更糟糕吧，丢也不能丢太多了，比如25帧的，你丟个3～5帧也顶多了，太多了就没意义了。实在不行，我们在buffer即将满的情况下，通知一个消息给DVR应用，暂停一下录像，这个我在前面的文章中也提到过。
另外，在写入数据的地方也是有很多门道的。两路数据的写入尽量隔开一点时间，一般采用固定码率的产品还比较多，这样两路的编码数据写入理论上是有周期的，在这种周期相撞的情况下，软件上控制一下后来的那一个任务稍微延后执行一下，尽量错开，这样SD卡的工作效率也更高一点。笔者在前面的文章中有专门介绍过具体的处理方法。另外还有编码堵塞其实也是可能监测的，如果堵塞了可以想办法发送消息给应用去处理，比如降低码率来降低符和。
当前面的常规方法都还拯救不了DVR的情况下，可以考虑临时性的杀一下mediaserver进程，此方法很有效，也有弊端，极端的情况下这种方法也救不回来，不过这种方法出异常时90%的情况下还是可行的。
除此之外，我们还需要监控一下SD卡的品质，比如是什么样的等级的卡，如果等级低了，我们提醒用户去换更换的卡，减少一些非法拔插SD卡的动作，要警示用户可能导致功能异常。目前在存储上，使用预分配的方法可以获得更好的SD读写性能，相等于分好了一块一块的，这样会减少多次分配的碎片问题，这样效率会高很多。
很多产品只有这个功能的，弄稳定还相对容易一些，在一些功能比较多的产品上做行车记录的功能，要做稳定需要更大的精力跟耐力。系统CPU也是多个任务在共用，CPU轮转不及时就可能堵塞造成功能异常，功能越多越复杂，留给DVR的操作余量要越大。多考虑一下异常情况下怎么做，各个条件都好的情况下，一般的工程师都能做出好产品。很多时候，我们没有那么足够的资源下去干一些相对多的事情，当然需要想更多的办法！
做车载产品不容易，做好车载产品更不容易，前行去珍惜，做好了大家还有口饭吃！加油！
